Wi-Fi penetration testing

The test starts with what protects the access point. We look at whether the network runs on WPA2 or the newer WPA3, and how it verifies a connection: with a shared password (PSK) that every employee knows, or with enterprise 802.1X, that is, authentication against an account on a RADIUS server where each person has their own login. With PSK a single leaked password is enough; with 802.1X we test whether the client verifies the server certificate or connects even to something merely pretending to be the network.

The second layer is resistance to spoofing. An evil twin is a fake access point with the name of your network that a device connects to on its own, because it knows the name. We test whether the client insists on verifying the real access point, whether the connection can be dropped by deauthentication and the victim pushed onto our access point, and what the captive portal, that is, the login page of the guest network, does when we slip it our own.

The third is capturing material for offline cracking. When a client connects, the handshake can be captured, and with WPA2 the PMKID directly from the access point, and the password then cracked off the network, where no one sees us and no attempt limit slows us down. That’s why the length and randomness of the password on PSK networks is what resistance stands on.

Wireless doesn’t stop at the walls. The signal of a corporate Wi-Fi can be heard in the hallway, in the parking lot, and from the street in front of the building, so an attacker doesn’t need to pass reception or plug in a cable. Being within range is enough, which is a completely different exposure from a wired network: you have to physically reach the wire; wireless makes itself available.

So we test Wi-Fi from the position of someone outside. We check how far the signal carries, whether the guest network can be joined without any check, and whether it leads anywhere further. When the guest and corporate networks share one access point without proper separation, a connection from the parking lot is the first step inside, and what an attacker can do further in the internal network follows on from the wired network and Active Directory test.

Some scenarios play out right by the building. A dropped device posing as an access point, or a connection made in the waiting room or a meeting room, sits on the border with physical intrusion, so access from around the building and on-site scenarios are handled together or separately, as agreed.

The effort rests on three things: the number of SSIDs, that is, network names in scope, the number of sites where testing happens, and the type of security. A network with one password at one branch office is different work from 802.1X across five buildings: more sites mean more places the tester with an antenna has to reach.

The effort is 2 to 3 person-days, and in calendar time it’s within a week from the start to report delivery. You get the exact figure after the scope is defined, not as an open-ended hourly rate. The price and duration of a Wi-Fi test come from how many SSIDs and sites are in scope and the type of security tested.

First, access to the signal. Either the tester is on site or within range of the Wi-Fi, because wireless can’t be tested remotely from an office. On top of that we need a list of the SSIDs in scope, so we don’t test someone else’s network in the neighboring building, a window when we may disrupt traffic with deauthentication, and a contact for someone who knows the network.

The rules of engagement are agreed in advance, the same as with other tests: what is allowed, what is out of scope, and whom we reach out to when we run into something. Deauthentication briefly disconnects connected clients. We tune its window so it doesn’t fall in a traffic peak.

Every finding has a description, the impact, evidence, and specific remediation: whether to move from PSK to 802.1X, enforce server certificate verification, separate the guest network into its own VLAN, or lengthen and randomize the password. We order severity by the impact on your network, not by a generic score.

For findings where a path leads from wireless to the inside, we describe the whole chain of steps, so it’s clear why a connection from the parking lot is a risk and not a theoretical defect. One retest of fixed findings is included in the price.

It makes sense where wireless is in use and leads into the corporate network, that is, where Wi-Fi gets you to files, printers, internal applications, or the domain. The more work goes through wireless, the greater the impact of a single flaw in network separation.

It makes no sense for a purely guest network that’s isolated and leads nowhere further, because the test would only confirm the expected. And if your main concern is the wired network and the domain environment, Wi-Fi is just one layer and the main work lies elsewhere. In that case, start with an internal network test and add Wi-Fi to it. Many flaws can be closed on your own before a test, and a practical article covers what most often fails on corporate Wi-Fi.