Transparent COM instrumentation for malware analysis

COM automation is a core Windows technology that allows code to access external functionality through well-defined interfaces. It is similar to traditionally loading a DLL, but is class-based rather than function-based. 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. This creates a key analysis point that many types of malware leverage when interacting with Windows components.This analysis point is quite complex and hard to safely instrumentate at scale.
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 blog describes the architecture, implementation challenges, and practical applications of comprehensive COM automation logging for malware analysis. This technique can be utilized on multiple types of malware.

Malware type	Binding type	Est. coverage
Windows Script Host	Always Late	100%
PowerShell COM	Always Late	100%
AutoIT	Always Late	100%
VBA Macros	Mostly Late	95%
VB6 Malware	Mixed	65%
.NET COM Interop	Mixed	60%
C++ Malware	Rarely Late (WMI)	10%

The challenge

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. Consider this attack pattern:

Transparent COM instrumentation for malware analysis — Figure 1. Sample VBScript code to create a process with WMI as its parent.

Behavioral monitoring will detect process creation, but the analyst often loses critical context such as who launched the process. In this scenario WMI spawns new processes with wmic.exe or wmiprvse.exe as the parent.

Technical approach

Interception strategy

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: Primary COM object instantiation (CreateObject in scripts)
CoGetClassObject: Class factory retrieval
GetActiveObject: Attachment to running COM instances
CoGetObject/MkParseDisplayName: Moniker-based binding (GetObject)
CLSIDFromProgID: ProgID resolution tracking

Why class factory hooking is essential

Initial implementation attempts hooked only CoCreateInstance, filtering for direct IDispatch requests. However, testing revealed that most VBScript CreateObject calls were not being intercepted.

To diagnose this a minimal ActiveX library was created with a MsgBox in Class_Initialize to freeze the process. The VBScript was launched, and a debugger attached to examine the call stack. The following code flow was revealed:

Disassembly of vbscript.dll!GetObjectFromProgID (see Figure 3) confirmed the pattern. VBScript’s internal implementation requests IUnknown first, then queries for IDispatch afterward:

The key line is CreateInstance(NULL, IID_IUnknown, &ppunk). Here, VBScript explicitly requests IUnknown, not IDispatch. This occurs because VBScript needs to perform additional safety checks and interface validation before accessing the IDispatch interface.

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:

The ClassFactoryProxy intercepts CreateInstance calls and handles both cases:

This ensures coverage regardless of which interface the script engine initially requests.

Architecture

Proxy implementation

The DispatchProxy class implements IDispatch by forwarding all calls to the wrapped object while logging parameters, return values, and method names. If the function call returns another object, we test for IDispatch and automatically wrap it.

The proxy is transparent, meaning it implements the same interface, maintains proper reference counting, and handles QueryInterface correctly. Malware cannot detect the proxy through standard COM mechanisms.

Recursive object wrapping

The key capability is automatic recursive wrapping. Every IDispatch object returned from a method call is automatically wrapped before being returned to the malware. This creates a fully instrumented object graph.

Object relationships are tracked:

GetObject("winmgmts:") triggers hook, returns wrapped WMI service object
Calling .ExecQuery() goes through proxy, logs call with SQL parameter
Returned query result object is wrapped automatically
Enumerating with For Each retrieves wrapped IEnumVARIANT
Each enumerated item is wrapped as it’s fetched
Calling .Terminate() on items logs through their respective proxies

Enumerator interception

VBScript/JScript For Each constructs use IEnumVARIANT for iteration. We proxy this interface to wrap objects as they’re enumerated:

Moniker support

VBScript’s GetObject() function uses monikers for binding to objects. We hook CoGetObject and MkParseDisplayName, then wrap returned moniker objects to intercept BindToObject() calls:

This ensures coverage of WMI access and other moniker-based object retrieval.

Implementation details

Interface summary

While standard API hooks can be implemented on a function-by-function basis, COM proxies require implementing all functions of a given interface. The table below details the interfaces and function counts that had to be replicated for this technique to operate.

Interface	Total Methods	Logged	Hooked/Wrapped	Passthrough
IDispatch	7	4	1	2
IEnumVARIANT	7	1	1	5
IClassFactory	5	2	1	2
IMoniker	26	1	1	24

During execution, a script may create dozens or even hundreds of distinct COM objects. For this reason, interface implementations must be class-based and maintain a one-to-one relationship between each proxy instance and the underlying COM object it represents.

While generating this volume of boilerplate code by hand would be daunting, AI-assisted code generation significantly reduced the effort required to implement the complex interface scaffolding.

The real trick with COM interface hooking is object discovery. The initial static API entry points are only the beginning of the mission. Each additional object encountered must be probed, wrapping them recursively to maintain logging.

Thread safety

Multiple threads may create COM objects simultaneously. Proxy tracking uses a critical section to serialize access to the global proxy map:

Reference counting

Proper COM lifetime management is critical. The proxy maintains separate reference counts and forwards QueryInterface calls appropriately:

Output analysis

When script code executes with DispatchLogger active, comprehensive logs are generated. Here are excerpts from an actual analysis session:

Object creation and factory interception:

[CLSIDFromProgID] 'Scripting.FileSystemObject' -> {0D43FE01-F093-11CF-8940-00A0C9054228} 
[CoGetClassObject] FileSystemObject ({0D43FE01-F093-11CF-8940-00A0C9054228}) Context=0x00000015 
[CoGetClassObject] Got IClassFactory for FileSystemObject – WRAPPING! 
[FACTORY] Created factory proxy for FileSystemObject 
[FACTORY] CreateInstance: FileSystemObject requesting Iunknown 
[FACTORY] CreateInstance SUCCESS: Object at 0x03AD42D8 
[FACTORY] Object supports IDispatch – WRAPPING! 
[PROXY] Created proxy #1 for FileSystemObject (Original: 0x03AD42D8) 
[FACTORY] !!! Replaced object with proxy!

Method invocation with recursive object wrapping

[PROXY #1] >>> Invoke: FileSystemObject.GetSpecialFolder (METHOD PROPGET) ArgCount=1 
[PROXY #1] Arg[0]: 2 
[PROXY #1] <<< Result: IDispatch:0x03AD6C14 (HRESULT=0x00000000) 
[PROXY] Created proxy #2 for FileSystemObject.GetSpecialFolder (Original: 0x03AD6C14) 
[PROXY #1] !!! Wrapped returned IDispatch as new proxy 
[PROXY #2] >>> Invoke: FileSystemObject.GetSpecialFolder.Path (METHOD PROPGET) ArgCount=0 
[PROXY #2] <<< Result: "C:UsershomeAppDataLocalTemp" (HRESULT=0x00000000)

WScript.Shell operations

[CLSIDFromProgID] 'WScript.Shell' -> {72C24DD5-D70A-438B-8A42-98424B88AFB8} 
[CoGetClassObject] WScript.Shell ({72C24DD5-D70A-438B-8A42-98424B88AFB8}) Context=0x00000015 
[FACTORY] CreateInstance: WScript.Shell requesting IUnknown 
[PROXY] Created proxy #3 for WScript.Shell (Original: 0x03AD04B0) 
[PROXY #3] >>> Invoke: WScript.Shell.ExpandEnvironmentStrings (METHOD PROPGET) ArgCount=1 
[PROXY #3] Arg[0]: "%WINDIR%" 
[PROXY #3] <<< Result: "C:WINDOWS" (HRESULT=0x00000000)

Dictionary operations

[CLSIDFromProgID] 'Scripting.Dictionary' -> {EE09B103-97E0-11CF-978F-00A02463E06F} 
[PROXY] Created proxy #4 for Scripting.Dictionary (Original: 0x03AD0570) 
[PROXY #4] >>> Invoke: Scripting.Dictionary.Add (METHOD) ArgCount=2 
[PROXY #4] Arg[0]: "test" 
[PROXY #4] Arg[1]: "value" 
[PROXY #4] <<< Result: (void) HRESULT=0x00000000 
[PROXY #4] >>> Invoke: Scripting.Dictionary.Item (METHOD PROPGET) ArgCount=1 
[PROXY #4] Arg[0]: "test" 
[PROXY #4] <<< Result: "value" (HRESULT=0x00000000)

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
Object relationship tracking showing parent-child relationships
Log post processing allows for high fidelity command retrieval

Deployment

DispatchLogger is implemented as a dynamic-link library (DLL) that can be injected into target processes.

Once loaded, the DLL:

Locates debug output window or uses OutputDebugString
Initializes critical sections for thread safety
Hooks COM API functions using inline hooking engine
Begins transparent logging

No modifications to the target script or runtime environment are required.

Advantages over alternative approaches

Approach	Coverage	Semantic visibility	Detection risk
Static analysis	Encrypted/obfuscated scripts missed	No runtime behavior	N/A
API monitoring	Low-level calls only	Missing high-level intent	Medium
Memory forensics	Point-in-time snapshots	No call sequence context	Low
Debugger tracing	Manual breakpoints required	Analyst-driven, labor-intensive	High
DispatchLogger	Complete late bound automation layer	Full semantic context	None

DispatchLogger provides advantages for:

WMI-based attacks: Complete query visibility, object enumeration, method invocation tracking
Living-off-the-land (LOTL) techniques: Office automation abuse, scheduled task manipulation, registry operations
Fileless malware: PowerShell/COM hybrid attacks, script-only payloads
Persistence mechanisms: COM-based autostart mechanisms, WMI event subscriptions
Data exfiltration: Filesystem operations, network object usage, database access via ADODB
Obsfuscation bypass: Working at the COM layer, method names and arguments are already fully resolved

Performance considerations

Proxy overhead is minimal:

Each Invoke call adds one virtual function dispatch.
In the demo, logging I/O occurs via IPC.
Object wrapping is O(1) with hash map lookup.
There is no performance impact on non-COM operations.

In testing with real malware samples, execution time differences were negligible.

Limitations

Current implementation constraints:

IDispatchEx: Not currently implemented (not used by most malware)
IClassFactory2+: Not currently implemented (may impact browser/HTA/WinRT)
Out-of-process COM: DCOM calls require separate injection into server process
Multi-threaded race conditions: Rare edge cases in concurrent object creation
Type library dependencies: Method name resolution requires registered type libraries
Process following: Sample code does not attempt to inject into child processes
64-bit support: 64-bit builds are working but have not been heavily tested

The sample code included with this article is a general purpose tool and proof of concept. It has not been tested at scale and does not attempt to prevent logging escapes.

Operational usage

Typical analysis workflow:

Prepare isolated analysis VM
Inject DispatchLogger into target process
Execute malware sample
Review comprehensive COM interaction log
Identify key objects, methods, and parameters
Extract IOCs and behavioral signatures

The tool has been tested against:

VBScript & Jscript using Windows Script Host (cscript/wscript)
PowerShell scripts
basic tests against .NET and Runtime Callable Wrappers (RCW)
VB6 executables with late bound calls and Get/CreateObject

Background and prior work

The techniques presented in this article emerged from earlier experimentation with IDispatch while developing a JavaScript engine capable of exposing dynamic JavaScript objects as late-bound COM objects. That work required deep control over name resolution, property creation, and IDispatch::Invoke handling. This framework allowed JavaScript objects to be accessed and modified transparently from COM clients.

The experience gained from that effort directly informed the transparent proxying and recursive object wrapping techniques used in DispatchLogger.

Conclusion

DispatchLogger addresses a significant gap in script-based malware analysis by providing deep, semantic-level visibility into COM automation operations. Through transparent proxy interception at the COM instantiation boundary, recursive object wrapping, and comprehensive logging, analysts gain great insight into malware behavior without modifying samples or introducing detection vectors.

The implementation demonstrates that decades-old COM architecture, when properly instrumented, provides powerful analysis capabilities for modern threats. By understanding COM internals and applying transparent proxying patterns, previously opaque script behavior becomes highly observable.

DispatchLogger is being released open source under the Apache license and can be downloaded from the Cisco Talos GitHub page.

Cisco Talos Blog – Read More