ThreatRoundup
HighIOCsBleepingComputer

cPGuard’s Own Updates Stole Server Passwords and Planted a Backdoor

An attacker with stolen credentials pushed malicious cPGuard updates (5.88.12 to 5.88.19) on Nov. 2, collecting password hashes, database configs and SSH keys and installing a backdoor shell. OpsShield says 2,946 servers were affected; update to 5.88.25 and rotate secrets.

ThreatRoundup · · 2 min read

The security tool that was supposed to guard Linux web servers spent part of Sunday robbing them. BleepingComputer reports that an attacker used stolen credentials to get into OpsShield’s update distribution network on Nov. 2 and pushed a malicious script out through cPGuard’s automatic updates. OpsShield’s advisory says the script grabbed password hashes, database and SSH files and planted a backdoor shell; a company spokesperson put the number of affected servers at 2,946.

For defenders

What’s affected: cPGuard 5.88.12 through 5.88.19, the versions pushed from 02:06 UTC on Nov. 2. OpsShield says it caught the attack and stopped distribution within 12 hours, and that some servers may never have pulled the script because update checks run on a schedule. The fix is 5.88.25 or later (cpgcli update --start, then check cpgcli --version). cPGuard runs alongside cPanel, DirectAdmin and Plesk, and Namecheap bundles it on VPS and dedicated plans, so plenty of hosting customers have it without having chosen it.

What the script did: it copied /etc/shadow and /etc/passwd (T1003.008 (OS Credential Dumping: /etc/passwd and /etc/shadow)), root’s MariaDB/MySQL my.cnf, root’s shell history (T1552.003 (Unsecured Credentials: Shell History)) and root’s SSH authorization and known-hosts files (T1552.004 (Unsecured Credentials: Private Keys)), staged them in an archive and uploaded it to OpsShield’s own licensing server through a compromised account, where the attacker picked it up. It also installed a backdoor shell. The delivery itself is a textbook T1195.002 (Supply Chain Compromise: Compromise Software Supply Chain). OpsShield confirms the attacker retrieved data, with a preliminary count of 32 collected files each tied to a customer server, and a spokesperson said the billing database was copied too. No other malicious activity has been found so far, the company says, while stressing that’s preliminary.

Check: grep 'Successfully updated' /opt/cpguard/logs/install_log. Any line showing 5.88.12 to 5.88.19 means treat the server as compromised, even if it’s on a fixed version now. A missing log doesn’t clear it.

Host
cpguard-v58812-i91511.sh (malicious update script)
/var/tmp/.cpg91511_sh (backdoor shell)
/var/tmp/.cpg91511/ (collection directory)
/var/tmp/.cpg91511/loot.tgz (staged archive)

OpsShield published no domains, IPs or hashes, and notes that the absence of these files doesn’t prove the script never ran.

What it means for you

If you rent a server or a VPS (from Namecheap or another host that offers cPGuard), the security add-on that’s meant to keep malware out may have shipped some in. The attacker went after the keys to the box: the server’s password hashes, the database admin password and the SSH keys used to log in. If you only have a shared hosting account and never installed anything yourself, ask your host whether cPGuard was on your server and whether it was in the affected window.

Do this now

  1. Update every cPGuard server to 5.88.25 or later and confirm the version.
  2. Check the install log for 5.88.12 to 5.88.19. If you find one, reset root and every local password from a trusted recovery environment, and change any of those passwords you reused elsewhere.
  3. Rotate database passwords, cloud keys (OpsShield names S3 keys and DigitalOcean tokens) and anything that ever appeared in root’s shell history.
  4. Replace the SSH keys under /root/.ssh and remove the old public keys from every machine that trusted them.

More from the Roundup