DET0481: Windows COM Hijacking Detection via Registry and DLL Load Correlation
This detection strategy matters because COM hijacking is a Windows persistence and privilege-escalation behavior: changes to COM-related Registry reference...
Analyst context for executives and security teams
This detection strategy matters because COM hijacking is a Windows persistence and privilege-escalation behavior: changes to COM-related Registry references can cause malicious DLLs or content to run when legitimate software interacts with those COM objects. The value is not just finding a Registry edit or a DLL load in isolation, but correlating the two so defenders can distinguish suspicious execution paths from normal Windows and application behavior.
Executive priority
Prioritize this as a resilience and incident-readiness control for Windows environments where persistence and privilege escalation would materially affect recovery time, privileged access integrity, or audit confidence. Leaders should ask whether SOC and IR teams can prove collection of both Registry modification evidence and DLL load/process execution evidence, and whether those data sources are retained long enough to reconstruct when a COM reference was changed and what subsequently executed.
Technical view
DET0481 is a detection strategy for T1546.015, Component Object Model Hijacking. The supplied ATT&CK relationship ties it to Windows and the privilege-escalation and persistence tactics. Detection engineering should validate correlation between COM-related Registry changes and later DLL loads or process activity that uses the altered COM reference. IR playbooks should treat suspicious correlation as a persistence investigation path: identify the modified Registry key/value, the loading process, the DLL path, signer or trust context if available locally, timing, user context, and whether the change aligns with legitimate software installation or update activity.
Likely telemetry
- Windows Registry change events for COM-related locations and values
- DLL/image load telemetry from endpoint sensors or Windows logging where available
- Process creation and parent-child process context around the DLL load
- User, host, and timestamp context for Registry modification and subsequent execution
- File metadata for referenced DLLs, such as path and local trust/signature information where collected
Detection direction
- Validate that Registry monitoring covers COM-related persistence locations; absence of this data will make the strategy weak even if process telemetry is strong.
- Correlate Registry modification time, modifying principal/process, referenced DLL path, and subsequent DLL load rather than alerting only on a single Registry write.
- Tune for legitimate installers, application updates, and administrative software changes, which can create noisy Registry and DLL activity.
- Prioritize suspicious cases involving unusual DLL paths, unexpected user-writable locations, uncommon loading processes, or changes followed by execution under privileged or business-critical processes, if those attributes are available in local telemetry.
- Use the relationship to T1546.015 to connect alerts to persistence and privilege-escalation triage rather than treating them as generic Registry events.
Mitigation priorities
- First, confirm visibility: Registry change collection and DLL load/process telemetry must be available and retained for Windows systems in scope.
- Next, harden change control around software installation, privileged administration, and endpoint configuration so legitimate COM changes are explainable during triage.
- Then, ensure IR procedures include containment and persistence review steps for suspected COM hijacking, including validation of modified COM references and loaded DLLs.
- Finally, use findings to improve audit evidence: demonstrate monitored data sources, correlation logic, triage criteria, and documented exceptions for approved software behavior.
Analyst notes and limits
The ATT&CK object is a detection strategy named “Windows COM Hijacking Detection via Registry and DLL Load Correlation” and is linked to T1546.015, Component Object Model Hijacking. The practical defensive takeaway is that correlation is the deciding factor: Registry-only or DLL-load-only monitoring can miss context or generate excessive noise.
The supplied object has no official description, no official detection text, no tactics listed on the detection strategy itself, and no platforms listed on the detection strategy itself. Windows, persistence, and privilege-escalation context come from the supplied relationship to T1546.015. Local environment baselines, logging configuration, retention, and approved software behavior are required to judge coverage and alert quality.
Windows COM Hijacking Detection via Registry and DLL Load Correlation
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1546.015 | Component Object Model Hijacking Sub-technique | This object detects Component Object Model Hijacking. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | ab9fa2318ef5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0481Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.