SSID Spoofing and Beacon Injection: How WiFi AP Spam Works
Your phone's WiFi list is supposed to show real networks. But the list is just a display of received beacon frames - and there's nothing in the 802.11 standard that verifies whether the device transmitting a beacon is a legitimate access point.
This is the foundation of AP Spam: inject enough beacon frames with enough different SSIDs, and you can fill a phone's WiFi list with hundreds of networks that don't actually exist. The BLEShark Nano does this using the ESP32-C3's raw frame injection capability. Here's how it actually works at the packet level.
What Is Beacon Injection?
Beacon injection is the act of transmitting 802.11 beacon frames from a device that is not a real access point. A beacon frame is a management frame - it has no encryption requirement, no authentication, and no mechanism by which a receiving device can verify that the sender is a legitimate AP.
The 802.11 standard was designed with the assumption that devices would only transmit appropriate frames for their role. An AP transmits beacons. Clients send probe requests. The standard doesn't include "is this sender actually an AP?" verification because there's no cryptographic infrastructure to support that check at the management frame layer.
Protected Management Frames (802.11w) adds some protection, but only after a client has already associated with a specific AP. An unassociated beacon from an unknown source can't be verified against anything. The client has no prior relationship with it.
How the ESP32 Transmits Raw Frames
Standard WiFi drivers operate in managed mode. The driver handles all the 802.11 protocol details - association, authentication, DHCP, everything. The application just sends data and receives data. Transmitting arbitrary management frames isn't normally possible from userspace.
The ESP32's WiFi library exposes a lower-level function: esp_wifi_80211_tx(). This function takes a raw byte buffer containing a complete 802.11 frame (including the MAC header) and pushes it out the radio. The application is responsible for constructing a valid frame - the driver just transmits it.
This is what makes the ESP32 useful for security research tools. You're not limited to what a normal WiFi stack does. You can craft any management frame you want - beacon, deauthentication, probe response, whatever - and transmit it. The radio doesn't care whether you're a real AP or a BLEShark Nano sitting on a desk.
Building a Beacon Frame
A beacon frame has a fixed structure that the BLEShark firmware constructs for each SSID it wants to broadcast.
graph TD
subgraph "Crafted Beacon Frame"
subgraph "MAC Header (24 bytes)"
FC["Frame Control: 0x8000
Type=Mgmt, Subtype=Beacon"]
DEST["Dest: FF:FF:FF:FF:FF:FF
(Broadcast)"]
SRC["Source: Random MAC
(unique per fake AP)"]
BSSID["BSSID: Same as Source
(simulates unique AP)"]
SEQ["Sequence Number
(incremented)"]
end
subgraph "Beacon Body"
TS["Timestamp: 0
(8 bytes)"]
INT["Beacon Interval: 100 TU
(~102.4ms)"]
CAP["Capabilities: 0x0421
(ESS + Short Preamble)"]
SSID["SSID IE: Tag=0
Length + SSID string"]
RATES["Supported Rates IE
1, 2, 5.5, 11 Mbps"]
DS["DS Param: Tag=3
Current channel"]
end
end
FC --> DEST --> SRC --> BSSID --> SEQ
SEQ --> TS --> INT --> CAP --> SSID --> RATES --> DS
subgraph "SSID Cycling Logic"
LIST["SSID List
(user-defined or random)"]
MAC_GEN["MAC Generator
(unique per SSID)"]
TX["esp_wifi_80211_tx()
Inject on channel"]
DELAY["Delay ~10ms
Next SSID"]
end
LIST --> MAC_GEN --> TX --> DELAY --> LIST
Beacon frame anatomy for AP spam - each fake network gets a unique random BSSID so clients treat them as separate access points in their scan results.
The MAC header (24 bytes) comes first:
- Frame control: 0x8000 (management frame, subtype 8 = beacon)
- Duration: 0x0000
- Destination address: FF:FF:FF:FF:FF:FF (broadcast)
- Source address: a MAC address (real or fabricated)
- BSSID: same as source address
- Sequence control: increments with each frame
Then the beacon body:
- Timestamp: 8 bytes, usually set to current microsecond count
- Beacon interval: 0x6400 (100 TUs = 102.4ms default)
- Capability info: 0x0431 (ESS bit set, short preamble, short slot time)
Then information elements (TLV format - type, length, value):
- SSID element (tag 0): the network name
- Supported rates (tag 1): rates the AP supports
- DS parameter (tag 3): the channel number
- TIM element (tag 5): traffic indication map (required for proper beacon format)
- RSN element (tag 48): optional, but including it makes the AP appear to be WPA2-secured
Finally, the FCS (4 bytes) - a CRC32 over the entire frame. The hardware typically calculates and appends this automatically.
The whole beacon for a short SSID is around 100-150 bytes. At 802.11b 1Mbps (the lowest mandatory rate, which ensures maximum range), that transmits in about 1.2 milliseconds. The BLEShark can send hundreds of these per second.
sequenceDiagram
participant FW as BLEShark Firmware
participant ESP as ESP32-C3
WiFi Radio
participant CH as WiFi Channel
participant C1 as Client Device 1
participant C2 as Client Device 2
Note over FW,C2: Beacon Injection Loop
FW->>ESP: Build beacon frame
SSID="Free_WiFi_1"
ESP->>CH: esp_wifi_80211_tx()
Raw frame injection
CH->>C1: Beacon received
CH->>C2: Beacon received
FW->>ESP: Build beacon frame
SSID="Free_WiFi_2"
ESP->>CH: Next beacon transmitted
FW->>ESP: Build beacon frame
SSID="CoffeeShop_Guest"
ESP->>CH: Unique BSSID per SSID
Note over FW: Cycle through SSID list
~10ms per beacon
Note over C1,C2: Client WiFi Scanner View
C1->>C1: Network list shows
dozens of fake APs
C2->>C2: Cannot distinguish
real from fake
Note over FW,C2: What Does NOT Happen
C1--xESP: Association request
(no AP functionality)
Note over ESP: ESP32 is TX-only
No DHCP, no routing
Beacon injection flow - the ESP32 transmits crafted beacon frames with unique SSIDs and BSSIDs, flooding nearby devices' network lists without actually providing any network access.
Cycling Through SSIDs
Broadcasting a list of 50 SSIDs looks like flooding from the receiver's side, but from the transmitter's side it's just a loop: construct beacon for SSID[0], transmit, construct beacon for SSID[1], transmit, ..., construct beacon for SSID[49], transmit, repeat.
Each iteration through the list takes a few hundred milliseconds at most. From a phone's perspective, it sees beacons from all 50 "networks" arriving within a short window and keeps them all in the scan list.
The BSSID (MAC address) for each fake AP can either be the chip's real MAC address (with the last byte incremented for each entry to make them look like different APs), or entirely random MACs. Using distinct BSSIDs for each SSID is important - if all the beacons came from the same BSSID, the phone would just see one AP whose SSID keeps changing.
What the Client Sees
When a device running AP Spam is nearby, the receiving phone sees its WiFi scan list populate with many networks simultaneously. They appear to be different access points because they have different BSSIDs. They may appear on different channels depending on the channel field in each beacon. They may show as open or secured depending on whether the RSN element is included.
The phone has no reason to treat these differently from real networks. The beacon format is valid. The frame checksum is correct. Nothing in the protocol says "verify this AP exists before listing it."
Modern iOS and Android may rate-limit or debounce their scan list display, so the visual effect depends on the OS. Some devices show all networks regardless of how many there are. Others have an informal limit on the UI list. But the underlying scanning layer records them all.
The Limits: What AP Spam Cannot Do
Broadcasting beacons is not the same as running an access point. Understanding the difference is important.
A beacon frame announces a network's existence. If a device tries to actually connect to one of the spoofed SSIDs, it sends an authentication request to the BSSID it saw in the beacon. The BLEShark firmware, in AP Spam mode, is not listening for authentication requests and is not responding to them. The association attempt times out. The client gives up.
This means AP Spam on its own cannot intercept any traffic. There's no man-in-the-middle possible from a flood of unresponded beacon frames. Devices that "see" the fake networks but get no response during association will mark them as unavailable and move on.
For a rogue AP scenario that actually intercepts traffic, you need a real functional AP - with association handling, DHCP, DNS, and either a transparent proxy or a captive portal. That's a fundamentally different technical setup. The BLEShark supports this via its captive portal and evil portal features, but those are distinct from AP Spam.
Channel Selection and Transmission Power
Beacon frames need to be transmitted on a specific channel. Clients scan channels sequentially (or all at once on multi-radio hardware). If you transmit beacons on channel 6 but a phone is currently scanning channel 1, it won't see them.
The BLEShark's AP Spam mode typically transmits on a fixed channel (usually the channel the device is currently set to, or hopping through channels to increase coverage). Transmitting on all channels simultaneously isn't possible with a single radio - it would require switching channels between each beacon, which adds latency to the cycle but improves the chance of being seen during any given scan.
The ESP32-C3's transmission power is limited to what's allowed by regulatory domain settings. This isn't a precision RF attack tool with amplified signal. In practice, beacon frames are clearly visible to any device within the same room or adjacent area, which is the intended demonstration context.
Why This Matters for Security Testing
AP Spam is primarily a demonstration tool. The scenarios where it has practical security testing value:
UI confusion testing: Does your endpoint management software alert when it detects an unusual number of nearby APs? Does it freak out when the scan list has 200 entries? Some security products have bugs in edge cases like this.
Client behavior testing: Do devices in your environment automatically connect to open networks they haven't seen before? If you broadcast an SSID that matches an autoconfigured network profile, will client devices attempt association? This tells you about your auto-connect policies.
SSID-based recon countermeasures: If you're testing whether an organization has sensitive information in their SSID names, broadcasting a flood of SSIDs is a low-noise way to blend in with the noise floor before conducting a more targeted scan.
Channel congestion assessment: Flooding beacon frames on a channel increases the management frame overhead on that channel. This can be used to assess whether your AP firmware handles high management frame loads gracefully, or degrades.
EU Compliance Note
The BLEShark Nano's AP Spam feature transmits beacons but does not transmit deauthentication frames in the EU firmware. The RED (Radio Equipment Directive) compliance restrictions apply specifically to deauth and active disconnection attacks.
Beacon injection is a transmit-only action that does not disrupt existing connections - it adds frames to the air but doesn't instruct any client to disconnect from anything. The regulatory context here is different from deauth.
That said, intentionally causing congestion on shared spectrum may have its own regulatory implications depending on jurisdiction and context. AP Spam in a test environment on equipment you own is a different situation from doing it at an airport. Use it in appropriate contexts.
Multi-Node AP Spam With Shiver Mesh
With the Shiver mesh system (up to 16 BLEShark Nanos, ESP-NOW at 250 kbps Long Range, 20-50m range), you can coordinate AP Spam across multiple nodes operating on different channels simultaneously. One master device sends commands to all nodes, each injecting beacons on its assigned channel partition.
graph TD
subgraph "Shiver Mesh Multi-Node AP Spam"
subgraph "Node 1 (Leader)"
N1["BLEShark #1
Channel 1"]
N1_TX["Beacons: SSID_1 to SSID_50
~500 beacons/sec"]
end
subgraph "Node 2"
N2["BLEShark #2
Channel 6"]
N2_TX["Beacons: SSID_51 to SSID_100
~500 beacons/sec"]
end
subgraph "Node 3"
N3["BLEShark #3
Channel 11"]
N3_TX["Beacons: SSID_101 to SSID_150
~500 beacons/sec"]
end
end
N1 -->|"ESP-NOW
Coordination"| N2
N2 -->|"ESP-NOW
Coordination"| N3
N3 -->|"ESP-NOW
Coordination"| N1
N1 --> N1_TX
N2 --> N2_TX
N3 --> N3_TX
subgraph "Coverage Result"
COVER["All 2.4GHz channels
covered simultaneously"]
COUNT["150+ fake SSIDs
visible to any client"]
RANGE["20-50m per node
Combined coverage area"]
end
N1_TX --> COVER
N2_TX --> COUNT
N3_TX --> RANGE
Shiver mesh distributes AP spam across nodes and channels - each BLEShark covers different channels so clients scanning any 2.4GHz frequency see fake networks.
The practical result: an observer anywhere in the covered area sees the fake SSID list regardless of which channel their device is scanning on. This is useful for large-area testing scenarios where single-channel coverage is insufficient.
BLE and mesh are mutually exclusive on a single BLEShark device (single radio, time-division), so AP Spam mode (which is WiFi-only) has no impact on mesh connectivity.
Using AP Spam on the BLEShark Nano
The AP Spam feature is accessible from the WiFi menu on the BLEShark. You can choose from preset SSID lists (including the rickroll list, a classic comedy SSID set, and others), or upload a custom list via the file portal. The file portal accepts plain text files with one SSID per line.
Custom lists are useful for testing scenarios: if you want to see whether a specific SSID triggers client auto-connect behavior, put that SSID in the list and watch for association attempts. Or use it for a demonstration where you want to show clients what an RF flooding scenario looks like in practice.
The device's settings let you configure channel, transmission interval, and whether to include the RSN element (making APs appear secured) or leave them open. These settings are accessible from the on-device settings menu or via the file portal config.
AP Spam and beacon injection features are intended for authorized security testing and educational use. Transmitting beacon frames on channels used by others constitutes use of shared radio spectrum - ensure you have appropriate authorization and are operating in a context where this activity is permitted.