• 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. 
• Pivoting around the similar WebDAV behavior led to a second loader named "pf.ch" and allowed us to reconstruct its earlier delivery stages. The chain uses a Cloudflare Worker to inject JavaScript code stored on BNB Smart Chain and a ClickFix prompt impersonating Google CAPTCHA, leading to download and execution of Amatera stealer. The chain is likely very similar to what has caused the WebDAV-based execution at the Ukraininan government organization.  
• The two Amatera builds were tasked with different secondary payloads by their respective command-and-control (C2) infrastructure: the "pf.ch" loader was instructed to deploy a NativeAOT loader running ZigCryptoStealer and a Go-based reverse proxy, while the "verification.google" loader was instructed to install an unauthorized instance of NetSupport Manager. 
• The NetSupport Manager installation contained configuration with the C2 server using an IP address based in Russia. With moderate confidence, we assess that "verification.google" branch attack was conducted by a Russian threat actor.  

 In April 2026, Cisco Talos identified an unusual WebDAV DLL execution in endpoint telemetry from a Ukrainian government organization. The remote file was named "verification.google" and was launched through the 32-bit version of "rundll32.exe". This initial finding led us to two similar delivery chains, 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. Using VirusTotal, we were able to identify a full chain from a second DLL loader named "pf.ch".  

These two examples are a part of a wider set of recent campaigns delivering Amatera through different infection chains. In July 2026, Malwarebytes documented fake game and software downloads that used RenPy Loader, MSBuild and EtherHiding before delivering Amatera. Blackpoint Cyber described another fake-verification chain that used a signed Microsoft App-V script, configuration stored in Google Calendar and a payload concealed in a PNG image. Apart from the main payload malware family, we found no common infrastructure or other evidence linking those activities to the chains described in this post. 

Initial finding in endpoint telemetry 

The initial event that started the investigation was recorded in April 2026 and it showed an execution of a DLL file through a WebDAV UNC path together with startup of the Windows WebClient service. Apart from the initial command line, we had details of the checksum of the executed DLL but it was not clear what started the execution chain. It was time for hunting in open source intelligence repositories and Talos analytical platform. We wanted to find a similar execution with the similar loader and the payload family and ideally recover the whole infection chain which would likely point to how "verification.google" execution was triggered. This lead us to the "pf.ch" loader and the chain we discovered.  

Hunting reveals a second WebDAV delivery chain 

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 ClickFake 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 site 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 main configuration is downloaded.  

The Amatera payload was recovered only as a memory-resident artifact and was not observed to be written to disk. Its hash is nonetheless included in the indicator of compromise (IOC) list below, as memory derived hashes remain applicable to memory scanning. 

"verification.google" uses DLL hollowing in "dbghelp.dll" 

The "verification.google" variant does not immediately unpack its payload. It first prepares the state and then passes execution through a callback. The callback is registered using the dynamically resolved function TpAllocWork, an undocumented native NT internal function in "ntdll.dll". The callback is later executed asynchronously by Windows. The callback function implements most of the malicious unpacking functionality in a large control flow flattening loop. 

The loader resolves functions by hash, derives execution state from the environment and implements direct WoW64 syscall stubs. The stubs decode syscall numbers at runtime and call the WoW64 transition pointer instead of the corresponding exported "ntdll.dll" functions. 

The loader reconstructs its next stage from data in the .rdata section. It first maps a clean image of the legitimate "dbghelp.dll" in memory and then overwrites the beginning of its code section with the unpacked next stage. Finally, it restores executable protection before transferring control to the overwritten code section of the "dbghelp.dll".  

This module overwriting (stomping) technique is also known as DLL hollowing or module overloading. VMRay’s technical overview of DLL hollowing describes the same core sequence: loading a legitimate DLL, overwriting its mapped code with malicious content, and executing from that overwritten region. G DATA documented module stomping in a HijackLoader chain that delivered ACRStealer, using different DLLs, "evr.dll", and "rasapi32.dll" rather than the "dbghelp.dll" observed in our case. 

Amatera C2 configurations 

"pf.ch" loaded Amatera resolves its C2 through a Telegraph page 

Before starting its Amatera C2 session, the Amatera sample used in "pf.ch" branch constructs the dead drop C2 URL "https[:]//telegra[.]ph/Functions-04-03". At the time of analysis, the page looked like a short Rust programming tutorial titled “Functions.” with an altered code example containing the string r.]MTQ1LjI0OS4xMDkuMTQ3)0(. 

​ The raw HTML places the same value inside a println statement.  

Decoding MTQ1LjI0OS4xMDkuMTQ3 produces “145.249.109[.]147” as its C2 address.  

After resolving the address, 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 contained a nonzero session identifier and an opaque 73-byte body whose framing is consistent with the ECDH and ChaCha20-Poly1305 protocol documented for recent Amatera versions.  

After removal of the transport and application encryption layers, the configuration is first Base64 decoded and then XOR decoded with the key 852149723\x00, before parsing it as a JSON object.  

Apart from the rules for stealing data the received configuration also contained the instructions to load secondary payloads in a ld (load) json array.  

The ld field is an array of secondary loader tasks supplied by the Amatera controller. Within each entry, u is the download URL, tf selects the payload type and tr selects file-based (1) or fileless (2) execution. The loader supports executables, DLLs, command scripts, PowerShell, raw shellcode and MSI packages, which is described by the field tf. The p value determines task order, with lower positive values processed first. 

"verification.google" loaded Amatera configuration 

The "verification.google" Amatera build stores its bootstrap controller as an encrypted string. At runtime, it decrypts the fixed address "45.150.34[.]2" and connects to it directly on TCP port 443, while presenting "github[.]com" as the TLS server name and HTTP Host value. Unlike the "pf.ch" build, it does not use a public dead-drop resolver to obtain its initial C2 address. After connecting, it sends the GetEndpoints command to obtain working endpoints used for subsequent communication.  

As in the "pf.ch" Amatera payload the first accessed C2 URL is GetEndpoints. This branch’s configuration contains over 400 entries across its browser, extension, messaging, wallet, and other-application collection lists, plus four file collection rules.  

The application rules in the configuration blob extend the initial browser related information collection to Telegram, Signal, WhatsApp, and other messaging data. They also cover over 100 desktop wallet locations and credential data from password managers, authenticators, FTP clients, mail clients, VPN software, and remote-access tools. Representative targets include KeePass, Bitwarden, 1Password, RoboForm, NordPass, WinAuth, Authy, FileZilla, AnyDesk, NordVPN and AzireVPN. 

Four file grabber rules cover the Desktop, Downloads, Documents and Windows Recent-items directory. Across those rules, more than 100 unique filename and extension patterns look for private keys, wallet backups, API and OAuth material, two-factor authentication data, password databases and certificate files such as .kdbx, .p12, .pfx and .pem. Most of the collection rules are focused on stealing cryptocurrency related data and credentials.  

Amatera secondary payloads 

Further on, we focus on the secondary loader tasks, which may point to a more advanced threat actor, based on the installed secondary payload type. 

The "pf.ch" Amatera build received two secondary tasks. One deployed a NativeAOT loader and ZigCryptoStealer, while the other ran a Go reverse TCP proxy from memory. The "verification.google" build received a PowerShell task that installed NetSupport Manager.  

NativeAOT chain runs ZigCryptoStealer 

The "jquery.min.js" entry has priority 1, so Amatera processes it first. Its tf: 1 and tr: 1 values select the file-based executable handler. The server response does not have to be a PE file but it can also be an archive file. When this handler receives an archive, the loader extracts it to a temporary directory, enumerates the resulting *.exe file and launches the selected executable. The most recently observed response was a ZIP archive, SHA-256 279d04c0cfd700c8bcb9acbed528131d3ffef8e25d12713e8649772739aecb92.  

The archive included the file "platform_experience_helper.exe", a legitimate Google Chrome component. The executable imports GetUserNameExW from "Secur32.dll", which is a malicious DLL file in the archive which gets sideloaded by the Chrome component.  

The side-loaded "Secur32.dll" is a NET NativeAOT loader which decrypts and loads 2 PE files. The first file is a user mode payload and the second a vulnerable driver used to ter. The NativeAOT DLL starts “C:\Windows\"explorer.exe" in a suspended state, manually maps the PE’s headers and sections into the child, changes its initial thread context to the new entry point, and resumes it.  

The payload is a cryptocurrency stealer written in Zig language — ZigCryptoStealer. It polls the clipboard, recognizes several cryptocurrency address formats and can replace matching values with addresses embedded in the payload.  

The payload makes a separate JSON-RPC eth_call through "bsc[.]rpc[.]blxrbdn[.]com" to BNB Smart Chain contract 0x7CC3cFC1Ac007B8c6566fD2C7419b15a75473468. This is a second use of EtherHiding in the infection chain, this time by the final payload rather than the browser delivery framework. VMRay has previously documented ZigCryptoStealer variants using BNB Smart Chain contracts as a dead drop for C2 configuration.  

ZigCryptoStealer disguises the request as a routine query for an ERC-20 token balance. It supplies a randomly generated cryptocurrency address, but the smart contract ignores it and instead returns text stored by the operator. The operator can change this text using the contract's setData(string) function. During our analysis, the contract returned "lb[.]propertyfind[.]cc", which ZigCryptoStealer then used as its C2 domain. 

The contract was deployed on March 16, 2026. The same wallet that deployed it made 39 successful setData calls through July 26. These calls provide a public history of the C2 values supplied to the malware with six domains active during July: 

Talos used Cisco Umbrella to observe DNS activity for all six domains while they were active. The two most recent values also had the broadest query distribution. Umbrella data includes DNS quaries from 38 countries for "static[.]quorashift[.]cc" and 98 for "lb[.]propertyfind[.]cc". Queries for the current value came most often from the United States, Indonesia, Brazil, India, and Egypt.  

Passive DNS shows that all six domains resolved through shared Cloudflare addresses.  

The second decrypted PE is a signed Windows driver whose version information contains the names MOCOMSYS & DCRC and DCRCV_U Driver (for SCM). Its original filename is "DCRCVDrv.sys", and it exposes the device \Device\DCRCVDRV_U.  

The NativeAOT loader enumerates running processes, hashes their names, and compares the hashes with an internal target list of EDR software and other security tools. For every matched process name, it sends the process identifier to the driver with IOCTL 0x2205c0. The driver’s handler accepts the four-byte PID, obtains a process handle and calls ZwTerminateProcess. We found no caller authorization check in that IOCTL branch. This gives the loader a kernel-mode process-termination primitive, a BYOVD driver. 

​

Go payload turns the host into a reverse TCP proxy 

The URL for the second secondary payload of the "pf.ch" branch yielded a binary shellcode blob with SHA-256 643ef35536ff9273fb84b8504467b1a5645cd3ffd5476d64b99244b02131b205. 

The 32-bit shellcode walks the process environment block (PEB) to find "ntdll.dll" and resolves LdrLoadDll, NtAllocateVirtualMemory, NtProtectVirtualMemory and NtFreeVirtualMemory . It then decrypts and decompresses the final payload stored in the shellcode using XOR to decrypt and LZNT1 to decompress the compressed proxy payload. 

The unpacked file has SHA-256 1819827e17f31e72d456158b6b9c90af25a65945f6f05d04a060da9f24179b25. 

The payload is a Golang 32-bit Windows executable with main package “github.com/acr/proxy-panel/cmd/bot”. It includes HashiCorp Yamux network multiplexing library with C2 hardcoded “wss://"update[.]dubbedmuch[.]cc"/”. 

The proxy reads the Windows MachineGuid and hostname, then sends them over WebSocket Secure (wss) protocol. After the C2 server accepts the client, the program creates a Yamux server session, multiplexing outgoing communications over the same connection. Each logical stream supplies a source and destination address. The client connects to the requested destination and relays bytes in both directions. 

PowerShell in the "verification.google" branch installs NetSupport Manager 

The secondary payload in this branch is "https://kr[.]cedar2glanz[.]ru/jewel[.]js". The tf value 4 of the single secondary payload loader instruction (ld) identifies the payload as PowerShell. The tr value 2 selects the execution path that retrieves the URL with PowerShell DownloadString and runs it through Invoke-Expression (IEX). Proofpoint’s Amatera analysis documents the same ld, tf and tr semantics in more details.  

The next PowerShell stage dynamically resolves native functions and runs an environment check before installing the payload containing the following steps: 

• It queries the C: volume serial and compares it with the hard-coded value 4E014A2F. The original expression returns true when this value matches, allowing execution to continue early and skipping the remaining checks.  
• It calculates system uptime from Win32_OperatingSystem.LastBootUpTime. An uptime below 10 minutes returns false, causing the script to exit. 
• It measures a native 500 ms NtDelayExecution call with GetTickCount64. If fewer than 400 ms appear to elapse, the gate returns false, which can identify an environment that accelerates or skips delays. 
• It checks the processor count. Fewer than three processors unexpectedly returns true and allows execution to continue early rather than rejecting the low-resource system. 
• It queries total physical memory. A reported value below 3.2GiB returns false. 
• It queries Win32_VideoController and selects the largest reported AdapterRAM value. A reported maximum below 384 MiB returns false. 
• It checks display-device friendly names and manufacturers against 36 strings associated with virtual graphics, remote displays, cloud platforms and generic virtual adapters. A match returns false. 

After the environment checks, the script derives an installation path by hashing MachineGuid|zdozwoqx3c. It also starts two background Powershell runspaces that request many legitimate URLs, including GitHub API, npm, Docker Hub, PyPI, NuGet, and PowerShell Gallery. The requests seem to generate decoy traffic to hide the malicious download within plausible developer activity. 

The script downloads "https://phys[.]stunned-amniotic[.]com/hub[.]log". Although the logs at the targeted system in Ukraine contained no evidence of accessing this URL we were able to download the file that was likely intended to be downloaded and executed by the Amatera stealer payload.  

The response at the time of analysis was a ZIP file with SHA256 bd36f4c15fe0acb6748da5ed12e45dcc37d412385812c078d1e4f04730e9f69b. Finally, the PowerShell validates ZIP entry paths, extracts the archive in the %APPDATA% directory, and starts "hypersnap.exe" executable without a visible window and creates a scheduled task triggered at user logon. 

The ZIP contains legitimate NetSupport Manager software 

The launched "hypersnap.exe" is a renamed, signed NetSupport Manager 12.44 "client32.exe". The "client32.exe" stub calls the export _NSMClient32@8 in signed "PCICL32.DLL", the main NetSupport client runtime containing the main functionality of the remote access platform.  

The actor-controlled "client32.ini" NetSupport Manager configuration enables silent operation, hides the system-tray interface, disables visible chat, message, disconnect, replay and help controls and configures "paternal-angrily[.]com:443" as the NetSupport HTTP Gateway. 

The client connects to the gateway, which acts as a proxy between the threat actor and the NetSupport Manager client installation at the victim system. The NetSupport client was configured to poll the gateway every 60 seconds. At the time of the analysis the domain resolved to the IP address "212.118.56[.]166", based in Russia.  

The NetSupport deployment used a license issued as KAKAN, with serial number NSM789508. The exact license file has appeared in numerous malicious NetSupport packages, including activity publicly tracked as EVALUSION and IClickFix. We therefore treat it as an indicator of shared deployment lineage rather than a unique threat actor identifier. 

NetSupport adds an operator driven capability after Amatera’s automated collection. Amatera steals configured credentials, session data, cryptocurrency material, and selected files. An unauthorized NetSupport client can then provide screen and input control, file transfer, inventory, process and service management and remote command or PowerShell execution. This could let an operator inspect data outside Amatera’s predefined rules, act on sessions from the original endpoint, or deploy additional tooling.  

Coverage 

The following ClamAV signatures detect and block this threat: 

• Win.Backdoor.BadDav-10060502-0
• Win.Backdoor.GoProxShell-10060503-0
• Win.Malware.AmateraStomper-10060507-0
• Win.Backdoor.BadNetSup-10060508-0
• Js.Downloader.ClickFix-10060510-0

Indicators of compromise (IOCs) 

The IOCs for this threat are also available at our GitHub repository here. 

• Component Object Model (COM) is a fundamental Windows technology used by legitimate applications for object activation, inter-process communication, automation and language-independent component reuse. Those same qualities make it useful to threat actors. 
• Malware frequently uses COM interfaces for lateral movement, execution, download and exfiltration, persistence, evasion, system discovery and automation of built-in Windows and Office functionality. 
• Reverse engineering COM-heavy binaries requires researchers to move from opaque GUIDs and indirect vtable calls to meaningful classes, interfaces and method names.  
• This post is based on research conducted for presentations at AVAR 2025 conference in Kuala Lumpur and a CARO 2026 workshop in Innsbruck.

Component Object Model (COM) is one of the Windows technologies that analysts regularly encounter but may not always prioritize during triage, as the manual analysis of COM functionality in binary executable files can be labor-intensive.

The post starts with a brief introduction into COM, following how binaries utilizing COM can be analyzed, and some examples of malware families and their usage of COM. The post concludes with a list of further resources.  

COM as Windows glue 

COM is an application binary interface (ABI) model for reusing software components. COM objects expose interfaces to client applications, and those interfaces can be consumed by multiple programming languages because the contract exists at the binary interface level rather than at a single language runtime level. COM is a fundamental, principal way for components written in different languages to communicate.  

Microsoft describes COM as a distributed, object-oriented system for creating binary software components that can interact with each other. COM is also the foundation for technologies such as OLE and ActiveX.

This language independence is visible in common scripting and automation patterns. The same COM object may be created from VBScript, PowerShell, Python, or C/C++. For example, a script can instantiate the WScript.Shell COM object and use it to read or write registry values, execute a command, create shortcuts, or access environment variables — and it can do it in a very similar way using different scripting languages supporting COM automation. 

DCOM extends the same model across the network 

Distributed COM (DCOM) extends COM so a client can activate and use COM objects on another system. At a high level, the local client talks to a proxy, the remote server exposes a stub, and the COM runtime transports the method invocation over Microsoft RPC.  

The existence of CoCreateInstanceEx API in a binary, with the appropriate parameters, can be used to distinguish between local COM and DCOM. DCOM extends local COM activation by allowing an object to be associated with a specified remote computer. DCOM is also explicitly represented in MITRE ATT&CK as one of the techniques and is described in Remote Services: Distributed Component Object Model, T1021.003. 

Classes, interfaces, and the registry 

Classes and interfaces are two foundational COM concepts. 

COM classes are templates for creating COM objects. A class is identified by a class identifier (CLSID), a GUID that uniquely identifies the component.

GUID is a 128-bit identifier used to uniquely identify COM-related objects and interfaces. The string representation of a GUID is common in the Windows registry, scripts, and configuration text. It is typically formatted as: 

{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} 

A GUID can also appear as a binary structure in a compiled executable. In a binary, the first three fields are typically stored in little-endian byte order, which is why byte-pattern searches for GUIDs differ from the familiar string form. Readers should be aware that many malware families assemble GUID structure dynamically on the stack before attempting to create a new object in order to make the analysis process harder. 

Interfaces are also represented by interface identifiers (IIDs), which also have the GUID's data type. Interfaces define methods an object exposes to clients. The foundational COM interface is IUnknown, which exposes functions QueryInterface, AddRef, and Release. Every COM interface ultimately derives from it. 

COM registration data is stored in the Windows registry. Classes can be inspected under HKEY_CLASSES_ROOT\CLSID, while interface registrations can be found under HKEY_CLASSES_ROOT\Interface. On a typical Windows installation, the number of registered classes can easily reach into the thousands and changes based on Windows version, optional components, and installed software. 

 A common example used in malware is the Windows Task Scheduler service. The newer Task Scheduler 2.0 COM class is commonly referenced by the CLSID {0F87369F-A4E5-4CFC-BD3E-73E6154572DD}. The ITaskService interface has IID {2FABA4C7-4DA9-4013-9697-20CC3FD40F85} and provides access to the Task Scheduler service for managing registered tasks. ITaskService::Connect should be called before using other ITaskService methods. Older Task Scheduler 1.0 samples may instead use the ITaskScheduler interface, which appears in the WarmCookie case study below. 

A program usually loads a COM class by specifying its CLSID, requests a specific interface by specifying its IID, and receives an interface pointer which points in memory at the beginning of the virtual function table (vtable) for the object. The interface methods are called indirectly through a vtable.  

Without type information, the analyst may only see something like: 

call qword ptr [rax+38h] 

With the correct interface recognized and renamed, the same call can become meaningful, which is our main goal when analyzing malware utilizing COM: 

call qword ptr [pTaskServiceVtbl.Connect] 

Basic COM concepts for reverse engineers 

COM clients, servers, and ProgIDs 

A COM client is any code that obtains a pointer to a COM interface and calls methods through that pointer. A COM server is the component that implements the object behind the interface. The two sides may be in the same process, in different processes on the same host, or on different hosts through DCOM. Malware is most commonly just a COM client. Malicious COM servers are encountered less frequently and are outside of the scope of this blog. 

The client asks the COM runtime, implemented in ole32.dll or combase.dll, to instantiate a class (identified by a CLSID) and to return a specific interface (identified by an IID). The dwClsContext argument supplied to activation APIs such as CoCreateInstance tells COM which server locations are acceptable. For reverse engineers, the CLSCTX flags provide a useful context, as they indicate whether the sample is trying to load a DLL into its own process, talk to a local EXE or service, or reach a remote DCOM server.

 A ProgID, or programmatic identifier, is a human-readable registry entry that can be associated with a COM class. Examples include WScript.Shell, Shell.Application, Excel.Application, MSXML2.XMLHTTP and WinHttp.WinHttpRequest.5.1. The registry maps a ProgID to a CLSID, and higher-level languages often use the ProgID directly through functions such as CreateObject or PowerShell’s New-Object -ComObject. Native code can call CLSIDFromProgID to resolve the string to a CLSID before activation. In binaries, the analyst may therefore see either a readable ProgID string, a string-form GUID, or the little-endian binary representation of the CLSID. 

What CoCreateInstance does for an in-process server 

A typical native COM client starts by initializing the COM runtime for the current thread with CoInitializeEx or CoInitialize. In code that will communicate across process or machine boundaries, the client may also configure process-wide COM security with CoInitializeSecurity. After that, the client activates a class, receives an interface pointer, calls methods through the interface, and releases the pointer when finished. 

For an in-process server, CoCreateInstance is a convenience wrapper around the class-factory path. COM resolves the CLSID registration, locates the in-process server DLL for the current bitness, loads the DLL if necessary, and asks the DLL for a class object. That class object usually implements the interface IClassFactory. COM then asks the class factory to create the object and return the requested interface pointer. 

DllGetClassObject is the main activation export and COM calls it to retrieve a class object for the requested CLSID. DllRegisterServer and DllUnregisterServer are self-registration exports used by installers or regsvr32-style workflows to create or remove registry entries; they are not part of the CoCreateInstance call path. 

 A local-server COM EXE follows the same class-factory idea, but the registration points to an executable or service rather than an in-process DLL. The server process typically registers its class object with the COM runtime, and clients receive an interface proxy when the object lives outside the client process. DCOM extends this model to another machine and adds remote activation, RPC transport, authentication, and impersonation state. 

IUnknown, object identity, and vtable layout 

Every COM interface derives from IUnknown. The first three entries in a COM vtable are QueryInterface, AddRef, and Release, regardless of the higher-level interface being used. QueryInterface lets a client ask whether the object supports another interface identified by an IID. AddRef and Release implement reference counting so that objects can manage their lifetime across language boundaries, DLL boundaries and proxy/stub boundaries without relying on a language-specific garbage collector or destructor model. 

COM activation and call security 

COM has its own security model on top of normal Windows process, token, registry, and file-system checks. Security is most visible for local-server and DCOM objects as activation and method calls cross a COM process or RPC boundary.

Activation security controls whether a client can launch or connect to a COM server. The COM Service Control Manager checks launch and activation permissions when a client requests an out-of-process or DCOM object. These permissions may come from machine defaults or from application-specific AppID configuration such as LaunchPermission. A class can be registered and still fail activation if the caller’s token is not permitted, if remote activation is disabled, if the server is not configured for remote use, or if required marshaling information is unavailable. 

Malware samples that call CoInitializeSecurity or CoSetProxyBlanket are often setting up the identity and authentication context needed for WMI, DCOM, or another out-of-process COM interface. For static analysis, the constants passed to these APIs help identify whether the sample expects local-only access, remote access, impersonation, or delegation. 

Tooling for COM exploration 

The first step in COM analysis is usually identification of classes and interfaces used by malware and understanding interfaces together with functions present in their vtables. Tools such as ComView and OleView.NET allow researchers to inspect classes, interfaces, type libraries, proxy/stub information, and method layouts registered on a system. 

OleView.NET, developed by James Forshaw, is particularly useful since it combines a graphical interface with a PowerShell interface, making it suitable for both manual exploration and repeatable research workflows. 

ComView is an older tool still available through internet archive. ComView contains offsets (in decimal) of a function address from the beginning of the vtable, which allows us to identify which functions are being called in the indirect calls observed in compiled executables. In the ComView screenshot below that displays the details of the ITaskService interface, we see that the connect method has offset 40 (28h) from the start of the vtable so any indirect call to a register + offset 28h after a client obtains a pointer to the interface can be transcribed as ITaskService.Connect to improve our understanding of the code functionality.  

 A manual reversing process would contain the following steps: 

1. Find calls to CoCreateInstance, CoCreateInstanceEx, CLSIDFromProgID, CoGetObject, GetActiveObject, IDispatch::Invoke, or related APIs. 
2. Identify the CLSID and IID values passed into those calls. 
3. Look up the class and interface definitions in the registry, Microsoft documentation, OleView.NET, ComView, or a COM database. 
4. Map indirect vtable calls to interface methods based on architecture and interface layout. 
5. Rename types, variables, and calls in the disassembler so the COM workflow becomes readable. 

For this research, we created a simple task scheduler sample written in C, which uses COM to create a Windows scheduled task that runs notepad.exe two minutes after it is created. To simplify the development, the sample was generated by a large language model (LLM).  

We used our Task Scheduler sample to show how compiled binary code differs from its source code. We then reverse engineered the binary to show that once the ITaskService vtable is reconstructed, calls that initially look like generic indirect calls can be renamed to Connect, NewTask, GetFolder, RegisterTaskDefinition, and related methods.  

A faster way to reach the same analysis stage is to use a plugin for your reverse-engineering tool that maps GUIDs to human-readable code. For example, in IDA Pro, the standard COM Helper can identify relevant class and interface IDs and rename locations in the database.  

The remaining task for the analyst is to add the required interface’s vtable structure to the list of code structures currently in use. For example, for ITaskService, we can add ITaskServiceVtbl to IDA Pro and apply the type wherever an indirect call is related to the instantiated interface pointer.

Still, having a thorough understanding is recommended, so that analysts can recognize calls to COM related functions and identify related indirect calls in a binary.  

Applying the workflow to a Qakbot DLL 

Qakbot, also known as Qbot or Pinkslipbot, is a long-running modular banking trojan that has been active since at least 2007 and evolved into a general-purpose malware delivery platform used by financially motivated actors. Early versions focused on credential theft and online banking fraud, but later campaigns added functionality for system reconnaissance, persistence, browser and credential harvesting, email collection, command execution, command and control (C2) communication, payload delivery, and movement inside enterprise environments. Qakbot was frequently distributed through phishing emails, including hijacked email threads, and was used as an initial access and loader component for follow-on malware and ransomware operations. 

In the Qakbot DLL shown below, CoInitializeSecurity is called before the sample references IID_IWbemLocator, and CoCreateInstance creates an instance of the WMI locator class. The GUID is visible in binary form and can be used for type recovery inside the disassembler.

After the class and interface are identified, the next step is to apply the correct interface type to the returned pointer. In this case, the relevant structure is IWbemLocatorVtbl, and the method of interest is ConnectServer.

 The call through a register and offset maps to IWbemLocator::ConnectServer once the vtable type is applied. 

 Several plugins and scripts can accelerate this process. IDA includes a default COM Helper plugin, and Airbus CERT’s COMIDA and Frank Boldewin’s COM Code Helper scripts are also useful options. Binary Ninja users can apply similar type reconstruction workflows to make interface pointers and vtable calls easier to read. Recent Binary Ninja releases include COMpanion-related data rendering support. 

 For dynamic analysis, tracing can help by observing COM activation and dispatch calls at runtime. DispatchLogger, written by Talos’ David Zimmer, is one example of a DLL that can be injected into a process to proxy and log COM-related calls, including IDispatch usage. Researchers can hook or place breakpoints on COM-related calls to identify which interface is being instantiated. For IDA Pro users, the file “<IDAROOT>\cfg\clsid.cfg“ can be used as a reference to map a GUID. OleView.NET can also be run inside the analysis environment to help with the mapping. Dynamic binary instrumentation frameworks such as DynamoRIO can also be used for runtime tracing of COM behaviors. 

How threat actors use COM and DCOM 

Malicious actors use COM as it provides convenient access to existing Windows functionality and can make static analysis efforts more difficult with the functionality of the sample hidden behind indirect register-based function calls.

The following COM classes and interfaces are useful when triaging samples and building hunting logic.

Hunting for COM interfaces 

Static hunting for COM usage starts with known ProgIDs or GUIDs targeted in a hunt. Some binaries contain ProgID strings such as WScript.Shell, Shell.Application, MSXML2.XMLHTTP or WinHttp.WinHttpRequest.5.1. Others contain binary GUIDs without helpful strings. For hunting, we need to be careful about the on-disk byte order for GUIDs because the first three fields are usually stored little-endian in memory and in binaries. 

For the Task Scheduler CLSID {0F87369F-A4E5-4CFC-BD3E-73E6154572DD}, the corresponding byte pattern is: 

9F 36 87 0F E5 A4 FC 4C BD 3E 73 E6 15 45 72 DD 

For the ITaskService IID {2FABA4C7-4DA9-4013-9697-20CC3FD40F85}, the byte pattern is:

C7 A4 AB 2F A9 4D 13 40 96 97 20 CC 3F D4 0F 85

 A simplified YARA hunting rule for binaries that reference the Task Scheduler COM class and interface might look like: 

 This kind of rule will also find legitimate software, so it typically needs to be tightened with detection names, submission dates, file types, family names, and other context to narrow the output. 

Notable malware families and COM 

Although there are many malware families utilizing COM, the following case studies demonstrate only a few notable malware families and their interaction with COM interfaces. 

Case study 1: Gh0stRAT/SimpleRemoter and Task Scheduler 

Gh0stRAT is a long-lived remote access trojan (RAT) whose source code has been publicly available for years, which has made it a convenient base for modified RAT families and actor-specific forks. MITRE ATT&CK describes Gh0stRAT as a remote access tool with public source code that has been used by multiple groups.  

The COM-relevant part of this example is the scheduled task creation logic in the RAT. The code uses Task Scheduler COM interfaces rather than simply invoking schtasks.exe. In process creation telemetry, the task creation may not appear as a direct schtasks.exe launch visible in EDR telemetry as COM calls run inside the malware process.  

Case study 2: Attor and BITS 

Attor is a Windows-based cyberespionage platform first publicly documented by ESET in 2019, with observed activity dating back to at least 2013. It is a modular implant built around a dispatcher component that manages loadable plugins, allowing operators to tailor functionality per victim. Reported capabilities include screen capture, audio recording, keylogging, clipboard capture, file collection and upload, process/window monitoring, persistence, Tor-based C2 communications, and GSM/GPRS device fingerprinting through AT commands. 

Background Intelligent Transfer Service (BITS) is another COM-exposed Windows service that attackers use, as it provides reliable file transfer functionality and an alternative service for C2 communications that may evade the scrutiny of EDR software.  

The IBackgroundCopyJob interface is used to add files to a job, set priority, determine state, and start or stop transfers. Malware using this interface may perform payload download, staging, or exfiltration through the same background transfer service used by legitimate applications. 

In the example used here, the Attor plugin uses IBackgroundCopyJob to communicate with a C2 server. The same plugin also contains COM exposed functionality for launching VBScript and PowerShell through COM client code, and through use of IWbemClassObject to enumerate installed endpoint security software. 

Case study 3: WarmCookie and Task Scheduler 

WarmCookie, also known as BadSpace, is a malware family that Talos reported as emerging in April 2024 and being distributed through malspam and malvertising. 

The COM-specific part of the workflow is visible in the decompiled function responsible for persistence. WarmCookie initializes COM, creates the older Task Scheduler 1.0 object using CLSID_CTaskScheduler, and requests IID_ITaskScheduler. It then creates a work item, configures flags and creates a trigger. In the screenshot below, the class and interface identifiers appear before the follow-on task and trigger creation calls. 

Conclusion  

COM is an integral part of the Windows programming model. As such, it will remain useful to malware authors wishing to utilize existing cross-platform functionality in Windows. COM is often used to hide malicious functionality behind the vtable based indirect function calls but equally for achieving persistence or moving laterally within victim environments.  

For threat researchers, the important skill is recognizing when a sample is using COM and then translating the evidence like ProgIDs, CLSIDs, IIDs, and vtable offsets into the human-readable name of the Windows component, interface, and method that are being used. 

Analysts in most malware cases do not need to fully master COM to analyze COM-based binary malware. They need enough practical knowledge to identify the client-side workflow, recover interface types, and understand whether the malware is using COM for task creation, WMI access, BITS transfers, shell automation, Office automation, local execution, remote activation, or persistence. 

Tools such as OleView.NET, ComView, IDA’s COM Helper, COMIDA, COM Code Helper, COMpanion plugin, and DispatchLogger can shorten the path from an anonymous indirect call to a meaningful API-level action. 

Further reading and tools 

• Microsoft Learn: Component Object Model (COM) and DCOM Remote Protocol overview 
• Microsoft Learn: COM technical overview and COM clients and servers 
• Microsoft Learn: CoCreateInstance, CoCreateInstanceEx, and CLSIDFromProgID 
• Microsoft Learn: IUnknown, IDispatch, and COM reference counting 
• Microsoft Learn: COM security with CoInitializeSecurity, CoSetProxyBlanket, LaunchPermission, and AccessPermission 
• Microsoft Learn: Task Scheduler ITaskService, legacy ITaskScheduler, and BITS IBackgroundCopyJob 
• Google Project Zero: OleView.NET tooling updates 
• James Forshaw: DCOM Research for Everyone! 
• James Forshaw: COM in Sixty Seconds! (well minutes more likely) 
• Mandiant/Google Cloud: Hunting COM Objects 
• Mandiant/Google Cloud: Hunting COM Objects, Part Two  
• Hex-Rays: COM reverse engineering and COM Helper  
• Malwarebytes Labs: Observing COM within Malicious Code  
• Tools: COM Code Helper, DispatchLogger, COMIDA, ComView