Before ransomware operators load a vulnerable driver to kill your EDR, they usually check which drivers, and which security products, are already on the host. MITRE ATT&CK T1652 Device Driver Discovery covers adversaries enumerating local device drivers to learn what a host does, which security tools and virtualisation layers are present, and which drivers might be exploitable. ATT&CK v20 places it in the Discovery tactic (TA0007) for Linux, macOS and Windows, with no sub-techniques. This guide explains the utilities, APIs and files involved, the detection logic MITRE maps to each platform, how to tell an attacker's query from an administrator's, and the controls that make the next step, a bring your own vulnerable driver (BYOVD) attack, fail. It is for detection engineers, endpoint engineers and incident responders, and is defensive only.
Key takeaways
- Driver discovery is an early warning for EDR tampering. ATT&CK links the results to Security Software Discovery, sandbox evasion and Exploitation for Privilege Escalation, which is the BYOVD chain.
- Context makes the signal. A driver listing from an inventory agent is routine; the same listing from a remote management tool session, a new binary or a shell spawned by a web server is not.
- Look for the sequence. Driver listing followed by a new service of kernel type, a driver load, or security processes stopping is the pattern worth an alert.
- Windows 11 24H2 changed the API picture. Microsoft documents that EnumDeviceDrivers now needs SeDebugPrivilege to return real load addresses, so a process enabling that privilege to call it is itself notable.
- Blocking the driver matters more than spotting the query. The Microsoft vulnerable driver blocklist, memory integrity (HVCI) and App Control for Business stop the follow-on step even if discovery goes unseen.
What T1652 covers
ATT&CK v20 says information about device drivers can reveal the function or purpose of a host, present security tools (T1518.001 Security Software Discovery), other defences such as virtualisation (T1497 Virtualization/Sandbox Evasion) and potentially exploitable vulnerabilities (T1068 Exploitation for Privilege Escalation). Drivers and their services also overlap with T1007 System Service Discovery and with T1012 Query Registry, because Windows records drivers as services in the registry.
| Platform | Sources of driver information | Notes for defenders |
|---|---|---|
| Windows | driverquery.exe (local, or remote with /s; /si for signing details); the EnumDeviceDrivers() API in Psapi.dll / Kernel32.dll; service keys under HKLM\SYSTEM\CurrentControlSet\Services; WMI and PowerShell queries | The remote form means one host can enumerate drivers on many; from Windows 11 24H2 EnumDeviceDrivers returns NULL addresses without SeDebugPrivilege |
| Linux | lsmod (which formats /proc/modules), modinfo, /sys/module/, entries in /dev | Reads of /proc/modules are common in monitoring agents, so baseline by process |
| macOS | kextstat, kextfind, ioreg, files under /System/Library/Extensions/ | Unexpected use by non-administrative users or scripts is the signal MITRE highlights |
This page describes these sources only to the depth needed to write detections.
How adversaries use it
ATT&CK v20 records four procedure examples. Ransomware operators lead the list, which matches the use of driver information to plan defence impairment.
| Actor or software | What ATT&CK records | Why it matters |
|---|---|---|
| Medusa Group (G1051) | Queried drivers on the victim device with driverquery | Same advisory reports attempts to use vulnerable or signed drivers to kill or delete EDR |
| INC Ransomware (S1139) | Verifies the presence of specific drivers, including Microsoft Print to PDF and Microsoft XPS Document Writer | Driver checks can serve the payload's own functions, not only evasion |
| Remsec (S0125) | Has a plugin to detect active drivers of some security products | Espionage tooling uses driver lists to profile defences |
| HOPLIGHT (S0376) | Enumerates device drivers in the registry at HKLM\Software\WBEM\WDM | Registry reads can replace the utility entirely, so command-line rules alone miss it |
Case: Medusa, from driverquery to EDR killing
The joint FBI, CISA and MS-ISAC advisory on Medusa ransomware (AA25-071A, first published 12 March 2025) lists cmd.exe /c driverquery among the commands observed. The same advisory reports that the actors attempted to use vulnerable or signed drivers to kill or delete EDR tools, ran scripts to remove a security product and disabled Windows Defender and other antivirus services before encryption. The advisory maps the EDR killing to Impair Defenses: Disable or Modify Tools, which ATT&CK v20 now tracks as T1685 Disable or Modify Tools. For the actor's wider tradecraft see the Medusa Ransomware Threat Actor Profile, and for the driver attack itself the Bring Your Own Vulnerable Driver and EDR Killers Guide.
What to detect and where
ATT&CK v20 maps detection strategy DET0579 with three analytics. The table summarises them and adds the telemetry most teams already have.
| Platform | Analytic | Data components and logs |
|---|---|---|
| Windows | AN1595: driver enumeration utilities (driverquery.exe) or API calls such as EnumDeviceDrivers(), plus abnormal registry access to HKLM\SYSTEM\CurrentControlSet\Services and HardwareProfiles, correlated into a chain | Process Creation: Security 4688; Windows Registry Key Modification: Sysmon 13 and 14. Also EDR process and API telemetry |
| Linux | AN1596: lsmod, modinfo or reads of /proc/modules and /dev in unusual contexts, such as unprivileged users or processes outside admin workflows | Command Execution: auditd SYSCALL execve; File Access: auditd read of /proc/modules or /sys/module/ |
| macOS | AN1597: kextstat, kextfind or ioreg for driver information, and access to /System/Library/Extensions/ by non-admin users or scripts | Process Creation and File Access in the unified log; EDR process events |
Two practical notes. Security event 4688 only carries the command line when "Include command line in process creation events" is enabled. Sysmon events 13 and 14 record registry changes, not reads, so registry-based enumeration such as HOPLIGHT's is better caught by EDR registry telemetry or by object access auditing on selected keys.
Detection logic that holds up
| Rule idea | Logic | Expected noise |
|---|---|---|
| Unusual parent | driverquery.exe, lsmod or kextstat started by Office apps, script hosts, web server workers, remote management tools or a binary first seen in the last 7 days | Low |
| Discovery burst | Driver listing plus process, service and security software discovery from the same process tree within 10 minutes | Medium: support scripts and inventory jobs; allow-list by signed path and account |
| Remote driver query | driverquery with /s to another host, especially with explicit credentials | Low outside inventory servers |
| Privilege then enumerate | A non-system process enabling SeDebugPrivilege shortly before driver or process enumeration | Low to medium: debuggers and some admin tools |
| Discovery then driver load | Driver listing followed within an hour by a new kernel-mode service (System event 7045 with a kernel driver type) or a Sysmon 6 Driver loaded event for a driver not seen in the fleet | Low; high-priority alert |
| Discovery then defence loss | Driver listing followed by EDR sensor stop, health heartbeat loss or security service stop | Very low; treat as active intrusion |
Use a fleet-wide driver baseline: hash and signer of every loaded driver. A driver seen on one host only, or a known vulnerable driver appearing anywhere, matters more than the discovery query that preceded it. The Sysmon Guide covers event 6 configuration.
Where identity fits
Driver discovery needs a foothold, and the follow-on driver load needs administrator rights. In ransomware cases those rights often come from a compromised service or remote management account rather than a person.
- Remote management accounts:
driverquery /sand remote tools let one credential enumerate many hosts; restrict which accounts may log on remotely to servers and watch them for discovery commands. - Local administrator sprawl: Unique, rotated local administrator passwords stop one host's credential unlocking the next host's driver store.
- Least privilege for agents: Software agents that legitimately enumerate drivers should run under dedicated identities so their activity can be baselined and anything else stands out. See the Service Account Security Guide.
Mitigations
ATT&CK v20 lists no mitigation for T1652 itself, because it abuses normal system features. The practical controls below are NHI Mgmt Group recommendations aimed at the step that follows, drawn from Microsoft's documentation where stated.
| Control | What it does | Source |
|---|---|---|
| Microsoft vulnerable driver blocklist | Blocks known vulnerable and malicious third-party kernel drivers; enabled by default on all devices since the Windows 11 2022 update; updated quarterly and through monthly updates | Microsoft Learn |
| Memory integrity (HVCI) | Enforces the blocklist and kernel code integrity; Microsoft's preferred option | Microsoft Learn |
| App Control for Business blocklist policy | Applies the blocklist where HVCI is not possible; test in audit mode, reboot to block drivers already running, confirm with CodeIntegrity Operational event 3099 | Microsoft Learn |
| ASR rule "Block abuse of exploited vulnerable signed drivers" | Stops applications writing vulnerable signed drivers to disk | Microsoft Learn |
| EDR tamper protection | Makes stopping the sensor harder after discovery | NHI Mgmt Group recommendation |
| Restrict kernel module loading on Linux | Signed module enforcement and module loading locks on servers where modules do not change | NHI Mgmt Group recommendation |
Microsoft notes the blocklist does not cover every vulnerable driver and that blocking can break devices, so pilot it. For allowlisting design see the Application Allowlisting Guide.
How to test
- Confirm telemetry: On a test host, run the native driver listing utility as a standard user and as an administrator, and confirm process events with full command lines reach the SIEM on each platform.
- Baseline: Run the rules in report-only mode for 30 days and record which agents and admin tools enumerate drivers.
- Emulate the chain: In a lab, run driver discovery from an unusual parent, then install a benign test driver as a kernel service, and confirm the sequence rule fires. Do not use real vulnerable drivers outside an isolated lab.
- Check the blocklist: Confirm event 3099 shows the expected policy on a sample of hosts, and that HVCI status is reported in your device management tool.
- Roll back: If a rule is noisy, scope exceptions by signed binary path and account, not by host.
Measuring it
- Share of Windows endpoints with memory integrity on and the vulnerable driver blocklist enforced.
- Share of hosts sending process creation events with command lines.
- Number of unique kernel drivers in the fleet and the count seen on fewer than five hosts.
- Alerts on discovery-then-driver-load sequences and their median triage time.
- False positive rate per rule per month.
Common failure patterns
- Alerting on every driverquery: Inventory and support tools run it constantly; without parent and sequence context the rule gets switched off.
- Command lines not logged: 4688 without command line auditing shows the utility but not the remote target.
- Relying on utility names: Registry and API enumeration, as in HOPLIGHT, bypasses rules keyed only on
driverquery.exe. - Blocklist assumed on: Older builds, servers and devices with HVCI off may not enforce it; verify per host.
- No driver baseline: Without knowing which drivers are normal, a rare driver load after discovery looks like any other.
Framework mapping
| Framework | Mapping |
|---|---|
| MITRE ATT&CK v20 | T1652 (TA0007 Discovery); detection DET0579 (AN1595, AN1596, AN1597); related T1518.001, T1497, T1068, T1007, T1012, T1685, T1543.003, T1547.006 |
| NIST SP 800-53 Rev. 5 | CM-7 Least Functionality, CM-8 System Component Inventory, SI-4 System Monitoring, SI-7 Software, Firmware, and Information Integrity, AC-6 Least Privilege |
| NIST CSF 2.0 | DE.CM-09 computing hardware, software and runtime environments monitored; DE.AE-02 adverse events analysed |
| ISO/IEC 27001:2022 Annex A | 8.7 Protection against malware, 8.16 Monitoring activities, 8.19 Installation of software on operational systems |
Practitioner checklist
- Enable command line capture in process creation events on Windows, and execve auditing on Linux servers.
- Collect Sysmon 6 driver loads and System 7045 service installs centrally.
- Build a fleet driver baseline by hash and signer.
- Alert on driver discovery from unusual parents and on discovery followed by a driver load or sensor loss.
- Turn on memory integrity and confirm the vulnerable driver blocklist with event 3099.
- Enable the ASR rule for vulnerable signed drivers and EDR tamper protection.
- Restrict which service and admin accounts may run remote commands on servers.
- Test the full chain in a lab twice a year.
Standards and references
- MITRE ATT&CK: Device Driver Discovery (T1652)
- CISA, FBI and MS-ISAC: #StopRansomware: Medusa Ransomware (AA25-071A)
- Microsoft Learn: Microsoft recommended driver block rules
- Microsoft Learn: driverquery
- Microsoft Learn: EnumDeviceDrivers function
- Linux man-pages: lsmod(8)
Related NHI Mgmt Group resources: EDR Tampering and BYOVD Response Playbook · T1685 Disable or Modify Tools Defensive Guide · T1068 Exploitation for Privilege Escalation · MITRE ATT&CK T1497 Virtualization/Sandbox Evasion