How do attackers use Component Object Model Hijacking?

How COM hijacking turns trust into execution

component object model hijacking works because many Windows applications and shell extensions resolve COM objects through registry registrations rather than through a hardcoded, verifiable path. If an attacker can change the registration or redirect the referenced DLL, the legitimate process can be made to load attacker-controlled code while still looking normal to operators and endpoint telemetry.

The technique is effective precisely because the victim process is often trusted. That means the malicious code inherits the context of a real application, which can reduce suspicion, blend into normal startup activity, and make initial detection harder than with a clearly malicious executable.

In practice, the security boundary is the registration data, not the process name. That makes registry integrity, DLL path integrity, and change visibility central to both prevention and detection. A COM hijack can also survive reboots if the altered registration remains in place, so it behaves more like a persistence mechanism than a one-time injection.

Where attackers place the hijack and why it survives

Attackers usually target registrations that are likely to be loaded automatically by common user activity, startup paths, or shell integration. The goal is not to replace the whole application, but to place malicious code in a loading path that the application already trusts and will execute on its own.

The most useful places are the ones defenders check least often, especially registrations that look routine, reside in unusual hive locations, or point to DLLs outside the expected program directory. A successful hijack can remain dormant until the associated COM object is invoked, which is why it may be missed during basic startup review.

This is one reason COM hijacking often overlaps with broader persistence tradecraft. The attack is durable when the attacker can preserve the altered registration, and it is stealthier when the registered object belongs to software that normally runs with user interaction rather than as an obvious service.

What defenders should verify first

Start with a baseline of COM registrations that are normal for your environment, then compare current registry state against that baseline. Focus on new entries, modified DLL paths, and registrations that point into temporary, user-writable, or otherwise unexpected locations. The highest-value question is not just whether a COM entry exists, but whether it resolves to a location that your software inventory can justify.

Investigation should also include the parent application that loads the COM object. If the host process is legitimate but the loaded module is not, the compromise often sits in the registration chain rather than in the executable itself. That is why module load visibility and registry change auditing matter together.

For attack-path context and adjacent persistence patterns, the Persistence Techniques Guide is the best place to compare COM hijacking with other autostart methods, and the Lateral Movement Guide helps when COM abuse is part of a broader post-compromise campaign.

Risk and Threat Considerations

COM hijacking is risky because it converts a trusted Windows loading mechanism into a covert execution path. The same mechanism that lets software discover components dynamically can let an attacker preserve persistence, hide inside normal application activity, and execute code under a trusted process name.

Failure mechanism: The defender assumes the application binary is the main trust anchor, but the attacker changes the registration or DLL target that the binary loads at runtime. That breaks the assumption that a legitimate host process implies legitimate code.

Impact: The attacker can gain durable code execution, evade casual inspection, and retain access across reboots as long as the altered registration remains in place. That can create a quiet foothold for follow-on actions such as credential theft, additional persistence, or staged payload delivery.

Practitioner Guidance

What to verify: Confirm which COM registrations are expected on each endpoint class, then flag any registration that resolves to a writable user path, an odd hive location, or a DLL that does not match your software baseline. Treat unknown COM entries as suspicious even when the host process itself looks normal.

Decision rule: If the hijacked registration points to a production system path or a load path that is broadly trusted by the application, prioritize containment and registry rollback before spending time proving active abuse. If the change is in a low-risk test context, validate ownership and software inventory first, then decide whether to restore or remove the entry.

Practitioner takeaway: The key control is not just detecting malicious files, it is protecting the registration metadata that tells trusted software what to load.

Related resources from NHI Mgmt Group

• How do attackers use the Component Object Model?
• How do attackers use distributed component object model?
• Why do attackers often check model availability before trying to generate content?
• Component Object Model Hijacking