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.
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?
Correct
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.
For sure, it will not response, because hcxdumptool is not a fake AP. It doesn't respond to requests if AKM and CYPHER suite is not stored in wpa_supllicant.conf of the target.
It is mandatory that the CLIENT was connected to a real existing NETWORK before (with existing AKM and CYPHER information) and there is an entry in his wpa_supplicant.conf like this:
https://getocean.vercel.app/docs/wifi-wpa-supplicant
We don't want to get false positives of not existing NETWORKs, because this information is useless to discover weak points.
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?
A passive tool is not able to request missing packets. As described in the article you need an active tool to attack and a passive tool to dump running on the same device.
tshark, wireshark, tcpdump do not make an evaluation. They only show what they have received. If they run on they same device as the attack tool, they should get the same packets.
If you run them on a different device than you'll notice some packet losses.
At the time this articles are written hcxdumptool was neither open source nor public and no one knew it existed (hcxdumptool/hcxdumptool went public together with hashcat going open source).
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?
That is easy to answer. Run this tools mentioned in the articles and convert the dump files to hc22000. Than do the same using hcxdumptool and compare the status output of hcxpcapngtool (EAPOL and PMKID entries of the status). I'm sure you'll notice the difference.
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.
I'm a (retired) crypto and signals analyst, but I'm sure there is a lot of stuff I still don't know, too. I'm learning every day something new (mostly related to OS updates and new security features).
But a good starting point is to get some basic information about 802.11 protocol and radio techniques.
hcxtools (that include hcxdumptool and hcxlabtool) are analysis tools working on unfiltered mass data (main purpose), e.g.:
https://hashcat.net/cap2hashcat/
https://wpa-sec.stanev.org/?
They are not designed to attack a single NETWORK or to recover a single PSK of a single NETWORK. However, they can do this using the right options, but purpose is to discover weak points within the entire system which are not not convered by other tools (eg.: PMKID attack, NONCE ERROR CORRECTION). This is only possible if you collect (and anylyze) thousands of packets.
Options may look similar to other tools, but the behavior is different. So please forget everything you read about this tools, because it will not(!) work as expected on hcxdumptool chain (hcxdumptool -> hcxpcapngtool -> hcxhashtool -> hcxpsktool -> hashcat).
Correct.
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?
Correct
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.
For sure, it will not response, because hcxdumptool is not a fake AP. It doesn't respond to requests if AKM and CYPHER suite is not stored in wpa_supllicant.conf of the target.
It is mandatory that the CLIENT was connected to a real existing NETWORK before (with existing AKM and CYPHER information) and there is an entry in his wpa_supplicant.conf like this:
Code:
network={
ssid="NAME-OF-YOUR-NETWORK"
psk="PASSWORD"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP
}We don't want to get false positives of not existing NETWORKs, because this information is useless to discover weak points.
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?
A passive tool is not able to request missing packets. As described in the article you need an active tool to attack and a passive tool to dump running on the same device.
tshark, wireshark, tcpdump do not make an evaluation. They only show what they have received. If they run on they same device as the attack tool, they should get the same packets.
If you run them on a different device than you'll notice some packet losses.
At the time this articles are written hcxdumptool was neither open source nor public and no one knew it existed (hcxdumptool/hcxdumptool went public together with hashcat going open source).
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?
That is easy to answer. Run this tools mentioned in the articles and convert the dump files to hc22000. Than do the same using hcxdumptool and compare the status output of hcxpcapngtool (EAPOL and PMKID entries of the status). I'm sure you'll notice the difference.
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.
I'm a (retired) crypto and signals analyst, but I'm sure there is a lot of stuff I still don't know, too. I'm learning every day something new (mostly related to OS updates and new security features).
But a good starting point is to get some basic information about 802.11 protocol and radio techniques.
hcxtools (that include hcxdumptool and hcxlabtool) are analysis tools working on unfiltered mass data (main purpose), e.g.:
https://hashcat.net/cap2hashcat/
https://wpa-sec.stanev.org/?
They are not designed to attack a single NETWORK or to recover a single PSK of a single NETWORK. However, they can do this using the right options, but purpose is to discover weak points within the entire system which are not not convered by other tools (eg.: PMKID attack, NONCE ERROR CORRECTION). This is only possible if you collect (and anylyze) thousands of packets.
Options may look similar to other tools, but the behavior is different. So please forget everything you read about this tools, because it will not(!) work as expected on hcxdumptool chain (hcxdumptool -> hcxpcapngtool -> hcxhashtool -> hcxpsktool -> hashcat).