hcxtools - solution for capturing wlan traffic and conversion to hashcat formats

[ZerBea]

Hi faberC.
Shall we take the hashline and a wordlist as input to calculate and/or verify the PMK (CPU based only, for quick tests - Well, I promised Atom never to code a GPU cracker - and he promised me never to code a dumper/attacker )

in hashline:
PMKID*MAC_AP*MAC_STA*ESSID
in wordlist:
12345678
abcdefgh

out:
PMK*PMKID*MAC_AP*MAC_STA*ESSID : PSK

[wakawaka]

my old rtl8187l adaptor went dead, and i've been trying to get my rtl8812au adaptor working with latest The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) + latest hcxtools. sometimes I get error - network is down during a capture session and I have to start monitor mode again. anyone using rtl8812au can recommend the driver to install in The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali) ? I suspect its the driver as when my adaptor works I can capture for for an hour without errors (plus adaptor works fine in windows without issue)

picture of rtl8812au adaptor in link below
https://images-na.ssl-images-amazon.com/...SX425_.jpg

[ZerBea]

Please try this one:
https://github.com/kimocoder/rtl8812au

[wakawaka]

Please try this one:
https://github.com/kimocoder/rtl8812au

thanks ZerBea, having the same issue sometimes with that driver too. will format & install the latest weekly release of K.ali when I have time and retry.

[ZerBea]

Added iw functionality to hcxdumptool.
From now on hcxdumptool will set monitor mode and restore old interface settings when terminated. You do not need to run iw, ip, iwconfig, ifconfig any longer.
To check this functionality run iw dev <your interface> info

$ iw dev wlp39s0f3u4u5 info
output should be something like this:
Interface wlp39s0f3u4u5
ifindex 4
wdev 0x100000001
addr xx:xx:xx:xx:xx:xx
type managed
wiphy 1
txpower 20.00 dBm

Now run hcxdumptool:
$ sudo hcxdumptool -i wlp39s0f3u4u5 -o capture.pcapng -t 5 --enable_status=3
output should be something like this:
start capturing (stop with ctrl+c)
INTERFACE:...............: wlp39s0f3u4u5
FILTERLIST...............: 0 entries
MAC CLIENT...............: f0a225ccee18 (client)
MAC ACCESS POINT.........: e00db9a6c73b (start NIC)
EAPOL TIMEOUT............: 150000
REPLAYCOUNT..............: 64915
ANONCE...................: 60250eced10289aa05a7d2e2c6dfa991fd236020918235cb8f7bd57d40f1daa0

[10:46:44 - 001] xxxxxxxxxxxx -> f0a225ccee18 networkname [PROBERESPONSE, SEQUENCE 1315, AP CHANNEL 1]

Open second terminal and type this (while hcxdumptool is running in first terminal):
$ iw dev wlp39s0f3u4u5 info
output should be something like this:
Interface wlp39s0f3u4u5
ifindex 4
wdev 0x100000001
addr xx:xx:xx:xx:xx:xx
type monitor
wiphy 1
channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
txpower 20.00 dBm

Terminate hcxddumptool (Ctrl +c) and retrieve interface info
$ iw dev wlp39s0f3u4u5 info
output should be something like this:
Interface wlp39s0f3u4u5
ifindex 4
wdev 0x100000001
addr xx:xx:xx:xx:xx:xx
type managed
wiphy 1
txpower 20.00 dBm

Keep in mind:
hcxdumptool will not stop other services that takes access to the interface - you must do it!

[ZerBea]

It seems that hcxtools/hcxdumptool successfully ported to "Pineapple".
Read more here:
https://forums.hak5.org/topic/44213-pmki...ineapples/

[Mem5]

HI ZerBea,

What do you mean by:

hcxdumptool is able to prevent complete wlan traffic

Your tool send deauth packets in order to disconnect connected users?
So connected users need to connect again?

[ZerBea]

Hi Mem5.
Yes, hcxdumptool sends a few deauthentication messages. That's true.
But hcxdumptool also sends a disassociation after it has received an EAPOL 4/4 (M4) with reason code: WLAN_REASON_DISASSOC_AP_BUSY
In that case, the client must do the authentication again, until hcxdumptool receive an EAPOL 4/4 (M4)...
Also hcxdumptool will send its own EAPOL 1/4 (M1) to a client within a regular authentication. If the clients responds to this one instead of the access points EAPOL 1/4 (M1), he will never get an EAPOL 3/4 (M3).
Right now, hcxdumptool stops this attacks, if it received all necessary data from the client or the access point.
In other words: I we do not stop the attack, the client will never be able to connect to the access point.
I think about an "--infinity" switch (do not stop attack) to disable this behaviour.

[ZerBea]

hcxdumptool update:

added GPSD support (stored as comment in pcapng file)
--use_gpsd : use GPSD to retrieve position
add latitude, longitude and altitude to every pcapng frame

device must be supported by GPSD:
http://www.catb.org/gpsd/hardware.html
(tested using: AktivePilot JENTRO BT-GPS-8)

1. run GPSD
2. run hcxdumptool with option --use_gpsd
3. terminate hcxdumptool
4. retrieve GPS information from capture file with (order is changeable):
$ tshark -r filename.pcapng -Y frame.comment -T fields -E header=y -e frame.number -e frame.time -e wlan.sa -e frame.comment

Output should look like this
1 Sep 27, 2018 00:22:59.081914000 CEST xx:xx:xx:x:xx:xx lat:xx.xxxxxx,lon:y.yyyyyy,alt:z.z
2 Sep 27, 2018 00:22:59.343230000 CEST xx:xx:xx:x:xx:xx lat:xx.xxxxxx,lon:y.yyyyyy,alt:z.z
3 ...

[kiara]

hcxdumptool update:

added GPSD support (stored as comment in pcapng file)
--use_gpsd                         : use GPSD to retrieve position
                                    add latitude, longitude and altitude to every pcapng frame

device must be supported by GPSD:
http://www.catb.org/gpsd/hardware.html
(tested using: AktivePilot JENTRO BT-GPS-8)

1. run GPSD
2. run hcxdumptool with option --use_gpsd
3. terminate hcxdumptool
4. retrieve GPS information from capture file with (order is changeable):
$ tshark -r filename.pcapng -Y frame.comment -T fields -E header=y -e frame.number -e frame.time -e wlan.sa -e frame.comment

Output should look like this
1 Sep 27, 2018 00:22:59.081914000 CEST xx:xx:xx:x:xx:xx lat:xx.xxxxxx,lon:y.yyyyyy,alt:z.z
2 Sep 27, 2018 00:22:59.343230000 CEST xx:xx:xx:x:xx:xx lat:xx.xxxxxx,lon:y.yyyyyy,alt:z.z
3 ...

just to make sure i will explain what what app-less mean and what client-less mean. (if i am wrong correct me)


client less mean, that the router aka AP it self send a PKMID to whoever is trying to connect to it which is a eapol packet , so even if there is no client attached to the AP , u "as an attacker/pen test" aka hcxdumptool will try itself to connect to the ap to see if it send a pkmid. if it does it will show pkmid found. 
again , u will receive the pkmid ONLY when the ap is near by and vulnerable(by sending the pkmid)


ap-less mean, if a phone/pc/device do a probe request and in his prob request (broadcast request) there is a name  hcxdumptool will create an fake AP with the same ESSID so when the device see that AP it will try to connect to it, hcxdumptool then catch the handshake and close/turning off that fake AP .