Command line enumerating attached peripheral or USB devices

Siemphony@siemphonylowT1120unverified

Matches AN1353's Windows leg directly on the command line: the `Get-PnpDevice` PowerShell cmdlet MITRE names, and the `Win32_USBController` WMI class from its own `wmic path Win32_USBController` example, extended here — not by MITRE — to the closely related `Win32_PnPEntity` class that enumerates all Plug and Play hardware rather than only USB controllers, since both are reached through the same wmic/PowerShell WMI query surface AN1353 targets. The analytic's Sysmon EventID 10 process-access leg, which would show the enumeration reading device-manager or driver-store handles, is a separate event from process creation and is not expressed here. Peripheral discovery is inherently low-signal: the commands this rule matches are the same ones IT inventory tooling and helpdesk troubleshooting run constantly, so this rule is a lead for correlation, not a standalone incident indicator. UNVERIFIED AS AUTHORED — derived from MITRE ATT&CK DET0491, 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 "Get-PnpDevice" or ProcessCommandLine contains "Win32_USBController" or ProcessCommandLine contains "Win32_PnPEntity")

Splunk · SPL

Run this as a search.

index=* (CommandLine="*Get-PnpDevice*" OR CommandLine="*Win32_USBController*" OR CommandLine="*Win32_PnPEntity*")

Elastic · ES|QL

Run this as a search.

FROM logs-*| WHERE (TO_LOWER(process.command_line) LIKE "*get-pnpdevice*" OR TO_LOWER(process.command_line) LIKE "*win32_usbcontroller*" OR TO_LOWER(process.command_line) LIKE "*win32_pnpentity*")

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)(Get-PnpDevice|Win32_USBController|Win32_PnPEntity)</field>    <description>Command line enumerating attached peripheral or USB devices</description>    <mitre>      <id>T1120</id>    </mitre>  </rule></group>

At a glance

Logsource: process_creation / windows
Level: low
Category: discovery_recon
Sigma status: experimental
Backends: 4 of 4 rendered
Updated: 30 Aug 2026
Rule ID: 2401243f-b474-4644-971c-d7697c901039

ATT&CKT1120

T1120Peripheral Device 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.

Lessondiscovery recon

discovery reconAI draft — unreviewed

01 · What this rule detects

This rule catches the Windows command-line half of AN1353: someone running Get-PnpDevice in PowerShell, or querying the WMI classes Win32_USBController or Win32_PnPEntity, to enumerate attached peripheral and USB hardware. That's discovery, not collection — an adversary building a picture of what's plugged into the box before deciding what to do with it (mount removable media, target a smart-card reader, and so on). The rule only proves the enumeration command ran; it says nothing about what happened next.

02 · Telemetry you need

The logsource is process_creation / windows, copied verbatim from the brief — this is either Sysmon EventID 1 or Security EventID 4688 with command-line auditing enabled. If you're on 4688, remember the Audit Process Creation policy and the separate Include command line in process creation events policy both have to be turned on, or the CommandLine field this rule keys on is simply empty and the rule silently returns nothing. The brief also lists a second leg for AN1353 — Sysmon EventID 10, process_access, which would show the enumeration reading device-manager or driver-store handles — but that leg is not implemented here. This rule is command-line-only.

03 · How the logic works

There's one selection block: CommandLine|contains any of the three strings, condition: selection. No chaining, no correlation. Attribution matters here: Get-PnpDevice and Win32_USBController are MITRE's own examples in the brief (the latter straight from MITRE's wmic path Win32_USBController illustration). Win32_PnPEntity is the rule author's own addition — a broader WMI class covering all Plug-and-Play hardware, not just USB controllers — reasoned by analogy, not sourced from MITRE. The brief's mutableElements for AN1353 name three tuning knobs: CommandLineRegex (populated here with the three terms above), TimeWindow (grouping discovery with follow-on device access), and UserContext (filtering accounts known to run this legitimately). Only the first is implemented. TimeWindow and UserContext need aggregation or a lookup against an allowlist, and Sigma as modeled in this corpus's lib/sigma has no | count() by, no near, no timeframes — so any knob that means "correlate across events" simply can't be expressed as a condition here. That's normal for this corpus, not a gap specific to this rule: this detection is precursor-only, a lead for a human or a downstream correlation rule to chain, never a standalone verdict.

04 · Common false positives

The rule's own falsepositives name three real sources, in descending order of volume: fleet-wide RMM and IT asset-inventory tools (SCCM, Intune, Datto, NinjaRMM) running these same queries on a schedule across every managed endpoint — called out as the largest single source, which is exactly why level is set to low rather than higher; helpdesk technicians running Get-PnpDevice by hand to diagnose a bad webcam or printer; and post-install driver-verification scripts. Beyond those, the reviewer caught something the false-positive list can't capture: a coverage gap. Get-PnpDevice only lands on CommandLine when the cmdlet text is typed inline, e.g. powershell.exe -Command "Get-PnpDevice...". A discovery script launched as powershell.exe -File inventory.ps1 puts none of that cmdlet text on the process command line — so a scripted attack using that exact cmdlet is invisible to this selector. The WMI-class terms are more durable because wmic.exe invocations are typically self-contained one-liners rather than sourced from a file. Separately, direct WMI/COM API calls from a compiled binary, bypassing wmic.exe and PowerShell entirely, leave no command line to match at all.

05 · Detection maturity

tier_1: UNVERIFIED — the lowest tier. This rule has never been run against real data, so there's no measured false-positive rate, no hit count, and no tuning derived from observation; everything above is reasoning from the logic and the brief, not evidence.

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

To close the -File blind spot, add a companion selector against PowerShell Script Block Logging (Event ID 4104), which captures cmdlet text regardless of invocation style — but that logging is off by default and has to be enabled first. To act on UserContext, add a filter excluding the specific RMM/inventory service accounts once you've identified them in your estate. TimeWindow isn't something to add to this Sigma rule at all; it belongs in whatever correlates this alert with a subsequent removable-media mount event downstream.

Declared by the author

Fleet-wide IT asset-inventory and RMM agents (SCCM, Intune, Datto, NinjaRMM and similar) that run Get-PnpDevice or WMI hardware queries on every managed endpoint on a recurring schedule — in most enterprise estates this is the largest single source of matches, which is why the level below is set low rather than higher.
Helpdesk and desktop-support troubleshooting, where a technician runs Get-PnpDevice or queries Win32_PnPEntity by hand to diagnose a malfunctioning printer, webcam or USB peripheral a user has reported.
Driver installation and Windows Update post-install scripts that enumerate Plug and Play devices to verify a driver bound correctly, which runs automatically after routine driver updates.

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 T1120, evaluated against their process_creation events.

Share this rule

/u/siemphony/2401243f-b474-4644-971c-d7697c901039

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.

Command line enumerating attached peripheral or USB devices

The detection

detection.yml

Sentinel · KQL

Splunk · SPL

Elastic · ES|QL

Wazuh · XML rule

Community

Verdicts from engineers who deployed it