Unintentional fun with Aircrack-ng at DerbyCon 5.0

Posted by on Sep 24, 2015 in Security | No Comments
Unintentional fun with Aircrack-ng at DerbyCon 5.0

During the DerbyCon 5.0 training sessions this week, you could find plenty of access points being created. You get everything from hilarious names and references to simple emojis:


I was asked to writeup what I indirectly accomplished, so here it goes. I wanted to take a stab at creating a handful of APs that when combined, would render out with ASCII art that said DerbyCon. So I fired up VIM and created a text file called “essids.txt” with the following:


I then placed my wireless card into monitor mode, checked for a channel that wasn’t already swarming with traffic (channel 8 at the time) and configured airbase-ng (included with the Aircrack-ng suite) with the following command:


For your reference:

  • -c 8: Create the AP on channel 8
  • –essids essids.txt: A file consisting of a list of APs to create, separate by newlines
  • wlan0mon: The name of your interface, in monitor mode

You can see in the airbase-ng output, that my APs had been created successfully. Opening up the wireless menu on my Mac, I see only a single AP had been created (sad clown). In my troubleshooting, I open airodump-ng expecting to see multiple APs but instead find a single BSSID, which appeared to be cycling through the entire supplied list of ESSIDs.

If you look at the earlier output from airbase-ng, you’ll see that airbase-ng is only creating a single BSSID for all of the ESSIDs (rather than a unique BSSID for each ESSID) thus updating the display name of the AP at a rapid rate. All of this occurred while sitting in an awesome class being lead by Mister X (@aircrackng), who says that this behavior (the lack of additional BSSIDs) was indeed a bug.

This unintended outcome became my new intentional outcome, so a new file was created:


The repeating lines were to simulate “pausing” the message long enough so that it is readable when being viewed in airodump-ng (unfortunately, each OS handles updating the ESSID differently). The end result was kind of fun (and POSSIBLY somewhat pointless):

Leave a Reply