Brevo (Sendinblue) CDN Supply-Chain Attack — ClickFix Lures & the "Web Media Optimizer" WordPress Backdoor

What happened. On 2026-09-14 an attacker used a long-lived Cloudflare API key with full account permissions — hardcoded in Brevo's application source code — to create a malicious Cloudflare Worker that rewrote content at the CDN edge for Brevo's own site and for JavaScript files (sdk-loader.js, the Brevo Conversations widget, and the Brevo forms script) embedded on customer websites. Sansec places the active malware-serving window at roughly 16:05-20:13 UTC; Brevo's own stated exposure window is 16:07-20:30 UTC. All attacker-controlled subdomains stopped resolving on 2026-09-15. Sansec estimates over 100,000 websites were affected because trust was inherited transitively through a simple <script> tag — no individual customer had to be compromised.

The payload had two branches. (1) Every visitor could be shown a fake "Cloudflare, verify you are human" page that used the ClickFix social-engineering technique: copy a command to the clipboard, then walk the victim through Win+R → paste → Enter to execute it via PowerShell or mshta. (2) On WordPress sites embedding an affected Brevo widget, if the visiting browser showed signs of being an authenticated WordPress administrator, the script instead attempted to silently install a plugin called "Web Media Optimizer" from an attacker-controlled CDN subdomain. That plugin behaves as a persistent backdoor: it hides itself from the WordPress admin plugin list, copies itself into the mu-plugins (must-use plugins) directory for persistence outside normal plugin management, carries a hardcoded authentication key that lets the attacker generate valid admin sessions without a password, and periodically polls for updated payload URLs.

Root cause. A long-lived Cloudflare API key with full account permissions was stored in Brevo's application source code and obtained by the attacker, letting them create Cloudflare Workers, routes, and DNS records across Brevo's zones without triggering the alerting a short-lived, narrowly-scoped token would have. Evidence (identical Last-Modified timestamps on rewritten assets, unified Cloudflare-DNS control of five Brevo apex domains) points to CDN-edge content rewriting rather than a breach of Brevo's origin servers — meaning file-integrity checks against the origin would not have caught this.

Relationship to the prior Sept 10 incident. Several sources describe a separate, earlier incident on 2026-09-10 in which attackers exploited a SAML SSO misconfiguration to access 138 Brevo customer accounts (including Trezor) and run phishing campaigns; Brevo's own status-page write-up confirms this SSO incident and its remediation. Whether the two incidents are connected is, per SecurityAffairs, a question Brevo had not answered as of the reporting cycle covered by this pack's sources — treat them as two related but distinct events; this pack's detections target the 2026-09-14 Cloudflare Worker / ClickFix / Web Media Optimizer incident.

Defender priority: This is a third-party script supply-chain exposure, not a bug in your own code. The two actionable planes are: (1) hunt your own endpoints and WordPress estate for the ClickFix execution chain and the Web Media Optimizer plugin using the queries and log hunts below, and (2) reduce the blast radius of the next compromised third-party script with Subresource Integrity (SRI) and a restrictive Content-Security-Policy on any page that embeds Brevo (or any third-party) JavaScript — see §12.

Intel gaps / perishability: Of the atomic host indicators, only cdn10.sendibt1.com / /p/wm.zip / "Web Media Optimizer" are corroborated by two or more independently fetched sources. The four other attacker domains (glegchner.com, corralos.beer, yelahaye.surf, boiseno.club) and the plugin SHA-256 appear in only one saved snapshot (BleepingComputer) — per this pack's two-source rule for prevent/critical, they ship as detect-tier indicators, not blocklist-tier. All attacker infrastructure stopped resolving on 2026-09-15, so these are historical/retrospective hunting indicators, not a live blocking need — see §4 and §10. No published report recovered the actual "Web Media Optimizer" plugin source code, so its full capability set is described narratively by researchers, not independently verified by this pack's authors.

Hunt hypotheses (fidelity-ordered)

Attack chain

Deliberately excluded from this table: the Cloudflare-anycast IPs reported for some *.sendibt1.com records (e.g. in the 104.21.x.x and 188.114.x.x ranges). Those are shared Cloudflare edge addresses used by millions of unrelated sites — blocking or alerting on them produces overwhelming false positives and provides no attribution value once the DNS records themselves are gone. Hunt on the domain names and the plugin artifact, not the shared IP space behind Cloudflare's proxy.

Coverage reality: the highest-fidelity WordPress-side signal (H7 — the admin plugin-upload POST) lives in native web/access logs, not Falcon telemetry, unless the web server itself runs a Falcon sensor with file-write monitoring enabled for PHP/zip writes under wp-content — validate this in your tenant before relying on Q5/Q6 as your only WordPress detection.

The single highest-fidelity WordPress-side signal for this campaign lives in your web server / WAF access logs, not EDR. Run these on every WordPress host that embeds a Brevo forms, Conversations, or SDK-loader snippet.

On the WordPress web/access log

• Plugin upload: search 2026-09-14 (and a few days either side, given the "late August" key-theft window) for a POST to /wp-admin/update.php?action=upload-plugin.
• Plugin activation: a GET to /wp-admin/plugins.php?action=activate shortly after that POST is the confirming second half of the signature (per Sansec's published remediation guidance).
• Hidden-plugin check: list the contents of wp-content/plugins/ and wp-content/mu-plugins/ on disk (SSH/SFTP/hosting file manager) and diff against what the WordPress admin "Plugins" screen shows. Web Media Optimizer is designed to hide from that screen — a plugin present on disk but absent from the admin list is the tell.
• Injected-script check: inspect served HTML/JS for script[src*="file.js"] (a commonly reported default loader filename in this campaign family) or a script tag carrying a data-c attribute — both reported as injection artifacts.
• Script hash check: compute SHA-256 of the embedded sdk-loader.js / brevo-conversations.js as served to visitors and compare against the clean vs. injected hashes in §10's Script Integrity Reference.

On the WordPress admin session / auth log

• Review admin login activity around 2026-09-14 16:00-21:00 UTC for sessions with no corresponding interactive login event — a symptom of the plugin's hardcoded backdoor auth key generating sessions without credentials.
• Force a credential reset and session invalidation for any admin account active on an affected site during the exposure window, out of caution, even without confirmed compromise.

On the endpoint (non-Falcon fallback — AV/EDR-agnostic)

• Check clipboard history / recent Run-dialog (Win+R) MRU entries for base64 or URL-bearing strings on machines whose users browsed an affected site during the window.
• Per Sansec's guidance: anyone who followed the ClickFix instructions and executed the pasted command should run a full anti-virus/EDR scan immediately, not wait for a hunt cycle.

All attacker domains stopped resolving 2026-09-15 — these are retrospective hunts against the 2026-09-14 window and general-purpose detections for the ClickFix/backdoor-plugin technique class going forward, not a live-blocking need.

// HUNT: DNS resolution to Brevo ClickFix / Web Media Optimizer attacker infrastructure
// MITRE: T1071.001 | CONF: high  FP: low  COST: low | REQUIRES: DnsRequest
#event_simpleName=/^DnsRequest$/
| DomainName=/^(glegchner\.com|corralos\.beer|yelahaye\.surf|boiseno\.club|cdn10\.sendibt1\.com|cdn\.sendibt1\.com|cdn2\.sendibt1\.com|cdn3\.sendibt1\.com|cdn4\.sendibt1\.com|cdn9\.sendibt1\.com|cdn11\.sendibt1\.com)$/i
| table([ComputerName, aid, UserName, DomainName], limit=200)

// HUNT: ClickFix clipboard-to-Run-dialog execution chain
// MITRE: T1204.004 / T1059.001 / T1218.005 | CONF: high  FP: medium  COST: low | REQUIRES: ProcessRollup2, SyntheticProcessRollup2
// TUNING: exclude known signed IT helpdesk / RMM tools that legitimately spawn PowerShell from explorer.exe on your fleet
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^explorer\.exe$/i
| FileName=/^(powershell|powershell_ise|mshta|cmd)\.exe$/i
| CommandLine=/(-enc|-e |-en |-w hidden|-windowstyle hidden|frombase64string|iex|invoke-expression|http(s)?:\/\/)/i
| table([ComputerName, aid, UserName, ParentBaseFileName, FileName, CommandLine], limit=200)

// HUNT: Browser process spawning script host / command interpreter
// MITRE: T1204.004 / T1059.001 / T1218.005 | CONF: medium  FP: medium  COST: low | REQUIRES: ProcessRollup2, SyntheticProcessRollup2
// TUNING: exclude signed browser updater/helper binaries and native-messaging hosts observed in your environment
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| ParentBaseFileName=/^(chrome|msedge|firefox|iexplore)\.exe$/i
| FileName=/^(powershell|mshta|cmd|wscript|cscript)\.exe$/i
| table([ComputerName, aid, UserName, ParentBaseFileName, FileName, CommandLine], limit=200)

// HUNT: Script-host download of the Web Media Optimizer plugin archive (wm.zip)
// MITRE: T1105 / T1059.001 | CONF: high  FP: low  COST: low | REQUIRES: ProcessRollup2, SyntheticProcessRollup2
#event_simpleName=/^(ProcessRollup2|SyntheticProcessRollup2)$/
| FileName=/^(powershell|curl|bitsadmin|certutil)\.exe$/i
| CommandLine=/(wm\.zip|sendibt1\.com|cdn10\.sendibt1)/i
| table([ComputerName, aid, UserName, FileName, CommandLine], limit=200)

// HUNT: Web Media Optimizer malicious plugin archive written to disk
// MITRE: T1505.003 | CONF: high  FP: low  COST: low | REQUIRES: ZipFileWritten, PeFileWritten
#event_simpleName=/^(ZipFileWritten|PeFileWritten)$/
| FileName=/^wm\.zip$/i OR SHA256HashData=/^f359ab0d2f732b54dd3300065f4d6553f4df1b67454b71fd81197e26f02af4a8$/i
| table([ComputerName, aid, UserName, FileName, FilePath, SHA256HashData], limit=200)

// HUNT: File write into WordPress mu-plugins directory (Web Media Optimizer persistence)
// MITRE: T1505.003 | CONF: medium  FP: medium  COST: low | REQUIRES: PeFileWritten ⚠ validate in tenant — Linux/PHP file-write coverage varies by sensor config
// TUNING: exclude known-good managed-hosting platform writers and legitimate must-use plugin deployment processes on your fleet
#event_simpleName=/^PeFileWritten$/
| FilePath=/wp-content[\\\/]mu-plugins/i
| table([ComputerName, aid, UserName, FileName, FilePath], limit=200)

The highest-fidelity WordPress-side detection (native H7 — the admin plugin-upload POST) belongs in your web server/WAF log pipeline, not a Falcon IOA — most WordPress hosting never reports to the Falcon sensor.

Playbook A — Windows: block mshta.exe and harden PowerShell against ClickFix (AppLocker + registry)

MITRE: T1204.004 / T1218.005 / T1059.001 → M1038, M1040, M1042  |  Estimated deploy time: 1-2 hours (Immediate tier), 1 pilot ring for Constrained Language Mode  |  Prerequisites: Windows 10/11 or Server 2016+, Group Policy or Intune management, local admin on target endpoints  |  Reboot required: No (AppLocker/registry changes apply on next policy refresh or PowerShell session; no reboot needed)

# Step 1 -- AppLocker deny rule for mshta.exe (GPO path shown; PowerShell equivalent below)
# GPO path: Computer Configuration > Windows Settings > Security Settings >
#           Application Control Policies > AppLocker > Executable Rules
# Add a Deny rule: Path = %SYSTEM32%\mshta.exe, applied to Everyone

# PowerShell equivalent (local testing before GPO rollout):
New-AppLockerPolicy -RuleType Path -User Everyone -Action Deny `
  -Path "%SYSTEM32%\mshta.exe" -XMLPolicy | Set-AppLockerPolicy -Merge

# Verify:
Get-AppLockerPolicy -Effective -Xml | Select-String "mshta"

# Rollback:
# Remove the Deny rule from the linked GPO (or the local policy) and run:
gpupdate /force
# No reboot required; AppLocker re-evaluates on next process launch after policy refresh.

# Step 2 -- Enable PowerShell Script Block Logging (visibility even if execution isn't blocked)
$path = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging'
New-Item -Path $path -Force | Out-Null
New-ItemProperty -Path $path -Name 'EnableScriptBlockLogging' -Value 1 -PropertyType DWORD -Force | Out-Null
Write-Output "PowerShell Script Block Logging enabled."

# Verify:
(Get-ItemProperty $path -Name EnableScriptBlockLogging -EA SilentlyContinue).EnableScriptBlockLogging
# Expect: 1

# Rollback:
Remove-ItemProperty -Path $path -Name 'EnableScriptBlockLogging' -EA SilentlyContinue
# No reboot required; takes effect for new PowerShell sessions.

Compatibility note: pilot the mshta.exe deny rule on a small ring first — a small number of legacy line-of-business HTA-based tools may depend on it. Search Event ID 8004 (AppLocker) for blocked launches during pilot.

Playbook B — WordPress: lock down plugin installation and monitor mu-plugins (shell / WP-CLI)

MITRE: T1505.003 → M1022, M1032, M1047  |  Estimated deploy time: 2-4 hours  |  Prerequisites: SSH/SFTP or hosting-panel file access, WP-CLI installed, ability to edit wp-config.php and web-server config  |  Reboot required: No

# Step 1 -- Audit current state: disk vs. admin-panel plugin list
wp plugin list --path=/var/www/html
ls -la /var/www/html/wp-content/plugins/ /var/www/html/wp-content/mu-plugins/
# Any plugin present on disk but NOT in the `wp plugin list` output is a hiding-plugin candidate -- investigate before proceeding.

# Step 2 -- Disable in-dashboard plugin/theme installation and file editing
# Add to wp-config.php (before "That's all, stop editing!"):
#   define('DISALLOW_FILE_MODS', true);   // blocks plugin/theme install+update+edit from wp-admin
# NOTE: this also blocks LEGITIMATE plugin updates from the dashboard -- pair with a
# controlled update process (WP-CLI, staging-then-deploy, or a managed host's own pipeline).

# Step 3 -- File-integrity baseline for wp-content
find /var/www/html/wp-content -type f \( -name "*.php" -o -name "*.zip" \) -exec sha256sum {} \; > /var/backups/wp-content-baseline-$(date +%F).sha256

# Step 4 -- Recurring integrity check (cron, e.g. daily)
sha256sum -c /var/backups/wp-content-baseline-$(date +%F).sha256 2>&1 | grep -v ": OK"
# Any FAILED or new/missing file warrants investigation.

# Verify Step 2:
grep DISALLOW_FILE_MODS /var/www/html/wp-config.php
# Expect: define('DISALLOW_FILE_MODS', true);

# Rollback:
# Remove (or set to false) the DISALLOW_FILE_MODS line in wp-config.php to restore
# dashboard-based plugin management. No service restart required.

Playbook C — Any site embedding third-party JavaScript: CSP + SRI containment

MITRE: T1195.002 → best-practice (W3C CSP/SRI specs; no single CIS control covers third-party-script supply chain)  |  Estimated deploy time: 2-6 hours plus a monitoring period for CSP report-only tuning  |  Prerequisites: ability to edit site HTTP response headers or HTML <head>; an inventory of every third-party script domain the site legitimately loads  |  Reboot required: No (web server / CDN config reload only)

# Step 1 -- Ship CSP in Report-Only mode first to avoid breaking legitimate embeds
# HTTP response header (nginx example):
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://sibforms.com https://cdn.brevo.com; connect-src 'self' https://cdn.brevo.com; report-uri /csp-violations;" always;

# Step 2 -- After a monitoring period with no unexpected legitimate violations, enforce it:
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://sibforms.com https://cdn.brevo.com; connect-src 'self' https://cdn.brevo.com;" always;
# Any future attempt by a tampered/injected script to load a NEW attacker domain (e.g. a
# repeat of *.sendibt1.com-style abuse or the four ClickFix domains in this pack) is blocked
# by the browser itself, even though the script content changed at the CDN edge.

# Step 3 -- Where the vendor serves an immutable/versioned script URL, pin it with SRI:
# <script src="https://cdn.brevo.com/js/sdk-loader.js"
#         integrity="sha256-BASE64_OF_KNOWN_GOOD_HASH"
#         crossorigin="anonymous"></script>
# NOTE: SRI requires the vendor to serve a byte-stable script at that URL; if the vendor
# rotates content at that same URL for legitimate reasons, SRI will break the embed --
# validate with the vendor before enforcing.

# Verify:
curl -sI https://your-site.example.com/ | grep -i content-security-policy

# Rollback:
# Remove the add_header line (or revert to Report-Only) and reload the web server:
nginx -t && systemctl reload nginx

Known gaps: the root cause (stolen Cloudflare API key, malicious Worker) and the highest-fidelity WordPress-side signal (admin plugin-upload POST) are both off-sensor for Falcon — recoverable only from Cloudflare account audit logs and web-server access logs respectively. Closing the primary WordPress gap means running §7's native log hunts on every site embedding a Brevo (or other third-party) snippet, not waiting on EDR coverage.

Validation: telemetry-ready and benign-baseline gates (§11) must pass before Q2/Q3/Q6 are promoted from Investigate to Detect.