Wireshark on WPA2-PSK [AES] not decrypting

Question

I am trying to capture all packets on my network from all devices connected to an SSID .

• I started up airmon-ng
• Started Monitoring on mon0
• Changed Preferences in wireshark to 'enable decrytion' with wpa-pwd:

After all this, I start the capture on my WPA2-PSK [AES] network and I get all sorts of packets but it is not decrypting it and all the filters (even for eapol or http) do not show any packets.

I've been trying to understand wireshark for a very long time and there is no proper explanation of things. How can I decrypt the wpa2-psk traffic?

A screenshot of capture is here:

Solution

If you haven't already, read Wireshark's How To Decrypt 802.11 document on this and try decrypting the sample capture.

If you can't even get Wireshark to decrypt the frames in the example file, then you're probably running into a Wireshark bug.

Hints on seeing if you've decoded the sample file:

• You can't decode frames 3, 26, or 47; so basically, you won't see anything change in the first screenful of frames even if you're successfully decrypting things. You need to scroll down to after you see the Auth, Assoc, and EAPOL-key handshake.
• The first frame you can decode is 99 (Data, 404 bytes). Fully decrypted and decoded, it's a DHCP Request.
• Frame 102 (Data, 652 bytes) is a DHCP ACK.

Now, about decrypting your own captures:

Note that to decode WPA-PSK or WPA2-PSK frames from your own captures, you must capture all four frames of the EAPOL-key handshake, which happens right after the client associates to the AP. The AP and the client take the PSK and generate some cryptographic nonces, exchange the nonces via the EAPOL-key handshake, and then derive a one-time session key from that (the Pairwise Temporal Key, or PTK). If you don't capture that handshake, there's no way for Wireshark to learn the nonces, so there's no way for it to figure out what PTK the client and AP created for that session, so there's no way for Wireshark to decrypt that session.

You already mentioned that you didn't find any EAPOL frames in your capture. Look and see if you have the 802.11-layer Authenticate and Associate frame pairs. I'll bet you didn't get those either. The EAPOL-key handshake comes right after the Associate frame exchange.

Update: Also make sure you're capturing in promiscuous mode. 802.11 monitor mode will show you 802.11 headers and 802.11-specific frames, but it still might not show you unicasts between other devices unless you also enable promiscuous mode.

Comments

[Ramhound]

Are you sure Wireshark supports the decrypting a WPA2-PSK-AES connection? Verify the version of Wireshark your using supports doing what you require: wiki.wireshark.org/HowToDecrypt802.11. It also sounds like the you have both PSK and AES enabled which more then likely is NOT supported by Wireshark.

[fineTuneFork]

Hey @Spiff, Thanks for the info. Though I'd already tried all the things you've mentioned above. My Wireshark decrypts the sample cap file properly but, as you pointed out correctly, I am not able to capture Probe Response, Authenticate , Associate or EAPOL handshake. I only get beacon frames and probe request frames and encrypted data frames. I've tried to do every possible thing but I just can't see to wrap my head around this. Is it because of some AES PSK no-wireshark-support thing? Others seem to have managed to do it with AES PSK somehow... Would be really awesome of you if you can help!

[Spiff]

@fineTuneFork Did you start your capture before having the target machine join the network? Is your capture card capable of all the same data rates as the AP and target machine? For example, if your target machine can do 3 spatial streams (3SS, 450 mbps) and your capture card can only do 2SS (300 mbps), then you can't hope to see packets that the target machine sent at 3SS.

[fineTuneFork]

I did start capturing before turning on my wi-fi on motorola xt311 and nexus 7. Still no EAPOL - only beacon and probe requests. I sure hope that the target machine doesn't have a better hardware because both xt311 and nexus 7 are pretty technologically backward compared to an ultrabook (right?). If I am able to capture probe requests then should the probe response , auth, eapol not follow that automatically?

[Spiff]

@fineTuneFork It's probably safe to assume that the Motorola Fire XT311 and the Nexus 7 are both 1SS devices, so I would expect the Ultrabook's radio to be capable of receiving at all the same data rates as those other devices can send. You might want to make sure your Ultrabook it positioned well; if the two other devices were next to each other and the Ultrabook was across the room, it might not be able to decode the other devices' top data rates.

[fineTuneFork]

both were next to my ultrabook. Still can't capture EAPOLs. I just need one successful wireshark operation to get a hang of things. I haven't been able to crack this wireshark thing for 2 years now! Phew... why does this happen to me... Anyway, will you suggest me to post the same question on wireshark mailing list?

[Spiff]

@fineTuneFork Overall I think you need to solve the problem of why you're never capturing Auth's, Assoc's, and EAPOL-key frames. It could be that your Ultrabook's wireless driver's support for 802.11 monitor mode is broken. Many Windows users resort to buying a CACE/Riverbed AirPcap Nx Wi-Fi capture USB dongle, but they're expensive. You might want to try Linux; there are wireless-security-specific distros designed to make it easy to boot from a USB flash drive and run a sniffer. BackTrack is one. See if one supports your Wi-Fi chipset.

[Spiff]

let us continue this discussion in chat

[fineTuneFork]

Cool, I'm on chat window.

[starfry]

This helped me greatly: must capture all four frames of the EAPOL-key handshake which happens right after the client associates to the AP. The How To Decrypt 802.11 doesn't make it clear that this means that you should start capturing BEFORE connecting to the wireless network. A much appreciated clarification! +1

[starfry]

I will also add to my previous comment for anyone else finding this that the requirement to authenticate AFTER the capture starts also applies to any third party device on the network whose packets you want to capture.