The first hour after your website is hacked

The call usually starts the same way. A customer has emailed about a strange redirect, a browser is showing a red warning page, or the hosting company has suspended the account for sending spam. Whoever discovers the problem wants it gone immediately, and that urge causes most of the lasting damage we see. Deleting suspicious files, restoring last night's backup and changing one password feels decisive, but it often destroys the evidence you need to find the entry point and leaves the attacker's back door intact. Here is the sequence our on-call team follows in the first hour, written so that a non-specialist can follow most of it.

Minutes 0 to 15: contain without destroying

The goal of the first fifteen minutes is to stop the harm to visitors and customers while keeping the crime scene intact.

• Put the site into maintenance mode at the edge, not in the application. If you have a CDN or firewall, serve a static maintenance page from there. A compromised application cannot be trusted to show its own maintenance page.
• Do not delete anything yet. Rename or move nothing. Every file timestamp is potential evidence.
• Take a full snapshot. Copy the web root, the database and the server logs to storage the compromised host cannot write to. If your host offers disk snapshots, take one.
• Revoke the obvious keys. Rotate hosting control panel, SFTP, database and administrator passwords from a device you trust. If the site handles payments, disable the payment gateway integration temporarily.

A fast cleanup that misses the back door just schedules the next incident. The first hour is for containment and evidence, not for looking fixed.

Minutes 15 to 35: understand what happened

With the site contained, you can start asking questions. You are looking for three things: what the attacker changed, how they got in, and whether they are still inside.

What changed

Compare core application files against a clean copy of the same version. For WordPress, the official checksums make this quick; for custom applications, compare against the last tagged release in your repository. Then list files modified in the last 14 days and look for PHP files in upload directories, unfamiliar must-use plugins, and recently edited theme files such as functions.php or header.php. In the database, check the users table for new administrators and the options table for injected scripts.

How they got in

Access logs usually tell the story. Search for POST requests to unusual endpoints around the time the first modified file appeared. Common entry points we see, in rough order of frequency:

1. A plugin or theme with a publicly disclosed vulnerability that was never patched.
2. Stolen or reused credentials for an administrator, SFTP or hosting account.
3. A neighboring site on the same shared hosting account that was compromised first.
4. A leaked API key or deployment secret in a public repository.

Whether they are still inside

Look for scheduled tasks, cron entries, extra SSH keys and unknown user accounts. Attackers rarely rely on a single back door; we typically find two to four persistence mechanisms on a compromised site.

Minutes 35 to 50: decide how to recover

At this point you choose between cleaning the current installation and rebuilding from known-good sources. Our default is to rebuild whenever possible:

• Rebuild means fresh core files, fresh plugin and theme files from official sources or your repository, and only the uploads and database carried over after inspection. It takes longer but leaves little room for surprises.
• Restore from backup works only if you can show the backup predates the compromise. Attackers often sit quietly for weeks, so last night's backup may already contain the back door.
• In-place cleanup is a last resort for sites without clean sources. It requires line-by-line review and a longer monitoring period afterward.

Whichever route you choose, patch the entry point before bringing the site back. Restoring a clean site with the same vulnerable plugin typically results in reinfection within 48 hours, because the automated scanner that found it the first time is still running.

Minutes 50 to 60: communicate

Before the hour is out, decide who needs to know. Internally, that means leadership and whoever handles customer support, with a short factual summary and a time for the next update. Externally, it depends on what data was exposed. If personal data may have been accessed, the clock on regulatory notification has already started; under GDPR you have 72 hours to notify the supervisory authority once you are aware of a breach. Write down the timeline as you go. You will need it later, and memory is unreliable under pressure.

Once the site is restored, request a review from Google Search Console if a security warning was shown, and check that your domain has not been added to email blocklists.

After the first hour

The work does not end when the site is back online. Plan for at least two weeks of heightened monitoring: daily file integrity checks, alerts on new administrator accounts and a close eye on outbound email volume. Hold a short review once things are calm and turn the findings into concrete changes, such as a firewall in front of the origin, two-factor authentication for every publishing account or an update policy with deadlines.

If you would rather not run this playbook yourself, our malware removal service follows exactly this sequence, and our backup and recovery setup makes the decision in minute 35 much easier, because you will know precisely which backups are clean. For ongoing protection, the monthly care plans include monitoring that usually catches a compromise before your customers do.

Have an incident right now, or want to be ready for one?

Tell us what you are seeing and we will give you a fixed price for cleanup and hardening, usually within a few hours for active incidents. Contact our team and include your host and platform so we can start immediately.