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

[ZerBea]

shortly before final release of hcxtools 4.0.0 I decided to add a new tool: wlanhcx2psk
wlanhcx2psk calculates weak password candidates for hashcat based on opensource intelligence data found in the hccapx file. There are no reverse engineered or vendor specific algorithms inside.

Usage is very simple:

The slow way:
$ wlanhcx2psk -s -i hashfile.hccapx | hashcat -m 2500 hashfile.hccapx

The fast way:
$ wlanhcx2psk -o candidates -i hashfile.hccapx
$ sort candidates | uniq > candidates.srt
$ hashcat -m 2500 hashfile.hccapx candidates.srt

[ZerBea]

small update wlanhcx2psk
added option (-W) to test if a wpskey is used as psk
added options (-D -d) to test if a date (eu or us) is used as psk

$ wlanhcx2psk -h
wlanhcx2psk 4.0.0-rc2 (C) 2017 ZeroBeat
usage..: wlanhcx2psk <options>
example: wlanhcx2psk -i <hccapx> -W -s | hashcat -m 2500 <hccapx>

options:
-i <file> : input hccapx file
-o <file> : output plainkeys to file
-s        : output plainkeys to stdout (pipe to hashcat)
-W        : include wps keys
-D        : include european date
-d        : include american date
-h        : this help
-v        : version



To improve the tool, let us know if you have some hits, please.

[ZerBea]

some background informations about wlanhcx2psk:

wlanhcx2psk is a dynamic tool (so look for latest hcxtools updates on git). It doesn't calculate a matching candidate
(if you need matching candidates use routerkeygenPC). Instead it creates a range of candidates
- given by the ESSID and
- analyses of real candidates from http://wpa-sec.stanev.org/?nets

Depending on the
- number of networks found in the hccapx file,
- the length of an ESSID and
- the selected options
output can be something between 20000 and real big (> 50000000 candidates)!

You can help by submitting your capfiles to http://wpa-sec.stanev.org/?nets
in the following ways:
- submit your uncleaned raw cap to http://wpa-sec.stanev.org/?submit
- or pre-clean and submit the cap using:
 $ wlancap2hcx -p precleaned.cap *.cap
 (data frames, IPv4 or IPv6 frames extended EAPOL frames and some management frames are stripped out)
- or complete clean the cap:
 $ wlancap2hcx -o test.hccapx *.cap
 $ wlanhcx2cap -i test.hccapx -o wpasec
 (single cap files containing only 1 handshake each mac_sta(!), please do not use -O option)
 $ wlancap2wpasec wpasec*.cap

You can also convert your uncracked hccapx files back to cap and submit this cap:
 $ wlanhcx2cap -i youruncracked.hccapx -o myuncracked
 (single cap files containing only 1 handshake each mac_sta(!), please do not use -O option)
 $ wlancap2wpasec myuncracked*.cap


As "bonus" you can download a list of found candidates (updated whenever a new candidate was found) direct from here:
http://wpa-sec.stanev.org/dict/cracked.txt.gz

The pre-clean option (wlancap2hcx -p) is also 100% compatible to cap2hccapx.
But keep in mind: a (pre-)cleaned cap is useless for analysis purpose!!!!

[MrShannon]

Hi ZerBea! Thank you for publishing all of this, it's fantastic. I've been using wlanresponse on a pi0 with the gpio button/led, and it's working great.

Is it possible to add a command line switch to determine which tactics to use, or not use? For example, I would like to prevent wlanresponse and wlandump-ng from using deauth and instead only listen for probe requests and stand up those SSID's for capture. I'm interested in a sort of "passive" behavior, collecting the handshakes of clients that are looking for networks, not kicking them off of ones they are already connected to.

Thanks again!

[ZerBea]

Hi MrShannon.
Thank's. Nice that you like this little wifi-toys.
All functions you asked for (and much more) are allready implemented:

1. case:
"I would like to prevent wlanresponse and wlandump-ng from using deauth and instead only listen for probe requests and stand up those SSID's for capture."
use option -p and wlandump-ng doesn't transmit
example:
wlandump-ng -i <device> -o capname.cap -c 1 -t 5 -m 1024 -s 20 -p

2. case:
"I'm interested in a sort of "passive" behavior, collecting the handshakes of clients that are looking for networks, not kicking them off of ones they are already connected to."
example:
wlandump-ng -i wlp3s0f0u1 -o capname.cap -c 1 -t 60 -m 1024 -s 20 -r -d 10000000 -D 1000000
use option -d and -D with high values and set option -r to reset the counters if channel 1 reached
you can also set option -b to activate beaconing.
But keep in mind:
Clients in connection with an ap also sending proberesponses and they are trying to connect us

3. case:
"I'm only interested in special BSSIDs"
use option -F (soft coded Berkeley Packet Filter)
wlandump-ng -i wlp3s0f0u1 -o capname.cap -F myfilterfile -c 1 -t 60 -m 1024 -s 20 -r -d 10000000 -D 1000000

myfilterfile is a text file containing valid wireshark/tcpdump filters (use your favorite wireshark filters).
example 1:
(wlan host 11:22:33:44:55:66 || wlan src aa:bb:cc:dd:ee:ff)
only this BSSID 11:22:33:44:55:66 in connection with this client  aa:bb:cc:dd:ee:ff is under attack

example 2:
!(wlan host 11:22:33:44:55:66 || wlan src aa:bb:cc:dd:ee:ff)
everything is under attack, except of this BSSID 11:22:33:44:55:66 in connection with this client  aa:bb:cc:dd:ee:ff

All combinations of all switches are possible.
Using this combinations, you are able either to use wlandump-ng as a surgeon uses his scalpel or as a conqueror uses an area weapon.


But it's not possible to implement "a single tactics option switch". Just play around and use different combinations and put your favourit options into a simple bashscript (example for different scenarios: raspberry pi root .bash_profile).
‎
#!/bin/bash

cd /home
export WLANDEV=`ls -1 /sys/class/net | grep ^wl`
if [[ ! -z $WLANDEV ]]
then
    ARCHIVNAME=`date +'%Y%m%d%H%M'`
    ip link set $WLANDEV down
    iw dev $WLANDEV set type monitor
    ip link set $WLANDEV up
    wlanresponse -i $WLANDEV -o $ARCHIVNAME.cap -t 3 -b
#    wlanresponse -i $WLANDEV -o $ARCHIVNAME.cap -t 43200 -b
#    wlanresponse -i $WLANDEV -o $ARCHIVNAME.cap -t 86400 -b
#    wlandump-ng -i $WLANDEV -o $ARCHIVNAME.cap -c 1 -t 600 -d 1000000 -D 100000 -m 512 -b -r -s 0
#    wlandump-ng -i $WLANDEV -o $ARCHIVNAME.cap -c 1 -t 4 -d 20 -D 2 -m 128 -b -r -s 0
fi
pioff &
systemctl start dhcpcd@eth0.service

‎This is the most (more than mdk3 can do) brutal mode for mobile and portable operations:
wlanresponse -i $WLANDEV -o $ARCHIVNAME.cap -t 3 -b

This is a friendly, stationary mode:
wlandump-ng -i $WLANDEV -o $ARCHIVNAME.cap -c 1 -t 600 -d 1000000 -D 100000 -m 512 -b -r -s 0
in this cases option -F is not used, because I'm using the "hard coded Berkeley Packet Filter"

For all UBUNTU users:
Do not try to use this .bash_profile. It will not work for you because UBUNTU is known to start "hundreds" of unneeded services that prevents wlandump-ng/wlanresponse to do their" work". wlandump-ng/wlanresponse needs full access to the device, so you must identify and stop them:

for example this two:
systemctl stop NetworkManager.service
systemctl stop wpa_supplicant.service


Cheers

[winxp5421]

ZerBea,

Is it possible to have Wlanresponse or wlandump-ng only capture handshakes once (or twice) instead of potentially hundreds of times. IE. captured handshake from (station or AP) mac aaAA.BBbb.ccCC with SSID: 'Land Of sweets' on the next loop leave (AP or Station looking for) SSID: 'Land Of sweets' alone ( we already have a captured handshake )

I understand that grabbing multiple handshakes of the same PSK is beneficial to guaranteeing at least one is a good crackable handshake but, cracking a hcx file with a few thousand handshakes where you may only have 30-40 unique SSID's is painful at times. Plus its noisy messing with the same client again and again.

[ZerBea]

Hi winxp5421.
No, automatically it is not possible (an automatic often fails). The only way to prevent this behavior is ‎"manual intervention". By using the corresponding switches for your operation area and scenario, wlandump-ng does what you want.
Use wlanresponse ‎in fast moving operations.

To have a quick reaction time the capture/authentication engine is client oriented (all other cracking tools are accesspoint oriented).  In a worst case scenario, you can have at least 3 different mac_ap for one real network:
If we received a beacon 'Land Of sweets', both tools use this mac_ap.
If the client transmits  undirected probes, both tools generates a ranom mac_ap on 'Land Of sweets'
If the client transmits directed probes, both tools use this mac_ap on 'Land Of sweets'
So it is possible that you have every loop leave a different constellation of mac_ap - mac_sta - ESSID.

If a client asks for an M1 key, both tools must answer immediately without checking older entries in a buffer.
ap  <-  client: associationrequest
ap  ->  client: acknowledge  (client knows that the ap received his packets and needs some time to calculate the answer)
          (at this point, we must be faster than than the ap and answer in the gap between ap ack and ap M1)
ap  ->  client:  M1
          (at this point, we have the last chance to answer)
ap  <-  client: acknowledge  (ap knows that the client received his packets and needs some time to calculate the answer)
ap  <-  client:  M2
ap  ->  client: acknowledge  (client knows that the ap received his packets and needs some time to calculate the answer)
ap  ->  client:  M3
ap  <-  client: acknowledge  (ap knows that the client received his packets and needs some time to calculate the answer)
ap  <-  client:  M4

For us (wd) it is not neccessary to receive the ap!!!
ap  <-  client: associationrequest
wd  ->  client: acknowledge  (client knows that the ap received his packets and needs some time to calculate the answer)
wd  ->  client:  M1
wd  <-  client: acknowledge  (ap knows that the client received his packets and needs some time to calculate the answer)
wd  <-  client:  M2
ap  <-  client: acknowledge  (ap knows that the client received his packets and needs some time to calculate the answer)
ap  <-  client:  M4
In this case we have a 100% valid, authenticated and verified 4-way handshake exchange!



If you read the status display you'll see that captured handshakes are not a direct result of deauthentications/disassociations (if you use high values in -d and -D). The stupid clients follows us to ‎establish a connection (an ugly weakpoint in ‎the implementation of the 802.11 protocol on the clients).
And for us, ..... well, it's much faster to answer them everytime they asks, than to check if we allready answered them.
Some words about the noise: In this case, neither a client, nor an ap is able to detect us.
We are only detectable if we transmit to much deauthentications/disassociations!

Keep in mind: hcxtools are designed to provide only one function each tool
- wlandump-ng/wlanresponse -> capture traffic
- wlancapinfo and wlanhcxinfo -> analysis
- wlancap2hcx -> convert to hccapx
- wlanhcx2ssid -> select what you want for output
they are also designed to retrieve mass data for analyse purpose (we found some real sad weakpoints in 802.11)

Conclusion:
To reduce noise, you must set the corresponding option (use less deauthentications/disassociations options -d -D, set option -r to reset the deauthentication-/disassociation counter, use option -F Berkeley Packet Filter).
To identify the handshake you want to crack, you must analyse either the cap file or the hccapx file (or filter by cascading wlanhcx2ssid).
Then you can strip the handshakes you want to crack.

Cheers
Mike

[winxp5421]

Zerba,

Thanks for the detailed response. Can't thank you enough for the work you have done.

It makes sense to grab as much as you can as quickly as you can ( and I love it! ) I was just inquiring if there was a way to have hcxtools limit how many times we "play" with a specific client which you have answered. I will just handle splitting duplicates out during the "post-attack" process. Again thanks!

winxp

[ZerBea]

hi winxp (did you received my mail?)

Well, it's hard to understand the aim, because hcxtools are completely different in both function and design, compared to other tools (I need this functions and that was the main reason for me to start this project several years ago).
We need thousands of handshakes (from a client) to find one single exception. And we found many of this exceptions.
For example the relationship between replaycount and increasing the anonce (result was the implementation of nonce-error-corrections to hashcat).
We found the zeroed plainmasterkey (result was the implementation of hashmode -m 2501 in hashcat).
We found plainmasterkeys which are not(!) calculated using PBKDF2 (you need  hashmode -m 2501 - you can't crack them using -m 2500).
We found some "group keys" which are installed instead of a pairwise key (this has nothing to do with KRACK!!!!).
We found "half or incomplete passwords" from which you can calculate the complete password.
and more...

Cheers

[winxp5421]

Zerbea, No I have not received any mail from you. I just got done searching my mailbox. I sent you an email via Hashcat.net's Email function to see if this site function is actually working. If you did not receive an email feel free to contact me directly.

<my hashcat.net username>@gmail.com
<my hashcat.net username>@hotmail.com
keybase.io/winxp5421