On November 2, an attacker successfully breached the update infrastructure of **cPGuard**, a security solution developed by **OPSSHIELD**. This compromise allowed the attacker to push a malicious script to customer **Linux** servers via the legitimate update channel. ### The Attack Vector and Timeline The incident began at 02:06 UTC when an unidentified attacker gained access to **cPGuard's** update system using compromised credentials. The malicious script was then distributed through **cPGuard** versions 5.88.12 to 5.88.19. **OPSSHIELD** detected the attack within 12 hours of the malicious versions being released. ### Malicious Script Functionality The deployed script was designed to install a backdoor on affected servers. More critically, it collected various sensitive files, including `/etc/shadow` (containing one-way password hashes), `/etc/passwd`, root's **MariaDB** or **MySQL** configuration (`my.cnf`), root's shell history, and **SSH** authorization and known-hosts files for root. This data was then uploaded to a compromised **OPSSHIELD** licensing server, from which the attacker subsequently exfiltrated 32 files, each linked to a specific customer server.  ### Remediation and Detection **cPGuard** versions 5.88.25 and later address the vulnerability by removing the backdoor and the files left by the script. However, **OPSSHIELD** stresses that credentials copied by the script may still be valid, necessitating a full password and key reset for any potentially compromised server. Administrators can check for affected versions by examining their update logs: ```bash grep 'Successfully updated' /opt/cpguard/logs/install_log ``` An entry for any version between 5.88.12 and 5.88.19 indicates the server received an affected update. Even if the server is now running a patched version, it should be treated as potentially compromised. If logs are missing or incomplete, or if there's any uncertainty, **OPSSHIELD** Support should be contacted. ### Immediate Actions for cPGuard Admins **OPSSHIELD** advises the following critical steps: 1. **Update cPGuard**: Run `cpgcli update --start` on each server and verify the version is 5.88.25 or later using `cpgcli --version`. 2. **Password Reset**: From a trusted recovery environment, reset passwords for root and all other local **Linux** accounts. Change any of these passwords that are reused on other systems from a trusted device. 3. **Rotate Secrets**: Rotate database passwords, **S3** access keys, **DigitalOcean** tokens, and any other secrets found in root's shell history. 4. **Replace SSH Keys**: Replace **SSH** private keys located under `/root/.ssh` and remove the corresponding old public keys from all trusting systems. While **OPSSHIELD** is not currently recommending a full system rebuild as a routine measure, this stance may change. Admins discovering further signs of compromise should seek case-by-case review from **OPSSHIELD** Support. ### Additional Security Measures As a precautionary measure, **OPSSHIELD** is releasing another update to remove its support-access keys from **cPGuard** servers where they were previously added. The company has not yet confirmed whether the private key associated with its support-access feature was exposed during the attack. ### Files Left by the Malicious Script **OPSSHIELD** identified the following files and directories associated with the attack. Their absence after an update does not confirm the script never ran: * **File**: `cpguard-v58812-i91511.sh` (the malicious script) * **File**: `/var/tmp/.cpg91511_sh` (backdoor shell) * **Directory**: `/var/tmp/.cpg91511` (where files were gathered) * **File**: `/var/tmp/.cpg91511/loot.tgz` (prepared archive)