Read on Twitter
1/ I realize that I should probably spend more time talking about how to detect the tools I write, so here goes. Want to know how to easily detect #eaphammer? Check out this thread:
2/ Suppose you're tasked with monitoring a wireless network for malicious actions. This network uses some form of WPA2-EAP. How would you detect a threat actor attempting to use evil twin attacks to capture your network's credentials?
3/ Let's assume the threat actor has spoofed the BSSID of one of your APs, so basic whitelisting isn't going to work. Have they also spoofed the AP's capabilities information? I'd be surprised if they did, as capabilities tend to vary wildly from network to network.
4/ Here are just some of the individual capability parameters of an AP near my house. Unless the attacker matches all of these, and more, the presence of an evil twin AP should be blatantly obvious.
5/ But for the sake of argument, let's suppose the attacker actually does mimic one of your APs to this level of detail. Are they using the same operating channel as your AP? This is where we go from looking at brittle detections to behavior, in a way.
6/ If the attacker does not spoof the operating channel, you'll see a one-to-many relationship between a single BSSID broadcasting to multiple channels simultaneously. This isn't something that should normally occur, and is something you can monitor for.
7/ Here's the super interesting part though: suppose the attacker actually does spoof the operating channel of the target AP. If the attacker is close to the target AP, this will cause the attack to fail and make it super easy to spot that something shady is happening.
8/ Here's why - both the association and authentication processes involve a series of steps that must occur in a specific order. Both the rogue and legitimate APs expect this order to be adhered to.
9/ When the attacker uses the same BSSID and channel as the target AP, the client device will technically send traffic to BOTH the legitimate and rogue APs.
10/ This creates a race condition - both the legitimate and rogue APs will respond to traffic from the client device, but the client device isn't going to wait for both responses to continue with the authentication process.
11/ The result is that from the perspective of at least one AP (and possibility the client), it will appear as if association and authentication steps are being skipped or repeated. This causes one or more parties to throw an error, and for the entire process to fail.
12/ And guess what - you can monitor for this! 
Of course, the attacker can work around this problem by moving further away from the legitimate AP. However, this is also a dead giveaway from a defender's perspective.
Of course, the attacker can work around this problem by moving further away from the legitimate AP. However, this is also a dead giveaway from a defender's perspective.
13/ APs don't just grow a pair of legs, get up, and walk to the other side of a corporate branch office on their own. If you keep track of the signal strength of your APs from strategic locations throughout your physical environment, it should stay within a certain threshold.
14/ If one or more sensors detects that this threshold has been exceeded, you know that someone is running #eaphammer. That pretty much covers it, except for one weak point.
15/ None of this will work if the attack takes place away from your network hardware (ex. corporate laptop in coffee shop). However, you can monitor for off-premises attacks from an endpoint perspective.
16/fin If the host sees one of its APs appear without any of its usual neighboring APs, that's an indicator. The inverse is also an indicator.
