I get the ticket. I read the client’s report. I connect to the server. And then I see it: a fresh backup restore from three hours ago. Every file replaced. The database rolled back to last Tuesday. The access logs, gone. The error logs, gone. The malicious files that would have told me exactly how the attacker got in, what they planted, and where they’re hiding — gone.
The client’s note says: “I already restored everything from backup. Just clean up whatever’s left.”
There is nothing left. That’s the problem.
This Happens 7 Out of 10 Times
I am not exaggerating. The overwhelming majority of malware cleanup requests I receive arrive after the client has already done one or more of the following:
- Restored the entire site from a backup
- Manually deleted every file their security plugin flagged
- Reinstalled the CMS core over the existing installation
- Dropped and re-imported the database from an old dump
- Ran
rm -rfon the entire document root and re-uploaded a “clean” copy
They think they are helping. They think they are saving time. They think the analyst will arrive, find a tidy server, and confirm everything is fine.
What they have actually done is destroy every piece of evidence that would have made the investigation effective — and in most cases, they have guaranteed the attacker will be back within days.
A Backup Restore Is Not a Cleanup
This is the fundamental misconception. A backup restore replaces files. That is all it does. It does not identify the attack vector. It does not reveal what the attacker modified. It does not tell you whether the backup itself is already compromised. It does not remove persistence mechanisms that live outside the document root. It does not invalidate stolen credentials.
A backup is a time machine, not a disinfectant. If the vulnerability that let the attacker in still exists in the backup — and it almost certainly does, because the backup was taken while the site was running the same vulnerable software — then you have just restored the exact conditions that caused the compromise in the first place.
But you have done something worse than merely failing to fix the problem. You have destroyed the only evidence that could have told you what the problem actually was.
What Gets Destroyed
When an analyst connects to a compromised server, the malicious artifacts are not just “bad files to delete.” They are evidence. Every single one tells a story:
The malware files themselves contain indicators of compromise: C2 server addresses, obfuscation techniques, payload delivery mechanisms. These get hashed and submitted to security vendors to improve detection signatures. When you delete the files before the analyst sees them, those signatures never get written. The next victim of the same malware family gets no protection. You did not just hurt your own investigation — you hurt everyone else’s.
File timestamps (stat output — creation time, modification time, access time) reveal the attack timeline. They show when the attacker first gained access, how long they were active, and the sequence of their actions. A restored backup sets every timestamp to the restore date. The timeline is gone.
Access logs show exactly which endpoints the attacker hit, from which IP addresses, at what times, and with what payloads. They reveal whether it was an automated bot or a manual intrusion. They identify the initial entry point — the vulnerable plugin, the brute-forced login, the exploited API endpoint. Without logs, the analyst is guessing.
Database records — rogue admin accounts, injected content, modified options, application passwords — tell you what the attacker did after they got in. Rolling back the database erases the attacker’s fingerprints. Worse, if the attacker created persistence mechanisms like MySQL triggers or stored procedures, and your backup predates their creation but you only restored tables, those triggers survive the restore. You now have a clean-looking database with invisible self-healing malware still active in the schema.
Server-level persistence — crontabs, SSH authorized keys, running processes, systemd services — lives outside the document root entirely. No backup restore touches these. The attacker’s reverse shell is still phoning home while you are celebrating your “clean” restore.
The Infected Backup Problem
Here is the question no one asks before clicking “Restore”: when was this backup taken?
If the backup was created last week, and the attacker has been inside the server for three weeks, the backup is already compromised. You just restored a copy of the infected site. The malware is different — maybe an earlier stage of the attack, maybe a different payload — but it is there. And because you wiped the current state before comparing, you have no way to know which version of the compromise you are now running.
I have seen this cycle repeat endlessly: client gets hacked, restores from backup, gets hacked again within 48 hours, restores from an older backup, gets hacked again, and finally opens a ticket after the third or fourth cycle. By the time I connect, there are zero original artifacts, zero logs, and three layers of partial restores stacked on top of each other. The server is a forensic graveyard.
The attackers, meanwhile, are not inconvenienced in the slightest. They had a webshell planted two months ago. They had credentials harvested three weeks ago. They have an automated reinfection script running from a remote server that checks every six hours whether its payload is still in place. Your backup restore is a speed bump they clear automatically.
Deleting Flagged Files Is Even Worse
Some clients take a more targeted approach: their security scanner flags 15 files as malicious, so they delete all 15 and call it done. This is arguably worse than a full restore, because it creates a false sense of precision.
Security scanners detect what they have signatures for. They do not detect everything. The files the scanner found are the known threats — the ones that match existing patterns. The dangerous ones are the files the scanner did not flag: the custom backdoor with no matching signature, the legitimate core file with three lines of injection buried in a function, the PHP file disguised with a .ico extension, the database record containing serialized PHP that executes on every page load.
By deleting only the flagged files, you have removed the evidence the analyst needed to trace the attack chain, while leaving the undetected components untouched. You gave the attacker a haircut and called it surgery.
The Signature Problem
This is the part that most clients never consider because it is not about their site. It is about everyone else’s.
Part of a malware analyst’s job is collecting undetected samples — false negatives — and submitting them to security vendors so they can build detection signatures. Every compromised server is a potential source of new intelligence. A novel obfuscation technique, a previously unseen C2 communication pattern, a new persistence mechanism — these are the raw materials that make the next detection update better.
When you delete the malware before the analyst collects samples, those signatures never get written. The malware family continues to evade detection. Other sites running the same software get hit by the same payload, and their security scanner says “clean” because no one ever submitted the sample that would have triggered a detection.
Every deleted sample is a missed signature. Every missed signature is someone else’s future breach.
What You Should Actually Do
If your site is compromised and you are about to request professional cleanup, here is the only correct sequence of actions:
1. Stop. Do not touch anything. Do not delete files. Do not restore from backup. Do not reinstall the CMS. Do not “clean up” what looks suspicious. The compromised state of the server is the evidence. Preserve it.
2. If the site is actively harming visitors (serving malware, redirecting to phishing, cryptocurrency mining), take it offline by disabling the virtual host or putting it behind a maintenance page. Do not delete the files — just stop serving them. There is a difference between stopping the bleeding and burning the patient’s medical records.
3. Contact the analyst and provide access. SSH credentials, hosting panel access, database credentials, and a description of what you observed. The more context you give, the faster the investigation goes. “The site started redirecting to a casino site three days ago” is infinitely more useful than “I restored from backup and it’s still broken.”
4. Let the analyst work first. Investigation, evidence collection, sample submission, root cause identification — all of this happens before a single file is deleted. The cleanup comes after the investigation, not instead of it.
5. Change credentials after cleanup, not before. Changing passwords before the investigation can lock out the analyst or mask which credentials were compromised. Change them after the analyst has documented the attack vector and confirmed the cleanup is complete.
The Hard Truth
If you restored from backup before contacting an analyst, you did not clean your server. You rearranged the furniture in a burning house. The fire is still there — you just cannot see it anymore because you also disconnected the smoke detectors.
The analyst you hired can still help, but the job is now harder, slower, more expensive, and less certain. Instead of reading the attacker’s playbook from the evidence they left behind, the analyst is now working blind — scanning for patterns without context, checking for persistence without a timeline, hunting for backdoors without knowing which door the attacker used to get in.
And the attacker? The attacker does not care about your backup. They have your credentials. They have their automated reinfection pipeline. They have been doing this longer than you have been worrying about it.
Your server is a crime scene. The malware is the evidence. Stop destroying it before the investigator arrives.
