Deauthentication Attack is an attack that spoofs the IEEE 802.11 management frame "Deauthentication (Subtype 0x0C)" to forcibly tear down an active session between an AP and a client. It runs on a Wi-Fi card you can buy for a few thousand yen plus aircrack-ng / mdk4 / wifite — a classic attack, and still very much current in 2026. The root cause is the historical design choice in the 1997 802.11 specification: "management frames are cleartext, unauthenticated." This article covers the mechanism, four attack scenarios, the tools, real-world incidents, defenses via 802.11w / WPA3, and the legal status under Japan's Radio Act and the US FCC.
802.11 frames and the historical flaw in management frames #
At the MAC layer, IEEE 802.11 broadly splits frames into three classes.
| Class | Role | Encryption (WPA2 era) |
|---|---|---|
| Data Frame | Actual user data (HTTP / TCP etc.) | Encrypted under WPA2 |
| Control Frame | Low-level control (RTS / CTS / ACK ...) | None |
| Management Frame | Beacon / Probe / Association / Deauthentication / Disassociation | Unencrypted even under WPA2 (when PMF is not in use) |
The problem is in the Management Frame. The critical frames that govern connection lifecycle (Authentication / Association / Deauthentication / Disassociation) were deliberately left in cleartext and without authentication — a decision that survived from the original 1997 specification onwards.
The consequence is that an attacker can impersonate either the AP or the client and, by sprinkling Deauth frames around, can:
- Disconnect a connected client
- Fool the AP into believing "this client has disconnected"
- After disconnection, capture the handshake when the client auto-reconnects, or steer it into an Evil Twin
No credentials, no WEP / WPA key — nothing about the target AP or client needs to be known up front. That is what makes Deauth Attack so structurally strong.
Structure of a Deauth frame #
A real Deauth frame on the wire is tiny — roughly 26 bytes of payload.
| Field | Length | Content |
|---|---|---|
| Frame Control | 2 bytes | Type=Management / Subtype=0x0C |
| Duration | 2 bytes | NAV |
| Address 1 (DA) | 6 bytes | Destination MAC |
| Address 2 (SA) | 6 bytes | Source MAC ★spoofable |
| Address 3 (BSSID) | 6 bytes | BSSID |
| Sequence Control | 2 bytes | Sequence number |
| Reason Code | 2 bytes | Disconnect reason (this is the whole payload) |
| FCS | 4 bytes | CRC32 / integrity check only — does not prevent tampering |
Common Reason Code values #
- 1 — Unspecified reason / the most generic, most commonly used in attacks
- 2 — Previous authentication no longer valid
- 3 — Sending STA leaving (deauth/disassoc)
- 7 — Class 3 frame received from nonassociated STA
Why these can be sent in cleartext and without authentication — the spec history #
The vast majority of installed devices run WPA2 / Mixed Mode, and public Wi-Fi and legacy corporate APs commonly leave PMF off. Rewriting Address 2 (SA) to any MAC lets the attacker impersonate either the AP or the client. With a Wi-Fi card supporting monitor mode and packet injection, you can fire hundreds to thousands of Deauth frames per second.
Four attack scenarios — Deauth is a building block #
"Deauth Attack" makes most people think of DoS (forced disconnection), but real-world abuse patterns are more varied — and Deauth is usually used as a component embedded in a larger attack.
| Scenario | What happens | Typical tools |
|---|---|---|
| ① Pure DoS | Broadcast Deauth in a loop → every client in range cycles between disconnect and reconnect. Physical impact on electronic locks, IP cameras, IoT | aireplay-ng / mdk4 / wifite |
| ② WPA2 4-way Handshake capture | Single Deauth → client auto-reconnects → capture 4-way handshake → offline dictionary attack | aircrack-ng / hashcat |
| ③ Evil Twin / Rogue AP steering | Set up a rogue AP with the same SSID, then Deauth to disconnect from the real AP → client reconnects to the stronger rogue → MITM | airbase-ng / WiFi-Pumpkin / EAPHammer |
| ④ 5GHz → 2.4GHz downgrade | Deauth the 5GHz AP off → client falls back to a 2.4GHz AP with the same SSID, or a rogue AP | mdk4 |
Sequence for scenario ② (handshake capture) #
aireplay-ng --deauth 1 -a [BSSID] -c [Client MAC]. Stealthier than broadcast.capture.pcap via airodump-ng.hashcat -m 22000 capture.hc22000 wordlist.txt on a GPU. A weak WPA2-PSK falls in hours to days. WPA3 SAE is dictionary-resistant offline.The crack itself is a separate step that happens after handshake capture. Deauth's role is to provide the necessary precondition — "force a re-association." Cases where Deauth itself is the goal are actually the minority; in practice, it is most often the opening move in a larger compromise.
Tools — readily available as OSS #
| Tool | Purpose |
|---|---|
| aircrack-ng suite | Industry standard — airmon-ng (monitor mode) / airodump-ng (scan) / aireplay-ng (Deauth injection) / aircrack-ng (cracking) |
| mdk3 / mdk4 | More destructive — mass Deauth flooding / Beacon flood / Authentication flood |
| wifite / wifite2 | An automation front-end for the aircrack-ng suite. One command does Deauth + handshake capture + cracking |
| scapy | Build arbitrary 802.11 frames from Python — custom Deauth, learning |
| bettercap | A general-purpose MITM framework — Wi-Fi module includes Deauth |
| airbase-ng / hostapd-mana / WiFi-Pumpkin | Build Evil Twin / Rogue APs (combined with Deauth) |
# (1) Put the Wi-Fi card into monitor mode
$ sudo airmon-ng start wlan0
# → wlan0mon is created
# (2) Find the target AP's channel / BSSID / client MAC
$ sudo airodump-ng wlan0mon
# → BSSID = XX:XX:XX:XX:XX:XX / Channel = 6 / Client = YY:YY:YY:YY:YY:YY
# (3) Lock onto that channel and capture
$ sudo airodump-ng -c 6 --bssid XX:XX:XX:XX:XX:XX -w capture wlan0mon
# (4) From another terminal, inject Deauth (--deauth 10 = 10 frames)
$ sudo aireplay-ng --deauth 10 -a XX:XX:XX:XX:XX:XX -c YY:YY:YY:YY:YY:YY wlan0mon
# (5) Confirm the handshake landed in capture-01.cap → crack
$ sudo aircrack-ng -w wordlist.txt capture-01.cap
KEY FOUND! [ password123 ]from scapy.all import *
bssid = "XX:XX:XX:XX:XX:XX"
client = "YY:YY:YY:YY:YY:YY"
# Deauth frame (Subtype 12 = Deauthentication)
pkt = RadioTap() / \
Dot11(type=0, subtype=12, addr1=client, addr2=bssid, addr3=bssid) / \
Dot11Deauth(reason=7)
sendp(pkt, iface="wlan0mon", count=10, inter=0.1)Running these commands against someone else's Wi-Fi is illegal in Japan under the Radio Act and the Unauthorized Computer Access Act. They are only allowed against an AP you own / your home LAN / targets contracted under a pentest engagement. See the final section for details.
Notable incidents — when Deauth caused real harm #
| Year | Incident | Details and lesson |
|---|---|---|
| 2014 | Marriott Hotel ($600,000 FCC fine) | Marriott Gaylord Opryland (Nashville) used Deauth to forcibly disable conference attendees' personal Wi-Fi hotspots, pushing them onto paid Wi-Fi. The FCC fined the chain $600,000 for "commercial Wi-Fi jamming" |
| 2014 | Hilton chain ($25,000 FCC fine) | Same pattern — Deauth against guests' MiFi/hotspots to force paid Wi-Fi use. $25,000 fine plus a duty to cooperate with the FCC's investigation |
| 2015 | Smart-city IoT trial | In a smart-city pilot, the Wi-Fi control channels of streetlights and outdoor IP cameras went down under Deauth during testing — exposing the structural weakness of building critical infrastructure on Wi-Fi-controlled IoT |
| 2016-2020 | Public Wi-Fi credential theft | Multiple reported cases at airports, cafes, and hotel lobbies where Evil Twin combined with Deauth was used to harvest social-media and email credentials. One of the things that pushed Wi-Fi Alliance to mandate WPA3 |
| 2017 | Disclosure of KRACK | Mathy Vanhoef's WPA2 KRACK vulnerability works on its own, but real-world exploitation typically combined it with Deauth to force re-association — useful for triggering nonce reuse |
| 2018- | Physical-security research | Various studies showed that office IP cameras, electronic locks, and access-control systems on Wi-Fi can be silenced by Deauth — entrenching the industry-wide view that "Wi-Fi-dependent physical security is fragile" |
The increasing number of products that fail over to wired (PoE Ethernet) or 4G/5G cellular is a direct response to this realisation.
Defense — 802.11w (PMF) and detection #
There is one root technical fix: enable 802.11w (Protected Management Frames, PMF).
| Mitigation | Details |
|---|---|
| Enable PMF (802.11w) | Both AP and client support and enable PMF → Deauth frames carry a MIC; tampering is detected and the frames are dropped |
| Adopt WPA3 | WPA3-certified equipment must support PMF → Deauth Attack is neutralised automatically |
| PMF Required mode | Run "Required" instead of "Capable" — non-PMF clients are rejected outright |
| WIDS / anomaly detection | A Wireless IDS pattern-matches on "lots of Deauth from a single MAC." Aruba / Meraki / Cisco all ship these |
| Physical shielding | RF shielding (paint, Faraday cages) is extreme but real for military / SCIF / DC use cases |
| Wire up critical devices | IP cameras, electronic locks, printers — anything whose loss is a physical impact — should be on PoE Ethernet |
| Monitoring | Periodically scan your own office for unauthorized APs and Deauth bursts with airodump-ng / Kismet |
# /etc/hostapd/hostapd.conf
wpa=2
wpa_key_mgmt=WPA-PSK
ieee80211w=2 # 0=Disabled / 1=Capable / 2=Required
# For WPA3
# wpa_key_mgmt=SAE
# ieee80211w=2 (required under SAE)# /etc/NetworkManager/system-connections/MyAP.nmconnection
[wifi-security]
key-mgmt=wpa-psk
pmf=3 # 0=default / 1=disable / 2=optional / 3=requiredWindows 11 / macOS / iOS / Android have shipped PMF by default for several years now. If the AP is in "Required" mode, it just turns on automatically on the client side.
- Older APs (5+ years old) may not support PMF, and firmware updates may never add it
- Public Wi-Fi prioritises compatibility, so PMF tends to be left Optional — Deauth is not blocked in practice
- Forcing PMF Required on WPA2 kicks older IoT devices (no PMF support) off the network
- In corporate environments, legacy gear on 2.4GHz often lacks PMF, forcing SSID separation between 2.4GHz and 5GHz
"Can we run PMF Required?" is the de facto litmus test of how well-defended an installation actually is against Deauth Attack.
Detection — what a Wireless IDS (WIDS) sees #
A WIDS detects anomalies on Wi-Fi, and Deauth Attack is one of the easiest classes of anomaly to detect.
| Detection signal | What it means |
|---|---|
| Large volume of Deauth from the same BSSID in a short window | Broadcast Deauth Flood (mdk4 and friends) |
| Continuous Deauth aimed at a specific client MAC | Targeted Deauth (the precursor to 4-way handshake capture) |
| Multiple BSSIDs beaconing the same SSID | Evidence of an Evil Twin |
| Abnormally strong RSSI (very close signal) | The attacker may be physically nearby |
| Cleartext Deauth arriving in a PMF-required environment | Definitively spoofed — dropped due to MIC validation failure, but logged as a warning |
OSS / commercial WIDS #
- OSS — Kismet (the classic, Linux, free) / WAIDPS / Snort with the Wireless preprocessor
- Commercial — Cisco CleanAir / Aruba RFProtect / Meraki Wireless Health — detection plus automatic mitigation bundled into enterprise APs
Modern practice is to forward Kismet logs to Splunk / Elastic and write a SIEM rule on "more than 100 Deauth frames in 1 minute against a given SSID."
Law — Japan's Radio Act and the US FCC #
Legal status in Japan #
- Radio Act §109(2) (Interference with radio facilities) — "Transmitting radio waves with the intent to interfere with another party's communication" carries up to 1 year of imprisonment or a fine of up to ¥1,000,000
- Radio Act §4 (Licensing principle) — Interference exceeding the output regulations of the Wi-Fi bands can also amount to operation of an unlicensed station
- Unauthorized Computer Access Act — When Deauth → Evil Twin steering → credential theft is chained, this can also trigger Article 5 (facilitation of unauthorized access) and Article 4 (the unauthorized access prohibition itself)
- Forcible obstruction of business (Penal Code §234) — Intentionally jamming the Wi-Fi of a commercial venue can mean up to 3 years' imprisonment or a fine of up to ¥500,000
The US FCC position #
- Communications Act of 1934, Section 333 — "Interference with the licensed communications of another party" is a federal violation
- The large fines against Marriott / Hilton were based on this provision
- In 2015 the FCC explicitly clarified that "jamming personal Wi-Fi hotspots in hotels or offices is illegal"
Pentesting and research require contracts and paperwork.
- An AP you own / your home LAN — legal
- Within the scope of a written Rules of Engagement signed with a client — legal
- Anything else done to someone else's Wi-Fi — illegal, full stop
Summary #
- Deauth Attack exploits the design flaw that Wi-Fi management frames have historically been sent in cleartext and without authentication, to forcibly tear connections down
- The 1997-vintage weakness was technically fixed in 2009 by 802.11w (PMF) and in 2018 by WPA3, but installed-base compatibility means most equipment still doesn't enable PMF — which keeps it a live, current attack in 2026
- In practice it's rarely used alone; it's the building block of larger attacks: WPA2 4-way handshake capture → offline cracking / Evil Twin steering / band downgrade
- The hardware is a single Wi-Fi card for a few thousand yen, and the software is aircrack-ng / mdk4 / wifite, so the bar to start using it (for learning and for pentesting) is low — and that low bar is why real-world incidents keep stacking up
- The root technical fix is enabling PMF Required + migrating to WPA3. Legally, it falls under Japan's Radio Act §109(2) and the US FCC Section 333 — running it against someone else's Wi-Fi is unambiguously illegal. If you want to try it, do it only on an AP you own or a contracted pentest target
