Emergency malware removal

The first hour after discovering a compromise decides how long the whole thing takes. Most of the expensive mistakes we are called in to unpick were made quickly and with good intentions — deleting files, restoring a backup, changing one password — before anyone worked out what had actually happened.

Do these first

1. Take a full backup of the infected state. Files and database, exactly as they are. This feels wrong and it is the single most useful thing you can do. It is the only record of what happened, and cleanup is not reversible.
2. Write down the timeline. When did you first notice? What changed recently — a plugin update, a new developer, a migration? This narrows the search enormously.
3. Preserve the logs. Server access and error logs frequently rotate daily. Copy them somewhere safe before the evidence expires.
4. Change credentials from a device you trust. Hosting panel, SSH, database, CMS administrators, and any deployment keys. If a laptop might also be compromised, do not use it for this.
5. Check every site on the same server. Not just the one showing symptoms.

Do not do these

• Do not start deleting files. You destroy the evidence that shows the entry point, and you will almost certainly miss the persistence.
• Do not immediately restore a backup. If the entry point is still open, you have reset the site to a state that gets recompromised — often within hours. And the backup may already contain the infection.
• Do not just delete a rogue admin account and stop. It will be recreated if whatever created it is still running.
• Do not assume a clean scan means clean. Scanners read files. They often miss database injections, server-level configuration and anything living outside the web root.
• Do not pay a ransom before getting advice. On web servers, recovery without payment is frequently possible.

Should you take the site offline?

It depends on what the malware is doing. Take it down, or put it behind a maintenance page, if it is actively serving malware to visitors, hosting a phishing page, skimming card details, or sending spam — the harm to other people and to your domain's reputation is worse than the downtime. If the infection is dormant or limited to injected spam pages, controlled cleanup with the site up is usually the better trade. Either way, keep the evidence.

What our emergency response does

1. Investigate. Establish the entry point and the timeline from the logs and filesystem before touching anything.
2. Quarantine. Isolate webshells and malicious uploads so they stop running, while keeping them as evidence.
3. Remove the persistence. Rogue administrators, injected core files, overwritten configuration, cron and systemd jobs, fake system binaries and unexpected SSH keys.
4. Repair. Restore damaged core files and recover overwritten configuration and database connections.
5. Harden. Block script execution in uploads, lock down firewall and SSH, audit administrator accounts, and close whatever was used to get in.
6. Verify and monitor. Confirm every site on the server is clean and online, then keep watching — a successful compromise is usually followed by further attempts.

After the site is clean

• Request a review if you were flagged. See removing a Google blacklist warning.
• Rotate anything the attacker could have read — API keys, mail credentials, payment integration secrets stored in configuration files.
• Consider your disclosure obligations. If personal data may have been accessed, UK GDPR sets a 72-hour window for notifying the ICO. Take proper advice rather than guessing.
• Fix the process, not just the site. Most repeat incidents trace back to updates nobody owned.

Related guides