A live site, compromised.

01 — The problem

The company's public site began serving spam pages and then stopped responding altogether. It was the front door for a business that was, at that moment, in the middle of a product launch. Nobody on the client side knew how far the attacker had got, whether the database was safe, or whether taking the site down would make things worse.

02 — What we did

• Found the entry vector. Access logs showed the attacker had come in through an unauthenticated batch endpoint on the CMS's REST API, a route that should never have been reachable from the public internet.
• Removed the persistence. Several web shells had been planted across the file tree, and a scheduled task was reinstalling them. We killed the task, catalogued every modified file and confirmed there was no second foothold.
• Restored from a verified clean snapshot. Rather than clean an infected tree in place, we identified the last block-storage snapshot that predated the first malicious write, verified it, and restored both files and database from it.
• Rotated everything. Database credentials, application salts and SFTP access were all replaced. The old ones are dead.
• Closed the hole. The vulnerable route was blocked at the web server, and the site was later hardened further when we traced an unrelated outage to worker-pool exhaustion from brute-force and probe traffic.
• Left a paper trail. A written incident report covering timeline, vector, impact, actions and follow-ups was delivered the same day, so the client could brief its own stakeholders accurately.

03 — How we proved it

• The restore point was chosen from evidence in the logs, not from guesswork, and the restored tree was diffed against the infected one.
• Daily, weekly and monthly backup tiers were installed and tested, so the next incident starts from a known-good state by default.
• Uptime and resource alarms were retuned afterwards so that a repeat would be caught in minutes rather than by a customer.

04 — The outcome

The site was diagnosed, cleaned, restored and back online within a day, with no data loss and no lingering access. The client got a report they could hand to their board, and a backup and monitoring setup they did not have before.

05 — What this means for you

An incident is not the time to find out who owns your infrastructure. If your marketing site or customer portal is run by a CMS that nobody has patched or monitored in a while, a short security review now is far cheaper than a day of downtime later. See our Security services.