Deauth Flood and Evil Twin on a Trading Floor
A financial services firm with 500 access points and 3,000 wireless clients runs a 24x7 security operations center (SOC). The WIPS raises a critical alert: 1,200 deauthentication frames per minute are originating from a single AP in the trading floor, affecting 50 clients. At the same time, the SOC sees an evil-twin SSID named 'CorpWiFi-Free' with an open security policy and a BSSID not in the authorized inventory. The trading floor uses latency-sensitive market-data applications; any containment action can disrupt trading. The SOC has a runbook but the on-call analyst is unsure whether this is a misconfigured AP, a client test, or an active attack. The firm is regulated by PCI DSS and SOX. The CISO wants a recommendation within 15 minutes.
1. Outline a 15-minute triage plan to determine whether the deauth flood and evil twin are related and whether they are malicious.
Read the worked answer
The triage must answer three questions quickly: where are the frames coming from, is the source authorized, and are the two alerts correlated?
Minutes 0–3: Preserve and scope. Pull the WIPS alert details: source BSSID, destination, frame type, reason code, channel, signal strength, and first/last seen. Confirm whether the deauth source is the same BSSID as the evil twin or a different authorized AP. Check the authorized AP inventory by BSSID and switch MAC. If the deauth source is an authorized AP, the issue may be a misconfiguration or a compromised AP; if it is unknown, treat it as malicious until proven otherwise.
Minutes 3–6: Check the wired side. Query the switch CAM table for the AP’s MAC and the rogue BSSID’s OUI. If the rogue is on a switch port, identify the port and owner. If the deauth source is an authorized AP, review its recent configuration changes, firmware, and controller logs. A sudden 1,200 frames/minute rate is not normal client behavior; look for a loop, a misconfigured WIPS containment policy, or an attack tool.
Minutes 6–10: Correlate client impact. Ask the trading-floor service desk which clients are affected and whether they see the “CorpWiFi-Free” SSID. Check whether affected clients are roaming to the evil twin. If the evil twin is open and clients are configured to auto-connect to open SSIDs, the deauth flood may be forcing them off the corporate SSID and onto the rogue.
Minutes 10–15: Decide containment. If the evil twin is unknown and open, contain it over the air with the WIPS. If the deauth source is an authorized AP and the traffic is malicious, isolate that AP’s switch port only if trading can tolerate the loss; otherwise contain the specific offending client or rate-limit the frames. Do not shut down the entire trading-floor WLAN without incident commander approval.
2. Recommend immediate containment actions that minimize disruption to trading-floor market-data applications.
Read the worked answer
Containment should be surgical because the trading floor cannot tolerate a broad WLAN outage.
Contain the evil twin, not the authorized infrastructure. Use the WIPS to deauthenticate clients from the unknown open BSSID and, if the rogue is on the wired network, shut the switch port after confirming the port owner. This removes the lure without touching the production APs. Preserve the rogue’s beacon and probe captures for evidence.
Handle the deauth source based on ownership. If the source is an unauthorized BSSID, contain it over the air. If it is an authorized AP but the frame rate is anomalous, check whether the AP is compromised or whether a WIPS containment policy is misfiring. Do not auto-contain an authorized AP; instead, temporarily disable the offending radio or move affected clients to another AP if coverage allows. If the AP must be isolated, coordinate with the trading-floor manager and move latency-sensitive clients to a pre-tested alternate AP.
Protect market-data clients. Identify the 50 affected clients and confirm whether they are on the corporate SSID or the evil twin. If they are on the evil twin, force them back to the corporate SSID and clear the offending SSID from their preferred network list through MDM if possible. Enable PMF on the corporate SSID where clients support it, because 802.11w protects against forged deauth frames.
Preserve evidence and communicate. Do not reboot the AP or clear logs until the captures are exported. Notify the CISO and trading-floor operations with a short status: what is contained, what is still at risk, and what trade-offs were made. PCI DSS and SOX require an audit trail, so record the time of each action and the person who approved it.
3. Propose post-incident controls to reduce the chance of forged deauth and evil-twin success.
Read the worked answer
The incident shows two gaps: management frames are not protected, and clients are willing to associate to an open SSID with a similar name.
Management-frame protection: Enable PMF (802.11w) as required on WPA3 SSIDs and as capable on WPA2 SSIDs where clients support it. PMF prevents forged deauthentication and disassociation frames, which directly addresses the 1,200 frames/minute symptom. Test legacy clients before enforcing PMF; for clients that cannot support it, isolate them on a separate SSID with monitoring rather than leaving the entire corporate SSID unprotected.
Evil-twin resistance: Use WPA3-Enterprise or EAP-TLS with server certificate validation on all corporate SSIDs. Clients should not auto-connect to open or dissimilar SSIDs. Push a preferred-network list through MDM that removes “CorpWiFi-Free” and disables auto-join to open networks. Train users to report unexpected captive portals.
WIPS policy: Tune auto-containment to act on unknown BSSIDs using the corporate SSID, but never auto-contain authorized BSSIDs. Add a correlation rule for a deauth flood plus a new BSSID with the same SSID. Require analyst approval for containment that affects more than 25 clients.
Wired-side controls: Enable 802.1X on switch ports used by APs, disable unused ports, and alert on new MAC addresses with wireless OUs. This stops a rogue AP from being plugged into the corporate LAN.
Incident response: Update the runbook with the 15-minute triage steps, a trading-floor contact, and evidence-preservation requirements. Run a tabletop exercise with the SOC and trading-floor operations so the next containment decision is faster and pre-approved.