I have a question about the -E argument, where some essids and other words (plain or hex) are dumped.
What could be it used for?
BTW. How long do people let the hcxdumptool be running for? Till you capture the essids you are looking for? Or is any other interesting information captured on a longer run?
Cheers
Thanks a lot. still have to learn about the basics of hashcat, but how do you feed hashcat with the essidlist? as a simple worldlist?
what kind of info is inside the -E file?
-E, -I and -U collecting data from the WLAN traffic and store them as ASCII text files. The idea is to use this lists as wordlists for hashcat.
For example, if a user confused something when he types password and ESSID the password will be transmitted in the clear. -I will give us some IMEIs (many mobile router use part of the IMEI as password) and -U some usernames. There are many, many examples like this...
New results will be added to existing ones. So it's a good idea to run this lists (they will grow, soon and your results are going to get better and better) against you latest captures from time to time.
... but how do you feed hashcat with the essidlist?
simply run this commands:
$ hcxpcaptool -E prlist -o test.hccapx test.cap
$ hashcat -m 2500 test.hccapx prlist
....ok it isn't so simple:
hcxdumptool requests identities and usernames and forces a client to probe and to do many things he doesn't want to do.
It acts as an access point for a client (ap-less attack vector to force probes and to do authentications, associations and request M2 EAPOL frames) and as a client for an access point (client less attack vector to request M1 EAPOL frames - they contain the PMKID).
You can improve the lists, running hcxwltool on them and feed this result to hashcat.
Or find out if password is part of the ESSID, running hcxpsktool and feed the result to hashcat.
Thanks for the explanation, very instructive, and a reason to go deeper using hcxtools.
I'll follow your indications and report my experience.
Thanks. for the moment -U -I don't return nothing on my captures, and -E gives Essid names, some HEX[xxxxxxxxxxxxx] and some random words and numbers, I'm using it as wordlist with rules combined but no match for the moment.
BTW I'm using HCXPCAPtool to convert to file.16800, is that ok?
that's the content of the -E
https://paste.hashkiller.co.uk/nyQFZj6y
cheers.
Running hcxpcaptool to convert EAPOL (-o) and PMKID (-k or -z) is fine.
The content of -E is very interesting, because we can find several passwords (PSK) inside. You should know, that
hcxdumptool captures more(!) PSKs than handshakes. So it may take a while until you get a matching handshake or a PMKID for an allready captured PSK. So it's a good idea to collect them and test them from time to time against your captured files.
To get a PSK, we only need one(!) packet (2 if we request it).
To get a PMKID, we need at least 2 packets (ESSID and M1). To request a PMKID, we need 14 packets (inclusive ack packets).
To get a handshake we need at least 3 packets (ESSID, M1, M2 or M2, M3, or if M4 is not zeroed, M1, M4 or M3, M4). To request an M2 from a client, we need 16 packets (inclusive ack packets).
Will say, if the client (or you) moving fast, it is possible that the complete authentication process fails and we get nothing.
-U is only usefull if your captured file contains HTTP traffic:
hcxdumptool -O
-O <dump file> : output file in pcapng format
unencrypted IPv4 and IPv6 frames
-I will give you identities (for example not encrypted IMEIs).
BTW:
Your "Test -E ESSID" contain some nice default key space PSKs:
lines 12, 53, 54, 70, 71, 72, 171, 179, 292
and some possible user defined PSKs like this ones:
lines 70, 321
All of them came from clients.
You can imagine, how much time hashcat will take to brute force a PSK like this one from line 53/54 (20 characters aZAZ09).
Will say, traffic from a client is a thousand times more interesting than stupid beacons from access points.
BTW:
To get the MAC of the client which use the 20 character PSK, run hcxpcaptool -X option.
This option is very useful for a penetration tester to identify a weak client within a company WiFi network.
@penetration testers: you can imagine, what will happen, if the PSK is not from the company WiFi network, but instead it is from the users WiFi network and the user is allowed to do "home office".....
hcxdumptool / hcxtools is designed to perform heavy attacks and to enable deep analysis of network traffic in combination with hashcat and JtR. Goal is to identify weak points or break the system not a single network in the neighborhood.
(06-04-2019, 08:18 AM)ZerBea Wrote: [ -> ]BTW:
Your "Test -E ESSID" contain some nice default key space PSKs:
lines 12, 53, 54, 70, 71, 72, 171, 179, 292
and some possible user defined PSKs like this ones:
lines 70, 321
All of them came from clients.
Thanks a lot again, but those PSKs are written by users as the access to the WLANs? what you explain to me is that they could come from other WLANs not captured on the .16800 file?
BTW what about the lines tagged with $HEX ?
the computer was capturing for more than 3 hours, so definitely would be super efficient to at least get a right PSK instead trying to bruteforce the AP.
Im considering running HCXDUMPTOOL with a couple of antennas to have more chances of capturing traffic.
hcxpcaptool doing hexify in the same way like hashcat. If we have non ASCII characters inside the traffic, we do a conversion to HEX-ASCII, too. hashcat understand this and will try this values as PSK.
We are doing this to make sure we don't loose a possible PSK.
For example lines 1/2 of your Test -E ESSID. That could be an ESSID, a PSK (EMOJI, UTF-8, or something else). We are doing a $HEX[....] and a hexify to HEX-ASCII. hashcat will test 2 different PSKs in this case.
"...but those PSKs are written by users as the access to the WLANs"
Not at all, some of them came from IOT devices.
"what you explain to me is that they could come from other WLANs not captured on the .16800 file"
Yes. And you will get better results, if you run the -E and -I lists against EAPOL (hash mode 2500), because you
get more information from a client than from an access point.
That always happens when you capture the PSK from a client and the client attempt to connect to hcxdumptool (ap-less attack). In other words, there is no need to hunt for an access point. Just wait for the client to come to you.
BTW:
3 hours isn't enough. You should consider 24/7 to get really all clients in range. Running hcxdumptool over a long(er) time on a place, where you expect many clients is a good idea. The more clients, the better results.