Component Object Model Hijacking is a persistence or execution technique in which a malicious COM component is registered or substituted so Windows loads attacker-controlled code. It is often used to survive reboot and hijack trusted processes. Defenders should check COM registration changes, suspicious CLSID use, and writable registry or file paths.
What Component Object Model hijacking means in practice
component object model hijacking is a Windows persistence and execution technique. An attacker abuses COM registration so the operating system loads attacker-controlled code through a trusted interface, which makes the technique useful for surviving reboot and blending into normal process activity.
The danger is not just that code runs, but that it runs through an object activation path Windows expects to be legitimate. That means defenders often have to distinguish malicious registration changes from ordinary software installation, updates, or application repair activity.
Why COM hijacking is effective for persistence
COM is designed to let applications request functionality by class identifier and registry-based activation data, rather than by directly loading an explicit file path. When an attacker can replace or redirect that registration, they can influence what code a trusted process loads without changing the parent process itself. That makes the technique attractive for persistence, because the malicious component can be invoked repeatedly when the associated COM class is used.
This technique commonly overlaps with other Windows persistence tradecraft. NHIMG’s Persistence Techniques Guide covers COM hijacking alongside run keys, services, WMI subscriptions, and other autostart mechanisms that defenders should consider together rather than in isolation.
How organisations identify exposure
Exposure assessment starts with inventory. Organisations need to know which COM classes are registered, which registry paths are writable by non-admin users, and whether any application or administrator workflow creates an opportunity for malicious substitution. That review is especially important on systems where multiple applications rely on shared COM objects.
Detection also benefits from correlation. Suspicious CLSID changes, new or modified InprocServer32 values, unexpected file writes in COM-related locations, and unusual loads by trusted processes all help separate legitimate software maintenance from abuse. NHIMG’s Lateral Movement Guide is useful here because COM-based execution often sits next to other Windows tradecraft that defenders already hunt for across endpoints.
Remediation and validation after suspected abuse
When COM hijacking is suspected, remediation is more than removing a file. Teams need to restore the intended registration, verify that the legitimate component is in place, and confirm that the underlying registry or filesystem permissions were not left writable. If the attacker achieved execution, the system may also need a broader compromise review because the technique can be used to drop additional payloads or establish follow-on persistence.
Post-remediation validation should check that the malicious class registration cannot be recreated easily and that affected endpoints no longer load unexpected code paths. Where the affected COM object supports privileged or service-side functionality, the review should also include any credentials, tokens, or other identity material that may have been exposed during the intrusion.
Risk and Threat Considerations
COM hijacking is risky because it turns a normal Windows extensibility feature into a persistence surface. The same trust that helps applications discover components can also help an attacker hide execution inside routine object loading, which makes the technique resilient and difficult to spot with file-based checks alone.
Failure mechanism: A writable registry key, writable component path, or overly permissive deployment process lets an attacker substitute a malicious COM registration or server, so trusted software resolves the attacker’s code instead of the intended component.
Impact: The attacker can gain durable execution, survive reboot, and potentially execute inside trusted processes, increasing the chance of follow-on credential theft, defence evasion, and additional persistence.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1546.015 — Component Object Model Hijacking | Directly defines this Windows persistence technique. |
| Recommendation — Hunt for CLSID and COM registration changes tied to T1546.015. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports limiting who can alter local configuration and persistence-related settings. |
| Recommendation — Restrict and review privileges that allow COM registration changes. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Applies to controlling and monitoring Windows configuration and registry-based activation paths. |
| AC-6 — Least Privilege | Limits which users and processes can write persistence-enabling locations. | |
| Recommendation — Baseline and monitor COM-related registry settings for unauthorized changes. Remove unnecessary write access to COM registration and component paths. | ||
Practitioner Guidance
What to watch for: Treat new or changed CLSID registrations, unexpected COM server paths, and registry writes by low-privilege users as high-value signals. Those changes are often the earliest indicator that a system has been prepared for persistent execution.
Practitioner takeaway: The most effective control is to reduce who can modify COM registration and to continuously watch the registry and file locations that determine COM activation.