Shared-host intrusion
A seven-day active intrusion on a shared host carrying 302 client accounts, contained with no data lost on any account.
May 2026
Led the response
I did not find this one. The host’s daily malware scanner flagged it and the hosting provider’s staff confirmed it; I led the remediation with them over the following week. The compromise reached root, which meant the response had to assume every credential on the box was already in someone else’s hands and act on that assumption rather than hunt for proof of it.
They were not after the data. The payload hijacked visitor clicks and pushed them out to online casino affiliates, so every compromised site was quietly monetising its own audience for someone else. That shapes the response: the damage is to the client’s traffic and reputation rather than to their records, and it is invisible from the admin side.
Two moments decided the outcome. A full-access root API token was created while the incident was still open, and was revoked with the session that made it still live. And a second sweep, run because the first pass had a blind spot I could name, turned up two obfuscated backdoors the first cleanup had walked straight past. Nothing was deleted. Every artifact was quarantined and preserved, because a cleanup that destroys its own evidence cannot be audited afterwards.
- client accounts on the affected host
- 302
- of active intrusion, contained
- 7 days
- cPanel passwords rotated in one proactive sweep
- 296
- accounts’ CMS files reverted after a hijacked sync
- 90+
- upload directories hardened; 1,106 others deliberately left alone
- 611
- previously compromised accounts re-verified two weeks later, all clean
- 22
Five sites dropped during the password sweep, my own change:, a database host-entry mismatch, diagnosed and restored in about ten minutes. The attack caused no outage; I did. Ten minutes on five sites bought 296 rotated credentials in a single pass, and 302 accounts that kept their data.
