DET0224: Detect Abuse of Component Object Model (T1559.001)
DET0224 is a MITRE detection strategy for identifying abuse of Windows Component Object Model behavior associated with ATT&CK technique T1559.001. The busi...
Analyst context for executives and security teams
DET0224 is a MITRE detection strategy for identifying abuse of Windows Component Object Model behavior associated with ATT&CK technique T1559.001. The business value is that COM can provide local code execution through normal Windows inter-process communication, so the defensive question is not simply “is COM present,” but whether teams can distinguish expected software object interaction from suspicious execution paths involving COM server DLLs or executables.
Executive priority
Prioritize this as a Windows execution visibility and incident readiness issue. Leaders should ask whether SOC and IR teams have enough endpoint evidence to explain local code execution paths that involve COM, especially when investigating suspicious process activity. Because the supplied detection strategy has no official detection text or platform field of its own, investment decisions should be based on validating telemetry coverage for the related Windows technique rather than assuming a packaged detection exists.
Technical view
This detection strategy detects T1559.001, Component Object Model, which is tied to the execution tactic on Windows. SOC and detection teams should validate whether endpoint telemetry can show when software objects interact through COM and when COM server components execute as DLLs or EXEs. Detection engineering should focus on behavior and context around local code execution, including process lineage, loaded modules or launched executables, and unusual execution chains involving COM-related activity where such telemetry is available.
Likely telemetry
- Windows endpoint process creation and parent-child process relationships
- Executable launch evidence for COM server processes where observable
- DLL load or module telemetry for COM server DLL execution where observable
- Endpoint detection and response records that expose local inter-process communication or COM-related execution context
- Incident response endpoint triage artifacts showing execution timelines and process/module relationships
Detection direction
- Confirm that detections are scoped to the related technique T1559.001 rather than to the detection strategy object alone, because no official detection logic is supplied for DET0224.
- Validate visibility on Windows execution paths involving COM server DLLs and EXEs, since the related technique description identifies these as common COM server forms.
- Tune for context: COM is a native Windows API capability and may be heavily used by legitimate software, so detections should emphasize unusual process lineage, execution context, and investigation-enabling evidence rather than broad COM usage alone.
- Assess blind spots where endpoint tools do not capture module loads, process lineage, or COM/IPC context; these gaps can make COM-based execution difficult to explain during incident response.
- Use relationship-driven context: treat alerts as execution-focused Windows activity linked to T1559.001, not as evidence of impact, persistence, or attribution without additional local findings.
Mitigation priorities
- Start with telemetry assurance: confirm Windows endpoint logging and EDR coverage can reconstruct process execution and module/executable activity relevant to COM abuse investigations.
- Harden investigation workflows so analysts can quickly pivot from suspicious execution to parent process, child process, DLL/EXE server activity, user context, and host timeline.
- Prioritize least-privilege and application control reviews where local code execution paths are material to business risk, while avoiding assumptions that all COM activity is malicious.
- Include this behavior in incident response playbooks for Windows execution investigations, with evidence requirements defined before an incident.
- Use compliance and audit discussions to document whether execution telemetry is collected, retained, and reviewable for Windows hosts in scope.
Analyst notes and limits
The supplied object is a detection strategy, not a technique description, and it contains no official description or detection text. The strongest supported context comes from its relationship to T1559.001 Component Object Model, which is an enterprise ATT&CK Windows execution technique involving COM IPC and server objects implemented as DLLs or EXEs.
No official DET0224 detection logic, tactics, platforms, aliases, or labels were provided on the detection strategy itself. The Windows platform and execution tactic are supported only through the related T1559.001 technique. Local environment baselines, endpoint telemetry capabilities, and approved software behavior are required before determining detection quality or alert severity.
Detect Abuse of Component Object Model (T1559.001)
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 | T1559.001 | Component Object Model Sub-technique | This object detects Component Object Model. |
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 | 0d4100f25baa… |
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 DET0224Open 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.