Last week, I released a tool called BeaconGraph aimed at supporting wireless auditing. As of this post, v0.2 has been released with some pretty big improvements over the initial release and can be found at the Github link above.
BeaconGraph is an interactive tool that visualizes client and Access Point relationships. Inspired by airgraph-ng and Bloodhound, BeaconGraph aims to support wireless security auditing. It is written in Python with some GUI support by pywebview and a Neo4j database backend. Relationship rendering is supported by cytoscape.js and the overall application is served by Flask.
Why is it needed?
I’ll start by saying that I’m not a wireless engineer or auditor by any means. I’ve never even been a network engineer or a network administrator for anything more than 10 clients/servers. So while attending a SANS SEC617: Auditing Wireless Networks course in September, a lot of concepts were new to me. During the course, we discussed the aircrack-ng suite, and although I was aware and had practiced with many of the tools in the suite, I was introduced to airgraph-ng for the first time. I thought it was a pretty cool concept to be able to visual the relationships between clients and access points and provide information about all of them. But there was one glaring problem…
While the information was valid and nicely arranged, there was no way to quickly find or display any particular part of the graph, since airgraph-ng rendered PNG files. It crossed my mind that this would be a problem in much larger graphs for auditors, or generally anyone wishing to quickly view the data provided. Additionally, it was mentioned in that class that airgraph would crash if the data provided to it was too large.
Thanks to some recent interactions with Bloodhound and it’s use of neo4j for graph visualizations, the idea for BeaconGraph nearly became a reality the next day when I established a very quick proof of concept using Python and the neo4j browser. The script accepts airodump-ng formatted CSV files and parses them into client-AP relationships, then stores them in the neo4j database. It established “Probe” and “AssociatedTo” relations:
- Probe: The client device was actively probing for some Access Point that it has saved.
- AssociatedTo: The client device was associated to a particular AP at the time of the traffic capture.
The neo4j browser displayed all the relationships pretty nicely in some great pastel (bleh) colors but this delivery wasn’t very user friendly, as the neo4j browser is just a means of querying the database.
Here’s where it got a bit difficult. As I mentioned, I am not a wireless network engineer so I can’t speak on the possibilities that BeaconGraph could be used for in an assessment. Here are some scenarios I thought might be possible.
- An audit to verify the access points that portable devices have only connected to approved access points. If a device has an unapproved access point saved (like most users do), it’ll be easy to spot with BeaconGraph and “Probes” edges.
- An audit to look for unauthorized APs in an environment. Granted, there are other tools to assist with this but BeaconGraph provides nice visuals to use in reporting.
The most recent scenario I thought of before drafting this write-up was not for auditing but from a penetration testing/red team perspective. After loading a significantly larger WiFi signal dataset gathered while traveling, I decided to perform some basic analysis with BeaconGraph to determine if there was any interesting data or attack approaches that could be discovered.
In this picture (yes, the node and neighbors are highlighted for visual pleasure!), we can see that there are a ridiculous amount of devices probing for a TMobileWingman access point. This TMobileWingman AP is saved on nearly every T-Mobile device managed networks and can’t be removed. It uses 802.1X EAP authentication and is used for in-flight texting with GoGo. Since it can’t be removed, T-Mobile devices are constantly probing for this network and, like any other saved AP, will attempt to connect to a properly configured AP with the same ESSID. There is a possibility of trying to perform some rouge attacks with Evil Twin tool eaphammer, but that isn’t what I immediately noticed.
The device currently in focus with the MAC address of DC:EF:CA:7C:08:0E is quickly enumerated as a T-Mobile device, as it was probing for the TMobileWingman AP. That same device was also associated to free wifi access point. If this device were to be targeted as a means of gathering credentials, it would be trivial to use a Man-In-the-Middle attack to present a T-Mobile themed web page to the user.
Additionally, with BeaconGraph, it’s easy to quickly visualize which access points are the most popular (xfinitywifi, attwifi and TMobileWingman seem to be the usual culprits) and prepare a Known WLAN list for tools such as WifiPhisher during assessments.
BeaconGraph should be a welcome tool to any wireless auditor or penetration tester. While not yet considered a full release at just v0.2, there are plans to expand its features in the future. Graph visualization is an amazing medium to representing data for technical and management perspectives so check out BeaconGraph if this type of representation interests you!