Half Handshake Tools?

[CyberPentester]

You are confusing options regarding attacks against APs and attacks against CLIENTs.



Please also notice that the ESSID list is not(!) a filter list.



We're doing filtering by MACs only using two different kinds of soft coded filter lists: MAC AP filtering and MAC CLIENT filtering.



As an alternative, you can use BPF code to filter whatever you want.





Filtering by ESSID is too slow, because many frames do not contain an ESSID. Doing this we need an additional list holding all(!) received MACs and the assigned ESSID (MAC_AP: MAC_CLIENT:ESSID). Due to MAC randomization this list will grow up very fast and it will take a long time to find the matching combination. We have to do this search on every(!) received frame! As a result, our response is too slow and the target disregard us.

I see, so in this case I could for example listen for incoming probes using airodump-ng and add the unassociated client MAC to the filtered_client list, and that only works when there is no MAC randomization.

Correct, this are not wildcard requests, but they are addressed to a bradcast MAC: fffffffffff



We can't use a broadcast MAC to respond and have to create a new MAC on every new ESSID. If we don't to this, we end up in an ESSID/MAC mismatch (same MAC on different ESSIDs).



This example



MAC_AP 112233445566 : ESSID "home"



MAC_AP 112233445566 : ESSID "my_network"



MAC_AP 112233445566 : ESSID "Obi WLAN Kenobi"



will end up in that mismatch and we are not able to calculate a PTK.



Please  remember the 2 formulas (PTK and PMK). As a result of this mismatch, hashcat will fail to find the PSK..







To prevent that, we're doing this on broadcast requests (undirekted PROBEREQUEST):



HCX_MAC_000da7864fc5 : ESSID "home"



HCX_MAC_000da7864fc6 : ESSID "my_network"



HCX_MAC_000da7864fc7 : ESSID "Obi WLAN Kenobi""

 



Ok, I understand and thank you for explaining that part. So, in the examples there is no way to tell hcxdumptool to only respond to client probe requests that match the ESSID in essidlist.txt and ignore the rest?

By the way, hcxdumptool does not seem to be hosting the ESSIDs properly, because when I click join on my phone and input a random password it returns "Couldn't join the network" instead of "Password incorrect".



This is the default response code of hcxdumptool. We tell the CLIENT that he can't join our NETWORK and it should look for another NETWORK (usually his assigned NETWORK or the next entry in its wpa_supplicant.conf).



We are doing this, because we want to request an M2 of every entry of the CLIENTs wpa_supplicant.conf and not only for the first entry.



https://www.codegrepper.com/code-example...nf+example

Hmm, but what is strange about this is that I setup an ESSID in essidlist.txt with name "AAAAAAAAA". However, when I did the authentication attempt from my phone, hcxdumptool did not pickup any of those authentication packets. Only on the ESSID from previously joined networks that were NOT part of the essidlist.txt.

BTW:



I know, that this stuff (zeored ESSID, wildcard ESSID, broadcast MAC, randomized MAC, PMK depending on ESSID and PSK, PTK depending on PMK and MACs and NONCEs, MIC depending on PTK, hashcat recovering the PSK depending on PMK and MIC, REPLAY COUNT, EAPOL TIMERs, time response behavior and the relationship/dependencies between all this conditions) is really hard core and it is very difficult to understand.



But hcxdumptool must take care about all of this dependencies and it must respond to a request just in time. Othersie the target disregard it.



To ensure that, hcxdumptool will respond to everything by default and store the packets to pcapng file. That is much faster than doing several filter options on the fly (except BPF code, because this is done inside kernel space, before the packet reach hcxdumptool).



Once we did it, hcxpcapngtool and hcxhashtool will have all the time needed to offline filter by MAC, ESSID, MESSAGE PAIR, PMKID, EAPOL, VENDOR, ...). All hashes are valid and hashcat is able to recover the PSK.

Yes, I am still pretty much a newbie, but I keep learning little by little with the usage of these tools and I am grateful to you and this community for teaching us more about these topics.



Since you mentioned the timing response I wanted to go back to when we were talking about tshark and other passive sniffers. What I want to know is, why are there articles about WPA Halfhandshake attack that suggest using passive sniffers like wireshark and tcpdump?

Examples:

https://kalitut.com/wpa2-half-handshake-attack/

https://thehackerway.com/2015/03/10/crac...handshake/



You mentioned that passive tools are missing some key information regarding timing that hcxdumptool is able to log. All articles are referencing the same github tool "WPA2-HalfHandshake-Crack". How come they claim that the "WPA2-HalfHandshake-Crack" tool (that hasn't been updated in ages btw) is able to read these packets and somehow be able to obtain the challenge PSK without this timing information?

Tool referenced: https://github.com/dxa4481/WPA2-HalfHandshake-Crack