hashcat Forum

Hi ZerBea

The information you provide in hcxhashtool --info= is awesome and so neatly laid out. Things are so clear when reading those outputted results.

Can I make a request please? When a handshake capture is made via "ROGUE attack" could you please make clear on the "MAC_AP.....:" that the AP MAC is spoofed? I appreciate it is obvious to any professional that the AP MAC has to be spoofed due to the nature of the attack.

However if users make their own scripts, or look for specific MACs or hardware at a later date, it can sometimes be confusing (I have hccap's named by the spoofed MAC). As users can also include the oui.txt file and have names resolved it might allow the users (who are not paying attention) to misunderstand the actual real devices around them.

Could you please make it so when a "ROGUE attack" is printed out in the info the line "MAC_AP.....:" shows it is spoofed.

Current output = MAC_AP.....: 50e24ad54a0a (unknown)

Desired output = MAC_AP.....: 50e24ad54a0a (hcx spoofed)

Cosmetic note: In my personal opinion "AP-Less" was a much better term than "ROGUE attack".


I also really like the "RC INFO....:" outputs and confirmation notices of whether or not NC Correction is required, you have done a fantastic job.

WPS
Can I make another suggestion for another test within hcx? Often an AP advertises that WPS in enabled and available. Obviously most modern AP's are no longer vulnerable to "reaver" type attacks but the user has to manually work through and test this out. Is it possible to automate a better test to see if the AP is actually responding to PIN attempts but without going through the entire process of trying to crack the PIN?

The idea is to produce an information report on AP's that do not just advertise WPS but actually respond (are vulnerable) to PIN attempts.

Thanks again for all you do with hcx.

I changed naming from AP-LESS to ROGUE ATTACK, because the attack vector isn't AP-LESS or CLIENT-LESS. Instead hcxdumptool will act as a "ROGUE" ACCESS POINT for a CLIENT and as a ROGUE CLIENT for an ACCESS POINT.
hcxdumptool's MAC addresses are not spoofed. Instead hcxdumptool collect received MACs and received ESSIDs and use them to let the CLIENTs connect to us. This include randomized MACs from ANDROID, APPLE, NetworkManager CLIENTs. At this point not even hcxdumptool knows if a MAC is a fake one or not - we are going stealth to prevent counter measures against us.

OK I understand about the ROGUE naming thank you.

How does hcxdumptool decide what MAC (BSSID) to use for an AP (ESSID) that a client is probing for if the real AP is not within range of the either the client or the penetration tester?

I assumed hcxdumptool just spoofed one.

I am guessing that the output from hcxhashtool --info= with regard to MAC addresses is not to be used for MAC tracing? I just thought that it was only the "ROGUE attack" AP MAC that was not genuine.

What do you think of the WPS test suggestion?

Thanks

We have an initial start value for MAC_AP and MAC_STA:


After we receive the first packet, hcxdumptool start to collect received MACs and use them.
Please notice: nearly all MACs from probing CLIENTs are randomized - MAC tracing doesn't make sense here.
If you really need real MACs, please use hcxpcapngtool --all option.
Now filter out PMKIDs and authenticated handshakes. They are received from "real" ACCESS POINTS and "real" CLIENTs.

WPS and WEP:
I talked with Atom about WPS (and WEP) and we decided not to add it.
WPS is reaver/bully/pixie-dust domain, because this tools can do it much better. Besides, hcxdumptool will have to stay a very long time on the same frequency to do this attack.

The same applies to WEP.
This is aircrack-ng domain, because this tools do it much better. Besides, hcxdumptool will have to stay a very long time on the same frequency to do this attack.

I'll put my focus on EAPOL, EAP and other Authentication Key Management (AKM) systems like SAE.
This attack vector need only a few packets before we switch the channel.

MACs
Thank you for your explanation. I will experiment with "hcxpcapngtool -all" following your advice. Good idea to also filter PMKID's and authenticated handshakes as they obviously are real MAC's.

WPS
I was not asking that you incorporate a WPS attack into hcxdumptool I just wanted a test for auditing routers, not to carry out a full WPS attack, just test if the router responds to PIN attempts.

hcxdumptool could try a few PIN's to see if the router is actually responding then for hcxdumptool to move on. The user can then use reaver or bully if they wish to pursue a WPS attack.

If you are concerned about the time taken on each AP perhaps this WPS vulnerability test could be an optional switch for the user?

I was hoping for a result in the hcxhashtool --info output something like...

WPS Version: 1 (or) 2
WPS Vulnerable: Yes (or) Not responding to PINs

If you still don't like the request I promise to stop going on about it

Thank you

No, because we have to stay much longer on the channel do do this.
Besides:
AUTHENTICATION REQUEST, AUTHENTICATION RESPONSE,
ASSOCIATION REQUEST, ASSOCIATIONREPONSE
(each of them followed by an ACKNOWLEGE packet)
we need the following EAP sequence, too:
EAP REQUEST IDENTITY, EAP RESPONSE IDENTITY,
EAP REQUEST M1, EAP RESPONSE M1,
EAP REQUEST M2, EAP RESPONSE M2,
EAP REQUEST M3, EAP RESPONSE M3,
EAP REQUEST M4, EAP RESPONSE M4,
EAP REQUEST M5, EAP RESPONSE M5,
EAP REQUEST M6, EAP RESPONSE M6,
EAP REQUEST M7, EAP RESPONSE M7,
EAP REQUEST M8, EAP RESPONSE M8,
EAP REQUEST DONE, EAP RESPONSE ACK
(each of them followed by an ACKNOWLEGE packet).

Please read more here:
https://ifconfig.dk/pixiedust/

Additional we have to calculate several NONCE and HASH values
https://en.wikipedia.org/wiki/Diffie%E2%...y_exchange

As long as hashcat doesn't have a hash mode to recover the keys from this key exchange, it doesn't make sense to add it to hcxdumptool.

Please notice that every modern router is hardened against pixie dust attack.

OK I understand, thank you for explaining.

Hi Zerbea, have noticed that sometimes proberesponse in terminal output window is not output to probelist past few weeks...but keep forgetting to copy the missing output.....finally did so today. seems the missing proberesponse contain dots (....). other proberesponses are output to probelist. as you can see 4 lines below contain dots (......) either fully or partly and are omited from output probelist.

Very well observed.
We don't want to flood the terminal with duplicated messages. So every combination AP - ESSID is only displayed once on first occurrence. Some CLIENTs randomize their MACs - that will cause that tons of messages are shown.

help will give you an information about this behavior:

(05-19-2020, 07:54 PM)ZerBea Wrote: [ -> ]Very well observed.
We don't want to flood the terminal with duplicated messages. So every combination AP - ESSID is only displayed once on first occurrence.  Some CLIENTs randomize their MACs - that will cause that tons of messages are shown.

help will give you an information about this behavior:

Code:

--enable_status=<digit>            : enable real-time display (waterfall)
                                    only incomming traffic
                                    only once at the first occurrence due to MAC randomization

thanks for the explanation zerbea. have a question on filtering.
--filterlist=list.txt --filtermode=3 seems to be not in use anymore from the help output. list.txt contains the ap & clients. what is the new filtering command to receive transmission of ap & client in the list and nothing else. i tried a few options but could not get as expected.