Bad Bluetooth (Bad-BT): What It Is and How to Test Your Defenses

What Is a Bad Bluetooth (Bad-BT) Attack?

A Bad Bluetooth attack - commonly abbreviated as Bad-BT - is a wireless HID injection technique in which an attacker device impersonates a Bluetooth keyboard or mouse to inject keystrokes into a target machine. The victim's operating system sees a trusted input device and executes every command the attacker sends, all without a single cable or physical port interaction.

At its core, Bad-BT exploits the Human Interface Device (HID) profile of Bluetooth Low Energy (BLE). When a computer or phone accepts a BLE pairing request from what appears to be a keyboard, it hands that peripheral unrestricted text input access. There is no sandbox. There is no permission prompt for individual keystrokes. Once paired - or in the case of some attacks, without any pairing at all - the injected device can type at machine speed.

The result: arbitrary commands executed on the target in seconds, silently, from across the room.

Bad-BT and Its Wired Cousin: USB Rubber Ducky / BadUSB

If you've worked in penetration testing or followed red team tooling, the concept is immediately familiar. The USB Rubber Ducky popularized HID injection via a physical USB device that impersonates a keyboard. BadUSB extended the concept to reprogrammed USB firmware. Both rely on the same OS-level trust: if the device says it's a keyboard, the OS believes it.

Bad-BT is the wireless evolution of that same attack primitive. The critical difference - and the reason it represents an escalated threat - is that physical access is no longer required.

• USB Rubber Ducky: Attacker must plug a device into the target port. Requires momentary physical access or a socially engineered insider.
• Bad-BT: Attacker broadcasts from a concealed device up to 10-30 meters away. No port. No contact. No visible hardware on the target machine.

The payload logic is identical - scripted keystrokes, shell commands, reverse shells - but the delivery vector is now entirely wireless. That fundamentally changes your threat model.

Why Bad Bluetooth Attacks Matter for Security Teams

Traditional physical security controls do not stop a Bad-BT attack. Locked server rooms, port blockers, USB disable policies, and even full-disk encryption offer zero protection against a keystroke injected over the air before the OS has any reason to be suspicious.

Consider the attack surface in a typical enterprise environment:

• Open-plan offices where laptops sit unlocked at desks
• Conference rooms with always-on presentation machines
• Kiosk systems paired with Bluetooth peripherals
• Employees working in coffee shops or co-working spaces
• Any device with Bluetooth enabled and no active user monitoring it

In all of these scenarios, a Bad-BT capable device operated from a bag, a passing vehicle, or an adjacent seat can inject a full attack payload in under five seconds.

Modern operating systems - Windows, macOS, Linux, Android, iOS - all implement the BLE HID profile. None of them prompt users when a paired keyboard sends keystrokes. That's by design; the UX of asking "are you sure you want to type this?" would be unusable. Attackers exploit exactly that design assumption.

Bad-BT Attack Scenarios

1. Automated Keystroke Injection

The attacker pre-scripts a DuckyScript-style payload. Once the BLE connection is established, the payload executes automatically - opening a terminal, disabling security tools, or establishing persistence - faster than any human could type.

sequenceDiagram
    participant N as BLEShark Nano
    participant T as Target Device
    participant OS as Target OS
    N->>T: BLE Advertisement: HID Keyboard
    T->>T: Auto-accepts BLE pairing
    N->>OS: HID Report: Open Run dialog
    Note over OS: WIN+R or CMD+Space
    N->>OS: HID Report: Type command string
    N->>OS: HID Report: Press Enter
    Note over OS: Command executes with user privileges
    N->>OS: HID Report: Close terminal window
    Note over N,OS: Entire sequence completes in under 3 seconds

Bad-BT attack sequence - the BLEShark Nano impersonates a Bluetooth keyboard and injects keystrokes faster than the user can react

2. Reverse Shell and Payload Delivery

A classic red team scenario: inject keystrokes that download and execute a second-stage payload from an attacker-controlled server. The entire chain - from BLE connection to running malware - can complete in under 10 seconds on an unlocked machine.

3. Data Exfiltration via Keystrokes

Less obvious but equally dangerous: inject commands that read sensitive files, encode them, and exfiltrate them via an outbound HTTP request or DNS query. No USB drive required. No suspicious port activity on the target machine until the data is already gone.

4. Credential Harvesting

On a locked machine, injected keystrokes can interact with the login screen, attempt known passwords, or trigger authentication dialogs. On a session already unlocked, credentials stored in browsers or password managers become accessible through scripted browser automation.

5. Supply Chain and Insider Vectors

A planted BLE device in a conference room - disguised as a power bank, wall charger, or forgotten peripheral - can activate on a schedule, waiting for a high-value target to sit nearby before deploying its payload.

How BLEShark Nano Implements Bad-BT for Authorized Testing

The BLEShark Nano is a compact, purpose-built security research device that implements the Bad-BT attack vector for authorized penetration testing engagements.

BLEShark Nano broadcasts as a Bluetooth HID keyboard over BLE. Security professionals use it to:

• Validate Bluetooth pairing policies - Does your organization's MDM actually prevent pairing with unknown BLE devices?
• Test endpoint detection - Does your EDR flag anomalous keystroke velocity or unexpected terminal spawns?
• Audit physical security perimeters - How far away can an attacker be and still reach a target device?
• Run realistic red team scenarios - Demonstrate wireless HID injection risk to executive stakeholders with live, controlled demonstrations.

DuckyScript payloads can be loaded onto the device via the file transfer portal - connect to the Nano's portal from your browser, upload your script, and it's ready to run. You can also download scripts from the device via the same portal, which is useful for saving modified scripts or keeping backups.

The device supports variable keystroke timing to evade rate-based detection heuristics - an important consideration when testing mature environments with behavioral analytics in place.

BLEShark Nano is designed for use by security professionals operating under explicit written authorization. It is not a consumer device.

View BLEShark Nano

The On-Device DuckyScript Editor: Iterate Without a Computer

The biggest differentiator for Bad-BT on BLEShark Nano is the on-device DuckyScript editor.

Here's the problem it solves. The traditional Bad-BT workflow looks like this: write a DuckyScript payload on your computer, upload it to the device via the file portal, connect to a test machine, run the script, watch it fail because a DELAY is 200ms too short, disconnect, go back to your computer, fix the delay, upload again, reconnect, test again. Most of the time is wasted in the upload-reconnect loop, not in actual testing.

BLEShark Nano's on-device editor lets you skip that loop entirely. After a test run, you stay on the device, open the script in the editor, change the delay from 500 to 700, save it, and run again. No computer. No uploads. No disconnecting. The iteration cycle drops from minutes to seconds.

The editor is not the best tool for writing a script from scratch - doing that on a full keyboard with syntax highlighting is faster. But for iterating on a script that's already mostly working, it's the right tool. Adjust a timing value, add a DELAY before a command, swap a hotkey, comment out a line for testing - all of it happens directly on the device.

This is a meaningful operational advantage over the Flipper Zero and the USB Rubber Ducky, neither of which have on-device editing capability. On those tools, every change requires going back to a computer. On BLEShark Nano, you stay in the field.

Defensive Measures: Protecting Against Bad-BT Attacks

Understanding the attack is the first step. The second is building layered defenses that reduce both the likelihood and the impact of a successful Bad-BT intrusion.

Bluetooth Pairing Policies

• Disable Bluetooth when not in use. A device that isn't broadcasting cannot be attacked.
• Enable Secure Simple Pairing with MITM protection where supported. Require numeric comparison or passkey entry for all new pairings.
• Restrict pairing via MDM/group policy. On managed endpoints, enforce allowlists of approved Bluetooth MAC addresses and block pairing with unrecognized devices.
• Set devices to non-discoverable when not actively pairing.

Device and Endpoint Management

• Audit paired devices regularly. Remove stale or unrecognized pairings from all endpoints.
• Deploy EDR solutions with behavioral analytics capable of detecting anomalous keystroke injection patterns - unusually high WPM, terminal launches from background processes, or privilege escalation following keyboard input.
• Use auto-lock policies aggressively. A locked screen dramatically limits what an injected payload can accomplish in a short window.

Network and Monitoring Controls

• Monitor for outbound connections initiated immediately following new Bluetooth device connections - a common indicator of a successful payload execution.
• Log and alert on new Bluetooth device pairings across managed endpoints via your MDM or SIEM.
• Segment sensitive systems so that even successful keystroke injection has limited lateral movement capability.

graph TD
    THREAT["Bad-BT Threat"] --> PAIR["Bluetooth Pairing
Policies"]
    THREAT --> EDR["Endpoint Detection
and Response"]
    THREAT --> MON["Network Monitoring"]
    PAIR --> CONFIRM["Require manual
confirmation for
new BT devices"]
    PAIR --> DISABLE["Disable BT on
sensitive systems"]
    PAIR --> WHITELIST["Whitelist known
device MACs"]
    EDR --> KEYSTROKE["Monitor keystroke
injection speed"]
    EDR --> BLOCK["Block unauthorized
HID enumeration"]
    MON --> ALERT["Alert on new BLE
HID connections"]
    MON --> LOG["Log all BT
pairing events"]

Testing Your Organization's Bluetooth Security Posture

A Bad Bluetooth attack assessment should be part of any comprehensive wireless security engagement. Here's a structured approach for security teams conducting authorized testing:

1. Scope and authorization. Define the target systems, timeframes, and acceptable methods in writing before any testing begins. This is non-negotiable.
2. Reconnaissance. Survey the target environment for BLE-enabled devices. Identify systems with Bluetooth enabled, devices currently paired with peripherals, and high-value targets (executive machines, kiosks, shared conference systems).
3. Pairing policy validation. Attempt to establish a BLE HID connection to a test endpoint. Document whether the OS prompts for confirmation, silently accepts, or blocks the pairing attempt.
4. Payload execution testing. With approval, deploy a benign test payload (e.g., open Notepad and type a timestamp) to confirm successful keystroke injection. This establishes proof of concept without causing harm.
5. Detection gap analysis. Review EDR and SIEM logs post-test. Did any alerts fire? Was the Bluetooth pairing event logged? Was the keystroke velocity anomalous enough to trigger a rule?
6. Reporting and remediation. Document findings, evidence, and recommended controls. Prioritize remediations based on exploitability and business impact.

Defense layers against Bad-BT attacks - effective protection requires controls at the pairing, endpoint, and monitoring levels

The goal of Bad-BT testing is not to demonstrate that an attack is possible - it almost always is, in default configurations. The goal is to measure your detection and response capability, and to drive concrete policy improvements.

Legal and Ethical Considerations

Bad-BT tools - including BLEShark Nano - are professional instruments intended exclusively for authorized security testing. Deploying a Bluetooth HID injection device against systems you do not own or have explicit written permission to test is illegal under the Computer Fraud and Abuse Act (CFAA), the UK Computer Misuse Act, and equivalent legislation in most jurisdictions worldwide.

Always obtain written authorization before conducting any security testing. Define the scope. Document the methodology. Notify the appropriate stakeholders. Responsible disclosure and ethical practice are not optional - they are the foundation of professional security work.

InfiShark sells BLEShark Nano to security professionals, researchers, and educators for lawful, authorized use only.

Conclusion

The Bad Bluetooth attack represents a meaningful evolution in HID injection threats. By eliminating the need for physical USB access, Bad-BT expands the attacker's operational range and removes one of the most reliable physical controls in the defender's toolkit. Organizations that have addressed BadUSB risk but not wireless HID injection have an incomplete threat model.

Testing your Bluetooth security posture with purpose-built tools like BLEShark Nano - under controlled, authorized conditions - is the only way to know whether your defenses hold. Assumptions are not a security strategy.

Get BLEShark Nano - Authorized Security Testing Tool

Legal Disclaimer: This article is provided for educational and informational purposes only. The techniques described are intended exclusively for use by qualified security professionals conducting authorized penetration tests and security assessments. Unauthorized use of Bluetooth HID injection tools against systems you do not own or have explicit written permission to test is illegal and may result in criminal prosecution. InfiShark Technologies Inc. assumes no liability for misuse of information or products described herein. Always obtain proper authorization before conducting any security testing activity.