A real-world incident analysis of a compromised WordPress/WooCommerce site discovered in March 2026. This repository contains sanitized malware samples, technical analysis, and detection guidance for educational and defensive security purposes.
This site was hosted on infrastructure managed by Webnestify, powered by the Enhance control panel running on Ubuntu 24.04 LTS with OpenLiteSpeed.
The compromise was discovered when the site owner contacted Webnestify after encountering a locked shell session. The entire incident — from customer report to full forensic analysis, backdoor termination, and webshell identification — was resolved within one hour, while the Webnestify team was simultaneously on a call with the customer reassuring them.
Despite deploying a full arsenal of tools — privilege escalation scanners, reverse shell generators, and automated exploit checkers — the attackers were ultimately script kiddies who couldn't break past the server's isolation. They had root-level ambitions but were stuck in a sandboxed user account with nowhere to go.
This case study demonstrates why proper server management matters — even when a WordPress site gets compromised, a well-managed hosting environment prevents it from becoming a server-wide breach.
A WordPress WooCommerce site on a Webnestify-managed server was found compromised with:
- 12 webshells planted across WordPress core directories + 1 SEO spam page
- 1 gsocket reverse shell binary for persistent remote access
- 1 infected .bashrc with an obfuscated backdoor launcher + shell lock
- Telegram-based C2 for real-time attacker notifications
- Remote code loading via Cloudflare Pages hosted payload
- Timestamp spoofing to hide when files were really planted
| Attribute | Detail |
|---|---|
| Target | WordPress 6.9.4 + WooCommerce on OpenLiteSpeed |
| Hosting | Managed by Webnestify, powered by Enhance |
| OS | Ubuntu 24.04.4 LTS |
| Duration | ~6 days undetected, resolved within 1 hour of report |
| Webshells | 12 files across 5 distinct types + 1 SEO spam page |
| Database | Clean — no injected code in posts, options, or comments |
| Persistence | gsocket binary + .bashrc autostart |
| C2 Channels | Telegram bot, email, remote code eval |
| Privilege Escalation | Attempted but failed (good isolation) |
| Data at Risk | WordPress database, wp-config credentials, customer data |
A single line hidden in .bashrc that looks like a PRNG seeding comment:
{ echo [BASE64]|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng apache2-inits-kernelDecodes to a gsocket reverse shell launcher that disguises itself as systemd-udevd.
All files had their Modify timestamps backdated to blend in. The Birth timestamps revealed the truth: everything was planted within a 3-minute window on March 11, 2026.
Every webshell was named to mimic a legitimate WordPress core file with a subtle typo:
class-IXR-clien.php(missing "t" from "client")wp-liinks-opml.php(double "i" in "links")class-walker-category-checklis.php(missing "t" from "checklist")
Scripts that load wp-load.php, query all admin users, pick one at random, and set an auth cookie — instant admin access without knowing any password.
A 307KB gambling spam page (blog/index.html) planted to abuse the site's domain authority for Indonesian slot machine keywords. Initially easy to overlook because wp core verify-checksums flagged it alongside legitimate Google verification files.
Full database audit found no injected code in wp_options, wp_posts, or wp_comments. No rogue admin accounts were created. The .htaccess and wp-config.php were also clean — the attackers stayed at the filesystem level.
Despite having a full hacking toolkit, the attackers were script kiddies who could not break out of the site container. The entire incident was identified, analyzed, and neutralized within one hour. The Webnestify/Enhance infrastructure held:
- User isolation — each site runs as its own Linux user with strict permissions
- Privilege separation —
/etc/shadowand system configs were unreadable - Patched system — sudo, kernel, and all system packages were up to date
- Container-level isolation — blast radius was limited to a single site; other hosted sites were completely unaffected
- Rapid incident response — the site owner was reassured that no other sites or server-level data were at risk
.
├── README.md
├── samples/
│ ├── webshells/ # All webshell samples (.txt extension)
│ │ ├── INVENTORY.txt # Complete list with metadata
│ │ ├── vir.php.txt # Full webshell toolkit
│ │ ├── po-mo.php.txt # Simple command execution
│ │ ├── wp-liinks-opml.php.txt # Admin bypass
│ │ └── class-IXR-clien.php.txt # Telegram C2 shell
│ ├── backdoor/ # gsocket backdoor documentation
│ └── bashrc/ # Infected .bashrc samples
├── analysis/
│ ├── timeline.md # Minute-by-minute attack timeline
│ ├── webshell-breakdown.md # Technical analysis of each shell type
│ └── indicators-of-compromise.md # IOCs for threat intel
├── detection/
│ └── hunting-commands.md # Commands to find similar compromises
├── prevention/
│ └── hardening.md # What would have prevented this
└── screenshots/
└── webshell-ui.png # The webshell's file manager interface
The single most effective detection command:
wp core verify-checksums --include-rootThis caught all 12 planted files by comparing against official WordPress checksums.
WordPress sites get compromised — that's an unfortunate reality of the internet. Vulnerable plugins, weak passwords, and automated scanners mean it's a matter of when, not if. What matters is what happens next.
In this case, proper server management turned what could have been a full server breach into an isolated incident affecting a single site. The attackers had every tool imaginable and still couldn't move laterally. The entire cleanup took under an hour.
If you're hosting WordPress sites, ask yourself: if one of your sites gets popped today, can the attacker reach the others?
This repository is for educational and defensive security purposes only. All samples have been renamed to .txt to prevent accidental execution. Server identifiers and credentials have been sanitized. Do not use any techniques described here for unauthorized access.
- Incident response and analysis: Webnestify
- Hosting platform: Enhance
MIT - Use freely for education, training, and defensive security.