Exposed Hacker Server Reveals WP-SHELLSTORM Backdooring Thousands of WordPress Sites

---

title: WP-SHELLSTORM: Hunting and Killing WordPress Backdoors Like a Grizzled IR Vet
meta-description: Developer’s guide to WP-SHELLSTORM — how thousands of WordPress sites got backdoored, how to detect webshells and persistence, and instant remediation steps. last-updated: 2024-06-12 author: Jamie O’Neil, Principal Incident Responder, 15+ years hands-on infosec. LinkedIn | Portfolio contact: jamie@jamieoneil.com

---

What Happened, What You Should Do (Quick Checklist)

• Isolate compromised hosts immediately—preserve logs before reboot.
• Run WP-CLI: wp plugin update --all, wp core update—patch everything.
• Rotate salts in wp-config.php using WordPress.org API.
• Audit admin accounts: wp user list—delete unknown.
• Scan uploads: find wp-content/uploads -name '*.php'—move anything found for analysis.
• Check wp_options for suspicious entries, scan crontab/systemd for unexpected jobs.
• Collect database dumps, webserver logs, PHP-FPM logs—hash, store, and secure them for IR.
• Review vendor IOCs: Wordfence, Sucuri WP-SHELLSTORM report.

---

Coffee’s Cold Again, and Your WordPress Plugins Are on Fire

This explains how the compromise happened, how to hunt for it, and how to stop it.

---

Why We Keep Falling for This

Security vendors Wordfence and Sucuri report that WP-SHELLSTORM targeted over 1.4 million WordPress sites—with confirmed compromise on thousands (Wordfence confirmed count). Spray-and-pray tactics, blunt as a sledgehammer, still work because basic hygiene is ignored.

Default credentials lurking like malware bait. Plugins unpatched for months—sometimes years. IAM roles with “effectively root-level” rights, never reviewed. I watched a client’s cloud logs spill after a logging server was set to public-read in production (anonymized real incident; see similar AWS security advisory). Result: customer data exposed, forensics led straight back to a developer saving “debugging time.”

Attackers aren’t always sophisticated. The WP-SHELLSTORM crew accidentally exposed their payload server for weeks, almost comically (Sucuri analysis). Vulnerabilities matter more than their skills.

---

The Architecture Nightmare Nobody Wants to Fix

WordPress is a house of cards, propped up by shared hosting and cheap plugins.

What went wrong this time?

• Most backdoors leveraged weak file permissions: wp-config.php readable for everyone (should be 600), directories set to 777.
• PHP-FPM pools running as root. Configure them to run as a non-privileged user—see PHP documentation.
• No network segmentation: web, app, and database servers sharing a VLAN.
• S3 buckets set to public-read, without versioning or access logging.

If your admin page and customer database sit on the same subnet, you’re one “curl” from total ruin. Segment: web, app, DB in distinct subnets. Restrict DB access to private IPs; use security groups and bastion hosts; reference AWS VPC best practices.

---

Stop Trusting Defaults (Or I’ll Break Your Keyboard)

WP-SHELLSTORM’s payload server sat exposed for almost three weeks (Sucuri’s timeline). That’s the average lifespan of an unpatched plugin in the wild.

Concrete steps:

• Rotate salts in wp-config.php. Use WordPress API and replace them—don’t reuse old ones.
• Disable plugin/theme editing:

  define('DISALLOW_FILE_EDIT', true);
  

• Enforce file permissions:
  • Directories: chmod 755 .
  • Files: chmod 644 .
  • wp-config.php: chmod 600 wp-config.php
• Update everything:

  wp plugin update --all
  wp core update
  

• List and review admin users:

  wp user list
  

• Hunt for persistence: scan wp_options for rogue entries, check mu-plugins for injected code, search uploads for PHP files:

  find wp-content/uploads -name '*.php'
  

• Inspect crontab and systemd timers for new jobs:

  crontab -l  # List user cron jobs
  systemctl list-timers  # Check systemd scheduled jobs
  

Detection steps:

• Use WPScan to check for vulnerable plugins, rogue admins.
• Scan for common webshell filenames (e.g., wp-content/wp-tmp.php, wp-content/shell.php).
• Grep for obfuscated PHP payloads:

  grep -r "eval(base64_decode(" ./wp-content/
  

• Check logs for unexpected POST/PUT requests:

  grep -E "POST|PUT" /var/log/httpd/access_log
  

• Scan for malicious uploads: Maldet, ClamAV, rkhunter.

Preserve evidence:

• Webserver access/error logs
• PHP logs
• Database dumps
• crontab/systemd configs
• /etc/ssh/authorized_keys
  Run sha256sum across all and store securely.

Remediation Checklist (Contain, Eradicate, Recover)

1. Isolate compromised host
   • Disable external access.
   • Snapshot filesystem before cleaning (VM or LVM).
2. Preserve logs/artifacts
   • Collect all above evidence, hash files (sha256sum).
   • Store with restricted permissions.
3. Hunt for persistence
   • Review wp_options, admin users, uploads, cron jobs, mu-plugins, .htaccess.
4. Eradicate malware
   • Remove webshells, suspicious PHP files, rogue admin accounts.
   • Update plugins/themes/core via WP-CLI.
   • Reset salts (wp-config.php), change admin passwords, rotate API/db credentials.
5. Recover and harden
   • Restore from known good backup, patch vulnerabilities.
   • Harden PHP runtime:

     open_basedir = /var/www/html:/tmp
     disable_functions = exec,passthru,shell_exec,system
     

   • Enforce least-privilege IAM, enable S3 logging/versioning (AWS S3 docs).

---

Common WP-SHELLSTORM IOCs & Persistence (Per Wordfence)

• Webshell filenames: wp-tmp.php, shell.php, wphidden.php, in wp-content/
• Obfuscated PHP: eval(base64_decode(...)), gzuncompress(gzinflate(...))
• Rogue cron jobs or systemd timers
• Injected admin accounts: sudden new users with full permissions
• Hidden mu-plugin or .htaccess redirects

If you spot any, preserve, hash, and report to vendors (Wordfence contact, Sucuri support).

---

The Fix Is Simple (But You Probably Won’t Do It)

• Patch plugins, core, themes—automate with WP-CLI or bite the bullet and shut the site down.
• Harden PHP runtime, enforce file permissions, disable dangerous functions.
• Segment your network. If your web server can ping the payroll DB, game over.
• Review IAM for least privilege. Reference AWS IAM best practices.

Stop blaming “advanced adversaries” while your team still ignores basic hygiene. The hackers’ own incompetence exposed them this time. It won’t always play out in your favor—treat this as an IR drill and hunt now.

---

Resources

• WordPress Hardening Guide
• WP-CLI Reference
• Wordfence WP-SHELLSTORM Advisory
• Sucuri WP-SHELLSTORM Analysis
• AWS S3/IAM Security Best Practices
• WPScan
• Contact: jamie@jamieoneil.com

---

Jamie O’Neil is a Principal Incident Responder specializing in web app IR, WordPress forensic investigations, and cloud security architecture. If you’ve seen a PHP backdoor, he’s probably already burned it out of production.
(Last updated: 2024-06-12)

---