Fun with WiFi: De-Authentication Attacks!

Fun with WiFi: De-Authentication Attacks!

Here I will be discussing another WiFi attack vector; deauthentication attacks.

Within the IEEE 802.11 standard, forever branded unoffically as "WiFi", there are many defined signalling types that all devices are expected to comply with, which largely consist of many expected signals for authentication, reassociation, announments, etc. One particular management frame subtype, the DeAuth signal, is sent by an access-point when it needs to clear connection sessions to free up resources, force a reauthentication handshake, or to simply tear down connections ahead of a powercycle.

DeAuth messages are just a part of normal WiFi operation, however this signal in particular relies on an unenforced layer of trust in that there is no authentication mechanism built into the signalling outside of the known MAC-address, and clients will mostly obey DeAuth requests without question. This is why DeAuth attacks are one of the most common WiFi exploits around, because they are very very easy.

When it comes to generating systhetic DeAuth signals, we have to futher compromise this layer of trust by spoofing the frame headers of the packet itself with the BSSID of the trusted access-point. Thankfully there have been tools around for quite some time to do just this, and we will be using one here to (hypothetically) deauthenitcate a device from a network. There are many reasons why you may wish want to deauthenticate a rogue wireless device from your network, but I will delving into neither the justifications nor ethics in this post.



With that out of the way we can procceed. Recon is the name of the game, and certainly the most important step to any wireless attack. There are a number of tools for every platform from Windows7 PCs to iPhones that are at your disposal for this step, but here is a favourite of mine; an absolutely fantastic TUI Linux tool called Kismet:


Similar to Netstumbler for Windows, the open-source Kismet can map all WLANs within reach and provide a wealth of details on both the wireless network, and the clients connected. Kismet has a few nifty features such as stickied notes on devices, GPS-integration and can even be run over SSH right from your shell!

The only feauture I have yet to find in Kismet is the ability to copy MAC addresses directly to xclip, and for that alone I often find myself reverting to Aircrack-NG's Airedump tool:


Once you have found your target client, you will want to make a note of 3 things; their MAC address, the MAC address of their gateway access-point, and the channel of the respective network. WiFi channels are simply slots in the Radiowave frequency spectrum, defined by the IEEE and built into the 802.11 spec. You probably already knew that, but it presents me the opportunity to show-off the visual RF analyzer built into my sweet Cisco Meraki home-lab dashboard:


Once you have these required parameters, you will be able to set your wireless adapter to match their frequency, and you can hop over to another Aircrack-NG tool to run your attack;

sudo iwconfig <interface> channel <channel>
sudo aireplay-ng -0 99 -c <client MAC> -a <AP MAC> <interface>

The -0 here is shorthand for the GNU-style --deauth operating mode, with argument 99 to specify the number of deauthentication signals to send. The rest is fairly straightforward following the above convention, and if all is correct you should see Aireplay fire up a process:


Be sure to include the -c flag in your command, else you may just deauthenticate EVERY DEVICE ON THE NETWORK. And that isn't your intention, right?

Anyway, with any luck you will get some well-deserved STDOUT from Aireplay to let you know that the attack is underway:

 11:35:25  Waiting for beacon frame (BSSID: E0:CB:BC:13:A7:C9) on channel 3
 11:35:25  Sending 99 directed DeAuth. STMAC: [30:07:4D:67:93:8F] [ 92|99 ACKs]

As we can see, our target client is respectfully acknoledging and complying with our DEAUTH request, and backing down from the network. When performing this attack within my own network to a mobile device of my own, the visibile stuttering of the WiFi connection manager is a clear flag that the attack has been successful, and I am unable to reconnect to the network until I kill the Aireplay process.

802.11 is a wonderful protocol when all partipants follow the rules, but security flaws can always, and will always, be exploited. Perhaps in the near-future when bandwidth is aplenty the 802.11 spec will be revised to build stonger trust layers into signalling plane of the protocol. But for now, it is what it is.

And that concludes this quick look into the world of WiFi. I hope to be back with more as soon as I find the time.

Thanks for reading!

Related Article