Site Hardening · Part 4
The site you forgot is the one they want
Shared hosting makes it easy to collect websites. The plan allows unlimited domains, each new one is a folder, and a site you built for a friend, a project that never took off or a business you closed can sit there for years costing nothing.
It isn’t costing nothing. Every site in a hosting account is a door into every other site in it. And the forgotten ones are the doors nobody is watching.
Why one account is one target
On most shared hosting, every site in your account runs as the same user and lives under the same top folder. Separate domains, separate folders — but one owner, as far as the server is concerned.
That means anything that can write to one site can usually write to all of them. A vulnerable plugin on a site you never update, a stray file on a site you forgot, a login scoped to the top folder — any one of them hands over the whole account. Your best-maintained site is only as safe as your worst.
From the case file. The compromise began in September 2024 with twelve small files written into two old static sites in the account — sites with no software on them to exploit. The host’s scanner emptied the files a month later and left a note saying the danger was removed. Nobody asked how they got there. The login that put them there was never changed, and eleven months later it was used again.
The beachhead
When the intruders came back, they didn’t choose the busiest site in the account. They chose the quietest.
From the case file. It was a small static brochure site built in 2022. No WordPress, no plugins, no dashboard — nothing to update, so nothing to warn anyone. They installed a complete copy of WordPress inside it, on a database stored as a single file so nothing new appeared in the hosting control panel, and left the original home page untouched. For five months, anyone who visited saw exactly the site they expected. Behind it, the operation built the pages that would be pushed out across the account’s other domains.
It was chosen because it looked safe. An early version of the investigation reasoned that a static site had nothing to exploit, so the entry must have been elsewhere. That reasoning was backwards. The quiet site was the perfect base precisely because nobody would ever think to check it.
Prune before you protect
The first hardening step for an account like this isn’t a setting. It’s a decision about each site: keep it and watch it, or take it off the server. There is no safe third option of keeping it and ignoring it.
From the case file. The account held around nineteen site folders when the fighting started. Several of them were test domains — bought for a single year to try something out, and nobody’s responsibility once the test was over. Exactly the kind of site an intruder hopes to find. After months of losing ground, the owner changed tactics deliberately: let the lesser sites go, and salvage the ones that mattered. The account came out of it with four domains plus the main business site. Every folder that disappeared was one less place to hide.
Since then, new sites have joined the account — each one built fresh after the rebuild, not carried over, and each one given the same protections from its first day.
For each site in your own account, ask:
- When did anyone last change it — or even look at it?
- Does it have a Search Console property, so Google would tell you if it started publishing pages?
- Is it running software that needs updates, and is anyone applying them?
- Would anyone notice if it went down tomorrow?
For test and experiment sites, the rule is simpler: delete the folder when the test ends, not when the domain lapses. An empty folder nobody remembers is still a place on the server nobody is watching.
If the answers are “years ago,” “no,” “no” and “no,” that site is a liability wearing the costume of an asset. Take it down, keep a copy on your own computer, and let the domain point at a simple holding page elsewhere if you want to keep it.
Shared hosting can still be the right choice
The obvious conclusion is to put every site in its own hosting account. For a business, that is often right. It isn’t the only answer, and it isn’t what happened here.
From the case file. After the compromise, the surviving sites went back into a single shared account — a new one, hardened. What changed wasn’t the kind of hosting. It was how much any one key could reach, and how each site was protected on its own:
- Far fewer sites, each one maintained and watched.
- File transfer over SFTP only, so the account login never crosses the network in plain text.
- Protective configuration pushed down into each site’s own folders instead of relying on one file at the top, which the intruders had been able to rewrite.
- No old project files, backups or build files left in any web folder — Part 5 covers that in full.
Separate accounts limit how far a compromise can spread. A small, maintained, hardened shared account limits how likely it is to start. Choose deliberately, but either way, don’t keep sites you aren’t watching.
Watch every site that stays
Keeping a site means watching it, and watching it doesn’t have to be much. At minimum, every domain in the account gets its own Search Console property and gets looked at — Part 10 of the investigation series explains why that single step would have exposed this operation months earlier.
And when something in one site looks wrong, check the others the same day. In a shared account, the question is never just what happened to this site. It is what else in this account has the same problem.
In a shared account, one compromised site means every site needs checking. A recovery review covers the whole account, not just the site that raised the alarm.
Start a Recovery ReviewPaid assessment · scope agreed up front
Back: Let the Edge Hold the Door: Cloudflare in Front of WordPress
Next: Files That Should Never Live on a Web Server
Hub: Site Hardening Blog Series
ProVAE builds and recovers websites in Douglas, Georgia, serving South Georgia.