Why didn't the site owners see the malicious plugin?

The plugin removed itself from the WordPress plugin list and did nothing when an administrator was logged in. It only served its payload to anonymous visitors, so the dashboard appeared normal.

Would a security plugin have stopped it?

Not on its own. The attacker used valid credentials, so there was no brute force to block. Unique passwords, two-factor authentication and restricted, regularly rotated FTP credentials are important defenses.

Is deleting the plugin enough?

No. Rotate the credentials that allowed the attacker in first, then check the rest of the website. One backdoor is rarely the only thing worth investigating.

Case Study: Fake WordPress Plugin Wallet Drainer

Anonymized case study. Client names, domains and identifying details are removed. Work carried out in July and August 2026.

In July 2026, three WordPress sites belonging to a small group of professional-services firms on the same managed hosting were found running a malicious plugin. The plugin served a cryptocurrency wallet drainer to visitors.

The attacker had not exploited a plugin vulnerability. Instead, they logged in with valid credentials and uploaded a one-file plugin designed to stay hidden from the people managing the sites.

We preserved the evidence, removed the plugin from all three installations, rotated the credentials and checked the sites again two weeks later. That follow-up also uncovered older suspicious activity on one of the sites, showing why removing the first backdoor is not always enough.

What we found

The first sign was a plugin file located at wp-content/plugins/buddypress/buddypress.php.

BuddyPress is a real, well-known WordPress plugin. However, this folder contained only one file of about 4 KB, while the genuine plugin contains hundreds of files. The attacker had borrowed the name to make the file look harmless in a directory listing.

The file was designed to avoid detection in several ways.

It hid itself from the plugin list. It filtered itself out of the WordPress plugin list, so it did not appear under Plugins in the dashboard.
It behaved differently for administrators. When a logged-in administrator visited the site, the file did nothing.
It targeted anonymous visitors. For everyone else, it injected a JavaScript payload that loaded a cryptocurrency wallet drainer. This type of code prompts visitors to connect a wallet and then attempts to empty it.
It used a public blockchain for instructions. The payload obtained its instructions from a smart contract on a public blockchain rather than a normal server. This made the attacker's command channel harder to take down.

The same file, carrying the same campaign identifier, was planted on the other two sites within about ten minutes.

This was not three unrelated infections. The timing and shared identifier pointed to one campaign affecting several sites.

How the attacker got in

The web server logs showed two successful WordPress logins from unfamiliar data-center IP addresses, a few days apart. There were no failed login attempts beforehand.

That pattern pointed towards stolen credentials rather than someone guessing passwords through repeated login attempts.

The forensic analysis also confirmed that the hosting FTP credentials had been compromised.

Around the same period, the logs recorded more than 30 requests from over 15 different IP addresses probing for common web shell paths, including up.php, wso.php, alfa.php and adminer.php.

None of those files existed on the sites. However, these requests showed that the websites were being targeted and that other suspicious activity needed to be considered during the investigation.

We also checked whether a known plugin vulnerability could explain the intrusion. We compared the installed plugins and their versions against public CVE data for the attack window.

Nothing matched. This supported the explanation that the attacker had gained access through compromised credentials rather than exploiting a known plugin vulnerability.

What we did

We followed a sequence that preserved evidence, removed the malicious file and reduced the chance of the attacker returning.

Preserved the evidence first. Before making changes, we copied the malicious file and its payload, recorded file hashes and timestamps, backed up .htaccess and wp-config.php, and documented the indicators of compromise. The document included file paths, the command channel, the campaign identifier and the evasion techniques.
Removed the malicious plugin. We removed it from all three sites and confirmed that the affected folders were gone.
Rotated the credentials. We changed the FTP credentials and WordPress administrator passwords, then rotated the security keys and salts in wp-config.php. This invalidated existing login sessions, including any session held by the attacker.
Checked for other changes. We reviewed recently modified PHP files and looked for unexpected files in plugin and upload folders.
Verified the cleanup two weeks later. We confirmed that the backdoor path was absent on every site and checked that recently changed files were legitimate. These included theme and plugin updates, firewall logs and analytics cache.

What the follow-up uncovered

The verification pass identified one site that did not look like the others. An oversized file inside another plugin's folder led us to investigate further.

That investigation uncovered much older access on the same site, including an IP allowlist file and a placeholder backdoor dating back years. The malware discovered in July had been added on top of this older access.

The site therefore needed a deeper investigation of its own.

This is an important point when dealing with compromised WordPress installations. The first backdoor you find is not necessarily the only one. An attacker who has gained access may leave several ways to return. Removing one malicious file without checking the rest of the installation can leave the website exposed to reinfection.

What website owners should take away

Protect your credentials. Use unique passwords, enable two-factor authentication for every administrator and prefer SFTP over FTP. Limit accounts to the sites they need to access. Our WordPress hardening checklist covers these measures.
Do not rely only on the WordPress dashboard. Malware can hide itself from administrators, making the site appear clean. Check the files on the server as well. Our guide to finding a backdoor in WordPress explains what to look for.
Rotate credentials before cleaning. Removing malicious files while the attacker still has working credentials leaves a way for them to regain access.
Verify the result later. A follow-up check one or two weeks after cleanup helped uncover older access that the initial removal did not reveal.

When to get help

If your WordPress site behaves normally for administrators but serves suspicious content to visitors, do not assume that the dashboard tells the whole story.

Our WordPress malware removal service follows the same sequence: preserve evidence, identify how the attacker gained access, clean the installation, rotate credentials and verify the result.

Agencies managing several websites can also start with a security audit to investigate exposure across their installations.

Case Study: A Fake Plugin, Stolen Credentials and a Wallet Drainer Across Three Sites