ClearFake WebDAV Chain Delivers Stealers and Remote Access
Cisco Talos details a ClearFake delivery chain using WebDAV, blockchain-hosted JavaScript, Amatera, ZigCryptoStealer, and NetSupport Manager.
Cisco Talos has documented a multi-stage ClearFake infection chain that combines compromised websites, blockchain-backed JavaScript, social engineering, WebDAV execution, and several follow-on payloads. The operation delivered Amatera stealer in the observed branches, with additional activity involving ZigCryptoStealer, a Go-based reverse proxy, and an unauthorized NetSupport Manager installation.
The investigation began after Talos observed a DLL called verification.google executing from a WebDAV location at a Ukrainian government organization. The researchers later identified a related chain involving a second disguised DLL named pf.ch. Talos says the two chains share a similar delivery design, but it did not directly recover every stage of the verification.google branch. The organization assesses with moderate confidence that the activity is part of a broader credential- and cryptocurrency-theft operation rather than an intrusion aimed exclusively at one organization.
Talos tracks the actor associated with the verification.google activity as UAT-10820. With moderate confidence, the organization assesses that this branch was conducted by a Russian threat actor. That assessment should not be extended automatically to every ClearFake or Amatera campaign: Talos found no common infrastructure or other evidence linking the activity described in its report to several separate Amatera delivery campaigns.
From compromised site to ClickFix prompt
The more completely reconstructed pf.ch chain appears to start when a compromised website loads JavaScript injected by an unauthorized Cloudflare Worker. The script retrieves encoded content from contracts on BNB Smart Chain, a technique Talos identifies as EtherHiding. The blockchain is used as remotely changeable storage for browser-delivered code rather than as a conventional web-hosting location.
The initial JavaScript checks characteristics of the browser, including whether it appears to be running in a local or headless environment. It also determines whether the system is using Windows or macOS and selects an operating-system-specific blockchain contract. For Windows visitors, the script creates a tracking identifier in a cookie and consults a separate contract to determine whether the desired interaction has already occurred.
When the browser is not headless and the target is Windows, the page displays a fake Google CAPTCHA-style verification prompt. This is a ClickFix technique: the victim is told to open the Windows Run dialog, paste content supplied through the clipboard, and press Enter. The copied command causes Windows to access a WebDAV path on a randomized subdomain of leaguejazire[.]com. It then invokes the disguised pf.ch file through the 32-bit version of rundll32.exe, using export ordinal 1.
Talos observed a comparable WebDAV pattern in the verification.google branch. In both cases, a 32-bit DLL is retrieved from a remote WebDAV path even though its filename does not identify it as a DLL. Execution occurs through rundll32.exe and an ordinal export. The relevant exports were named moor in pf.ch and CfgInspectModuleData in verification.google.
The macOS portion of the browser chain used a different execution sequence and was not investigated further by Talos because the original research focused on Windows telemetry. Organizations should therefore avoid assuming that the Windows and macOS branches have identical payloads or post-exploitation behavior.
Two loaders, different evasion designs
The two initial loaders use different protection and unpacking methods. Talos describes pf.ch as a packed 32-bit DLL that uses vectored exception handling, API hashing, XOR operations, and unusual control-flow patterns. After initialization, a thread waits for an event named hit. Once triggered, the loader places an embedded blob into memory and transfers control through Windows fibers. XOR and LZNT1 decoding then reveal the Amatera payload.
The recovered Amatera sample was a memory-resident artifact and was not observed being written to disk. It uses a 32-to-64-bit transition approach for system calls and resolves APIs by walking loaded module export tables. Talos observed the build label 4.1.5-alpha and the string GETWELLV2. The sample resolves its command-and-control address before downloading its configuration.
The verification.google loader follows a separate path. It schedules work through the dynamically resolved TpAllocWork function, uses control-flow flattening, resolves functions by hash, and implements direct WoW64 syscall stubs. It then maps a clean copy of dbghelp.dll into memory and overwrites the beginning of its code section with the unpacked next stage. Execution is transferred to the modified region. Talos describes this as module stomping, also called DLL hollowing or module overloading.
These behaviors create several endpoint-monitoring opportunities. Suspicious combinations include 32-bit rundll32.exe accessing WebDAV paths, ordinal-based DLL execution, unexpected use of Windows fibers, direct system-call activity, and a legitimate system DLL being mapped and then modified in memory. None of these signals alone proves compromise, but their combination is materially more suspicious than ordinary application behavior.
Amatera tasking and follow-on payloads
Amatera acts as the primary information-stealing component in both branches, but its command-and-control configuration differs. In the pf.ch branch, the sample uses a Telegraph page as a dead-drop resolver. Talos decoded the page content to obtain the C2 address 145[.]249[.]109[.]147, which the malware contacted over TCP port 443. The sample then requested a GetEndpoints resource and received randomized paths for later functions and collection rules.
The other Amatera build contained an encrypted bootstrap address that resolved to 45[.]150[.]34[.]2, also using TCP port 443. It presented github[.]com as the TLS server name and HTTP Host value. Its configuration contained extensive collection rules covering browsers, extensions, messaging applications, cryptocurrency wallets, password managers, authenticators, VPN and FTP software, remote-access tools, selected files, private keys, certificate material, and other credential-related data.
Amatera's tasking format can direct the loader to retrieve additional executables, DLLs, scripts, PowerShell, shellcode, or MSI packages, with support for file-based or fileless execution. In the pf.ch branch, one task downloaded an archive containing a legitimate Chrome component and a malicious Secur32.dll. The Chrome executable sideloaded the DLL, which was a NativeAOT loader.
The NativeAOT component loaded ZigCryptoStealer and a signed Windows driver. Talos reports that ZigCryptoStealer monitors the clipboard for cryptocurrency address formats and can replace matching values with addresses embedded in the payload. It also queries a BNB Smart Chain contract to obtain changeable C2 data. At the time of analysis, the contract returned lb[.]propertyfind[.]cc. Earlier values included fd[.]gstats-api-contact[.]cc, pkg[.]vogueatelier[.]cc, kffd3[.]vogueatelier[.]cc, kffd3[.]vexlatech[.]cc, and static[.]quorashift[.]cc.
The same loader also used the driver to terminate processes associated with endpoint security tools. Talos identified the driver as DCRCVDrv.sys, with device name \\Device\\DCRCVDRV_U. The reported IOCTL path accepted a process identifier and invoked process termination without a caller authorization check. This is a bring-your-own-vulnerable-driver-style defense-evasion capability, although Talos does not assign a CVE in the supplied research.
A second pf.ch task delivered shellcode that unpacked a Go executable. The program used WebSocket Secure and Yamux to create a multiplexed reverse TCP proxy. It collected the Windows MachineGuid and hostname, connected to update[.]dubbedmuch[.]cc, and relayed traffic between requested destinations. This capability gives an operator an interactive network relay beyond Amatera's automated collection.
NetSupport adds interactive access
The verification.google branch received a fileless PowerShell task. The script performed environment checks involving system uptime, timing, processor and memory characteristics, display information, and virtualization-related device names. It also generated background requests to legitimate developer and software services, which Talos assesses may create plausible decoy traffic.
The script downloaded an archive, extracted it under the user's application-data directory, and created a scheduled task triggered at user logon. The launched hypersnap.exe was a renamed and signed NetSupport Manager client. Its configuration suppressed visible interface elements and directed the client to paternal-angrily[.]com:443, which resolved during analysis to 212[.]118[.]56[.]166. The client polled the gateway every 60 seconds.
NetSupport Manager is a legitimate remote-access product, but the installation described by Talos was unauthorized. In this context it provided operator-driven screen and input control, file transfer, system inventory, process and service management, and remote command or PowerShell execution. The deployment license information overlapped with other malicious NetSupport packages, but Talos treats that as evidence of shared deployment lineage rather than a unique attribution marker.
What organizations should do now
- Investigate WebDAV and Rundll32 telemetry. Alert on remote WebDAV UNC paths, the Windows WebClient service starting unexpectedly, 32-bit
rundll32.exelaunching files with misleading extensions, and ordinal-based exports. - Restrict user-driven execution. Train users that CAPTCHA or verification pages should not require pasting commands into Run or Terminal. Consider application-control policies that limit script interpreters, unapproved remote-access tools, and execution from temporary or user-writable locations.
- Monitor memory and module behavior. Hunt for module stomping, suspicious executable memory, direct syscall patterns, unusual fiber activity, and unsigned or unexpected DLLs loaded beside legitimate Chrome components.
- Protect endpoint security processes. Review driver-installation events, new kernel services, unusual IOCTL activity, and attempts to terminate security software. Maintain current allowlists for approved drivers and use platform controls that block unapproved vulnerable-driver loading where available.
- Review persistence and remote-access software. Audit scheduled tasks triggered at logon, renamed NetSupport binaries, hidden client configurations, and outbound connections to unauthorized remote-support gateways.
- Hunt for the supplied indicators. Search DNS, proxy, firewall, endpoint, and memory telemetry for the domains, IP addresses, filenames, and hashes reported by Cisco Talos. Defanged indicators should be restored only within controlled security tooling.
- Reduce credential and wallet exposure. Rotate credentials and tokens following confirmed compromise, invalidate active sessions where appropriate, and review cryptocurrency activity and access to password managers, authentication stores, certificates, and private-key files.
Talos also lists the following ClamAV signatures for coverage: Win.Backdoor.BadDav-10060502-0, Win.Backdoor.GoProxShell-10060503-0, Win.Malware.AmateraStomper-10060507-0, Win.Backdoor.BadNetSup-10060508-0, and Js.Downloader.ClickFix-10060510-0. Organizations should validate that their deployed security products support the relevant signatures and should not rely on signature detection alone.
Conclusion
The campaign described by Cisco Talos is notable less for a single novel component than for how several delivery and evasion methods are assembled. A compromised site and blockchain-backed script lead to a ClickFix prompt; WebDAV and disguised DLLs provide execution; Amatera performs broad credential and cryptocurrency collection; and follow-on tasks can add clipboard theft, security-process termination, network proxying, or interactive remote access.
Organizations can disrupt this chain by treating command-pasting prompts, unexpected WebDAV execution, unauthorized remote-support software, suspicious driver activity, and memory-only payloads as related signals. The findings and attribution judgments remain those of Cisco Talos, and some stages—particularly parts of the verification.google delivery path—were reconstructed rather than directly observed.