Security teams can detect COM hijacking by looking for suspicious registry changes that redirect COM class lookups to attacker-controlled binaries, followed by unexpected process launches. Monitor persistence locations for new or altered COM entries, especially when a legitimate application starts loading a DLL from an unusual path or after a recent install is absent.
What COM Hijacking Detection Is Actually Looking For
COM hijacking detection is about spotting when a Windows application is steered to the wrong component through the registry rather than loading the expected COM object. The practical signal is a mismatch between what the system should resolve and what it actually loads: new or altered COM registration, unusual DLL paths, and process starts that do not fit the application’s normal execution pattern.
Because COM resolution is often silent, defenders usually need to correlate registry activity with execution behavior. A registry change alone can be benign, but a change followed by an uncommon parent-child process chain, an unexpected module load, or a program launch after installation activity is a much stronger indicator of tampering.
Where to Look in Telemetry and Endpoints
The most useful detection path is to watch persistence-sensitive registry locations for COM-related writes, then validate whether the referenced binary or DLL is legitimate for that host. The value is in pairing registry visibility with process creation, module load telemetry, and command-line context so you can distinguish normal COM use from redirection to attacker-controlled code. NHI Management Group’s Persistence Techniques Guide is a useful map for this broader class of startup and execution hijacks.
Endpoint hunting is more reliable when it includes image path anomalies, signed-versus-unsigned module checks, and whether the supposed COM server appears in a user-writable or otherwise unusual directory. If a COM registration points to a binary path that does not match the software inventory, or the binary appears without a corresponding deployment event, that deserves immediate review.
How to Separate Noise from Real Hijacking
Not every COM registry modification is malicious, so the key is to validate intent and timing. Legitimate software installers can register COM objects, but they normally do so in a way that lines up with change windows, vendor files, and expected installation artifacts. COM hijacking becomes more credible when the registry entry changes outside a maintenance cycle, points to a location inconsistent with the product, or is followed by execution from a path that should never host a trusted component.
Correlate the suspicious COM entry with nearby persistence and execution techniques, because attackers often combine them. A suspicious COM redirect that also sits beside autorun changes, service modification, or other startup abuse is far more likely to be part of a broader persistence chain than an isolated configuration oddity. The same analysis pattern applies to related startup abuse, which is why defenders often compare it with other persistence families and adjacent execution hijacks.
Risk and Threat Considerations
COM hijacking is dangerous because it abuses trusted Windows behavior, which means the malicious component can launch under the cover of a legitimate application and evade simple allowlisting. The most common failure mode is treating the registry as configuration only, without validating whether it now redirects execution to an untrusted binary or a path that normal software would never use.
Failure mechanism: An attacker alters COM registration or class resolution so the system loads attacker-controlled code during a normal application or shell action, turning a trusted lookup into persistence or code execution.
Impact: This can produce stealthy persistence, unexpected process execution, and a foothold that is hard to spot if defenders watch only for obvious autoruns or service creation.
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 CSF 2.0 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 models the persistence technique this question is about. |
| Recommendation — Map suspicious COM registry writes and follow-on execution to T1546.015 in your hunting rules. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | COM hijacking detection depends on endpoint and registry anomaly monitoring. |
| Recommendation — Correlate registry changes with process and module-load anomalies for COM hijacking detection. | ||
| NIST SP 800-53 Rev 5 | SI-4 — System Monitoring | Endpoint telemetry and alerting are central to finding COM hijacking activity. |
| CM-7 — Least Functionality | Reducing unnecessary startup and execution paths limits hijack opportunities. | |
| Recommendation — Monitor registry and process activity for suspicious COM redirection and unexpected execution. Remove unneeded COM registration paths and restrict writable persistence locations. | ||
Practitioner Guidance
What to verify: Confirm whether the COM entry maps to a known product, a valid installation path, and a recent change record. If those three do not line up, treat the registry write as suspicious until proven otherwise.
Common mistake: Teams often alert on the registry change but stop short of validating what executed afterward. For COM hijacking, the follow-on process and module-load evidence is what turns a weak signal into a defensible detection.
Practitioner takeaway: The best detections pair registry monitoring with execution telemetry, because COM hijacking is fundamentally a trust-abuse problem, not just a registry anomaly.