COM Server Hijacking

What COM Server Hijacking Is

COM Server Hijacking is a Windows persistence and execution-abuse technique that changes how Component Object Model activation resolves a class, so an application launches attacker-controlled code instead of the intended COM server. The abuse usually targets registration data, file paths, or lookup behavior, which makes the technique attractive because it blends into normal Windows component wiring.

For defenders, the important point is that the hijack does not need to replace the application itself. It only needs to influence the component lookup path, which can let malicious code run when a legitimate program or system feature activates the object.

Because this is a Windows-specific abuse pattern, it is best understood as a way to redirect trusted execution flow rather than as a standalone malware family. The security problem is the abuse of trust in registration and activation metadata.

How COM Activation Gets Redirected

COM relies on registration and class lookup to connect callers with the right object implementation. When an attacker can alter that mapping, the system may load a different binary or script handler than the one the application expected. That can happen through registry changes, file replacement, path manipulation, or other hijackable lookup points.

This makes the technique closely related to broader event-triggered execution and persistence tradecraft. NHIMG’s T1546 Event Triggered Execution Defensive Guide covers COM hijacking alongside other activation-based persistence methods, while the Persistence Techniques Guide places it in the wider family of Windows persistence mechanisms.

The practical challenge is that the redirect often looks like normal registration or configuration state until a process activates the object. That means the malicious change may sit dormant until a user session, service, or host component triggers it.

Why It Is Dangerous in Windows Environments

COM Server Hijacking is dangerous because it converts a trusted software dependency into an execution path for hostile code. Once the attacker controls activation, they can piggyback on a legitimate process, inherit its trust context, and potentially reach a wider set of resources than a direct executable launch would allow.

The technique is also attractive for stealth. Activation-based execution can blend with routine application behavior, which makes it harder to distinguish from legitimate component loading unless defenders are watching the relevant registry, file system, and process-creation activity.

For detection and hunting, defenders should treat unusual COM registration changes, unexpected binary paths, and activation from atypical locations as high-signal indicators. Correlating those changes with process lineage and recent administrative activity is often the fastest way to separate legitimate software updates from abuse.

Exposure, Detection, and Remediation

Exposure depends on whether the relevant COM registration surfaces are writable by an attacker, whether the host is monitored for registry and file changes, and whether the application’s activation path can be influenced by user-writable locations. The strongest defensive posture is to know which COM entries matter, where they live, and which processes are allowed to modify them.

When hijacking is suspected, defenders should review the affected registration entries, verify the referenced binaries, and compare them with known-good paths and hashes. Because the technique can be used for persistence, post-remediation review should also check for related autostart mechanisms and any secondary payloads that may have been launched during activation.

Windows telemetry that records registry edits, image loads, and suspicious child processes is especially useful for this technique. Pairing that telemetry with a hardened change-management process makes it easier to tell a legitimate component update from tampering.

Practitioner Guidance

What to watch for: COM hijacking is easiest to miss when teams look only for overt malware files and ignore registration drift. The most useful operational question is whether a COM class now resolves differently than it did before, especially on endpoints where the application behavior has not otherwise changed.

Practitioner takeaway: Treat COM activation paths as part of your execution-control surface, not just configuration data. If you can see who changed the lookup target, you can usually explain, and contain, the abuse much faster.

Related resources from NHI Mgmt Group

• Why does broad user access make BitLocker COM hijacking more dangerous?
• How do you detect COM hijacking persistence on Windows?
• BitLocker Com Hijacking
• COM Server DLL