Solid advice. We're seeing this spike in the SOC as well. I'd add checking the wp_options table for active plugins that might not show up in the admin dashboard. Attackers often hide the plugin directory or modify the active_plugins array value directly in the DB to keep it stealthy.

This is why I insist on separating staging and production access. The logic targeting only logged-in admins is clever social engineering—it ensures the payload runs with high privileges.

We've pushed a rule to our WAF to block requests serving the specific JS hashes mentioned in the IOCs, but that's reactive. I'm interested in if anyone has automated hooks to validate plugin file checksums via wp-cli before deploying updates.

Checking my client base now... found two instances with unauthorized wp_users entries matching the timeframe. It's wild how trusted plugins have become such a soft target.

I'm running this quick Python script to compare local plugin files against the WordPress.org SVN repository to verify hashes. It's saved me twice this year already.

The stealth here is alarming. To catch script tampering before the payload triggers, I recommend checking file modification times in your plugin directories. You can hunt for recently altered JavaScript files using this command:

find /path/to/wp-content/plugins -name "*.js" -mtime -7

Automating this via a File Integrity Monitoring (FIM) agent is even better to catch these swaps in real-time.

Solid intel from everyone. To verify actual integrity beyond just timestamps, I recommend checking file hashes against the WordPress.org repository using WP-CLI. This confirms if the payload has actually altered the file content versus just system changes.

wp plugin verify-checksums --all

This command flags any mismatched plugins instantly, saving you from manual diffing during a breach investigation.

Great breakdown. Since the payload ultimately tries to install a new plugin, a solid containment strategy is locking down the filesystem via wp-config.php. Enforcing DISALLOW_FILE_MODS and DISALLOW_FILE_EDIT will prevent the backdoor from successfully completing its installation phase, even if the initial JS trigger executes. Here is the config snippet to add:

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

Great catch on the hash verification, Tanya. Beyond file integrity, I recommend auditing the database directly for the new administrator role. If the backdoor created a user, it might be hidden in plain sight. You can run this SQL to find all users with 'administrator' capabilities:

SELECT u.user_login, u.user_email FROM wp_users u INNER JOIN wp_usermeta m ON u.ID = m.user_id WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%';

Cross-reference these results with your known list. If you see a new one, nuke it immediately and rotate your salts in wp-config.php.