So now that we know what containment looks like (see 2nd post here), how do you find the offending device if it is actually containing your APs? The issue here is that you don’t know what the device is that is doing the containment because you only see the spoofed frames in a packet capture. It could be an AP that is servicing other clients, but you don’t know which SSID it is broadcasting. If you did, you could just track the signal strength of the SSID and walk around until you find the strongest signal. So how do you track down something that isn’t known to be broadcasting anything?
Here is how I have done it. There may be other (better) ways. If you know one, please share!
If we look back at the same packet capture in my previous blog post, you can see there is a column called “Signal.” The signal strength is what is seen from the perspective of the adapter taking the packet capture. I am using a Netgear A6210 here.
The big item to note is the difference in signal strength between the authorized AP frames (beacons, probe responses, and encrypted data), and the rogue AP frames (deauths and disassociations). All frames appear to be from the same BSSID/source address but the signal strength is very different between the beacons (44%) and the deauths/disassociations (100%). The beacons would be from the authorized AP while the deauths/disassociations are from the rogue AP. My client adapter is very close to the rogue AP in this example.
Another indicator you have 2 APs in play could be the data rates used. Notice the deauths/disassociations are using 6 Mbps as the data rate while the beacons are sent at 12 Mbps. This is because I configured my authorized SSID to use 12 Mbps as my lowest data rate, but the rogue AP doing containment doesn’t mimic that. This could be more obvious in a 2.4 GHz scenario where you (hopefully) have disabled 802.11b rates.
Now if the rogue AP is also broadcasting the same SSID in an attempt to get clients to join it for a Man-in-the-Middle attack, we would see beacon frames with different source addresses and BSSIDs. You could then hone in on the MAC that is not your vendor of AP by looking up the vendor OUI here. Then track it down with an Aircheck or utility on your phone.
I am using Savvius OmniPeek for my packet captures above, but you can also use Wireshark, though it shows up slightly different.
In the OmniPeek capture (top) you can see it uses Signal as a percentage, though you can also add the Signal dBm column if you prefer. In the Wireshark image above I added both Signal [dBm] and Signal strength in %. The deauths/disassociations are at -43 dBm/55% and the beacons are -69 dBm/27%. So again, my AP doing the capture is closer to the rogue device than the authorized AP.
Obviously walking around with an AP doing the packet captures and sending them to a laptop running Wireshark is not ideal, so I will focus on the Omnipeek method using the Netgear adapter for my example. I don’t own a Mac that can natively capture wireless packets.
How you find the rogue AP, if you didn’t pick up on it already, is by playing a game of Hot and Cold. Start walking around with the packet capture running and watch the signal strengths change. It can be easier to watch by filtering the capture to only show the BSSID you are looking at as I did below. Or you can filter by the deauths and disassociations specifically to watch only those frames.
In a real environment you will likely not be close to the rogue AP initially, but closer to your AP that is being contained. Often starting underneath your AP and walking around looking for the rogue AP. See image below. Notice the signal strengths are stronger for the beacons than the deauths/disassociations.
Here is a capture of when I was about equal distance between the rogue AP and the authorized AP. Signal strengths of the beacons and deauths/disassociations are fairly close at 73-76%. This can be tricky if you happen to start somewhere like this. If you move toward or away from your AP you will start to see a larger signal disparity.
Here is a capture showing when I was closer to the rogue AP and further away from the authorized AP.
This works if the rogue AP is constantly sending deauths/disassociations. Usually this will occur anytime a client is connected to the SSID that the rogue AP is containing. So you may have to have a phone or something handy to constantly be trying to associate to the SSID in order to ensure you see the deauths/disassociation frames.
There you have it. You find the rogue AP with a slightly more complex game of Hot and Cold. The hardest part is figuring out which frames are coming from the rogue device. Once you know, just track it down and have your way with it when you find it. 🙂