ClearFake WebDAV infection chain delivers Amatera stealer, ZigCryptoStealer, and NetSupport Manager
Cisco Talos has identified a sophisticated and ongoing campaign leveraging WebDAV execution to deliver the Amatera stealer. The campaign utilizes a complex chain of loaders and payloads, including ZigCryptoStealer and NetSupport Manager, to steal credentials and cryptocurrency. The initial trigger is often a Cloudflare Worker injecting JavaScript into a compromised website, leading to a BNB Smart Chain-based EtherHiding operation. The campaign is likely driven by a Russian threat actor, with evidence pointing to a similar activity targeting a Ukrainian government organization. The campaign employs various techniques to evade detection, including DLL hollowing, module stomping, and utilizing a Telegram-based C2 server.
Cisco Talos began an investigation after observing a DLL named "verification.google" executing from WebDAV at a Ukrainian government organization. We assess with moderate confidence that the attacks are not targeted at a particular organization, but are a part of a cryptocurrency and credentials-stealing operation using the Amatera stealer as the primary payload. Following the initial finding in endpoint telemetry in April 2026, we discovered two similar WebDAV and ordinal-execution patterns, two different DLL loaders and two ACR/Amatera stealer payloads. Talos tracks the actor behind the observed "verification.google" activity as UAT-10820.
Following the initial investigation, we decided to hunt for similar WebDAV and ordinal-execution patterns in an attempt to recover the full infection chain, which would likely point to how "verification.google" execution was triggered. This led us to the "pf.ch" loader and the chain we discovered.
The "pf.ch" sample uses the same combination of WebDAV, a disguised DLL filename and ordinal execution through "rundll32.exe". We were also able to recover the full ClickFix related sequence leading to this loader. Figure 1 shows both chains, with dashed elements marking stages that were not directly recovered. With low to medium confidence, we assess that the two delivery chains are identical.
The discovered "pf.ch" loader chain was initiated by ClearFake Javascript injected into the content of a compromised website by a malicious Cloudflare worker. The C2 server returned configuration instructing the stealer to download a DLL side-loading package in which a signed Chrome component sideloads a malicious NativeAOT DLL, "secur32.dll". The DLL loads ZigCryptoStealer and uses a vulnerable driver to terminate EDR software. A separate x86 shellcode loader with a Go reverse TCP proxy is also downloaded as a secondary payload by the Amatera configuration sent by the C2 server.
The secondary payload of the "verification.google" branch as instructed by its own C2, is a PowerShell script which attempts to install a sample of NetSupport Manager remote access tool.
ClearFake retrieves browser code from BNB Smart Chain The "pf.ch" branch begins likely on a compromised website. A Cloudflare Worker injects a malicious JavaScript which queries BNB Smart Chain testnet contract 0x886d310Ac23e05EA705e24E513D19f53793832A9 through "bsc-testnet-rpc[.]publicnode[.]com".
BNB Smart Chain is a public, Ethereum-compatible blockchain hosting transactions and smart contracts. The actor uses the contract as remotely changeable storage for encoded JavaScript, a technique known as EtherHiding. Based on the operating system of the victim’s machine, the JavaScript code retrieves the next stage from the blockchain, which acts as a bulletproof hosting provider for the malicious code. Potent Pages previously documented unauthorized Cloudflare Workers querying the same first stage contract.
The initial Javascript code contains routines to check for local and headless browser environments, identifies the operating system, and queries a second contract based on the result of the operation. If the victim is running Windows, it retrieves code from 0x46790e2Ac7F3CA5a7D1bfCe312d11E91d23383Ff and if the victim is running macOS, it uses 0x68DcE15C1002a2689E19D33A3aE509DD1fEb11A5. The response is Base64 decoded and evaluated as JavaScript.
The Windows browser stage creates a victim identifier, stores it in the cjs_id cookie and asks a tracking contract whether the goal for that identifier has already been reached. If the browser is not headless and the target is Windows, the script overlays a fake Google CAPTCHA-style checkbox onto the compromised page, instructing the victim to open the Windows Run dialog, paste the clipboard contents, and press Enter.
The copied command opens a WebDAV path on a randomized subdomain of "leaguejazire[.]com", places the victim identifier in the path, and executes "pf.ch" through ordinal #1.
Censys documented the same Windows and macOS contracts in a blockchain-backed ClickFix chain, although the downstream payloads in that reporting differ from those analyzed here.
The macOS browser stage uses the same headless-browser checks, victim tracking, and fake verification design, but its execution chain is different. It instructs the victim to open Terminal and paste a command that uses curl with a macOS user-agent string. The request goes to a subdomain of "riyazinikokar[.]xyz". Since the subject of our initial research was a customer running Windows, we have not further pursued the macOS side of the "pf.ch" branch.
WebDAV launches disguised DLLs
Both observed variants retrieve a 32-bit DLL over WebDAV using a file extension name that does not indicate it is a standard DLL file. Both use the 32-bit "rundll32.exe" process and invoke a function by calling the function ordinal #1. The corresponding first exports are moor in "pf.ch" and CfgInspectModuleData in "verification.google".
Different initial loaders
Although the WebDAV execution pattern is the same the two initial loaders use different code and protection methods.
"pf.ch" uses exception-driven control flow The "pf.ch" loader is a packed 32-bit DLL whose only named export is moor with import table containing only AddVectoredExceptionHandler and __mb_cur_max functions.
The packed code uses vectored exception handling, XOR loops, API hashing, and control-flow patterns, which makes the static analysis of the code more difficult. After the initialization, one of its threads is waiting for an event named hit. Once the event is triggered, it copies an embedded blob into memory and transfers control to it using Windows fibers. The next stage decoder uses XOR and LZNT1 to decode the final Amatera payload.
The unpacked PE file, an Amatera sample, is also 32-bit, has no import table, and resolves APIs by walking loaded module export tables. The sample uses 32-to-64-bit transitions to execute system calls, possibly in an attempt to evade EDR hooks.
The sample contains the build label 4.1.5-alpha and string GETWELLV2. Amatera is known to use the Steam community profiles as C2 dead drop resolvers, and the GETWELL2 string was observed in some previous samples as a name of a Steam community profile used to retrieve the IP address of the C2 server. Once C2 server address is resolved, the payload generates WoW64 transition gates, opens an Auxiliary Function Driver (AFD) socket and connects directly to "145.249.109[.]147" on TCP port 443.
After connecting to the C2 server, Amatera connects to the GetEndpoints URL on the server. The response supplies randomized URI paths for different C2 functions. The stealer then uses the configuration path, together with an embedded build identifier, to retrieve its information collection rules.
In the "pf.ch" build, a TLS-decoded HTTP buffer we were able to analyse contain...