Description
* 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.
__Figure 1. COM acts as__ __glue__ __between__ __component__ __consumers and__ __component__ __providers written in different languages.__ __Credit__ __for original figure: James Forshaw, Google Project Zero.__
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.
 __Figure 2. As a glue between__ __component__ __consumers and__ __component__ __providers, languages such as VBS, PowerShell and Python can use it to access Windows services.__
## 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.
 __Figure 2. DCOM uses proxy and stub classes with the COM and RPC runtimes to carry method calls between__ __component__ __consumers and providers.__ __Credit for original figure: James Forshaw, Google Project Zero.__
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.
 __Figure 3. COM class information in the registry. The exact classes and interfaces available vary by__ __OS__ __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.
 __Figure 4.__ __ComView__ __showing a COM interface and method layout. This__ __view helps analysts map__ __vtable__ __offsets to method names,__ __as offsets are clearly visible in a specific column. __ __Figure 5. OleView.NET can be used to inspect COM registrations and interface definitions__ __in GUI and PowerShell form. __
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).
 __Figure 6. A simple Windows Scheduled task example is used to show usage of COM servers for the purpose of a manual analysis walkthrough. __
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.
 __Figure 7. IDA Pro analysis of a Task Scheduler COM example. Reconstructing the__ __vtable__ __lets the analyst map indirect calls to method names. __
### 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.
__Figure 8.__ __Qakbot__ __DLL analysis in IDA Pro showing__ __CoInitializeSecurity,__ __IID_IWbemLocator__ __and__ __CLSID_WbemLocator__ __around the__ __CoCreateInstance__ __call. __
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_.
__Figure 9. IDA Pro COM type__ __selection__ __showing__ __IWbemLocatorVtbl.ConnectServer__ __as the function__ __actually used__ __in the indirect call. __
The call through a register and offset maps to `IWbemLocator::ConnectServer` once the vtable type is applied.
 __Figure 10. Once the__ __vtable__ __type is applied, the__ __Qakbot__ __sample resolves to a named__ __IWbemLocatorVtbl.ConnectServer__ __call, making the WMI connection logic explicit. __
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_.
 __Figure 11. Binary Ninja view of COM-related types and__ __vtable__ __usage. __
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.
 __Figure 12.__ __DispatchLogger__ __can__ __assist__ __dynamic analysis by logging Win32 API and COM-related activity__ __of a__ __target process. __
## 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.
 __Figure 13. Hunting for COM interfaces with YARA can pivot on GUIDs,__ __activation__ __APIs,__ __and__ __additional__ __context such as import tables and prevalence. __
## 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.
 __Figure 14. Gh0stRAT/SimpleRemoter__ __code creating a scheduled task through Task Scheduler COM interfaces.__
### 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.
 __Figure 15.__ __Attor-related flow showing BITS use through__ __IBackgroundCopyJob__ __as part of a larger infection and data movement chain. __
### 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.
 __Figure 16.__ __WarmCookie__ __Task Scheduler COM persistence routine showing COM initialization,__ __CoCreateInstance__ __with the older Task Scheduler 1.0__ __CLSID_CTaskScheduler,__ __and__ __IID_ITaskScheduler__ __values, and follow-on task and trigger creation. __
## 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
* 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.
__Figure 1. COM acts as__ __glue__ __between__ __component__ __consumers and__ __component__ __providers written in different languages.__ __Credit__ __for original figure: James Forshaw, Google Project Zero.__
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.
 __Figure 2. As a glue between__ __component__ __consumers and__ __component__ __providers, languages such as VBS, PowerShell and Python can use it to access Windows services.__
## 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.
 __Figure 2. DCOM uses proxy and stub classes with the COM and RPC runtimes to carry method calls between__ __component__ __consumers and providers.__ __Credit for original figure: James Forshaw, Google Project Zero.__
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.
 __Figure 3. COM class information in the registry. The exact classes and interfaces available vary by__ __OS__ __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.
 __Figure 4.__ __ComView__ __showing a COM interface and method layout. This__ __view helps analysts map__ __vtable__ __offsets to method names,__ __as offsets are clearly visible in a specific column. __ __Figure 5. OleView.NET can be used to inspect COM registrations and interface definitions__ __in GUI and PowerShell form. __
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).
 __Figure 6. A simple Windows Scheduled task example is used to show usage of COM servers for the purpose of a manual analysis walkthrough. __
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.
 __Figure 7. IDA Pro analysis of a Task Scheduler COM example. Reconstructing the__ __vtable__ __lets the analyst map indirect calls to method names. __
### 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.
__Figure 8.__ __Qakbot__ __DLL analysis in IDA Pro showing__ __CoInitializeSecurity,__ __IID_IWbemLocator__ __and__ __CLSID_WbemLocator__ __around the__ __CoCreateInstance__ __call. __
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_.
__Figure 9. IDA Pro COM type__ __selection__ __showing__ __IWbemLocatorVtbl.ConnectServer__ __as the function__ __actually used__ __in the indirect call. __
The call through a register and offset maps to `IWbemLocator::ConnectServer` once the vtable type is applied.
 __Figure 10. Once the__ __vtable__ __type is applied, the__ __Qakbot__ __sample resolves to a named__ __IWbemLocatorVtbl.ConnectServer__ __call, making the WMI connection logic explicit. __
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_.
 __Figure 11. Binary Ninja view of COM-related types and__ __vtable__ __usage. __
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.
 __Figure 12.__ __DispatchLogger__ __can__ __assist__ __dynamic analysis by logging Win32 API and COM-related activity__ __of a__ __target process. __
## 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.
 __Figure 13. Hunting for COM interfaces with YARA can pivot on GUIDs,__ __activation__ __APIs,__ __and__ __additional__ __context such as import tables and prevalence. __
## 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.
 __Figure 14. Gh0stRAT/SimpleRemoter__ __code creating a scheduled task through Task Scheduler COM interfaces.__
### 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.
 __Figure 15.__ __Attor-related flow showing BITS use through__ __IBackgroundCopyJob__ __as part of a larger infection and data movement chain. __
### 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.
 __Figure 16.__ __WarmCookie__ __Task Scheduler COM persistence routine showing COM initialization,__ __CoCreateInstance__ __with the older Task Scheduler 1.0__ __CLSID_CTaskScheduler,__ __and__ __IID_ITaskScheduler__ __values, and follow-on task and trigger creation. __
## 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
Basic Information
ID
TALOSBLOG:DF79C7F3B829B007D2B66F9ECF438A07
Published
Jun 25, 2026 at 10:00