Join our Newsletter — 33% off our NHI Course
Home› Guides› MITRE ATT&CK T1669 Wi-Fi Networks: Detecting and Blocking…
Guide SOC & Detection Engineering

MITRE ATT&CK T1669 Wi-Fi Networks: Detecting and Blocking Entry

← All guides
By NHI Mgmt Group, edited by Lalit Choda Updated 12 November 2026 14 min read
On this page

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.

RoutePreconditionVictim exposureWhere you see it
Open or hotel Wi-Fi shared with a travelling userPhysical presence or a compromised device on that networkLaptop services, unencrypted traffic, credentials typed into captive portals or cleartext protocolsEndpoint logs only; the network is not yours
Corporate Wi-Fi with password-based 802.1X (PEAP/MSCHAPv2) or a pre-shared keyValid domain credentials or the shared keyWhatever the wireless VLAN can reachRADIUS/NPS, controller and DHCP logs
Corporate Wi-Fi reached through a neighbour's dual-homed systemCompromise of a third party within radio range, plus credentialsAs above, from an attacker located anywhereController logs show a new client MAC near perimeter-facing access points
Guest Wi-Fi with a path into the wired networkGuest access, then a pivotInternal systems if guest isolation or firewalling failsFirewall 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:

  1. Password spraying (T1110.003) against an Internet-facing service at the target ("Organization A") validated credentials. MFA prevented their use on public services.
  2. Organization A's enterprise Wi-Fi did not require MFA: a valid domain username and password were enough.
  3. 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.
  4. Inside, the actor lived off the land: shadow copies to take ntds.dit (T1003.003), registry hive saves for SAM (T1003.002), netsh port proxy rules to pivot from guest Wi-Fi into the wired network (T1090.001), and cipher.exe to 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:

AnalyticPlatformData component and log sourceWhat to look forTuning element
AN1476WindowsNetwork Connection Creation: Microsoft-Windows-WLAN-AutoConfig events 8001, 8002, 8003. User Account Authentication: Security 4776, 4625Unexpected SSID associations, repeated failed authentication, connections outside known geofenced networksKnownSSIDList, GeoLocationContext
AN1477LinuxNetwork Connection Creation: syslog from wpa_supplicant and NetworkManager. Network Traffic Flow: auditd ioctl calls changing wireless interfacesNew SSIDs outside the baseline, repeated association failures, rogue AP connectionsAllowedSSIDRegex, RetryThreshold
AN1478macOSNetwork Connection Creation: unified log association and authentication events. Network Traffic Flow: osquery history of associated SSIDsRapid SSID switching, unapproved SSIDs, repeated authentication failuresBaselineSSIDHistory
AN1479Network DevicesFirewall Rule Modification on wireless interfaces. Network Traffic Content: WIDS association logsRogue access points, anomalous MAC addresses associating, firewall changesAuthorizedAPList

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 mitigationWhat ATT&CK says for T1669Practical implementation (NHI Mgmt Group recommendation)
M1032 Multi-factor AuthenticationHarden Wi-Fi access with two or more pieces of evidence, such as a password plus a token or smart cardEAP-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 SegmentationSeparate Wi-Fi and wired environments, particularly where the wired network reaches sensitive resourcesWireless 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 InformationEncrypt wired and wireless traffic, use strong authentication protocols such as Kerberos, protect credential-bearing web traffic with TLSWPA3-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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Migrate by ring: IT, then general staff, then exceptions. Track failed authentications per device each day and fix enrolment gaps before moving rings.
  6. Retire password-based access on corporate SSIDs once failures are near zero; move non-certificate devices to an isolated SSID with per-device controls.
  7. 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

FrameworkReferenceRelevance
MITRE ATT&CK v20TA0001 Initial Access; T1669; related T1078, T1110.003, T1040, T1557, T1016.002, T1584Technique, prerequisites and follow-on activity
NIST SP 800-53 Rev 5AC-18 Wireless Access; AC-18(1) Authentication and Encryption; SI-4(14) Wireless Intrusion Detection; IA-3 Device Identification and Authentication; SC-7 Boundary ProtectionAuthorising, authenticating and monitoring wireless access; separating zones
NIST CSF 2.0PR.AA-03; PR.IR-01; DE.CM-01Authenticate users and hardware; protect networks from unauthorised access; monitor networks
NIST SP 800-153Guidelines for Securing Wireless Local Area NetworksWLAN 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

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.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 12 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security. nhimg.org