This content was originally published on the SpecterOps blog. The original can be found here: https://posts.specterops.io/modern-wireless-attacks-pt-i-basic-rogue-ap-theory-evil-twin-and-karma-attacks-35a8571550ee
The past few years have seen some exciting developments in the subtle art of forcing wireless devices to connect to malicious access points. We’ve seen the resurgence of karma-style attacks with Dominic White’s and Ian de Villiers’ work on MANA, as well George Chatzisofroniou’s Lure10 and Known Beacon attacks, which can be used to target devices that are immune to karma .
I wanted to dive deeper into these techniques and understand how they work at a deep technical level, and attempting to implement them myself seemed like a perfect opportunity to do so. This writeup was originally intended to be a relatively short narrative of my efforts to recreate these techniques and incorporate them into EAPHammer (see: https://github.com/s0lst1c3/eaphammer). However, given the general lack of focus on this subject within the threat replication community, as well as the recent high profile cases in which rogue AP attacks were used in the wild (i.e. the string of attacks by Russia’s GRU against targets in the US and Europe that occurred earlier this month), I decided to expand this post into something a bit lengthier .
The result is a four part series of blog posts intended to provide a detailed roadmap of rogue AP fundamentals aimed at people who are interested in learning more about modern wireless security at both an operational and technical level. In this series, we’ll go over nearly all of the ways that an adversary can abuse 802.11 to initiate a Person-In-the-Middle (PITM) attack. Additionally, we’ll discuss why these techniques were developed, tracing the history of both rogue AP attacks and corresponding mitigations from the early 2000s to the present day. Finally, this series will provide operational guidance for both offensive and defensive practitioners.
Acknowledgement of Prior Work
Before proceeding any further, I need to make something perfectly clear:
I did not invent the techniques listed throughout this guide, nor was I the first to write tools that implement them. The originators of the techniques described in this writeup are Dino A. Dai Zovi, Shane Macaulay, @_sophron (George Chatzisofroniou), @singe (Dom White), and Ian de Villers. These authors will be cited throughout this writeup, so please provide credit where it is due.
In spite the amazing work done by these people, this was probably one of the most challenging endeavors I’ve ever attempted. Implementing the techniques described in this guide took a solid four months of on and off work. Most of the attacks described in this guide had to be patched directly into hostapd (see: https://w1.fi/cgit/hostap/), which is a massive and complicated codebase written in kernel-level C. Debugging was challenging, and subtle memory corruption bugs were a pretty common occurrence towards the beginning of the project (although my ability to manage these got better over time). Needless to say I learned a lot, and seriously leveled up my proficiency with C, but this project still would have been much more difficult without prior work providing a road map for my development.
The 802.11 protocol defines two entities that can be present in a wireless network:
- Base Stations: Client devices that connects to an access point (i.e. laptops, phones, etc). This writeup may, at times, use the terms “station(s)”, “base station(s)”, “client(s)”, and “client device(s)” to describe the same thing. 
- Access Points (APs): Networking hardware that provides stations with access to the distribution system (i.e. network) 
These two entities can be used to build the three fundamental network types defined by 802.11:
- Extended Service Set (ESS) (aka “Infrastructure” network): Infrastructure networks will be the primary focus of this writeup, so pay attention to this part. BSS’s within infrastructure networks consist of zero or more stations connected to an access point, and are identified by their Basic Service Set Identifier (BSSID). The Extended Service Set (ESS) itself is comprised of one or more BSS’s joined by a common Distribution System (DS). The DS itself can be any sort of wired or mesh network that links the access points together .
- ‘Independent Basic Service Set (IBSS) (aka “Ad-Hoc” network): IBSS networks don’t require an access point, and consist of at least one base station. We’re not covering this type of network in this writeup .
- Mesh Basic Service Set (MBSS) (aka “Mesh” network): EBSS networks consist of one or more mesh stations consisted to zero or more mesh gates (what???). Sound confusing? Don’t worry about it — as interesting as mesh networking may be, it’s not pertinent to what we’re discussing here .
Network Selection and Roaming
Although the 802.11 protocol has very specific rules that dictate how a station can join an ESS, it does not specify how the station should select an ESS to connect to. Additionally, the protocol allows stations to roam freely between access points that share the same ESSID (because you wouldn’t want to lose WiFi connectivity when walking from one end of a building to another, etc). However, the 802.11 protocol does not specify how these access points should be selected. Furthermore, even though stations must be authenticated to the ESS in order to associate with an access point, the 802.11 protocol does not require the access point be authenticated to the station .
This ambiguity was deliberately built-in to the protocol to grant hardware manufacturers a degree of flexibility when designing client devices. However, this ambiguity is also what makes each of the attacks described in this writeup possible . In the sections that follow, we’ll go over each of the algorithms that are currently used by client devices for network discovery and selection, as well as access point selection during roaming. We’ll then describe the network attacks that can be used to abuse those algorithms.
Preferred Network Lists (PNLs)
Each time a station connects to a wireless network, the network’s ESSID is stored in the station’s Preferred Network List (PNL). The PNL is an ordered list of every network that the station has connected to in the past, and each entry in the PNL contains the network’s ESSID and any network-specific configuration information needed to establish a connection .
The first network selection algorithm used by client devices is known as passive scanning. In infrastructure networks, access points periodically transmit beacon frames to advertise their presence and capabilities to nearby stations. Beacons are broadcast frames, which means they are intended to be received by all nearby stations in range. Beacons include information about the AP’s supported rates, encryption capabilities, and additional information. Most importantly to this writeup, beacon frames contain the AP’s ESSID (as long as ESSID broadcasting is not disabled).
During passive scanning, the client device listens for beacon frames from nearby access points. Client devices are typically configured by default to connect to networks within their PNL automatically. If this is the case, and the client device receives a beacon frame whose ESSID field matches an ESSID from the client’s PNL, the client will automatically connect to the access point that sent the beacon frame . This process is depicted in the following animation:
Using Evil Twin Attacks to Abuse the Passive Scanning Process
As mentioned earlier, the 802.11 protocol does not require access points to authenticate themselves to stations. In fact, all forms of authentication that are used in 802.11 wireless communication are layered on top of the core 802.11 protocol, and do not take place until a client device has decided to connect to an access point. Furthermore, stations using passive scanning rely exclusively on beacon frame ESSID fields to determine which ESS an access point belongs to .
Suppose we want to target a wireless device that is not currently connected to any wireless. If we know at least one entry in that client’s PNL, we can force the client to connect to us simply by creating our own access point with that entry’s ESSID. The reason why this works is that our access point will transmit beacon frames which will be received by the client device. The client device will compare the ESSID field in the beacon frames to its PNL, and attempt to connect to our AP when the match is found .
As previously mentioned, the 802.11 protocol allows stations to roam freely between access points within the same ESS. However, the standard does not specify how stations should select an AP to connect to when multiple APs within the station’s ESS are available. Client devices are typically optimized to respond to this situation by selecting the access point that provides the best connection, which usually boils down to a combination of signal strength, throughput, and signal to noise ratio. As with automatic network selection, client devices rely on beacon frame ESSID fields to determine what nearby APs are part of their current ESS .
Using Evil Twin Attacks to Abuse 802.11 Roaming
We can abuse the 802.11 roaming process by creating an access point with the same ESSID as the network we wish to target. If we can provide a better signal than the target network’s access points, any client devices associated with the target network will roam to our rogue access point . We can do this in one of two ways:
- enticement: We provide a superior signal than the target access point, which entices a client device to roam to our AP
- coercion: We block access to the target access point using deauthentication packets, jamming, or some other form of denial-of-service (DoS) attack. This coerces any client devices connected to the AP to roam to our rogue access point.
Abusing 802.11 Roaming with EAPHammer
In the next two sections, we’ll go over how to use EAPHammer to abuse 802.11’s roaming process in order to force client devices to connect to a rogue AP.
Forced Roaming Using Enticement
To entice clients to roam to an evil twin, just create an access point with the same ESSID as the target network:
./eaphammer -i wlan0 --essid exampleCorp --captive-portal
The attack process should look similar to what you see in the following GIF:
High powered antennas can help with this style of attack, although it still may be difficult to achieve consistent results against enterprise networking hardware.
Forced Roaming Using Coercion
To coerce clients to roam to an evil twin, first create a rogue access point point with the same ESSID as the target network:
./eaphammer -i wlan0 --essid exampleCorp --captive-portal
Next, deauthenticate the target client devices from their access point, forcing them to roam to your evil twin:
ifconfig wlan1 down
iwconfig wlan1 mode monitor
ifconfig wlan1 up
iwconfig wlan1 channel 1
aireplay-ng -0 0 -a de:ad:be:ef:13:37
The entire attack process should look similar to what you see in the following GIF:
Note that coercive rogue access point can often be non-deterministic. Real-world wireless deployments usually have more than a single access point, and these access points are often more powerful and have better line-of-site range due to their placement towards the ceiling. Deauthenticating a single access point usually results in the target roaming towards another valid access point rather than your rogue AP, unless all nearby access points are deauthenticated (loud) or you are very careful with the placement of the rogue AP (difficult).
The second network selection algorithm used in 802.11 is known as Active Probing. Client devices that use active probing continuously transmit probe request frames to determine what APs are within range, as well as what their capabilities are. Probe requests come in two forms: directed and broadcast. Directed probe requests are addressed to a specific ESSID, and are the client’s way of checking if a specific network is nearby .
Clients that use directed probing will send out probe requests for each network in its PNL. It should be noted that directed probing is the only way of identify the presence of nearby hidden networks. Broadcast probe requests work almost exactly the same way, but are sent with the SSID field set to NULL. This addresses the broadcast probe to all nearby access points, allowing the the station to check if any of its preferred networks are nearby without revealing the contents of its PNL .
When an access point receives a probe request frame, it first checks the frame’s SSID field. If the frame is a broadcast probe or the frame’s SSID field matches the ESSID of the access point, the AP will respond by sending a probe response frame back to the client. Probe response frames contain similar information to what can be found in beacon frames, including supported data rates, capabilities, and the access point’s ESSID (directed probe requests only) .
When a client receives a probe response for a network within their PNL, it sends an authentication request to the access point that sent it (even with open networks, no authentication is still treated as a form of authentication). Assuming that authentication succeeds (and with open networks it pretty much always should), the client will then send an association request to the client to initiate the connection .
Karma Attacks: Making (and Breaking) Assumptions About Active Network Discovery
Assuming that access points treat the 802.11 standard as law, access points should only ever respond to broadcast probe requests, or probe requests directed towards their ESSID.
However, as Dino Dai Zovi and Shane Macaulay realized back in 2005, something interesting occurs when you modify an access point to respond to *all* probe requests it receives. By doing this, you can effectively trick client devices into connecting to a rogue AP without prior knowledge of the client’s PNL .
This is known as a Karma attack, and it’s strikingly simple: the access point just listens for directed probe requests, and sends back directed probe responses with the same ESSID. The client then receives the ESSID, thinks it’s near a network from its PNL, and connects to the rogue AP .
Executing Karma Attacks With EAPHammer
EAPHammer doesn’t support classic karma attacks anymore, so if you want to experiment these you’ll have to downgrade to an older version. Instead, EAPHammer supports MANA attacks, which are covered in Part II.
This concludes Part I of this writeup. In Part II, we’ll talk about how improvements in modern wireless device security have greatly reduced the effectiveness of the original Karma attack. We’ll then dive into two techniques for circumventing these mitigations, and describe how they’ve been implemented in EAPHammer.