ESP32 Marauder Firmware Volume 5 — Wi-Fi Attack Subsystems — ESP32 Marauder · Hacking

Deauth, beacon spam, probe spam, karma probe-response, Evil Portal — frame anatomy, attack patterns, gating, hygiene

Section	Topic
1	About this volume
2	Deauth attack
· 2.1	Frame anatomy
· 2.2	Why deauth still works on WPA2
· 2.3	WPA3 PMF / 802.11w breaks it
· 2.4	Broadcast vs targeted deauth
· 2.5	Marauder’s deauth menu
3	Beacon spam
· 3.1	Synthetic beacon mechanics
· 3.2	The iOS Wi-Fi UI denial mode
· 3.3	SSID list format and built-in lists
· 3.4	Channel and timing strategies
4	Probe spam and karma-style attacks
· 4.1	Probe spam — what it does
· 4.2	Karma probe-response
· 4.3	Why karma rarely works on modern OSes
5	Evil Portal
· 5.1	Architecture
· 5.2	Captive-portal detection per OS
· 5.3	HTML authoring (forward-ref Vol 8 § 5)
· 5.4	Credential capture and the `creds.txt` log
· 5.5	Operational signatures
6	Targeting strategies
7	Build flags that gate attacks
8	Output and credential capture summary
9	Operational hygiene (forward-ref Vol 11)
10	Resources

1. About this volume

Vol 5 covers the Wi-Fi attack catalogue — frames Marauder generates on the air, not just observes. Pairs with Vol 4 (scanning); many real engagements use deauth from this volume to induce the 4-way handshake capture from Vol 4 § 6.

The catalogue has four major attacks plus minor variants:

Deauth (§ 2) — force a station off an AP, optionally to induce reassociation handshake capture.
Beacon spam (§ 3) — flood the air with synthetic AP beacons. Denial-of-Wi-Fi-UI use case.
Probe spam (§ 4.1) and karma probe-response (§ 4.2) — minor / niche.
Evil Portal (§ 5) — the most operationally complex. Captive-portal credential harness.

Legal/ethical posture (read first): every attack in this volume is illegal in most jurisdictions when fired at networks the operator doesn’t own or doesn’t have written authorization for. See ../../../_shared/legal_ethics.md for the broader Hack Tools posture and Vol 11 for Marauder-specific operational considerations. The rest of this volume assumes the operator is on their own bench, on their own network, or has authorization in hand.

2. Deauth attack

2.1 Frame anatomy

A deauthentication frame is a management frame (type 0, subtype 0x0C in 802.11 frame-control). Per IEEE 802.11-2020 § 9.4.1.7, the frame body is short:

Field	Size	Notes
Frame Control	2 B	Type=Mgmt, Subtype=Deauth
Duration	2 B	NAV; usually 0 for deauth
Address 1 (DA)	6 B	Destination (the station being deauthed; broadcast = FF:FF:FF:FF:FF:FF)
Address 2 (SA)	6 B	Source (the AP MAC, spoofed by Marauder)
Address 3 (BSSID)	6 B	Usually = SA (the AP)
Sequence Control	2 B	Sequence number + fragment number
Frame body: Reason Code	2 B	Why the deauth is being sent

The Reason Code is the only body content. Common values (802.11-2020 Table 9-49):

Code	Meaning	Marauder default?
1	Unspecified reason	✓
2	Previous authentication no longer valid
3	Deauthenticated because sending STA is leaving
4	Disassociated due to inactivity
7	Class 3 frame received from nonassociated STA
8	Disassociated because sending STA is leaving BSS

Marauder uses Reason Code 1 by default; the practical effect is identical regardless of Reason Code (clients disconnect either way).

2.2 Why deauth still works on WPA2

The fundamental design flaw: 802.11 management frames including deauth are unauthenticated in the original WPA/WPA2 spec. The AP does not cryptographically sign its deauth frames, and the client has no way to verify the deauth actually came from the AP. So anyone within RF range can spoof the AP’s MAC and send a deauth that the client will obey.

This was a known flaw at WPA2’s design time. The fix (802.11w / PMF — Protected Management Frames) wasn’t mandatory in WPA2; clients and APs that didn’t enable PMF remain vulnerable. As of 2026, the bulk of SOHO equipment in deployment still defaults PMF to optional or off, so the attack still works against most real-world targets.

2.3 WPA3 PMF / 802.11w breaks it

WPA3-Personal mandates PMF (Management Frame Protection). When both AP and client have PMF enabled (a WPA3 association requirement), management frames including deauth are cryptographically integrity-protected. A spoofed deauth from Marauder is silently dropped by the client.

This is the single biggest reason WPA3 is meaningfully more secure against this class of attack. The migration is partial — many networks run WPA2/WPA3 transition mode (Vol 4 § 4.3) where WPA2 clients still negotiate without PMF, leaving them vulnerable.

For an engagement-planning check: read the target AP’s RSN IE (Vol 4 § 4.3) for the MFPC (MFP Capable) and MFPR (MFP Required) bits. If MFPR=1, deauth won’t work against properly-configured clients on that AP.

2.4 Broadcast vs targeted deauth

Mode	Destination	Effect
Broadcast	FF:FF:FF:FF:FF:FF	All stations associated with the spoofed AP receive and obey. Affects every client on the target AP. Loud — entire AP loses clients.
Targeted	Specific client MAC	Only the named client disconnects. Surgical — useful for the deauth-and-rejoin handshake capture (Vol 4 § 6.3) without disrupting other users.

Targeted is the preferred mode for engagements that need stealth-by-narrow-effect. Broadcast is reserved for “I want to disable the AP entirely” scenarios — extremely conspicuous and triggers any IDS that’s watching.

Menu path: WiFi → Attack → Deauth.

Workflow:

Run an AP scan first (Vol 4 § 4) to populate the AP-list — deauth needs a target BSSID.
From the AP-list, select the target AP (or set BSSID manually in Settings).
Set the target client MAC (Settings → Target Client MAC) — or leave as FF:FF:FF:FF:FF:FF for broadcast.
Set channel to static, locked to target AP’s channel (otherwise the deauth frames go out on whatever channel the radio happens to be on during the hop cycle).
Start the attack. Marauder transmits ~50 deauth frames/sec while the attack is running.
Stop with Back or Select.

Mainline behavior: the MARAUDER_DEAUTH build flag (Vol 3 § 9) gates compilation of the deauth attack. Some mainline build configurations ship with deauth disabled; check the menu — if WiFi → Attack doesn’t show Deauth, the build was compiled without the flag. Rebuild from source (Vol 10) with -DMARAUDER_DEAUTH in build_flags to turn it on.

3. Beacon spam

3.1 Synthetic beacon mechanics

Marauder switches the Wi-Fi radio out of station/promiscuous mode and into AP mode (briefly, per beacon) to transmit synthesized beacon frames. Each synthetic beacon:

Source = a random or configurable MAC (Marauder typically randomizes; the OUI is set to a Marauder-default value or randomized fully depending on build)
SSID = next entry from the SSID list (cycled)
Channel = current channel
Encryption advertisement = configurable (Open / WPA2 — does not have to match anything real, since no one is going to associate)
All other beacon IEs = synthetic defaults

The radio cycles through synthesizing-and-transmitting at a rate of ~10-50 beacons/sec across the configured channel set. Beacon frames are unauthenticated — APs and clients have no defense against an attacker injecting synthetic beacons into the airspace.

3.2 The iOS Wi-Fi UI denial mode

The signature use case: when Marauder fires beacon spam with a large random-MAC + random-SSID list at high rate, iOS devices’ Wi-Fi UI grays out within seconds. The UI becomes unresponsive — Wi-Fi can be toggled in airplane mode but the Wi-Fi settings panel shows a frozen scrolling list or “no networks” until the spam stops.

The mechanism (community-reverse-engineered, not Apple-documented): iOS’s CoreWLAN/wifid daemon tries to display every distinct nearby AP, and the beacon-frame parsing path appears to scale poorly when the unique-AP count balloons rapidly. The UI doesn’t crash but becomes unusable.

Android 12+ shows similar symptoms in some implementations (highly OEM-dependent). Windows generally handles the flood without UI-level denial — the Wi-Fi panel just shows hundreds of entries.

The denial-of-Wi-Fi-UI effect is the primary operational reason to run beacon spam. It’s not stealthy and it’s not a secret; it’s a known annoyance attack.

3.3 SSID list format and built-in lists

SSID lists live on the SD card at /marauder/beacons.txt. Format: line-separated UTF-8 strings, one SSID per line, up to 32 bytes per SSID (the 802.11 SSID-length hard limit). Empty lines and lines starting with # are skipped as comments.

# Custom SSID list — one per line, max 32 bytes each
Rick Astley
You've been Rick Rolled
RickRoll_Free_WiFi
🎶 Never Gonna Give You Up 🎶
# (32-byte UTF-8 limit means emoji count for ~4 bytes each)

Built-in lists (compiled into firmware, selectable from Settings):

Rick Roll — Astley-themed (the canonical funny choice)
Funny Names — generic prank pool
Random — synthesized random alphanumeric strings each beacon (no list at all)

The SD-card list overrides the built-in when present. Settings → Beacon SSID Source picks among Custom (beacons.txt) / Rick Roll / Funny / Random.

3.4 Channel and timing strategies

Beacon spam fires on the current channel by default. For an all-channels effect, set channel mode to hopping — Marauder will fire beacons on each channel as the hop cycle visits it (lower per-channel density but full-spectrum coverage).

For the iOS-UI-denial effect, hopping is typically worse than static — concentrated rapid beacons on one channel deny the UI faster than dispersed beacons across 11 channels. Pick one channel (typically the busiest, e.g., 6 or 11) and stay static.

Beacon rate is fixed at ~10-50/sec depending on the build; can’t be tuned at runtime in mainline. Ghost ESP exposes a runtime beacon-rate setting.

4. Probe spam and karma-style attacks

4.1 Probe spam — what it does

A probe spam attack: Marauder transmits synthesized probe-request frames at high rate, each pretending to be from a random MAC asking about a random SSID. Effect: APs and other clients see a flood of probe requests they don’t recognize, polluting their probe-request log buffers.

Use cases are limited:

Cover for a real attack — a real probe-request scan (Vol 4 § 3) buried inside a flood of synthetic ones is harder to detect.
AP probe-log overflow — some APs maintain a probe-request log of recent clients; flooding can push out older entries. Mostly a curiosity.

Probe spam is rare in mainline real-world workflows. The menu entry exists (under WiFi → Attack → Probe Spam) but isn’t part of typical engagement flows.

4.2 Karma probe-response

The “karma” attack: Marauder watches for probe-request frames from clients (Vol 4 § 3) and responds with a synthesized probe-response naming the exact SSID the client asked about. The idea: the client thinks “the network I want is here!” and tries to associate.

Mainline ships a basic karma variant in the WiFi → Attack → Karma menu. Ghost ESP has a more aggressive variant that responds with multiple SSIDs per client to increase association probability.

4.3 Why karma rarely works on modern OSes

The 2013-2016 era was karma’s heyday. Modern OS defenses largely neutralized it:

iOS / macOS — won’t auto-associate with an unknown AP that claims an SSID the device has previously connected to unless the BSSID also matches a previously-seen BSSID for that SSID. Karma can spoof the SSID but not a specific BSSID the client has seen before, so the client won’t auto-join. The client will display the network as available, but the user has to manually tap-to-connect.
Android 9+ — similar BSSID-binding behavior. The defense isn’t perfect; can be bypassed in some flavors of Android by careful BSSID choice.
Windows 10+ — has the same defense in principle but exposes a setting (now off by default in Windows 11) to allow auto-connect by SSID alone. Vulnerable devices exist but they’re a minority.

For an attended attack where the user tap-to-connects to the karma-spoofed AP, the attack succeeds — at which point the Evil Portal (§ 5) takes over to capture credentials. Karma is most useful as a pre-staging for Evil Portal in mixed crowds.

The blanket-karma fire-at-everything approach is mostly a relic. Targeted karma against specific known-vulnerable client devices still occasionally works.

5. Evil Portal

5.1 Architecture

Evil Portal is the most operationally-complex attack in mainline. The architecture, walked from the radio outward:

SoftAP — Marauder switches Wi-Fi into SoftAP mode and broadcasts a single AP with a configurable SSID (default: “Free WiFi” or “ESP32 Marauder”; user-configurable via Settings → Evil Portal SSID). Open security — no passphrase, anyone can join.
DHCP server — embedded; hands out IPv4 addresses from a small pool (10.0.0.x typical) to clients that join.
DNS spoofing — UDP listener on port 53 catches every DNS query and responds with the Marauder’s own IP. Every domain the joined client looks up resolves to Marauder.
HTTP server — TCP listener on port 80. Every HTTP request, regardless of Host header, serves back the captive page (HTML from SD or from SPIFFS-bundled fallback). The captive page typically has a <form action="/get" method="get"> with input fields for credentials.
Credential logging — when the form is submitted, Marauder appends the field name/value pairs to creds.txt on SD with a timestamp.
UI feedback — the TFT shows “Captures: N” updating live as new credentials come in. Optional: shows the BSSID of the most-recent capture-victim.

The combination of SoftAP + DHCP + DNS-spoof + HTTP captures every protocol that the captive-portal-victim’s OS might use to test for a captive portal; whichever URL it hits, Marauder serves the page.

5.2 Captive-portal detection per OS

Each OS tests for a captive portal differently on joining a new network. Knowing the detection behavior helps tune the Evil Portal page:

OS	Captive-portal test URL	Behavior on Marauder’s 200 OK
iOS / macOS	`captive.apple.com/hotspot-detect.html`	Expects a body containing `<HTML><HEAD><TITLE>Success</TITLE>` — if it gets that, it considers the network “open” and shows no captive-portal sheet. If it gets anything else, it pops the captive-portal sheet showing the page. Marauder typically serves the credential page here.
Android 7+	`connectivitycheck.gstatic.com/generate_204`	Expects HTTP 204 (no content). Anything else → captive-portal sheet pops.
Windows 10+	`www.msftconnecttest.com/connecttest.txt`	Expects body `Microsoft Connect Test`. Anything else → “Sign in” notification appears.
Older Android	Various Google domains	Mostly the 204-check pattern

The standard Evil Portal flow: serve the credential page to every URL. iOS, Android, Windows all pop their captive-portal sheets, showing the page directly to the user with a “Sign in” pretext. The user enters credentials thinking they’re authenticating to the open Wi-Fi; the credentials go to creds.txt.

Variations:

Apple-specific bypass: some operators want iOS to not pop the sheet (so the device joins quietly and the user has to navigate to a URL manually to see the page). To suppress, serve the success page to /hotspot-detect.html and the credential page to everything else.
Android-specific bypass: serve HTTP 204 to /generate_204 and credential page elsewhere.

These bypasses are useful when running long-duration captures where you want devices to stay connected without users actively engaging.

5.3 HTML authoring (forward-ref Vol 8 § 5)

The HTML lives on the SD card at /marauder/evil_portal/index.html (preferred) or in the firmware-bundled data/index.html (fallback). Vol 8 § 5 has the full authoring conventions; capsule here:

Form must use <form action="/get" method="get"> (GET because Marauder logs query-string args; POST is supported in newer mainline builds via <form action="/post" method="post">).
Named input fields: any name; Marauder logs all of them.
Static assets (CSS, JS, images) can be bundled in data/portal/ and referenced relatively.
32 KB total page-size soft limit (smaller is faster).

Community templates ship for common pretexts: hotel check-in, conference reg, ISP login, Wi-Fi terms-of-service.

5.4 Credential capture and the `creds.txt` log

creds.txt on the SD card receives one line per captured credential set:

2026-05-13T14:32:17, AP=MarauderGuest, IP=10.0.0.42, MAC=A4:5E:60:11:22:33, username=jdoe, password=hunter2
2026-05-13T14:35:08, AP=MarauderGuest, IP=10.0.0.43, MAC=DC:A6:32:44:55:66, username=admin, password=admin123

Field names match the form’s input name attributes. Multiple submissions from the same MAC are logged separately (Marauder doesn’t deduplicate).

Handling captured credentials (forward-ref Vol 11 § 7 for the broader chain-of-custody discussion):

Treat creds.txt as sensitive evidence. SD-card encryption is not available in mainline; physical SD-card access protects everything.
Hash creds.txt (sha256) immediately on retrieval to lock the content.
Sanitize before sharing — redact obvious bystander data; deliver only the engagement-relevant captures.

5.5 Operational signatures

Evil Portal is extremely conspicuous on the air:

A new open SSID appears in everyone’s Wi-Fi list.
Marauder’s MAC is broadcast in beacons.
Every device that joins receives DHCP from a unique-looking server (Marauder’s IP).
Every DNS query goes to Marauder — visible to anyone running a packet sniffer.
The HTTP server identifies itself in the Server: header (configurable in some builds).

Any competent Wi-Fi IDS or even alert end-user will spot this within minutes. Evil Portal is not a stealthy attack; it relies on social-engineering (the user willingly enters credentials into the captive page) rather than RF stealth. Run with the engagement plan + legal-cover in hand.

6. Targeting strategies

Selecting what to attack is half the engagement quality. Common strategies:

Strategy	Approach	When applicable
By BSSID	Pick exact AP from AP-list scan	Most common — Vol 4 § 4 populates the list
By SSID	Attack all APs broadcasting a named SSID (multi-AP campus)	Site-wide engagement; multiple BSSIDs share one SSID
By client MAC	Targeted deauth at one station only	The deauth-and-rejoin handshake-capture flow (Vol 4 § 6.3)
By RSSI threshold	Only attack APs above -60 dBm (in close range)	Narrow effect — reduces collateral damage to distant networks
By client count	Only attack APs with > N associated clients	Maximize handshake-yield per attack
By manufacturer OUI	Filter to specific OUI prefix (e.g., Cisco enterprise)	Targeted engagement against specific equipment vendor

Marauder exposes BSSID and SSID filters in Settings. RSSI threshold, client count, and OUI filters are not exposed in mainline UI — they require pre-filtering on the host (run an AP scan, decide the targets, then set BSSID manually).

Narrow first. Almost every attack in this volume scales blast-radius poorly — broad attacks affect everyone in RF range, including third parties unrelated to the engagement. Default discipline: identify specific targets in advance, configure narrow filters, fire only at those.

7. Build flags that gate attacks

Inventory of the attack-related build_flags from Vol 3 § 9, repeated here with operational context:

Flag	What it gates	Default state
`MARAUDER_DEAUTH`	Compile deauth attack into the firmware	Often OFF in mainline pre-built binaries — rebuild from source to enable
`MARAUDER_PROBE_SPAM`	Compile probe-spam menu entry	ON typically
`MARAUDER_BEACON_SPAM`	Compile beacon-spam menu entry	ON by default — the most common attack
`MARAUDER_EVIL_PORTAL`	Compile Evil Portal menu entry	ON by default
`COUNTRY_US` etc.	Channel-region restriction; affects which channels attacks can fire on	One must be set

The deauth flag is the most-asked-about. If you flashed mainline from the web flasher and the Deauth menu entry is missing, it’s because the web-flasher-served binary was built without MARAUDER_DEAUTH. Two solutions: rebuild from source with the flag enabled (Vol 10 § 3), or flash Ghost ESP (which usually ships with deauth on).

8. Output and credential capture summary

Where each attack’s output lives on SD:

Attack	Output file	Format	Notes
Deauth	(none)	—	Deauth doesn’t produce capture output; pair with Vol 4 EAPOL sniff
Beacon spam	(none)	—	Open-loop transmit; no capture
Probe spam	(none)	—	Same
Karma	(none)	—	Captures any associations only if Evil Portal is also running
Evil Portal	`creds.txt`	Plain text, comma-separated	One line per credential submission
Evil Portal	`evil_portal.log`	Plain text	Connection/disconnect events with timestamp + MAC

The fundamental asymmetry: scan modes (Vol 4) produce capture output; attack modes mostly don’t. The exception is Evil Portal, which is a hybrid — it generates RF (the SoftAP) and captures (cred submissions).

9. Operational hygiene (forward-ref Vol 11)

Brief here; full treatment in Vol 11.

Own the airspace — only fire attacks on RF you own (lab) or have written authorization for (engagement). Casual use against neighbors / coffee shops / passing strangers is criminal in essentially every jurisdiction.
Plan blast radius — narrow targeting first (§ 6). Default to specific BSSIDs or client MACs, not broadcast attacks.
Document everything — date/time/location/target BSSID/justification. Chain-of-custody for any captured material (especially Evil Portal creds.txt).
Time-box — set a duration and stop. Open-ended attacks are how operators get caught.
Sanitize — purge SD card after engagement. Hash + verify + secure-delete.
Coordinate with other engagements — if a colleague is running a packet capture on the same site, your beacon spam will pollute their capture.

The single most-violated rule in practice: own the airspace. Resist the temptation to test on neighbor networks. The legal exposure is real and undocumented engagements have ended careers.

10. Resources

Standards

IEEE 802.11-2020 § 9.4.1.7 (Deauth Reason Codes)
IEEE 802.11w (Management Frame Protection, folded into 2020 base)
WPA3 specification: https://www.wi-fi.org/discover-wi-fi/security

Captive-portal detection mechanics

iOS captive portal detection: https://support.apple.com/guide/security/security-of-runtime-process-sec15b6f5fa1/web
Android captive portal: https://source.android.com/docs/core/connect/captive-portal
Windows NCSI (Network Connectivity Status Indicator): documented in MS docs

Tools and references

mdk3 / mdk4 (the reference deauth/spam tools that predate Marauder): https://aircrack-ng.org/doku.php?id=mdk3
aireplay-ng (aircrack-ng’s deauth tool): part of aircrack-ng suite

Forward references in this series

Capturing the handshake the deauth induces: Vol 4 § 6.3
Evil Portal HTML authoring conventions + community templates: Vol 8 § 5
Capture analysis pipeline (host side): Vol 9
Fork-specific deltas (Ghost ESP runtime beacon-rate, multi-SSID karma, etc.): Vol 7
Build toolchain + flag-flipping (turning on deauth): Vol 10 § 3
Full operational posture / detection / legal: Vol 11

This is Volume 5 of a twelve-volume series. Next: Vol 6 covers the Bluetooth subsystems — BLE advertising scan, the BLE-spam variants (Sour Apple / Swiftpair / Easysetup / Google Fast Pair — mostly in Ghost ESP, not mainline), AirTag detection, BT-classic scan on classic-ESP32 hardware.

ESP32 Marauder Firmware Volume 5 — Wi-Fi Attack Subsystems

Contents