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?

saltthehash
  • 235
  • 1
  • 8
  • My guess is that your NIC isn't actually in monitor mode. – Stephane Aug 29 '16 at 09: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. – saltthehash Aug 29 '16 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 '16 at 05: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. – saltthehash Aug 30 '16 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 '16 at 11:00
  • But I am getting some multicast and unicast messages. For example, I captured/decrypted multicast ICMP and MDNS packets from the target computer whose handshake I captured (they were addressed to ipv4 and ipv6 multicast addresses). I did just notice that I captured a bunch of "Request-to-send" frames between the target computer and AP (mixed in with "Clear-to-send" and "Block Ack" frames). There are also other 802.11 frames between devices on my LAN and the AP (RTS, CTS, BA, etc.) – saltthehash Aug 31 '16 at 15:19

1 Answers1

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 -_-

saltthehash
  • 235
  • 1
  • 8