Environment requirements for wireless pentest
Before you go to the facility, you need a set of three protocols: Wi-Fi (802.11), Bluetooth Low Energy (BLE) and ZigBee (802.15.4).Iron:
• Wi-Fi adapter with monitor mode and packet injection support - Alfa AWUS036ACH (2.4/5 GHz) or AWUS036ACHM. Before leaving, be sure to check the compatibility with the core: airmon-ngwill show whether the driver sees the adapter in the monitor mode
• Ubertooth One for BLE-sniffing at the link layer level (last firmware release - 2020, the project lives on the enthusiasm of the community, there are still no real alternatives in the market)
• CC2531 USB-stick with the firmware KillerBee for ZigBee interception, or HackRF One for SDR-app approach to 802.15.4
Soft (Kali Linux 2024.4+, at least 8 GB RAM, for GPU-cracking - a discrete graphics card with VRAM from 6 GB):
• Aircrack-ng suite - airodump-ng, aireplay-ng, aircrack-ng (actively supported, last release - 2024)
• hcxdumptool + hcxpcapgtool for PMKID-attacks (actively developing, GitHub: ZerBea/hccddumptool)
• hashcat 6.2.6+ for GPU-brutfors
• Kismet - passive analysis Wi-Fi/BLE/ZigBee (updated regularly)
• Bettercap 2.x - MITM, BLE-enumeration, Wi-Fi modules
• eaphammer - Evil Twin for WPA2-Enterprise (the last commit - 2023, works stable)
• KillerBee (zbstumbler, zbdump, zbreplay) - ZigBee-tulite (supported by River Loop Security, uninvalid updates, but standard tool)
GPU-creking WPA2 on a laptop in the field is a bad idea. At the facility, I only launch the grip, and I drive drothes away at the workstation with RTX 3060 and above. The difference is about an order of magnitude: RTX 3060 gives about 400 thousand hashes / s for WPA2, built-in laptop schedule - tens of thousands. Spending a watch on the spot where you can merge .pcpf and leave is irrational.
Radio reconnaissance: from awardriving to BLE scanning
The first stage of kill chain in wireless pentest - reconnaissance (Wi-Fi Discovery, T1016.002, Discovery). Task: to get a complete map of the radio broadcast of the object before the start of active attacks.
Wi-Fi scanning: airmon-ng start wlan0 to translate the adapter into the monitor mode, then airodump-ng wlan0mon. In output, we record all BSSIDs, channels, type of encryption, availability of connected clients and hidden SSID. Hidden SSID is not protection: according to Synacktiv, the client’s request contains the name of the network in the open form, it is enough to wait for the reconnection. Hide SSID - how to close your eyes and think that you can't be seen.
What to pay attention to in 2025:
• WPA3 Transition Mode - AP simultaneously responds to WPA2 and WPA3. V airodump-ngENC column will show WPA2 WPA3. Transition Mode = attacked configuration because WPA2 is subject to standard attacks
• OWE (Opportunistic Wireless Encryption) - open-network with transparent encryption without a password. Passive traffic interception (Network Sniffing, T1040) is not possible as opposed to classic open-networks, but Evil Twin is still working
• WPS - enabled is checked through wash -i wlan0mon -C. If WPS is included - a separate vector via Reaver/Pixie Dust, sometimes the fastest way inside
In parallel, I launch Kismet with Ubertooth for BLE detection. Kismet outputs MAC addresses of BLE devices, names and UUID services. For ZigBee - zbstumbler from KillerBee scans channels 11-26, showing PAN ID and address of the coordinators.
The result of the reconnaissance is the table of all wireless devices on the object: protocol, encryption, number of customers and preliminary attackability assessment. Without it, it is pointless to move on it - it's too easy to spend hours on hardened AP, skipping a BLE lock without authentication behind the wall.
Wi-Fi pentest: WPA2 attack via PMKID and offline-brutfors
The PMKID attack is the most working source of initial access via WPA2-PSK in 2025 (Password Cracking, T1110.002, Credential Access). Three reasons: you don’t need connected customers, no deauth frames, for WIPS you’re virtually invisible.
Mechanics: when the AP connection is initiated, the AP gives PMKID in the first 4-way handshake message. PMKID is calculated as HMAC-SHA1-128(PMK, "PMK Name" || MAC_AP || MAC_STA). Intercepting PMKID, let's move on to the offline PSK.
For an 8-symbolic password of the GPU level GPU level, the RTX 3060 will cope in a watch. For 12+ characters with numbers and specialties - unrealistic without a targeted dictionary, compiled from the data of the OSINT by the company (name, year of foundation, address, employee names - all in the rules of hedcat).
The popular option is the classic 4-way handshake: if PMKID is not given (depending on the AP chipset), proceed to a deauth attack. aireplay-ng -0 5 -a <BSSID> -c <CLIENT> wlan0mon - 5 deauth frames, customer reconnected, airodump-ng catching handshake.
Detectability: Deauth attack is detected by Cisco Adaptive wIPS, Aruba WIDS, Extreme AirDefense - mass deauth frames generate analt in seconds. PMKID-capture via hcxdumptool in passive mode does not create anomalies and passes by WIPS. The equipment works for WPA2-PSK in any environment - from SMB to corporate networks with shared key. It does not work for WPA2-Enterprise (another authentication model) and WPA3-only (SAE does not give PMKID in the same format).
Place in kill chain: initial access. After receiving the PSK, we connect to VLAN and go to network sniffing (T1040), ARC Cache Poisoning (T1557.002) and lateral movement.
Evil Twin Attack on WPA2-Enterprise
WPA2-Enterprise with PEAP/MSCHAPv2 is a standard configuration in corporate networks. Evil Twin (T1557.004, Credential Access / Collection) - raise a fake access point with the same SSID. Customers cling to it and give MSCHAPv2 hashes of domain-clearing.
When connecting the client, eaphammer intercepts MSCHAPv2 challenge/response. Offline-cracking - through asleap -C <challenge> -R <response> -W wordlist.txt or hashcat in 5500 mode. To force clients to reconnect, we use a deauth target AP.
The client will connect to Evil Twin under three conditions: SSID coincides, the Evil Twin signal is stronger, and the speaker does not check the RADIUS server certificate. According to the observations of Synacktiv, the correct validation of the certificate is not found in all corporate deployments - the rest swallow any self-signed certificate.
When it doesn't work: the pinning certificate in the subline block the attack completely. On Windows-domain machines with GPO, forcibly set trusted CA for 802.1X - Evil Twin is useless. On BYOD devices (phones, laptops of employees) - works in most cases. Evil Twin with deauth is the noisiest vector in the wireless pentest. WIPS detects SSID with anomalous BSSID.
Place in kill chain: credential access → initial access. The received domain records open up VPNs, wired network, mail and other corporate services.
WPA3 Hacking: Transition Mode as a Vector
WPA3 with SAE (Simultantous Authentication of Equals) is resistant to offline brutfors – and this is really a major improvement. Research Dragonblod (2019) revealed a side-channel vulnerability in SAE, but most are closed by firmware updates. There is no direct attack on the clean WPA3-only in the field for 2025.
The real vector - Transition Mode: AP simultaneously supports WPA2 and WPA3. The attacker lifts rogue AP with the same SSID, but only with WPA2 (via airbase-ng -e "TargetSSID" -Z 4 -c 6 wlan0mon, where -Z 4 includes WPA2 CCMP). Customers without WPA3 support - or with certain supplicant settings - connect via WPA2. Next is a standard PMKID or handhake attack.
WPA3-only without Transition Mode with 802.11w (Protected Management Frames) is a configuration that I never could break through. Deauth frames do not work (802.11w encrypts management frames), offline gruntbox PSK is not possible (SAE). If you see WPA3-only on the site, it’s really a work protection. For two years of such networks in my practice met three of several dozen projects.
Applicability: Transition Mode - a typical transitional configuration (modern-infrastructure with legacy clients). In clean WPA3-environment (rareness in 2025), this vector does not work.
Bluetooth hacking: MITM attack on BLE devices
BLE is a protocol that almost never enters the pentest scooter. And in vain. BLE devices are found on most of the objects surveyed: smart locks, motion sensors, badges, thermostats. In terms of MITRE ATT&CK, Bluetooth is described as an exfilter (Exfiltration Over Bluetooth, T1011.001), but in practice more often works as initial access into the IoT segment or as Hardware Additions (T1200) - a BLE device for fixing.
BLE-environment intelligence: Bettercap module ble.recon on scans the devices within a radius of 10 m, removes MAC, name, GATT services and characteristics. Ubertooth One intercepts raw BLE-packages on link layer - needed to analyze pairing and search for devices with Legacy Pairing (BLE 4.0/4.1 without Secure Connections).
Typical Script - BLE-Class:
1. Detection through ble.recon on- fix MAC and device name
2. Listing GATT profile through ble.enum <MAC>- looking for characteristics with the rights of Write or Write Without Response
3. Analysis: if the management characteristic (lock/unlock) is available without authentication - we record the command directly
4. The unlock command often turns out to be a single-byte record in a specific characteristic - without encryption, without PIN, without bonding. Just write a byte - and the castle opens
Such devices with zero authentication on the GATT recording I met on industrial facilities and in retail many times. Manufacturers save on safety, counting on the “physical isolation” of BLE-range. Ten meters is, of course, a serious barrier (no).
When it does not work: BLE 5.x with LE Secure Connections (ECDH-based pairing) seriously complicates interception and MITM. The BTLEJack attack (compulsory fallback on Legacy Pairing) is only triggered if the device supports downgrade. Industrial new generation BLE devices are increasingly demanding bonding with PIN - then the attack goes into the category of side-channel and requires specialized equipment.
