09-21-2022, 03:09 PM
(This post was last modified: 09-21-2022, 03:34 PM by CyberPentester.)
(09-21-2022, 08:50 AM)ZerBea Wrote: 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.
(09-21-2022, 08:50 AM)ZerBea Wrote: ".. 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
(09-21-2022, 08:50 AM)ZerBea Wrote: BTW:
stop_client_m2_attacks= 2 and the user doesn't notice that the device transmit the M2 to hcxdumptool
Good tip!