Mitigate this by protecting COM-related registry settings and startup locations from unauthorised changes. Monitor for new or altered COM registrations, restrict write access to sensitive registry and file paths, and use application control to block untrusted code loading. Attackers hijack COM entries to persist, execute code, or redirect legitimate processes.
How to harden the COM surfaces that hijackers abuse
component object model hijacking becomes practical when an attacker can alter the registration data or file paths that Windows uses to resolve a COM object. The core defensive move is to make those resolution points hard to change: protect registry keys, treat startup-related locations as sensitive, and prevent low-trust write access from reaching the paths that drive COM activation.
In practice, that means reviewing which users, services, and software update processes can write to COM registration areas and related startup locations, then tightening those permissions where they are broader than necessary. If a process can modify the lookup path, it can often redirect execution without replacing the parent application itself.
Use Persistence Techniques Guide as the broader reference point for registry-based persistence, because COM hijacking is one of several startup and execution-flow techniques that depend on the same control weakness.
What to monitor so COM hijacking is visible early
Detection should focus on changes, not just payloads. Monitor for new or altered COM registrations, unexpected CLSID or handler changes, and registry edits in locations that normally remain stable on production endpoints. A hijack often starts as a configuration change long before it becomes an obvious malicious process.
It is also worth correlating registry change telemetry with the process that made the change and with the next process that consumes it. That helps separate legitimate software installation activity from a registration change that is meant to trigger code execution or persistence. File integrity monitoring on the associated DLL or binary paths adds another layer of confidence when a COM entry points to a newly dropped component.
For defenders who need to understand how this fits into a broader post-compromise pattern, Lateral Movement Guide is useful because COM-related abuse is often paired with adjacent Windows tradecraft such as remote execution, living-off-the-land activity, and follow-on access expansion.
How to contain execution without breaking legitimate software
Application control is the most important compensating control when you cannot fully eliminate the hijack path. Block untrusted code loading, especially from user-writable directories, temporary locations, and other paths that should never host production COM payloads. Where possible, allow only signed or otherwise approved binaries to load into sensitive application contexts.
That control works best when paired with constrained write permissions on registry and filesystem locations that influence COM resolution. If attackers can both register a malicious object and place the backing binary where the application can load it, they can turn a configuration weakness into execution. Restricting either side helps, but restricting both sharply reduces the blast radius.
For teams that need a general detection and control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful anchor for configuration management, access control, and integrity monitoring expectations.
Risk and Threat Considerations
COM hijacking is attractive because it abuses trusted Windows behavior rather than forcing a noisy exploit. A successful change can create persistence, execute code under a legitimate process, or redirect a normal workflow into attacker-controlled code, which makes the technique useful both for initial foothold retention and for post-compromise staging.
Failure mechanism: The attacker gains write access to a COM registration point, startup location, or associated binary path, then substitutes or redirects the object that Windows or an application expects to load.
Impact: The hijack can survive restarts, blend into ordinary system activity, and give the attacker execution through a trusted process path, which increases both stealth and recovery effort.
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 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 registry-based execution-flow persistence technique. |
| Recommendation — Map COM registration changes to T1546 and alert on abnormal event-triggered execution. | ||
| CIS Controls v8 | CIS-5 — Account Management | Restricting who can change COM-related settings depends on tight account and write-access control. |
| Recommendation — Limit privileged write access to COM-related registry and startup locations. | ||
| NIST SP 800-53 Rev 5 | CM-7 — Least Functionality | Blocking untrusted code loading and unnecessary COM paths aligns with minimizing executable surface. |
| SI-7 — Software, Firmware, and Information Integrity | Monitoring altered registrations and blocking untrusted binaries directly supports integrity protection. | |
| Recommendation — Remove unnecessary COM entries and deny execution paths that are not required. Detect and block unauthorized changes to COM registrations and backing files. | ||
Practitioner Guidance
What to verify: Confirm which registry keys, handler registrations, and startup-adjacent paths are actually required by approved software, then remove write access everywhere else. The common mistake is allowing broad admin-equivalent writes to remain in place because the setting is “part of Windows.”
Decision rule: If a COM registration can be changed by a user, service account, or updater that does not own the application, treat it as a persistence risk and tighten the control before relying on detection alone. If business constraints prevent that, treat monitoring and application control as compensating measures, not substitutes.
Practitioner takeaway: The best mitigation is to make COM resolution hard to tamper with, then assume attackers will try to exploit whatever registry or path trust remains.