“12 sites — one password. Zero effort from the hacker — zero chance for the owner”
A story that could happen to anyone
Not long ago I cleaned up a mass infection across twelve WordPress sites that lived on a single hosting account. Someone had added pages that never existed. Files with cryptic names appeared out of nowhere. Google started showing online casino and crypto-scheme content under these domains in search results. The sites themselves were barely breathing — up one minute, down the next — and the host was one step away from suspending them entirely.
The work was intense. The result: clean sites and plenty of takeaways worth sharing.
Anatomy of the breach: what we found on the server
When I got access to the server, the picture was… telling. All twelve sites lived on a single shared hosting account, under one system user. One password — and the attacker had access to everything. Like a single key to a twelve-apartment building.
What came next? Pour yourself some tea and get comfortable, because the list of what we found in there is quite something.
Doorway pages — 182 of them
All over WordPress — in wp-admin, wp-includes, wp-content — folders with numeric names had appeared, each containing an index.php file. These are so-called doorway pages: ghost pages that exist only for search engine crawlers. Google indexes them, sees a “trusted” domain, and starts serving spam in its search results. The site owner can go months without knowing their domain is moonlighting for someone else’s casino, damn it!
Web shells — 9+ copies
A web shell is essentially a backdoor into your server: a small PHP script that lets an attacker remotely run any command — read files, upload new ones, delete, modify, anything they want. And we found nine of these backdoors.
Files with names like clasa99.php, astar.php, and proccess_config.php, scattered across different directories. Some were disguised as CSS files (editorm.css.php in /wp-includes/blocks/avatar/). One even used AES encryption — that’s not amateur work anymore, that’s a tool from the arsenal of people who resell access on hacker forums.
Fake plugins
In the plugins directory, folders appeared that mimicked legitimate extensions. Inside were PHP files of 50–60 KB stuffed with obfuscated code — deliberately scrambled so that neither a human nor an antivirus can quickly tell what it does. WordPress sees them as “plugins,” and an admin might never notice one extra line in the list. Like an extra tenant nobody ever invited, quietly living in your apartment and eating from your fridge.
Code injections in themes
In six themes, functions.php had been modified. Someone added code with comments in Indonesian (“Memanggil file backlink”) that used the wp_footer hook to pull in a file called backlink.php — an external-link injection in the site footer. Every page view generated SEO links to the attacker’s clients’ sites, invisible to visitors.
Hidden administrator
Sitting in mu-plugins was a file called jetpack-performance.php — a name that raises no suspicion. Inside, though, was a filter that hid one specific user from the admin panel. The hacker had created an administrator account for themselves and then made it invisible. Even if you open “Users,” you won’t see it. It simply doesn’t exist in your interface. But it’s there. Sitting quietly in your apartment, eating your borscht, sleeping in your bed — and you don’t even suspect it. The nerve? No. It’s a business model.
Infected root files
In each root-directory index.php, someone had embedded code that pulled a payload from an external server. That let the hacker change the sites’ behavior without breaking in again — a casino redirect today, a cryptominer tomorrow, a phishing page the day after. A remote control for your site, except it’s in someone else’s hands.
Rogue accounts
Most of the sites had rogue administrator accounts. And on one site we discovered 232 spam accounts. Two hundred thirty-two. On a single site. Isn’t it getting a little crowded in there, guys? 😄
Who is behind this and why
Judging by the Indonesian comments in the code, the trail leads to Southeast Asia. But don’t picture a movie hacker in a hoodie, sipping coffee at night and grinning menacingly at a monitor. This is an assembly line. A business. A very profitable business.
The breach is mass-scale and automated. Bots scan millions of servers, trying common passwords or credentials from leaked databases. One stolen password — and an automated script infects every site on the account within minutes.
And then comes monetization. Layered like an onion.
Doorway pages are sold in bulk to spam operators: “1,000 doorways on trusted domains — $300.” Backdoors are resold separately — access to a hacked server goes for $5 to $50 apiece on hacker forums. Backlink injections are a separate service for black-hat SEO. And if all else fails, you can always deploy a cryptominer or use the server for DDoS attacks.
One hacked account with twelve sites isn’t an “incident.” It’s an asset that earns money for several different buyers at once.
Why this happened: no geniuses, just negligence
There are no SQL injections or fancy zero-day exploits here. It’s all far more mundane. And that’s exactly what makes this story so painful.
All signs point to a compromised FTP/SSH password. An identical infection pattern on all twelve sites — one automated pass through the file system. Modified WordPress core files — you can’t do that through a plugin vulnerability; it takes direct file access. Files owned by the hosting account’s system user.
How did the password leak? There are a few typical scenarios.
A weak or reused password. If you use the same password for FTP and for some forum registration, sooner or later it will end up in a leaked database.
The FTP client as the weakest link. FileZilla and similar clients store passwords in plain text in XML files on your computer. One info-stealer trojan — and every account you have is compromised.
Phishing. A fake hosting control panel login page that looks identical to the real one — but sends your credentials somewhere else entirely.
And then shared hosting did its part. Twelve sites under one system account. One password = full access to everything. Like a single key to the whole building — the apartments, the basement, and the attic.
And one more thing I can’t leave out: the server was running PHP 7.3–7.4. PHP 7.3 hasn’t received security patches since December 2021, PHP 7.4 since November 2022. That’s years without a single security fix. In 2026, the standard is PHP 8.3+. Three or four years without patches is a gift to every bot scanning the internet.
How I nursed these sites back to health
The cleanup took several hours of intensive work. Several very intense hours. In short, here’s what had to be done:
- Found and removed every malicious file — web shells, fake plugins, doorway pages, backdoors in mu-plugins, infected
index.phpfiles, and backlink injections in themes - Deleted the rogue accounts from every site’s database
- Downgraded suspicious “system” accounts to the Subscriber role
- Regenerated the WordPress secret keys (salts) — this invalidates every active session, including the hacker’s
- Blocked PHP execution in the
uploadsdirectory - Disabled file editing from the admin panel
- Restored the damaged theme files
That was the technical part. But without a change in how you approach security, all of it will have to be done again and again.
Five lessons that cost me a sleepless night
I’ve put together a detailed WordPress security checklist for 2026 — it’s available on my educational portal: WordPress Security Checklist (2026) (in Ukrainian). It covers everything from wp-config.php configuration to server security headers and WAF setup.
But if I had to distill the most important takeaways from this story, here are five.
One password is one point of failure. If ten sites live under a single hosting account, compromising one password means compromising everything. Use SSH keys instead of passwords. If you must use passwords, make them unique, make them strong, and keep them in a password manager. And never — never — store them in FileZilla or any other FTP client.
PHP must be current. As I mentioned above, an outdated PHP version with no security patches is an open invitation for bots. Update to a current version — don’t put it off.
Shared hosting is a shared apartment. Your sites live next door to hundreds of others, and one compromised neighbor can become everyone’s problem. For serious projects, consider a virtual private server (VPS) or a host that isolates sites from one another.
Monitoring is not a luxury. The owner of these sites found out about the breach by accident — when Google was already indexing spam under their domains. With Wordfence or any other file integrity monitoring in place, the breach would have been caught within an hour, not months later.
Backups are not an “I’ll get to it someday.” With clean backups, recovery would have taken minutes instead of hours of manually hunting down and deleting every malicious file one by one.
The bottom line
A breach is never just a technical problem. It’s a problem of priorities.
When a business decides to “save” on security, postpone updates, and use one password for everything, it isn’t saving. It’s taking out a loan. A loan with a very high interest rate — one you’ll pay not in money but in reputation, Google rankings, customer data, and sleepless nights.
Twelve sites. One night. One password.
Don’t be this case study.
If your WordPress site is acting strange, if Google is showing someone else’s content under your domain, or if you just want to make sure everything is fine — get in touch. I’ll run a security audit, find the vulnerabilities, and close them before someone else does. Better to spend an hour on a checkup now than several sleepless nights on cleanup later.
