Technical report: malicious Cloudflare Worker on autocorrectforpc.com (1 to 18 October 2026)

All times are UTC. Indicators are defanged: [.] is a dot, hxxp is http. Do not run any command shown here.

1. Summary

On 1 October 2026, an unauthorized person logged in to the Cloudflare account in front of our website using a compromised password (two-factor authentication was not enabled) and created a Cloudflare Worker. The Worker had routes on our website domains and inserted an attacker-controlled script into HTML responses before the closing </body> tag.

On Windows desktop browsers, that script could display a fake "Performing security verification" overlay (a ClickFix lure) and place a PowerShell command on the clipboard, telling visitors to paste and run it. In the researcher's sandbox run, the command led to browser credential theft behaviour. Mac visitors were served a separate payload that has not been analysed.

An independent researcher, Adonis Sardiñas, found and analysed the problem on 18 October. We deleted the Worker and its routes the same day at about 16:48. The Worker was live for roughly 17 days.

2. Timeline

3. How the attacker got in

The Worker was created 15 seconds after a login to the account. The password was compromised and two-factor authentication was off, so the password alone was enough. We have not established how the password was exposed (reuse, a breach, malware on a device, or phishing). We will update this report when we know. We are also reviewing every account change from late September onward, not only the Worker.

4. The malicious Worker

We hold a copy of the Worker's code, captured before the Worker was deleted. The address of the smart contract it read is redacted in our copy and has not been recovered. Its behaviour, in order:

1. Makes one read-only eth_call to a public BNB Smart Chain testnet RPC server (bsc-testnet-rpc[.]publicnode[.]com) to read a base64 string from a smart contract.
2. Forwards the original request to our origin and receives the response.
3. If the response has an HTML content type and the string was read, decodes it and inserts it as an inline <script> immediately before </body>. Otherwise the response passes through unchanged.

Observations:

The page markup appended before </body> was confirmed in the HAR as the last script on the page, after our own content, which also rules out browser extensions as the source.

5. Downstream chain (researcher's analysis)

1. Loader. The injected script skips headless browsers, automation frameworks and local or private addresses (printing the marker string stop watching us :)). Otherwise it selects a contract by operating system: one for Windows, one for macOS. Other systems receive nothing. It tries up to seven public testnet RPC hosts in turn.
2. Stage 1 (Windows). About 94 KB of JavaScript. It builds the "Performing security verification" overlay (using Font Awesome 5.0.0 CSS for icons), sets a cookie named cjs_id (2 days) containing the visitor's public IP from an Avast IP-info endpoint (random UUID as fallback), loads Yandex Metrica counter 99162160 and fires a "Click" goal, polls a tracker contract about once a second (selector 0x24513bb6 plus the visitor id) to see whether the visitor already ran the command, and writes the PowerShell command to the clipboard.
3. Execution. The overlay tells the visitor to press Win+X, I, Ctrl+V, Enter. The command downloads a script from a GitHub account served through jsDelivr, using quote-splitting (c"d"n, g"h") to evade string detection.
4. Stage 3. That script downloads install.ps1 from a selectivewilled[.]cc host and runs it in a second PowerShell with the execution policy bypassed.
5. Payload. In the sandbox, rundll32 launched with a browser-credential-theft signature and checked in to audit[.]bitfetch[.]cc. The sandbox PCAP showed no other attacker hosts. The run is public: ANY.RUN task 034205a0-c25c-428e-b6d2-e5daa98901d2.

macOS was not analysed. Mac visitors were sent to a separate contract. Campaigns of this type commonly deliver an infostealer through a Terminal paste lure, but that is an educated guess, not a finding.

6. Impact

7. Indicators of compromise (defanged)

Some identifiers are attacker-chosen and are not well-formed GUIDs. Check any copy against the original captures.

Long indicators, one per line (copy from here, because table cells can wrap at hyphens):

8. Detection and hunting suggestions

Note that Win+X, I opens a terminal, not the Run dialog, so Run history is not the place to look. History files can be cleared.

9. Response and changes

Done:

10. Lessons

1. An edge account without two-factor authentication is a single point of failure. A Worker on a wildcard route can modify every page without touching the origin, so origin logs and repository checks showed nothing wrong.
2. Edge configuration needs the same review as code: list Workers, routes, Snippets and tokens regularly, and alert on changes.
3. Put a reachable security contact on every domain. The first report to us bounced because of a wrong domain in an email footer.
4. The on-chain payload stays live and reusable after the injection is removed, so detection and fast removal at the point of injection matter most.

11. MITRE ATT&CK mapping

T1078.004 Valid Accounts: Cloud Accounts; T1584.006 Compromise Infrastructure: Web Services; T1583.001 Acquire Infrastructure: Domains; T1608.001 Stage Capabilities: Upload Malware; T1608.004 Stage Capabilities: Drive-by Target; T1189 Drive-by Compromise; T1102.001 Web Service: Dead Drop Resolver; T1497.001 Virtualization/Sandbox Evasion: System Checks; T1027 Obfuscated Files or Information; T1027.010 Obfuscated Files or Information: Command Obfuscation; T1140 Deobfuscate/Decode Files or Information; T1204.004 User Execution: Malicious Copy and Paste; T1059.007 Command and Scripting Interpreter: JavaScript; T1059.001 Command and Scripting Interpreter: PowerShell; T1105 Ingress Tool Transfer; T1218.011 System Binary Proxy Execution: Rundll32; T1555.003 Credentials from Web Browsers; T1071.001 Application Layer Protocol: Web Protocols.

12. Open items

We will update this report as these are resolved.

13. External reports filed by the researcher (18 October)

Our domain registrar (two reports, with our domain framed as the victim); the registrar of the two attacker domains; GitHub (account werd19327); jsDelivr (stage 2 path); FortiGuard web filtering; Netcraft; Malwarebytes; urlscan; APWG; the UK NCSC; and a "Report this product" report on our Microsoft Store listing, stating that our website, not the app, had been compromised. We are contacting the registrar and Microsoft ourselves with our incident summary.

14. Credit

We thank Adonis Sardiñas, Cyber Security Researcher and Adjunct Professor, Jack D. Gordon Institute for Public Policy, Florida International University, who found this problem, analysed the attack chain, filed the external reports, and gave us detailed evidence and advice.

AutoCorrect PC Team