A 7 KB File That Shouldn't Have Been There

In April 2026, the WordPress Plugin Review Team closed wp-advanced-math-captcha and deleted a single file: wp-math-captcha.dat. That file was a 7 KB compressed binary—unusual for a captcha plugin. Decoding it with one line of Python revealed PHP:

python3 -c "import zlib; print(zlib.decompress(open('wp-math-captcha.dat','rb').read()).decode())"

The output was a dropper that installed a 482-line backdoor (siteguarding_tools.php) into the WordPress root, posted the site URL to apitest.siteguarding.com, then self-deleted. The plugin had 6,000 active installs.

The Dropper's Confession

The dropper's comment block read:

/**
* SiteGuarding tools installer for customer's panel
* https://www.siteguarding.com
* Do not distribute or share.
*
* ver.: 1.7
* Date: 20 Mar 2020
*/

This tied the captcha plugin to a company called SiteGuarding. But the plugin was submitted by an anonymous account @lulub5592, not SiteGuarding.

The Sibling Plugin

Inside the same captcha plugin, a file includes/advert-test-codes.php hardcoded a target: image-optimizer-x. That plugin, published by @dalielsam, was clean until December 16, 2025, when it added CMSPlughubAPI_LicenseValidator.php (981 lines). That file contained two hardcoded RSA private keys and a file-downloader pointed at api.cmsplughub.com. RSA private keys in a free plugin made no sense for licensing—they enable authenticated two-way control.

The DNS Pivot

Instead of deobfuscating 981 lines, a simple dig resolved the case:

dig NS cmsplughub.com

Both cmsplughub.com and siteguarding.com used the same nameservers (ns1.siteguarding.com, ns2.siteguarding.com) and resolved to the same IP (198.7.59.167), with reverse DNS server2.siteguarding.com. The domain was registered on 2025-02-11, but it was SiteGuarding's infrastructure. Three accounts (@siteguarding since 2013, @lulub5592, @dalielsam) were now linked.

The Back Catalog

Querying the Beacon database for @siteguarding returned 27 plugins published between 2013 and 2020, all closed by wp.org between May 4 and June 5, 2020. Fifteen of them shipped the identical siteguarding_tools.php backdoor inline (MD5 3eddf6d18214d0d612809efd585a2471). Another 12 phoned home to siteguarding.com without an inline backdoor, including wp-antivirus-site-protection with 4,000+ installs (85% of the portfolio).

Systematic Sweeps Found More

Two systematic sweeps uncovered six more burner plugins:

Sweep A: Plugins force-fixed by wp.org at closure. Three undocumented burners: speedup-optimization, wp-plugin-management, and bytedefense. wp-plugin-management had a remediation release confirming the attack: it installed a remote management tool that connected to siteguarding.com and safetybis.com. speedup-optimization hid the backdoor in classes/tools.gzs and used str_replace("j","") on sjijtjejguarding_tojoljs to resolve the domain. bytedefense disguised its payload as core/scan_sigs_db.dat and used str_replace("v","") on svitevguardvinvgv.

Sweep B: Decoding every non-PHP blob in closed plugins. This found payloads hidden under .dat, .gzs, and .bin extensions. All pointed back to SiteGuarding.

The Full Tally

  • 44 plugins total (27 original + 6 sweep A + 6 sweep B + 2 earlier burners + 3 more found later)
  • 19 WordPress.org accounts
  • One operator
  • 13 years of operation (2013–2026)
  • Backdoor MD5 identical across 15 plugins

Technical Details

  • The dropper used zlib compression; one-liner Python decode
  • RSA private keys embedded for two-way control
  • Domain obfuscation via str_replace on character patterns
  • Payloads hidden under non-PHP extensions (.dat, .gzs, .bin)
  • Force-install primitive: a captcha plugin pushing an image optimizer

Why It Matters

This wasn't a sophisticated zero-day. It was a 13-year campaign using simple tricks: compress a backdoor, rename it to .dat, and hide in plain sight. The operator relied on the fact that most reviewers don't decode random binaries. The DNS lookup was the cheapest pivot—a 30-second dig that connected everything.

What You Should Do

  • If you ever used any of the 44 plugins (see list in source), assume compromise. Check for siteguarding_tools.php in your WordPress root and inspect for outbound connections to siteguarding.com, cmsplughub.com, or safetybis.com.
  • For WordPress site maintainers: scan for binaries in plugin directories that aren't images or archives. Decode them.
  • For security researchers: do the cheap check first. DNS, whois, and reverse IP lookups often tell the story faster than deobfuscation.