Over 5,400 Hacked Sites Serve ClickFix and WebRTC Paths

1. Basic Information

• Article Name: Over 5,400 hacked sites serve ClickFix payloads stored on the blockchain
• Publisher: BleepingComputer
• Publication Date: 2026-09-05
• Original Source: BleepingComputer
• Related Information Sources: Netskope Threat Labs, Netskope Threat Labs IOC repository
• Related Malware, Attack Groups, CVEs, and Products: ClickFix, EtherHiding, WordPress, PrestaShop, BNB Smart Chain Testnet, WebRTC, PowerShell
• Severity: High

2. Summary

Over 5,400 compromised websites fetched next-stage components from BNB Smart Chain Testnet smart contracts. The observed vectors include ClickFix, which tricks users into pasting PowerShell commands, and a WebRTC variant that receives and runs JavaScript through a WebRTC data channel without signaling.

3. Attack Flow

ClickFix Vector

1. Attackers compromise legitimate websites, including WordPress and PrestaShop, adding inline scripts or loaders disguised as legitimate packages. The initial compromise method is unknown.
2. The loader runs in the visitor browser and sends a JSON-RPC eth_call to the BSC Testnet RPC.
3. The script retrieved from the smart contract displays a fake CAPTCHA ClickFix screen, prompting the user to paste a command into the Windows Run dialog.
4. When the user performs this action, a downloader containing PowerShell retrieves and runs the final payload. The final payload is not fixed.

WebRTC Data Channel Vector

1. The smart contract returns a small JavaScript stager instead of a ClickFix screen.
2. The stager builds the C2 IP address, UDP port, ICE password, and DTLS certificate fingerprint in the code.
3. Without using a normal signaling server, it provides its own generated response to the browser to open a WebRTC data channel.
4. It combines the JavaScript received from the C2 in memory, reuses the CSP nonce of the legitimate script, and adds it to the DOM. If there is no nonce, it uses Function().
5. After code execution, it deletes the added script element and the channel.

4. Attacker Position and Execution Location

• Attackers are in a position to insert loaders into already compromised websites. The initial method used to compromise the sites is not publicly disclosed.
• The initial loader, ClickFix screen, and WebRTC stager run in the visitor browser.
• Commands pasted by users via ClickFix run on Windows endpoints. The WebRTC variant adds the received JavaScript to the page DOM and executes it.
• BSC Testnet smart contracts serve as storage where operators can update the distribution content for many compromised sites from a single location.

5. Visibility for Victims and Administrators

Victims

• When visiting a legitimate site, the page may blur, displaying a screen disguised as a CAPTCHA and instructions for Windows operations.
• In the ClickFix vector, a command is placed on the clipboard, and users are guided to paste it into the Run dialog themselves.
• In the WebRTC variant, there may be no noticeable saved files or standard signaling screens, and code may execute within the page.

Administrators

• On the website side, items to check include suspicious added code at the end of legitimate JavaScript, fake plugin directories, and JSON-RPC requests to the BSC Testnet RPC.
• On the endpoint side, PowerShell execution after browser browsing, downloads, child processes, and final payload behavior appear.
• In the WebRTC variant, while regular DNS or STUN/TURN associated with signaling is absent, DTLS/WebRTC traffic from the browser to external IPs and UDP ports may appear.

6. Success and Failure Conditions

Success Conditions

• Attackers embed loaders into legitimate websites and have them execute in visitor browsers.
• Reachability to BSC Testnet RPC and the attacker smart contract.
• In the ClickFix vector, users follow the displayed steps to paste and run the command.
• In the WebRTC vector, traffic from the browser to the specified external IP and UDP port is allowed, and the received code executes within the page.

Failure Conditions and Risk Mitigation

• Monitor website file and plugin integrity and remove suspicious added scripts.
• Block connections to BSC Testnet RPC groups unnecessary for business, and limit usage subjects if necessary.
• Restrict unnecessary outbound UDP traffic from browsers and monitor WebRTC traffic destinations and usage.
• Apply application control and PowerShell control to prevent users from executing suspicious pasted commands.
• Educate users that CAPTCHAs normally do not request the pasting of Windows commands.

7. What Happens Upon Success

• In the ClickFix vector, arbitrary final payloads may be retrieved and executed with user privileges.
• In the WebRTC variant, JavaScript received from the encrypted data channel runs in the page execution context.
• Attackers can switch the content distributed by numerous compromised sites simply by updating the smart contract.
• Public information does not confirm the final payload executed for each visitor, the number of infected endpoints, or post-compromise damage.

8. Observable Logs

• Email: Not applicable. Email was not observed as an initial vector.
• Proxy/SWG/DNS: JSON-RPC requests to BSC Testnet RPC after visiting legitimate sites, eth_call, and connections to final payload retrieval destinations.
• Endpoint/EDR: PowerShell or downloader execution following browser activity, clipboard usage, downloaded files, and final payload process lineage.
• Identity/IdP: No direct authentication abuse reported. If payloads utilize credentials, check for subsequent suspicious sign-ins separately.
• SaaS/Cloud: Website management and deployment history, CMS file modifications, plugin additions, and hosting-side change logs.
• Network: DTLS/WebRTC traffic from the browser to unknown external IPs and UDP ports. Even without normal signaling DNS or STUN/TURN, check outbound UDP itself.

9. Attack Success Determination

• Attack Attempt Observed (Success Unconfirmed): Confirm site visits, BSC Testnet RPC requests, and fake CAPTCHA display. Code execution on endpoints is unconfirmed at this stage.
• User Action Confirmed: Confirm records of users pasting commands into the Run dialog and executing them. Separate pasting from execution.
• Initial Execution Confirmed: Confirm launch of PowerShell or downloaders, or DOM addition of JavaScript received via WebRTC.
• Malware Execution or Authentication Success Confirmed: Confirm final payload processes and behavior, or execution results of code received from WebRTC C2. Downloading alone does not count as execution success.
• Information Theft or Session Compromise Confirmed: Confirm credential and data retrieval by the final payload and exfiltration. Public articles do not indicate the number of victims at this stage.
• Subsequent Compromise Confirmed: Confirm persistence, lateral movement, or additional tool deployment. Do not treat the count of over 5,400 sites as the number of successfully compromised endpoints.

10. Investigation Playbook

Inference: Investigation proposals based on observed distribution vectors and capabilities.

• Trigger: BSC Testnet RPC connection after visiting legitimate sites, PowerShell execution following fake CAPTCHA, and UDP traffic from the browser to unknown external IPs.
• Initial Verification: Preserve visited URLs, timestamps, browsers, clipboards, command lines, and outbound traffic.
• Endpoints: Examine browser child processes, PowerShell history, downloads, in-memory execution, and final payload artifacts.
• Authentication and Cloud: Check subsequent sign-ins by endpoint users and CMS modifications or administrative actions on managed websites.
• Subsequent Actions: Track credential access, data collection, exfiltration, persistence, and lateral movement.
• Containment: Isolate endpoints, block RPC and C2 traffic, remove loaders from compromised sites, and rotate credentials as necessary.
• Determination Categories: Separate site compromise, browsing, fake screen display, user action, initial execution, final payload execution, C2 establishment, and subsequent damage.

11. Defense and Detection Ideas

Inference: The following are implementation proposals for operations.

• Single Event: PowerShell launched from user action immediately after browser activity.
• Time-Series Correlation: Correlate legitimate site visit -> BSC Testnet RPC -> fake CAPTCHA -> Run dialog -> PowerShell -> external retrieval.
• Hunting: Search for connections to BSC Testnet RPC groups, eth_call, non-web UDP from browsers, and added script elements using legitimate script CSP nonces.
• Log Gaps: Without TLS decryption or browser monitoring, RPC methods or execution within the DOM may not be visible. Because WebRTC bypasses normal signaling, DNS alone will miss it.
• Priority Measures: Prioritize CMS integrity monitoring, Testnet RPC group restrictions, PowerShell and application control, browser outbound UDP monitoring, and user training.

12. Facts / Inference / Hypothesis

Facts

• Netskope reported observing over 5,400 compromised websites connecting to BSC Testnet RPCs, spanning over 2,200 organizations.
• Investigated sites are primarily WordPress and some PrestaShop; initial compromise methods are unknown.
• Loaders retrieve next stages from smart contracts via JSON-RPC eth_call and execute them in the browser.
• The ClickFix variant displays a fake CAPTCHA and prompts users to paste and execute Windows commands.
• Another variant opens WebRTC data channels with hardcoded connection details, bypassing normal signaling.
• The WebRTC variant assembles received JavaScript in memory, reuses CSP nonces to add it to the DOM, and deletes the element after execution.
• Netskope reports continuously observing over 300 compromised sites on weekdays.

Inference

• Blocking a single BSC Testnet RPC may allow attackers to switch to another RPC on the same network.
• The WebRTC variant makes it easier to evade monitoring that relies solely on standard web proxies or signaling destination DNS.

Hypothesis

No additional hypotheses. Unconfirmed items are listed in "Unanswered Questions and Further Investigation".

13. MITRE ATT&CK Mapping

• T1189 Drive-by Compromise (High): Malicious scripts are distributed to browsers starting from visits to compromised websites.
• T1204.004 User Execution: Malicious Copy and Paste (High): ClickFix screens prompt users to copy and paste commands.
• T1059.001 Command and Scripting Interpreter: PowerShell (High): Pasted commands use PowerShell to retrieve and execute subsequent stages.
• T1105 Ingress Tool Transfer (High): Downloaders retrieve final payloads from external sources.

14. Unanswered Questions and Further Investigation

• Initial methods and common vulnerabilities or credentials used to compromise WordPress, PrestaShop, and other sites.
• All types of final payloads distributed via the ClickFix vector and the number of successful endpoint executions.
• The purpose of JavaScript sent from C2 via the WebRTC vector and subsequent damage from its execution.
• Number of users who visited the over 5,400 compromised sites, infected endpoint counts, and regional impact.
• Relationship of operators and infrastructure with Amatera ClickFix. IOC repositories manage related activities in the same directory, but current WebRTC activity is considered unattributed.

15. Impact on SOCs and Organizations

For organizations, it is important not to treat web browsing-based attacks solely as email security issues. This activity begins with compromised legitimate sites and branches into BSC Testnet RPCs, fake CAPTCHAs, PowerShell, and WebRTC. It is necessary to cross-reference web proxy, DNS, endpoint, and network logs to trace the flow from visiting legitimate sites to unnatural operational instructions or outbound UDP traffic.

Blocking a single BSC Testnet endpoint or individual IP address may cause operators to switch to another RPC. For organizations with no operational need, restricting Testnet RPC groups and whitelisting usage subjects and purposes when necessary is more effective. Regarding WebRTC, do not assume browser traffic is safe; verify outbound UDP and DTLS traffic to unknown peers that are not required for business operations.

Meanwhile, the figure of over 5,400 represents the number of compromised websites, not endpoints where final payloads were executed. SOCs should evaluate site visits, fake CAPTCHA displays, command pasting, PowerShell execution, final payload execution, and C2 establishment separately, containing incidents based on confirmed stages.

16. Summary by Role

• For SOCs: Correlate BSC Testnet RPCs, post-browser PowerShell, and outbound UDP in a time-series, separating stages from browsing to C2 establishment.
• For Administrators: Implement CMS tampering monitoring, restrict Testnet RPC groups, control PowerShell, and monitor WebRTC outbound traffic.
• For Users: If a CAPTCHA requests pasting a Windows command, do not execute it; close the page and report it.