An adversary who can associate with your Wi-Fi is on your network without ever touching your perimeter firewall, your VPN or your MFA-protected portals. MITRE ATT&CK T1669 Wi-Fi Networks is an Initial Access (TA0001) technique on Windows, Linux, macOS and Network Devices: adversaries connect to open Wi-Fi used by target devices, or to an organisation's secured Wi-Fi using valid credentials. Proximity used to be the limiting factor, but APT28's Nearest Neighbor campaign showed that a compromised dual-homed laptop in the building across the street is close enough. This guide covers the technique as ATT&CK v20 defines it, the documented cases, the detection analytics and data sources ATT&CK lists, the mitigations, and how to test your exposure. It is for SOC analysts, detection engineers, network and wireless teams. For assessing wireless security as a tester, see the Wireless Penetration Testing Guide; this page stays on the defender's technique view.
Key takeaways
- Wi-Fi is a remote access path. If a domain username and password are enough to join corporate Wi-Fi, the Wi-Fi is a VPN without MFA, and should be governed like one.
- Proximity is no longer a defence. In the Nearest Neighbor campaign (C0051), APT28 reached a target's enterprise Wi-Fi from overseas through compromised systems in neighbouring organisations.
- Credentials sprayed elsewhere get reused here. The same campaign validated passwords against an Internet-facing service where MFA blocked their use, then used them on Wi-Fi where it did not.
- ATT&CK lists three mitigations. M1032 Multi-factor Authentication, M1030 Network Segmentation and M1041 Encrypt Sensitive Information, with certificate-based 802.1X as the practical form of strong Wi-Fi authentication.
- Detection spans two log worlds. Endpoint WLAN events (Windows WLAN-AutoConfig 8001 to 8003, wpa_supplicant, macOS unified log) and the wireless controller, WIDS/WIPS and RADIUS logs only the network team usually reads.
What T1669 covers
ATT&CK v20 describes two routes. The first is exploiting open Wi-Fi networks used by target devices, such as hotel and conference networks, where the adversary shares a network segment with the victim's laptop. The second is accessing an organisation's secured Wi-Fi, which ATT&CK notes requires T1078 Valid Accounts. Either way the adversary needs enough proximity to discover and hold a stable connection, which they get by physically positioning themselves nearby (a close access operation) or by remotely compromising a nearby third-party system that has both wired and wireless interfaces.
Once connected, ATT&CK lists the follow-on activity as T1040 Network Sniffing and T1557 Adversary-in-the-Middle for credential access or discovery, plus normal lateral movement. T1669 has no sub-techniques. A related technique, T1016.002 Wi-Fi Discovery, covers enumerating wireless networks from a host, and the adversary's neighbour foothold maps to T1584 Compromise Infrastructure.
| Route | Precondition | Victim exposure | Where you see it |
|---|---|---|---|
| Open or hotel Wi-Fi shared with a travelling user | Physical presence or a compromised device on that network | Laptop services, unencrypted traffic, credentials typed into captive portals or cleartext protocols | Endpoint logs only; the network is not yours |
| Corporate Wi-Fi with password-based 802.1X (PEAP/MSCHAPv2) or a pre-shared key | Valid domain credentials or the shared key | Whatever the wireless VLAN can reach | RADIUS/NPS, controller and DHCP logs |
| Corporate Wi-Fi reached through a neighbour's dual-homed system | Compromise of a third party within radio range, plus credentials | As above, from an attacker located anywhere | Controller logs show a new client MAC near perimeter-facing access points |
| Guest Wi-Fi with a path into the wired network | Guest access, then a pivot | Internal systems if guest isolation or firewalling fails | Firewall logs between guest and corporate zones |
How adversaries have used it
APT28 Nearest Neighbor campaign (C0051)
ATT&CK records the campaign from February 2022 to November 2024, based on Volexity's report of November 2024. Volexity tracks the actor as GruesomeLarch and assessed with high confidence that it is APT28 (G0007). The sequence Volexity describes:
- Password spraying (T1110.003) against an Internet-facing service at the target ("Organization A") validated credentials. MFA prevented their use on public services.
- Organization A's enterprise Wi-Fi did not require MFA: a valid domain username and password were enough.
- From overseas, the actor compromised nearby organisations and used privileged credentials to RDP (T1021.001) into a dual-homed system at "Organization B" across the street, then ran a custom PowerShell script to scan for and connect to Organization A's Wi-Fi. Organization B had itself been reached through Wi-Fi and a non-MFA VPN via a third organisation.
- Inside, the actor lived off the land: shadow copies to take
ntds.dit(T1003.003), registry hive saves for SAM (T1003.002),netshport proxy rules to pivot from guest Wi-Fi into the wired network (T1090.001), andcipher.exeto wipe deleted files. Volexity reports no malware was deployed in this phase.
Investigators traced the traffic to access points near street-facing windows, and packet captures with NetBIOS queries identified the neighbour. Volexity's lesson: treat corporate Wi-Fi access with the same care as VPN access. See the APT28 (Fancy Bear) Threat Actor Profile.
GRU close access operations
The US Department of Justice indictment announced on 4 October 2018 describes GRU officers travelling to where targets were when remote hacking failed, using specialised equipment to breach networks over Wi-Fi, including hotel networks, and passing access to colleagues in Russia. The cases include Wi-Fi used by anti-doping officials in Rio de Janeiro in 2016, a conference hotel's Wi-Fi in Lausanne in September 2016 used to compromise an official's laptop and credentials, and an April 2018 attempt against the OPCW in The Hague that Dutch intelligence disrupted, recovering Wi-Fi compromise equipment from a rental car. ATT&CK cites this indictment for APT28's use of open Wi-Fi access points.
The common thread: Wi-Fi was the fallback when other paths were hardened. Credentials harvested over Wi-Fi were then used remotely against cloud and email services.
Where identity fits
Wi-Fi authentication is an identity decision. Password-based 802.1X turns every domain account into a Wi-Fi credential, so a sprayed or phished password grants network access with no second factor. Shared pre-shared keys are worse: a single secret shared by people, printers and IoT devices, rarely rotated, and impossible to attribute. Machine certificates move Wi-Fi to device identity: EAP-TLS with a certificate issued to a managed device, ideally with a hardware-protected key, means a stolen user password alone does not get onto the network. Devices that cannot do certificates (printers, sensors, building systems) are non-human identities and need their own inventory, owner, isolated SSID or VLAN, and per-device credentials where the platform supports them. See the 802.1X and EAP-TLS Enterprise Wi-Fi Guide and the Network Access Control (NAC) Guide.
What to detect and where
ATT&CK v20 detection strategy DET0536 has four analytics. Their data components and log sources:
| Analytic | Platform | Data component and log source | What to look for | Tuning element |
|---|---|---|---|---|
| AN1476 | Windows | Network Connection Creation: Microsoft-Windows-WLAN-AutoConfig events 8001, 8002, 8003. User Account Authentication: Security 4776, 4625 | Unexpected SSID associations, repeated failed authentication, connections outside known geofenced networks | KnownSSIDList, GeoLocationContext |
| AN1477 | Linux | Network Connection Creation: syslog from wpa_supplicant and NetworkManager. Network Traffic Flow: auditd ioctl calls changing wireless interfaces | New SSIDs outside the baseline, repeated association failures, rogue AP connections | AllowedSSIDRegex, RetryThreshold |
| AN1478 | macOS | Network Connection Creation: unified log association and authentication events. Network Traffic Flow: osquery history of associated SSIDs | Rapid SSID switching, unapproved SSIDs, repeated authentication failures | BaselineSSIDHistory |
| AN1479 | Network Devices | Firewall Rule Modification on wireless interfaces. Network Traffic Content: WIDS association logs | Rogue access points, anomalous MAC addresses associating, firewall changes | AuthorizedAPList |
The endpoint analytics catch a managed device joining the wrong network. The Nearest Neighbor pattern is different: the attacker's client is someone else's machine, so your endpoint telemetry never sees it. That case lives in the network-side logs. NHI Mgmt Group recommends adding these correlations:
- Credential seen on Wi-Fi but not on a known device: a RADIUS/NPS accept for a user account from a client MAC never seen before, or not registered in your device inventory or MDM.
- Spray then associate: accounts that appeared in password-spray detections against Internet-facing services and later authenticated to Wi-Fi.
- Impossible presence: a Wi-Fi authentication for a user whose badge, VPN session or sign-in location says they are elsewhere.
- Edge access points: new clients associating mainly through access points on exterior walls, especially outside office hours, at low signal strength.
- Guest to corporate: any allowed flow from the guest SSID's subnet to internal ranges, and new port proxy or forwarding rules on hosts reachable from guest Wi-Fi.
- Rogue and dual-homed devices: WIDS/WIPS alerts for unknown access points and for corporate hosts bridging wired and wireless interfaces. See the Wireless intrusion detection guide.
Noise: Windows 8001 to 8003 fire on every roam and sleep cycle, so baseline per SSID and alert on unknown SSIDs or bursts of 8002 failures, not on volume. Retain controller and RADIUS logs for as long as endpoint logs; Volexity's investigation spanned weeks and the attacker returned after remediation.
Mitigations
| ATT&CK mitigation | What ATT&CK says for T1669 | Practical implementation (NHI Mgmt Group recommendation) |
|---|---|---|
| M1032 Multi-factor Authentication | Harden Wi-Fi access with two or more pieces of evidence, such as a password plus a token or smart card | EAP-TLS with device certificates issued only to managed devices, plus user authentication where the platform supports it; retire PEAP/MSCHAPv2 and shared keys on corporate SSIDs |
| M1030 Network Segmentation | Separate Wi-Fi and wired environments, particularly where the wired network reaches sensitive resources | Wireless clients land in their own zone with firewall policy to internal services; guest SSIDs routed straight to the Internet with client isolation; IoT on its own SSID and VLAN |
| M1041 Encrypt Sensitive Information | Encrypt wired and wireless traffic, use strong authentication protocols such as Kerberos, protect credential-bearing web traffic with TLS | WPA3-Enterprise or WPA2-Enterprise with protected management frames; remove cleartext protocols that sniffing (T1040) would expose; always-on VPN for travelling users on untrusted networks |
Further controls that follow from the cases:
- Configure clients to validate the RADIUS server certificate and pin the expected server name, so users cannot hand credentials to an evil twin access point.
- Disable automatic connection to open networks on managed laptops, and block simultaneous wired and wireless connections where the platform allows it, which removes your own estate as someone else's dual-homed bridge.
- Close the spray-to-Wi-Fi gap: lock out or force reset for accounts caught in password-spray detections, because MFA on the web portal does not protect the Wi-Fi.
- Review radio coverage: reduce transmit power on access points near exterior walls where coverage outside the building is not needed. This narrows exposure but does not replace authentication.
Broader hardening is in the Wi-Fi Security Guide.
Implementation sequence
- Inventory: list every SSID, its authentication method (open, PSK, PEAP, EAP-TLS), the VLAN or zone it lands in and what that zone can reach.
- Collect logs: forward controller, WIDS/WIPS, RADIUS/NPS and DHCP logs to the SIEM and enable WLAN-AutoConfig collection on Windows endpoints. Build the correlations above in alert-only mode for two to four weeks.
- Segment first: firewall the wireless zone from sensitive wired resources and break any guest-to-corporate path. This is low-risk and reduces impact immediately.
- Pilot certificate authentication: issue device certificates through MDM to a pilot group on a new SSID or as a parallel policy on the RADIUS server, with server certificate validation configured on clients. Keep the old method available to the pilot as rollback.
- Migrate by ring: IT, then general staff, then exceptions. Track failed authentications per device each day and fix enrolment gaps before moving rings.
- Retire password-based access on corporate SSIDs once failures are near zero; move non-certificate devices to an isolated SSID with per-device controls.
- Re-test as in the next section, and add the wireless path to your incident response runbooks.
Small organisations without a PKI can use a cloud RADIUS or NAC service with MDM-issued certificates, or at minimum WPA3-Personal with a unique, rotated key per segment and strict segmentation. Large estates should treat Wi-Fi authentication policy as part of the identity programme, with the same change control as VPN access.
How to test
- Credential-only join: with an authorised, unmanaged test laptop, confirm that a valid domain password alone cannot join any corporate SSID.
- Detection drill: join from the unmanaged test device using a test account and confirm the "unknown device" alert fires and reaches the SOC queue.
- Segmentation check: from guest and corporate Wi-Fi, scan only approved internal ranges and confirm sensitive systems (domain controllers, management interfaces) are unreachable from guest and limited from corporate wireless.
- Exterior survey: measure signal strength from the street, car parks and neighbouring buildings, and list which access points are visible.
- Evil twin resistance: under an authorised wireless test, confirm managed clients refuse a look-alike SSID with an untrusted server certificate.
Testing on radio networks needs written authorisation and must avoid neighbouring networks. Scope and method are in the Wireless Penetration Testing Guide.
Metrics
- Percentage of corporate SSIDs using certificate-based authentication (target 100%).
- Percentage of Wi-Fi authentications from devices present in the device inventory or MDM.
- Number of allowed flows from guest Wi-Fi to internal address ranges (target zero).
- Mean time from an unknown-device Wi-Fi authentication alert to triage.
- Number of accounts caught in password-spray detections that were reset before any further authentication.
Common failure patterns
- MFA on the portals, passwords on the Wi-Fi: the exact gap Nearest Neighbor used. Inventory every authentication path that accepts a domain password.
- Guest Wi-Fi with an internal route: APT28 pivoted from guest Wi-Fi into the wired network with port forwarding rules.
- Clients that do not validate the RADIUS certificate: PEAP clients set to trust any server will hand credentials to an impostor access point.
- Wireless logs owned by nobody: controller and RADIUS logs stay on the appliance, so the SOC cannot correlate them with spray detections or device inventory.
- Shared PSKs on corporate networks: a key known to every former employee and every contractor, never rotated.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| MITRE ATT&CK v20 | TA0001 Initial Access; T1669; related T1078, T1110.003, T1040, T1557, T1016.002, T1584 | Technique, prerequisites and follow-on activity |
| NIST SP 800-53 Rev 5 | AC-18 Wireless Access; AC-18(1) Authentication and Encryption; SI-4(14) Wireless Intrusion Detection; IA-3 Device Identification and Authentication; SC-7 Boundary Protection | Authorising, authenticating and monitoring wireless access; separating zones |
| NIST CSF 2.0 | PR.AA-03; PR.IR-01; DE.CM-01 | Authenticate users and hardware; protect networks from unauthorised access; monitor networks |
| NIST SP 800-153 | Guidelines for Securing Wireless Local Area Networks | WLAN security configuration and monitoring across the lifecycle |
Practitioner checklist
- Every corporate SSID authenticates devices with certificates, not passwords or shared keys.
- Clients validate the RADIUS server certificate and name.
- Wireless, guest and IoT networks are separate zones with firewall policy to sensitive resources.
- Controller, WIDS/WIPS, RADIUS and DHCP logs reach the SIEM with retention matching endpoint logs.
- WLAN-AutoConfig events 8001 to 8003 and their Linux and macOS equivalents are collected and baselined per SSID.
- Alerts exist for Wi-Fi authentications from devices not in inventory and for accounts caught in password spraying.
- Managed laptops do not auto-join open networks and use always-on VPN when travelling.
- Exterior signal coverage has been surveyed and reduced where not needed.
- Wi-Fi access is in the incident response runbook and the remote access policy.
Standards and references
- MITRE ATT&CK: T1669 Wi-Fi Networks
- MITRE ATT&CK: C0051 APT28 Nearest Neighbor Campaign
- Volexity: The Nearest Neighbor Attack
- US Department of Justice: U.S. Charges Russian GRU Officers with International Hacking and Related Influence and Disinformation Operations
- NIST: SP 800-153 Guidelines for Securing Wireless Local Area Networks
- NIST: SP 800-53 Rev 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: ATT&CK Initial Access Tactic, MITRE ATT&CK T1110 Brute Force Guide, T1584 Compromise Infrastructure, T1003 OS Credential Dumping and ATT&CK Mitigations.