hcxtools - solution for capturing wlan traffic and conversion to hashcat formats
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.
Reply
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.
Reply
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
Reply
We have an initial start value for MAC_AP and MAC_STA:

Code:
$ sudo hcxdumptool -i wlp39s0f3u3u1u2
initialization...

start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE........: N/A
INTERFACE NAME............: wlp39s0f3u3u1u2
INTERFACE HARDWARE MAC....: 74da38f2038f
DRIVER....................: mt7601u
DRIVER VERSION............: 5.6.11-arch1-1
DRIVER FIRMWARE VERSION...: N/A
ERRORMAX..................: 100 errors
BPF code blocks...........: 0
FILTERLIST ACCESS POINT...: 0 entries
FILTERLIST CLIENT.........: 0 entries
FILTERMODE................: unused
WEAK CANDIDATE............: 12345678
ESSID list................: 0 entries
ROGUE (ACCESS POINT)......: 580943e645ac (BROADCAST HIDDEN)
ROGUE (ACCESS POINT)......: 5809430045ad (BROADCAST OPEN)
ROGUE (ACCESS POINT)......: 580943e645ae (incremented on every new client)
ROGUE (CLIENT)............: d85dfb191ce1
EAPOLTIMEOUT..............: 20000 usec
REPLAYCOUNT...............: 61908
ANONCE....................: d7777e471a712f6a3078e200ccad66f1be031e233b4b952a0a22091e91f23a35
SNONCE....................: 51c535657193024054db65b16e9d6dbde8bcc9b7146a35c5a2ec2255cc7764f8

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.
Reply
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 Smile

Thank you
Reply
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.
Reply
OK I understand, thank you for explaining.
Reply
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.

Code:
phy1    wlan1          rt2800usb      Ralink Technology, Corp. RT2870/RT3070

hcxdumptool 6.0.5-12-geb8fe76 (C) 2020 ZeroBeat

15:24:05  10 88f7bfxxxxxx cc32e5xxxxxx Hxxxxxx [PROBERESPONSE]
15:24:10  11 ffffffffffff d667d3xxxxxx .................. [BEACON]
15:24:12  11 76981xxxxxxx d667d3xxxxxx .................. [PROBERESPONSE]
15:24:14  11 20395xxxxxxx 34e89xxxxxxx jxxxxxxxxxx [PROBERESPONSE]

16:59:36  11 f832exxxxxxx 78f94xxxxxxx ixxxxxxxxx [ROGUE PROBERESPONSE]
16:59:36  11 ffffffffffff d0fa1xxxxxxx 360...............-7ACD [BEACON]
16:59:39  11 fe01cxxxxxxx d0fa1xxxxxxx 360...............-7ACD [PROBERESPONSE]

22:20:00  10 ERROR:0 INCOMING:1047239 OUTGOING:16311 PMKIDROGUE:3 PMKID:0 M1M2ROGUE:5 M1M2:7 M2M3:5 M3M4:0 M3M4ZEROED:6 GPS:0
Reply
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
Reply
(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.
Reply