Wireless Penetration Testing: What Wi-Fi Surveys and Rogue AP Scans Miss

Introduction

Your firewall stops at the edge of your network. Your Wi-Fi does not stop at the edge of your building. It carries into the car park, the coffee shop downstairs and the office across the street. Anyone in range can see your network names, and with the right credentials, connect.

That is not a theoretical concern. In April 2018, Dutch military intelligence disrupted four officers from Russia's GRU in the car park of the Marriott Hotel next to the Organisation for the Prohibition of Chemical Weapons in The Hague. According to the Dutch briefing, the boot of their hire car held equipment intended to hack into the OPCW's Wi-Fi, identify users and intercept their log-in data, with the antenna pointed at the building and hidden under a jacket.

Six years later, Volexity described something more unsettling. The same threat group, tracked publicly as APT28, breached a target organisation through its enterprise Wi-Fi without ever being nearby. They compromised organisations in neighbouring buildings, found laptops with both wired and wireless connections, and used those machines' Wi-Fi adapters to log on to the target's network with password-sprayed credentials. Volexity called it the "Nearest Neighbor Attack".

In our work we keep seeing the same pattern. Internet-facing services get MFA, monitoring and an annual penetration test. Wi-Fi gets a coverage survey and a quarterly rogue access point scan. This article explains why those checks miss the attacks that matter, what a wireless penetration test actually examines, and how to commission one that produces evidence rather than a heat map.

Wi-Fi Is a Remote Access Service. Most Organisations Don't Treat It as One.

The Volexity case is worth reading in full because of one detail. The target organisation had done the work on its internet-facing services. They required MFA, so the stolen passwords were useless there. The enterprise Wi-Fi did not. It accepted a valid domain username and password and nothing else.

Volexity's conclusion was direct: it may be time to treat access to corporate Wi-Fi networks with the same care as VPNs and other remote access services.

That is the shift in thinking a wireless test is designed to support. If your Wi-Fi grants access to the internal network, it is a remote access service with an unusually wide attack surface. It is reachable by anyone within radio range, and as the Nearest Neighbor case showed, by anyone who controls a machine within radio range.

The same investigation found a second weakness. After the main intrusion was cleaned up, the attacker returned through the guest Wi-Fi. That network was believed to be isolated from the corporate network. One system was reachable from both. That was enough.

MITRE ATT&CK now catalogues this as its own initial access technique, Wi-Fi Networks (T1669), with mitigations that include MFA for wireless authentication and separating wireless from wired networks that reach sensitive resources.

What Surveys and Compliance Scans Are Good At, and Where They Stop

We are not arguing that your existing wireless checks are useless. They have a clear job.

A site survey tells you where coverage is strong and where it is weak. A wireless intrusion detection system can alert on unexpected access points. For organisations handling card data, PCI DSS v4.0.1 Requirement 11.2.1 requires testing for authorised and unauthorised wireless access points at least once every three months, even where wireless is not used in the cardholder data environment.

Those are sensible controls. They are not an adversarial test.

They count access points, not attack paths

A rogue AP scan answers one question: is there a device broadcasting that we did not approve? It does not ask what an attacker could reach from the network you did approve, or from the guest network you assumed was isolated.

They don't test authentication the way an attacker would

Many enterprise networks still authenticate with a username and password over a protocol such as PEAP. If client devices are not configured to validate the server's certificate properly, an attacker can stand up a convincing look-alike network and collect credentials from devices that connect to it automatically. A coverage survey will never notice. A wireless penetration test checks it directly.

They assume the protocol is the protection

WPA3 is a genuine improvement, but it is not a guarantee. In 2019, researchers Mathy Vanhoef and Eyal Ronen published the Dragonblood findings, which included a downgrade attack against WPA3's transition mode. In that mode a network accepts both WPA3 and WPA2 with the same password, and an attacker can lure clients onto a rogue WPA2-only network and capture enough of the handshake to attempt password cracking. In 2021, Vanhoef's FragAttacks research showed design flaws in Wi-Fi's frame aggregation and fragmentation that affect every protected Wi-Fi network from WEP to WPA3, alongside widespread implementation flaws. The FragAttacks site is candid that the design flaws are hard to abuse, and that the bigger practical concern is the programming mistakes in Wi-Fi products. That is exactly why configuration and firmware need testing, not assuming.

They stop at the network boundary

The most important question is not whether someone can connect. It is what happens next. Can a device on the guest network reach a printer, a management interface or a file server? Does the corporate Wi-Fi land users on the same flat network as your domain controllers? Would anyone notice if a new device authenticated from the far end of the building at 7pm on a Sunday?

What a Wireless Penetration Test Actually Examines

A good wireless assessment starts outside and works inwards, testing the network the way an attacker would approach it.

Reconnaissance and exposure

• Which network names (SSIDs) are visible, from where, and how far beyond the building line they reach.
• Hidden networks, legacy networks and forgotten test SSIDs that are still broadcasting.
• Unauthorised access points, including consumer devices plugged in by staff, and devices that bridge wired and wireless connections.

Authentication and encryption

• Pre-shared key networks: password strength, how widely the key has been shared, and whether it has been rotated since staff left.
• Enterprise (802.1X) networks: whether clients validate the authentication server's certificate, and whether credentials can be captured through an evil twin access point.
• Whether Wi-Fi authentication relies on a domain password alone, or requires certificates or a second factor.
• WPA3 transition mode and other configurations that allow downgrade.

Client behaviour

• Whether laptops and phones automatically join networks with familiar names.
• Whether corporate devices will connect to spoofed networks outside the office, where an attacker can work with less chance of being seen.

Segmentation and post-connection access

• What a guest user can reach, tested from the guest network rather than assumed from a diagram.
• What a corporate wireless user can reach compared with a wired user, and whether that is intentional.
• Whether wireless management interfaces and controllers are exposed to the networks they manage.

Detection and response

• Whether your wireless controller, RADIUS logs and monitoring raise an alert when testing activity occurs.
• Whether the logs would let your team, or an incident responder, reconstruct what happened. In the Volexity case, the wireless controller's logs provided the first major break in the investigation.

This work naturally sits alongside internal network testing, where it shows how far a wireless foothold extends, and physical testing, where the same proximity that lets a tester read your Wi-Fi also lets them test your doors.

What It Means for the Business

The business case is straightforward. A Wi-Fi network that leads to internal systems widens your attack surface to anyone in radio range. If those systems hold personal data, a compromise raises UK GDPR obligations. If they hold card data, PCI DSS applies. If an attacker reaches your domain, the conversation moves quickly from "a Wi-Fi issue" to downtime, regulatory reporting and customer notification.

Equally important is the evidence. A quarterly rogue AP report demonstrates a control operated. It does not demonstrate that the control works against a determined attacker. Boards, auditors and cyber insurers increasingly want the second kind of evidence.

How to Commission a Wireless Test That Produces Evidence

Scoping questions to answer first

• Which sites are in scope? Head office is the obvious one. Branch offices, warehouses and retail sites are often where unmanaged access points and weaker configurations turn up.
• Which networks are in scope: corporate, guest, IoT, operational technology, and any network provided by a landlord or shared building?
• Is the goal to test the wireless configuration alone, or to follow any access gained into the internal network?
• Should client devices be tested off-site, for example how laptops behave on public or spoofed networks?

Rules of engagement

• Confirm which networks belong to you. Wireless testing near shared buildings needs care so that neighbouring organisations' networks are not touched.
• Agree testing windows, contact details and how the team should behave if challenged by staff or security on site.
• Decide in advance whether denial-of-service techniques, such as disconnecting clients to capture handshakes, are permitted, and when.

Retesting

Fixes to wireless configuration often look simple and fail in practice: a certificate validation setting pushed to most devices but not all, or a segmentation rule with one exception. Retest within 90 days to confirm the fix works and to give your board evidence that it does.

Practical Insights

1. Treat Wi-Fi as remote access. If it grants internal access, apply the same standard you apply to VPNs, including strong authentication and monitoring.
2. Don't rely on passwords alone for enterprise Wi-Fi. Volexity's case turned on a network that accepted a domain password without MFA or certificates.
3. Test guest isolation, don't assume it. One reachable system was enough for the attacker to return through a guest network believed to be isolated.
4. Check certificate validation on every client. Misconfigured clients will hand credentials to a look-alike network.
5. Review WPA3 transition mode. Backwards compatibility can reopen weaknesses that WPA3 was meant to close.
6. Keep firmware current. FragAttacks showed that implementation flaws in Wi-Fi products are a bigger practical risk than the protocol flaws.
7. Make sure your logs would tell the story. Wireless controller and RADIUS logs are often the only record of who connected, when and from where.
8. Retest within 90 days. Wireless fixes are easy to apply partially.

Conclusion

Wi-Fi is easy to overlook because it works. Staff connect, visitors connect, and the coverage map is green. None of that tells you what an attacker in the car park, or in the building across the road, could reach.

The GRU team in The Hague and the Nearest Neighbor attack were state operations. The weaknesses they relied on were not exotic: credentials without a second factor, networks that reached further than intended, and segmentation that existed on paper.

A wireless penetration test answers the question surveys and compliance scans leave open. Not "is our Wi-Fi working?" but "what happens when someone hostile connects to it?"

Don't wait for a real adversary to find the pathway. Contact our team today to discuss a tailored manual assessment for your organisation.

Sources

• Dutch Ministry of Defence (DISS/MIVD) press briefing on the GRU close-access operation against the OPCW, 4 October 2018: https://www.justice.gov/archives/opa/page/file/1098576/dl
• GOV.UK, Minister for Europe statement on the attempted hacking of the OPCW by Russian military intelligence: https://www.gov.uk/government/speeches/minister-for-europe-statement-attempted-hacking-of-the-opcw-by-russian-military-intelligence
• Volexity, "The Nearest Neighbor Attack: How A Russian APT Weaponized Nearby Wi-Fi Networks for Covert Access", 22 November 2024: https://www.volexity.com/blog/2024/11/22/the-nearest-neighbor-attack-how-a-russian-apt-weaponized-nearby-wi-fi-networks-for-covert-access/
• MITRE ATT&CK, Wi-Fi Networks, Technique T1669: https://attack.mitre.org/techniques/T1669/
• PCI DSS v4.0.1, Requirement 11.2.1 (PCI Security Standards Council)
• Mathy Vanhoef and Eyal Ronen, "Dragonblood: Analysing WPA3's Dragonfly Handshake": https://wpa3.mathyvanhoef.com/
• Mathy Vanhoef, "FragAttacks: Security flaws in all Wi-Fi devices", 11 May 2021: https://www.fragattacks.com/