The four things we check first when a site is compromised
When someone messages us saying their site has been hacked, these are the four things we look at before anything else — and why the order matters.
The message usually arrives the same way: a site is redirecting to somewhere unexpected, or the host has sent a warning, or Google is showing a warning label. The person on the other end wants to know one thing — how bad is it?
Before we can answer that, four things need establishing. In this order.
1. Is it still happening?
The first question is not what happened but whether it is ongoing. A site that was compromised three months ago and cleaned badly is a different situation from one where an attacker has an active session right now.
We look at recent file modification times, active sessions, and outbound connections. If something is live, containment comes before investigation — because the alternative is investigating a moving target while it does more damage.
2. What actually changed?
The visible symptom is rarely the whole picture. A redirect might be one modified line in a theme file, or it might be one of forty changed files with three separate backdoors.
File integrity comparison against known-good sources gives the real answer. Anything modified, anything added, anything with a timestamp that does not fit the deployment history.
The single most common mistake we see is cleaning the visible symptom and stopping. The backdoor is almost never in the file that was doing the obvious thing.
3. How did they get in?
This is the question that determines whether the cleanup holds. Cleaning files without closing the entry point means the same compromise recurs, usually within days, and usually people conclude the cleanup was incomplete rather than that the door is still open.
Entry points cluster around a small set of causes: an outdated plugin or component with a public exploit, credentials that appeared in a breach elsewhere and were reused, a file upload that accepted more than it should have, or an exposed admin interface that was brute-forced.
Logs answer this if they still exist — which is why the first thing worth doing, before anything else, is preserving them. Many hosts rotate logs within days.
4. What did they reach?
Finally: what was exposed. Customer data, credentials, payment details, or nothing beyond the web root. This determines your disclosure obligations, and it is the question your customers will ask.
Sometimes the honest answer is that the logging was not in place to say for certain. When that is the case we say so, rather than guessing in either direction, and help work out what to assume for disclosure purposes.
What to do before you contact anyone
- Do not delete anything — including the malicious files. They are evidence.
- Preserve your logs, especially access logs, before your host rotates them.
- Take a full backup of the current compromised state, separate from your clean backups.
- Change passwords from a machine you trust, not the potentially compromised one.
- Do not rebuild from a backup until you know when the compromise started, or you may restore the backdoor.
If you are in this situation now, message us and we will work through it with you.