How We Cleaned a WordPress Site of 90+ Malware Artifacts in 6 Hours

09/08/20262 min read

Yesterday we received an email from a client. Their website was displaying an Indonesian casino instead of their logistics company page. What followed was 6 hours of intensive work against a well-organized attack system. This is the story of what we discovered, how we cleaned it up, and what we learned from it.

What Happened

One of our client WordPress sites was compromised on July 3, 2026. Attackers broke in through an automated scanner exploiting a publicly known vulnerability (CVE-2026-63030) in an outdated WordPress version. The client had received our reminders about the necessary updates, but they went unanswered. But the most interesting part wasn't the breach itself. The most interesting part is what they did after.

Over the next 66 days, the attackers methodically built out a persistence infrastructure. Multiple independent backdoor channels, sophisticated obfuscation, command and control infrastructure through GitLab and Telegram. Only when everything was ready did they deploy the final payload: the site homepage was replaced with a static clone of the Indonesian RUBY8000 casino brand for SEO manipulation purposes.

Why this matters
If Google had indexed the site while in casino state before we cleaned it up, the client's SEO reputation would have been damaged for months. Google quickly blacklists such sites, and returning to normal rankings requires a long recovery time and manual Google Search Console submissions.

Anatomy of the Attack

When we began forensic analysis, we realized this wasn't a work of amateur script kiddies. The attack had 8 clearly identifiable phases, each designed as a fallback for the previous one:

Phase 1 — Initial Foothold

PHP webshell uploaded through a vulnerable endpoint.

Phase 2 — Privilege Escalation

Created 22 WordPress admin accounts using bulk-generated templates (admin_wp2, wpadmin, root_admin...).

Phase 3 — Persistence Through Plugins

Deployed 4 hidden backdoor plugins: core-helper-f6003adcd7, wp2shell_badba2c3, wp2shell-f38e02fa54f1, WP-Compact, plus a fake WebP optimization plugin wtec-webp with an embedded ALFA_TEAMSHELL shell.

Phase 4 — Auto_prepend_file Backdoor

Directives planted in .htaccess and .user.ini files forced the execution of default.php before every PHP request. Even if all plugins were deleted, the backdoor would continue to work.

Phase 5 — Deeply Hidden index.php

15+ index.php files scattered deep within the WordPress structure (e.g., wp-includes/theme-compat/plugins/, wp-admin/network/pomo/) with goto-based obfuscation and base64 evaluated payloads.

Phase 6 — mu-plugins-old Fallback

Alternative mu-plugins directory with an l10n backdoor. The name was disguised as an old backup copy.

Phase 7 — C&C Communication

Three independent command and control channels: GitLab snippet for dynamic payload downloads, Telegram bot for notifications, and direct HTTP communication with the operator's server.

Phase 8 — Payload Deployment

The site's index.php was replaced with index.html containing a full-featured RUBY8000 casino clone.