Having recently completed a wireless network security assessment of an organization, I thought it useful to document the steps and tools I used on the engagement. This write-up largely covers the passive phase of discovering SSIDs in use within the client’s network, identify access points in use, and then finishing this phase with traffic analysis and wireless profiling. It is in this phase that we evaluate the cryptographic strength of the encryption algorithms in use along with any additional security controls in place.
After the passive phase comes the attack scenario, but that is going to be out of scope for this write-up. Instead, we’ll focus on the hardware and terminal commands and tools used to gather the information needed to carry out the attack scenario afterwards.
First, everything I’ll be doing will be using a Kali iso within VMware. Not my usual go-to Kali instance though. This is a Kali VM I use solely for wireless assessments and I try to change it as little as possible after I tweak it to work. This wont keep out every gremlin, but it makes things a little easier. Wireless tools are finicky, and different drivers, tool versions, chipsets and settings can lead to hours of troubleshooting. This is especially troublesome as a lot of what you do on wireless engagements is very time sensitive.
For hardware, I used the panda wireless PAU09 card. Its been a great little tool and is widespread and highly recommended in the community. Also they are fairly inexpensive so its not difficult to grab 2 or 3 of these, though for this assessment I used only one.
To set this up, simply plug it in to the port > navigate to the virtual machine tab in the menu bar of your Kali VMware > select USB & Bluetooth > select Ralink USB (it comes up as that for some reason). Now to test it and see if your computer is seeing the device.
lsusb
This command will list out the devices and if you see your device (Ralink Technology Group in the case of my panda card) you are one step closer. Now to see if it can connect to the proper interface
iwconfig
This command will allow you to display/ change parameters of the network interface. When typed in, you should see lo displays no wireless connections, eth0 displays no wireless connection, and you should now see wlan0 as displaying the name of your device. If you don’t see that, I’m so sorry, troubleshooting must begin now and at this stage its probably linked to your drivers or settings of your VM.
airmon-ng
Now we use airmon-ng in order to check and make sure there are no services that will interfere with the panda. Run the command:
airmon-ng check
There is likely to be services that are shown with airmon-ng check. Especially if the reader is using a fresh install of Kali. So you will very likely need to run airmon-ng check kill to conveniently kill these services:
airmon-ng check kill
Now we start airmon-ng with the start command followed by the interface created by the panda:
airmon-ng start wlan0
Kismet
Now that we have our wireless cards working we can start up Kismet, the “wireless network and device detector, sniffer, wardriving tool, and WIDS (wireless intrusion detection) framework.” For this write-up, though it be published well into the 2020’s where there exists a newer version of Kismet, you may find in that there are a lot of professionals in the industry that still prefer the older version, found here:
https://www.kismetwireless.net/downloads/#kismet-legacy
The reason being that there are certain important filter options present in the older version that the newer version’s web UI lacks, ergo, we will be using the legacy version in this walk-through. After installing kismet we have to set the ncsource to wlan0 by un-commenting it in the conf file:
vim /etc/kismet/kismet.conf
Now kismet has our permission to help itself to the wlan0 interface. The first command we’ll use after we install Kismet is:
kismet -n
This command will start up kismet but the -n flag will keep it from logging the information it gathers. This is useful for setting up kismet and troubleshooting if need be without needlessly creating dozens of logs to confuse us later.
Navigating kismet is easy, just use the ~ to jump up to the main menu and use arrows to determine choices from there.
You will find your display varies from mine. This is because I have customized my columns to give me the information I deem most valuable for the engagement. You can do the same with ~ > Kismet > preferences > network columns. From here you can set what you want displayed and in what order with space to toggle On/off and +/- to change order of appearance. My preferences are shown below:
Now we’re ready to start the real analysis. On an engagement you will likely have several networks in scope to be looking for and these will appear in the SSID column. Once you have found one or all of them, take note of every channel they appear on.
For example, suppose our network in scope is CableWiFi. We find our domain in the SSID column, and then note each channel it appears on.
We note the channels 6, 149, 1 and 11. There would likely be more on a real engagement but four will serve the purpose of this example splendidly. For now kismet has served its purpose, we can power her down. We now fire up airodump-ng.
airodump-ng
As we begin the process of narrowing our target, we start with airodump-ng to capture traffic and filter unassociated clients.
airodump-ng --ignore-negative-one -a --band ag --channel 1,6,11,149 --essid CableWiFi wlan0
–ignore-negative-one = removes message that says fixed channel wlan0: -1
-a = filters unassociated clients
–band = band on which airodump-ng should hop
–channel = specific channel to capture traffic
–essid = filter APs by ESSID
Once we initiated the command, we watch our tailored results come in and we hope to see BSSID’s that have associated clients connected. We also pay attention to the channels we see most often here when we do spot one with associated clients.
What we hope for is clients to pop in below the last line in the above image as they connect to the access points, which a necessity when seeking to carry out relay attacks, but that hasn’t happened with this demo. If it did, we would take note of the channel(s) associated with the most clients and narrow our command further:
airodump-ng --ignore-negative-one -a --band ag --channel 6 --essid CableWiFi wlan0 -w CableWiFi
-w (–write) = We now create a log file which is vital for the next component of this assessment within Wireshark.
Now we’ll leave aireplay-ng out for another time. For now, lets not focus on capturing handshakes to crack and instead on determining what ciphers and authentication key management is in place with Wireshark
Wireshark
We open Wireshark and open the .cap file which we saved when we used the -w flag along with a name in our airodump-ng command. Ours would be CableWiFi-01.cap for example. Now we hit the info column header to organize into groups by the info category. What we’re looking for is the probe response which is the response to our probe request. When an access point sees a probe request frame directed at the specific access point (or to all stations in the area using the broadcast SSID) it will send out a probe response. Once we find one we can select it ant then below expand IEEE 802.11 wireless LAN > tagged parameters > Tag: RSN information (robust security network). This shows us ciphers in place like TKIP or AES and if we expand Auth key management as well, we see the type, like PSK.
There is so much you can do at this point but that as far as we’ll go in this walk-through. Good luck in your pursuit of root.
Thank you to Matt B for teaching me all of this and Brett L for the PR.
pursuit_of_root 