COM Hijacking

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.

Expanded Definition

COM hijacking is a Windows persistence and execution technique that abuses Component Object Model registration so a trusted application loads attacker-controlled code. In NHI security terms, it matters because the technique can be used to extend access after initial compromise, especially when a service account, scheduled job, or automation host has broad system rights.

The mechanism is subtle: the attacker does not need to replace the parent application, only influence how Windows resolves a COM class, server path, or handler. That makes detection harder than with obvious startup entries or dropped binaries. The relevant security controls are usually discussed under registry integrity, application control, and endpoint hardening in NIST SP 800-53 Rev 5 Security and Privacy Controls, though no single standard uses the term COM hijacking as a standalone control objective.

Definitions vary across vendors, because some treat it as a persistence mechanism while others classify it under living-off-the-land tradecraft. The most common misapplication is assuming only malicious files are risky, which occurs when teams ignore registry-based execution paths that legitimate software reads during normal startup.

Examples and Use Cases

Implementing defenses against COM hijacking rigorously often introduces monitoring overhead, requiring organisations to balance registry visibility and software compatibility against operational noise.

• Attackers alter a COM class registration so a signed business application launches a malicious DLL during normal startup.
• A compromised admin workstation modifies per-user registry entries, allowing code execution without touching global startup folders.
• Red teams simulate COM hijacking to test whether endpoint detection can catch registry changes tied to high-value automation accounts.
• Security teams compare suspicious COM registration changes against the baseline guidance in the Ultimate Guide to NHIs when service accounts show unexpected post-login behaviour.
• Windows hardening programs map registry auditing and control validation to NIST SP 800-53 Rev 5 Security and Privacy Controls to detect unauthorised COM activation paths.

For NHI operators, the practical use case is often not the endpoint itself but the identity behind the endpoint: a hijacked COM path can inherit the privileges of a workload, browser helper, or scheduled automation process.

Why It Matters in NHI Security

COM hijacking is important because it turns trusted Windows behaviour into a persistence layer that can outlive password resets, token revocation, and routine file cleanup. That is especially dangerous in NHI environments where service accounts, automation agents, and API-facing workloads often have excessive permissions. NHI Mgmt Group notes that Ultimate Guide to NHIs reports 97% of NHIs carry excessive privileges, which means a hijacked execution path can amplify a small foothold into broad lateral movement.

Because the technique blends into normal OS activity, it can bypass teams that focus only on secret theft or credential stuffing. Once a COM entry is changed, the resulting execution may appear legitimate unless registry baselines, application allowlists, and identity telemetry are correlated. This is why COM hijacking should be treated as both an endpoint integrity issue and an identity governance issue, not just a malware problem. Organisations typically encounter the operational impact only after a service account is abused for persistence, at which point COM hijacking becomes unavoidable to investigate and contain.

Related resources from NHI Mgmt Group

• BitLocker Com Hijacking
• How can security teams reduce the risk of session hijacking in SaaS environments?
• Why does MFA not stop session hijacking?
• What is the difference between credential theft and session hijacking?