Most website owners assume that if their security plugin is running and their host’s scanner reports a clean bill of health, their site is safe. A recent emergency engagement showed us, in detail, why that assumption can quietly fail on WordPress, and what it actually takes to remove a modern compromise for good.
The client was a Southern California design studio, and their WordPress site did not live alone. Like a great many small-business sites, it shared a single hosting account with several other WordPress installations, a common and convenient setup that, as it turned out, is also a liability. Nothing looked obviously wrong from the outside. The site loaded, the dashboard worked, and both the site’s own security plugin and the host’s server-level malware scanner had been running the entire time. The compromise surfaced because of a human catch, not an alert. While working on the account, we noticed a must-use plugin with an odd, unfamiliar name. Must-use plugins load automatically and never appear in the normal WordPress plugins list, so they are easy to overlook, and this one simply looked wrong. That single suspicious file was worth pulling on, and it turned out to be the visible edge of everything below.
What we found
Hidden inside the site was a custom backdoor, hand-built for this specific target and disguised under boring, legitimate-sounding filenames, including one dressed up to look like an ordinary WordPress performance plugin. It was not off-the-shelf malware with a known signature. It was purpose-made, and it was keyed to the site’s own internal WordPress security keys, the secret salts that every WordPress install uses. That detail let it hide in plain sight and, crucially, rebuild itself if disturbed.
It was not a single file, either, and it had spread. By the time we mapped the full account, the kit had planted itself across nearly every WordPress site on that shared hosting account, live sites and staging copies alike. A break-in on one site had quietly become a break-in on almost all of them, because they all lived in the same account and could read and write one another’s files.
Each copy of the backdoor did several jobs at once. One component granted the attacker remote code execution on demand. Another let them log in as a genuine administrator with no password at all, using a key derived from the site’s own security salts. A third hid a rogue administrator account from the WordPress users list, so nobody would spot it in the dashboard. A fourth created hidden FTP accounts at the hosting level, a separate door back in that would survive even a thorough file cleanup. And the cleverest piece watched for its own removal and regenerated the malicious files from an encrypted copy stashed in the site’s database, twice a day, on a schedule. Delete the files and they simply came back.
The most instructive detail came from the host’s own scanner logs. The scanner had actually been doing something. For three straight weeks it had detected and cleaned a batch of decoy files, again and again. What it never caught was the real backdoor sitting one layer beneath. Every time it wiped the decoys, the hidden regeneration routine replanted fresh ones under new names to stay ahead of the signature. From the outside it looked like the scanner was handling things. Underneath, the actual threat had never been touched, on any of the affected sites.
That is the trap. Symptom-level cleaning, whether by an automated scanner or a rushed manual pass, does not remove this kind of compromise. It resets the visible symptoms while the machinery that produces them keeps running.
How we approached it
The core principle of our work is simple to state and much harder to do: find and remove every persistence mechanism, not just the files you can see. A backdoor that can rebuild itself is only truly gone when you have cut off every path it uses to come back.
So we mapped the entire environment before touching anything. We inventoried every WordPress install on the account, traced how the backdoor stored copies of itself, how it triggered its own regeneration, which credentials and keys it depended on, and everywhere it had spread. Only then did we remove everything in a single coordinated pass across all the affected sites at once: the malicious files, the hidden database copies, the scheduled regeneration task, the rogue administrator accounts, and the attacker-created FTP accounts that were the most likely way back in. We rotated the WordPress security salts, which is the step that instantly invalidates a backdoor keyed to those salts, and we rotated database and administrator passwords.
Doing it everywhere at once matters. If you clean one site today and its neighbor tomorrow, the still-infected neighbor can simply reinfect the site you already cleaned. On a shared account, cleanup has to be simultaneous.
Then we verified, because “it looks fine now” is not the same as proof. We ran a seventeen-point audit across the account: a file-integrity check against the official WordPress release to confirm no core files had been altered, a full sweep for known malware patterns and stray code, a database re-scan to confirm the hidden copies were gone, and a review of every administrator account on every site. Everything came back clean.
There was even a bonus. Removing the malicious and orphaned code that had been loading on every page request made the sites measurably faster. The same work that eradicated the intrusion improved performance.
The lessons for site owners
This engagement reinforced a handful of truths that apply well beyond this one account:
- A clean scanner report is not proof of a clean site. Signature-based tools catch known, generic malware. They routinely miss custom, targeted WordPress backdoors, which is exactly the kind used when someone is after a specific business.
- Removing malware files is not the same as removing the threat. If a compromise can regenerate itself from a hidden copy, deleting files just restarts the clock. The fix is finding what rebuilds it.
- Shared hosting spreads risk. When several WordPress sites live in one hosting account, a break-in on one can become a break-in on all of them. Isolating important sites on their own accounts contains the blast radius, and it is one of the highest-value changes you can make.
- Clean every affected site at the same time. On a shared account, a half-finished cleanup is an open invitation to reinfection.
- Rotate your keys and passwords after any compromise. Modern WordPress backdoors often tie themselves to your site’s own secret salts. Rotating those secrets is one of the fastest ways to shut them down.
- The best detection is still a knowledgeable human. This backdoor was invisible to automated tooling and obvious to a trained eye reading the code.
The bottom line
Cleaning a hacked WordPress site is not about deleting the files you can find. It is about understanding how the attacker built persistence, mapping everywhere it spread, and systematically dismantling every layer of it, then proving the result with independent verification. That is the difference between a site that looks clean and a site that is clean.
If you suspect your WordPress site has been compromised, or you simply want an expert set of eyes before you have a bad day, that is exactly the kind of work we do. Reach out to Startec Web Solutions and we will help you find out what is really running on your site.