Cracking a password present in wordlist doesn't work

[bbjjlk]

Hello there,

First of all i'm kinda new in pen testing and cracking, so I might lack some knowledge, this is why i'm asking here.

I have captured data with hcxdumptool via this comand:

Code:

hcxdumptool -i wlan0 -o dumpfile.pcapng --active_beacon --enable_status=15

Let it run for a while to check all frequencies and then run that one:

Code:

hcxpcapngtool -o hash.hc22000 -E essidlist dumpfile.pcapng

From the hash file I isolated the desired WPA*01*..... with the mac address i wanna try to crack and put it in a separate .hc22000 file.

From that I ran:

Code:

hashcat -m 22000 myhash.hc22000 rockyou.txt

I know the password of the Wifi and he's present in the wordlist but for some reason hascat didn't recovered it.
Am I doing something wrong ?

EDIT: I noticed that WPA*01 are kinda short lines as WPA*02 are way longer, what's the difference between the two ?

[bbjjlk]

Aftre further investigation an some tests, it seems like i can't crack PKMIDROGUE that generate a WPA*01... line, even with the password in the wordlist, but I get no problem on EAPOL whcih generate WPA*02... lines.

I still struggle to understand why.

[ZerBea]

Take a look at the MESSAGEPAIR field of the EAPOL hash line (WPA*02) and the MESSAGEPAIR field of the PMKID hash line (WPA*01).


EAPOL MESSAGEPAIR field:
An EAPOL M1M2 (challenge) is a valid MESSAGEPAIR but this does not automatically imply that it belongs to the target NETWORK.
Make sure the EAPOL is authorized:

Code:

001 = M1+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed
010 = M2+M3, EAPOL from M2 (authorized)
101 = M3+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed

PMKID MESSAGEPAIR field:
A PMKID taken from the CLIENT does not automatically imply that it belongs to the target ACCESS POINT.
Make sure the PMKID is taken from the target ACCESS POINT:

Code:

1: PMKID taken from AP

To get MESSAGEPAIR field information of PMKIDs, hcxpcapngtool 6.3.1 is mandatory!


Explanation of the MESSAGE PAIR fields is here:
https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2


Explanation of the 4way handshake is here:
https://medium.com/@alonr110/the-4-way-h...779a315a64


Please notice that hcxdumptool is acting as an ACCESS POINT (too) that accepts every challenge of a CLIENT (depending on how many connection attempts the CLIENT started hcxdumptool will get several challenges with possible different PreSharedKeys).
The only way to distinguish the hashes is by MESSAGEPAIR field.

[ZerBea]

hcxdumptool is designed to request (depending on the options) an entire history of PreShardKeys stored in the CLIENTs wpa-supplicant.conf (challenges).
It is up to the user to choose the desired MESSAGPAIR(s).

[bbjjlk]

Thanks fo your reply i'm gonna try that and make you an update

[bbjjlk]

Alright i've read the doc you sent me and have a few noobish questions:

This is how to understand MESSAGEPAIR ok.

Code:

bitmask of message pair field PMKID (WPA*01):
0: reserved
1: PMKID taken from AP
2: reserved
4: PMKID taken from CLIENT (wlan.da: possible MESH or REPEATER)
5: reserved
6: reserved
7: reserved


bitmask of message pair field EAPOL (WPA*02):
2,1,0:
000 = M1+M2, EAPOL from M2 (challenge)
001 = M1+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed
010 = M2+M3, EAPOL from M2 (authorized)
011 = M2+M3, EAPOL from M3 (authorized) - unused
100 = M3+M4, EAPOL from M3 (authorized) - unused
101 = M3+M4, EAPOL from M4 (authorized) - usable if NONCE_CLIENT is not zeroed
3: reserved
4: ap-less attack (set to 1) - nonce-error-corrections not required
5: LE router detected (set to 1) - nonce-error-corrections required only on LE
6: BE router detected (set to 1) - nonce-error-corrections required only on BE
7: not replaycount checked (set to 1) - replaycount not checked, nonce-error-corrections mandatory

Let try with an example. if I follow what's written in the doc:

Code:

WPA*01*PMKID*MAC_AP*MAC_CLIENT*ESSID***MESSAGEPAIR

This is the formatting of my hash.hc22000 which is correct. In my case tho, I have the line but the MESSAGEPAIR is missing.
So why is it missing ? Does it comes from my configuration of the tools when i launch the command of is it related to the AP or just my adapter have not intercept the MESSAGEPAIR ?

Sorry if this sound obvious for you, just learning and try to understand and not just executing command blindly.

[ZerBea]

The MESSAGEPAIR information on PMKID (format WPA*01*) is new. It was added to hcxpcapngtool since version 6.3.1
Older versions of hcxpcapngtool don't have this information.

Regarding a PMKID, it is important to know where it comes from.
A CLIENT can hold an old/outdated PMKID. It also can hold a PMKID of a REPEATER.
This PMKIDs may calculated by an old/outdated PSK.

If you have something like this:

Code:

WPA*01*PMKID*fc690c158264*f4747f87f9f4*686173686361742d6573736964***01
WPA*02*MIC*fc690c158264*f4747f87f9f4*686173686361742d6573736964*ANONCE*EAPOL*x2

If the MAC_AP of WPA*01 and WPA*02 is the same
and if the MAC_CLIENT of WPA*01 and WPA*02 is the same
and if THE ESSID of WPA*01 and WPA*02 is the same
and if the PMKID is from the AP (MESSAGEPAIR: 01)
and if the EAPOL is AUTHORIZED (MESSAGEPAIR x2 or x5)
the PSK belong to the same NETWORK.

Take a look at this NETWORK:
https://wpa-sec.stanev.org/?search=inwi+Home+4G181E6D
The conditions mentioned above met.

An example of a valid MESSAGEPAIR that does not belong to the target NETWORK:
The NETWORK PSK is ABCDEFGH.
A not authorized CLIENT tries to connect to the NETWORK using the PSK 12345678.
Your word list contain 12345678.
You got a PMKID MP 01.
You got an EAPOL MP 00.

In that case hashcat recover the PSK 12345678 from the EAPOL MESSAGEPAIR but this is not the PSK of the NETWORK. The NETWORK PSK remain unrecovered.

If you add ABCDEFGH to the word list, hashcat is able to recover both.
As a result, you get 2 different PSKs for this NETWORK:
an authorized one ABCDEFGH that allow to get access to the NETWORK
a not authorized one 12345678 from the try of a CLIENT that does not have the permission to enter the NETWORK.

If you do not want to run hashcat on not authorized EAPOL MESSAGEPAIRs you have to remove them (MP x0) from your hash list.

[bbjjlk]

I've updated my hcxdumptool which was 6.2 to 6.3 and made a rescan and now i got the MESSAGEPAIR after the *** on my WPA*01 lines
In my hash file i was able to scan 3 network:

Code:

WPA*02*4039a05f115e8cd2c8ec1fac03e40041*000b18beacc8*0006784bb43a*4c697665626f782d46333438*189dfe9c4eb15ecf14d266803d018fb71d115a4f807387632e07705f4d9cd683*0103007502010a0000000000000000f7922c149c96e80bd392a55bba45bd69ea6f4d7d194ceb7ac48a9c112a9748b31d12000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001630140100000fac020100000fac040100000fac020000*10
WPA*01*c34fa9c6b55fe62801403b00959d3089*6c61f402a7ee*b4e1eb143790*5346525f41374538***01
WPA*01*009fbfdd3bc3f9df472002a45ca0e45d*f46bef4d04a6*b4e1eb143790*4b434d***01

Before the update of the tool, i didn't get the ***01 at the end of the line.
So If i got it right 01 means i got PMKID form the AP so i'd be able to crack the password this time ?

WPA*02 works, I already cracked one.

So far I never got the case where I got a WPA*01 and a WPA*02 for the same MAC_AP.
Not sure I got it right but from a WPA*01, do I need a WPA*02 witht the same MAC_AP to be able to crack it or does the WPA*01 line is enough ?

[ZerBea]

The EAPOL MESSAGEPAIR is not authorized (MP 10). If hashcat is able to recover the PSK it is possible that it does not belong to the NETWORK, because hcxdumptool recorded a connection attempt of a not authorized CLIENT.

The PMKIDs came from two APs. The recovered PSKs should belong to the NETWORKs.

If you got a PMKID from an AP, you do not need an EAPOL MESSAGEPAIR to recover the PSK

BTW:
Please mask the PMKID and the MIC of your examples by xxxx as well as the EAPOL field. We do not need this information to explain the MESSAGEPAIR fields.

[ZerBea]

BTW:
Regarding the default key space of the examples (which is huge), it is nearly impossible to recover the PSK.
You need to reverse engineer the firmware