COM hijacking is a persistence technique that manipulates Windows Component Object Model registry entries so legitimate software loads attacker-controlled code. It is effective because it abuses normal operating-system behaviour rather than relying on obviously malicious file names or startup entries.
What COM hijacking is and why it works
COM hijacking is a persistence method, not just a registry tweak. It works because Windows Component Object Model lookups can be redirected through registry entries that applications expect to be trustworthy, so the attacker does not need to replace the target program or drop an obviously suspicious startup file.
This makes the technique attractive for long-lived access on Windows hosts. The malicious code can be loaded when a normal process resolves the COM object, which means execution may occur under the context of a legitimate application and blend into ordinary activity.
Registry abuse and execution flow
At a practical level, COM hijacking depends on registry modification and execution flow abuse. The attacker changes a COM registration path, class identifier association, or related lookup value so the operating system or an application retrieves attacker-controlled code instead of the intended component.
Because the redirection uses native Windows behaviour, the technique often avoids the simple indicators defenders look for in conventional persistence, such as new services, scheduled tasks, or startup folder entries. That is why it is often grouped with other event-triggered execution techniques rather than with noisy malware dropper behaviour.
Detection and exposure review
Exposure review should start with the Windows estate itself: which endpoints and servers allow user-writable registry locations, which software relies on COM activation, and which hosts show unusual changes to COM-related keys. The most useful hunt logic combines registry monitoring, process lineage, and execution context rather than relying on file names alone.
Because the technique is often used in post-compromise persistence, defenders should also review whether registry changes correlate with unfamiliar DLL loads, unusual parent-child process chains, or legitimate applications that begin loading code from unexpected paths. A broad persistence hunt is often the fastest way to surface related abuse patterns, especially when compared with a narrow search for a single known registry value.
Remediation and hardening priorities
Remediation should focus on removing the hijack path, restoring legitimate COM registration, and then checking whether the attacker used the technique to maintain broader access. If the underlying machine is still trusted without review, the same persistence method can be re-established after cleanup.
Hardening is mainly about reducing write access to sensitive registry locations, tightening local administrative exposure, and improving visibility for registry and image-load activity. For defenders who want a broader set of adjacent persistence techniques to compare against, the Persistence Techniques Guide provides useful context, while the T1546 Event Triggered Execution Defensive Guide focuses on COM hijacking alongside other trigger-based persistence methods.
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 NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1546.015 — Event Triggered Execution: COM Hijacking | COM hijacking is an ATT&CK persistence sub-technique under event-triggered execution. |
| Recommendation — Map registry-triggered execution to T1546.015 and hunt for anomalous COM registration changes. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Blocking unauthorized registry changes directly reduces COM hijack persistence opportunities. |
| AU-2 — Event Logging | COM hijacking is best found through registry, process, and code-load audit visibility. | |
| Recommendation — Restrict who can modify COM-related registry entries and validate those changes. Log registry and process events needed to detect suspicious COM registration abuse. | ||
| CIS Controls v8 | CIS-5 — Account Management | Limiting privileged access reduces the ability to alter persistence-related registry paths. |
| CIS-8 — Audit Log Management | Audit visibility is central to identifying registry-backed persistence on Windows hosts. | |
| Recommendation — Limit and review privileged accounts that can change persistence-related registry settings. Centralise and review logs that expose suspicious registry modification and code loading. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org