Is it possible to get a WPA 'false positive'?
#1
I am working through a challenge which involves gaining access to a WPA2 protected network. In short, I used airodump-ng to capture the PMKID and WPA handshake for the network, and converted this to a 22000 file. I am satisfied that I did everything correctly here because I have used this process on successful cracks many times before.

After I unsuccessfully tried some wordlists, I did some research on the type of router and saw that the default password had an 8 digit numerical mask, e.g. 12345678. I then started a mask attack which cracked the hash to a string which matches this format.

Unfortunately, my attempts to log into the network have failed. When I try and login via terminal (to see the error message) it's apparently an authentication error ('secrets required but not supplied'). I then repeated the whole process to double check my results, including by running a mask attack with the --keep-guessing flag. All attempts yielded the same password.

Is it possible that I have a 'false positive' here? I would think not... If that is the case, are there any other ways I could investigate why my connection to the network is being refused?
Reply
#2
(06-22-2023, 02:54 AM)sex_lion Wrote: I am working through a challenge which involves gaining access to a WPA2 protected network. In short, I used airodump-ng to capture the PMKID and WPA handshake for the network, and converted this to a 22000 file. I am satisfied that I did everything correctly here because I have used this process on successful cracks many times before.

After I unsuccessfully tried some wordlists, I did some research on the type of router and saw that the default password had an 8 digit numerical mask, e.g. 12345678. I then started a mask attack which cracked the hash to a string which matches this format.

Unfortunately, my attempts to log into the network have failed. When I try and login via terminal (to see the error message) it's apparently an authentication error ('secrets required but not supplied'). I then repeated the whole process to double check my results, including by running a mask attack with the --keep-guessing flag. All attempts yielded the same password.

Is it possible that I have a 'false positive' here? I would think not... If that is the case, are there any other ways I could investigate why my connection to the network is being refused?

Yes if the handshake is not successful
sometimes, it says handhshake captured successfully but in reality
it might turn out to be a half handshake, incomplete
Reply
#3
(06-22-2023, 07:27 AM)Zeroc0ol82 Wrote: Yes if the handshake is not successful
sometimes, it says handhshake captured successfully but in reality
it might turn out to be a half handshake, incomplete

This is a good point - I went through the initial capture file with Wireshark and it was the case that there was only a partial handshake (but a returned PMKID). I just re-ran the attack and have verified that the full handshake has now been captured, and verified this through both a manual inspection and by running aircrack-ng to ensure it returned 'WPA (1 handshake, with PMKID)'.

... but then I ran it through hashcat again and all hashes were contained in the potfile!

Quote:Minimum password length supported by kernel: 8
Maximum password length supported by kernel: 63

INFO: All hashes found as potfile and/or empty entries! Use --show to display them.

I am wondering if the network may have some kind of MAC filtering or other mode enabled, but I do not know how to probe for this (perhaps this is off topic). I mainly just want to get to the bottom of whether or not I should accept the password returned by hashcat as being the correct one.
Reply