T1200

Hardware Additions

Initial Access Last updated:

Adversaries may physically introduce computer accessories, networking hardware, or other computing devices into a system or network to gain access or expand capabilities. Hardware additions range from passive network taps (Throwing Star LAN Tap) to active keystroke injection devices (USB Rubber Ducky, Bash Bunny, O.MG Cable), rogue wireless access points, DMA attack devices (PCILeech), and fully autonomous compute devices (Raspberry Pi, netbooks) providing persistent network footholds. Unlike purely software-based attacks, hardware additions require physical proximity to target systems and can bypass many software security controls by presenting as trusted peripherals. The DarkVishnya threat group is documented connecting Bash Bunny, Raspberry Pi, and inexpensive netbooks directly to victim organization networks to establish persistent access and conduct internal reconnaissance. Detection relies primarily on monitoring for unexpected device class connections via Windows Plug and Play audit events, correlating new HID device connections with subsequent automated keystroke injection patterns, and identifying new network interfaces with unknown MAC addresses appearing on internal segments.

What is T1200 Hardware Additions?

Hardware Additions (T1200) maps to the Initial Access tactic — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for Hardware Additions, covering the data sources and telemetry it touches: Driver: Driver Load, Hardware: Hardware, Windows Security Event Log, Plug and Play Activity. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access
Technique
T1200 Hardware Additions
Canonical reference
https://attack.mitre.org/techniques/T1200/
Microsoft Sentinel / Defender
kusto 
// T1200 Hardware Additions — Detects suspicious USB/HID/network device connections via Security Event 6416
// Requires: Advanced Audit Policy > Detailed Tracking > Audit PNP Activity = Success
let KnownPentestVIDs = dynamic([
    "VID_2B04",  // Hak5 (Bash Bunny, Rubber Ducky, LAN Turtle, Signal Owl)
    "VID_16D0",  // MCS / Digispark ATTiny85 HID injectors
    "VID_2E8A",  // Raspberry Pi Foundation (Pi Pico USB gadget mode)
    "VID_2341",  // Arduino (commonly repurposed for HID attacks)
    "VID_1B4F",  // SparkFun Electronics (BadUSB research boards)
    "VID_221A",  // ZTEX USB FPGA (DMA research hardware)
    "VID_04D8"   // Microchip Technology (common in DIY HID injectors)
]);
let LegitimatePeripheralVIDs = dynamic([
    "VID_045E",  // Microsoft
    "VID_046D",  // Logitech
    "VID_05AC",  // Apple
    "VID_413C",  // Dell
    "VID_03F0",  // HP
    "VID_17EF",  // Lenovo
    "VID_047D",  // Kensington
    "VID_046A",  // Cherry
    "VID_1B1C",  // Corsair
    "VID_1532",  // Razer
    "VID_1038",  // SteelSeries
    "VID_04B3",  // IBM
    "VID_04CA",  // Lite-On Technology
    "VID_0461"   // Primax Electronics
]);
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 6416
| parse EventData with * 'Name="ClassName">' ClassName '</Data>' *
| parse EventData with * 'Name="DeviceId">' DeviceId '</Data>' *
| parse EventData with * 'Name="HardwareIds">' HardwareIds '</Data>' *
| parse EventData with * 'Name="ClassId">' ClassId '</Data>' *
| parse EventData with * 'Name="SubjectUserName">' SubjectUserName '</Data>' *
| parse EventData with * 'Name="SubjectDomainName">' SubjectDomain '</Data>' *
| extend IsHIDDevice = ClassName =~ "HIDClass"
| extend IsNetworkDevice = ClassName in~ ("Net", "WLAN", "Bluetooth", "Net Service")
| extend IsKnownPentestVID = HardwareIds has_any (KnownPentestVIDs)
| extend IsLegitimateVendor = HardwareIds has_any (LegitimatePeripheralVIDs)
| extend IsSuspiciousHID = IsHIDDevice and not IsLegitimateVendor and HardwareIds !has "Mouse" and HardwareIds !has "Keyboard"
| extend IsSuspiciousNetDevice = IsNetworkDevice and not IsLegitimateVendor and (DeviceId has "USB" or HardwareIds has "USB")
| extend SuspicionScore = toint(IsKnownPentestVID) * 3 + toint(IsSuspiciousHID) + toint(IsSuspiciousNetDevice)
| where SuspicionScore > 0 or IsKnownPentestVID
| extend RiskReason = case(
    IsKnownPentestVID, "Known pentest/attack hardware VID detected",
    IsSuspiciousHID, "Unknown vendor HID device — possible keystroke injector",
    IsSuspiciousNetDevice, "Unknown USB network device — possible LAN tap or rogue adapter",
    "Suspicious device class connection")
| project TimeGenerated, Computer, SubjectUserName, SubjectDomain, EventID,
         ClassName, ClassId, DeviceId, HardwareIds,
         IsHIDDevice, IsNetworkDevice, IsKnownPentestVID, SuspicionScore, RiskReason
| sort by SuspicionScore desc, TimeGenerated desc

Detects suspicious hardware additions using Windows Security Event ID 6416 (A new external device was recognized by the System), which fires when Plug and Play device audit is enabled. Filters for HID devices from unknown or known-pentest vendors, USB-connected network adapters not from recognized peripheral manufacturers, and specific Vendor IDs (VIDs) associated with penetration testing and attack hardware (Hak5 products, Digispark, Raspberry Pi Pico in gadget mode, Arduino). Assigns a suspicion score to prioritize alerts: known pentest VIDs score 3, unknown-vendor HID devices and USB network adapters score 1 each. Requires Advanced Audit Policy — Detailed Tracking — Audit PNP Activity enabled on target systems.

high severity medium confidence

Data Sources

Driver: Driver Load Hardware: Hardware Windows Security Event Log Plug and Play Activity

Required Tables

SecurityEvent

False Positives

  • IT administrators and developers connecting legitimate USB development boards (Arduino, Raspberry Pi Pico for hobby projects) — VIDs overlap with those used for attacks
  • Employees connecting unrecognized third-party peripherals (generic USB keyboards, mice, USB-to-Ethernet adapters from lesser-known brands) not in the approved vendor list
  • Virtual machine host software creating virtual network adapters (VMware VMXNET, Hyper-V Virtual Network Adapter) that trigger device connection events
  • OT/SCADA technicians connecting USB-to-Serial or USB-to-RS485 adapters for legitimate industrial equipment management
  • Laptop docking stations presenting built-in NICs as new USB network devices when first connected to a new dock

Sigma rule & cross-platform mapping

The detection logic for Hardware Additions (T1200) 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:
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for T1200 Sigma rules on detection.fyi

Platform-specific guides for T1200

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-04-19 Research depth: deep
References (8)

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 1Install Microsoft Loopback Network Adapter via devcon

    Expected signal: Windows Security Event ID 6416: ClassName=Net, ClassId={4d36e972-e325-11ce-bfc1-08002be10318}, DeviceId=ROOT\NET\0001 or similar, HardwareIds=*MSLOOP. Windows System Event IDs 20001 and 20003 in System log for driver installation. Entry in C:\Windows\INF\setupapi.dev.log with timestamp and INF path.

  2. Test 2Enumerate Connected HID Devices via PowerShell

    Expected signal: Sysmon Event ID 1: Process Create with Image=powershell.exe and CommandLine containing 'Get-PnpDevice' and 'HIDClass'. Security Event ID 4688 (if command line auditing enabled). PowerShell ScriptBlock Log Event ID 4104 with the full device enumeration script.

  3. Test 3Query USB Device Connection History via Registry

    Expected signal: Sysmon Event ID 1: Process Create for reg.exe with CommandLine containing 'HKLM\SYSTEM\CurrentControlSet\Enum\USB'. Sysmon Event ID 1 also for findstr.exe. Security Event ID 4688 (if enabled) for both processes. Registry access events may be logged depending on SACL configuration.

  4. Test 4Simulate Keystroke Injection via PowerShell SendKeys

    Expected signal: Sysmon Event ID 1: Process Create for powershell.exe initiated by the calling process, plus any processes spawned by the injected keystrokes. If Sysmon monitors for the parent process chain, keystrokes injected into an Explorer window will show explorer.exe as parent. PowerShell ScriptBlock Log Event ID 4104 for both the outer and any inner PowerShell sessions.

Response Playbook

Triage

  1. Identify the physical location of the affected endpoint — check building access logs, badge swipes, and CCTV footage for who had physical access to the device in the time window around the alert. Hardware additions require physical presence.
  2. Review the full device connection record: ClassName, HardwareIds (VID/PID), ClassId, and SubjectUserName from the Event 6416 data. Look up the VID at https://devicehunt.com/ or usb-ids.gowdy.ca to identify the manufacturer and specific device model.
  3. Check for subsequent process creation events on the same host within 5 minutes of device connection — especially cmd.exe, powershell.exe, or mshta.exe spawned from explorer.exe, winlogon.exe, or userinit.exe, which may indicate keystroke injection execution.
  4. Review DeviceNetworkEvents or Sysmon Event ID 3 for new outbound connections from the endpoint occurring shortly after the device connection event — a rogue USB-to-Ethernet adapter or wireless adapter may establish C2 communications immediately.
  5. Check Windows System Event Log (Event IDs 20001, 20003) and C:\Windows\INF\setupapi.dev.log for driver installation details, which may reveal exact device make and model not captured in Event 6416.
  6. For HID device alerts: determine if the connected device was logged in an IT asset management system or approved peripheral registry. An unregistered keyboard or HID device on a server or unattended endpoint is a strong indicator of attack.
  7. Query the registry key HKLM\SYSTEM\CurrentControlSet\Enum\USB\ on the affected host to enumerate all USB devices ever connected, not just the most recent, to identify if this is a recurring pattern.

Containment

  1. If physical access was unauthorized or the device is unaccounted for: physically inspect the endpoint immediately to locate and remove any foreign hardware. Document and photograph all connected devices before removal for evidence preservation.
  2. If keystroke injection or command execution is confirmed: isolate the endpoint from the network immediately using EDR isolation or VLAN quarantine before the payload can beacon or spread.
  3. If a rogue USB network adapter or LAN tap is suspected: scan the internal network segment for new MAC addresses (using arp -a on neighboring systems or DHCP lease analysis) to identify the rogue device's network footprint.
  4. Disable automatic driver installation for unauthorized device classes via Group Policy: Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions > Prevent installation of devices not described by other policy settings.
  5. If the device was connected to a conference room, lobby, or shared workstation: check all physically accessible Ethernet ports on the same network segment for inline LAN taps (Throwing Star, Douleur) that may have been installed passively and would not generate Event 6416.
  6. Rotate credentials for the user account active on the system at time of device connection — keystroke injection attacks often harvest typed credentials or inject commands to dump credential stores.

Evidence Collection

  1. Windows Security Event Log — Event ID 6416 (A new external device was recognized): contains ClassName, ClassId, DeviceId, HardwareIds, CompatibleIds, LocationInformation, and connecting user account.
  2. Windows System Event Log — Event IDs 20001 (device driver installed) and 20003 (device needs drivers): provides additional device installation context and driver file paths.
  3. C:\Windows\INF\setupapi.dev.log — Windows Setup API log recording every device installation attempt with timestamps, device descriptions, INF files used, and any driver signing errors.
  4. Registry: HKLM\SYSTEM\CurrentControlSet\Enum\USB\ — complete history of every USB device ever connected to the system, including timestamps (via $MFT analysis of registry hive modification times), VID/PID, serial numbers, and driver bindings.
  5. Registry: HKLM\SYSTEM\CurrentControlSet\Enum\HID\ — HID device history including device descriptions, hardware IDs, and parent USB device relationships.
  6. Microsoft-Windows-Kernel-PnP/Configuration event log and Microsoft-Windows-DriverFrameworks-UserMode/Operational event log — detailed PnP subsystem activity including device arrival, driver binding, and power state changes.
  7. Network ARP cache on adjacent hosts and managed switch port MAC address tables — to identify new MAC addresses that appeared on the segment after device connection.
  8. Physical inspection report — photograph all accessible ports, physically examine the device for tamper evidence, document serial numbers of all peripherals, and check for inline devices on Ethernet runs between wall jacks and endpoints.
  9. PowerShell history and command execution logs — if keystroke injection occurred, commands may appear in PSReadLine history at $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt

Escalation Criteria

  • ! Known pentest hardware VID detected (VID_2B04 Hak5, VID_16D0 Digispark, VID_2E8A Raspberry Pi Pico) — these are purpose-built attack tools and rarely have legitimate enterprise use.
  • ! Process execution detected within 60 seconds of HID device connection, especially cmd.exe or powershell.exe spawned from explorer.exe or winlogon.exe with no corresponding user interaction — strong indicator of keystroke injection payload.
  • ! New network interface with unknown MAC address appeared on an internal segment coinciding with device connection event, followed by outbound connections to external IPs — indicates rogue network tap or implant establishing C2.
  • ! Device connected to a server room, data center endpoint, network closet, or any system that should not have peripherals connected — physical access to infrastructure should be treated as critical.
  • ! Multiple endpoints across different physical locations showing similar unknown device connection events in a short time window — may indicate coordinated physical access operation.
  • ! Device connection event occurring outside business hours or during known employee absence (overnight, weekends, holidays) with no associated change ticket or authorized access record.

Investigation Guide

Forensic Artifacts

  • > Registry: HKLM\SYSTEM\CurrentControlSet\Enum\USB\[VID_XXXX&PID_XXXX] — full device enumeration history with device serial numbers (USB iSerialNumber), friendly names, and parent hub path. Each subkey's LastWriteTime indicates first connection.
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Enum\HID\ — HID device history mapping HID collections back to their parent USB device entries.
  • > Registry: HKLM\SYSTEM\CurrentControlSet\Enum\USBSTOR\ — USB storage device history (if Bash Bunny or similar device was used in storage mode prior to attack mode).
  • > File: C:\Windows\INF\setupapi.dev.log — timestamped device installation history with full device paths, INF files, and driver signing results. Essential for determining exact time of hardware attachment.
  • > Windows Event Log: Security/6416 — requires Audit PNP Activity enabled. Contains ClassName, ClassId, HardwareIds (VID/PID/REV), and LocationInformation (hub/port path).
  • > Windows Event Log: Microsoft-Windows-Kernel-PnP/Configuration — Event IDs 400/410 for device arrival/removal with detailed PnP subsystem context.
  • > Windows Event Log: Microsoft-Windows-DriverFrameworks-UserMode/Operational — driver installation and binding events with process context.
  • > File: C:\Windows\Prefetch\ — if keystroke injection executed programs (e.g., POWERSHELL.EXE, CMD.EXE), prefetch files record execution timestamps and loaded DLLs corroborating the injection timeline.
  • > Network: DHCP server lease logs — new IP assignments to unknown MAC addresses on internal VLANs following the device connection event indicate a rogue network interface.
  • > Network: Managed switch MAC address tables (show mac address-table) — persist new MAC addresses on specific switch ports, allowing physical location identification of rogue hardware.

Tuning Guidance

Hardware addition detection requires significant baselining to avoid alert fatigue. Begin by running the hunting query (VID/PID inventory) against 30 days of Event 6416 data before activating the main detection — this reveals the legitimate peripheral landscape in your environment and allows you to extend the LegitimatePeripheralVIDs list accordingly. Key tuning steps: (1) Add VIDs for peripherals your organization issues (corporate keyboard/mouse VIDs, USB dock manufacturers) to the allowlist. (2) Create exclusions for specific computer names or OUs that legitimately connect diverse USB hardware — developer workstations, IT helpdesk machines, and A/V production systems typically connect more diverse device classes. (3) For server endpoints and kiosk machines where NO peripheral connections should occur, set severity to critical and remove all VID exclusions — any Event 6416 from these hosts warrants immediate investigation. (4) The keystroke injection correlation query is high-fidelity but requires that both Security Event auditing and Sysmon process monitoring be deployed. (5) Ensure Audit PNP Activity is enabled via GPO: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Detailed Tracking > Audit PNP Activity = Success. This is enabled by default on Windows 10 1703+ and Server 2016+ but may need explicit enabling on older systems. (6) Consider implementing USB device control via Windows Defender Device Control or Group Policy (Computer Configuration > Administrative Templates > System > Removable Storage Access) to block unauthorized device classes at the endpoint as a preventive control alongside detection.

Hunting Queries

Correlates new HID device connections (Event 6416) with shell process execution within 5 minutes on the same host. A standard user's HID device connection followed by cmd.exe or PowerShell spawning from explorer.exe or winlogon.exe is a strong indicator of keystroke injection payload delivery. The short time window (300 seconds) reduces false positives from coincidental administrative activity.

Hunting — KQL
kql 
// Hunt: Rapid process execution shortly after HID device connection — potential keystroke injection
let HIDConnections = SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 6416
| parse EventData with * 'Name="ClassName">' ClassName '</Data>' *
| where ClassName =~ "HIDClass"
| project HIDConnectTime=TimeGenerated, Computer;
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ("cmd.exe", "powershell.exe", "wscript.exe", "mshta.exe", "rundll32.exe")
| where InitiatingProcessFileName in~ ("explorer.exe", "winlogon.exe", "userinit.exe")
| join kind=inner HIDConnections on $left.DeviceName == $right.Computer
| where abs(datetime_diff('second', Timestamp, HIDConnectTime)) < 300
| project Timestamp, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, HIDConnectTime,
         SecondsAfterHIDConnect=datetime_diff('second', Timestamp, HIDConnectTime)
| sort by SecondsAfterHIDConnect asc
Hunting — SPL
spl 
index=wineventlog sourcetype="WinEventLog:Security" EventCode=6416
| rex field=EventData "Name=\"ClassName\">(?P<ClassName>[^<]+)<"
| where lower(ClassName)="hidclass"
| rename _time as HIDConnectTime, host as HIDHost
| table HIDConnectTime, HIDHost
| join type=inner HIDHost [
    search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
        (Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\mshta.exe" OR Image="*\\wscript.exe")
        (ParentImage="*\\explorer.exe" OR ParentImage="*\\winlogon.exe" OR ParentImage="*\\userinit.exe")
    | rename host as HIDHost, _time as ProcessTime
    | table ProcessTime, HIDHost, Image, CommandLine, ParentImage
]
| eval SecondsAfterHID=ProcessTime - HIDConnectTime
| where SecondsAfterHID > 0 AND SecondsAfterHID < 300
| table HIDConnectTime, ProcessTime, HIDHost, Image, CommandLine, ParentImage, SecondsAfterHID
| sort SecondsAfterHID

Hunts for external network connections occurring within 60 minutes of a new network-class device being connected. A USB-to-Ethernet adapter or rogue wireless card establishing external connectivity shortly after being attached is a high-fidelity indicator of a hardware network implant (LAN Turtle, Bash Bunny in network mode, Raspberry Pi with cellular modem) establishing a C2 channel.

Hunting — KQL
kql 
// Hunt: New MAC addresses appearing on internal network segments after device connection events
let DeviceConnectionHosts = SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 6416
| parse EventData with * 'Name="ClassName">' ClassName '</Data>' *
| where ClassName in~ ("Net", "WLAN", "Bluetooth")
| summarize FirstSeen=min(TimeGenerated) by Computer
| project Computer, FirstSeen;
DeviceNetworkEvents
| where Timestamp > ago(7d)
| where RemoteIPType == "Public" or (RemotePort in (4444, 8443, 1337, 31337, 443, 80))
| join kind=inner DeviceConnectionHosts on $left.DeviceName == $right.Computer
| where Timestamp > FirstSeen
| where abs(datetime_diff('minute', Timestamp, FirstSeen)) < 60
| project Timestamp, DeviceName, RemoteIP, RemotePort, RemoteUrl, LocalIP,
         InitiatingProcessFileName, InitiatingProcessCommandLine, FirstSeen,
         MinutesAfterDeviceConnect=datetime_diff('minute', Timestamp, FirstSeen)
| sort by MinutesAfterDeviceConnect asc
Hunting — SPL
spl 
index=wineventlog sourcetype="WinEventLog:Security" EventCode=6416
| rex field=EventData "Name=\"ClassName\">(?P<ClassName>[^<]+)<"
| where match(lower(ClassName), "(^net$|wlan|bluetooth)")
| rename _time as DeviceConnectTime, host as NetHost
| table DeviceConnectTime, NetHost
| join type=inner NetHost [
    search index=wineventlog sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=3
        NOT (DestinationIp="10.*" OR DestinationIp="172.16.*" OR DestinationIp="192.168.*" OR DestinationIp="127.*")
    | rename host as NetHost, _time as ConnectTime
    | table ConnectTime, NetHost, SourceIp, DestinationIp, DestinationPort, Image
]
| eval MinutesAfterDevice=(ConnectTime - DeviceConnectTime) / 60
| where MinutesAfterDevice > 0 AND MinutesAfterDevice < 60
| table DeviceConnectTime, ConnectTime, NetHost, SourceIp, DestinationIp, DestinationPort, Image, MinutesAfterDevice
| sort MinutesAfterDevice

Builds a 30-day baseline of all USB Vendor IDs and Product IDs seen across the environment and surfaces devices observed on only a single host. Legitimate enterprise peripherals typically appear across many hosts; a device seen only once on one machine — especially with an unknown VID — is statistically anomalous and warrants physical investigation. Use devicehunt.com or usb-ids.gowdy.ca to look up VID/PID combinations identified by this query.

Hunting — KQL
kql 
// Hunt: Enumerate all unique USB VIDs/PIDs seen across the environment to identify outliers
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 6416
| parse EventData with * 'Name="ClassName">' ClassName '</Data>' *
| parse EventData with * 'Name="HardwareIds">' HardwareIds '</Data>' *
| parse EventData with * 'Name="DeviceId">' DeviceId '</Data>' *
| where HardwareIds has "VID_"
| extend VID = extract("VID_([0-9A-Fa-f]{4})", 1, HardwareIds)
| extend PID = extract("PID_([0-9A-Fa-f]{4})", 1, HardwareIds)
| summarize HostCount=dcount(Computer), ConnectionCount=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), SampleHardwareIds=any(HardwareIds) by VID, PID, ClassName
| where HostCount == 1  // Seen on only one host — unusual devices stand out
| sort by FirstSeen desc
Hunting — SPL
spl 
index=wineventlog sourcetype="WinEventLog:Security" EventCode=6416 earliest=-30d
| rex field=EventData "Name=\"HardwareIds\">(?P<HardwareIds>[^<]+)<"
| rex field=EventData "Name=\"ClassName\">(?P<ClassName>[^<]+)<"
| rex field=HardwareIds "VID_(?P<VID>[0-9A-Fa-f]{4})"
| rex field=HardwareIds "PID_(?P<PID>[0-9A-Fa-f]{4})"
| where isnotnull(VID)
| stats dc(host) as HostCount, count as ConnectionCount, earliest(_time) as FirstSeen, latest(_time) as LastSeen, values(HardwareIds) as SampleHardwareIds by VID, PID, ClassName
| where HostCount=1
| sort FirstSeen desc

Atomic Red Team Tests

Test 1 Install Microsoft Loopback Network Adapter via devcon
windows

Installs the Microsoft Loopback Adapter using devcon.exe, which triggers Windows Security Event 6416 with ClassName=Net and a device ID prefixed with *MSLOOP. This simulates the telemetry generated when an adversary connects a USB-to-Ethernet adapter, LAN Turtle, or rogue USB NIC. Requires devcon.exe from the Windows Driver Kit (WDK) or the Windows Hardware Lab Kit. The loopback adapter is a signed Microsoft driver and safe to install/remove in test environments. Run as Administrator.

Command

powershell 
devcon.exe install %SystemRoot%\inf\netloop.inf *MSLOOP

Cleanup

powershell 
devcon.exe remove *MSLOOP

Expected Telemetry

Windows Security Event ID 6416: ClassName=Net, ClassId={4d36e972-e325-11ce-bfc1-08002be10318}, DeviceId=ROOT\NET\0001 or similar, HardwareIds=*MSLOOP. Windows System Event IDs 20001 and 20003 in System log for driver installation. Entry in C:\Windows\INF\setupapi.dev.log with timestamp and INF path.

Expected Detection

KQL: IsNetworkDevice=true, IsSuspiciousNetDevice=true if *MSLOOP is not in LegitimatePeripheralVIDs (it won't contain a USB VID, so it may not score). For more targeted testing, note that actual USB network adapters will have USB\VID_XXXX&PID_XXXX hardware IDs. SPL: IsNetworkDevice=1, observable in WinEventLog:Security EventCode=6416.

Test 2 Enumerate Connected HID Devices via PowerShell
windows

Uses PowerShell Get-PnpDevice to enumerate all connected HID class devices, listing their status, friendly name, and hardware instance ID. This simulates post-connection reconnaissance an analyst would perform and generates process creation telemetry consistent with an attacker inventorying the connected HID implant. Also extracts USB VIDs/PIDs from instance IDs to demonstrate identification of attack hardware signatures.

Command

powershell 
powershell.exe -Command "Get-PnpDevice -Class HIDClass | Select-Object Status, FriendlyName, InstanceId | ForEach-Object { $vid = if ($_.InstanceId -match 'VID_([0-9A-F]{4})') { $matches[1] } else { 'N/A' }; $pid_ = if ($_.InstanceId -match 'PID_([0-9A-F]{4})') { $matches[1] } else { 'N/A' }; [PSCustomObject]@{Status=$_.Status; FriendlyName=$_.FriendlyName; InstanceId=$_.InstanceId; VID=$vid; PID=$pid_} } | Format-Table -AutoSize"

Expected Telemetry

Sysmon Event ID 1: Process Create with Image=powershell.exe and CommandLine containing 'Get-PnpDevice' and 'HIDClass'. Security Event ID 4688 (if command line auditing enabled). PowerShell ScriptBlock Log Event ID 4104 with the full device enumeration script.

Expected Detection

Process creation detection for PowerShell executing device enumeration commands. Not directly detected by the T1200 KQL/SPL (which focuses on Event 6416), but provides visibility into an adversary performing device inventory after connection. Combine with T1059.001 detections.

Test 3 Query USB Device Connection History via Registry
windows

Queries the Windows registry for USB device connection history stored under HKLM\SYSTEM\CurrentControlSet\Enum\USB. This key persists all USB devices ever connected to the system, including hardware IDs (VID/PID), device serial numbers, and friendly names. Adversaries performing reconnaissance may query this to understand what security devices are connected; defenders use this to identify rogue hardware attachments. The query generates process creation telemetry for reg.exe.

Command

powershell 
reg query "HKLM\SYSTEM\CurrentControlSet\Enum\USB" /s /f "DeviceDesc" /t REG_SZ 2>nul | findstr /i "VID_\|DeviceDesc\|Hak5\|Bash\|Rubber\|Ducky\|Armory\|Turtle"

Expected Telemetry

Sysmon Event ID 1: Process Create for reg.exe with CommandLine containing 'HKLM\SYSTEM\CurrentControlSet\Enum\USB'. Sysmon Event ID 1 also for findstr.exe. Security Event ID 4688 (if enabled) for both processes. Registry access events may be logged depending on SACL configuration.

Expected Detection

Process creation detection for registry enumeration of USB device history. Cross-reference output with known pentest VIDs. The presence of VID_2B04 (Hak5), VID_16D0 (Digispark), or VID_2E8A (Raspberry Pi) in this output on a production system indicates historical hardware addition attack tool connection.

Test 4 Simulate Keystroke Injection via PowerShell SendKeys
windows

Simulates the type of command execution that results from a keystroke injection attack (USB Rubber Ducky, Bash Bunny HID mode, Digispark). Uses the Windows Shell.Application COM object to send keystrokes to the current desktop, similar to what an HID attack device would inject. This demonstrates the process chain (explorer.exe spawning child processes) that the hunting query looks for when correlating HID device connections with subsequent execution. Run from an interactive desktop session only.

Command

powershell 
powershell.exe -Command "$shell = New-Object -ComObject WScript.Shell; Start-Sleep -Milliseconds 500; $shell.SendKeys('powershell -Command Write-Host HID-Injection-Simulation{ENTER}')"

Expected Telemetry

Sysmon Event ID 1: Process Create for powershell.exe initiated by the calling process, plus any processes spawned by the injected keystrokes. If Sysmon monitors for the parent process chain, keystrokes injected into an Explorer window will show explorer.exe as parent. PowerShell ScriptBlock Log Event ID 4104 for both the outer and any inner PowerShell sessions.

Expected Detection

This test exercises the hunting query correlation — if preceded by Test 1 (loopback adapter installation) within 5 minutes on the same host, it will fire the 'Rapid process execution after HID device connection' hunting query. Direct T1200 detection requires Event 6416; this test demonstrates the downstream execution indicators.

Related Detections

Tactic Hub

TA0001Initial Access

Related Techniques

T1091Replication Through Removable MediaT1557Adversary-in-the-MiddleT1056.001KeyloggingT1040Network SniffingT1078Valid AccountsT1059.001PowerShellT1059.003Windows Command ShellT1133External Remote ServicesT1205Traffic SignalingT1601Modify System Image

Same Tactic: Initial Access

Popular Detections