Updated: 22 October 2026.
A hacked website comes back online. The redirects disappear, the warning is gone, and the owner can log in again. A few days later, the same symptoms return.
It is tempting to assume that somebody missed a malicious file. That is one possibility, but I would also ask whether the attacker ever lost access.
Restoring a site answers an immediate business need. Explaining why it was compromised answers a different question. A recovery process needs room for both.
A clean scan has a limited meaning
A scanner reports what it recognised in the material it examined. It does not establish that every account, scheduled task, database record and server component is trustworthy.
Consider a hypothetical WordPress site with a vulnerable upload feature. Removing the uploaded backdoor helps, but an attacker can upload another copy while the feature remains vulnerable. In a different scenario, the software is patched but a stolen hosting password still works. The same visible symptom can therefore require different corrective actions.
I would keep three possibilities separate: something malicious survived, the original entry point remained open, or another access path was available. Treating all three as “the malware came back” makes the investigation less useful.
Preserve evidence before replacing it
Before extensive cleanup, I would preserve relevant logs, suspicious files, account details and a snapshot where practical. That does not mean leaving a compromised site exposed while collecting everything. Containment and evidence collection need to happen together.
The useful timeline includes when suspicious requests arrived, when files appeared, which accounts changed and when the owner first noticed a problem. File timestamps can help, but I would not treat them as unquestionable evidence. Deployments, restores and an attacker’s changes can all affect them.
A vulnerable plugin found on the server is a lead. It becomes a stronger explanation when the logs and affected files support the same sequence.
Repeat infection can come from persistence, an unclosed entry point or another access path. The investigation should test all three.
flowchart TD A["Malicious activity returns"] --> B["Contain and preserve evidence"] B --> C["Check surviving persistence"] B --> D["Check original entry point"] B --> E["Check other accounts and applications"] C --> F["Correlate timeline and findings"] D --> F E --> F F --> G["Recover from trusted sources and close access"] G --> H["Monitor and document uncertainty"]
Review the access around the website
My investigation would extend beyond the public web directory:
- Which WordPress, hosting, SSH, SFTP and deployment accounts could modify the site?
- Were unfamiliar administrators, API credentials or scheduled tasks added?
- Could another application under the same hosting account write to its files?
- Did a restore bring back the vulnerable component or an existing backdoor?
- Are backups and deployment sources themselves trustworthy?
For recovery, I would favour known-good application packages and a reviewed configuration over trying to make every suspicious file look normal. Custom code needs separate examination because replacing WordPress core does not validate a custom plugin.
Credentials and sessions should be addressed from a trusted environment. Otherwise, a compromised workstation or server can capture the replacements.
Write down what the investigation actually established
A useful incident report distinguishes the observed malicious activity, the likely entry point, the evidence supporting it and the uncertainty that remains.
If logs have expired, I would say that the entry point could not be confirmed. I would still document the weaknesses corrected and the monitoring put in place. That is more useful than turning a plausible explanation into a certainty.
After recovery, watch for unexpected file changes, new privileged accounts and recurring outbound activity. Agree on an observation period and who will respond to an alert. The site being available again is an operational milestone; maintaining confidence in its recovery requires evidence over time.
