Once a hacked site is clean, a harder question remains: how did this happen? Without an answer, you are trusting a site you do not fully understand. You may also need to explain the incident to someone else, whether that is a business partner, a client, or the people whose details sit in your database.
A hack investigation is the work of answering that question with evidence. It runs alongside the cleanup described on our main hacked website help page, but what it produces is different. The result is not a clean site. It is an account of events that you can read, check and act on.
What an investigation is trying to establish
Most owners want answers to the same handful of questions, and it helps to name them before a single log is opened.
- Entry: what weakness let the attacker in. A plugin flaw, a reused password, a leaked FTP login, or a neighbouring site on the same account.
- Timing: when the first malicious action happened. This is often much earlier than when anyone noticed.
- Actions: what the attacker changed, added or ran after getting in.
- Reach: what data they could have read. Order details, contact form entries, user accounts, the configuration file and the database password inside it.
- Persistence: what they left behind so they could return, which our backdoor removal work then deals with.
Not every case needs every answer to the same depth. A brochure site that stores no customer data mostly needs entry and persistence, so that it stays clean. A store or membership site usually needs reach as well, because that decides what the owner may have to tell customers. Where card details might have been captured at checkout, the skimmer removal page covers that particular situation.
Where the evidence comes from
Web server access logs
Every request to the site leaves a line: the address that asked, the time, the URL and the response. Attacks often show up as requests to a plugin file that ordinary visitors never touch, followed by requests to a new file that did not exist the day before. Hosts keep these logs for a limited period and then rotate them away, which is why the first step of any investigation is saving copies. If you would like to read them yourself, our guide to reading activity and server logs once a site has been hacked explains what the lines mean.
Error logs
Exploits are noisy. A failed attempt can leave PHP warnings naming the file and function involved, sometimes days before the attempt that worked.
File system data
Modification times, file ownership, and the content of files compared with clean copies from official sources. An attacker can fake timestamps, so they are treated as clues rather than proof and checked against log entries.
The WordPress database
User registration dates, role changes, injected content in posts and options, and plugin settings that were quietly altered. A rogue administrator account created on a particular day narrows the window a great deal.
Hosting panel and FTP records
Many control panels keep login and file transfer records. A successful FTP login from an unfamiliar location, just before files changed, tells a very different story from a plugin exploit.
Version history
Which plugins and themes were installed, and at which versions, around the time of the attack. Matching those versions against publicly disclosed flaws, of the kind described in how plugin vulnerabilities are found, disclosed and patched, often points to the most likely way in.
How we work through a case
We begin by preserving. Logs, suspicious files and a copy of the database are saved before anything is cleaned, because cleanup changes the very things being examined. If you have already started cleaning, that is not a disaster. It just means some findings will carry less certainty.
Next we establish a baseline. Every site has its own normal traffic: search engine crawlers, the uptime checker, the owner logging in from the same city each morning. Separating that from everything else makes the odd requests easier to spot.
Then we work backwards from the damage. Starting with a known malicious file or account, we find the first moment it appears, then the requests just before it, and keep tracing until the chain either reaches an entry point or runs out of evidence.
Finally, we test the theory. If the trail points at a particular plugin, we check that the installed version had a known flaw that fits what the logs show. A theory that does not match the evidence is dropped, however tidy it looks.
If the trail reveals an infection that is still active, the cleanup itself is done under our WordPress malware removal service, with the investigation findings guiding where to look first.
What the written report contains
The report is written for a business owner rather than another technician, although the technical detail is there for anyone who wants it. It sets out a timeline of the incident with dates and times, the probable entry point and the evidence behind it, a list of what was changed or added, and a frank view of what data the attacker could reach.
Each finding is labelled with how sure we are. “Confirmed” means the logs show it directly. “Likely” means the evidence fits and nothing contradicts it. “Unknown” means the evidence needed was not available. We would rather hand you a report with its gaps clearly marked than one that fills them with guesses.
It closes with recommendations tied to what was actually found. If the way in was a reused password, the advice is about access. If it was an outdated plugin, the advice is about updates and replacement. General advice about “improving security” is not much use after a specific incident.
The report is technical information, not legal advice. If the incident may involve personal data, share it with whoever advises you on your obligations. For general background on that side, see our post on telling customers about a website breach.
Why the cause matters even after the site is clean
It is reasonable to ask why you should care about the past once the site is working again. There are three practical reasons. A cleanup that does not know the entry point can only guess at what to fix, which is how sites end up reinfected; our page on the reinfected WordPress site fix covers what that looks like. The cause also decides who needs to change what: a leaked FTP password is a conversation with whoever held it, while a plugin flaw is a conversation about updates. And if anyone else asks what happened, an evidence-based answer is far easier to give than a vague one.
When an investigation is worth it, and when it is not
Not every hacked site needs a full investigation. If a small brochure site was hit by an automated attack through a plugin that was years out of date, the likely cause is obvious and a careful cleanup with updates may be enough. We will say so rather than sell you a report you do not need.
An investigation earns its keep when the stakes or the uncertainty are higher. A store or booking site that holds customer details. A site that has been reinfected despite earlier cleanups. A dispute between the host, a former developer and the owner about who was responsible. Or a situation where someone, inside or outside the business, needs a written account they can rely on.
What to do before the investigation starts
- Ask your host, in writing, to preserve or export the access logs, error logs and any FTP logs for the account. Ask how far back they go.
- Leave suspicious files where they are. If the damage must be stopped now, a maintenance page or an access restriction set by the host does that without destroying anything.
- Note when and how the problem was first spotted, and by whom.
- List every person and company that had access to the site and hosting over the past few months.
- Gather any emails from the host, Google or customers about the incident.
If you are curious about the usual routes attackers take, our plain-language overview of how websites get hacked is useful background before you read the report.
Starting an investigation
Tell us what happened, when it was noticed, and what has already been done to the site. If time matters because logs may be rotating away, open your WhatsApp message to us with the single word HACKED, so the request is marked urgent. We secure a backup and the evidence before touching anything, tell you honestly what the logs are likely to show and when we can start, and update you on WhatsApp as the timeline takes shape.