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

[ZerBea]

Are you running an old version? That was fixed by this commit on 27th of January 2022:
https://github.com/ZerBea/hcxdumptool/pu...b2d99a1cae

Code:

$ hcxdumptool -h
hcxdumptool 6.2.5-58-g121c620  (C) 2021 ZeroBeat
usage  : hcxdumptool <options>
         press ctrl+c to terminate hcxdumptool
         press GPIO button to terminate hcxdumptool
         hardware modification is necessary, read more:
         https://github.com/ZerBea/hcxdumptool/tree/master/docs
         do not set monitor mode by third party tools (iwconfig, iw, airmon-ng)
         do not run hcxdumptool on logical (NETLINK) interfaces (monx, wlanxmon, prismx, ...) created by airmon-ng and iw
         do not run hcxdumptool on virtual machines or emulators
         do not run hcxdumptool in combination with tools (channel hopper), that take access to the interface (except: tshark, wireshark, tcpdump)
         do not use tools like macchanger, because hcxdumptool runs its own MAC space and will ignore this changes
         stop all services (e.g.: wpa_supplicant.service, NetworkManager.service) that take access to the interface

short options:
...

Please notice that hcxdumptool/hcxlabtool/hcxtools is not suitable for beginners. From README.md:
- knowledge of radio technology
- knowledge of electromagnetic-wave engineering
- detailed knowledge of 802.11 protocol
- detailed knowledge of key derivation functions
- detailed knowledge of Linux

Regarding this, the default settings are less weird. On other tools you have to enable the attack modes, here you have to disable them. By default, hcxdumptool will request EAP frames from the target in a very short time so that it can be terminated after a few minutes.

BTW:
There are (much) better ways to get an EAPOL M2 frame (the most important frame, because it is unencrypted!) from a CLIENT or a PMKID from an ACCESS POINT than injection stupid DEAUTHENTICATION frames. So there is an option to disable this old school attack:

Code:

--disable_deauthentication         : do not send deauthentication or disassociation frames
                                     affected: conntected clients

Additional, you can choose several other options to disable every single attack and/or to use BPF code, so that the behavior will turn from noisy (aggressive as hell) to silent.

If you are interested in this 802.11 stuff and to take a closer look behind the scenes, I recommend to read:

Code:

802.11 Wireless Networks: The Definitive Guide, O'Reilly, April 2002

Chapter "4.4.1 Frames Classes" is very interesting. Often the reaction of an ACCESS POINT is violent after it received an unexpected class 3 frame or class 2 frame outside the actual authentication state. In that case the ACCESS POINT (not hcxdumptool) will disconnect all(!) connected CLIENTs immediately.

[hashserious]

"In that case the ACCESS POINT (not hcxdumptool) will disconnect all(!) connected CLIENTs immediately. "
That's the thing. Running the hcxdumptool in default settings is pretty big violation against everyone around you(and i'm not even talking about the law here). I ran this for some minutes and everyone started complaining(plus i saw on my own comps) the wifi is not working.
Also, --disable_deauthentication doesn't seem to work. It still throws off everyone off their nets, sooner or later(2 mins).
Wait, what's the "hardware modification is necessary"? You mean the usual networkmanager wpa_supplicant + if on raspbi conf etc?
P.S. Oh, the missing "p" is there now.
P.P.S. The book from 2002?

[ZerBea]

"Running the hcxdumptool in default settings is pretty big violation against everyone around you (and i'm not even talking about the law here)."
I fully agree. In every thread, in every comment in every post, in --help and in README.md I mention that this tools are not designed to be used by beginners!

Code:

Warning
--------------
hcxdumptool is designed to be an analysis tool. This means that everything is requested/stored by default. Unwanted information must be filtered out later on, offline!
You must use hcxdumptool only on networks you have permission to do this, because:
* hcxdumptool is able to prevent complete wlan traffic
  (depend on selected options)
* hcxdumptool is able to capture PMKIDs from access points (only one single PMKID from an access point required)
  (use hcxpcapngtool to convert them to a format hashcat and/Or JtR understand)
* hcxdumptool is able to capture handshakes from not connected clients (only one single M2 from the client is required)
  (use hcxpcapngtool to convert them to a format hashcat and/Or JtR understand)
* hcxdumptool is able to capture handshakes from 5/6GHz clients on 2.4GHz (only one single M2 from the client is required)
  (use hcxpcapngtool to to a format hashcat and/Or JtR understand)
* hcxdumptool is able to capture passwords from the wlan traffic
  (use hcxpcapngtool -E to save them to file, together with networknames)
* hcxdumptool is able to request and capture extended EAPOL (RADIUS, GSM-SIM, WPS)
  (hcxpcapngtool will show you information about them)
* hcxdumptool is able to capture identities from the wlan traffic
  (for example: request IMSI numbers from mobile phones - use hcxpcapngtool -I to save them to file)
* hcxdumptool is able to capture usernames from the wlan traffic
  (for example: user name of a server authentication - use hcxpcapngtool -U to save them to file)
* Do not use a logical interface and leave the physical interface in managed mode
* Do not use hcxdumptool in combination with aircrack-ng, reaver, bully or other tools which take access to the interface
* Stop all services which take access to the physical interface (NetworkManager, wpa_supplicant,...)
* Do not use tools like macchanger, as they are useless, because hcxdumptool uses its own random mac address space

and:

Code:

Requirements
--------------
* knowledge of radio technology
* knowledge of electromagnetic-wave engineering
* detailed knowledge of 802.11 protocol
* detailed knowledge of key derivation functions
* detailed knowledge of Linux

If you decide to use hcxdumptool or hcxtools it is mandatory that you know what you are doing and to learn 802.11.
Also it is mandatory to read (and understand) README.md and --help before(!) you use hcxdumptool.
Unfortunately, no one seems to be reading this.

Everything is explained, e.g. the hardware modification (from help menu):

Code:

press GPIO button to terminate hcxdumptool
hardware modification is necessary, read more:
https://github.com/ZerBea/hcxdumptool/tree/master/docs

It is not "the usual networkmanager wpa_supplicant + if on raspbi conf etc".

This also is mentioned in README.md

Code:

GPIO hardware mod recommended (push button and LED) on Raspberry Pi

If you choose option "--disable_deauthentication" hcxdumptool will not transmit DEAUTHENTICATION or DISASSOCIATION frames, because it is a stupid old school attack. To verify this, run Wireshark in parallel to monitor the traffic.
Please notice:
This option only disable injecting (stupid) DEAUTHENTICATION frames. There are better (and more effective ways) attack vectors.
DEAUTHENTICATION attack us useless if MFP is activated. It is also useless if DATA frames are transmitted and ACKed.
And it can be detected by e.g. hcxpcapngtool

Code:

Warning: too many deauthentication/disassociation frames detected!
That can cause that an ACCESS POINT change channel, reset EAPOL TIMER,
renew ANONCE and set PMKID to zero.
This could prevent to calculate a valid EAPOL MESSAGE PAIR
or to get a valid PMKID.

or

Code:

Warning: excessive number of deauthentication/disassociation frames detected!
That can cause that an ACCESS POINT change channel, reset EAPOL TIMER,
renew ANONCE and set PMKID to zero.
This could prevent to calculate a valid EAPOL MESSAGE PAIR
or to get a valid PMKID.

If you do not want to attack APs:

Code:

--disable_ap_attacks: do not attack access points
affected: connected clients and client-less (PMKID) attack

If you don't want to attack CLIENTs:

Code:

--disable_client_attacks: do not attack clients
affected: ap-less (EAPOL 2/4 - M2) attack

Run as passive dumper:

Code:

$ hcxdumptool -i INTERFACE --enable_status=95 --silent

will not throw off everyone

Get information about the target:

Code:

$ hcxdumptool -i INTERFACE --do_rcascan

will not throw off everyone

Various filter options to select the target or to protect devices:

Code:

--bpfc=<file> : input kernel space Berkeley Packet Filter (BPF) code
affected: incoming and outgoing traffic - that include rca scan
steps to create a BPF (it only has to be done once):
set hcxdumptool monitormode
$ hcxdumptool -m <interface>
create BPF to protect a MAC
$ tcpdump -i <interface> not wlan addr3 11:22:33:44:55:66 and not wlan addr2 11:22:33:44:55:66 -ddd > protect.bpf
where addr3 protect ACCESS POINTs and addr2 protect CLIENTs
recommended to protect own devices
or create BPF to attack a MAC
$ tcpdump -i <interface> wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 -ddd > attack.bpf
it is strongly recommended to allow all PROBEREQUEST frames (wlan_type mgt && wlan_subtype probe-req)
see man pcap-filter for a list of all filter options
to use the BPF code
$ hcxdumptool -i <interface> --bpfc=attack.bpf ...
notice: this is a protect/attack, a capture and a display filter
--filtermode=<digit> : user space filter mode for filter list
mandatory in combination with --filterlist_ap and/or --filterlist_client
affected: only outgoing traffic
notice: hcxdumptool act as passive dumper and it will capture the whole traffic on the channel
0: ignore filter list (default)
1: use filter list as protection list
    do not interact with ACCESS POINTs and CLIENTs from this list
2: use filter list as target list
    only interact with ACCESS POINTs and CLIENTs from this list
    not recommended, because some useful frames could be filtered out
    using a filter list doesn't have an affect on rca scan
    only for testing useful - devices to be protected should be added to BPF
    notice: this filter option will let hcxdumptool protect or attack a target - it is neither a capture nor a display filter
--filterlist_ap=<file or MAC> : ACCESS POINT MAC or MAC filter list
format: 112233445566, 11:22:33:44:55:66, 11-22-33-44-55-66 # comment
maximum entries 256
run first --do_rcascan to retrieve information about the target
--filterlist_ap_vendor=<file> : ACCESS POINT VENDOR  filter list by VENDOR
format: 112233, 11:22:33, 11-22-33 # comment
maximum entries 256
run first --do_rcascan to retrieve information about the target
--filterlist_client=<file or MAC> : CLIENT MAC or MAC filter list
format: 112233445566, 11:22:33:44:55:66, 11-22-33-44-55-66 # comment
maximum entries 256
due to MAC randomization of the CLIENT, it does not always work!
--filterlist_client_VENDOR=<file> : CLIENT VENDOR filter list
format: 112233, 11:22:33, 11-22-33 # comment
maximum entries 256
due to MAC randomization of the CLIENT, it does not always work!

An example is here:
https://hashcat.net/forum/thread-10805-p...l#pid55471
The pcapng file is attached to the comment. You'll notice that only the target was attacked and nothing else.


I strongly recommend everyone who decide to use hcxdumptool to learn 802.11 and to learn the options.

By latest commit I added additional information (It is mandatory to set options tailored to the target!) to --help:

Code:

Run hcxdumptool -i interface --do_rcascan for at least 30 seconds, to get information about the target!
It is mandatory to set options tailored to the target!

The book is from 2002 and a good reference to learn 802.11.

Last but not least (to mention it again):
If someone is a beginner or if he/she doesn't know what he/she is doing, it is not a good idea to run hcxdumptool/hcxtools, because hcxdumptool is an area weapon. Running it unconfigured it is acting like a jammer (similar to mdk3/mdk4).

[hashserious]

I wanted to ask some more stuff, but since seeing that i kicked some kind of hornets nest... Chill out dude. I understand this tool is your baby or something like that and it leads to heavy emotional investment.
Maybe you should be happy that your tool is used by people from wide variety of industries and backgrounds.
"It is mandatory to set options tailored to the target!"
Fine, fine.

[ZerBea]

Again, I fully agree and it is nice that this tools are used by experienced penetration testers. But also I'm not happy that this tools are used by "script kiddies", e.g. (my definition):
He/she installed K A L I for the first time - but doesn't know anything about Linux.
He/she use a high power WiFi adapter (ALFA, AWUS xxx) - and think more power is the best.
He/she running hcxdumptool/hcxtools or other WiFi related tools (disregarding README.md and help) - and wonder why the results are not as expected.

Very often (unfortunately) the same criteria also apply to a beginner:

Code:

K A L I  &  ALFA AWUS xxx high power adapter  &  WiFi attack tool

That is a dangerous combination and lead to many (unnecessary) issue reports, e.g. missing dependencies. For me, it looks like nobody is reading README.md (it is explained there).

Maybe I'm a little biased, not neutral, blinded by routine and suspect script kiddies everywhere.....
but in any case I expect that the one who wants to know something has read the instructions (README.md and --help) before!

Some words about injecting (stupid) DEAUTHENTICATION packets (possible done by a high power WiFi adapter. I analyzed a lot of dump files (mostly from wpa-sec) to improve hcxdumptool/hcxtools and mostly I saw something like this (which is a good example of what I mentioned above about "script kiddies"):

Code:

$ hcxpcapngtool *.* -o test.22000
hcxpcapngtool 6.2.7-5-gd66ebbf reading from dump.cap...

summary capture file
--------------------
file name.................................: dump.cap
version (pcap/cap).......................: 2.4 (very basic format without any additional information)
timestamp minimum (GMT)..................: 02.06.2022 20:43:52
timestamp maximum (GMT)..................: 02.06.2022 22:03:24
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11 (105) very basic format without any additional information about the quality
endianess (capture system)...............: little endian
packets inside...........................: 75192
ESSID (total unique).....................: 1
BEACON (total)...........................: 1
BEACON on 2.4 GHz channel (from IE_TAG)..: 9
ACTION (total)...........................: 253
PROBERESPONSE (total)....................: 538
DEAUTHENTICATION (total).................: 37245
DISASSOCIATION (total)...................: 10
AUTHENTICATION (total)...................: 40
AUTHENTICATION (OPEN SYSTEM).............: 40
ASSOCIATIONREQUEST (total)...............: 5
ASSOCIATIONREQUEST (PSK).................: 5
WPA encrypted............................: 15472
EAPOL messages (total)...................: 150
EAPOL RSN messages.......................: 150
EAPOLTIME gap (measured maximum usec)....: 25072
EAPOL ANONCE error corrections (NC)......: working
REPLAYCOUNT gap (recommended NC).........: 8
EAPOL M1 messages (total)................: 116
EAPOL M2 messages (total)................: 1
EAPOL M3 messages (total)................: 32
EAPOL M4 messages (total)................: 1
EAPOL pairs (total)......................: 3
EAPOL pairs (best).......................: 1
EAPOL pairs written to 22000 hash file....: 1 (RC checked)
EAPOL M32E2 (authorized).................: 1
PMKID (useless)..........................: 116

frequency statistics from radiotap header (frequency: received packets)
-----------------------------------------------------------------------
not available due to missing radiotap header

Warning: out of sequence timestamps!
This dump file contains frames with out of sequence timestamps.
That is a bug of the capturing tool.

Warning: excessive number of deauthentication/disassociation frames detected!
That can cause that an ACCESS POINT change channel, reset EAPOL TIMER,
renew ANONCE and set PMKID to zero.
This could prevent to calculate a valid EAPOL MESSAGE PAIR
or to get a valid PMKID.

Information: limited dump file format detected!
This file format is a very basic format to save captured network data.
It is recommended to use PCAP Next Generation dump file format (or pcapng for short) instead.
The PCAP Next Generation dump file format is an attempt to overcome the limitations
of the currently widely used (but limited) libpcap (cap, pcap) format.
https://www.wireshark.org/docs/wsug_html_chunked/AppFiles.html#ChAppFilesCaptureFilesSection
https://github.com/pcapng/pcapng

Information: radiotap header is missing!
Radiotap is a de facto standard for 802.11 frame injection and reception.
The radiotap header format is a mechanism to supply additional information about frames,
from the driver to userspace applications.
https://www.radiotap.org/

Information: missing frames!
This dump file does not contain undirected proberequest frames.
An undirected proberequest may contain information about the PSK.
It always happens if the capture file was cleaned or
it could happen if filter options are used during capturing.
That makes it hard to recover the PSK.

Transmission of 37245 deauthentication packets
DEAUTHENTICATION (total).................: 37245
during a period of one hour and 20 minutes
timestamp minimum (GMT)..................: 02.06.2022 20:43:52
timestamp maximum (GMT)..................: 02.06.2022 22:03:24
to get a single handshake
EAPOL pairs (best).......................: 1
the entire WiFi channel 9
BEACON on 2.4 GHz channel (from IE_TAG)..: 9
(and some neighbor channels) was jammed by DEAUTHENTICATION packets (especially if a high power adapter was used to inject packets).
WiFi channels are overlapped. Channel 9 is 22 MHz width so the transmission interferes with channel 7, 8, 10 and 11.
https://en.wikipedia.org/wiki/List_of_WLAN_channels

This is not an isolated case. More than 90% of the submitted dump files looking like the one mentioned above:

Code:

timestamp minimum (GMT)..................: 29.05.2022 21:40:58
timestamp maximum (GMT)..................: 29.05.2022 23:37:04
DEAUTHENTICATION (total).................: 202240
EAPOL pairs (best).......................: 1
or
timestamp minimum (GMT)..................: 02.06.2022 18:33:21
timestamp maximum (GMT)..................: 02.06.2022 19:51:43
DEAUTHENTICATION (total).................: 143508
EAPOL pairs (best).......................: 3
or
timestamp minimum (GMT)..................: 02.06.2022 18:55:09
timestamp maximum (GMT)..................: 02.06.2022 20:08:06
DEAUTHENTICATION (total).................: 98732
EAPOL pairs (best).......................: 2

And this is just the tip of the iceberg.

I don't know which tools are used to attack the target and to dump the traffic, because of a limited dump file format that doesn't include this information. But running hcxdumptool/hcxtools in a right way (using the right options) this behavior could be completely prevented. Please compare the status printed above to status of the the dump file (taken by hcxdumptool) from here:
https://hashcat.net/forum/thread-10805-p...l#pid55471
and you'll see what I mean.
From my point of view, hcxdumptool option "--disable-deauthentication" has a specific right to exist.

By the last comment I didn't mean you. To make that clear (and that it is not emotional) I edited the comment:
Last but not least (to mention it again):
If someone is a beginner or if he/she doesn't know what he/she is doing, it is not a good idea to run hcxdumptool/hcxtools, because hcxdumptool is an area weapon. Running it unconfigured it is acting like a jammer (similar to mdk3/mdk4).

Please take I look at the issue reports:
https://github.com/ZerBea/hcxdumptool/is...s%3Aclosed
https://github.com/ZerBea/hcxtools/issue...s%3Aclosed
and you'll notice that I answer every question and add every feature request (if it make sense). And the same applies to this thread, to the questions asked here and to your questions.


If you take a closer look at the latest commits:
https://github.com/ZerBea/hcxdumptool/co...758a7fde61
https://github.com/ZerBea/hcxdumptool/co...5ad0b61343
https://github.com/ZerBea/hcxdumptool/co...fb4b9cfb22
you'll notice that I have taken up your suggestions.

Especially this one:
https://github.com/ZerBea/hcxdumptool/co...218d42d236
I agree that hcxdumptool should not try to attack everything if a user try to run hcxdumptool only with interface option "-i". That is fixed, now:

Code:

$ hcxdumptool -i wlp39s0f3u1u1u1
not enough options selected for an attack vector
run hcxdumptool --help to get more information

Please feel free to ask your questions and to share your ideas how to improve the tools.


BTW:
An example of a working environment:
Raspberry Pi Zero:
https://www.reichelt.de/de/en/raspberry-...ol_1&nbc=1

WiFi adapter:
https://www.reichelt.de/de/en/allnet-wir...GE=EN&&r=1

you'll see the hardware modification (LED and push button) and a power bank:
https://github.com/ZerBea/hcxdumptool/wi...g-system-1

operating system:
Arch Linux (new RPI >= v2) or Raspbian lite (old RPI v1).

command Line:

Code:

$ sudo hcxdumptool -i wlp39s0f3u1u1u2 -c 11 -o test.pcapng --enable_status=15 --bpfc=target.bpfc --active_beacon

And the entire system is exactly doing what you want.

May I ask a question:
Which distribution do you use?
Which WiFi adapter do you use?


Luckily hcxdumptool will give you more than one solution to attack your target. Here are four examples using filter options (the results are similar):
If you know your target you can use --bpfc to attack it exactly (bpfc as attack filter).
If you do not know your target (e.g. if the MAC is randomized) but you know all other devices in your neighborhood you can use --bpfc to protect them (bpfc as protect filter).
That is working in transmission and in reception branch.

or you can use filter mode in combination with a filter list
In mode 1 device entries are protected
In mode 2 device entries are attacked
That is working in transmission branch, only. The reception branch remain untouched and every received packet that matches the options (e.g. ipv4, IPv6, EAPOL, WEP, WPA, ...) will stored to the dump file.

I don't know which attack vector is preferred by the user, so I leave hcxdumptool unconfigured by default and let the user decide which option is the best one (with minimal impairment of the neighborhood) for his purpose.

Wireless Networks: The Definitive Guide is an older book, but it is good to learn 802.11 basics.
More information about 802.11 is here:
https://mrncciew.com/
e.g. why are PROBERESPONSE frames more important than BEACON frames:
https://mrncciew.com/2014/10/27/cwap-802...tresponse/

or why it is a good idea to store an (RE)ASSOCIATIONREQUEST frame instead of a single BEACON frame only:
https://mrncciew.com/2014/10/28/802-11-m...qresponse/
https://github.com/kismetwireless/kismet/issues/419

[hashserious]

Thanks for the reply. I actually looked at all your links and bookmarked some. Those answered my questions.
I have been using arch since backtrack turned into The-Distribution-Which-Does-Not-Handle-OpenCL-Well (Kali). Also have raspbi(raspbian os, maybe should switch to arch too, but since the raspbian works for intended purposes, still using it) to be more mobile. Battery banks and stuff. I have multiple(i think if i really look hard, maybe 10) adapters, MT7601U is one of them.
I guess i have to practice more with bpfc files.
I also want to thank you for adding so many options to these tools. Really versatile.
Now come to think of it, i guess deauth as default may be good. Throws off some script kiddies.
Btw, haven't used deauth reason codes at all(i don't use deauth, mostly, maybe that's why). How much do they change the results, practically?

[ZerBea]

Ok, thanks for your detailed information.
There is a huge difference between hcxdumptool/hcxtools and other WiFi attack tools. Many options may look similar, but the engine behind is completely different.
hcxdumptool is interacting with the target. If the target is an AP that include all CLIENTs of this NETWORK. As a cause if this, the DEAUTHENTICATION process is not static. hcxdumptool use more than one DEAUTHENTICATION code and it switches from DEAUTHENTICATION to DISASSOCIATION depending on the state of the target. This goes so far that it use different reason codes for the AP and the CLIENTs. You can override this as you already mentioned (--reason_code).

But let me start with the implemented attack vectors that run simultaneously:
BEACON spoofing
PROBERESPONSE spoofing
PROBEREQUEST (to get additional information that is not present in a BEACON)
AUTHENTICATION attack (to prepare one of the following attacks)
ASSOCIATION attack (e.g. to retrieve a PMKID)
REASSOCIATION attack (e.g. to retrieve a PMKID or to downgrade an AUTHENTICATION state)
M2 attack (to retrieve CLIENT NONCE and MIC)
M4 attack (to make sure we got an entire valid handshake or to prevent connections)
PS-POLL (to downgrade an AUTHENTICATION state)
EAP attack (to retrieve an EAP-ID)
and
DEAUTHENTICATON / DISASSOCIATION attack

On some attacks it make sense to disable them by a single command (e.g. --disable_deauthentication).
Other attacks are grouped and it only make sense to deactivate the entire group (--disable_client_attacks).
Or if an AP is able to detect attacks against it, it may be useful to run attacks only against the CLIENTs (--disable_ap_attacks).
The same applies if the CLIENT is in the range of hcxdumptool but the AP not.

The first step is always to run a rca scan, to find out if the target is in range and to get some additional information, eg. AKM (authentication key management) of the target
Requesting the AKM of a CLIENT is not necessary, because it always announce it in its ASSOCIATIONREQUEST.

Take a look at the RSN IE_TAG field (by Wireshark or by tshark)

Code:

RSN Capabilities: 0x00c0
    .... .... .... ...0 = RSN Pre-Auth capabilities: Transmitter does not support pre-authentication
    .... .... .... ..0. = RSN No Pairwise capabilities: Transmitter can support WEP default key 0 simultaneously with Pairwise key
    .... .... .... 00.. = RSN PTKSA Replay Counter capabilities: 1 replay counter per PTKSA/GTKSA/STAKeySA (0x0)
    .... .... ..00 .... = RSN GTKSA Replay Counter capabilities: 1 replay counter per PTKSA/GTKSA/STAKeySA (0x0)
    .... .... .1.. .... = Management Frame Protection Required: True
    .... .... 1... .... = Management Frame Protection Capable: True
    .... ...0 .... .... = Joint Multi-band RSNA: False
    .... ..0. .... .... = PeerKey Enabled: False
    ..0. .... .... .... = Extended Key ID for Individually Addressed Frames: Not supported

Management frame protection is enabled and it is absolutely useless to inject DEAUTHENTICATION frames or DISASSOCIATION frames. As long as the target is not downgraded, it will only jam the channel. To avoid this, use e.g. --disable_deauthentication.
Please note:
The BEACON IE_TAGs give an overview of the capabilities of an AP.
The PROBERESPONSE IE_TAGs show all supported capabilities.
But only the ASSOCIATIONREQUEST/REASSOCIATIONREQUEST IE_TAGs give an information about the capabilities that are in use on the following connection (that include the ESSID).
The IE_TAGs of this frames may differ and it is mandatory to get the last one (instead of only the first one in the BEACON).
Ignoring this kind of frames can lead to an issue like this one:
https://github.com/kismetwireless/kismet/issues/419

Luckily there are some frames that can't be protected (ASSOCIATIONREQUEST, REASSOCIATIONREQUEST, PS POLL). Now hcxdumptool try to downgrade the AUTHENTICATION state of the target (using this CLASS 3 or CLASS 4 frames) to a state that will allow to throw of the CLIENTs. If successful, mostly the AP will do this job for us (you noticed that the CLIENTs are disconnected even though you have disabled DEAUTHENTICATIONs). That include a WPA3 connection, too. Now, if CLIENT attacks are not disabled, the CLIENT first try to connect to hcxdumptool and we can retrieve its M2. Than the CLIENT will try to connect to its AP and we can get M1M2M3M4. For both cases there is an option to disable this behavior.

Some of the attack vectors are extremely aggressive (e.g. M4 attack), because they are able to prevent that the CLIENT can reconnect. This attack vector is also usable to fool a user, because (depending on the reason code) he have to type his PSK again, and again, and again... (for all eternity or until --stop_client_m2_attacks= is reached).
The M2 attack vector e.g. is able to retrieve more than one PSK from the CLIENT.
The EAP attack vector is able to retrieve an EAP-ID from the target (that can be the IMEI of a mobile phone).

BPF code is really powerful and it allow you to control hcxdumptool behavior completely. It allow to attack/protect an entire NETWORK (addr3), to attack frames coming from a target (addr2), to attack frames going to a target (addr1) or any combination of this. Also it allow to attack/protect all kinds of frames. A combination of targets and frames is possible. This will act as a scalpel. Additional it is possible to use all options, the soft filter and BPC in combination.

By default, most of the options are activated. Only with activated options hcxdumptool is able to interact with the target and to choose that attack vector which is the best to retrieve the hash in a short time. How long it take or when a CLIENT is allowed to connect again , can be controlled via options, too: --stop_ap_attacks= or --stop_client_m2_attacks= or a combination of that.

If you choose --disable_deauthentication only, all remaining attack vectors are still active (and they are much more powerful than a stupid deauthentication attack). A connected CLIENT will be downgraded, BEACONs and PROBERESONSES are spoofed and hcxdumptool respond to all CLIENTs. As a result to this response every CLIENT will leave its associated AP and connect to hcxdumptool.

The MediTek and the Ralink (now MediaTek) adapters are the best ones, I know. The drivers are more than excellent, part of the stock kernel and well maintained.


BTW:
To be a beginner is absolutely ok for me. In most of the cases, I'm a beginner, too.
And every day I learn something new. Yesterday I learned that the frequency range on 6GHz band is much wider than expected:
https://github.com/aircrack-ng/aircrack-...1147617852

[ZerBea]

@CyberPentester, I really want to answer your question, received by PM

Code:

I wanted to ask you directly since you are quite the expert on this field.

1. Let's say I got 2 PMKID hashes and 1 WPA Handshake, all from the same WiFi network, using hcxpcapngtool. Would hashcat crack faster if I give all 3 hashes? Or is selecting just 1 PMKID faster?

2. Do you know of any tool (maybe a hashcat option does this) that can bruteforce passwords with a mask attack based on probability? For example: A WiFi password that consists of 10 digits where different random numbers ("1634845593") are more probable than say "1111111111" or "22224444".

But you disabled private messaging!

Code:

Please correct the following errors before continuing:
    CyberPentester has private messaging disabled. You cannot send private messages to this user.

To answer 1) we have to take a closer look at the calculation of the keys:
The construction (PBKDF2 calculation) of the plainmasterkey (PMK) is for both hash types (PMKID and EAPOL 4way) the same and take long period of CPU/GPU time.
This part is a really slow part.
Luckyly, we need to calculate PBKDF2 once (each different ESSID) and can use it for PMKID and MIC (EAPOL 4way) calculation:
https://github.com/hashcat/hashcat/issues/1816

In the second part, PMKID calculation (PMKID) is much faster:

Code:

PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)

than calculating a MIC from EAPOL (4way handshake) wpa1:
calculate PKE, calculate PTK, calculate MIC (encrypt message and compare MIC) for WPA1:

Code:

HMAC(EVP_sha1(), pmk, 32, pkedata, 100, ptk + p * 20, NULL);
HMAC(EVP_md5(), &ptk, 16, eapol, eapol_len, mic, NULL);

or wpa2:
calculate PKE, calculate PTK, calculate MIC (encrypt message and compare MIC) for WPA2:

Code:

HMAC(EVP_sha1(), pmk, 32, pkedata, 100, ptk + p * 20, NULL);
HMAC(EVP_sha1(), &ptk, 16, eapol, eapol_len, mic, NULL);

or wpa2 keyversion3:
calculate PKE, calculate PTK, calculate MIC (encrypt message and compare MIC) for WPA2 key version 3:
[code]
HMAC(EVP_sha256(), pmk, 32, pkedata_prf, 2 + 98 + 2, ptk, NULL);
omac1_aes_128(&ptk, eapol, eapol_len, mic);
[code]
If you only want to recover the PSK just use the PMKID hash line (WPA*01*) and remove the EAPOL 4way hash lines (WPA*02*) for that ESSID.


The second question is not easy to answer, because it depend on the target.
If the default password algo is known, routerkeygen (RKG) should be the first choice.
https://github.com/routerkeygen/routerkeygenPC
If the default key space is know, hcxpsktool could be a choice.
Additional you can do a picture search (e.g. DuckDuckGo or ebay) to find a possible pattern and use it as a mask file.

[CyberPentester]

@CyberPentester, I really want to answer your question, received by PM



But you disabled private messaging!

Whoops, did not know that was a thing. I enabled it now. Thanks for letting me know and answering here.

In the second part, PMKID calculation (PMKID) is much faster:


If you only want to recover the PSK just use the PMKID hash line (WPA*01*) and remove the EAPOL 4way hash lines (WPA*02*) for that ESSID.

Yes, understood the part of the complexity between PMKID and EAPOL 4way, thank you for the explanation into how the algorithm works. My question was a bit confusing, so let me change it to this: If I had multiple PMKID hashes from the same ESSID and put them all into hashcat, it does not make the PSK crack faster, correct? In fact it would take longer?

The second question is not easy to answer, because it depend on the target.

If the default password algo is known, routerkeygen (RKG) should be the first choice.

https://github.com/routerkeygen/routerkeygenPC

The manufacturer is not there, but I do know the keyspace. I would have to take some time to figure out this tool. If I choose one of manufacturers in that tool that has the same keyspace as the router I know, will the generated wordlist be optimized or does it also do a simple bruteforce mask without taking into account probability?

If the default key space is know, hcxpsktool could be a choice.

I do know the keyspace. Does hcxpsktool take into account probability of same characters appearing multiple times in the PSK candidates? Also may you please provide an example of hcxpsktool for a keyspace of 10 digits?

Thanks again for answering!

[ZerBea]

"Yes, understood the part of the complexity between PMKID and EAPOL 4way, thank you for the explanation into how the algorithm works. My question was a bit confusing, so let me change it to this: If I had multiple PMKID hashes from the same ESSID and put them all into hashcat, it does not make the PSK crack faster, correct? In fact it would take longer?"

It would take longer. The fastest method is to take only one PMKID each NETWORK.


"The manufacturer is not there, but I do know the keyspace. I would have to take some time to figure out this tool. If I choose one of manufacturers in that tool that has the same keyspace as the router I know, will the generated wordlist be optimized or does it also do a simple bruteforce mask without taking into account probability?"

No,RKG use MAC and/or ESSID to calculate only one PSK,


"I do know the keyspace. Does hcxpsktool take into account probability of same characters appearing multiple times in the PSK candidates?"

No, hcxpsktool use use MAC or ESSID to calculate a possible key space.
The difference between RKG and hcxpsktool:
hcxpsktool will work on by hcxdumptool random generated MACs, too - RKG not.


"Also may you please provide an example of hcxpsktool for a keyspace of 10 digits?"

$ hcxpsktool --digit10
no hashes loaded
9438521860
2755437655
7948132838
...
This is the entire possible keyspace of Infinitum models.

Both tools (RKG and hcxpsktool) are based on analyzed submissions of
https://wpa-sec.stanev.org/
The same applies to hcxdumptool and hcxlabtool series.