TL;DR
- She reached out because her homepage had been taken over by foreign-language spam text, not because a security tool flagged anything on her end. Malwarebytes catching the malicious redirect came later, once the investigation was already underway.
- The attacker had valid login credentials on her site for a full month before that homepage change ever showed up.
- Fake plugins disguised as tools like Cloudflare and an Elementor extension (on a site that runs Divi, not Elementor) sat in the plugins list looking completely normal.
- Finding the exact username the attacker used to create his hidden admin account is what turned the investigation around, narrowing pages of activity log noise down to one account’s history.
- The attack didn’t end when the malware was removed. Failed login attempts under that same hidden username are still showing up in the activity log more than two weeks later.
- If your site is self-managed, this is the exact gap WordPress Support Services is built to close.
A Month of Silence Before Anyone Noticed
What actually brought my client to me was simpler than a security alert. Her homepage had been replaced with foreign-language spam text, visible to anyone who landed on the site. That’s what she saw, and that’s what made her reach out.
Malwarebytes flagging the site as malicious came afterward, once I was already running my own tools against it during the investigation.
The attacker had been inside her site for a full month before that homepage ever changed.
The earliest evidence we found was a login under her own WordPress account, using her own credentials, a full month before she saw any symptoms. That’s the part that matters most here. This wasn’t a plugin vulnerability. It wasn’t outdated software. Someone got her password, logged in as her, and used that access to build out an infrastructure for weeks without tripping any alarms.
That’s the uncomfortable truth about a compromised credential, meaning a username and password an attacker has obtained and can use to log in as if they were you. It doesn’t look like an attack. It looks like a normal login. Nothing about it screams “hacked” until the attacker starts using that access to do something visible.
The Fake Plugins Were Built to Blend In
Once inside, the attacker didn’t dump obvious malware onto the site. He installed fake plugins disguised as legitimate ones. This is where the deception really showed its teeth.
One file was disguised as a Cloudflare plugin. Another was named to look like an Elementor extension, even though this site runs on Divi, not Elementor, a mismatch that should have been a red flag on its own. A third was labeled as a generic “SEO tool.” Every one of these was designed to sit in the plugins list and look boring. Normal. The kind of thing you’d scroll right past.
Several of these fake plugins weren’t single files, either. They came with their own directories and multiple supporting files, built to look like a legitimate plugin installation rather than one dropped script.
Here’s what those disguised files were actually doing:
- A content injector and redirect tool (disguised as a Cloudflare plugin) that pulled spam content from a remote server and inserted it into the site’s footer, hijacked login redirects for outside visitors, and hid itself from the Plugins screen entirely.
- A remote code execution backdoor, meaning a public-facing entry point that let the attacker run commands on the server directly, with no login required at all.
- Three separate “rogue admin creator” files, each built to quietly add a hidden administrator account to the site and restore that account automatically if it was ever deleted.
- A command-and-control plugin disguised as an Elementor add-on. This was the most serious find. It let the attacker remotely create admin users, install or delete any plugin on the site, and inject or remove content, all through a signed remote channel that didn’t require him to log into WordPress at all.
- A second, independent command-and-control channel, functioning as a backup in case the first one was found and removed.
That last point matters. This wasn’t one piece of malware. It was a layered system with built-in redundancy, designed so that removing one tool wouldn’t shut the attacker out.
Two more files rounded out the toolkit. One was a spam injector that exposed its own remote endpoint, letting the attacker push new spam HTML into the footer any time he wanted, stored in its own database table so it didn’t rely on the plugin files staying in place. The other was uploaded twice, under two different disguised filenames, within the same week, suggesting the attacker was actively testing which version would go unnoticed longer.
Three Hidden Admin Accounts, Rebuilding Themselves
Alongside the fake plugins, the attacker created three hidden administrator accounts. Two of them were programmed to recreate themselves automatically if deleted. Remove the account from the database or the WordPress admin area, and it would come back on its own, because the malware file generating it was still active.
Each account was hidden from the Users screen, from search, and from the REST API, meaning even a site owner who knew to check the admin user list wouldn’t see it sitting there. One of the three was also tied to a file that exposed a separate endpoint leaking WooCommerce payment method and order count data, which is a detail worth sitting with if your site processes payments at all.
That’s a self-restoring account, a hidden user the attacker’s code keeps re-adding until the actual malicious file behind it is found and removed. Deleting the account isn’t enough. You have to find and remove the file creating it, then delete the account again.
This is also why cleanup on a compromised site takes real forensic work, not a quick plugin scan. You’re not just removing bad files. You’re tracing what each file does, what it’s connected to, and confirming nothing regenerates after you walk away.
A Spam Campaign Designed to Go Unnoticed
While the command-and-control tools were running, the attacker also published over 1,300 spam posts promoting gambling and casino sites, written in German and Italian. Then he trashed them using his own account.
This is a Black Hat SEO tactic, meaning a manipulation technique that violates search engine guidelines on purpose, built to borrow ranking authority from an established domain without the owner ever knowing anything happened. Search engines had already indexed the spam pages by the time the attacker trashed them, so the ranking benefit passed through the client’s domain regardless. Moving the posts to trash, instead of leaving them published, meant a site owner glancing at the dashboard wouldn’t see anything unusual sitting in the published list.
The Part That Put Her Students at Risk
Most of what’s described so far affected the site and its search rankings. One tool went further.
A plugin disguised as a performance optimizer displayed a fake loading spinner to visitors, then, for visitors on Windows machines specifically, pulled a malicious script address from a public blockchain and ran it in the visitor’s browser.
This technique is called EtherHiding. Attackers store malicious code references on a blockchain because blockchain data can’t be taken down the way a hacked server can. Even after you clean the site, the reference the attacker planted is still sitting out there on a public ledger, waiting to be called again if the delivery mechanism isn’t fully removed.
Everything else in this report affected search rankings, spam content, and account access. This tool ran code directly in the browsers of her own students.
How the Investigation Actually Moved
None of this was discovered by clicking through the Plugins screen and squinting at names. Two things moved this along without dragging it out.
The first was having the right monitoring already in place. A site with an activity log tracking user creation, file changes, and login attempts gives you a timeline to work from instead of a guessing game.
The second, and the bigger shift, was AI helping locate the exact username the attacker used to create his hidden admin account. Once I had that username, I could filter the activity log down to just that account’s history instead of reading through everything. That one account alone had roughly 80 pages of log entries. Filtering to it is what turned an unmanageable stack of activity into a trackable list of what the attacker actually did, and when.
AI also helped decode what the obfuscated malware files were doing, meaning code deliberately scrambled to make it hard to read. Instead of manually working through each file by hand, AI helped identify what each script did, what it connected to, and whether it would regenerate if deleted.
None of that replaces experience. AI enhanced an experienced webmaster’s role in finding and fixing the source. It didn’t replace it. You still need to know what you’re looking at once the analysis comes back, have the confidence to delete and search directly in the database, and know how to give the AI the right scope to work with in the first place. What could have taken 8 to 10 hours took about half that.
The Attack Didn’t Stop When the Cleanup Did
Cleaning up the malware didn’t end the attacker’s interest in this site.
The hidden admin username the attacker had been using kept showing up in failed login attempts from dozens of different IP addresses, so blocking a single IP was never going to stop anything. That username had no shortage of new addresses to try from.
More than two weeks after the cleanup, the activity log is still recording failed login attempts under that same username. Not once or twice. Hundreds of attempts, some batched dozens at a time, continuing right up through today.
That’s the piece that’s easy to miss once a site looks clean again. The malware is gone. The attacker’s interest in getting back in is not.
What This Site Didn’t Have
This client manages her own WordPress site, and she isn’t on any kind of ongoing support plan.
That’s exactly the situation ongoing WordPress support is built to catch. A managed site gets security monitoring and activity logging running before there’s a problem, not after. It gets someone monitoring the site regularly enough that a month-long infection doesn’t have a month to build out three admin accounts and two separate remote-control channels.
A stolen password is going to happen to somebody. The question is whether anyone is watching for what comes after, including weeks later, when the attacker is still trying to get back in.
Get Your Site Monitored Before It Needs a Rescue
If your WordPress site is self-managed right now, ask yourself honestly whether you’d catch this. Not just the visible symptoms, the redirect, the spam banner. The month of quiet activity before that, and the attempts that keep coming long after everything looks fixed.
Webmaster For Hire’s WordPress Support Services cover hosting, updates, backups, security monitoring, and 24 hour hack repair and restore, starting at $100 a month. If you want someone actually watching your site instead of hoping nothing goes wrong, reach out and let’s talk about what your site needs.
