DET0579: Detection Strategy for Device Driver Discovery
This detection strategy matters because device driver discovery can help an intruder understand what kind of host they are on, what security or virtualizat...
Analyst context for executives and security teams
This detection strategy matters because device driver discovery can help an intruder understand what kind of host they are on, what security or virtualization controls may be present, and whether local driver-related weaknesses might shape later actions. For leaders, the value is not the discovery event alone; it is whether the organization can see host-level enumeration that may precede evasion, vulnerability targeting, or follow-on discovery across Linux, macOS, and Windows environments.
Executive priority
Treat DET0579 as a validation point for endpoint visibility and incident readiness around ATT&CK technique T1652, Device Driver Discovery. Security leaders should ask whether SOC and IR teams can identify unusual driver-enumeration behavior, correlate it with other discovery activity, and preserve enough host telemetry to support an investigation. This is especially relevant for prioritizing endpoint logging, managed detection requirements, vulnerability-management context, and audit evidence showing that discovery-stage behavior is monitored rather than ignored.
Technical view
The supplied ATT&CK object is a detection strategy for T1652 but does not include official detection logic, tactics, or platform fields of its own. The related technique is Discovery and applies to Linux, macOS, and Windows. SOC and detection engineering teams should therefore validate coverage against local device-driver enumeration behavior on those operating systems, then correlate it with nearby discovery patterns such as security software discovery or virtualization/sandbox awareness where local telemetry supports that context. Because benign administration and troubleshooting may also enumerate drivers, detections should emphasize unusual users, processes, timing, command lineage, host role, and clustering with other discovery activity.
Likely telemetry
- Endpoint process execution and command-line telemetry related to driver, kernel module, hardware, or system extension enumeration
- Parent-child process relationships and user/session context for local enumeration activity
- OS-specific system logs that record driver, kernel module, or system extension queries where available
- EDR or host sensor events that capture discovery commands, scripts, or tools interacting with driver information
- Asset inventory and vulnerability-management context to distinguish expected administrative activity from unusual discovery on sensitive hosts
Detection direction
- Validate that Linux, macOS, and Windows endpoint telemetry can capture local device-driver enumeration rather than only driver installation or load events.
- Tune for context: unusual process lineage, non-administrative users, rare tools, unexpected hosts, or enumeration occurring alongside other discovery behaviors should carry more weight than a single expected admin query.
- Account for false positives from IT operations, troubleshooting, inventory tools, diagnostics, and security products that legitimately inspect drivers.
- Use relationship-driven context: because T1652 may reveal security tools, virtualization indicators, host purpose, or potential vulnerabilities, correlate driver discovery with security software discovery, sandbox/virtualization checks, and vulnerability-relevant host attributes when available.
- Document gaps explicitly if endpoint tools do not retain command-line details, script content, user context, or OS-specific driver/module query events.
Mitigation priorities
- Prioritize endpoint logging and EDR configuration that preserves process, command-line, user, and host context for discovery-stage activity.
- Maintain accurate asset and driver inventory so SOC teams can separate normal administrative enumeration from unexpected behavior on critical systems.
- Use least-privilege and administrative access governance to reduce the number of accounts and tools expected to perform broad host inspection.
- Feed driver and host inventory into vulnerability management so discoveries involving sensitive or outdated driver exposure can be triaged with business context.
- Prepare IR playbooks to treat suspicious driver discovery as a potential precursor signal and to pivot into related discovery, evasion, and vulnerability-targeting evidence.
Analyst notes and limits
The ATT&CK detection-strategy object itself has no official description or detection text. The practical guidance above is derived from its relationship to T1652, Device Driver Discovery, including the related Discovery tactic and Linux, macOS, and Windows platform scope. Local baselining is essential because device-driver inspection is common in administration, diagnostics, inventory, and security tooling.
No ATT&CK-provided detection analytics, data sources, procedures, mitigations, or platform list were supplied for DET0579 itself. This take should be used as a coverage-validation guide, not as proof of detection coverage or active threat activity.
Detection Strategy for Device Driver Discovery
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 | T1652 | Device Driver Discovery | This object detects Device Driver Discovery. |
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 | 17a8db5f88dd… |
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 DET0579Open 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.