Hijacking the WordPress Train
- Javier Conejo del Cerro
- hace 1 día
- 4 Min. de lectura

Threat actors are quietly derailing WordPress security by exploiting a powerful but often overlooked feature: must-use plugins, known as mu-plugins. In a newly observed campaign, attackers are abusing this mechanism to implant stealth backdoors, giving them persistent administrative access and total control of targeted sites. The malicious code hides in plain sight—never appearing in the plugin dashboard, immune to deactivation, and silently executing PHP commands, all while site owners remain unaware.
This latest wave of compromise, uncovered by researchers at Sucuri, shows just how dangerous the misuse of built-in WordPress features can be when weaponized by skilled adversaries. The attack combines filesystem manipulation, database injection, obfuscated network calls, and credential hijacking to maintain a covert presence on victim sites. Once inside, attackers can exfiltrate data, redirect traffic, install more malware, or completely lock out legitimate administrators.
This backdoor is not just a single point of entry—it’s a multi-layered foothold, designed for persistence, evasion, and full control of one of the world’s most popular content management systems.
New train conductors
The targets in this campaign are WordPress site administrators, typically running small-to-medium business sites, media outlets, e-commerce platforms, or service portfolios. These administrators often rely on prebuilt plugins, automated updates, and basic security plugins to manage their sites. However, they rarely inspect deeper areas of the WordPress filesystem like the mu-plugins directory, which is not visible through the standard admin dashboard.
Attackers exploit this blindspot. Once access is gained—usually through a separate initial compromise—they deploy a malicious loader into the wp-content/mu-plugins folder. This backdoor never appears in the visible plugin list, making it an ideal mechanism for long-term persistence. It allows the attacker to create unauthorized admin accounts, change critical passwords, and remotely manipulate the site without leaving obvious traces.
For administrators, the danger is twofold: not only do they lose control over their site, but their platform can also be weaponized to attack visitors, host phishing kits, or serve malware—creating reputational and legal risks that extend far beyond the initial compromise.
Total train control
At the heart of the breach is a small but dangerous file: wp-index.php, placed within the mu-plugins directory. This script is the entry point for a broader infection chain.
Once installed, wp-index.php performs the following operations:
Fetches a remote payload using a ROT13-obfuscated URL, a basic but effective form of ciphering that prevents casual detection by static scans.
Temporarily writes the payload to disk and executes it, initializing a sequence of system alterations.
Injects malicious code into the WordPress database, specifically writing to the wp_options table under the key hdracore.
Installs a hidden file manager (pricing-table-3.php) in the active theme’s directory, enabling the attacker to upload, browse, and delete files remotely.
Creates a new administrative account named officialwp, which is used to maintain persistent access even if other accounts are removed.
Downloads and activates a fake plugin named wp-bot-protect.php, which can serve additional malicious purposes including content injection and redirect logic.
Changes passwords for commonly used administrator usernames, such as admin, root, and wpsupport, to a password of the attacker’s choosing—ensuring exclusive access.
Grants full remote execution of PHP code, enabling the attacker to modify site behavior, deface content, or pivot to additional payloads.
These techniques make the attack exceptionally dangerous: once deployed, the malware embeds itself across multiple layers of the WordPress architecture—filesystem, database, user management, and remote command execution—ensuring resilience and adaptability.
Because mu-plugins are automatically loaded on every request and are not shown in the admin interface, this backdoor is virtually invisible without manual inspection or external monitoring tools.
Let the sheriff board the train
Mitigating this threat requires a deep inspection of WordPress installations, beyond the admin dashboard. Administrators must embrace proactive security measures that include both technical controls and continuous monitoring. Key actions include:
Inspect the wp-content/mu-plugins directory for unauthorized files such as wp-index.php or any files not officially documented or expected.
Examine the WordPress database, particularly the wp_options table, for suspicious entries like hdracore which may be used to store and retrieve injected code.
Delete unauthorized administrator accounts immediately—especially accounts with suspicious names like officialwp.
Rotate passwords for all privileged users, including default admin accounts, and ensure strong, unique credentials are in place.
Enable two-factor authentication (2FA) for all admin users to prevent brute force and credential stuffing attacks.
Keep WordPress core, themes, and plugins updated, removing any unused or outdated components to reduce the attack surface.
Audit the wp-content/themes directory for hidden files such as pricing-table-3.php, which may serve as rogue file managers.
Deploy file integrity monitoring and web application firewalls (WAF) to detect unauthorized file changes, plugin loads, or outbound network calls.
Limit write permissions on plugin and theme directories where possible, reducing the risk of unauthorized uploads.
Regularly review user activity logs, server logs, and access attempts to identify early signs of compromise.
The abuse of WordPress’s mu-plugin infrastructure represents a shift toward stealth-first web compromises. Unlike typical plugin-based infections that rely on visibility and user interaction, this technique leverages WordPress’s own trusted architecture to hide in plain sight. For site owners and defenders, the takeaway is clear: visibility must extend beyond the dashboard, and security strategies must evolve to cover the full lifecycle of WordPress internals.
What makes this attack particularly insidious is its ability to function like a Trojanized operating system kernel—manipulating site behavior from within while presenting a clean, operational surface to both admins and users. This is not just an intrusion; it is an occupation. And until defenders reclaim the filesystem, the database, and the user access layers, the attackers remain in control of the train.
Comentarios