COM hijack persistence is a persistence technique that alters Component Object Model registration so Windows loads attacker-controlled code when a COM object is activated. It commonly abuses per-user registry overrides or search order changes, letting malware start at logon or during normal application activity without changing the original executable.
How COM Hijack Persistence Works
COM hijack persistence works by changing how Windows resolves Component Object Model registrations, so a COM activation loads attacker-controlled code instead of the intended component. The technique is attractive because it can ride on normal application behaviour and system startup paths rather than launching a visibly new executable.
That makes it a persistence mechanism rather than a single execution event. The attacker is not always trying to replace the original program binary; instead, they are redirecting a trusted object lookup so the malicious payload is invoked whenever the target COM class is requested.
Why Registry and Activation Details Matter
COM objects are activated through registration data, so small changes in registry placement or lookup order can have outsized impact. In practice, per-user overrides are especially useful to attackers because they can sometimes influence execution without needing to alter machine-wide configuration.
This is why the technique often blends into ordinary software behaviour. The application still appears to start or operate normally, but behind the scenes Windows is resolving the COM object to a different handler. The security problem is less about a noisy implant and more about trust being inherited from a registration path that defenders may not inspect closely.
Where Defenders Usually Miss It
COM hijack persistence is often overlooked when teams focus only on startup folders, services, scheduled tasks or direct autoruns. Because the persistence can sit in registration data and may be triggered during legitimate application activity, it can survive for long periods if registry changes and COM activation paths are not monitored.
It is also a good example of why persistence hunting has to include configuration abuse, not just file-based artefacts. A seemingly minor registry change can become a reliable execution path if the affected COM class is commonly used by the operating system or by frequently launched applications.
Detection and Containment Focus Areas
Detection should centre on unexpected changes to COM registration, unusual per-user overrides, and activation paths that resolve to user-writable locations or non-standard binaries. Correlating those changes with process creation, registry modification, and suspicious parent-child process relationships helps separate benign software registration from abuse.
Response is usually stronger when teams validate the resolved COM target rather than assuming the registered class is safe. If you are mapping the technique to broader identity and persistence abuse patterns, the Identity Threat Detection and Response (ITDR) Guide is useful for the response logic, and Malicious Office Add-ins Guide covers COM as one of the common Office persistence surfaces.
Risk and Threat Considerations
COM hijack persistence matters because it can turn a trusted Windows activation mechanism into a durable launch point for malware. The main risk is stealth, since the malicious code may execute through legitimate application flows and survive routine cleanup that only checks obvious autorun locations.
Failure mechanism: An attacker alters COM registration or lookup precedence so the system loads attacker-controlled code when a class is activated, creating a persistent execution path tied to normal user or application activity.
Impact: The compromise can persist across logons, support repeated payload execution, and provide a stable foothold for follow-on credential theft, lateral movement, or post-compromise staging.
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, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1546.015 — Component Object Model Hijacking | This technique is the ATT&CK persistence sub-technique for COM hijacking. |
| Recommendation — Map suspicious COM registration changes to T1546.015 and hunt for persistence paths in registry telemetry. | ||
| CIS Controls v8 | CIS-5 — Account Management | COM hijack persistence often relies on user-context execution and persisted access paths. |
| Recommendation — Review account and user-context persistence paths that can keep attacker-controlled code running. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Restricting unnecessary software and execution paths reduces abuse of COM registration for persistence. |
| AU-2 — Event Logging | Detection depends on visibility into registry changes and activation-related events. | |
| Recommendation — Limit unnecessary COM-enabled software and execution paths that can be repurposed for persistence. Log registry and process events that reveal COM registration abuse and suspicious activation. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | COM hijacking is best found by continuous monitoring of unexpected registry and process activity. |
| Recommendation — Monitor endpoint configuration and process activity for anomalous COM registration changes. | ||
Practitioner Guidance
What to watch for: Investigate COM registrations that point to unusual file paths, per-user registry locations, or components that do not match the expected software owner. Pay particular attention when the change appears shortly before repeated execution of the same payload or when benign-looking applications begin launching unfamiliar DLLs or handlers.
Governance implication: Treat COM registration changes as a persistence-control surface, not just a software-compatibility issue. That means registry monitoring, change review, and investigation playbooks should explicitly cover COM activation paths and user-level overrides, especially on endpoints that handle sensitive administrative activity.
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 October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org