Unable to decrypt Wifi data

One of the common causes of possible WPA2 decryption issues is that there are, in fact, no data to actually decrypt. This is often due to modulation differences in the data frames under review, or sometimes even more fundamental issues such as sniffing on the wrong channel or band, or even not having monitor/promiscuous mode capability at all.

For the sample trace provided, there is one full EAPOL handshake present with

Filter: eapol
BSS Id: Cambridg_dd:27:b4 (70:d9:31:dd:27:b4)
STA address: IntelCor_16:ea:ef (f0:d5:bf:16:ea:ef)

Looking at a beacon for this BSSID, no HT is supported so it would only be an 802.11b/g capable access point.

filter: wlan.bssid == 70:d9:31:dd:27:b4 and wlan.fc.type_subtype == 0x08

Tagged parameters (129 bytes)
Tag: SSID parameter set: Public Wifi
Tag: Supported Rates 1(B), 2(B), 5.5(B), 11(B), 6, 9, 12, 18, [Mbit/sec]
Tag: DS Parameter set: Current Channel: 11
Tag: Traffic Indication Map (TIM): DTIM 0 of 0 bitmap
Tag: ERP Information
Tag: Extended Supported Rates 24, 36, 48, 54, [Mbit/sec]
Tag: Vendor Specific: Microsof: WPA Information Element
Tag: RSN Information
Tag: Vendor Specific: Microsof: WMM/WME: Parameter Element
Tag: Vendor Specific: RealtekS

This is somewhat good, as this type of traffic will be easier to capture. I notice the trace is taken VERY close to the AP as the RSSI is very high and I see bleed through into other channels. You might want to move away a meter or two from the AP, maybe have a -40 or so RSSI instead of -25.

To see if there is anything to decrypt, we can check for any Data or QoS-Data frames, noting we will only have QoS-Data frames if WMM is available on both STA and AP (and it is if you look at the Association Request/Response frames):

filter: wlan.bssid == 70:d9:31:dd:27:b4 and (wlan.fc.type_subtype ==0x020 or wlan.fc.type_subtype ==0x028)

I see two possible frames to decrypt AFTER the EAPOL handshake, but that is it (frames 16622 and 16628):

After applying your SSID/Passphrase, these frames do, in fact, decrypt:

So this confirms a number of things:

1. The ability to collect the 4-way EAPOL handshake exists, and the decryption parameters are correct (SSID/Passphrase)
2. The issue lies with NOT collecting all the data frames expected
3. This system likely does not have modulation issues collecting packets since the capture adapter is 802.11bgn/1SS but the system is running at 802.11bg only
4. There are more than 19K Deauth frames out of a total of 23K frames, so 83% of the captured traffic are Deauths. This is more than a bit excessive; yes, using tools to send Deauths to capture the 4-way handshake is valid but this implementation is like squishing an ant with sledgehammer; can you send one or two Deauths instead? There are other techniques as well to force a client to generate an unencrypted rekey.

Recommendations:

1. The signal is coming into the capture adapter very hot so move the systems a little further apart
2. Develop a new technique to generate the 4-way handshake (rekey). Some options: reboot the client device; use a config tool in the client device to disable the radio and then re-enable; select a different SSID on the client and then come back to this one; reboot the AP; work on the injection tool to reduce the number of Deauths transmitted; use a possible config option in the AP to remove a client from association - if it exists; and there are other ways.
3. Allow the capture to run for a longer period of time after the handshake. You should be able to see this in Wireshark with live scrolling and keep repeating until you getting the behavior you want - with decryption credentials entered, Wireshark should decrypt in realtime as frames scroll by.