DET0377: Detection of Kernel/User-Level Rootkit Behavior Across Platforms
DET0377 is a detection strategy for finding behavior associated with rootkits, which matter because they are designed to hide malware, files, services, dri...
Analyst context for executives and security teams
DET0377 is a detection strategy for finding behavior associated with rootkits, which matter because they are designed to hide malware, files, services, drivers, network connections, and other system components from normal administrative and security views. For leaders, the key issue is not only whether malware can be found, but whether the organization can trust its endpoint evidence during an incident.
Executive priority
Prioritize this as an operational resilience and incident-response readiness question: if a rootkit is suspected, can the SOC prove what is running on Linux, macOS, and Windows systems, and can IR teams collect evidence from sources that are not easily blinded by user- or kernel-level tampering? This affects containment decisions, audit confidence, and whether endpoint security investments provide usable evidence against stealth techniques.
Technical view
The supplied ATT&CK object has no official detection text or platform list, but it detects T1014 Rootkit, which is associated with stealth and Linux, macOS, and Windows. SOC and IR teams should validate coverage for discrepancies between normal OS-reported state and independent security or integrity sources: hidden processes, files, services, drivers or kernel modules, network connections, and API-hooking or system information manipulation indicators. Treat this as a coverage-validation strategy rather than a single analytic.
Likely telemetry
- Endpoint security and EDR host telemetry where available
- Kernel driver, kernel module, and service inventory data
- Process, file, and network connection enumeration from host sensors
- Operating system integrity or configuration state evidence
- Security logs related to driver, service, or privileged component changes
Detection direction
- Compare multiple evidence sources for the same host because rootkits may manipulate API calls that supply system information.
- Validate visibility across the related technique platforms: Linux, macOS, and Windows, rather than assuming one endpoint control covers all operating systems equally.
- Tune for high-risk changes to kernel-level or privileged components while accounting for legitimate drivers, security tools, administrative software, and platform updates as false-positive sources.
- Include checks for hidden or inconsistent process, file, service, driver, and network connection views during triage.
- Document where collection depends entirely on the potentially compromised operating system, as that is a material blind spot for rootkit detection.
Mitigation priorities
- Maintain strong privileged access controls and change governance around drivers, services, kernel modules, and other high-trust system components.
- Ensure endpoint monitoring and IR procedures can collect corroborating evidence when local OS reporting may be untrustworthy.
- Baseline approved system components so unusual privileged additions or hidden components can be investigated faster.
- Prepare escalation playbooks for suspected rootkit activity, including evidence preservation and rebuild-or-reimage decision criteria where trust cannot be restored.
- Use the ATT&CK relationship to T1014 as a control-validation item in SOC, IR, and compliance readiness exercises.
Analyst notes and limits
The most important decision value is trust in telemetry. Rootkit behavior directly challenges the assumption that host-reported process, file, service, driver, and network data is complete. Glexia would use this object to drive a cross-platform detection coverage review and an IR readiness discussion, not to claim a specific analytic exists in the ATT&CK entry.
The official detection strategy entry provides no description, no detection text, no tactics, and no platforms. Platform and behavior context comes from the supplied relationship to T1014 Rootkit. Local architecture, endpoint controls, logging depth, and IR tooling determine practical coverage.
Detection of Kernel/User-Level Rootkit Behavior Across Platforms
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 | f9b923b55e82… |
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 DET0377Open 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.