Siren Mode: Evil Twin Attacks and WPA Handshake Capture at Scale

Evil twin attacks are one of the most effective ways to harvest credentials on a physical engagement. The concept is simple: stand up a rogue access point that impersonates a legitimate network, wait for clients to connect, and intercept everything they send. In practice, pulling this off reliably requires a stack of moving parts -- hostapd, dnsmasq, iptables, captive portal pages, handshake capture tools -- and a lot of manual configuration. Siren mode on the Phantom collapses all of that into a single toggle with a WiFi 6 radio purpose-built for the job.

What Is an Evil Twin Access Point?

An evil twin is a rogue access point that broadcasts the same SSID as a legitimate network. When a client device sees two access points with the same name, it typically connects to whichever has the stronger signal -- and if you're in the same building as the target, that's usually you. The client has no way to distinguish your AP from the real one at the SSID level. Even WPA2 networks are vulnerable: if your evil twin is open (no password), many clients will connect without complaint because they treat the SSID as the primary identifier, not the security configuration.

The more sophisticated version clones not just the SSID but the BSSID (MAC address) of the legitimate AP. This makes the attack invisible to basic wireless IDS that only compares SSIDs. Some enterprise WIDS solutions detect duplicate BSSIDs on different channels, but most organizations don't have that kind of monitoring deployed.

Hostapd Under the Hood

Every evil twin attack starts with hostapd, the standard Linux user-space daemon for turning a wireless NIC into an access point. When Siren mode activates, the Phantom configures hostapd with the target SSID, channel, and security parameters -- all derived from the scan data collected during Scope mode or from the operator's configuration in the dashboard.

The configuration includes the interface, driver (nl80211 for modern radios), SSID, channel, hardware mode (a/g/n/ac/ax depending on the target), and optionally the BSSID to clone. For open networks, that's enough. For WPA2 targets where you want to deploy a captive portal, Siren stands up an open AP with the same SSID -- the goal is to get the client to connect and present them with a credential harvesting page, not to actually run WPA2 on the rogue AP.

Behind hostapd, dnsmasq handles DHCP and DNS. Every DNS query resolves to the Phantom's IP, which forces all HTTP traffic to the captive portal. iptables rules redirect ports 80 and 443 to the local portal service. The entire stack comes up in under three seconds from toggle.

How Does Captive Portal Credential Capture Work?

The captive portal is where credentials actually get harvested. Siren mode ships with portal templates that mimic common enterprise WiFi login pages -- the kind you see when connecting to a corporate guest network or a WPA2-Enterprise network that requires username and password authentication.

When a client connects to the evil twin, their device detects the captive portal (via the standard connectivity check to connectivitycheck.gstatic.com, captive.apple.com, or similar endpoints) and presents the login page automatically. The user sees what looks like their corporate WiFi login, enters their domain credentials, and those credentials are captured, encrypted, and exfiltrated to the operator via the relay.

Custom portal templates can be uploaded through the dashboard. If you've done recon on the target's actual captive portal (screenshot it during the site survey), you can clone it and deploy an exact replica. The more authentic the portal looks, the higher the capture rate. In practice, generic enterprise templates work well enough -- most users don't scrutinize WiFi login pages.

WPA/WPA2 4-Way Handshake Capture

Captive portals capture plaintext credentials, but many engagements also require cracking the actual WiFi PSK. This is where handshake capture comes in. The WPA/WPA2 4-way handshake occurs every time a client authenticates to an access point. The handshake itself doesn't contain the password, but it contains enough information (the ANonce, SNonce, MIC, and the EAPOL frames) to verify a password guess offline.

Siren mode captures these handshakes passively by monitoring the target channel while clients connect, or actively by triggering deauthentication attacks (covered below) to force clients to reconnect. Each captured handshake is stored and can be exfiltrated for offline cracking.

Offline cracking with hashcat is where the handshakes become useful. A captured EAPOL handshake (hashcat mode 22000) can be attacked with dictionary files, rules-based mutations (the best-64, dive, or custom rulesets that append numbers, swap cases, and apply common password patterns), or brute force. On modern GPUs, WPA2-PBKDF2 runs at roughly 500-800K hashes per second on a single RTX 4090 -- slow compared to NTLM, but feasible for targeted dictionaries and common patterns. An 8-character lowercase password falls in hours; a dictionary word with common mutations falls in minutes.

PMKID Capture: The Clientless Alternative

PMKID capture is the quieter cousin of handshake capture. Discovered in 2018, the PMKID is derived from the PMK (Pairwise Master Key), the AP's MAC address, and the client's MAC address. The critical insight is that the AP includes the PMKID in the first message of the 4-way handshake (the EAPOL-1 frame), which means you can capture it by sending a single association request to the AP. No client needs to be connected. No deauthentication is required.

This matters for stealth. Deauthentication attacks are noisy -- they disconnect users, trigger complaints, and can be detected by WIDS. PMKID capture looks like a normal client attempting to connect to the AP. The AP sends back the EAPOL-1 containing the PMKID, you capture it, and you disconnect. One packet in, one packet out. The PMKID is then crackable offline with hashcat (mode 22000, same as EAPOL) using the same dictionaries and rules.

Siren mode attempts PMKID capture automatically against all detected APs before falling back to deauthentication-based handshake capture. This gives the operator the quietest possible approach first, escalating only if the AP doesn't include PMKIDs in its EAPOL-1 frames (not all do -- it depends on the AP's implementation and whether it supports roaming optimizations like OKC or 802.11r).

Deauthentication Attacks

When passive capture and PMKID fail, deauthentication is the fallback. 802.11 deauthentication frames are management frames, and in networks without 802.11w (Protected Management Frames), they are unauthenticated. Any device can send a deauthentication frame spoofing the AP's BSSID, and the client will disconnect.

Siren mode sends targeted deauthentication frames to specific clients rather than broadcasting to all clients on the network. Targeted deauths are less disruptive and harder to detect -- disconnecting one or two devices at a time looks like normal WiFi instability rather than an attack. The disconnected client immediately attempts to reconnect, generating a fresh 4-way handshake that Siren captures.

On networks with 802.11w enabled, deauthentication frames are protected by a MIC derived from the IGTK (Integrity Group Temporal Key). Spoofed deauth frames will be rejected. In this case, Siren falls back to PMKID capture or channel-based denial of service (transmitting on the same channel to cause interference, which is less reliable but still forces some clients to roam or reconnect).

Why Use Siren Mode Instead of a Laptop?

Running an evil twin attack from a laptop requires configuring at minimum five separate tools: hostapd for the access point, dnsmasq for DHCP/DNS, iptables for traffic redirection, a web server for the captive portal, and a capture tool (airodump-ng or hcxdumptool) for handshakes. Each tool needs its own configuration file. The wireless interface needs to be put into the right mode (monitor for capture, managed for the AP -- often requiring two separate NICs). And all of this needs to be torn down cleanly on exit to avoid leaving a rogue AP running.

Siren mode abstracts this entire stack. The operator selects Siren in the dashboard, picks a target SSID (or lets it auto-select based on Scout or Scope data), optionally uploads a custom portal template, and toggles it on. The Phantom handles interface management, hostapd configuration, DHCP/DNS, portal deployment, handshake capture, PMKID extraction, and deauthentication scheduling internally. Captured credentials and handshakes are encrypted and exfiltrated to the relay in real time.

More importantly, the Phantom does this unattended. A laptop-based evil twin requires you to be nearby, monitoring the attack, restarting tools when they crash, and managing the interface. The Phantom runs Siren mode for hours or days, recovering from errors automatically, and reporting results to the dashboard.

Why Does the WiFi 6 Radio Matter?

The Phantom's WiFi 6 (802.11ax) radio matters for evil twin attacks for several reasons. First, it supports both 2.4 GHz and 5 GHz bands, which means it can clone networks on either band. Many modern enterprise networks run primarily on 5 GHz -- if your attack radio only supports 2.4 GHz, you can only target clients on the 2.4 GHz band.

Second, WiFi 6 supports wider channel widths (up to 160 MHz on 5 GHz) and higher data rates. A rogue AP that offers better performance than the legitimate AP is more likely to attract client connections, especially when the legitimate AP is congested.

Third, the radio supports simultaneous monitor mode and AP mode through virtual interfaces. This means Siren can run the evil twin AP on one virtual interface while capturing handshakes on another -- no second NIC required. On a laptop, this often requires two separate USB WiFi adapters, each with its own driver quirks and capabilities.

The combination of purpose-built hardware, automated configuration, and unattended operation makes Siren mode significantly more practical than the equivalent laptop-based attack. The attack surface is the same -- evil twins exploit fundamental weaknesses in how 802.11 clients select access points -- but the execution overhead drops from hours of setup to seconds.