DET0780: Detection of Rootkit
DET0780 is a detection strategy placeholder for identifying rootkit behavior related to the ICS ATT&CK technique T0851. The business significance is that r...
Analyst context for executives and security teams
DET0780 is a detection strategy placeholder for identifying rootkit behavior related to the ICS ATT&CK technique T0851. The business significance is that rootkits are designed to hide malicious components from normal operating-system views, which can undermine confidence in endpoint status, incident scoping, recovery decisions, and audit evidence. For security leaders, the key question is not whether this specific ATT&CK entry provides ready-made analytics—it does not—but whether teams can independently verify system integrity when normal host telemetry may be manipulated or incomplete.
Executive priority
Treat this as a resilience and assurance issue: if a rootkit is suspected, standard monitoring may not be trustworthy enough to support containment, restoration, or compliance attestations. Leaders should ask whether incident response plans include trusted recovery media, integrity validation, forensic escalation paths, and criteria for rebuild versus clean-up. Because the object is in the ICS domain, prioritize environments where hidden system components could affect operational continuity or confidence in cyber-physical systems, while avoiding assumptions about specific platforms because MITRE does not specify them here.
Technical view
This detection strategy has no official ATT&CK detection text, platforms, or tactics supplied. The only relationship context is that it detects T0851 Rootkit, which describes adversaries hiding programs, files, network connections, services, drivers, and other system components by intercepting and modifying operating-system API calls, potentially at user, kernel, or lower levels including firmware. SOC and IR teams should therefore validate whether they have host integrity, driver/service inventory, file/process/network cross-checking, and out-of-band forensic methods that do not rely solely on potentially hooked operating-system APIs.
Likely telemetry
- Host process, file, service, driver, and network-connection inventories
- Endpoint security and EDR observations, where deployed
- Operating system logs relevant to service, driver, or component loading
- File integrity and configuration integrity evidence
- Firmware or boot integrity evidence where available
Detection direction
- Do not rely on a single host API view; compare multiple evidence sources for mismatches in files, processes, services, drivers, and network connections.
- Validate whether monitoring can observe or infer hidden components when user-level or kernel-level visibility is impaired.
- Create escalation criteria for systems where telemetry gaps, inconsistent inventories, or unexplained service/driver artifacts suggest possible hiding behavior.
- Tune carefully: administrative tools, security agents, and legitimate drivers can create noisy low-level activity, so detections should emphasize inconsistency, persistence, and untrusted components rather than any single event.
- For ICS environments, confirm which assets can safely support endpoint telemetry and which require passive, maintenance-window, or forensic collection approaches.
Mitigation priorities
- Prioritize trusted recovery and rebuild procedures for systems where integrity cannot be established.
- Maintain known-good baselines for critical hosts, including services, drivers, files, and configuration where feasible.
- Use least privilege and change control to reduce unauthorized installation or modification of low-level components.
- Ensure incident response playbooks include forensic collection methods that can operate when local operating-system reporting is suspect.
- For operational technology environments, align containment and investigation actions with safety and availability requirements before making intrusive changes.
Analyst notes and limits
The ATT&CK object is a detection strategy entry, DET0780, for Detection of Rootkit and is related to ICS technique T0851 Rootkit. Since MITRE did not provide official detection guidance, tactics, or platforms in the supplied fields, this take focuses on defensive validation questions and evidence classes derived from the related technique description.
No official description or detection text was supplied for DET0780, and platforms and tactics are not specified. The related T0851 description is truncated in the provided context. Local architecture, asset criticality, endpoint tooling, and forensic capabilities are required to turn this into concrete analytics or procedures.
Detection of Rootkit
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.
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 | e643c9baf970… |
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 DET0780Open 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.