Detect it by monitoring registry changes to COM class registrations and looking for suspicious DLL paths, especially in user-writable locations. Compare current COM registrations against a baseline and alert when legitimate objects point to unexpected executables or libraries. Correlate registry edits with new logons, process launches, and persistence-style parent processes to identify hijacked activation paths.
What COM hijacking persistence looks like on Windows
com hijacking persistence works by redirecting a legitimate Component Object Model class to attacker-controlled code. The key signal is not just “a registry change”, but a change that alters which DLL or executable Windows loads when a COM object is activated. On Windows, that means the detection problem is really about spotting unexpected registration state, not just arbitrary registry noise.
Because COM activation is a normal OS mechanism, the most useful detections focus on where the registration points, who changed it, and whether the target path matches the application or system component that should own it. A baseline of known-good registrations gives you the comparison point needed to separate routine software changes from persistence.
For defenders, that also means the high-value cases are often small and easy to miss: a CLSID or related registration that still “looks valid” but now resolves to a file in a user profile, temp directory, downloads folder, or other writable location. That is the pattern that turns a legitimate activation path into a persistence mechanism.
Registry and file-path signals that matter most
The primary detection method is to watch for changes to COM class registrations and the file paths they resolve to. Suspicious cases usually involve CLSID, InprocServer32, LocalServer32, or similar registration points that now reference an unusual DLL, EXE, or script host path. The path is often more important than the key name itself, because the attacker’s goal is to preserve a trusted activation point while swapping the backing binary.
A good detection rule should therefore compare current registrations against a trusted baseline and flag deviations where the referenced binary is not consistent with the expected product, vendor, or system location. That includes registrations that resolve to writable directories, renamed binaries, or libraries that were recently dropped by a less trusted process.
This is also where correlation helps. Registry edits become much more actionable when they occur near new logons, unexpected process launches, or parent processes commonly associated with persistence setup. The combination gives you a chain, rather than a single noisy event, and helps distinguish installation activity from active hijacking.
For a broader persistence baseline, NHIMG’s Persistence Techniques Guide is useful because COM hijacking usually appears alongside other Windows autostart and execution-flow modifications rather than in isolation.
How to distinguish benign COM changes from hijacking
Not every COM registration change is malicious. Software installation, updates, repair routines, and enterprise management tools all modify COM state. The practical question is whether the new registration is consistent with the owning application and whether the file path is where that component should logically live.
Focus on three checks: whether the registration changed recently, whether the target file resides in an unexpected or user-controlled location, and whether the new reference aligns with a legitimate software change window. If those conditions do not line up, the probability of persistence rises quickly, especially when the object is commonly activated by other software or system processes.
It also helps to look for registration drift across multiple hosts. A legitimate enterprise deployment usually affects a predictable set of systems and paths. An isolated change on one endpoint, especially one paired with unusual parent-child process activity, is more consistent with attacker staging than with normal software management.
Risk and Threat Considerations
COM hijacking is dangerous because it abuses trusted Windows activation behavior, so the malicious code can run under the cover of a legitimate object. That makes the persistence durable and the initial execution path harder to notice, especially when the attacker chooses a registration point that is triggered by common applications or user actions.
Failure mechanism: The attacker replaces or redirects a COM registration so future activations load attacker-controlled code instead of the intended DLL or executable. If defenders only monitor process creation or startup folders, the hijack can persist unnoticed because the trigger remains a normal COM call.
Impact: The compromised registration can provide repeated execution, enable follow-on credential theft or lateral movement, and survive reboots until the registration or backing binary is removed. In practice, the persistence often blends into ordinary application behavior unless registry, file-path, and process-activity telemetry are correlated.
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, 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 — Event Triggered Execution | COM hijacking is a persistence form of event-triggered code execution. |
| Recommendation — Map suspicious COM activation paths to T1546 and hunt for registry-based persistence changes. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Security Events | Registry and process correlation depend on continuous monitoring for persistence activity. |
| Recommendation — Monitor registry and process events for unexpected COM registration drift. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Detection depends on retaining and reviewing registry and process evidence over time. |
| Recommendation — Centralize and review endpoint logs for registry edits tied to persistence behavior. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | COM hijacking exploits unnecessary or ungoverned execution paths and file locations. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Correlating registry edits with logons and process launches is an audit analysis task. | |
| Recommendation — Restrict executable locations and remove unneeded COM-activated components. Correlate registry, logon, and process events to identify hijacked COM activations. | ||
Practitioner Guidance
What to verify: Treat the COM registration itself as the object of review. Confirm the CLSID or related entry, the referenced binary path, the file owner, and whether the location is writable by the user or a low-privilege process. If the activation target is outside the normal vendor or system path, escalate it even before you prove execution.
Decision rule: If a COM class points to a file in a user-writable location or to a binary that does not match the expected software inventory, assume persistence risk first and business justification second. Validate whether the registration changed during a known deployment, then decide whether you are seeing abuse or maintenance.
What good looks like: You should have a known-good COM baseline, alerting on registration drift, and host telemetry that ties registry modification to process ancestry and logon context. Identity Threat Detection and Response (ITDR) Guide is useful here because the same correlation logic that exposes identity abuse also helps surface persistence chains built around compromised endpoints and active sessions.
Practitioner takeaway: The most reliable detection is not a single indicator, but a consistency check, legitimate COM registrations should point to expected code in expected places, and persistence usually becomes visible when that relationship breaks.