Evil Twin Attacks: A Technical Deep Dive

If you've spent any time in wireless penetration testing, you know that attacking WPA2 directly can be a slow, frustrating process, especially against strong passwords. That's where the Evil Twin attack comes into play. Instead of directly breaking the cryptography of a protected wireless network, an Evil Twin attack attempts to impersonate a trusted wireless network and exploit weaknesses in client network-selection behavior, authentication configuration, or user trust.

An Evil Twin attack is fundamentally a rogue Access Point (AP) attack, but with a specific twist: the rogue AP is configured to perfectly mimic a legitimate AP that the target client already trusts. This typically involves replicating the SSID and, depending on the assessment, matching relevant security and network characteristics of the legitimate AP. Cloning the BSSID is not inherently required for an Evil Twin attack.

How Evil Twin Attacks Actually Work Under the Hood

To understand the Evil Twin, you have to understand 802.11 management frames. When a client device is looking for networks, clients may use Probe Requests during network discovery. Depending on the device and operating-system behavior, these can be directed toward specific SSIDs or used as wildcard discovery requests. Legitimate APs respond with Probe Responses. Once the client decides to connect, it goes through an Authentication and Association process.

In an Evil Twin scenario, the attacker sets up a rogue AP. But just setting it up isn't enough; if the legitimate AP is still nearby, the client might stay connected to the real one. To fix this, attackers use Deauthentication frames.

The Role of Deauthentication (Deauth) Attacks

In traditional 802.11 deployments without Protected Management Frames (PMF), deauthentication and disassociation frames were not cryptographically protected against forgery. IEEE 802.11w introduced Protected Management Frames, which provide cryptographic protection for relevant management frames and make spoofed deauthentication and disassociation attacks substantially harder when PMF is properly enforced.

aireplay-ng --deauth 100 -a [Target_BSSID] -c [Client_MAC] wlan0mon

When the client gets kicked off, it immediately scans for the network to reconnect. Radio conditions, antenna characteristics, AP placement, client behavior, and transmit power can all influence whether a client encounters or prefers a rogue AP. High transmit power alone does not guarantee association.

Setting up the Infrastructure (hostapd & dnsmasq)

Most automated tools (like Wifiphisher, Fluxion, or our own Wifi Cracker 2.0) automate this, but understanding the manual setup is crucial for troubleshooting.

First, you need hostapd to create the AP. Your configuration file (hostapd.conf) needs to mimic the target:

interface=wlan0
ssid=Corporate_Guest_WiFi
hw_mode=g
channel=6
bssid=00:11:22:33:44:55

Once the AP is up, you need a DHCP server to hand out IP addresses to victims, and a DNS server to resolve their queries. dnsmasq handles both beautifully.

interface=wlan0
dhcp-range=192.168.1.10,192.168.1.100,12h
dhcp-option=3,192.168.1.1
dhcp-option=6,192.168.1.1
address=/#/192.168.1.1

Notice that last line: address=/#/192.168.1.1. This creates a wildcard DNS response, causing matching DNS queries to resolve to the specified local address. In a controlled captive-portal environment, this can be used to redirect traffic toward the portal.

The Captive Portal Attack (Phishing for Credentials)

When a modern OS connects to a Wi-Fi network, it automatically checks if it has internet access by reaching out to a specific URL (e.g., captive.apple.com for iOS/macOS, or connectivitycheck.gstatic.com for Android).

Because our dnsmasq configuration resolves all queries to our IP, the operating system may detect that the network requires captive-portal authentication and present the user with a sign-in interface. The exact detection and user-interface behavior varies between operating systems and versions.

Modern HTTPS significantly limits what a rogue DNS response can transparently redirect. A DNS response pointing a hostname to the attacker's address does not provide a valid TLS certificate for that hostname. As a result, HTTPS certificate validation can prevent transparent interception and may produce certificate errors rather than silently displaying a cloned site.

Capturing WPA2 Handshakes (The Side Channel)

While the captive portal runs, we can also perform a secondary attack. By forcing clients to disconnect via deauth packets, they will attempt to reconnect to the legitimate AP. During this reconnection, the 4-way WPA2 handshake occurs. We can capture this handshake using airodump-ng and crack it offline later using tools like hashcat.

In many pentests, combining the Evil Twin captive portal with offline handshake cracking is attempted. The captured handshake can be subjected to offline password-guessing. Whether the password can actually be recovered depends primarily on the password's strength, the quality of the candidate wordlist or attack strategy, and the wireless security configuration.

Enterprise Defenses: How to Stop Evil Twins

From a defensive perspective, how do we stop this? WPA2-PSK relies on a shared secret and does not provide the same form of per-user authentication and server authentication available in properly configured enterprise EAP deployments. This can make users more susceptible to certain impersonation and credential-phishing scenarios.

1. 802.11w Management Frame Protection (PMF): For deployments that support PMF, configuring it as required where appropriate provides stronger protection than merely supporting it as optional. It helps prevent spoofed management frames like deauthentication.
2. WPA2/WPA3 Enterprise (802.1X): Enterprise Wi-Fi commonly uses IEEE 802.1X with EAP authentication and a backend authentication service such as RADIUS. Depending on the EAP method, certificates may be used to authenticate the server and/or client. Correct client-side certificate validation and server-identity configuration are critical.
3. Wireless Intrusion Prevention Systems (WIPS): Enterprise access points constantly scan the airwaves. If they detect another AP broadcasting their SSID, or detect a flood of deauth frames, they alert administrators and can even actively suppress the rogue AP.
4. WPA3-Personal: WPA3-Personal uses SAE rather than the WPA2-PSK handshake mechanism and provides stronger resistance to offline password-guessing attacks. However, WPA3 does not make rogue-AP or social-engineering attacks impossible; users and clients can still interact with malicious networks.

Evil Twin attacks demonstrate that wireless security is not solely a matter of encryption strength. Strong authentication, properly configured certificate validation, Protected Management Frames, wireless monitoring, secure client configuration, and user awareness must work together. No single control completely eliminates rogue-access-point threats.