5

The Problem

On my WPA2 network, I have been successfully able to get intercept a full four-message EAPOL handshake from a particular computer on my network. It is my understanding that with this handshake (and knowing the passphrase for my network), I should be able to decrypt not only broadcast traffic, but also internet traffic from that computer whose handshake I captured, since its communication with the access point is encrypted using data exchanged in the handshake and the PMK (computed from the SSID and passphrase data).

However, I still seem to only be decrypting "broadcast" traffic. There is no TCP traffic from the computer whose handshake I captured even though I visited unencrypted HTTP sites on it and used netcat on it to communicate with another computer on the WLAN. I can tell that at least the broadcast data is correctly decrypted because I can look at the encrypted and decrypted hex codes for those packets (they happen to primarily be MDNS, ICMP, ARP, etc.). I even tried to take the data and decrypt it with airdecap-ng but this did not work either.

It seems that based on examples of packet data I've been able to play with in Wireshark that I should be able to get this traffic. In particular, this guide shows how to do it and provides a pcap file on which you can easily decrypt the WPA2 packets and get a bunch of TCP packets in Wireshark. Similarly, the Wireshark Wiki explains how to do this in addition to providing pcap samples that also can be decrypted to yield TCP traffic.

My Setup

  • Kali Linux Live Persistence on USB
  • Alfa AWUS036H in monitor mode (using airmon-ng)
  • WLAN with WPA2, no WPS
  • Wireshark IEEE 802.11 Preferences:
    • Enable decryption IS checked
    • Ignore the Protection bit is set to No
    • Decryption keys include a wpa2-pwd entry in the format of passphrase:ssid

Main Question

Why am I not able to pick up the TCP traffic from the computer for which I intercepted a full EAPOL handshake from, the way that I was able to do so in the sample pcap files I have linked? Am I fundamentally misunderstanding how this works, or is this likely the result of a hardware or network related issue?

6
  • My guess is that your NIC isn't actually in monitor mode.
    – Stephane
    Aug 29, 2016 at 9:50
  • I used airmon-ng which added interface wlan0mon in lieu of wlan0, and I confirmed on iwconfig that it was in monitor mode. I also ensured that monitor mode was enabled on wlan0mon in Wireshark before capturing, and used that interface. Also, it had to see a handshake before decrypting broadcast messages which is only necessary on monitor mode since the nic is not actually connected to the network and the computer doesn't get a handshake of its own. Aug 29, 2016 at 16:50
  • Then I don't know. I guess you've checked if you're receiving the encrypted frames at the very least
    – Stephane
    Aug 30, 2016 at 5:47
  • I'm receiving some encrypted frames that wireshark decrypts but they don't seem to include the primary Internet traffic, just mainly broadcast/ARP messages. Aug 30, 2016 at 16:11
  • That's a hint that your interface is not actually in full monitor mode: you get the broadcast frames, not unicasts or multicasts not meant to you. That being said, I don't have any solution to offer, I'm afraid. The problem could come from your adapter, drivers or setup.
    – Stephane
    Aug 31, 2016 at 11:00

1 Answer 1

5

As it turns out, the issue was that my WLAN is setup as 802.11b/g/n, and the target devices I had been testing this on were all 802.11b/g/n compatible, so they were using 802.11n by default to directly communicate with the AP. As I realize now, the Alfa AWUS036H is only 802.11 b/g compatible, so it was was not able to intercept the 802.11n traffic! Once I switched my router to only use b/g, then I was able to capture the TCP traffic as expected.

Lesson learned: get a WiFi card that is actually compatible with modern wireless standards -_-

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .