The Component Object Model (COM), a core Windows technology, is increasingly being leveraged by malicious actors for various stages of cyberattacks, according to recent analysis. While COM is designed for legitimate purposes such as inter-process communication, automation, and code reuse across different programming languages, its inherent capabilities are also attractive to threat actors. Malware authors are utilizing COM for actions including lateral movement within networks, executing malicious code, downloading and exfiltrating data, establishing persistence, evading detection, and automating tasks within Windows and Microsoft Office.
Reverse engineering binaries that heavily rely on COM presents a challenge for security researchers. The process involves deciphering opaque Globally Unique Identifiers (GUIDs) and indirect virtual function table (vtable) calls to understand the underlying classes, interfaces, and methods being used. This complexity can make COM functionality a lower priority during initial malware triage, despite its prevalence.
COM functions as a foundational element for software component interaction in Windows. It enables different programming languages to communicate by defining contracts at the binary interface level. Microsoft describes COM as a distributed, object-oriented system for creating interoperable software components, and it underpins technologies like OLE and ActiveX. This language independence means that a COM object can be instantiated and utilized similarly across various scripting languages, such as VBScript, PowerShell, and Python, as well as compiled languages like C/C++. For instance, scripts can use the WScript.Shell COM object to interact with the registry, execute commands, or access environment variables.
Distributed COM (DCOM) extends this model to enable communication and object activation across network boundaries. In a DCOM interaction, a local client communicates with a proxy, which then interacts with a stub on the remote server. The COM runtime facilitates the transfer of method invocations over Microsoft Remote Procedure Call (RPC). The presence of the `CoCreateInstanceEx` API in a binary, along with specific parameters, can indicate the use of DCOM for remote activation, as opposed to local COM. DCOM is recognized in the MITRE ATT&CK framework under the technique Remote Services: Distributed Component Object Model (T1021.003).
Key to understanding COM are the concepts of classes and interfaces. COM classes serve as blueprints for creating COM objects, each uniquely identified by a Class Identifier (CLSID), which is a GUID. Interfaces, also identified by GUIDs (Interface Identifiers or IIDs), define the methods that a COM object makes available to clients. The fundamental COM interface is `IUnknown`, which provides essential functions like `QueryInterface`, `AddRef`, and `Release`, and all other COM interfaces derive from it.
Information about COM classes and interfaces is stored in the Windows registry, typically under `HKEY_CLASSES_ROOT\CLSID` for classes and `HKEY_CLASSES_ROOT\Interface` for interfaces. The number of registered COM classes on a Windows system can be extensive and varies based on the operating system version, installed components, and third-party software.
A common example of COM usage seen in malware involves the Windows Task Scheduler service. The Task Scheduler 2.0 COM class is often referenced by the CLSID `{0F87369F-A4E5-4CFC-BD3E-73E6154572DD}`, and its associated `ITaskService` interface has the IID `{2FABA4C7-4DA9-4013-9697-20CC3FD40F85}`. This interface allows for the management of registered tasks. Older malware might interact with the Task Scheduler 1.0 service using the `ITaskScheduler` interface.
When a program utilizes COM, it typically initializes the COM runtime, activates a specific class using its CLSID, requests a desired interface using its IID, and receives an interface pointer. Methods are then invoked indirectly through a vtable. Without proper analysis and symbol renaming, these calls may appear as opaque memory dereferences, such as `call qword ptr [rax+38h]`. However, with the correct interface identified, the call can be understood, for example, as `call qword ptr [pTaskServiceVtbl.Connect]`.
In the COM ecosystem, a COM client is any code that uses a COM interface pointer, while a COM server implements the object behind that interface. Malware typically acts as a COM client, interacting with existing COM objects. The COM runtime, found in `ole32.dll` or `combase.dll`, handles the instantiation of classes and the retrieval of interfaces. The `dwClsContext` argument in activation APIs like `CoCreateInstance` provides clues to reverse engineers about whether a sample is attempting to load a DLL into its own process, communicate with a local executable or service, or connect to a remote DCOM server.
Programmatic Identifiers (ProgIDs) offer a human-readable alternative to CLSIDs, such as `WScript.Shell`, `Shell.Application`, or `Excel.Application`. The registry maps ProgIDs to CLSIDs, and higher-level languages often use ProgIDs directly through functions like `CreateObject`. Native code can convert a ProgID to a CLSID using `ClsidFromProgID`. Therefore, analysts might encounter ProgID strings, string-form GUIDs, or the binary representation of CLSIDs within malware.
For in-process COM servers, the `CoCreateInstance` function simplifies the process. After the COM runtime is initialized (using `CoInitializeEx` or `CoInitialize`) and potentially security is configured (`CoInitializeSecurity`), the client activates a class. The COM runtime resolves the CLSID registration, locates the appropriate DLL for the in-process server, loads it if necessary, and then requests a class object from that DLL.
