Taking over a compromised website: account audit, clean-up and rebuild

This case study is about one of my own websites, and that is deliberate: a security incident belongs to whoever suffered it. I do not publish my clients’ incidents, even anonymised. This one is mine, so I can show the complete procedure — it is exactly the one I follow when I am entrusted with a compromised website.

What happened

The website was returning a 500 error, with a suspected infection. Two classic aggravating factors: no usable backup at the time of the incident, and uncertainty about what had been deployed last. This is the situation most troubleshooting requests arrive in — rarely a clean website with a clear history.

The first rule: the scope is not the website

The most common mistake is to clean the website and put it back online. On shared hosting, the compromised scope is the entire account, not the website’s folder: the other websites hosted on the same account, the scheduled tasks, the mailboxes, the access credentials. Cleaning the website alone means getting reinfected within the week.

The procedure applied

• An audit of the entire hosting account, not just the website that was down;
• Purging SSH keys — every key that was not formally recognised was removed;
• searching for entry points: abandoned plugins, outdated PHP versions, files dropped outside their expected locations, auto-loaded extensions;
• a clean rebuild rather than a repair, when the state of the website makes it impossible to guarantee nothing remains;
• checking the second hosting account, to make sure the incident had not spread.

What I take from it, and what I propose next

Getting back online is not the end: without verified backups and hardening, the same incident happens again. It is the part clients often cut back on in an emergency, and it is the part that costs the most the next time. I say so beforehand, not afterwards.

See also: Security and troubleshooting · Maintenance and support.