T1557.004 Google Chronicle · YARA-L

Detect Evil Twin in Google Chronicle

Adversaries may host fraudulent Wi-Fi access points using the same SSID as a legitimate network to intercept traffic, steal credentials, or deliver malware. Evil Twin attacks exploit the 802.11 protocol's lack of mutual AP authentication — clients connect to whichever access point advertises the correct SSID with the strongest signal, without verifying the AP's identity. Attackers use tools such as hostapd, airbase-ng, create_ap, or Wi-Fi Pineapple devices to clone corporate or public SSIDs. Upon connection, victims are often directed to a fake captive portal for credential harvesting or subjected to man-in-the-middle attacks against unencrypted or SSL-stripped traffic. Attackers may also listen for 802.11 probe requests in which client devices broadcast previously connected network names (Preferred Network Lists), responding with matching SSIDs to automatically attract victim connections. APT28 (Fancy Bear / GRU) operationally deployed Wi-Fi Pineapple devices for Evil Twin attacks during intelligence collection operations against Organization for the Prohibition of Chemical Weapons (OPCW) and other targets, as documented in the October 2018 GRU indictment.

MITRE ATT&CK

Tactic
Credential Access Collection
Technique
T1557 Adversary-in-the-Middle
Sub-technique
T1557.004 Evil Twin
Canonical reference
https://attack.mitre.org/techniques/T1557/004/

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral
rule evil_twin_ssid_multi_bssid {
  meta:
    author = "df00tech"
    description = "Detects Evil Twin AP attack: same corporate SSID advertised by multiple distinct BSSIDs from different hosts within 24h, indicating a rogue AP cloning a legitimate network"
    mitre_attack_tactic = "Credential Access"
    mitre_attack_technique = "T1557.004"
    mitre_attack_url = "https://attack.mitre.org/techniques/T1557/004/"
    severity = "HIGH"
    priority = "HIGH"
    false_positives = "Legitimate enterprise APs sharing SSID for roaming; tune BSSID threshold to your AP infrastructure baseline"
    version = "1.0"

  events:
    $e1.metadata.event_type = "NETWORK_CONNECTION"
    $e1.metadata.vendor_name = "Microsoft"
    $e1.network.ssid != ""
    $e1.network.bssid != ""
    $e1.network.bssid != "00:00:00:00:00:00"
    re.regex($e1.network.ssid, `(?i)(corp|office|employee|secure|work|hq|internal|guest|wireless)`)
    $ssid = $e1.network.ssid
    $bssid1 = $e1.network.bssid
    $host1 = $e1.principal.hostname

    $e2.metadata.event_type = "NETWORK_CONNECTION"
    $e2.metadata.vendor_name = "Microsoft"
    $e2.network.ssid = $ssid
    $e2.network.bssid != ""
    $e2.network.bssid != "00:00:00:00:00:00"
    $e2.network.bssid != $bssid1
    $e2.principal.hostname != $host1

  match:
    $ssid over 24h

  condition:
    $e1 and $e2
}
high severity medium confidence

Google Chronicle YARA-L 2.0 rule detecting Evil Twin AP attacks by correlating two NETWORK_CONNECTION UDM events that share the same SSID value but carry different BSSIDs, originating from different endpoints within a 24-hour sliding window. The multi-host constraint ($e2.principal.hostname != $host1) focuses the signal on fleet-wide BSSID divergence — the pattern that emerges when a rogue AP is introduced into the wireless environment and different clients connect to different BSSIDs for the same network name. Single-host BSSID changes (legitimate roaming) are excluded by requiring the two events to come from distinct hostnames. Chronicle must be ingesting Windows WLAN AutoConfig events via a parser that maps SSID and BSSID fields into the UDM network.ssid and network.bssid fields; verify parser coverage using the Chronicle Data Studio UDM event inspector before deploying.

Data Sources

Google Chronicle UDM NETWORK_CONNECTION eventsWindows WLAN AutoConfig Operational log normalized via Chronicle Windows parser or Bindplane OP agentEndpoint telemetry with UDM network.ssid and network.bssid field population confirmed

Required Tables

UDM events — NETWORK_CONNECTION type with network.ssid and network.bssid populated by parser

False Positives & Tuning

  • Enterprise wireless infrastructure with many APs sharing a corporate SSID — different hosts on different floors connecting to their nearest AP each get a unique BSSID, satisfying both the SSID match and BSSID mismatch conditions; create a Chronicle reference list of authorized BSSIDs per SSID and add a NOT $e1.network.bssid in %authorized_bssids condition
  • Wireless networks using 802.11r fast BSS transition or 802.11k neighbor reports that actively steer clients between BSSIDs, causing UDM NETWORK_CONNECTION events on different hosts to show valid SSID-consistent but BSSID-variable connection patterns that are completely legitimate
  • Organizational mergers or acquisitions where two companies temporarily operate overlapping SSIDs (e.g., both have a 'corp' or 'guest' network) at shared office locations, creating a period where the same SSID resolves to BSSIDs from two entirely separate wireless infrastructure owners
Download portable Sigma rule (.yml)

Other platforms for T1557.004


Testing Methodology

Validate this detection against 4 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Evil Twin AP with hostapd and dnsmasq on Linux

    Expected signal: On victim Windows devices connecting to the rogue AP: WLAN AutoConfig Event ID 8001 in Microsoft-Windows-WLAN-AutoConfig/Operational showing successful connection to 'TargetCorporateSSID' with the attacker NIC's MAC address as BSSID. DHCP lease assignment from 192.168.50.x range (distinct from corporate DHCP). MDE DeviceNetworkInfo records new BSSID and gateway 192.168.50.1 for the SSID. DNS queries from victim directed to 192.168.50.1.

  2. Test 2Karma / Evil Twin Probe Response Attack with airbase-ng

    Expected signal: Victim devices send visible 802.11 probe requests (capture with: tcpdump -i wlan0mon -e 'wlan type mgt subtype probe-req' 2>/dev/null). airbase-ng probe responses visible in tcpdump (subtype probe-resp). Victim device connection generates WLAN AutoConfig Event 8001 with airbase-ng NIC MAC as BSSID. DeviceNetworkInfo in MDE captures at0 MAC as BSSID with SSID 'TargetCorporateSSID'. DHCP logs show 192.168.55.x lease assignment.

  3. Test 3Wi-Fi Pineapple PineAP SSID Broadcast Configuration

    Expected signal: Victim devices: WLAN AutoConfig Event 8001 with Pineapple's BSSID (Hak5 LLC OUI: 02:13:37 or similar; or randomized MAC depending on firmware version). Default gateway assignment from Pineapple's DHCP (typically 172.16.42.x or configured range). DeviceNetworkInfo captures Pineapple MAC as BSSID. Captive portal HTTP POST requests to 172.16.42.1 visible in web proxy logs. EvilPortal logs on Pineapple at /pineapple/modules/EvilPortal/logs/ contain captured credentials.

  4. Test 4Windows Mobile Hotspot Rogue AP (No Special Hardware Required)

    Expected signal: On the attacker device: Microsoft-Windows-WLAN-AutoConfig/Operational events related to hosted network state changes; System Event Log entries for the 'Microsoft Hosted Network Virtual Adapter' appearing. On victim devices that connect: WLAN AutoConfig Event 8001 with attacker device's virtual adapter MAC (Microsoft Virtual WiFi Miniport Adapter OUI) as BSSID. Default gateway 192.168.137.1 (Windows Mobile Hotspot default) appears in DeviceNetworkInfo — distinct from corporate gateway. DeviceNetworkInfo records new BSSID for the corporate-named SSID.

Unlock Pro Content

Get the full detection package for T1557.004 including response playbook, investigation guide, and atomic red team tests.

Response PlaybookInvestigation GuideHunting QueriesAtomic Red Team TestsTuning Guidance

Related Detections