Defending Against HID Injection: What Actually Works
HID injection works because operating systems are designed to trust keyboards. Plug in a USB device that presents as a keyboard, pair a Bluetooth device that presents as a keyboard, and the OS starts accepting input without authentication. That's the whole attack surface - and it's not a bug, it's a feature of how human interface devices work.
This means you can't "patch" HID injection the way you patch a software vulnerability. What you can do is layer defenses that make it harder to execute, limit the damage when it does execute, and detect when it's happening. Here's what actually works, what's limited in effectiveness, and what to prioritize for different environments.
Table of Contents
- Why HID Injection Is Hard to Defend Against Completely
- Physical Security: The First Layer
- OS-Level Device Policies: What Windows and macOS Offer
- Bluetooth-Specific Defenses
- Endpoint Security: What It Can and Can't Do
- User Training and Awareness
- Network-Level Detection
- MDM and Enterprise Device Management
- Prioritizing: What's Most Effective
Why HID Injection Is Hard to Defend Against Completely
The fundamental problem is that the OS can't tell the difference between a legitimate keyboard and a device pretending to be one. Both present the same USB class (03 = HID) or the same Bluetooth profile (HID over GATT). The device descriptor says "I am a keyboard." The OS loads the HID driver and starts processing input.
graph TD
subgraph "Layer 1 - Physical Security"
PHYS1[USB port locks/blockers]
PHYS2[Restricted physical access]
PHYS3[Security cameras at workstations]
end
subgraph "Layer 2 - OS Device Policies"
OS1[Windows GPO: block new HID devices]
OS2[macOS: Bluetooth device allowlist]
OS3[Linux: udev rules for USB filtering]
end
subgraph "Layer 3 - Endpoint Protection"
EP1[EDR keystroke velocity detection]
EP2[Behavioral analysis of input patterns]
EP3[USB device class whitelisting]
end
subgraph "Layer 4 - Network Detection"
NET1[Monitor for suspicious command execution]
NET2[Detect data exfiltration patterns]
NET3[Alert on new device connections]
end
subgraph "Layer 5 - User Training"
TRAIN1[Recognize unknown BT pairing requests]
TRAIN2[Report suspicious USB devices]
TRAIN3[Lock workstation policy]
end
PHYS1 --> OS1
PHYS2 --> OS2
OS1 --> EP1
OS2 --> EP2
EP1 --> NET1
EP2 --> NET2
NET1 --> TRAIN1
NET2 --> TRAIN2
Defense-in-depth layers against HID injection attacks - from physical controls to user awareness
There's no cryptographic authentication in USB HID. No certificate signing. No attestation. A USB device says it's a keyboard and the OS believes it. This is intentional - requiring authentication for keyboard input would make keyboards non-functional in pre-OS environments and would create accessibility problems for users with unusual input devices.
Bluetooth HID has pairing (and LE Secure Connections for BLE), but "Just Works" pairing - the standard mode for keyboards - provides no MITM protection and requires only that the user click "Accept" on a pairing prompt. The pairing model prevents random unapproved devices from connecting, but a user who is socially engineered into clicking Accept has effectively authorized the attack.
This context matters for choosing defenses: you're not patching a single vulnerability, you're reducing the probability and impact of a category of attacks.
Physical Security: The First Layer
USB HID injection requires physical access to a USB port. The most direct defense is controlling physical access to USB ports.
USB port blockers are physical plugs that fill unused USB ports. They require a key or tool to remove. These prevent opportunistic device insertion during brief physical access scenarios (tailgating, social engineering scenarios where an attacker has a few seconds near an unattended machine).
Machine placement matters. A workstation with USB ports facing the user is more visible than one with ports on the back or sides. Physical placement that makes it obvious when something is plugged in provides passive deterrence.
Visitor policies and unescorted access restrictions directly reduce the attack surface. An attacker who never gets near a machine can't plug anything in. This sounds obvious, but "social engineering resistance" - ensuring visitors don't have unaccompanied access to workstations - is often underimplemented.
Physical security is the most effective defense against USB Rubber Ducky-style attacks. Bluetooth HID attacks (like Bad-BT) require Bluetooth range but not physical USB access, so physical port security alone isn't sufficient for the full threat model.
OS-Level Device Policies: What Windows and macOS Offer
Windows has Device Installation Restrictions via Group Policy. This allows administrators to block USB devices by device class, device ID, or both. To block all USB HID devices except a pre-approved list:
Group Policy path: Computer Configuration > Administrative Templates > System > Device Installation > Device Installation Restrictions
The relevant policies are "Prevent installation of devices that match any of these device IDs" and "Allow installation of devices that match any of these device IDs" (with the "Prevent" policy taking effect when a device doesn't match the allow list).
USB Class Code for HID devices is 03. Blocking class 03 prevents all USB keyboards and mice from being installed - including legitimate ones. This makes the allow-list approach necessary: first allow all known-good device IDs, then block everything else. This is manageable in an enterprise with known inventory but complex for environments with diverse hardware.
Windows also supports Endpoint Protection Platform (EPP) policies that can restrict USB storage devices while leaving HID devices open. This is a more common enterprise deployment because users legitimately need keyboards and mice, even if flash drives should be blocked.
macOS in managed (MDM) environments can enforce similar restrictions through device management profiles. Unmanaged macOS is more permissive - consumer Macs don't have easily accessible device installation restriction policies outside of MDM.
Bluetooth-Specific Defenses
Bluetooth HID injection (like Bad-BT) requires a prior pairing. Defenses that target the pairing stage are effective:
Disable Bluetooth when not in use. A radio that's off can't receive pairing requests. This is the most effective Bluetooth defense but also the most friction-heavy - many users rely on Bluetooth peripherals and want it always on.
Remove unused Bluetooth pairings. Devices that are paired but not in use represent dormant attack surface. Periodically auditing and removing unrecognized or unused pairings reduces the risk of a previously-established unauthorized pairing.
Disable Swift Pair on Windows. Swift Pair auto-prompts for nearby pairable devices. Disabling it (Settings > Bluetooth > Show notifications to connect using Swift Pair > Off) reduces unsolicited pairing prompts, though it doesn't prevent manual pairing through Settings.
MDM Bluetooth policy. Enterprise MDM platforms (Intune, Jamf, etc.) can restrict which Bluetooth device types can pair. Some MDM configurations allow audio devices (headsets) but block HID devices. This is a significant defense against Bad-BT specifically.
Use "Secure Connections Only" mode if available. Some enterprise Bluetooth configurations require LE Secure Connections rather than LE Legacy. This doesn't prevent HID injection from an already-paired device but makes new pairing attempts slightly harder to manipulate.
Endpoint Security: What It Can and Can't Do
Antivirus and traditional endpoint security products cannot detect HID injection. The attack doesn't involve malware execution - it uses the keyboard input system, which is not a code execution vector that AV monitors. A payload that types "notepad" and opens Notepad looks exactly like a user typing "notepad" from the AV perspective.
Behavioral EDR (Endpoint Detection and Response) tools are more capable. They can monitor USB device insertion events and flag unusual patterns: a new HID device connecting and immediately generating high-volume keyboard input is an anomalous event. Tools like CrowdStrike, SentinelOne, and Microsoft Defender for Endpoint log USB device events with device ID, timestamp, and user context.
What EDR can detect:
- USB device insertion events (unusual device IDs)
- High-rate keyboard input immediately after device connection
- Keyboard input patterns that don't match typical human typing (regular spacing, non-random characters)
- Process creation events triggered by keyboard-driven automation (powershell.exe opened immediately after a new USB HID connected)
What EDR cannot reliably detect:
- Low-rate, human-like keystroke injection
- Bluetooth HID injection that mimics normal keyboard usage
- Injection that doesn't spawn new processes or make network connections
The detection capability is better for automated, high-speed injection (which EDR can flag as anomalous) and weaker for slow, deliberate injection designed to look like human typing.
User Training and Awareness
Users are the primary defense against Bluetooth HID attacks because pairing requires user interaction. Training should include:
Don't accept unexpected Bluetooth pairing prompts. A pairing prompt appearing without a known, expected reason is suspicious. Users should decline and report it to IT rather than clicking Accept out of habit.
Don't plug in unknown USB devices. Found a USB drive in the parking lot? Don't plug it in. Given a USB device by someone you don't know? Don't plug it in. This is basic security hygiene that directly addresses the USB Rubber Ducky attack vector.
Lock your screen when stepping away. A locked machine can't execute HID payloads - the injected keystrokes hit the lock screen, not the desktop. Windows+L, or configuring auto-lock after 1-2 minutes of inactivity, is a simple and highly effective defense. Many HID injection attacks rely on the machine being unlocked and unattended.
Report unusual behavior. If a computer starts doing things by itself - windows opening, applications launching, text typing without a person at the keyboard - that's an indicator worth reporting. Users who know what HID injection looks like can recognize it and report it.
Network-Level Detection
Many HID injection payloads eventually make network requests - opening a browser to a URL, running a command that downloads a file, initiating a reverse shell. Network monitoring provides a detection layer independent of the endpoint.
Outbound connections to unusual destinations from a workstation immediately after an anomalous event are a detection signal. DNS queries for unusual domains, HTTP/HTTPS to newly-registered or known-bad domains, or connections on unusual ports can all be flagged.
This doesn't prevent HID injection, but it can detect successful payloads that make network requests and provide incident response opportunity. Payloads that are purely local (opening Notepad, locking the screen, demonstrating HID access) won't generate network indicators.
MDM and Enterprise Device Management
For enterprises, MDM is the most scalable defense. Policies pushed to managed devices can enforce:
- USB device class restrictions (block HID class, allow only approved device IDs)
- Bluetooth HID restrictions (block keyboard/HID profile pairing)
- Auto-lock timers (reduce window for unattended machine attacks)
- Screen lock enforcement when Bluetooth keyboard disconnects
- Removal of unauthorized Bluetooth pairings on next MDM check-in
The Bluetooth keyboard restriction via MDM is specifically effective against Bad-BT. If the MDM policy prevents unknown Bluetooth keyboards from pairing, the Bad-BT attack vector is substantially closed. Some enterprise MDM configurations allow only devices enrolled in the company's device inventory to pair as BT keyboards.
MDM doesn't help with personally-managed machines (BYOD) or with machines where MDM enrollment hasn't happened. Consumer machines and small businesses without MDM are more exposed to HID injection attacks.
Prioritizing: What's Most Effective
In priority order for most environments:
- Screen lock enforcement (auto-lock after 2-3 minutes, require password to unlock). Eliminates unattended machine attacks entirely.
- User training on Bluetooth pairing prompts and unknown USB devices. Directly addresses the primary social engineering vector.
- MDM device policies if managing enterprise machines. Allows broad USB and Bluetooth restrictions at scale.
- Physical USB port control for high-security workstations (executives, finance, sensitive data handlers).
- EDR with USB device monitoring for detection and incident response capability.
- Bluetooth disabled when not in use on any machine in a sensitive environment.
What doesn't work: antivirus alone, NAC (network access control) alone, or relying on users to physically inspect every device that connects. These provide no defense against HID injection.
What works surprisingly well: screen lock. The vast majority of HID injection attacks require the machine to be logged in and unlocked. A machine that locks itself after 2 minutes of inactivity requires an attacker to complete their payload within that window. Short payloads can do this, but complex multi-stage payloads cannot. Enforcing a 2-minute auto-lock is the single cheapest, most impactful defense against this category of attack.
This article is for IT security professionals and system administrators. The defenses described are standard enterprise and consumer security practices.