WiFi Deauthentication Frame Explained

Table of contents

• What is a Deauthentication Frame?

• Structure of a Deauthentication Frame

• Reason codes

• Disassociation vs. Deauthentication

• How deauthentication frames can be exploited

The structure and functionality of deauthentication frames are something we get asked about regularly. So we thought it was time for a blog post to explore what they are and how they work.

What is a Deauthentication Frame?

The Deauthentication Frame is a type of packet defined in the IEEE 802.11 WiFi standard. It has been part of the standard since the beginning and still plays an important role.

It's used to terminate a WiFi connection. It can be sent by either the access point or the station to let the other side know that the connection is closed.

In case you're unfamiliar with the terminology, the access point (AP) is a device that provides access to a WiFi network, for example, your home router. While a station is a client device that can connect to an access point, for example, your phone.

The station might send a deauthentication frame to the access point because it's switching to another WiFi network. Or the access point might send a deauthentication frame to the station because the router has to restart. Deauthentication works both ways, and there are plenty of reasons why they are sent - you can find a complete list of reasons below.

But one crucial attribute of the deauthentication frame is that it's not a request; it's a notification, and it can not be refused.

Structure of a Deauthentication Frame

The actual data the packet holds is very minimal:

Deauthentication frame body

Order	Information
1	Reason code
Last – 1	One or more Vendor Specific elements are optionally present.
Last	The MME is present when management frame protection is enabled at the AP and the frame is a group addressed frame.

But if you look at a deauthentication frame in Wireshark, you'd see more than just the frame body. That's because deauthentication packets are part of the family of WiFi management frames, and their format looks like this:

Octets	Description
2	Frame Control
2	Duration
6	Address 1
6	Address 2
6	Address 3
2	Sequence Control
0 or 4	HT Control
variable	Frame Body
4	FCS

In the DeautherX's code, a packet looks like this:

COPY

uint8_t deauthPacket[26] = {
    /*  0 - 1  */ 0xC0, 0x00,                         // type, subtype c0: deauth (a0: disassociate)
    /*  2 - 3  */ 0x00, 0x00,                         // duration (SDK takes care of that)
    /*  4 - 9  */ 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, // reciever (target)
    /* 10 - 15 */ 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, // source (ap)
    /* 16 - 21 */ 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, // BSSID (ap)
    /* 22 - 23 */ 0x00, 0x00,                         // fragment & squence number
    /* 24 - 25 */ 0x01, 0x00                          // reason code (1 = unspecified reason)
};

Deauthentication frame definition in DeautherX code You can find this definition in the Attack.h file.

You might notice that some data is left out of this array. For example, the frame check sequence (FCS) is not defined here. That's because it's already handled by the underlying ESP8266 SDK functions automatically. The same goes for the duration and the flags in the second byte of the frame control field.

Reason codes

As mentioned, every deauthentication frame has to contain a code for the reason of disconnect. Here is a list of the available reason codes and what they mean.

Yes, the list is quite long...

Code	Description
0	reserved
1	Unspecified reason
2	Previous authentication no longer valid
3	Deauthenticated because sending STA is leaving (or has left) the BSS
4	Disassociated due to inactivity
5	Disassociated because AP is unable to handle all currently associated STAs
6	Class 2 frame received from nonauthenticated STA
7	Class 3 frame received from nonassociated STA
8	Disassociated because sending STA is leaving (or has left) BSS
9	STA requesting (re)association is not authenticated with responding STA
10	Disassociated because the information in the Power Capability element is unacceptable
11	Disassociated because the information in the Supported Channels element is unacceptable
12	Disassociated due to BSS transition management
13	Invalid element, i.e., an element defined in this standard for which the content does not meet the specifications in Clause 9
14	Message integrity code (MIC) failure
15	4-way handshake timeout
16	Group key handshake timeout
17	Element in 4-way handshake different from (Re)Association Request/Probe Response/Beacon frame
18	Invalid group cipher
19	Invalid pairwise cipher
20	Invalid AKMP
21	Unsupported RSNE version
22	Invalid RSNE capabilities
23	IEEE 802.1X authentication failed
24	Cipher suite rejected because of the security policy
25	TDLS direct-link teardown due to TDLS peer STA unreachable via the TDLS direct link
26	TDLS direct-link teardown for unspecified reason
27	Disassociated because session terminated by SSP request
28	Disassociated because of lack of SSP roaming agreement
29	Requested service rejected because of SSP cipher suite or AKM requirement
30	Requested service not authorized in this location
31	TS deleted because QoS AP lacks sufficient bandwidth for this QoS STA due to a change in BSS service characteristics or operational mode (e.g., an HT BSS change from 40 MHz channel to 20 MHz channel)
32	Disassociated for unspecified, QoS-related reason
33	Disassociated because QoS AP lacks sufficient bandwidth for this QoS STA
34	Disassociated because excessive number of frames need to be acknowledged, but are not acknowledged due to AP transmissions and/or poor channel conditions
35	Disassociated because STA is transmitting outside the limits of its TXOPs
36	Requesting STA is leaving the BSS (or resetting)
37	Requesting STA is no longer using the stream or session
38	Requesting STA received frames using a mechanism for which a setup has not been completed
39	Requested from peer STA due to timeout
40–45	Reserved
46	In a Disassociation frame: Disassociated because authorized access limit reached
47	In a Disassociation frame: Disassociated due to external service requirements
48	Invalid FT Action frame count
49	Invalid pairwise master key identifier (PMKID)
50	Invalid MDE
51	Invalid FTE
52	Mesh peering canceled for unknown reasons
53	The mesh STA has reached the supported maximum number of peer mesh STAs
54	The received information violates the Mesh Configuration policy configured in the mesh STA profile
55	The mesh STA has received a Mesh Peering Close frame requesting to close the mesh peering.
56	The mesh STA has resent dot11MeshMaxRetries Mesh Peering Open frames, without receiving a Mesh Peering Confirm frame.
57	The confirmTimer for the mesh peering instance times out.
58	The mesh STA fails to unwrap the GTK or the values in the wrapped contents do not match
59	The mesh STA receives inconsistent information about the mesh parameters between mesh peering Management frames
60	The mesh STA fails the authenticated mesh peering exchange because due to failure in selecting either the pairwise ciphersuite or group ciphersuite
61	The mesh STA does not have proxy information for this external destination.
62	The mesh STA does not have forwarding information for this destination.
63	The mesh STA determines that the link to the next hop of an active path in its forwarding information is no longer usable.
64	The Deauthentication frame was sent because the MAC address of the STA already exists in the mesh BSS.
65	The mesh STA performs channel switch to meet regulatory requirements.
66	The mesh STA performs channel switching with unspecified reason.
67	Transmission link establishment in alternative channel failed.
68	The alternative channel is occupied.
69–65535	Reserved

Disassociation vs. Deauthentication

Besides the deauthentication frame, there is also the disassociation frame. They sound similar, work similar, and their structure is basically identical.

To understand the difference between Disassociation and Deauthenticatios, we have to understand the difference between WiFi association and authentication.

When you connect to a WiFi network, you first authenticate yourself. This is done by entering a password, for example. Then, to use the WiFi network, you now have to associate to an access point. It's simply another step before you can start browsing the web through WiFi. Of course, this is all done automatically and really fast.

In the case of a regular home router, you both authenticate and associate to the same access point. And if you disconnect, you both deauthenticate and disassociate to the same access point. But in a larger network made out of multiple access points, you might disassociate from one access point and associate to a new one while staying authenticated to the same network.

How deauthentication frames can be exploited

Deauthentication frames are very simple in their structure. You basically only need a sender or receiver MAC address. And you can obtain such by simply scanning for WiFi devices nearby.

So it's super easy to spoof a deauth packet. And keep in mind that if the target receives it, it has to drop its connection.

The target can reconnect immediately, of course, and it can do that quite fast, maybe without the user noticing that the connection was ever dropped. But if these deauth packets are sent continuously, it results in a denial of service attack, and network access is blocked for the entirety of the attack.

Luckily this was addressed, and we now have protected management frames! This feature allows packets like deauthentication frames to be safe against spoofing.

The only problem with this feature is that not every access point has it enabled yet. If you want to test if your network is safe against this type of attack, check out our DeautherX project.