Windows BLE Spam: Why Windows Laptops Are Vulnerable to Popup Floods
Apple gets most of the attention when people talk about BLE popup spam. The iOS "New AirPods detected" notification is well-documented. But Windows has its own version of this - Swift Pair - and it behaves differently in ways that matter for both security researchers and everyday users.
Swift Pair was introduced in Windows 10 version 1803 to make Bluetooth pairing faster. Instead of digging through Settings to pair a new device, a notification pops up when a pairable device is nearby. It's convenient. It's also trivially triggerable by spoofed BLE advertisements.
Table of Contents
- What Is Swift Pair?
- The Advertisement Format That Triggers It
- Why It Works on Windows 10 and 11
- How BLEShark Nano Windows Spam Mode Works
- What Actually Happens to the User
- How to Disable Swift Pair
- Security Research Context
What Is Swift Pair?
Swift Pair is Microsoft's name for their BLE-based fast pairing system, introduced alongside the Windows 10 April 2018 Update (version 1803). The feature is built into the Windows Bluetooth stack and requires no additional software. It's active by default on Windows 10 and Windows 11 when Bluetooth is enabled.
The mechanism is simple: Windows monitors BLE advertisement packets for a specific Microsoft vendor-specific payload. When it sees one, it pops up a toast notification in the bottom-right corner of the screen: "New device found - [Device Name]. Connect." One click pairs the device.
For legitimate use, device manufacturers implement Swift Pair in their firmware. Microsoft Bluetooth peripherals like the Arc Mouse and Surface Headphones use it. Logitech, Jabra, and others also support it. When you unbox a new headset and Windows automatically asks if you want to connect, that's Swift Pair working as intended.
The problem is that the advertisement is just a BLE packet with a specific format. Any device capable of transmitting BLE advertisements - including the ESP32-C3 in the BLEShark Nano - can send that format.
sequenceDiagram
participant NANO as BLEShark Nano
(BLE Spam Mode)
participant BLE as 2.4GHz BLE
Advertising Channels
participant WIN as Windows 10/11
(Swift Pair enabled)
participant UI as Windows UI
(Shell)
Note over NANO: Generates randomized
Swift Pair advertisements
loop Every ~20ms (rapid fire)
NANO->>BLE: ADV_IND with Swift Pair payload
(Vendor ID: Microsoft 0x0006)
NANO->>BLE: Randomize device name + MAC
BLE->>WIN: BLE advertisement received
WIN->>WIN: Check: Is Swift Pair enabled?
WIN->>WIN: Check: Vendor-specific data
matches Microsoft Swift Pair format?
WIN->>WIN: RSSI above threshold?
WIN->>UI: Toast notification:
"New device found nearby"
UI->>UI: Display popup with
device name + pair button
end
Note over UI: Multiple popups stack
overwhelming the user
Note over WIN: Each unique MAC/name
generates a new popup
rect rgb(40, 40, 40)
Note over NANO,UI: Impact Assessment
Note over UI: UI becomes unresponsive
popups consume focus
potential for misclick pairing
end
Windows BLE spam attack flow - the BLEShark Nano rapidly broadcasts fake Swift Pair advertisements with randomized MACs, each triggering a separate pairing popup on nearby Windows devices.
graph TD
subgraph PKT["Swift Pair BLE Advertisement"]
direction TB
subgraph HEADER["BLE ADV_IND Header"]
H1["Preamble + Access Address"]
H2["PDU Type: ADV_IND"]
H3["Advertiser Address (random MAC)"]
end
subgraph AD_FLAGS["AD Structure 1: Flags"]
F1["Length: 0x02"]
F2["Type: 0x01 (Flags)"]
F3["Value: 0x06
(General Discoverable + BR/EDR Not Supported)"]
end
subgraph AD_TX["AD Structure 2: TX Power"]
TX1["Length: 0x02"]
TX2["Type: 0x0A"]
TX3["Value: TX power level"]
end
subgraph AD_VENDOR["AD Structure 3: Microsoft Vendor Data"]
V1["Length: variable"]
V2["Type: 0xFF (Manufacturer Specific)"]
V3["Company ID: 0x0006 (Microsoft)"]
V4["Beacon Type: 0x03 (Swift Pair)"]
V5["RSSI Threshold: proximity trigger"]
V6["Device Scenario: 0x01"]
V7["Display Name: spoofed device name"]
end
end
HEADER --> AD_FLAGS --> AD_TX --> AD_VENDOR
subgraph TRIGGER["Windows Swift Pair Service"]
T1["DevicePicker monitors
BLE advertisements"]
T2["Matches Microsoft
vendor ID 0x0006"]
T3["Checks RSSI vs
threshold in payload"]
T4["Generates toast
notification per device"]
end
AD_VENDOR --> TRIGGER
Swift Pair advertisement packet structure - Windows specifically watches for Microsoft vendor ID 0x0006 with beacon type 0x03, triggering the DevicePicker popup when RSSI exceeds the embedded threshold.
The Advertisement Format That Triggers It
Swift Pair uses a Microsoft vendor-specific AD (Advertising Data) type in the BLE advertisement. The AD type for Microsoft-specific data is 0xFF (manufacturer specific data), followed by the Microsoft company identifier: 0x0006.
The Microsoft BLE advertisement beacon format for Swift Pair is documented in part by Microsoft and has been further analyzed by security researchers. The key elements are:
- AD type: 0xFF (manufacturer specific)
- Company ID: 0x06, 0x00 (Microsoft)
- Microsoft beacon sub-type: 0x03 (Swift Pair)
- Reserved: 0x00
- RSSI byte: typically 0x80 (used for proximity hints)
- Device name bytes (optional, variable length)
When Windows sees this payload in a BLE advertisement, it triggers the Swift Pair notification. The device name displayed in the notification is pulled from either the payload itself or from a separate AD type for the complete local name.
The RSSI byte in the payload is not the actual received signal strength - it's a value baked into the advertisement by the device itself as a hint about the reference transmit power. Windows uses this for proximity estimation, but doesn't strictly enforce that the device must be close before showing the popup. At typical indoor ranges with a device like the BLEShark, the popup fires reliably.
Why It Works on Windows 10 and 11
Swift Pair has no authentication. There's no way for Windows to verify that the advertising device is what it claims to be before showing the notification. The pairing prompt is shown based entirely on the presence of the correct advertisement format.
This is by design in one sense - the actual Bluetooth pairing that would follow a user clicking the notification does involve authentication and key exchange. The notification itself is just a UI feature saying "hey, something pairable is nearby." Windows isn't automatically connecting to anything by showing the popup.
But showing the popup is itself the problem in a spam scenario. If dozens of fake Swift Pair advertisements arrive per second, Windows will queue up dozens of notifications. The notification stack can become completely unusable. On a machine with relatively low-spec resources or in a meeting room where someone needs to actually work, this is genuinely disruptive.
Windows 10 and Windows 11 both exhibit this behavior. The notifications appear in the notification area (Action Center) and as toast popups over the taskbar. If notification focus assist is off - the default in most configurations - every single popup is visible.
How BLEShark Nano Windows Spam Mode Works
The BLEShark Nano includes a Windows Spam mode as part of the BLESpam feature set. It works by transmitting rapid BLE advertisement packets formatted with the Swift Pair payload. The device name in each packet can be static or varied to generate multiple distinct notifications.
The ESP32-C3's BLE 5.0 stack supports advertisement intervals down to 20ms. At that rate, the BLEShark can generate a high volume of distinct Swift Pair advertisements per second. Combined with randomized device names, each advertisement triggers a new popup rather than Windows suppressing duplicates.
From a BLE protocol perspective, what's happening is straightforward: the radio is transmitting ADV_IND (connectable undirected advertisement) packets on BLE advertising channels 37, 38, and 39 with the Microsoft vendor-specific payload. Any Windows machine within BLE range - typically 10-30 meters indoors - that has Bluetooth enabled and Swift Pair active will receive and process these packets.
The BLEShark doesn't need to be within USB range, doesn't need physical access to the target machine, and doesn't leave any persistent trace on the target system. The advertisements simply stop when the device goes back to idle.
The BLESpam features - including Windows Spam - are included for authorized security demonstration and testing. They're useful for showing IT departments why Bluetooth management policies matter, or demonstrating the attack surface at a security awareness session. The BLEShark's mesh capability via Shiver lets you coordinate BLESpam across multiple nodes: a pack of 3 or 5 nodes distributed around a space creates comprehensive coverage for a wider demonstration area.
What Actually Happens to the User
A rapid stream of Swift Pair notifications is annoying but not dangerous in itself. Clicking "Connect" on a fake Swift Pair notification will initiate a Bluetooth connection attempt that will fail - the BLEShark doesn't actually implement a full HID or audio profile that Windows could successfully pair with in this mode. The user sees a brief "Couldn't connect" message and nothing further happens.
The real impact is distraction and degraded usability. During a presentation, meeting, or focused work session, repeated popup notifications break concentration. On machines where Windows notifications are set to audible, each popup also triggers a sound.
There's also a secondary concern: user training. In a social engineering scenario, a flood of pairing prompts could be a setup to get a user conditioned to clicking "dismiss" - or alternatively, to get them looking away from their screen. This is the social engineering framing that makes BLESpam relevant to physical security assessments, not the technical impact of the packets themselves.
How to Disable Swift Pair
Disabling Swift Pair is straightforward on Windows 10 and Windows 11:
- Open Settings (Win + I)
- Go to Bluetooth and devices
- Scroll down to find "Swift Pair" or "Show notifications to connect using Swift Pair"
- Toggle it off
Alternatively, via Group Policy for enterprise deployments: Computer Configuration > Administrative Templates > Windows Components > Bluetooth > Allow Swift Pair. Set to Disabled.
The registry key that controls this is: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Bluetooth\SwiftPair with the value Enabled set to 0.
Disabling Swift Pair removes the automatic popup behavior but doesn't affect Bluetooth functionality. You can still pair devices manually through Settings > Bluetooth and devices > Add device. If you're in an environment where BLE popup spam is a realistic concern - an open office, conference center, or any public space - disabling it is a reasonable hardening step.
It's also worth noting that disabling Bluetooth entirely when not in use is the most comprehensive defense. A radio that isn't active can't receive advertisements. Windows Fast Startup can leave Bluetooth active even when the machine appears to be off, so for maximum assurance, check that Bluetooth is actually disabled rather than just leaving it at the default state.
Security Research Context
Swift Pair popup spam is a low-severity issue in the CVSS sense - it doesn't result in code execution, data theft, or credential compromise. Microsoft hasn't classified it as a vulnerability because the behavior is a feature working as designed. The advertisement format is public. Any device with BLE can generate it.
What makes it worth understanding is the broader category it represents: UI-level attacks that exploit legitimate OS features to degrade user experience or distract users. Popup floods are one of the simpler versions of this. More sophisticated approaches combine notification spam with social engineering to get users to take specific actions.
For red teams doing physical security assessments, BLE popup spam is a useful social engineering component - not because it directly compromises anything, but because it demonstrates the attack surface to stakeholders in a visible, tangible way. Seeing a laptop get flooded with pairing prompts from a pocket-sized device is more memorable than reading a report about theoretical BLE attack vectors.
The BLEShark also includes a BLE scanner that does the passive reconnaissance side: seeing what Bluetooth devices are broadcasting in an environment, reading their MAC addresses and manufacturer data, and identifying devices that could be spoofed. This combines with the BLESpam mode to give a complete picture of the BLE attack surface in a given space.
This article is for educational and authorized security research purposes. BLESpam testing should only be performed in environments where you have explicit permission to do so.