02-06-2017, 10:29 PM
A few days ago a user came into the #hashcat IRC channel and reported to have problems cracking one of his WPA handshake captures. No worries, the user knew the password to the WPA handshake so this seemed to be a ligitimate request.
After some debugging it was clear what is the problem. It's the tools he used to convert the .cap file to .hccap!
We've tested the following:
Especially if you run a deauth attack to accelerate the handshake capture process, it's possible that there's multiple WPA handshakes running in parallel (and getting captured) from the same AP and Station. Each of them will have different nonce's (random data) which is part of the calculation that hashcat is doing to verify if a password candidate is correct or not. To do a successfull verification it's important to use the correct nonce's and to do this it's important to match the handshake packets correctly.
I've reported this to the Aircrack-NG Team, trac ticket is here: http://trac.aircrack-ng.org/ticket/651
As this ticket is open since 8 years, and the last submission for cap2hccap is also 3 years ago, we've decide to write our own converter. This new converter is now finished and is called "cap2hccapx". We've added it as a new tool to https://github.com/hashcat/hashcat-utils, whose newest version we've already released as hashcat-utils v1.4.
While we were implementing cap2hccapx we learned a bit better about the information exchanged in the so-called 4-way WPA handshake and from which packets we can obtain valuable information. There's basically two possible combinations of messages (also called exchanges) in the handshake process that can be used to crack the authentication, not just one.
The most important message of the 4 messages is the second one. We always need that one. After that, in addition to the beacon requests/responses (which provide us with the network name, aka ESSID, and MAC of the access point, aka BSSID), we at least need one of these messages:
On the other hand, if we only are in possession of the 1st and 2nd one, we can't tell for sure if the connection was established or even if the password was correct. However, it has it's own usecase. For example whenever you see a Client probing for his AP this typically also shows you the ESSID. As an attacker, you can now simply setup an AP with exactly this ESSID. If the Client does not verify the MAC address (most clients don't do this), it will try to connect to your AP. Of course this will fail, because you AP doesn't use the same Password as the Client does. However, the Client will have used the correct Password. This so called "non-authenticated" Handshake can get cracked with hashcat now, too. If you succeed to crack it, you can re-setup your AP with the cracked password and the connection with the Client will be successful giving you access to the Client from a more "internal" network position or to do any man-in-the-middle attack. Alternatively, you could also connect to the real AP, in case you know where it is located.
We very quickly recognized that all of this new type of information somehow will force us to introduce a new hashcat capture format. We call it "hccapx". You can see the details about the new format here: https://hashcat.net/wiki/hccapx (and if you want you can compare it to the old hccap format https://hashcat.net/wiki/hccap).
All in all, we added several additional entries that help hashcat to know if the file is a valid one (because we added a file magic "HCPX" at the start of the file), we added a format version number and of course the information about whether the authentication was successful (see the "authenticated" entry) and therefore if message 3 was captured too. If your .hccapx file contains both types, hashcat will try to crack both. This will create no additional cost because all the verification is done after the slow PBKDF-HMAC-SHA1 part. IOW, you get this features for free.
The hccapx is a new format and we know that you might have some old .hccap files in your archives. But believe us, the changes were needed and we love them. Without these changes we can't ensure that the converted data is even crackable (because as you already know, output from other tools might not be crackable at all, because of the missing checks and faulty matching algorithm). Therefore it also doesn't make any sense to write a converter from hccap to hccapx.
In case you were using the old converter site, we've also updated that one: https://hashcat.net/cap2hccapx/
Finally, with these changes in hashcat-utils and hashcat, we expect to get much fewer problem reports and hopefully you will crack more WPA/WPA2 networks too.
After some debugging it was clear what is the problem. It's the tools he used to convert the .cap file to .hccap!
We've tested the following:
- aircrack-ng (latest version from GitHub)
- cap2hcap (latest version from SVN)
Especially if you run a deauth attack to accelerate the handshake capture process, it's possible that there's multiple WPA handshakes running in parallel (and getting captured) from the same AP and Station. Each of them will have different nonce's (random data) which is part of the calculation that hashcat is doing to verify if a password candidate is correct or not. To do a successfull verification it's important to use the correct nonce's and to do this it's important to match the handshake packets correctly.
I've reported this to the Aircrack-NG Team, trac ticket is here: http://trac.aircrack-ng.org/ticket/651
As this ticket is open since 8 years, and the last submission for cap2hccap is also 3 years ago, we've decide to write our own converter. This new converter is now finished and is called "cap2hccapx". We've added it as a new tool to https://github.com/hashcat/hashcat-utils, whose newest version we've already released as hashcat-utils v1.4.
While we were implementing cap2hccapx we learned a bit better about the information exchanged in the so-called 4-way WPA handshake and from which packets we can obtain valuable information. There's basically two possible combinations of messages (also called exchanges) in the handshake process that can be used to crack the authentication, not just one.
The most important message of the 4 messages is the second one. We always need that one. After that, in addition to the beacon requests/responses (which provide us with the network name, aka ESSID, and MAC of the access point, aka BSSID), we at least need one of these messages:
- The 1st one: packet from the access point (AP) to the client (STA) which initiate the connection request
- The 3rd one: packet from the access point (AP) to the client (STA) which is a response to the message number 2
On the other hand, if we only are in possession of the 1st and 2nd one, we can't tell for sure if the connection was established or even if the password was correct. However, it has it's own usecase. For example whenever you see a Client probing for his AP this typically also shows you the ESSID. As an attacker, you can now simply setup an AP with exactly this ESSID. If the Client does not verify the MAC address (most clients don't do this), it will try to connect to your AP. Of course this will fail, because you AP doesn't use the same Password as the Client does. However, the Client will have used the correct Password. This so called "non-authenticated" Handshake can get cracked with hashcat now, too. If you succeed to crack it, you can re-setup your AP with the cracked password and the connection with the Client will be successful giving you access to the Client from a more "internal" network position or to do any man-in-the-middle attack. Alternatively, you could also connect to the real AP, in case you know where it is located.
We very quickly recognized that all of this new type of information somehow will force us to introduce a new hashcat capture format. We call it "hccapx". You can see the details about the new format here: https://hashcat.net/wiki/hccapx (and if you want you can compare it to the old hccap format https://hashcat.net/wiki/hccap).
All in all, we added several additional entries that help hashcat to know if the file is a valid one (because we added a file magic "HCPX" at the start of the file), we added a format version number and of course the information about whether the authentication was successful (see the "authenticated" entry) and therefore if message 3 was captured too. If your .hccapx file contains both types, hashcat will try to crack both. This will create no additional cost because all the verification is done after the slow PBKDF-HMAC-SHA1 part. IOW, you get this features for free.
The hccapx is a new format and we know that you might have some old .hccap files in your archives. But believe us, the changes were needed and we love them. Without these changes we can't ensure that the converted data is even crackable (because as you already know, output from other tools might not be crackable at all, because of the missing checks and faulty matching algorithm). Therefore it also doesn't make any sense to write a converter from hccap to hccapx.
In case you were using the old converter site, we've also updated that one: https://hashcat.net/cap2hccapx/
Finally, with these changes in hashcat-utils and hashcat, we expect to get much fewer problem reports and hopefully you will crack more WPA/WPA2 networks too.
