Transparent COM Instrumentation for Malware Analysis
Transparent COM Instrumentation for Malware Analysis
Published on: March 18, 2026
Source: Talos Blog
COM automation is a core Windows technology that allows code to access external functionality through well-defined interfaces. Many advanced Windows capabilities are exposed through COM, such as Windows Management Instrumentation (WMI). Scripting and late-bound COM calls operate through the IDispatch interface, creating a key analysis point that many types of malware leverage when interacting with Windows components. In this article, Cisco Talos presents DispatchLogger, a new open-source tool that closes this gap by delivering high visibility into late-bound IDispatch COM object interactions via transparent proxy interception. This technique can be utilized on multiple types of malware, including Windows Script Host, PowerShell COM, AutoIT, and VBA Macros, with high coverage.
Modern script-based malware (e.g., VBScript, JScript, PowerShell) relies heavily on COM automation to perform malicious operations. Traditional dynamic analysis tools capture low-level API calls but miss the semantic meaning of high-level COM interactions. Behavioral monitoring will detect process creation, but the analyst often loses critical context such as who launched the process. DispatchLogger starts with API hooking at the COM instantiation boundary. Every COM object creation in Windows flows through a small set of API functions. By intercepting these functions and returning transparent proxies, deep visibility can be achieved without modifying malware behavior. The core API hooking targets are: CoCreateInstance, CoGetClassObject, GetActiveObject, CoGetObject/MkParseDisplayName, and CLSIDFromProgID.
Initial implementation attempts hooked only CoCreateInstance, filtering for direct IDispatch requests. However, testing revealed that most VBScript CreateObject calls were not being intercepted because VBScript explicitly requests IUnknown, not IDispatch. If we only wrap objects when IDispatch is directly requested in CoCreateInstance, we miss the majority of script instantiations. The solution is to also hook CoGetClassObject and wrap the returned IClassFactory. This ensures coverage regardless of which interface the script engine initially requests.
The DispatchProxy class implements IDispatch by forwarding all calls to the wrapped object while logging parameters, return values, and method names. The key capability is automatic recursive wrapping; every IDispatch object returned from a method call is automatically wrapped before being returned to the malware, creating a fully instrumented object graph. Malware cannot detect the proxy through standard COM mechanisms. Additionally, VBScript’s GetObject() function uses monikers for binding to objects. DispatchLogger hooks CoGetObject and MkParseDisplayName, then wraps returned moniker objects to intercept BindToObject() calls, ensuring coverage of WMI access and other moniker-based object retrieval.
When script code executes with DispatchLogger active, comprehensive logs are generated. For example, output shows object creation and factory interception like ‘[CLSIDFromProgID] ‘Scripting.FileSystemObject’ -> {0D43FE01-F093-11CF-8940-00A0C9054228}’ and method invocation like ‘[PROXY #1] »> Invoke: FileSystemObject.GetSpecialFolder (METHOD PROPGET) ArgCount=1’. This output provides: Complete object instantiation audit trail with CLSIDs, all method invocations with method names resolved via ITypeInfo, full parameter capture including strings, numbers, and object references, return value logging including nested objects, and object relationship tracking showing parent-child relationships. DispatchLogger is implemented as a dynamic-link library (DLL) that can be injected into target processes, and no modifications to the target script or runtime environment are required.