WP Beacon
Campaign SiteGuarding 2013–present 10 audits
See also: #25 wp-advanced-math-captcha · #26 image-optimizer-x · #28 wp-antivirus-site-protection · #42 speedup-optimization · #43 wp-plugin-management · #44 bytedefense · #45 cls-lcp-issues-fix · #46 code-quality-control-tool · #48 seo-pack

← All audits

Audit #47 Malicious Closed by wp.org

Magex AI Bot Defender Closed on WP.org · 10 installs · baseline — → head 1.5.8 · suspect committer viktoriasantos · by beacon-scan-skill · closed 1d ago

Actor: SiteGuarding (SafetyBis Ltd.)
Show full summary

A SiteGuarding burner that routes through the safetybis.com C2 — Tier B (undisclosed phone-home / proxy, no in-plugin RCE sink). Surfaced by the closed-plugin blob scan via siteguarding.com + safetybis.com references in includes/class-siteguarding-api.php.

The mechanism. The plugin is a plausible-looking "AI Bot Defender" (bot detection, honeypots, rate-limiting, captcha — 32 PHP files), but its AI features are proxied through a SiteGuarding C2:

  • includes/class-siteguarding-api.php hardcodes https://safetybis.com/api/index.php. register() POSTs the site URL and stores a server-issued api_key in the aibd_siteguarding_api_key option; ai_request() POSTs prompts and returns the C2's JSON; "AI tokens" are purchased at https://www.siteguarding.com/en/buy-service/add-ai-tokens?domain=<host>.
  • create_validation_files() writes ABSPATH/<md5(domain)>.html and WP_CONTENT_DIR/<md5(domain)>.html containing the md5 string — domain-ownership tokens for the C2 handshake (the same validate-the-domain pattern as cls-lcp-issues-fix's webanalyze/verification.txt).

Bounded mechanism (verified by full file-by-file review). A complete read of all 32 PHP files found no code-execution sink: the safetybis.com response is only esc_html-rendered / stored in a reports table / parsed for verdict keywords — never included, eval'd, or written to a .php file. The only files written outside the plugin dir are the .html validation tokens. There is no wp-config.php patching, no remote payload download, no decode/obfuscation chain. Privileged AJAX handlers are nonce + manage_options gated (two inline registration handlers miss an explicit current_user_can — a hardening gap, not exploitable for code execution).

So unlike its siblings cls-lcp-issues-fix (#45) and code-quality-control-tool (#46), magex cannot currently achieve RCE/persistence through this plugin — the operator's leverage stops at the API boundary. The malice is the covert registration + data/AI traffic to a confirmed-malicious SiteGuarding C2 and unsolicited webroot writes, with the operator controlling all API responses.

Why it matters anyway. safetybis.com is a known SiteGuarding C2 (IOC #169/#153). A burner account (empty profile, single plugin, fake-praise pattern) shipping a security plugin that silently registers every install with that C2 is a SiteGuarding fleet member; the operator can change what the API returns at will, and an "AI defender" that funnels site/security telemetry to the operator is a supply-chain liability regardless of the current absence of an execution sink.

🛑
10 installs potentially exposed to compromised code.

Site owners should remediate immediately. Plugin author: see the steps below to clear this label.

If you run magex-ai-bot-defender on your site

Verify your install matches the wp.org canonical version:

wp plugin verify-checksums magex-ai-bot-defender

A patched build isn't yet published for this audit. Check the security advisories index or remove the plugin until one is available.

Or remove the plugin entirely:

wp plugin deactivate magex-ai-bot-defender
wp plugin delete magex-ai-bot-defender

If you're the plugin author

Cleanup steps to clear this label have not yet been documented for this audit. Contact the investigator listed above.

The label clears automatically on the next wp beacon scan-deltas once the cleanup conditions above are met.

Plugins under the same committer's SVN access

viktoriasantos holds push access to 1 plugin totalling 10 active installs.

Magex AI Bot Defender — COMPROMISED — this audit
10

IOCs extracted (3)

Kind Value Confidence
code_pattern aibd_siteguarding_api_key high
filename class-siteguarding-api.php medium
url https://safetybis.com/api/index.php high

Audit #47 — magex-ai-bot-defender

  • Plugin: magex-ai-bot-defender ("Magex AI Bot Defender")
  • Active installs: fewer than 10 (at closure — recovered via Wayback 2026-03-16 snapshot)
  • Event: #3168 closed_blob_scan · high · clean-on-closure / blob-scan hunt 2026-06-15
  • Suspect committer / account: viktoriasantos (empty profile — single plugin, created 2025-11-21)
  • First published: 2025-11-21 (intake) · author commits through 2025-12-15 (v1.6.2)
  • Closed on wordpress.org: 2026-04-07 (empty closed_reason)

Summary

A SiteGuarding burner that routes through the safetybis.com C2 — Tier B (undisclosed phone-home / proxy, no in-plugin RCE sink). Surfaced by the closed-plugin blob scan via siteguarding.com + safetybis.com references in includes/class-siteguarding-api.php.

The mechanism. The plugin is a plausible-looking "AI Bot Defender" (bot detection, honeypots, rate-limiting, captcha — 32 PHP files), but its AI features are proxied through a SiteGuarding C2:

  • includes/class-siteguarding-api.php hardcodes https://safetybis.com/api/index.php. register() POSTs the site URL and stores a server-issued api_key in the aibd_siteguarding_api_key option; ai_request() POSTs prompts and returns the C2's JSON; "AI tokens" are purchased at https://www.siteguarding.com/en/buy-service/add-ai-tokens?domain=<host>.
  • create_validation_files() writes ABSPATH/<md5(domain)>.html and WP_CONTENT_DIR/<md5(domain)>.html containing the md5 string — domain-ownership tokens for the C2 handshake (the same validate-the-domain pattern as cls-lcp-issues-fix's webanalyze/verification.txt).

Bounded mechanism (verified by full file-by-file review). A complete read of all 32 PHP files found no code-execution sink: the safetybis.com response is only esc_html-rendered / stored in a reports table / parsed for verdict keywords — never included, eval'd, or written to a .php file. The only files written outside the plugin dir are the .html validation tokens. There is no wp-config.php patching, no remote payload download, no decode/obfuscation chain. Privileged AJAX handlers are nonce + manage_options gated (two inline registration handlers miss an explicit current_user_can — a hardening gap, not exploitable for code execution).

So unlike its siblings cls-lcp-issues-fix (#45) and code-quality-control-tool (#46), magex cannot currently achieve RCE/persistence through this plugin — the operator's leverage stops at the API boundary. The malice is the covert registration + data/AI traffic to a confirmed-malicious SiteGuarding C2 and unsolicited webroot writes, with the operator controlling all API responses.

Why it matters anyway. safetybis.com is a known SiteGuarding C2 (IOC #169/#153). A burner account (empty profile, single plugin, fake-praise pattern) shipping a security plugin that silently registers every install with that C2 is a SiteGuarding fleet member; the operator can change what the API returns at will, and an "AI defender" that funnels site/security telemetry to the operator is a supply-chain liability regardless of the current absence of an execution sink.

Verdict

malicious

Attribution

SiteGuarding. Burner @viktoriasantos (single plugin, empty profile, created 2025-11-21). Tier-B phone-home to safetybis.com + siteguarding.com token storefront + domain-validation HTML handshake. Same fleet as audits #25/#26/#42–#46.

IOCs to extract

  • kind: url, value: https://safetybis.com/api/index.php, confidence: high
  • kind: code_pattern, value: aibd_siteguarding_api_key, confidence: high
  • kind: filename, value: class-siteguarding-api.php, confidence: medium

Cleanup

If a site ever ran this plugin: (1) delete the plugin; (2) remove any <md5>.html ownership-token files left in WordPress root and wp-content/; (3) delete the aibd_siteguarding_api_key option and aibd_* transients/tables; (4) block outbound to safetybis.com, siteguarding.com. No wp-config.php modification or dropped .php payload was used by this plugin (unlike siblings #45/#46), so persistence cleanup is limited to the above.

Everything in this audit is reproducible from the links cited above: SVN log, RDAP records, GitHub repositories, wp.org forum threads, and any live endpoints. Full WP Beacon scan logs and any associated zip artifacts are available on request from the investigator.