Emergency Malware Removal: What to Do in the First Hour

In the first hour after a hack, focus on containment and evidence rather than a full clean-up. Protect visitors and customers, take a complete backup before touching anything, lock the attacker out by changing credentials from a clean device, and record what you see. The thorough clean-up comes next, once the situation is stable.

Discovering a hacked site is stressful, especially if customers are phoning, sales have stopped or Google is showing a red warning. The natural instinct is to start deleting suspicious files immediately. That usually makes things worse: evidence is lost, the attacker's other backdoors stay in place, and the malware returns once you think the problem is fixed.

The plan below is broken into four short stages. It works whether you intend to clean the site yourself or hand it to specialists, and following it makes any professional clean-up faster. If you would rather hand over now, our emergency team starts triage as soon as you get in touch on 01932 593642.

Protect visitors straight away by taking the risky parts of the site offline: switch on a maintenance page if the site is redirecting or serving malware, and disable the checkout if card details could be exposed. Contact your payment provider if you suspect a card skimmer. A few hours offline costs far less than harm to customers.

• Redirects or malware warnings: enable a maintenance page, ideally a static HTML file served by the web server rather than a WordPress plugin.
• Suspected card skimmer: disable the checkout or switch to a hosted payment page, and tell your payment provider.
• Phishing pages on your domain: take the affected folder offline immediately.
• Spam email from your server: stop the mail queue or ask your host to block outbound mail temporarily.

A simple way to put up a maintenance page on Apache without relying on WordPress is to rename the site's .htaccess (keep the original, it is evidence) and add a rule that serves a static page to everyone except your own IP address:

# Temporary maintenance: allow only your own IP
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteRule ^ /maintenance.html [R=302,L]

You should back up a hacked site before cleaning it because the infected files, database and logs are the evidence needed to find the entry point, see what the attacker did and decide whether personal data was accessed. Once files are deleted or logs rotate, that evidence is gone and the investigation becomes guesswork.

Take a full copy of the web root, export every database and copy the web server access and error logs. Store the copy off the server. If you have SSH access, a single archive is quickest:

# Archive site files and logs with a timestamp (read-only snapshot)
tar -czf /root/evidence-$(date +%F-%H%M).tar.gz /var/www/example.co.uk /var/log/nginx
# Export the database
mysqldump --single-transaction example_db > /root/evidence-db-$(date +%F-%H%M).sql
# Record a hash so you can prove the copy is unaltered
sha256sum /root/evidence-*

Do not restore an old backup yet. Many infections sit unnoticed for weeks, so a recent backup may already contain malware, and restoring over the live site destroys the evidence you just saved. Restores are a decision for later, once you know when the infection started.

Evidence also matters for compliance. If customer data may have been accessed, UK GDPR may require you to report the breach to the ICO within 72 hours of becoming aware of it. Read website hacks and UK GDPR.

Lock the attacker out by changing every credential connected to the site from a device you trust: hosting panel, SFTP and SSH, database and all WordPress administrators. Then remove any administrator accounts you do not recognise, force every session to log out and check for unfamiliar SSH keys. Assume any password stored on the server is known to the attacker.

1. Use a clean device. If your own computer might be infected, a new password could be stolen as you type it.
2. Change hosting and server access first. Hosting panel, SFTP, SSH and any control panel such as cPanel or CloudPanel.
3. Change the database password and update wp-config.php to match.
4. Remove rogue administrators and reset passwords for every genuine one.
5. Force logouts. Regenerating the salts in wp-config.php invalidates every existing WordPress session.
6. Check SSH keys. Look in ~/.ssh/authorized_keys for every user and remove keys you do not recognise.

Work out how bad the hack is by checking what else the attacker could reach: every other site on the same server or hosting account, the operating system for cron jobs, services and unknown users, and any personal or payment data the site holds. The answer decides whether you need a site clean-up, a server clean-up or a breach report.

A few quick, read-only checks give you a reasonable first view of scope if you have SSH access. List the web roots on the server and compare modification dates across sites, look at every user's crontab, list running services and check for listening ports or outbound connections you do not recognise. Anything that appears across more than one site, or outside the web root, widens the incident from one website to the whole server.

Also write down who needs to know: your host, your payment provider, your developer or agency, and possibly customers. Clear, early communication prevents a technical problem becoming a reputational one.

In an emergency, avoid deleting files before taking a backup, restoring an old backup over the live site, reinstalling the server before you know what happened, and trusting a single scanner result. Each of these feels like progress but either destroys evidence or leaves the attacker's other backdoors in place, so the infection returns.

• Do not only delete the one file a scanner flagged.
• Do not change passwords from a device that may be compromised.
• Do not request a Google review until the site is fully clean; a failed review can delay the next one.
• Do not announce the site is fixed until monitoring confirms nothing has returned.
• Do not wipe and rebuild the server in the first hour; you lose the evidence needed to find the entry point.

It also helps to keep a simple written log from the start: what you noticed, what you changed and when. It takes a minute per entry, and it saves hours later when you, your developer or a specialist team are piecing together the timeline, deciding whether a breach report is needed or explaining the incident to customers.

Once the first hour is done, the real clean-up can begin: a full forensic scan, removal of every backdoor, closing the entry point and hardening. If you would rather not do it yourself, PatientZero's hacked website repair handles the whole process, and every plan includes unlimited malware removal with no contract. Start with our emergency triage or call 01932 593642.