The plugin guarding the site had been off for four and a half months.
Fifty-nine backdoors, a stolen password rather than a flaw in the system, and the question the client cared about most: did any data leave?
A gallery’s website was behaving oddly and the hosting provider wrote that spam was going out from the domain. A very ordinary beginning. The ending was less ordinary: the system held fifty-nine backdoors in two families. Some of them faked their last-modified date, so in an ordinary look through the file manager they passed for original files.
First you work out how they got in
This is the step that usually gets skipped. The site is cleaned, a backup goes up, everyone breathes out — and three weeks later it is back, because the door that was closed was not the one being used.
In this case everyone expected a flaw in some plugin. The logs said otherwise: hundreds of login attempts where the server answered “wrong password” every time. And then a single login that went through on the first try.
That is not brute force. That is a password the attacker already had — leaked, captured, or reused somewhere else that leaked it.
The difference matters, because it changes what needs fixing. A plugin flaw is fixed by updating. A stolen password is not fixed by updating at all: passwords have to change, old accounts have to go, and a second factor has to be switched on — otherwise next time the attacker simply logs in again.
The question that matters most
The client did not ask how many backdoors there were. He asked one thing:
Did our data leak?
There is an answer to that, even though nobody expects one. Backdoors can be read to see what they can actually do and where they would send data. Access logs show whether anyone invoked them at all and what they took away. Here it came out that the scripts were there to send mail and to keep access — not to ship the contents of the database — and there was not a single request in the log that matched data being pulled out.
This is not a technicality. When personal data leaks, GDPR gives you a duty to report it and a deadline that starts running. A documented “nothing left” and an undocumented “probably nothing left” are two entirely different things to a regulator.
Why it got that far
The security plugin everyone had been relying on had been switched off for four and a half months. Nobody turned it off maliciously — it most likely deactivated during an update and nobody noticed, because the site kept working.
And that is the whole point. Protection that cannot tell you it has stopped working is not protection. It is a feeling.
What to take from it
- Check that protection is running, not that it is installed. Anything meant to watch must be able to say it is alive. One weekly summary e-mail is enough.
- Two-factor on the administration. A stolen password is the most common way in, and this is the one measure that stops it on its own.
- Limit the administration to your own addresses where you can. Most small companies log in from one or two networks.
- Backups with history, off the server. An attacker who has been inside for a month will encrypt any backup they can reach.
- After an incident, investigate before you clean. A cleaned server can no longer tell you what happened.
If you are dealing with something similar right now, do not switch the server off unless someone has explicitly told you to — a powered-down machine is harder to examine, and some of the evidence only exists in running memory.
Not sure whether someone is watching your site from the outside instead of you? I will go through it for free — or ask for an audit.