A remediation tool that cleans the hack and writes the client handoff
Updates
- 2026-07-24 — Initial idea, sketched rough approach.
Bulwark tells me a site is compromised and where the payload is. Everything after that is still manual, and it is the same manual work every single time. Quarantine the files. Kill the persistence. Rotate the credentials. Then write the client a message explaining what happened and what they now have to do.
That last part is the one nobody builds, and it is the part that takes longest.
Two halves
The cleanup half acts on what Bulwark found. Quarantine the payloads, remove the rogue admin, strip the injected database rows, clear the malicious cron hooks, rotate the salts.
The handoff half produces a document for the site owner. Which plugins are abandoned or unpatched. Which paid plugins need a licence renewal so they can actually be updated. Which users have admin rights and probably should not. What passwords must change and in what order. What was removed and where it went, in case something breaks next week.
The second half is what makes it worth building. The first half saves me twenty minutes. The second half saves an hour of writing and stops the same site coming back in three months.
Design rules I would not bend
Never delete. Quarantine. Everything suspicious moves to a timestamped directory outside the web root, with a manifest recording original paths and hashes. Automated deletion on a customer site is how you turn an incident into a much worse incident. Anything the tool does must be reversible by hand.
Dry run is the default. The tool prints what it would do and changes nothing until told otherwise. A remediation tool that acts on first run is a remediation tool nobody will let near production.
Order matters, and it is not the obvious order. Kill the persistence mechanism first, then remove the payload, then rotate credentials. Do it the other way around and the backdoor simply recreates the admin account you just deleted and helpfully learns your new password. This is the whole lesson of the reinstall post, encoded as an execution order.
Salt rotation is a feature, not a side effect. Regenerating the salts in
wp-config.php invalidates every session on the site, including the attacker’s.
It also logs out every legitimate user, which is why it needs to be a deliberate
step with a warning rather than something that quietly happens.
The parts I have not worked out
Whether it should be a separate binary or a --fix mode inside Bulwark. Keeping
detection read-only and remediation separate feels safer, and the separation
makes it obvious which tool can change things.
What the handoff report should actually be. Markdown is easiest for me, HTML is better for a client, and a support desk really wants something it can paste into a ticket. Possibly all three from the same data.
How much it should trust Bulwark’s findings versus rescanning independently before it acts. Acting on a stale report is a good way to quarantine something that was already cleaned.
And whether the licence-expiry check on commercial plugins is even possible in a general way, given every vendor does licensing differently. That might have to be a list of known plugins rather than anything clever.