Half Handshake Tools?

[ZerBea]

I removed the option mac_ap to set a default MAC_AP instead of a randomized one, because it was counterproductive.
It doesn't work if the CLIENT transmit directed PROBEREQUESTs.
It can cause ESSID mismatches if another ESSID using the same MAC is on air.

".. it responds to EVERY client authentication from EVERY AP, not just the ones setup by hcxdumptool itself."
That always happens if the CLIENT set a WILDCARD ESSID or a zeroed ESSID in his PROBEREQUESTs. In that case we must respond to the AUTHENTICATION REQUEST and the ASSOCIATIONREQUEST of the CLIENT the get the ESSID and some other information). And if we respond, not only the ESSID.

BTW:
hcxdumptool doing the same as a modern CLIENT (use WILDCARD ESSID and MAC randomization), when attacking an AP:

Code:

ACCESS POINT (ROGUE)......: 10b71301efb2 (BROADCAST WILDCARD used for the attack)

Using WILDCARD or zeroed ESSIDs and MAC randomization is a very effective way (used by default on modern devices) to prevent tracking. Unfortunately it also prevent to filter an unwanted CLIENT.

Authentication procedure:
Step 1
BC <- CLIENT : undirected PROBEREQUEST (ESSID not mandatory) BC_MAC = ffffffffffff
or
AP <- CLIENT : directed PROBEREQUEST (ESSID not mandatory)
AP -> CLIENT : PROBEREPSONSE (ESSID not mandatory - information about all possible AKM and CYPHER suites)

Step 2
AP <- CLIENT : AUTHENTICATION (no ESSID - request AUTHENTICATION system))
AP -> CLIENT : AUTHENTICATION (no ESSID - set AUTHENTICATION system)

Step 3
AP <- CLIENT : ASSOCIATIONREQUEST (ESSID mandatory, request AKM and CYPHER suite)

Step 4
AP -> CLIENT : ASSOCIATIONRESPONSE (no ESSID, set AKM and CYPHER suite that will be used )
AP -> CLIENT : M1 (challenge - unencrypted WPA information) must be transmitted immediately after the ASSOCIATIONRESPONSE
AP <- CLIENT : M2 (challenge - unencrypted WPA information)

Step 5
AP -> CLIENT : M3 (authorization - encrypted WPA information)
AP <- CLIENT : M4 (authorization - usually zeroed SNONCE)

In every case hcxdumptool must do step 1, step 2 and step 3 to get an accurate information on ESSID and AKM and CYPHER suite.
It will not do step 4, if the CLIENT MAC is in the filter list (option filterlist_client & --filtermode=2). Unfortunately, this kind of filtering only works if the CLIENT doesn't randomize its MAC.
It will not do step 5 (because we do not have the correct PSK).

Please note:
To avoid that the CLIENT spam a channel by his requests, we must respond to stop that behavior!

At the moment, I (and many companies that provide tracking tools) found no way to identify and protect a MAC randomized CLIENT.
https://www.techrepublic.com/article/how...ndroid-10/


BTW:
stop_client_m2_attacks= 2 and the user doesn't notice that the device transmit the M2 to hcxdumptool

[CyberPentester]

I removed the option mac_ap to set a default MAC_AP instead of a randomized one, because it was counterproductive.

It doesn't work if the CLIENT transmit directed PROBEREQUESTs.

It can cause ESSID mismatches if another ESSID using the same MAC is on air.

Hmm, I don't really understand this because in the hcxdumptool status output I see many different MAC_SOURCE starting with "000da7864fXX", and I do not know which one will belong to the rogue AP the tool hosts, so I cannot filter by a single MAC_AP with --filterlist and --filtermode=2.

EDIT: I noticed that the BROADCAST WILDCARD changes every time hcxdumptool is run, so I cannot filter for that either. The only way would be for me to specify the MAC_AP I want, but I cannot do that. I feel like this should be brought back.

".. it responds to EVERY client authentication from EVERY AP, not just the ones setup by hcxdumptool itself."

That always happens if the CLIENT set a WILDCARD ESSID or a zeroed ESSID in his PROBEREQUESTs. In that case we must respond to the AUTHENTICATION REQUEST and the ASSOCIATIONREQUEST of the CLIENT the get the ESSID and some other information). And if we respond, not only the ESSID.



BTW:

hcxdumptool doing the same as a modern CLIENT (use WILDCARD ESSID and MAC randomization), when attacking an AP:

Code:

ACCESS POINT (ROGUE)......: 10b71301efb2 (BROADCAST WILDCARD used for the attack)

I am not sure I follow. The issue I am having is that hcxdumptool is acting as other ESSIDs that are NOT specified in essidlist.txt. I see something like this in the status:
<CLIENT_MAC>  <HCX_MAC_000da7864fc5>  <ESSID_NOTINLIST>  [ROGUE PROBERESPONSE]

<CLIENT_MAC>  <HCX_MAC_000da7864fc5>  <ESSID_NOTINLIST>  [AUTHENTICATION]
<CLIENT_MAC>  <HCX_MAC_000da7864fc5>  <ESSID_NOTINLIST>  [REASSOCIATION]
<CLIENT_MAC>  <HCX_MAC_000da7864fc5>  <ESSID_NOTINLIST>  [EAPOL:M1M2ROGUE EAPOLTIME:2214 RC:62503 KDV:2]

And this is another case where the ESSID is not in essidlist.txt either:
<CLIENT_MAC>  <HCX_MAC_000da7864fce>  <OTHERESSID_NOTINLIST>  [AUTHENTICATION]
<CLIENT_MAC>  <HCX_MAC_000da7864fce>  <OTHERESSID_NOTINLIST>  [ASSOCIATION]
<CLIENT_MAC>  <HCX_MAC_000da7864fce>  <OTHERESSID_NOTINLIST>  [EAPOL:M1M2ROGUE EAPOLTIME:151 RC:62503 KDV:2]

As far as I understand these two examples are not WILDCARD requests. It seems to me that they are targeted towards a particular ESSID (<ESSID_NOTINLIST> and <OTHERESSID_NOTINLIST>), so I don't understand why hcxdumptool is "creating" these fake APs from all probe requests in the area and responding to obtain the M1M2 challenge when I only want it to create and respond to the ones I specified in the essidlist.

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".

So is what am trying to achieve possible at all because of how the protocols work? Or is simply not possible within hcxdumptool

BTW:

stop_client_m2_attacks= 2 and the user doesn't notice that the device transmit the M2 to hcxdumptool

Good tip!

[ZerBea]

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.

"As far as I understand these two examples are not WILDCARD requests. It seems to me that they are targeted towards a particular ESSID (<ESSID_NOTINLIST> and <OTHERESSID_NOTINLIST>), so I don't understand why hcxdumptool is "creating" these fake APs from all probe requests in the area and responding to obtain the M1M2 challenge when I only want it to create and respond to the ones I specified in the essidlist."
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""

You haven't set a target (CLIENT) filter list and hcxdumptool guess that you want to attack everything. If you don't want that behavior, set filterlist_client and filter mode 2:

Code:

--filterlist_client=<file or MAC>  : CLIENT MAC or MAC filter list
                                     format: 112233445566, 11:22:33:44:55:66, 11-22-33-44-55-66 # comment
                                     maximum entries 256
                                     due to MAC randomization of the CLIENT, it does not always work!

You can choose 256 CLIENT targets:

Code:

$ sudo hcxdumptool -i INTERFACE -c 1 --disable_ap_attacks --disable_deauthentication --essidlist=essidlist.txt --active_beacon --stop_client_m2_attacks=1000 --filterlist_client=attackmacclients.txt --filtermode=2 -o dump.pcapng --enable_status=31

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

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. Otherwise the target disregard/ignore it.
To ensure that (and I'm counting CPU cycles), 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).
Please notice:
It takes several CPU cycles until the packet find its way from the antenna through the device (firmware) and through the driver (kernel) until it reached hcxdumptool.
Once it reached the user space, hcxdumptool must handle the radiotap header and detect the kind of the frame before it decide how to respond to it and to create a response packet). All this have a price tag, counted in CPU cycles. If the response packet is created, it has to go the way back (driver -> device firmware -> antenna). All this must happen before the packet response timeout is reached.

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

[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

[ZerBea]

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:

Code:

network={
    ssid="NAME-OF-YOUR-NETWORK"
    psk="PASSWORD"
    proto=RSN
    key_mgmt=WPA-PSK
    pairwise=CCMP TKIP
    group=CCMP TKIP
}

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).