Invasion Investigation · Part 7
These aren’t technical decisions
Everything up to here had a method. Look at this, check that, compare, label.
What follows doesn’t, and the reason people find it so hard is that they keep trying to solve it technically. Which approach is more thorough? Which is more correct? Which would a professional do?
Wrong questions. Almost every decision after a compromise is economic, and the currency isn’t dollars. It’s your hours — the input nobody prices, because it never arrives as an invoice.
A consultant bills for their time and you can see the number. When you do it yourself, the same cost is incurred and simply never shows up anywhere. That’s why owners cheerfully spend three weeks avoiding an eight-hundred-dollar decision, and why “I’ll just clean it myself” is the most expensive sentence in this entire series.
One exception, first, because it’s the only decision here that money shouldn’t decide.
If data belonging to other people may have been exposed, talk to an attorney before you decide anything else on this page. Notification duties vary by state and by data type, and it is the one item in this series where “it costs too much time” is not a reason. Part 8 covers it properly.
Clean it, or rebuild it?
The instinct is to clean, because rebuilding feels like losing. Price both properly and the instinct usually reverses.
Cleaning looks cheap and is open-ended. You don’t know how long it takes because you don’t know what’s there — and if you’re wrong, you pay again. Possibly several times.
Rebuilding looks expensive and is bounded. You can estimate it. It ends on a date.
The question that actually decides it isn’t “how bad is the damage.” It’s “do I know everything they left?” If the honest answer is better than hope, cleaning is a task. If it isn’t, cleaning is an open bet and rebuilding is a fixed price.
There is no partial credit
This is the part that makes cleaning so much riskier than it feels, and it’s worth stating as bluntly as it deserves:
If you don’t get them all, you have done nothing.
Not less. Nothing. One surviving backdoor restores full access. One drop-in that loads on every request puts their code back in the execution path. One scheduled task rebuilds the files you removed. One administrator account you didn’t spot logs straight back in.
Ninety-nine per cent clean is zero per cent clean, and the site is fully compromised again in the time it takes them to notice.
Which exposes the real problem with cleaning: you can never verify completeness. You can verify that you found everything you found. That’s a different claim, and it’s the only one available to you. Their tooling builds a fresh payload per victim, so there’s no signature to match; it hides in directories that don’t appear in file managers; and it leaves spares specifically so that finding some of it feels like finishing.
That asymmetry is what decides the question. Cleaning is a bet on your own thoroughness, settled by an opponent who gets to check your work. Rebuilding from a copy you trust doesn’t require you to have been thorough at all — it just requires the copy to be clean.
If you clean anyway — and often that’s the right call — this is the argument for taking the whole site out of service first and denying PHP execution across everything, rather than removing files one at a time. It’s the only approach that covers what you haven’t found.
The rule
Everything above reduces to one sentence, and it’s worth carrying out of this article even if you forget the rest:
If you can’t get the hackers out, nuke it.
Not as a last resort. Not as an admission of failure. As the correct answer, the moment you stop being able to say with confidence that you’ve found everything.
The signals that you’ve reached it are unambiguous once you know to look for them. You’ve cleaned the same site more than once. Files come back. You keep finding things in places you’d already checked. You can’t produce a list of what they left that you’d stake anything on.
Any one of those means the honest answer to “is it clean?” is “I hope so” — and hope is not a state you can leave a business sitting in while spam accumulates against a domain you can’t rebuild.
Wiping and rebuilding is not the expensive option. It’s the only one with a guaranteed ending.
From the case file. The site in this series was cleaned repeatedly and kept coming back — because the persistence was executing during the cleanup. Must-use plugins and drop-ins load on every request, including every dashboard page used to remove them. Cleanup ran, reported success, and changed nothing.
Cleanup that has to be repeated isn’t telling you that you missed a file. It’s telling you something is running while you work — and every repetition is hours spent buying the same result.
The question underneath it: where does your master copy live?
This is what actually sets the price, and almost nobody asks it.
If your site is built somewhere else and published to the server, the server is a deployment, not the original. Your clean copy is on your own machine, untouched by any of this. Rebuilding means republishing — hours, not weeks — and you may lose a few recent edits.
If your site is edited live in a browser, which is how most WordPress sites work, the server is the master. There is no clean copy anywhere. Your only fallback is a backup, and a backup is only useful if you know it predates the compromise — which Part 6 probably told you is a floor, not a date.
That’s the whole difference, and it’s usually decided years before the hack.
From the case file. Every site in this account was built locally and published up. The server held a compromised copy of something that existed intact on a desktop the intruders never touched. Slightly out of date, entirely clean.
Meanwhile the server itself held more than 45,000 files. Cleaning meant accounting for every one of them; rebuilding meant republishing from a copy that was already trustworthy.
Priced in hours, it wasn’t close — and the reason it wasn’t close had nothing to do with the compromise. It was a decision made about how to build websites, long before any of this.
So the arithmetic is: hours to verify every file on the server against hours to redeploy from a copy you already trust. If you have a genuine master, that comparison usually answers itself. If you don’t, you’re choosing between an unbounded cleanup and a backup you can’t fully vouch for — which is a worse position, and worth fixing before you need it rather than after.
But the site was never the expensive part
Here’s what the file arithmetic doesn’t capture, and it’s the thing that actually costs you.
A local master restores your website. It restores nothing about your standing in Google.
That asset doesn’t live on your computer, or on the server, or in any backup. It lives in somebody else’s index, built out of years of consistent history, and there is no copy of it anywhere that you control.
From the case file. The site itself could be republished from a clean local copy in an afternoon. What couldn’t be republished was twenty years of domain trust — spent on thousands of spam URLs, fabricated review markup validated against the domain, and pages teaching Google that this website served junk.
The files came off in an afternoon. That didn’t.
And this is where the fight-or-leave decision actually gets decided, because it inverts the instinct completely.
Fighting feels like defending your site. But your site is the cheap thing — you can rebuild it from a master in hours. Meanwhile, every week you spend fighting is another week of spam pages being discovered and indexed, more soft 404s, more of the one asset that cannot be rebuilt at any price being spent.
You’re staying up until 4am to protect the inexpensive half, while the expensive half drains in the background.
That’s the real case for leaving early. Not that the fight is unwinnable — though it is — but that you’re guarding the wrong thing.
And rebuilding isn’t the risk people think it is
The objection that stops most owners: won’t starting over destroy what’s left of my search presence?
No — and this is worth understanding properly, because the fear is doing real damage.
Google is entirely accustomed to sites being rebuilt. Redesigns, replatforming, migrations, consolidations, changes of CMS — it happens constantly, at every scale, and the systems are built to process it. A domain with a long clean history that suddenly presents a coherent, well-structured site is a completely ordinary event.
What Google is not built to forgive is a site that keeps publishing spam. That isn’t a change to be processed; it’s an ongoing signal about what your domain is for.
So the two options aren’t safe versus risky. They’re:
Keep fighting — spam continues to be discovered and indexed, soft 404s keep accumulating, and the signal Google receives about your domain gets worse every week.
Rebuild — you present something clean and legible, and the re-evaluation can actually begin.
From the case file. The domain was twenty years old with a long, consistent history. That history doesn’t evaporate because the site behind it was replaced — it’s the reason the recovery had a foundation to work from at all.
The rebuild was never the dangerous choice. Staying in the fight was, because it kept feeding Google the one thing it genuinely holds against you.
Fight, or leave?
The one nobody writes about, because it feels like surrender.
You find their accounts and delete them. They come back. You delete them again. Somewhere in there they notice you, and it stops being cleanup and becomes a contest.
Price the asymmetry honestly. Recreating an administrator account is one database query — instant, free, automated, part of a tool that runs against a list. Removing one is manual and slow. They can watch you work; you can’t see them. Every round costs you an hour and them nothing.
There is no hour at which you win. That’s the part that isn’t obvious from inside it — you’re not approaching a finish line, you’re paying rent.
And you don’t choose the hours. They do.
From the case file. The activity came at roughly 4am, night after night — which is an ordinary afternoon somewhere on the other side of the world, and the middle of the night in Georgia.
So that’s when the owner was up. For weeks. Not because it was a good use of the time, but because being there was the only way to watch it happen and the only way to respond while it was happening.
Price that honestly, because it’s the real number. The fight doesn’t cost you working hours you could have billed — it costs you sleep, on their schedule, indefinitely. There’s no invoice for that either, and it’s the most expensive thing in this entire article.
The observations it produced were genuinely valuable and are scattered through this series. They were also bought at 4am, several weeks running, by someone with a business to run in the mornings.
From the case file. The owner fought them directly for weeks, deleting their administrator accounts as fast as they were created. They kept creating them.
And note what they didn’t do throughout — the site was never defaced, never taken down, never broken. A working site keeps its owner calm and keeps the operation earning. Damage would have cost them the thing they were there for.
What ended it wasn’t winning. It was abandoning the hosting account and rebuilding elsewhere.
Sometimes the correct move is to stop fighting and leave, and every week you delay makes that decision more expensive, because the cost of the fight is already sunk and the rebuild costs the same as it did in week one.
The decision, when it finally came
It wasn’t exhaustion, and there was no single dramatic moment. It was arithmetic.
From the case file. “I knew it was going to be a long way back, and I wouldn’t have enough time to keep fighting for a damaged website and work to get Google’s trust again.”
That’s the whole thing, and it’s worth reading twice, because it’s the clearest statement of the problem anyone in this position has to solve.
There are two jobs competing for the same hours. Fighting the intruder, and rebuilding what the compromise cost you in search. You cannot do both — not properly, not while running a business.
And they aren’t equivalent. One has no finish line and defends the cheap half. The other is the long road back to the thing that can’t be rebuilt any other way.
So leaving isn’t surrender. It’s reallocation — taking the hours out of a fight that couldn’t be won and putting them into recovery that could. The site was gone either way; only one of those two uses of the time produced anything.
The honest counterweight: those weeks produced observations no quiet victim ever gets. If you’re going to fight anyway, take notes while you do — that’s the only thing the fight reliably produces, and we’ll come back to it at the end.
If you keep the site: take it out of service without destroying it
Before either decision, there’s a move that buys you room, and it solves the problem that makes cleanup so maddening.
Drop in a static index.html, and rename index.php.
That’s it. WordPress starts at index.php — rename it and the application never bootstraps. No must-use plugins load. No drop-ins load. No injected code runs, because nothing is there to run it. The static page serves instead.
Nothing is deleted. You’ve renamed one file, and you can put it back in ten seconds.
What this gets you: WordPress no longer loads. Must-use plugins and drop-ins never execute, which is the mechanism that was quietly defeating your cleanups. Every dashboard page you’d been using to remove their code was loading that code first — with index.php renamed, that stops being true.
But this is only half the job, and the other half is the important one
Renaming index.php does not stop their files from running.
A payload doesn’t need WordPress. webindex.php, wp-admin.php, anything in the web root — request it directly and PHP executes it, whether or not index.php exists. And if their rewrite rules point at their own handler rather than at WordPress, the spam keeps being served to crawlers exactly as before, from a site you now believe is switched off.
That’s the trap: the front page looks like a holding page while the compromised pages carry on working. You’ve quietened the part you can see.
So do all three things, not one:
1. Static index.html, and rename index.php. Stops WordPress.
2. Replace .htaccess entirely — don’t edit it. Rename the existing one (you want it as evidence) and drop in a minimal replacement. Their routing lives in that file alongside yours, and commenting out the WordPress block leaves theirs untouched.
3. Deny PHP execution across the whole site in that replacement file. This is the step that actually takes the site out of service, because it’s the only one that covers files you haven’t found yet. Nothing PHP runs — not WordPress, not their handlers, not the payload sitting in an uploads folder you haven’t looked in.
Then verify it, don’t assume it. Request one of the spam URLs from Part 1 with a crawler user agent and confirm you get nothing. If content still comes back, PHP is still executing somewhere and the site is not out of service, whatever the homepage says.
What you’ve bought
The spam stops being served, so the damage to your search presence stops accruing — the half you genuinely can’t rebuild.
Google sees a site under construction, not a broken one. A static holding page is an ordinary state for a website; crawling backs off and nothing alarming is learned about your domain.
And the evidence survives intact, because you renamed rather than deleted — the same principle as defanging a suspicious file instead of removing it.
And when you start on the files: rename them, don’t delete them
Every file you identify as theirs gets renamed, not removed.
ws70.php → ws70.php.20260114071843.txtOriginal name, the date and time you found it, and .txt — an extension nothing will ever execute. The file is inert. It’s also still there, still readable, and still in the folder where you found it, because where a file sits is evidence in its own right.
The reason isn’t sentiment about evidence. It’s that you will be wrong about some of them.
This investigation produced six documented findings that turned out to be the site owner’s own software or his hosting company — a security plugin, provisioning files, a legitimate plugin misjudged by three orders of magnitude, and one of his own countermeasures. Every one of them looked more like an intruder than the intruder did.
Rename something you were wrong about and you rename it back in five seconds. Delete it and you’ve broken your own site and destroyed the thing that would have told you why.
Renaming stops execution exactly as completely as deleting does. It just doesn’t burn the bridge.
Delete later — from the copies you kept — once the site is stable and you’re certain. There is never a moment where deleting during the investigation is the better option.
Now you can work on a site that isn’t fighting back, and decide the next question without a clock running.
If you nuke the server
When a server is heavily compromised — multiple domains, no confident inventory of what’s on it, cleanup that keeps failing — wiping it is the right answer. It’s also the hardest one to actually do, because it feels like destroying your own work rather than theirs.
Do it in an order that leaves you something. There’s a version of this that goes badly, and it’s the one where you wipe first and discover afterwards what you needed.
1. Take a complete server-wide backup before you do anything else — including before you investigate.
Not at the end. At the very beginning, the moment you realise you have a problem. Everything, every domain, above the web root, databases included.
The reason is longer-range than it sounds: months after the new site is running, you will want to go back and look at something. A question will surface that you can’t answer, and the only place the answer exists is the server you no longer have. That archive is the difference between an investigation you can resume and one that ended when the server did.
2. Pull the configuration files from every domain onto your own machine.
Specifically: robots.txt, .htaccess, and sitemap.xml — for each site, not just the one that looks wrong.
These are the files that control how search engines see your site, they’re the hardest to reconstruct from memory, and they carry years of accumulated decisions — redirects from old URLs, rules for sections you’ve forgotten, crawl instructions that are load-bearing.
One warning: harvest them, don’t restore them blindly. These same three files are where the attacker’s rules live. You’re taking copies so you know what yours said, so you can tell your redirects from theirs and rebuild a clean version deliberately. Copying a compromised .htaccess onto a fresh server reinstalls the problem.
3. Screenshot the control panel before it stops existing — DNS, redirects, cron, mail forwarders, database users. None of that is in any file backup, and you’ll be rebuilding it from scratch.
4. Work one domain at a time, and finish each before starting the next.
The temptation on a multi-site account is to sweep everything at once and be done. Resist it, for two reasons.
You lose track. Five sites cleaned in parallel becomes five half-cleaned sites, and you can no longer say with confidence which one you’ve actually finished.
And you throw away a free diagnostic. Clean one domain, verify it, then watch it while you work on the next. If a finished site gets touched again while the others are still dirty, you’ve just learned something important — the vector is at account level, not site level. Shared filesystem, a credential, something above the individual site. Sweeping everything simultaneously destroys that signal entirely.
5. Copy every file to your own machine before you delete it.
Even with the full backup from step 1. That archive is the scene; this is the record of what you personally removed, from which site, on which date.
A folder per domain, dated, on your PC. It takes seconds and it answers a question you will absolutely have in four months’ time — “what exactly did I take off that site, and when?” — which the whole-server archive cannot answer, because it doesn’t distinguish between what was there and what you decided to remove.
It’s also the practical form of the investigator’s log: you’re not just noting what you changed, you’re keeping it.
6. Then, when the server is empty, put a single static index.html up.
This is the detail almost nobody knows, and it’s worth the two minutes.
A domain that returns nothing at all reads as broken or abandoned. A domain serving a simple static page saying the site is being rebuilt reads as under construction — and Google is entirely comfortable with that. It’s a normal state for a website to be in. Crawling backs off, the domain stays alive, and nothing is being learned about you that you’ll have to unlearn later.
Your rebuild then arrives as a site that came back, rather than a domain that died and reappeared.
Do it the way you’d do it now, not the way it was done
Worth saying plainly, because this series is built on one real case: how it was handled and how it would be handled today are different things.
The case behind these articles produced good evidence, a documented timeline and a set of techniques — and also weeks of 4am fighting that produced nothing, a delayed decision to leave, and a full capture taken well after the point where it would have been most useful.
Read the case for the evidence. Don’t read it as a model. The improved version is: back everything up on day one, decide early whether you’re staying or going, and spend the recovered hours on the half that can’t be rebuilt.
What you can do yourself, and what you can’t
The decision is yours and can’t be delegated. Not to us, not to your host, not to whoever does the cleanup. Every technical step in this series has a right answer. This one doesn’t — it has a number, and only you know what your own hours are worth.
You can do the preservation work. Take the full server backup. Harvest robots.txt, .htaccess and sitemap.xml from every domain. Screenshot the control panel. Copy files to your machine before you remove them. None of that needs a specialist, all of it is worth more the earlier it’s done, and every one of those steps is cheaper now than it will ever be again.
What needs someone with access and experience is the part where a wrong move is expensive: replacing .htaccess and denying PHP execution without taking the site down permanently, working out whether a deletion triggered a redistribution, and verifying — with a crawler user agent, against a known spam URL — that the site really has stopped serving what it was serving.
And there’s one decision still ahead of you that isn’t economic at all: who you’re obliged to tell, and when. That’s next.
Back: How to Analyze a Hacked Website
None of these decisions get easier with less information. Knowing what you are actually deciding between — how deep it went, how long it was there, what is still reachable — is what turns a guess into a choice.
Start a Recovery ReviewPaid assessment · scope agreed up front
Next: Who Do You Have to Tell After a Website Hack? → — your host, your customers, the other tenants on the server, and whether reporting it goes anywhere.
Hub: Invasion Investigation Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.