October 24, 2026
What a Real WiFi Hack Actually Looks Like (Spoiler: Itβs Not One Move) π‘
Youβve seen the movie scene. Hacker types fast, green text scrolls, password cracked in ten seconds flat. π¬
By Krithick
7 min read
Real life isn't that. Real life is slower, quieter, and honestly a lot more interesting β because the real work happens at the packet level, long before anyone touches a password cracker.
When you actually sit down to test a WiFi network the right way, cracking the password is the last thing you reach for. Before that, there are seven doors to knock on. Some creak open. Some don't budge. And you won't know which is which until you've read what every single one is broadcasting, bit by bit.
So grab a coffee β, because I want to walk you through what that actually feels like β the protocols, the exact fields you're staring at, the commands β from the chair of the person doing the knocking.
The Setup π οΈ
Target: a corporate WPA2-PSK network, locked down with CCMP (AES-128) encryption, running on both the 2.4 GHz and 5 GHz bands. Black-box test. No clients harassed, no sessions crashed, nothing broken that didn't need breaking.
My toolkit for the night:
Tool What it's for airmon-ng Flips the WiFi card into monitor mode β raw 802.11 frames, no association needed airodump-ng Sits quietly and catches every beacon and probe frame floating through the air aireplay-ng Tests deauthentication β can I forge the frame that kicks someone off? hcxdumptool Hunts for a PMKID, a shortcut attackers love bettercap My Swiss Army knife for active probing wash Checks for WPS, the old PIN-based side door Wireshark Where I actually read what the airwaves are saying, field by field hashcat The muscle, for whenever there's something crackable
A USB adapter in monitor mode, a laptop running Kali, and a lot of patience. That's it. No magic β just a radio and the willingness to read every byte it hears.
Door #1: Can Someone Justβ¦ Kick You Off? πͺπ¨
Here's a wild thought: what if an attacker didn't need your password at all? What if they could just forcibly disconnect your device, over and over, from across the parking lot, without ever touching the network?
That's not science fiction. That's what happens when Protected Management Frames (PMF / IEEE 802.11w) aren't enforced. Deauthentication and disassociation frames are management frames, and in plain WPA2 they ride completely unauthenticated β no MIC, no sequence check, nothing stopping anyone from forging one with the right source MAC and a reason code.
PMF fixes this with BIP (Broadcast/Multicast Integrity Protocol), which signs those frames with a separate key β the IGTK, handed out alongside the usual pairwise keys during the 4-way handshake. No IGTK, no protection, and a forged deauth sails straight through.
So the first thing I do is listen. Just listen.
airodump-ng wlan0monairodump-ng wlan0monThen I pull that capture into Wireshark and go straight for the RSN tag buried inside the beacon frame:
wlan.tag.number == 48wlan.tag.number == 48
Inside the RSN Capabilities field, two specific bits tell the whole story: bit 6 is MFPC (Management Frame Protection Capable β can this AP even do it?) and bit 7 is MFPR (Management Frame Protection Required β does it insist on it?). Both zero, and you're looking at a network where anyone with a WiFi card and aireplay-ng can write their own disconnect button:
aireplay-ng --deauth 0 -a <BSSID> wlan0monaireplay-ng --deauth 0 -a <BSSID> wlan0mon(--deauth 0 means "keep sending forever" β I didn't run it to completion here, just confirmed the door was unlocked.)
Door #2: Can a Stranger Just Walk In? π§βπ»π«
Next, I try something almost rude. I bring my own access point and try to slide it onto the network, like showing up to a party uninvited and hoping nobody checks the guest list.
# Rogue AP in bridge mode β plugged in, sending a DHCP DISCOVER,
# waiting to see if an OFFER comes back# Rogue AP in bridge mode β plugged in, sending a DHCP DISCOVER,
# waiting to see if an OFFER comes backIf the network hands my device an IP address without blinking, there's no gatekeeper beyond "are you physically plugged in or in range." If it doesn't β if the DHCP server silently drops the request β someone built a guest list: a MAC address allowlist, checked before a lease is ever issued.
Here's the catch, and it's worth sitting with: a MAC address is just a field in a frame header. It's not cryptographically tied to anything. An attacker who sniffs one legitimate device's MAC off the air (trivial in monitor mode β it's sitting in plaintext in every frame that device sends) can clone it with macchanger and walk straight through the same door. A real identity check needs 802.1X / EAP, where the device proves who it is with a certificate or credentials, not just a hardware address it can lie about. MAC filtering is a speed bump, not a wall.
Door #3: The Shortcut That Skips the Line πββοΈπ¨
Normally, cracking a WiFi password offline means catching a real device shaking hands with the AP β all four messages of the 4-way handshake (M1 through M4), which derive the session keys from the PMK. That takes patience; you're waiting for someone to actually associate while you're watching.
But there's a shortcut, and it's almost elegant. The PMKID is calculated as:
PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AP-MAC || STA-MAC)PMKID = HMAC-SHA1-128(PMK, "PMK Name" || AP-MAC || STA-MAC)Some access points cram this value into the very first message of the handshake (M1) β the one the AP sends back the instant anyone sends it an association request. No client has to connect. No four-way exchange has to complete. You just ask, and some APs answer with exactly what you need, baked into the Key Data field of the EAPOL frame.
hcxdumptool -i wlan0mon -o capture.pcapng --enable_status=1
hcxpcapngtool capture.pcapng -o hashes.22000hcxdumptool -i wlan0mon -o capture.pcapng --enable_status=1
hcxpcapngtool capture.pcapng -o hashes.22000I also send bettercap's WiFi module in from a different angle β association requests to the target BSSID, watching for the same signature in the response.
If a PMKID does show up in that .22000 file, the next step is the part people actually picture when they think "hacking WiFi":
hashcat -m 22000 hashes.22000 wordlist.txthashcat -m 22000 hashes.22000 wordlist.txtMode 22000 is hashcat's unified WPA/WPA2/PMKID format β it'll happily chew through either a captured PMKID or a full handshake, same command either way. Whether anything actually fell out of that file on this network is a different question, and not one this write-up answers.
Door #4: The Eight-Digit Key Under the Mat π
Some networks let devices join with an 8-digit PIN instead of the real password. Sounds convenient. It's also famously flimsy, and the flaw is baked into the protocol's own math: the PIN isn't checked as one 8-digit number. It's checked as two halves β the first 4 digits, then the last 4 (where the 8th digit is just a checksum). That turns a 1β°βΈ brute-force problem into roughly 1β°β΄ + 1β°Β³, which collapses to about 11,000 total guesses instead of 100 million.
On top of that, certain older chipsets generate the nonces inside the WPS exchange with weak entropy. Pixie Dust exploits that directly β instead of brute-forcing online (slow, lockout-prone), it captures one exchange and recovers the PIN offline, in seconds, by attacking the weak randomness in message M3.
First question, before any of that: is this door even there?
wash -i wlan0monwash -i wlan0monOne command, listening passively across both bands, and I know whether WPS is sitting there waiting, or whether it's been switched off at the firmware level entirely.
Door #5: Is This Network Ready for What Comes Next? π
This check isn't about breaking anything. It's about reading the fine print on the upgrade path. WPA3-SAE (Simultaneous Authentication of Equals) replaces the old PSK exchange with the Dragonfly handshake β a commit-and-confirm exchange built on a zero-knowledge proof. Both sides prove they know the password without ever putting anything derived from it on the air in a form that's useful for offline dictionary attacks. Capture the entire exchange and you still can't brute-force it offline the way you can with a WPA2 handshake.
SAE also buys you forward secrecy β each session negotiates fresh keys, so a password compromised next year doesn't retroactively unlock traffic captured today β and it makes PMF mandatory, which would close Door #1 permanently and by default.
airodump-ng wlan0mon --essid <target-SSID>airodump-ng wlan0mon --essid <target-SSID>Same beacon, same RSN tag I pulled apart back at Door #1 β just hunting for a different Authentication and Key Management (AKM) suite signature this time: SAE, or its open-network cousin OWE.
Door #6: The Convenience That Can Bite Back πββοΈβ‘οΈπ
802.11r, or Fast BSS Transition, lets a device hop between access points on a big network without doing a full re-authentication every time β handy when you've got a whole building full of APs and someone walking from one end to the other on a call. It works by pre-deriving the next AP's keys (via an R0KH/R1KH key hierarchy rooted in the original MSK) before the device even associates.
The catch: that FT exchange happens over FT Action frames, and if PMF isn't standing guard alongside it, those frames can be captured and picked apart offline, at the attacker's leisure, the same way an unprotected handshake can.
airodump-ng wlan0mon --essid <target-SSID>airodump-ng wlan0mon --essid <target-SSID>Same capture technique as Door #5. This time I'm hunting for the FT-PSK or FT-SAE AKM suite OUIs hiding in the RSN tag β the fingerprint that says "fast roaming is live here."
Door #7: Is the Lock Itself Actually Good? π
Last stop, and the most fundamental one: what's actually encrypting this traffic, at the cipher level? The RSN tag carries this as an OUI-plus-suite-type code β 00-0F-AC:2 means TKIP (broken, deprecated, vulnerable to the chop-chop and Beck-Tews attacks), 00-0F-AC:4 means CCMP-128 (AES in counter mode, with CBC-MAC for integrity β the real WPA2 standard), and on a WPA3 network you'd see 00-0F-AC:9 for GCMP-256 instead.
Some networks say they're on WPA2 while quietly leaving a WEP or TKIP fallback alive in a legacy AP profile, which downgrades a connection without telling anyone sitting at it.
airodump-ng wlan0monairodump-ng wlan0monThen one more pass through Wireshark, reading the Pairwise Cipher Suite and Group Cipher Suite fields directly β not what the network claims to run in its spec sheet, but what it's actually negotiating, suite code by suite code.
The Part Nobody Talks About π€
Here's what got me, sitting there running all seven of these: not one of them needed hashcat yet. Every single check up to this point is just reading fields that are already sitting in plaintext in the air β RSN tags, AKM suites, cipher OUIs, capability bits. Most networks are already telling you exactly how exposed they are, in a 90-byte beacon frame broadcast ten times a second. You just have to know which seven fields to look at, and what each bit actually means.
Cracking the password is the backstop. These seven doors, read straight off the 802.11 frame headers, are the actual wall.
That's the thing the movie scene never shows you: the real work isn't the ten seconds of green text. It's the hour before it, parsing beacon frames byte by byte, letting the network tell you everything it's already saying out loud. π§
One thing left out on purpose: which of these doors actually opened on this particular network. That part stays with the client. The protocol-level process β the part worth sharing β is everything above. π€