Malware removal and hardening.
Overview
Most hacked sites were not chosen. Bots sweep enormous numbers of sites looking for one outdated plugin, one reused password, one writable file, and take whichever ones answer. Nobody read your about page first.
That is oddly reassuring, because it means the fix is not cleverness. It is closing the small number of doors that get tried, and then noticing quickly if one opens anyway.
Hardening is the work of doing that across the site and the server it runs on: accounts, updates, file permissions, firewall rules, backups and monitoring. If a site has already been compromised, we clean it, work out how the attacker got in, and close that route so the clean-up is not an annual event.
How sites actually get in trouble
Four routes account for most of what we are called about. Pick one and watch it play out.
Notice that in three of the four, the moment of compromise is silent. The interesting question is almost never how it happened, it is how long it ran before anyone noticed.
What an audit turns up
Here is the audit we run, against a site before and after hardening. Run it, switch to After, and run it again.
$ 3ple-lift audit --target northbridge.example --profile wordpress
Press Run audit to start.
None of that is exotic. There is no clever exploit in the list and no product you have to buy. It is the ordinary list, and the reason sites fail it is that every item belongs to somebody who was busy.
Our checklist: hardening WordPress in an afternoonWhat we lock down
On the site
- Core, plugins and themes updated, and anything unused deleted rather than deactivated
- Administrator accounts reduced to the people who need them, with two-factor enforced
- Dashboard file editing turned off, so a stolen login cannot write code
- Login attempts rate limited, with lockout and an alert
- Version, username and directory disclosure closed off
- Security headers set: transport, content policy, framing, referrer and permissions
On the server
- Supported PHP, and a web server configured to say as little as possible about itself
- File permissions set so the web user cannot rewrite the code it runs
- A firewall in front of the login and admin paths
- Off-site versioned backups, with a restore performed and timed
- File-integrity monitoring, so an unexpected change raises an alert
- TLS certificates renewing automatically, and checked that they actually did
If it has already happened
A clean-up that only removes what it can see buys a few weeks. The work that matters is finding the way in, because until you have, you are cleaning the symptom.
- 01
Contain, do not panic
Hours 0–2Take a full forensic copy before changing anything, because that copy is the only evidence of how this happened. Then reduce the blast radius: rotate the keys and passwords that can be rotated immediately, and take the site offline only if it is actively harming visitors.
A frozen copy, and the bleeding stopped - 02
Find the way in
Day 1Access logs, file modification times and the database are read together. A compromise leaves a timeline, and the first unexplained write is usually within minutes of the entry point.
A root cause, not a guess - 03
Clean and rebuild
Days 1–3Core and plugin files are replaced from official sources rather than edited, because trusting a file you have just cleaned is how sites get reinfected. Anything custom is diffed against version control. Injected database content is removed by hand.
A site that is genuinely clean - 04
Close the door
Days 2–4The route that was used gets closed, and so do the neighbouring ones. Every credential is rotated, including the ones nobody thought were exposed: database, SFTP, API keys, and any account that shared a password with the one that was taken.
The entry point gone, not patched over - 05
Watch, then report
Week 1–2Monitoring goes on before the site goes back to normal, because reinfection tends to arrive quickly if anything was missed. You get a written account of what happened, what was done, and what would have prevented it.
A written root-cause report
Emergency work is scoped on the day. The timings above are what a straightforward WordPress compromise usually takes.
We have done this work. One of those clean-ups is on our clients page, unnamed, because the publisher has not agreed to be named and that is entirely their call.
What happens after
Hardening is a state, not an event. Plugins that were current in March are not current in June, and an account that was appropriate last year belongs to somebody who left.
So the work ends with monitoring rather than a handshake. File integrity is checked on a schedule, uptime is watched, certificate expiry is watched, and the update cycle continues on a care plan if you want it to. The useful measure of all this is not that nothing ever happens. It is that when something does, you hear it from us and not from a customer.
What you get
- A written audit with risks ranked by severity, and what each one would actually cost you
- Updates applied, unused plugins and themes removed rather than switched off
- Least-privilege accounts, with two-factor on anything that can publish or install
- Firewall and rate limiting in front of the login and admin paths
- Security headers set and verified, not just added
- Off-site, versioned backups with a restore that has been performed and timed
- File-integrity monitoring and alerting, so a change nobody made gets noticed
- Malware removal and a root-cause report if the site was already compromised
Questions we get asked
How would I know if we have already been hacked?
Often you would not, which is the uncomfortable part. The common signs are pages in search results you never wrote, redirects that only happen on mobile or only for visitors arriving from Google, email starting to bounce because the domain has been blocklisted, or an unfamiliar administrator account. If you are seeing any of those, treat it as a compromise until it is ruled out.
Can you just clean it and leave the rest?
We can, and we will say clearly that we think it is a poor use of your money. A clean-up without finding the entry point means the same thing happens again, usually within weeks, and the second clean-up costs what the first one did.
Will hardening slow the site down or break things?
Done carelessly, yes. Security headers in particular can break embeds and payment widgets if they are pasted in from a blog post. That is why every change goes on staging first, is tested against the parts of the site that talk to third parties, and is reversible.
Do we need a security plugin?
Usually less than you would think. A lot of what those plugins do is better done at the server or the edge, where it costs nothing per request and cannot be disabled by whatever just got in. We will tell you where a plugin genuinely earns its place rather than selling you a subscription.
Is a plugin update really that urgent?
Once a fix is published, the flaw it fixes is public too, and scanning starts within days. The window between a patch being available and being applied is the window that most compromised sites were taken in. That is the whole argument for updating on a schedule rather than when you remember.
What if the attacker is still in there?
That is precisely why credentials get rotated before the clean-up rather than after, and why monitoring goes on before the site returns to normal. Reinfection within days is the signal that something was missed, and it is the thing we are watching for.