The challenge
Malware had compromised the site badly enough that the host suspended it, which meant paying members couldn't log in and recurring revenue was actively at risk with every hour of downtime. The client's first instinct — understandably — was to restore last week's backup and get back online immediately. That would almost certainly have reinfected the site, because the vulnerability that let the attacker in was present in that backup too, and as it turned out so was one of the backdoors. The pressure to rush is the single most dangerous thing about incident response.
State at first contact: site suspended by host, 1,847 active member accounts inaccessible, membership plugin running a version with a publicly disclosed unauthenticated file-upload vulnerability, no filesystem integrity monitoring in place, and admin credentials shared across three people.
The approach
The instinct after a hack is to restore a backup and move on. That is precisely how sites get reinfected within a week — the backup usually contains the same vulnerability, and often the same backdoor. Cleanup has to be evidence-led or you're just resetting the clock for the attacker.
The results
Service was restored within six hours and members were back in the same working day. Verification against the pre-incident backup confirmed all 1,847 member records intact. The part worth highlighting is what the filesystem diff caught: two of the three backdoors were in an uploads directory, exactly where a straight backup restore would have preserved them. That is the usual reason 'cleaned' sites get reinfected a fortnight later, and it's why the diff step isn't optional.
What this didn't cover
This was incident response, not a security retainer — monitoring was configured but ongoing management is billed separately. I gave no advice on GDPR breach-notification obligations; the client took that to their own legal counsel, which is where it belongs and where I'd always send it. Payment card data was never in scope because the site used a hosted gateway, so no cardholder data was exposed to the compromised environment. The membership plugin was patched rather than replaced, so the underlying vendor risk remains and is worth revisiting. I also can't prove no data was exfiltrated — nobody honestly can after the fact; what I can confirm is what was verified intact and what was removed.
Services used on this project
Want the same for your site? Start here: