Driver enumeration by command line or services-key query

Siemphony@siemphonylowT1652unverified

Matches the two Windows driver-discovery behaviours AN1595 names that leave a command line: an invocation of `driverquery`, and a registry read of `HKLM\SYSTEM\CurrentControlSet\Services` or the `HardwareProfiles` subtree. Every selection sits on `CommandLine` so the rule stays a single-field OR that all four backends render, and the value lists are ones assembled here — MITRE supplies the `AllowedUtilities` knob, not its contents. The analytic's other observables do not survive contact with the log sources: `EnumDeviceDrivers()` is an in-process API call that emits no event, and the registry sources the brief lists are Sysmon EventID 13 and 14, which record value writes and key renames — Sysmon has no registry-read event, so enumeration performed through the registry API rather than a command line is invisible here. Written in the Sysmon EventID 1 vocabulary; the Security EventID 4688 feed populates `CommandLine` only when *Audit Process Creation* and *Include command line in process creation events* are both enabled, and neither is on by default. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0579, not hand-written and not tested by its author. Any lab result is on this rule's own page.Full description

The 4 SIEM queries below are previews produced by Siemphony’s own translator, not pySigma, and none has been executed against a real backend — review before you deploy.

detection.yml

Sentinel · KQL

Run this as a search.

DeviceProcessEvents| where (ProcessCommandLine contains "driverquery" or (ProcessCommandLine contains "query" and ProcessCommandLine contains "CurrentControlSet\\Services") or ProcessCommandLine contains "CurrentControlSet\\HardwareProfiles")

Splunk · SPL

Run this as a search.

index=* (CommandLine="*driverquery*" OR (CommandLine="*query*" AND CommandLine="*CurrentControlSet\\Services*") OR CommandLine="*CurrentControlSet\\HardwareProfiles*")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.command_line) LIKE "*driverquery*" OR (TO_LOWER(process.command_line) LIKE "*query*" AND TO_LOWER(process.command_line) LIKE "*currentcontrolset\\\\services*") OR TO_LOWER(process.command_line) LIKE "*currentcontrolset\\\\hardwareprofiles*")

Wazuh · XML rule

Deploy to your manager — this is a rule, not a search.

<group name="sigma,windows,process_creation,">  <!-- Rule ids must be unique on your manager; 100000+ is the user range. -->  <rule id="100000" level="5">    <!-- Set <if_sid> to the decoder/base rule for windows so this only evaluates relevant events. -->    <field name="CommandLine" type="pcre2">(?i)(driverquery|(?=.*(?:query))(?=.*(?:CurrentControlSet\\Services)).*|CurrentControlSet\\HardwareProfiles)</field>    <description>Driver enumeration by command line or services-key query</description>    <mitre>      <id>T1652</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: low
Category: network_service_discovery
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: cafc5b23-171f-4764-90e7-0596e5535099

ATT&CKT1652

T1652Device Driver Discovery

ATT&CK® is a registered trademark of The MITRE Corporation. These mappings are the rule author’s, and are neither reviewed nor endorsed by MITRE.

Lessonnetwork service discovery

network service discoveryAI draft — unreviewed

01 · What this rule detects

MITRE's analytic AN1595 for Device Driver Discovery names three observables: the driverquery.exe utility, the EnumDeviceDrivers() API call, and registry reads of HKLM\SYSTEM\CurrentControlSet\Services or its HardwareProfiles subtree. This rule can only catch the first and third — both as command-line text, not as the behaviours themselves. It fires when a process's CommandLine contains driverquery, contains both query and CurrentControlSet\Services, or contains CurrentControlSet\HardwareProfiles. Anything that enumerates drivers without generating one of those exact substrings is outside its reach.

02 · Telemetry you need

The rule is written against Sysmon EventID 1 (process_creation), reading CommandLine. If your environment instead relies on Security EventID 4688, know that CommandLine only populates there when Audit Process Creation and the separate Include command line in process creation events policy are both enabled — neither is on by default, so an unconfigured 4688 feed will produce zero matches that look like a quiet host rather than a blind one.

03 · How the logic works

Three selections, one condition, 1 of selection*: - selection_driverquery: CommandLine|contains: 'driverquery' - selection_services_key: CommandLine|contains|all: ['query', 'CurrentControlSet\Services'] — both substrings must appear, in any position - selection_hardware_profiles: CommandLine|contains: 'CurrentControlSet\HardwareProfiles' Everything sits on one field so the rule renders on all four backends without contortion. But this also means the rule catches only a precursor, not the technique AN1595 actually describes. MITRE's analytic asks for correlation — "correlate command execution, process creation, and registry access to build a behavioral chain" — and even names a TimeWindow knob for it. This rule has no aggregation or time window; it is a flat OR over single events. A single driverquery hit is not the behavioral chain MITRE describes, just one ingredient of it. EnumDeviceDrivers() and registry reads of the Services key never appear here at all — Sysmon's registry events (13/14) record value writes and key renames, not reads, so enumeration performed purely through the registry API is structurally invisible to this logsource.

04 · Common false positives

The review flagged that selection_services_key is not actually specific to T1652. HKLM\SYSTEM\CurrentControlSet\Services holds both driver registrations and ordinary Win32 service registrations under the same key, so a match here is equally consistent with T1007 (System Service Discovery) — the rule cannot tell the two apart, and the description doesn't say so. Treat any hit on that selector as "someone queried the Services key," not confirmed driver discovery.
Named false positives, roughly by volume: scheduled asset-inventory scripts running driverquery /v /fo csv (by far the loudest); driver installers and hardware-update agents doing a reg query version check before writing a service entry; and helpdesk staff querying the key by hand while troubleshooting. Review also flagged a fourth, likely larger source the rule omits: RMM/endpoint-management agents (SCCM, Tanium, Datto, NinjaOne) polling every managed endpoint on a schedule.

05 · Detection maturity

tier_1: UNVERIFIED. This rule has never been run against real logs — no test dataset, no observed match rate, no confirmed true or false positive. It sits at the lowest DeBMM tier until someone deploys it against live telemetry and records what actually fires.

Tuning & false positivesexperimental · 3 declared

experimental (current stage)
test
stable

Written and reasoned about, but not yet run against real telemetry. Expect to tune it before trusting it.

Tuning tips

MITRE names the AllowedUtilities knob for this analytic; the rule doesn't populate it — the false-positive text just says to "pin the expected caller" there rather than deleting the driverquery selector outright. Add your RMM and inventory tooling's parent process or path to that allowlist first. Note also that pnputil.exe /enum-drivers and PowerShell's Get-WindowsDriver/Get-PnpDevice achieve the same discovery and match none of these three substrings — a real gap, not a tuning choice.

Declared by the author

Asset-inventory and diagnostic scripts that snapshot driver versions on a schedule or at logon, typically as driverquery /v /fo csv redirected to a share. Wherever this exists it is the highest-volume match by a wide margin, and MITRE's AllowedUtilities knob is the place to pin the expected caller rather than dropping the utility from the rule.
Driver installers and hardware update agents that read HKLM\SYSTEM\CurrentControlSet\Services with reg query during a version check before writing their own service entry, which fires once per managed device per update cycle.
Helpdesk and engineering troubleshooting of a device or service fault, where a human queries the Services key by hand or dumps the driver list before escalating a ticket.

Noise check0 of 30 fired

Fires on none of the 30 ordinary behaviours the baseline holds for this log type. That is not a precision guarantee: it means only not caught by these 30 behaviours, and the next ordinary behaviour nobody wrote down may still match.

Run live against 65 hand-written events of ordinary corporate activity — backup agents, software distribution, patching, helpdesk scripts, EDR. It says nothing about how often the rule would fire in production, which is the number that actually exhausts an analyst.

Verification1 run

Not verified

Siemphony benign baseline
completed
Siemphony IR · 3 Sept 2026
No events matched, so this run proves nothing either way.

Test it yourselfin your browser

Runs here in your browser against public attack recordings. A preview — not the verification badge.

Recordings of T1652, evaluated against their process_creation events.

Share this rule

/u/siemphony/cafc5b23-171f-4764-90e7-0596e5535099

More from this repertoire

All compositions

Verdicts · reactions · comments

Community

Verdicts from engineers who actually deployed it, and the conversation around it.

Not yet reported on

Nobody has run this in a real environment and said what happened.

Verdicts from engineers who deployed it

0 cast

No verdicts reported yet. The first one is worth more than the tenth — say what you ran it against.

No comments yet. Someone who deploys this will have something to say about it.

Driver enumeration by command line or services-key query

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it