A new attack vector, but not the golden ticket to Wi-Fi pwnage.

So, you’ve seen the new attack one can do on Access Points. Its client-less, meaning no need to do Spiderman stunts on the sides of buildings trying to be in range of both the AP’s AND the client’s using them.
No doubt you thus pulled out your Wi-Fi adapters and began trying to perform this attack. Only to find your success rate is less than stellar.

We’re going to go through some background about this attack vector, as well as some ways we can approach it. Keep in mind that the “old” or traditional method of WPA2 attacks based on capturing handshakes is still the most viable to guarantee results. However, the method of capturing PMKID’s is easier if you are not within range of clients – especially with highly directional antennas.

How does it work?
A brief lesson in Wi-Fi and how client’s and AP’s talk to each-other is in order.

STEP 1 – Who’s out there?
When your Wi-Fi network adapter kicks in and comes online, your system (be it Windows, Linux, MacOS, iOS etc.) will perform a few things. One of those is to find known networks that it has connected to before. It does this by sending a “probe” request along with the network name (SSID) that it is looking for.

For example, if your device connects to your home network called “HOME_WIFI”, even when you are at the Mall, your device is “probing” for “HOME_WIFI” – to see if it is available and to connect to it.

If an Access Point is within range who’s name is “HOME_WIFI” – it will respond to the probe request.
Note that your AP will respond with an RSN, which is Robust Security Network. This RSN enables negotiation of available encryption and authentication types.

STEP 2 – “Hi, its me!”
Your system, and thus Wi-Fi adapter now reply to the response from the AP with an Authentication Request. Note that your Wi-Fi adapter cannot “Associate” to an Access Point until Authentication is done. For obvious reasons – much like you would not first open the door to find out who the stranger is, vs looking through the intercom and checking they’re who they say they are before opening the door.

The Authentication Request prompts the Access Point to reply with its own frames for authentication, now being Sequence 2 and indicating if your request to associate is successful.

STEP 3 – “Let me in!”
Upon receiving the Sequence 2 frame from the AP, your client can now do a few things. For the PMKID attack however, the client is going to do the following:
The client is going to send an Association Request to the AP along with the ESSID and RSN (see above) information.
At this point, the stranger is saying open the door, but we have not authenticated yet.

The AP responds with “Hmmm, lets negotiate your access first.” – It does this by replying with an EAPOL frame (1/4 sequence) which, if supported by the AP, would contain the PMKID.

At this point, we now have the PMKID. But what exactly do we have?

The PMKID consists of the PMK, a feature of RSN which includes the PMK Name, The AP’s MAC Address and the Station’s Mac Address all concatenated together and processed through HMAC-SHA1-128 algorithm to result in a hash value.
The below is taken from the Hashcat website to illustrate how the PMKID is derived:
PMKID = HMAC-SHA1-128(PMK, “PMK Name” | MAC_AP | MAC_STA)

Let’s get Cracking
One avenue of this new attack vector that I very much like, is that I not only do not need to be in range of clients AND an AP, but also that I can actually be very FAR from an AP with a good quality and powerful directional antenna. Since I’m only interested in traffic to/from a single point, not a potential client as well.

To test this, I pulled out my trusty “Can”-tenna for this example. Once you have it pointed in the general direction, use airodump-ng to scan for networks and tweak the “can”-tenna movement until you have a nice strong signal from your target AP.

You will need to download and compile HCXTools and HCXDumptool from https://github.com/ZerBea – doing this on Kali is trivial and should take just a few minutes.

NOTE: By default, HCXDumptool is going to target ALL AP’s your adapter can see. I document how to prevent this further below if you do not want your attacks hitting all available networks around you.

STEP 1 – Put your Adapter into Monitor Mode

Put your Wi-Fi adapter into monitor mode, by using either of the two options below. Note that your adapter must support Monitor Mode & Packet Injection for it to be used with these tools.

OPTION 1 (assuming wlan0 is your wireless adapter)
ifconfig wlan0 down
iwconfig wlan0 mode monitor
ifconfig wlan0 up

(note the difference between iWconfig and iFconfig above)

OPTION 2 (assuming wlan0 is your wireless adapter)
airmon-ng check kill
airmon-ng start wlan0

(note that airmon-ng check kill is used to kill the WPA supplicant and DHCP clients which can mess up tools trying to monitor traffic. Even if using Option 1, you could still run airmon-ng check kill to kill unwanted processes).

If you used OPTION 1, your adapter will remain wlan0 and be in monitor mode. If you used OPTION 2, your adapter is now called wlan0mon and is in monitor mode.

STEP 2 – Use HCXDumpTool to get those PMKIDs

By default, running HCXDumpTool with the below syntax will work:

However, as mentioned, we want to target only specific network(s) and their AP’s. To do this, simply run airodump-ng and find your target SSID plus the Base Station Mac Address:

We will now tell HCXDumpTool to perform the same attack above but this time with 2 extra switches – one will give it a “filter” file which contains the MAC address of the target AP we want to attack, and the second switch will tell HCXDumpTool to ONLY TARGET the Mac addresses in the filter list.

Note that the filter list should not have blank or empty lines in it. Also Note that the filter file’s Mac address should have the colons (“:”) removed from the hex address.

We now run HCXDumpTool again, using the filter switches and watch as it attacks our target network, waiting for a PMKID.
The switches are:
–filterlist= To tell the tool which file contains the Mac Addresses
–filtermode=2 Tells the tool that these Mac Addresses in –filterlist are our targets, ignore anything else:

STEP 3 – Extract the PMKID hash value

To do this, we use HCXTools OR you can upload your packet capture file to https:///labs.bitcrack.net/pmkidtool.php which will extract the PMKID from any Wi-Fi capture file for you.

The PMKIDTool on Bitcrack’s website is also useful if you have an older capture file lying around from Wireshark or airodump-ng and want to check if it contains any PMKIDs.

The example below is using HCXTools:

STEP 4 – Crack the hash with Hashcat

Download Hashcat from https://hashcat.net or build it from source.
Once you have Hashcat, simply use Mode 16800 ( -m 16800) and crack it as you would any other hash file.

Assuming you have a wordlist called MyBigWordlist.txt, your Hashcat command would look like this:

We won’t go into detail of the cracking job, as it will vary greatly according to your hardware. Note that GPU’s are preferred over CPU’s for this kind of hash. Also note that if you want to use only CPUs, you will need to install the Intel OpenCL drivers. See more on the Hashcat website.

Conclusion
As you can see, this is a very viable attack vector if you do not have access to clients on the target Wi-Fi network. However, it is only supported by certain Access Points, and hence you may not be able to obtain a PMKID.
The best solution is to use a dual-approach of this method and the original 4-way handshake capture method. Between the two, your success rate of obtaining something to crack will be much higher.

——-
Dimitri Fousekis AKA RuraPenthe.

Thank you to ZerBea/ZeroBeat and Atom for their work on the PMKID attack vector.
The information in this article is strictly for education purposes only. We take no responsibility for how this information is used.