The first anyone knew of it was an email, on a Sunday morning, from an uptime monitor that had been set up years earlier and forgotten about. Site down.
It was not exactly down. The store owner opened his website and found a page he had never seen, in a language he did not recognise, where his shop used to be. He tried to log in to fix it. The admin login was gone. Not rejecting his password. Gone, as if the door had been bricked over.
By the time he reached me, he had already burned half a day finding out who to ask. The hosting company's support chat turned out to be a bot. The developer who built the site years ago was in another timezone, asleep. The one person in his office who is good with computers set up the printers once, and this was never his job. Nobody was a villain. And still, hours passed before a competent person had even looked at the problem.
What saved the morning is a distinction most owners never have a reason to learn. The attackers had taken the WordPress login, the door everyone thinks of as the website. But the hosting account underneath it was still his. Once he fought his way back into that, he could hand me a key the attackers never touched: SFTP, a side door straight to the files WordPress is built from. I went in that way, and spent the rest of that day finding out what had been living in there.
Here is the thing to hold onto while you read the rest. This store was not naked. Somebody, long ago, had set it up properly: an uptime monitor, a paid security plugin, activity logs quietly keeping their records. Every one of those tools was still running, and every one of them did its job this week. What the store did not have, for years, was a single human being on the other end of any of them.
The tools had outlasted the people. This article is about what that actually costs.
Maintenance would not have stopped this
Let me kill the thing my own industry sells, before I ask you to buy anything.
Maintenance does not make a website unhackable. Anybody who tells you a monthly plan prevents breaches is selling you a feeling. Software has holes in it. Some are found by people who report them, some by people who use them, and occasionally you are unlucky about which came first.
What maintenance changes is the size of the hole and the length of the silence. How old the software is when the hole is found. Whether an alarm reaches a human, rather than a dashboard or a dead inbox. How many hours pass before someone competent is looking. Whether, afterwards, you can say what happened, or only guess.
This store is the proof that the tools alone do not do it. It had the tools. What it had not had, for years, was anyone watching them.
That is a much smaller promise than "we will keep you safe." It is also the only one worth making, and this story is what it looks like when the difference shows up.
A known hole, and an alarm in an empty room
The way in was a plugin. A popular commercial one, running a version several years old, with four publicly documented security holes in it. The worst of them let a stranger read files off the server and, with a little work, run code on it.
Every one of those holes had already been fixed by the plugin's makers. The patches existed. The site was simply running an old copy.
Here is the part that should bother you more. The site had a security plugin, and its scanner did its job properly. It found the vulnerable plugin and flagged it, every hour, for fifty-two days before the first intruder account appeared. Nobody saw a single alert, because email notifications had never been switched on. The warning went into a dashboard nobody had a reason to open, and sat there, being right, being ignored, for nearly two months.
No zero-day. Nobody targeting this business specifically. A known hole with a published fix, and an alarm ringing in an empty room since June.
Nine days inside
They came in on a Saturday in the middle of August and stayed until the following Sunday.
In that time they created five administrator accounts, through a request that should not have been able to create anything, on a WooCommerce store where public registration was switched off. They logged in from eleven addresses across four continents, never twice from the same one for long. One of the accounts logged in three seconds after it was created, and within another sixteen seconds had uploaded a plugin, installed it, and deleted the file behind it. Nobody types that fast. The hands on this were scripts.
They uploaded a web-based file manager. They installed a remote-control backdoor that took signed commands from outside. They planted a fake plugin dressed up with a readme and a licence file so it would look ordinary in the plugin list, and two real, legitimate admin tools, because legitimate tools are easier to explain away than malware.
Then two things that made me sit back.
The whole time, a defacement page had been sitting on the server under a spare filename, loaded and waiting. On the final morning they flipped it: the store's real front page was swapped out for it, which is what put a stranger's page where the shop used to be, and is almost certainly what finally tripped the uptime monitor. More than a week of careful quiet, ended by choice. Breaking the site was not a mistake they made. It was the last item on their list.
And at some point in those nine days, they had verified ownership of the domain in their own Google Search Console. That is the one that turns an incident into a business problem. Search Console is where you tell Google what your website is. With ownership accepted and the defacement staged, they were one step from turning a working store into a spam property, with Google primed to believe the paperwork. The only reason it did not happen is that they had not got round to it yet. It never fired, and that ownership has since been cleared out. But it was sitting there, filed and accepted, when I found it.
Nothing they did required extraordinary skill. It required time, and nobody interrupting.
The hack was just the loud part
I mapped the nine days and thought I was finished. Then I read through the old blog posts, and the day got worse.
There were spam links buried inside articles. Pharmacy links, casino links, jammed mid-sentence into posts that had nothing to do with any of it. One sat in the middle of a sentence describing a product: the sentence had been broken open, a link to a page selling valium pushed into the gap, and the sentence carried on afterwards as if nothing had happened. Fourteen of those, across thirteen articles, dated 2021 to 2023.
This store had been compromised, in some form, years before the break-in I was looking at. Somebody had been quietly renting out its reputation to sell pills, and nobody noticed, because nothing looked broken.
The customer list told the same story from another angle. Five hundred and thirty-nine accounts registered in one year alone, not one of which ever placed an order. Bots, piling up in the background until 731 junk accounts sat in that store, and not one person ever had a reason to look.
So those nine days in August were not the breach. It was the first time the breach got loud enough to notice. That is the real lesson, and it has almost nothing to do with security software. A website nobody looks at will tell you it is fine right up until the day it cannot.
Logs are the whole difference
I can name the exact plugin that let them in, the exact web address used to create the accounts, all five account names, the eleven addresses, what each one uploaded, and the second they deleted the evidence behind them.
I know all of that for one boring reason. The logs existed. An activity log and the security plugin's own record, both with retention reaching back far enough to cover everything, including the warning from fifty-two days before the break-in.
Take the logs away and this becomes a different day. You cannot find the way in, so you cannot be sure you closed it. You cannot prove which accounts were theirs, so you distrust all of them. You wipe everything, restore from a backup, and quietly hope the backup is older than the problem and newer than the last order. Then you spend a year wondering.
Logs cost nothing and do nothing, visibly, on any normal day. On exactly one day they are the difference between knowing and guessing, and you never get to configure them on that day.
The green tick that lied
Here is the part I am least comfortable writing, because it goes against the version where the tools save you.
That security plugin, the good one, the paid one, the one whose scanner had been right since June, had a whole layer that never worked. It writes server-level protection rules: bad bots blocked, bad referrers blocked, every banned address enforced. The dashboard reported those rules as active, in a green box, regenerated successfully.
They had never loaded. Not once since the day it was installed. The plugin was writing them to a file the web server could not see, on the far side of a boundary it could not cross, and its own error blamed a permissions problem, which sent anyone who checked in exactly the wrong direction. Every banned address was a note in a drawer. Every bad bot walked straight past a door reported as locked.
There is a ten-second test for this, and I would rather you ran it than trusted anyone's dashboard, including mine:
curl -I -A "Acunetix" https://yoursite.com/
That pretends to be a well-known vulnerability scanner. On this store's setup, the plugin's server rules are supposed to turn that request away, and the logs frame the whole story: a clean 200 the entire time the dashboard showed green, a 403 only after the repair. If your security tool claims to block bad bots, aim the same test at your own site. A refusal of any kind means something real stood in the way. Your homepage, served politely to a scanner's calling card, means that claim is decoration, whatever the dashboard says.
Green ticks are not evidence. Testing is evidence.
What watching actually means
So here is the honest description of the thing I sell, with the marketing taken out.
It is not updating everything the moment an update appears; updating blindly breaks stores, and a broken checkout on a Friday costs more than most vulnerabilities ever will. It is knowing which updates are urgent because someone is actively using the hole, and which can wait for a quiet Tuesday and a backup.
It is alerts that reach a human. Not a dashboard that would have told you if you had opened it. Everything in this story was preventable at that one step.
It is looking at boring things. Nobody was breaking into that store in 2022. Somebody was quietly using it, and a monthly glance at the content and the user list would have caught it in an afternoon.
And it is being the first phone call. The owner in this story lost half a day because that line in his life was blank. When we look after a site, we are the number, the access already exists, and nothing starts with proving who anyone is. That is what turns four to six hours of panic into a few minutes of work. Not brilliance. Someone whose job it is to pick up.
An afternoon of WordPress checks
You do not need a WordPress maintenance company to act on any of this.
Find out which of your plugins are out of date, and which of those have known holes rather than just new features. Turn on email alerts in whatever security plugin you already run, pointed somewhere a human reads. Check that logging is on and reaches back further than a week. Open your user list and count how many accounts have ever bought anything. Read one old blog post slowly, and see whether every link in it is one you put there. Then run that curl command and see whether the protection you think you have is switched on.
And write down, somewhere you will find it at three in the morning, exactly who you ring when the login stops working. If that line is blank, that is the real gap. Everything in this article was downstream of a blank line.