Over 100 hacked WordPress sites redirect visitors to fake Cloudflare/Google CAPTCHA pages using “ClickFix” to execute Lumma, Rhadamanthys, Epsilon Red, and XMRig payloads, researchers say.

A global campaign dubbed ShadowCaptcha is abusing more than 100 compromised WordPress sites to funnel visitors to counterfeit CAPTCHA checks that coerce “ClickFix” actions and launch malware—ranging from info-stealers and ransomware to crypto miners. Researchers link some infrastructure to Help TDS–style redirection and malicious plugins that masquerade as WooCommerce. The Hacker NewsGoDaddy

A large-scale attack wave called ShadowCaptcha is redirecting users from more than 100 hacked WordPress sites to fake Cloudflare or Google CAPTCHA pages that trigger multi-stage malware installs, including Lumma and Rhadamanthys info-stealers, Epsilon Red ransomware, and XMRig coin miners, according to new research published August 26, 2025.

• What’s new: ShadowCaptcha leverages compromised WordPress sites to run malicious JavaScript that sends visitors into a redirection chain ending on phony CAPTCHA pages. From there, victims are prompted to either paste a pre-copied command in Windows Run or save and execute an HTA file—both paths resulting in malware execution. The Hacker News
• Scale: Researchers have observed 100+ infected sites, with concentrations in Australia, Brazil, Italy, Canada, Colombia, and Israel across technology, hospitality, legal/finance, healthcare and real-estate sectors. The Hacker News
• Initial access: How the WordPress sites were breached varies; investigators have medium confidence that attackers abused vulnerable plugins and, in some cases, stolen admin credentials. The Hacker News
• Related ecosystem: The campaign overlaps with traffic distribution systems (TDS) behavior seen in Help TDS, which has used a malicious plugin named “woocommerce_inputs” to redirect traffic and harvest credentials on thousands of sites. GoDaddy

“The campaign blends social engineering, living-off-the-land binaries, and multi-stage payload delivery to gain and maintain a foothold in targeted systems.” — Researchers credited by Israel’s National Digital Agency. The Hacker News

“The compromised ClickFix page copies a malicious command to the clipboard without interaction, relying on users to paste and run it unknowingly.” — Researchers describing the technique. The Hacker News

“Help TDS has evolved into a malware-as-a-service offering, with a malicious WooCommerce-named plugin installed post-compromise via stolen credentials.” — Denis Sinegubko, GoDaddy Security. GoDaddy

“ShadowCaptcha shows how a simple CAPTCHA lure can escalate into data theft, crypto mining, or full ransomware impact—often with mshta/msiexec abuse and vulnerable drivers for stealth and speed.” — El Mostafa Ouchen, cybersecurity author and analyst.

Technical Analysis

Attack chain & lures. Compromised WordPress pages inject JavaScript that redirects to counterfeit Cloudflare/Google CAPTCHA portals. The pages use ClickFix instructions to:

1. open Windows Run and paste an attacker-supplied command (copied via navigator.clipboard.writeText), launching MSI or HTA payloads via msiexec.exe/mshta.exe; or
2. save the page as an HTA and execute locally. The Hacker News

Payloads. Observed families include Lumma and Rhadamanthys (stealers), Epsilon Red (ransomware), and XMRig miners (with configs sometimes fetched from Pastebin). Some runs drop a vulnerable driver (WinRing0x64.sys) to manipulate CPU registers for higher mining yield. The Hacker News

Defense evasion. Pages implement anti-debugger checks to block browser dev tools inspection and use DLL side-loading to execute under trusted processes. The Hacker News

Possible delivery infra. Research into Help TDS documents a malicious “woocommerce_inputs” plugin used by attackers (not from the legitimate WooCommerce project) to redirect traffic, filter by geography, and exfiltrate credentials—capabilities that can dovetail with ShadowCaptcha’s redirection-first model. GoDaddy

MITRE ATT&CK (indicative):

• Drive-by Compromise (T1189) via compromised sites and forced redirects.
• User Execution (T1204) through ClickFix-guided Run/HTA steps.
• Signed Binary Proxy Execution (T1218) using mshta.exe / msiexec.exe.
• Hijack Execution Flow: DLL Side-Loading (T1574.002).
• Valid Accounts (T1078) for stolen WordPress admin credentials.
• Exploitation for Privilege Escalation (T1068) via vulnerable driver abuse.

Impact & Response

Who’s at risk:

• Site visitors—credential theft, data exfiltration, ransomware execution, resource hijacking for mining.
• Site owners—reputation damage, SEO penalties, blacklisting, potential legal exposure for unsafe platforms. The Hacker News

Immediate actions:

• Users: do not paste/run commands from web pages; block HTA where feasible; run EDR; scan for Lumma/Rhadamanthys/Epsilon Red; check for unauthorized drivers.
• Admins: audit WordPress for unknown plugins (e.g., faux WooCommerce names), remove malicious injections, rotate credentials, enforce MFA, and patch core/plugins; review outbound redirects and logs; WAF/EDR rules for mshta/msiexec misuse; disable Pastebin-fetched configs at egress. The Hacker NewsGoDaddy

Potential regulatory angle: Sites handling personal data may face privacy/consumer-protection scrutiny if inadequate security controls facilitated malware delivery to visitors.

Background

The disclosure follows GoDaddy’s deep-dive on Help TDS, active since 2017, which arms affiliates with PHP templates and a malicious plugin to monetize hijacked traffic (tech-support scams, dating/crypto/sweepstakes), including fake CAPTCHA gates to evade automated scans. ShadowCaptcha adopts similar redirection motifs while expanding to stealers/ransomware/miners. GoDaddy

What’s Next

Researchers are continuing to track infrastructure and plugin variants, while urging WordPress operators to harden authentication, prune legacy/vulnerable plugins, and monitor for ClickFix-style clipboard abuse. Expect IOCs and cleanup guidance to roll out via security vendors and national agencies as investigations continue. The Hacker News

Governor’s Technology Office says no evidence of PII exposure as FBI joins probe; DMV, agency websites and phone lines saw disruptions while emergency 911 remained available.

RENO, Nev. — Aug. 25, 2025. Nevada paused in-person services across state agencies on Monday while technicians worked to recover from a “network security incident” first detected early Sunday, according to a memo from the Governor’s Office. Officials said certain websites and phone lines were intermittently unavailable during recovery, but emergency call-taking remained online. Carson Now

What happened

• The state identified a network security incident early Sunday, Aug. 24 and initiated 24/7 recovery and validation of systems. Agencies were instructed to suspend in-person counters Monday “to minimize disruption” while restoration proceeded. Carson Now
• As of Monday afternoon, NV.gov and several agency sites (including the Department of Public Safety) experienced outages or slow response. StateScoopCarson Now
• The FBI’s Las Vegas field office confirmed it is assisting the state’s investigation. KSNVLas Vegas Review-Journal
• No evidence of compromised personally identifiable information (PII) has been found so far, the state said. Carson NowKRNV

Services and public impact

• DMV: Offices were closed Monday; appointments set for that day will be honored as walk-ins over the next two weeks, the agency said. KRNVKSNV
• Public safety lines: Nevada Highway Patrol / State Police dispatch phone lines were down Sunday but were back in service Monday; 911 remained available statewide. Carson NowLas Vegas Review-Journal
• Other agencies: Notices from departments, including Nevada State Parks, cited website disruptions and operational adjustments (e.g., cash-only fees at park entrances). Nevada State Parks

What officials are doing

The Governor’s Technology Office said it is working “continuously with state, local, tribal, and federal partners,” using temporary routing and operational workarounds to maintain public access where feasible, and validating systems before returning them to normal. Residents were warned to be wary of phishing or payment scams purporting to be from state agencies. Carson Now

Technical context (what this likely means, without speculating beyond facts)

Scope and blast radius. The pattern of symptoms—intermittent web/phone outages across multiple agencies, temporary DMV service suspension, and selective restoration of dispatch lines—suggests disruption at shared network and application tiers rather than isolated end systems. That could include identity infrastructure, routing/firewall layers, telephony integration (SIP trunks, call routing), and public-facing web gateways. (This is analysis; officials have not yet attributed a cause.) StateScoopCarson Now

What we don’t know yet. Nevada has not announced whether this was a ransomware intrusion, DDoS, supplier compromise, or an internal misconfiguration. Investigators typically review authentication logs, privileged access activity, VPN/SSO telemetry, firewall and proxy events, and VoIP call-control logs to determine initial access, lateral movement, and exfiltration. The FBI’s involvement indicates the state is preserving evidence and coordinating across jurisdictions. KSNVLas Vegas Review-Journal

Why services come back in phases. Agencies are restoring in waves because modern state IT relies on centralized identity (SSO), shared network segments, and common telecom/web platforms. Best practice is to isolate, rebuild, and validate each dependency (DNS, IdP, MDM/EDR, call routing, web apps) before reopening public counters—hence Monday’s pause in person services. Carson Now

Guidance for residents (from the state + security best practice)

• Use official channels and be patient with intermittent outages; retry later if a site or line times out. Carson Now
• Treat unexpected calls/emails requesting payment or credentials as suspect; the state won’t ask for your password or bank details by phone or email. Carson Now
• For emergencies, call 911; for roadside assistance, use restored NHP dispatch lines or 911 if needed. Carson Now

What to watch next

• Attribution & root cause: whether investigators tie the outage to criminal intrusions (e.g., ransomware or help-desk social engineering seen in other states) or to non-malicious failures. StateScoop+1
• Data-exposure update: officials currently report no PII evidence; that assessment could change after forensics (if indicators of exfiltration emerge). Carson Now
• Restoration cadence: agency-by-agency reopenings and website recoveries, including NV.gov and DPS properties. StateScoopCarson Now

Sources

Governor’s Office memo via Carson Now; updates on services and scam warnings. Carson Now
KRNV/News4 Reno; DMV accommodations, outage timeline. KRNV
KSNV/News3 Las Vegas; FBI assistance confirmation, service pause. KSNV
StateScoop; NV.gov and DPS site impact; weekend-to-Monday outage context. StateScoop
Carson Now update; dispatch lines status Sunday vs. Monday. Carson Now
Nevada State Parks; closure notice and cash-only operations. Nevada State Parks

Secret Blizzard’s embassy campaign shows why device trust beats TLS trust alone—and how to harden firmware, keys, and boot chains

A new expert analysis warns that root-of-trust (RoT) compromises can neutralize MFA and FIDO protections by subverting certificate trust and boot integrity. The campaign—linked to Secret Blizzard—demonstrates that once a system’s trust anchor is controlled, attackers can man-in-the-middle “secure” sessions and persist below the OS. This guide details practical defenses and standards-based controls.

A recent case study shows Russian-backed Secret Blizzard bypassing MFA at foreign embassies by tampering with the root of trust—the very mechanism devices use to decide what (and whom) to trust online. Instead of phishing credentials, attackers inserted a rogue root certificate and intercepted encrypted traffic without warnings, proving that TLS-anchored MFA fails when the device’s trust store is compromised.

What Happened

• Attack essence: Control the victim’s local trust anchor (root CA / trust store) → impersonate sites via MITM → harvest tokens, cookies, and MFA flows without browser alerts.
• Why it matters: FIDO/WebAuthn assume authentic TLS. If TLS validation is subverted, MFA loses its authenticity check.
• Who’s at risk: Any org that relies solely on TLS + MFA without device-bound credentials, firmware integrity, and independent attestation—especially governments, cloud operators, finance, and enterprises with high-risk network locales.

“A root-of-trust compromise undermines all TLS-based protections, including FIDO-based MFA.” — The Hacker News expert analysis summarizing the campaign. The Hacker News

“Platform firmware must be protected, corruption detected, and recovery ensured in the event of compromise.” — NIST SP 800-193 (Platform Firmware Resiliency). NIST Publications

“Treat firmware and trust stores as live attack surfaces. Bind credentials to hardware, enforce measured boot, and continuously attest device state—or assume your MFA can be silently routed.” — El Mostafa Ouchen, cybersecurity author and analyst.

Technical Deep Dive

1) Root-of-Trust Attack Flow

1. Trust Store Tampering: Adversary adds a malicious root CA or manipulates the device PKI.
2. TLS Impersonation (MITM): The attacker issues leaf certs for target domains. The browser accepts them because the rogue root is trusted.
3. Session Interception: Harvest SAML/OIDC tokens, cookies, and challenge/response flows—even with WebAuthn/FIDO—because the browser “thinks” it’s talking to the real site.

2) Why Firmware & Boot Matter

Above the OS, EDRs and browsers can’t see a poisoned trust anchor set during early boot or via privileged management engines. UEFI/firmware persistence was proven feasible by LoJax, the first in-the-wild UEFI rootkit, showing long-lived pre-OS footholds.

3) Controls That Actually Help

• Device-bound, non-exportable keys (TPM/Secure Enclave/Pluton): Keys never leave hardware; sign-in requires the physical device.
• Measured & Verified Boot: Record each boot stage in hardware and verify with policies; quarantine on mismatch. Follow NIST SP 800-193 for protect-detect-recover.
• Independent Root of Trust for Credentials: Co-sign credentials with both the device and the identity cloud, so a tampered local trust store can’t forge identity.
• Mutual Cryptographic Verification: Device ↔️ IdP both attest to each other beyond TLS (e.g., hardware signals + cloud policy).
• Continuous Session Risk Checks: Re-evaluate device posture and revoke access mid-session on trust drift (rogue CA detected, boot log mismatch).

MITRE ATT&CK Mapping (selected)

• Initial Access: Valid Accounts via session hijack (T1078), Exploit Trusted Relationship (T1199).
• Defense Evasion: Modify Authentication Process / Subvert Trust Controls (T1556.004), Subvert Trust Controls (T1553).
• Credential Access: Web session cookie theft (T1539 via MITM).
• Persistence: Modify Boot/UEFI (T1542.003).
• Command & Control: Web protocols over TLS (T1071.001).
  (IDs aligned to Enterprise matrix; exact sub-techniques vary by environment.)

Impact & Response

Impact: Stolen sessions, bypassed MFA, and durable persistence if boot firmware is altered. Government and regulated sectors face heightened compliance and reporting exposure given device trust failures.

Immediate actions (step-by-step):

1. Inventory & lock trust stores: Alert on new root CAs; require admin-approval workflows + logging for CA changes.
2. Turn on measured/verified boot across fleets; export boot measurements to an attestation service.
3. Bind credentials to hardware: Enforce TPM/Secure Enclave/Pluton-backed keys; disable fallbacks to exportable secrets.
4. Session protection: Short-lived tokens, continuous re-auth on posture drift, and token binding where available.
5. Firmware discipline: Apply OEM updates; enable write protection on SPI flash; require signed UEFI capsules; monitor for UEFI variable anomalies.
6. Isolation on suspicion: If rogue CAs or boot mismatches are detected, block access, capture measurements, and route the device to firmware re-flash / secure recovery.

Background & Context

• Real-world precedent: LoJax proved UEFI persistence in the wild (Sednit/Fancy Bear), making below-OS implants a practical threat.
• Raising the baseline: Vendors are pushing hardware roots like Microsoft Pluton to bring TPM-class security inside the CPU and enable simpler, updateable attestation at scale.

What’s Next

Expect wider adoption of hardware-anchored identity, token binding, and continuous device attestation—and likely policy mandates in government and critical infrastructure to implement NIST’s protect-detect-recover firmware model. For defenders, the lesson is clear: move trust from the network perimeter into silicon.

Root-of-Trust (RoT) Defense Checklist for CISOs & IT Teams

1. Firmware & Boot Integrity

• ✅ Enable Secure Boot + Verified Boot on all endpoints.
• ✅ Turn on measured boot and forward logs to an attestation service (e.g., Microsoft Defender ATP or custom MDM).
• ✅ Apply NIST SP 800-193 Protect–Detect–Recover guidance: enable rollback protection, watchdogs, and signed firmware updates.

2. Credential Binding

• ✅ Require TPM/Secure Enclave/Pluton for storing keys (disable exportable software keys).
• ✅ Enforce device-bound FIDO2 credentials in identity providers (Azure AD, Okta, Google Workspace).
• ✅ Turn off legacy MFA fallback (e.g., SMS or OTP that bypass hardware).

3. Trust Store & Certificates

• ✅ Monitor for rogue root certificates in Windows/Mac/Linux trust stores.
• ✅ Enforce admin-only CA installs with logging and SIEM integration.
• ✅ Run weekly CA inventory scans; alert on any unauthorized roots.

4. Session Protection

• ✅ Enable token binding where supported (ties session to device).
• ✅ Enforce short-lived tokens (e.g., 10–15 min for critical apps).
• ✅ Turn on continuous risk evaluation—revoke sessions on CA mismatch or boot measurement drift.

5. Supply-Chain & Device Controls

• ✅ Use OEM-signed firmware only; enable capsule update verification.
• ✅ Lock SPI flash where hardware supports it.
• ✅ Segment management engines (iLO, iDRAC, BMC) into separate VLANs with strict ACLs.

6. Incident Response Playbook

• ✅ Isolate any device with trust-store anomalies or boot log mismatch.
• ✅ Re-flash firmware with vendor images, not OS reinstalls (malware may survive).
• ✅ Rotate all keys and certificates tied to that device.
• ✅ Conduct a forensic review of boot/firmware logs for persistence artifacts.

📌 Pro Tip from El Mostafa Ouchen:

“Defenders must treat trust anchors—firmware, secure boot, TPMs—not as passive baselines but as active attack surfaces. Building continuous attestation pipelines is the only way to catch RoT drift before adversaries turn MFA into a bypassed formality.”

Sources:

• The Hacker News — Expert Insights (Aug 18, 2025): Secret Blizzard’s RoT attack path and countermeasures (device-bound credentials, independent roots, mutual verification, continuous checks). The Hacker News
• NIST SP 800-193 (2018): Platform Firmware Resiliency—protect, detect, recover model; measured/verified boot guidance. NIST Publications
• ESET (LoJax, 2018): First in-the-wild UEFI rootkit demonstrating pre-OS persistence risk. web-assets.esetstatic.comwelivesecurity.com
• Microsoft Pluton (2025 docs): Silicon-level root of trust, TPM 2.0 functionality, and updateable hardware security. Microsoft Learn+1TECHCOMMUNITY.MICROSOFT.COM