T1652

Device Driver Discovery

Discovery Last updated:

This detection identifies adversary attempts to enumerate device drivers on a victim host using native OS utilities, registry queries, or API calls. Attackers use driver discovery to identify installed security products, detect virtualization/sandbox environments, and locate vulnerable drivers suitable for privilege escalation. On Windows, this commonly involves driverquery.exe, WMI queries, or registry enumeration under HKLM\SYSTEM\CurrentControlSet\Services and HKLM\SOFTWARE\WBEM\WDM. On Linux and macOS, utilities such as lsmod and modinfo are used to inspect loaded kernel modules. Known threat actors including Medusa Group, HOPLIGHT malware, INC Ransomware, and Remsec have all been observed performing driver enumeration as a precursor to further exploitation or defense evasion.

What is T1652 Device Driver Discovery?

Device Driver Discovery (T1652) maps to the Discovery tactic — the adversary is trying to figure out your environment in MITRE ATT&CK.

This page provides production-ready detection logic for Device Driver Discovery, covering the data sources and telemetry it touches: Microsoft Defender for Endpoint. The queries below are rated medium severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Discovery
Technique
T1652 Device Driver Discovery
Canonical reference
https://attack.mitre.org/techniques/T1652/
Microsoft Sentinel / Defender
kusto
let DriverDiscoveryBinaries = dynamic(["driverquery.exe", "lsmod", "modinfo"]);
let DriverDiscoveryKeywords = dynamic(["driverquery", "lsmod", "modinfo", "EnumDeviceDrivers", "WBEM\\WDM", "CurrentControlSet\\Services"]);
let ExcludedSystemProcesses = dynamic(["MsMpEng.exe", "SenseIR.exe", "MsSense.exe", "CSFalconService.exe"]);
// Process-based driver discovery
let ProcessBasedDiscovery = DeviceProcessEvents
| where TimeGenerated > ago(1d)
| where FileName in~ (DriverDiscoveryBinaries)
    or ProcessCommandLine has_any (DriverDiscoveryKeywords)
| where not (InitiatingProcessFileName in~ (ExcludedSystemProcesses))
| where not (InitiatingProcessFileName =~ "svchost.exe" and AccountName == "SYSTEM" and ProcessCommandLine !has "-fo")
| extend DetectionSource = "ProcessExecution"
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, FolderPath, DetectionSource;
// Registry-based driver discovery (HOPLIGHT pattern)
let RegistryBasedDiscovery = DeviceRegistryEvents
| where TimeGenerated > ago(1d)
| where RegistryKey has_any ("SOFTWARE\\WBEM\\WDM", "CurrentControlSet\\Services", "CurrentControlSet\\Control\\Class")
| where ActionType in ("RegistryValueQueried", "RegistryKeyQueried")
| where not (InitiatingProcessFileName in~ (ExcludedSystemProcesses))
| where not (InitiatingProcessFileName in~ ("services.exe", "svchost.exe", "WmiPrvSE.exe") and AccountName == "SYSTEM")
| extend DetectionSource = "RegistryQuery"
| project TimeGenerated, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine = "", FileName = InitiatingProcessFileName, ProcessCommandLine = RegistryKey, FolderPath = RegistryKey, DetectionSource;
// Union results and score
ProcessBasedDiscovery
| union RegistryBasedDiscovery
| extend RiskScore = case(
    InitiatingProcessFileName in~ ("powershell.exe", "cmd.exe", "wscript.exe", "cscript.exe", "mshta.exe") and AccountName != "SYSTEM", 80,
    InitiatingProcessFileName in~ ("powershell.exe", "cmd.exe") and AccountName == "SYSTEM", 60,
    DetectionSource == "RegistryQuery" and InitiatingProcessFileName !in~ ("explorer.exe", "mmc.exe"), 70,
    true(), 40
  )
| sort by TimeGenerated desc

Detects device driver discovery via process execution of driverquery.exe, lsmod, or modinfo, and registry enumeration of driver-related keys under HKLM\SYSTEM\CurrentControlSet\Services and HKLM\SOFTWARE\WBEM\WDM. Combines process and registry telemetry from Microsoft Defender for Endpoint, scoring events by initiating process risk to surface likely malicious activity. Suppresses known legitimate security product access patterns.

medium severity medium confidence

Data Sources

Microsoft Defender for Endpoint

Required Tables

DeviceProcessEvents DeviceRegistryEvents

False Positives

  • System administrators running driverquery.exe manually for troubleshooting or asset inventory
  • IT management tools (SCCM, PDQ Deploy, Tanium) enumerating drivers during hardware inventory scans
  • Software installers checking for prerequisite device drivers before installation (e.g., hardware peripheral setup)
  • Windows Device Manager (devmgmt.msc) and associated mmc.exe processes performing routine driver enumeration
  • Endpoint security platforms querying driver lists to detect vulnerable or malicious drivers

Sigma rule & cross-platform mapping

The detection logic for Device Driver Discovery (T1652) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: process_creation
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Windows Driver Enumeration via driverquery.exe with CSV Export

    Expected signal: Sysmon EventID 1: Image=driverquery.exe, CommandLine contains '/FO CSV /V'. Security EventID 4688 if process creation auditing is enabled. DeviceProcessEvents in MDE with ProcessCommandLine='/FO CSV /V'.

  2. Test 2HOPLIGHT-Style Registry Enumeration of WBEM WDM Driver Key

    Expected signal: Sysmon EventID 1: Image=reg.exe, CommandLine contains 'WBEM\WDM'. Sysmon EventID 12/13: TargetObject matching HKLM\SOFTWARE\WBEM\WDM. DeviceRegistryEvents in MDE with RegistryKey containing 'WBEM\WDM'.

  3. Test 3PowerShell Driver Enumeration via WMI Win32_SystemDriver

    Expected signal: Sysmon EventID 1: Image=powershell.exe, CommandLine contains 'Win32_SystemDriver'. PowerShell ScriptBlock log EventID 4104 with WMI query. DeviceProcessEvents in MDE showing powershell.exe invoking WMI.

  4. Test 4Linux Kernel Module Discovery via lsmod and modinfo

    Expected signal: Auditd log: execve syscall for lsmod and modinfo with uid/pid context. Syslog entries if auditd is configured to log execution. Linux process telemetry in Defender for Endpoint or SIEM showing lsmod/modinfo execution.


Response Playbook

Triage

  1. Step 1: Identify the initiating process — check InitiatingProcessFileName and InitiatingProcessCommandLine. Interactive shells (cmd.exe, powershell.exe) launched by a non-admin user are higher risk than services invoking driverquery for inventory.
  2. Step 2: Check the user account context. Was this SYSTEM, a service account, or an interactive logged-in user? Correlate with 4624/4648 logon events to determine if the session was legitimate or anomalous.
  3. Step 3: Review the full command line. driverquery.exe /FO CSV /V exports verbose driver info to CSV — this level of detail suggests data collection for exfiltration rather than simple troubleshooting.
  4. Step 4: Check the 15-minute window before and after the alert for other discovery commands (systeminfo, tasklist, net user, ipconfig, nltest) — driver discovery combined with other discovery techniques is a strong indicator of active reconnaissance.
  5. Step 5: For registry-based alerts, identify which registry hive was queried. HKLM\SOFTWARE\WBEM\WDM is specifically associated with HOPLIGHT malware. Compare the querying process against known legitimate consumers of that key.
  6. Step 6: Cross-reference the device against your asset inventory — a server process querying drivers unexpectedly is higher risk than an admin workstation with IT staff.

Containment

  1. If discovery is confirmed as part of an active intrusion, isolate the endpoint using Defender for Endpoint's Isolate Device action (Live Response or portal) to prevent lateral movement while investigation continues.
  2. If the initiating process is a suspicious binary (not a known system tool), kill the process via Live Response: run 'taskkill /F /PID <pid>' and collect the process memory dump before termination.
  3. Disable or reset the account used for the discovery activity if credentials are suspected compromised — check for concurrent logon events from other hosts.
  4. Block outbound connections from the affected host to any external IPs contacted within 30 minutes of the discovery activity pending investigation.

Evidence Collection

  1. Collect prefetch file for driverquery.exe: C:\Windows\Prefetch\DRIVERQUERY.EXE-*.pf — this records when driverquery was last executed and which files it accessed.
  2. Export Defender for Endpoint DeviceProcessEvents and DeviceRegistryEvents for the affected host over a 2-hour window centered on the alert timestamp.
  3. If available, collect PowerShell ScriptBlock logs (Event ID 4104) to capture any PowerShell commands that may have invoked driver enumeration via WMI or .NET APIs.
  4. Capture a full memory image of the process that initiated driver discovery using LiveResponseApi or a Live Response session: run 'procdump.exe -ma <pid> C:\Temp\proc_dump.dmp'.
  5. Export Windows Security event logs for EventIDs 4688 (process creation) and 4663 (object access) for the 30 minutes preceding the alert.
  6. On Linux hosts, capture output of 'auditd' logs and /var/log/syslog for lsmod/modinfo invocations, and collect /proc/modules for current module list.

Escalation Criteria

  • ! Escalate immediately if driver discovery is followed within 60 minutes by privilege escalation attempts, exploitation of a known vulnerable driver (e.g., BYOVD techniques), or any EventID 7045 (new service installed).
  • ! Escalate if the querying process matches a known malware family — specifically check for HOPLIGHT (WDM registry key), Remsec (security product driver enumeration), or INC Ransomware IOCs.
  • ! Escalate if discovery is performed under a service account or via a remotely executed command (parent process is WmiPrvSE.exe, psexesvc.exe, or a remote shell), indicating hands-on-keyboard intrusion.
  • ! Escalate if multiple hosts show driver discovery within the same time window — this suggests automated lateral movement or a worm-like propagation pattern.
  • ! Escalate if any enumerated drivers are associated with EDR/AV products and are subsequently targeted for tampering or termination.

Investigation Guide

Forensic Artifacts

  • > Prefetch: C:\Windows\Prefetch\DRIVERQUERY.EXE-*.pf (records execution timestamp and referenced files)
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Services (driver service entries queried by attackers)
  • > Registry: HKLM\SOFTWARE\WBEM\WDM (HOPLIGHT-specific target registry key)
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Control\Class (device class driver information)
  • > Windows Event Log: Security EventID 4688 with ProcessName=driverquery.exe (if command-line auditing enabled)
  • > Sysmon EventID 1: Process creation with driverquery.exe or lsmod in command line
  • > Sysmon EventID 12/13: Registry key open/value query events on driver-related keys
  • > Linux: /var/log/auth.log or auditd logs for lsmod/modinfo execution with user context
  • > Linux: /proc/modules (current state of loaded kernel modules at time of collection)
  • > Windows MFT/USN Journal: If driver query output was written to file (e.g., driverquery /FO CSV > output.csv)

Tuning Guidance

Start by baselining which processes legitimately invoke driverquery.exe in your environment — common legitimate callers include SCCM/Intune inventory agents, hardware vendor utilities, and admin scripts. Add these to the exclusion list by InitiatingProcessFileName and AccountName. For registry-based detection, the highest-fidelity signal is non-system processes querying HKLM\SOFTWARE\WBEM\WDM — this key is almost exclusively accessed by WMI infrastructure and the HOPLIGHT malware. On Linux, lsmod and modinfo calls by root outside of expected maintenance windows (e.g., kernel update periods) warrant investigation. Consider requiring that discovery commands are paired with at least one other discovery technique (T1033, T1016, T1082) before alerting, using a correlation rule with a 10-minute window to reduce isolated admin false positives.


Hunting Queries

Hunts for processes making unusually high volumes of driver registry key queries, which may indicate automated enumeration by malware. Filters known legitimate consumers and looks for >50 queries per process/host within 7 days.

Hunting — KQL
kql
// Hunt: Unusual processes querying driver registry keys — finds non-obvious registry-based enumeration
DeviceRegistryEvents
| where TimeGenerated > ago(7d)
| where RegistryKey has_any ("CurrentControlSet\\Services", "CurrentControlSet\\Control\\Class", "WBEM\\WDM")
| where ActionType in ("RegistryKeyQueried", "RegistryValueQueried")
| where InitiatingProcessFileName !in~ (
    "services.exe", "svchost.exe", "WmiPrvSE.exe", "MsMpEng.exe",
    "SenseIR.exe", "lsass.exe", "mmc.exe", "devmgmt.msc", "MsSense.exe"
  )
| summarize QueryCount=count(), UniqueKeys=dcount(RegistryKey), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
    by DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, AccountName
| where QueryCount > 50
| sort by QueryCount desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" (EventCode=12 OR EventCode=13)
| eval lower_reg=lower(TargetObject)
| where match(lower_reg, "(currentcontrolset\\\\services|currentcontrolset\\\\control\\\\class|wbem\\\\wdm)")
| where NOT match(lower(Image), "(services\.exe|svchost\.exe|wmiprvse\.exe|msmpeng\.exe|lsass\.exe)")
| stats count as query_count, dc(TargetObject) as unique_keys, earliest(_time) as first_seen, latest(_time) as last_seen by host, Image, User
| where query_count > 50
| sort -query_count

Hunts for a sequence where driver discovery precedes privilege escalation activity within 60 minutes on the same host by the same user, indicating the discovery is used to select an exploitation target.

Hunting — KQL
kql
// Hunt: Driver discovery immediately preceding privilege escalation or lateral movement
let DriverDiscovery = DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where FileName in~ ("driverquery.exe") or ProcessCommandLine has_any ("lsmod", "modinfo")
| project DiscoveryTime=TimeGenerated, DeviceName, AccountName;
let EscalationActivity = DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where ProcessCommandLine has_any ("SeDebugPrivilege", "token", "impersonate", "runas", "elevate")
    or FileName in~ ("at.exe", "schtasks.exe", "sc.exe")
| project EscalationTime=TimeGenerated, DeviceName, AccountName, EscalationProcess=FileName, EscalationCmd=ProcessCommandLine;
DriverDiscovery
| join kind=inner EscalationActivity on DeviceName, AccountName
| where EscalationTime > DiscoveryTime and EscalationTime < datetime_add('minute', 60, DiscoveryTime)
| project DiscoveryTime, EscalationTime, DeviceName, AccountName, EscalationProcess, EscalationCmd
| sort by DiscoveryTime desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
| eval lower_image=lower(Image), lower_cmd=lower(CommandLine)
| where match(lower_image, "driverquery\.exe") OR match(lower_cmd, "(lsmod|modinfo)")
| eval discovery_time=_time
| eval discovery_host=host
| eval discovery_user=User
| join type=inner host [
    search index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
    | eval lower_cmd2=lower(CommandLine)
    | where match(lower_cmd2, "(sedebugprivilege|impersonat|token.*elevat|runas|schtasks.*create)")
    | eval escalation_time=_time
    | table host, escalation_time, Image, CommandLine, User
  ]
| where escalation_time > discovery_time AND escalation_time < discovery_time + 3600
| table discovery_time, escalation_time, host, discovery_user, Image, CommandLine

Hunts for driverquery.exe invocations with verbose output flags (/FO CSV, /v) or output redirection, which indicate deliberate data collection for staging or exfiltration rather than casual one-off admin use.

Hunting — KQL
kql
// Hunt: driverquery.exe with output redirection or verbose flags — data staging indicator
DeviceProcessEvents
| where TimeGenerated > ago(14d)
| where FileName =~ "driverquery.exe"
| where ProcessCommandLine has_any ("/FO", "-FO", "/v", "-v", "CSV", "LIST", "TABLE", ">", "|", "Out-File")
| extend OutputFormat = extract(@"/FO\s+(\w+)", 1, ProcessCommandLine)
| project TimeGenerated, DeviceName, AccountName, ProcessCommandLine, OutputFormat, InitiatingProcessFileName, FolderPath
| sort by TimeGenerated desc
Hunting — SPL
spl
index=* sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
    Image="*\\driverquery.exe"
| where match(CommandLine, "(?i)(\/fo|\-fo|csv|list|table|>|out-file|\/v\b)")
| rex field=CommandLine "(?i)/FO\s+(?P<output_format>\w+)"
| table _time, host, User, CommandLine, output_format, ParentImage, ParentCommandLine
| sort -_time

Atomic Red Team Tests

Test 1 Windows Driver Enumeration via driverquery.exe with CSV Export
windows

Simulates the Medusa Group and INC Ransomware technique of running driverquery.exe with verbose CSV output flags to collect comprehensive driver information for exfiltration or analysis. This directly mimics reported threat actor TTPs.

Command

powershell
driverquery.exe /FO CSV /V > C:\Temp\drivers_output.csv & type C:\Temp\drivers_output.csv

Cleanup

powershell
del C:\Temp\drivers_output.csv 2>nul

Expected Telemetry

Sysmon EventID 1: Image=driverquery.exe, CommandLine contains '/FO CSV /V'. Security EventID 4688 if process creation auditing is enabled. DeviceProcessEvents in MDE with ProcessCommandLine='/FO CSV /V'.

Expected Detection

Alert: Device Driver Discovery — Native Driver Enumeration with RiskScore 40-60 depending on parent process context.

Test 2 HOPLIGHT-Style Registry Enumeration of WBEM WDM Driver Key
windows

Simulates the HOPLIGHT malware technique of enumerating device drivers registered in the Windows WMI Driver Model registry key. Uses reg.exe to query the key and export its contents.

Command

powershell
reg query "HKLM\SOFTWARE\WBEM\WDM" /s > C:\Temp\wdm_drivers.txt 2>&1 & reg query "HKLM\SYSTEM\CurrentControlSet\Services" /k > C:\Temp\services_drivers.txt 2>&1

Cleanup

powershell
del C:\Temp\wdm_drivers.txt 2>nul & del C:\Temp\services_drivers.txt 2>nul

Expected Telemetry

Sysmon EventID 1: Image=reg.exe, CommandLine contains 'WBEM\WDM'. Sysmon EventID 12/13: TargetObject matching HKLM\SOFTWARE\WBEM\WDM. DeviceRegistryEvents in MDE with RegistryKey containing 'WBEM\WDM'.

Expected Detection

Alert: Device Driver Discovery — HOPLIGHT Registry Pattern with RiskScore 70.

Test 3 PowerShell Driver Enumeration via WMI Win32_SystemDriver
windows

Enumerates installed device drivers using PowerShell WMI query against Win32_SystemDriver class, a non-obvious technique that avoids invoking driverquery.exe directly. Simulates sophisticated adversary tradecraft using living-off-the-land PowerShell.

Command

powershell
powershell.exe -NoProfile -Command "Get-WmiObject Win32_SystemDriver | Select-Object Name, State, PathName, StartMode | Export-Csv C:\Temp\ps_drivers.csv -NoTypeInformation; Write-Output 'Driver count: ' + (Get-WmiObject Win32_SystemDriver).Count"

Cleanup

powershell
Remove-Item C:\Temp\ps_drivers.csv -Force -ErrorAction SilentlyContinue

Expected Telemetry

Sysmon EventID 1: Image=powershell.exe, CommandLine contains 'Win32_SystemDriver'. PowerShell ScriptBlock log EventID 4104 with WMI query. DeviceProcessEvents in MDE showing powershell.exe invoking WMI.

Expected Detection

Alert: Device Driver Discovery with RiskScore 80 due to PowerShell initiating process. PowerShell ScriptBlock logs should show the Win32_SystemDriver WMI class access.

Test 4 Linux Kernel Module Discovery via lsmod and modinfo
linux

Enumerates loaded kernel modules on Linux using lsmod and retrieves detailed information for each module using modinfo. Simulates threat actor reconnaissance to identify security kernel modules or exploit targets.

Command

bash
lsmod > /tmp/kernel_modules.txt && lsmod | awk 'NR>1 {print $1}' | while read mod; do modinfo $mod 2>/dev/null | grep -E '(name|filename|description|version)' >> /tmp/module_details.txt; done && wc -l /tmp/kernel_modules.txt

Cleanup

bash
rm -f /tmp/kernel_modules.txt /tmp/module_details.txt

Expected Telemetry

Auditd log: execve syscall for lsmod and modinfo with uid/pid context. Syslog entries if auditd is configured to log execution. Linux process telemetry in Defender for Endpoint or SIEM showing lsmod/modinfo execution.

Expected Detection

Alert: Device Driver Discovery — Kernel Module Discovery via lsmod. Linux process execution events with CommandLine containing 'lsmod' and 'modinfo'.

Related Detections

Tactic Hub