T1652: Device Driver Discovery
Adversaries may attempt to enumerate local device drivers on a victim host. Information about device drivers may highlight various insights that shape follow-on behaviors, such as the function/purpose of the host, present security tools (i.e. Security Software Discovery) or other defenses (e.g., Virtualization/Sandbox Evasion), as well as potential exploitable vulnerabilities (e.g., Exploitation for Privilege Escalation).
Many OS utilities may provide information about local device drivers, such as `driverquery.exe` and the `EnumDeviceDrivers()` API function on Windows.[1][2] Information about device drivers (as well as associated services, i.e., System Service Discovery) may also be available in the Registry.[3]
On Linux/macOS, device drivers (in the form of kernel modules) may be visible within `/dev` or using utilities such as `lsmod` and `modinfo`.[4][5][6]
Analyst context for executives and security teams
Device Driver Discovery is adversary reconnaissance of the drivers or kernel modules present on an endpoint. This matters because driver information can reveal what kind of system an attacker has landed on, what security or virtualization controls may be present, and whether vulnerable drivers could support later privilege escalation. For leaders, it is a signal that endpoint visibility and vulnerability management need to cover low-level system components, not only user applications.
Executive priority
Treat this as a discovery behavior that can shape more damaging follow-on actions. The business decision value is in validating whether SOC and incident response teams can see driver enumeration across Windows, Linux, and macOS, whether vulnerable or unnecessary drivers are being managed, and whether evidence exists to show auditors that endpoint hardening and monitoring include kernel-level components. The relationship context includes ransomware and backdoor software using this technique, so it should be prioritized as part of resilience against post-compromise reconnaissance rather than as a standalone impact event.
Technical view
For Windows, validate visibility into driverquery.exe execution, command-line arguments, relevant registry access for device and driver information, and telemetry that may expose calls to EnumDeviceDrivers() where available. For Linux and macOS, validate logging for kernel module and device enumeration such as lsmod, modinfo, and inspection of /dev. Because ATT&CK provides no official detection text for this object, detection engineering should focus on local baselines: which administrators, management tools, and security products normally enumerate drivers, and which accounts or processes do so unexpectedly during broader discovery activity.
Likely telemetry
- Endpoint process creation and command-line telemetry for utilities such as driverquery.exe, lsmod, and modinfo
- Windows Registry access telemetry related to device and driver/service information
- Endpoint API or EDR telemetry that can expose driver enumeration behavior such as EnumDeviceDrivers() where collected
- Linux/macOS shell, process, and file/directory access telemetry involving /dev and kernel module information
- Asset and vulnerability inventory for installed drivers or kernel modules
Detection direction
- Baseline legitimate administrative, troubleshooting, inventory, and security-tool use of driver enumeration utilities before alerting on the commands alone.
- Prioritize alerts when driver discovery is performed by unusual users, unusual parent processes, newly observed binaries, remote shells, or in close sequence with other discovery activity.
- Account for blind spots where enumeration occurs through APIs, registry reads, or embedded tooling rather than obvious command-line utilities.
- Tune for platform differences: Windows driver and registry visibility will differ from Linux/macOS kernel module and /dev enumeration visibility.
- Use the supplied relationship context as threat-informed prioritization: this technique is associated with Medusa Group and software including Remsec, HOPLIGHT, and INC Ransomware, but do not infer attribution from the behavior alone.
Mitigation priorities
- Maintain an accurate inventory of installed drivers and kernel modules across supported endpoint platforms.
- Fold driver and kernel-module exposure into vulnerability management, especially where vulnerable drivers could support later privilege escalation.
- Reduce unnecessary drivers and services where operationally feasible to shrink reconnaissance value and attack surface.
- Ensure endpoint logging and EDR configurations capture process creation, command lines, relevant registry access, and Linux/macOS module enumeration events needed for investigation.
- Document legitimate administrative use cases so SOC teams can distinguish routine operations from suspicious post-compromise discovery.
Analyst notes and limits
This technique sits in the Discovery tactic and is relevant across Linux, macOS, and Windows. It is not inherently destructive, but it can provide adversaries with information needed to choose later evasion, targeting, or privilege-escalation paths. DET0579 is listed as a detection strategy for this object, but no detection logic details were supplied here.
MITRE does not provide official detection text in the supplied object, and the relationship context does not prove activity in any specific environment. Local telemetry coverage, endpoint baselines, driver inventories, and vulnerability data are required to turn this into reliable detection or risk prioritization.
Device Driver Discovery
Adversaries may attempt to enumerate local device drivers on a victim host. Information about device drivers may highlight various insights that shape follow-on behaviors, such as the function/purpose of the host, present security tools (i.e. Security Software Discovery) or other defenses (e.g., Virtualization/Sandbox Evasion), as well as potential exploitable vulnerabilities (e.g., Exploitation for Privilege Escalation).
Many OS utilities may provide information about local device drivers, such as `driverquery.exe` and the `EnumDeviceDrivers()` API function on Windows.[1][2] Information about device drivers (as well as associated services, i.e., System Service Discovery) may also be available in the Registry.[3]
On Linux/macOS, device drivers (in the form of kernel modules) may be visible within `/dev` or using utilities such as `lsmod` and `modinfo`.[4][5][6]
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.
Groups, software, and campaigns
G1051: Medusa Group
Medusa Group has been active since at least 2021 and was initially operated as a closed ransomware group before evolving into a Ransomware-as-a-Service (RaaS) operation. Some reporting indicates that certain attacks may still be conducted directly by the ransomware’s core developers. Public sources have also referred to the group as “Spearwing” or “Medusa Actors.” [1] [2] Medusa Group employs living-off-the-land techniques, frequently leveraging publicly available tools and common remote management software to conduct operations. The group engages in double extortion tactics, exfiltrating data prior to encryption and threatening to publish stolen information if ransom demands are not met. [3] For initial access, Medusa Group has exploited publicly known vulnerabilities, conducted phishing campaigns, and used credentials or access purchased from Initial Access Brokers (IABs). The group is opportunistic and has targeted a wide range of sectors globally. [4]
S0376: HOPLIGHT
S1139: INC Ransomware
INC Ransomware is a ransomware strain that has been used by the INC Ransom group since at least 2023 against multiple industry sectors worldwide. INC Ransomware can employ partial encryption combined with multi-threading to speed encryption.[1][2][3]
S0125: Remsec
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 | 7f074e1ff2b0… |
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]
Microsoft Driverquery
Microsoft. (n.d.). driverquery. Retrieved March 28, 2023.
Open source URL -
[2]
Microsoft EnumDeviceDrivers
Microsoft. (2021, October 12). EnumDeviceDrivers function (psapi.h). Retrieved March 28, 2023.
Open source URL -
[3]
Microsoft Registry Drivers
Microsoft. (2021, December 14). Registry Trees for Devices and Drivers. Retrieved March 28, 2023.
Open source URL -
[4]
Linux Kernel Programming
Pomerantz, O., Salzman, P.. (2003, April 4). The Linux Kernel Module Programming Guide. Retrieved April 6, 2018.
Open source URL -
[5]
lsmod man
Kerrisk, M. (2022, December 18). lsmod(8) — Linux manual page. Retrieved March 28, 2023.
Open source URL -
[6]
modinfo man
Russell, R. (n.d.). modinfo(8) - Linux man page. Retrieved March 28, 2023.
Open source URL -
[7]
mitre-attack T1652Open 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.