Not attacking and deauthenticating clients

[fa1rid]

Hi ZerBea,

Thanks for the nice tool. The tool is working fine when a device connects to the AP and I can capture the handshake, however if clients are already connected there's no de-authentication happening. I tried both 2.4GHz and 5Ghz. How can I disconnect clients so I can capture the handshake?

Thanks for help!

[ZerBea]

Running default options, hcxdumptool will deauthenticate, disassociate and reassociate every to an ACCESS POINT connected CLIENT unless Management Frame Protection is not activated! $ hcxdumptool -i interface -o dump.pcapng --enable_status=31 You can verify this behavior running Wireshark directly after you started hcxdumptool. You'll see the deauthentication / disassociation / reassociationrequest packets from hcxdumptool.

Please notice: Running default options, hcxdumptool will give up to disconnect a CLIENT after a while or when a handshake was captured. If you don't want this, you must use --resume_ap_attacks= (see --help)

BTW: What kind of device are you running (rtl8812au and 8188eus have serious problems). Please add output of: $ lsb $ hcxdumptool -I $ hcxdumptool -i interface --check_driver is packet injection working: $ hcxdumptool -i interface --check_injection

[ZerBea]

BTW: How have you tested this: "however if clients are already connected there's no de-authentication happening." hcxdumptool doesn't store this useless packets in pcapng file and it will not show you them in status, because that will spam the real time display.

[ZerBea]

By this commit https://github.com/ZerBea/hcxdumptool/commit/83370fb79864b96143a5828a4c776d4bd9f3e63f hcxdumptool allow to set channels (-c) to test that injection is really working on this channel. I noticed that some drivers support injection on 2.4GHz, but not on 5GHz. Now you can check this: $ hcxdumptool -i interface -c 52,100 --check_injection the same applies to rcascan: $ hcxdumptool -i interface -c 1,6,11,56,100 --do_rcascan

[fa1rid]

BTW: How have you tested this: "however if clients are already connected there's no de-authentication happening." hcxdumptool doesn't store this useless packets in pcapng file and it will not show you them in status, because that will spam the real time display.

I have tested this in two ways: 1- It's my own wifi network and my devices are connected to it. Non of them got disconnected. 2- I used Aircrack to manually deauth a client and it worked. So aircrack worked but hcxdumptool not.

I have 3 WiFi adapter testing for this. All of them support packet injection and monitoring mode. I will send you details about them.

Another thing I noticed is aircrack wasn't able to deauthenticate on 5Ghz only (packet sent successfully with no errors but clients didn't disconnect). (I will verify this now again with different adapters)

I will send you more details in a bit, I will do some tests now.

[ZerBea]

1- It's my own wifi network and my devices are connected to it. Non of them got disconnected. It is not the goal of hcxdumptool to disconnect a client to receive a handshake - we do this with a reassociationrequest Do you receive the handshake running from the connected client?

[ZerBea]

At this moment, I have not seen an adapter that support full packet injection on 5GHz. All of them showing issues. That is the reason why 5GHz is not in automatic mode. Please add output of $ hcxdumptool -i interface -C to find out which channels are supported by the driver/interface

[fa1rid]

With hcxdumptool I don't get handshake if I don't manually disconnect the client. So? update: it's only happening with certain wifi adapters and -c option (driver problem)

[ZerBea]

I can't reproduce that. hcxdumptool disconnect the CLIENT and receive the handshake

$ sudo hcxdumptool -i wlp39s0f3u1u1u2 -c 8 --enable_status=1
initialization...

start capturing (stop with ctrl+c)
NMEA 0183 SENTENCE........: N/A
INTERFACE NAME............: wlp39s0f3u1u1u2
INTERFACE HARDWARE MAC....: 74da38eb460b
DRIVER....................: mt7601u
DRIVER VERSION............: 5.7.7-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)......: 0418b638ada8 (BROADCAST HIDDEN)
ROGUE (ACCESS POINT)......: 0418b638ada9 (BROADCAST OPEN)
ROGUE (ACCESS POINT)......: 0418b638adaa (incremented on every new client)
ROGUE (CLIENT)............: b4e1eb05b46a
EAPOLTIMEOUT..............: 20000 usec
REPLAYCOUNT...............: 62528
ANONCE....................: 76efbadc4459e1e3ed023ea14d2b36c67cb02da86a194aeba36d1ba3a4b65809
SNONCE....................: f283f5f0db28c7202635acc196ce0a2db6378e7181cbfcb76de18e68cedb7dd5

15:51:17   8 b0c090461aab 0418b638adab TEST_NETWORK [EAPOL:M1M2ROGUE EAPOLTIME:2160 RC:62528 KDV:2 PSK:12345678]
15:51:51   8 b0c090461aab 3481c4e7411b TEST_NETWORK [EAPOL:M1M2 EAPOLTIME:2180 RC:1 KDV:2 PSK:12345678]
15:51:51   8 b0c090461aab 3481c4e7411b TEST_NETWORK [EAPOL:M2M3 EAPOLTIME:3712 RC:2 KDV:2 PSK:12345678]
15:51:51   8 b0c090461aab 3481c4e7411b TEST_NETWORK [EAPOL:M3M4ZEROED EAPOLTIME:4238 RC:2 KDV:2]

Explanation: The CLIENT was disconnected and he first tried to connect to hcxdumptool, because we are faster than the ACCESS POINT (AP). 15:51:17 8 b0c090461aab 0418b638adab TEST_NETWORK [EAPOL:M1M2ROGUE EAPOLTIME:2160 RC:62528 KDV:2 PSK:12345678] hcxdumptool received the M2 from the CLIENT and recovered the weak Pre Shared Key (PSK): 12345678

Than the CLIENT run a 4way handshake with the AP. 15:51:51 8 b0c090461aab 3481c4e7411b TEST_NETWORK [EAPOL:M1M2 EAPOLTIME:2180 RC:1 KDV:2 PSK:12345678] 15:51:51 8 b0c090461aab 3481c4e7411b TEST_NETWORK [EAPOL:M2M3 EAPOLTIME:3712 RC:2 KDV:2 PSK:12345678] 15:51:51 8 b0c090461aab 3481c4e7411b TEST_NETWORK [EAPOL:M3M4ZEROED EAPOLTIME:4238 RC:2 KDV:2] hcxdumptool received all EAPOL frames and recovered the weak PSK.

[ZerBea]

Please add output of $ hcxdumptool -I $ hcxdumptool -i interface -C $ lsusb

Please notice that rtl8812au and rtl8188eus adapters are not working as expected!

[fa1rid]

intel.txt usb.txt hcxdumptool.txt

[ZerBea]

Great, thanks.

This driver support monitor mode, but not full packet injection: 645d86385e37 wlan0 (iwlwifi) https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_the_monitorsniffer_mode https://community.intel.com/t5/Wireless/Does-Intel-802-11ac-1x1-Wi-Fi-card-support-packet-injection-i/td-p/480459?profile.language=en

This driver is currently broken: 90f6520939df wlan1 (ath9k_htc) https://bugzilla.kernel.org/show_bug.cgi?id=208251

This driver will not work. On mainline kernel neither native monitor mode nor full packet injection available: 8416f918428c wlan2 (rtl8xxxu) you can try driver from here: https://github.com/aircrack-ng but you will run into several issues: https://github.com/aircrack-ng/rtl8812au/issues/587 due to NETLINK stuff

[fa1rid]

iwlwifi & ath9k_htc are working with me fine on kali-linux. I'm testing rtl8xxxu now and seems working fine as well.

There's one issue, I did hcxdumptool -i wlan1-o dump.pcapng --enable_status=31 problem is I can see 5G networks, wlan1 is the usb which doesn't support 5G channels.

[fa1rid]

I did a new installation of latest Kali Linux and now auto de-authentication is working. I'm very confused now. I will do more tests and let you know.

[fa1rid]

There's some inconsistencies, --do_rcascan doesn't show 5G networks while dumping shows. Another inconsistency is that de-authentication is not happening when you specify channel by -c de-authentication only happens when u don't specify any additional parameters.

[ZerBea]

Nice to hear that it is working, now. I don't use KALI, so I don't know what driver versions are inside of this distribution. But most of the issues are caused by the driver in combination with the kernel version.

[ZerBea]

--do_rcascan -s 3 should show 2.4 and 5 GHz networks:

$ hcxdumptool -i wlp3s0f0u2 --do_rcascan -s 3
 BSSID         CH COUNT   HIT ESSID                 [23:10:06]
---------------------------------------------------------------
 3481c4e7411b  36     6     0 TEST_NETWORK
 4c1b860b2796   1     1     0 WLAN-TEST

[ZerBea]

I can't reproduce that. Transmitting deauthentications doesn't depend on the channel options.

[fa1rid]

for -s 3 i get: hcxdumptool: invalid option -- 's' also I don't see -s 3 in the --help

What does Rogue mean? For example EAPOL:M1M2ROUGUE

[ZerBea]

I pushed that update 5 hours ago. https://github.com/ZerBea/hcxdumptool/commit/775c3366aaf6f4053a1efbefaab88d3cb3f28158 You must do either a git pull or a fresh git clone M1M2ROGUE means hcxdumptool acting as an AP for the CLIENT. The other values are explained here: https://github.com/ZerBea/hcxdumptool/issues/112

[ZerBea]

$ hcxdumptool -h
-s <digit>     : set predefined scanlist
                 0 = 1,6,11,3,5,1,6,11,2,4,1,6,11,7,9,1,6,11,8,10,1,6,11,12,13 (default)
                 1 = 1,2,3,4,5,6,7,8,9,10,11,12,13
                 2 = 36,40,44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136,140,149,153,157,161,165
                 3 = 1,2,3,4,5,6,7,8,9,10,11,12,13,36,40,44,48,52,56,60,64,100,104,108,112,116,120,124,128,132,136,140,149,153,157,161,165

[ZerBea]

Please take a look at this example: https://github.com/ZerBea/hcxdumptool/issues/121#issuecomment-654253516 We specified a channel -c 8 and the CLIENT is deauthenticated.

[fa1rid]

I can't reproduce that. Transmitting deauthentications doesn't depend on the channel options.

I tried two times, and I can confirm to you that using -c option doesn't allow de-authentication to happen.

[fa1rid]

without -c I get many death...

[fa1rid]

I'm using the correct -c channel and I see network name as beacon but no de-authentication happening. I remove -c option and de-authentication works.

[fa1rid]

Let me try different wifi adapter and check..

[ZerBea]

Hmmm. Transmitting deauthentications doesn't depend on the channel or the -c option or the -s option.

[fa1rid]

Ok now I tried ath9k_htcand the problem didn't happen. However, how come I can see 5G network of the same router there and this device doesn't support that and it's on different channel even?

[ZerBea]

Please add output of $ hcxdumptool -i interface --check_driver $ hcxdumptool -i interface --check_injection and for 5GHz channels $ hcxdumptool -i interface -s 2 --check_injection

Expected output:

$ hcxdumptool -i wlp3s0f0u2 --check_driver
initialization...
starting driver test...
driver tests passed...
all required ioctl() system calls are supported by driver

terminating...

$ hcxdumptool -i wlp3s0f0u2 --check_injection
initialization...
starting packet injection test (that can take up to two minutes)...
packet injection is working! Ratio: 483 to 148 

$ hcxdumptool -i wlp3s0f0u2 -s 2 --check_injection
initialization...
starting packet injection test (that can take up to two minutes)...
packet injection is working! Ratio: 190 to 58 

[ZerBea]

However, how come I can see 5G network of the same router there and this device doesn't support that and it's on different channel even? That is easy to answer and explained in README.md:

* hcxdumptool is able to capture handshakes from 5GHz clients on 2.4GHz (only one single M2 from the client is required)
  (use hcxpcapngtool to save them to file)

[ZerBea]

The shown 5GHz network isn't real. It is a hcxdumptool simulation of the 5GHz network on 2.4GHz. The CLIENT will be fooled and connect to hcxdumptool. You sould see a M1M2ROGUE. ROGUE was added to every simulated network.

[ZerBea]

hcxdumptool is CLIENT oriented. hcxdumptool will be the AP, that the CLIENT expect - independant of the channel or of the band. If the CLIENT expect a network with the ESSID: hello - hcxdumptool will be that network on the current channel. If the CLIENT connect, we request and store his M2. If we have the M2 from the CLIENT, hashcat/JtR is able to recover the PSK.

[fa1rid]

initialization... starting driver test... driver tests passed... all required ioctl() system calls are supported by driver

terminating...[?25h initialization... starting packet injection test (that can take up to two minutes)... packet injection is working! Ratio: 88 to 68

terminating...[?25h initialization... starting packet injection test (that can take up to two minutes)... packet injection is working! Ratio: 20 to 12

terminating...[?25h

[ZerBea]

Thanks. That is looking fine. The ratio is good. In the first case, we received 88 frames and got 68 responses. 20 frames are not responded. In the first case, we received 20 frames and got 12 responses. 8 frames are not responded.

[fa1rid]

The shown 5GHz network isn't real. It is a hcxdumptool simulation of the 5GHz network on 2.4GHz. The CLIENT will be fooled and connect to hcxdumptool. You sould see a M1M2ROGUE. ROGUE was added to every simulated network.

Sorry but can you please explain this more, how is it useful?

[ZerBea]

That is called an AP-LESS attack. Only a M2 of a CLIENT is required to recover the PSK. You don't need an AP or a CLIENT connected to an AP. You don't need to deauthenticate or disassociate a CLIENT from an AP. hcxdumptool will wait for a CLIENT and request his M2. This information is enough for hashcat or JtR to recover the PSK.

[fa1rid]

Now I'm trying again to see why -c is not de authenticating users on iwlwifi. It still not working, also now when I did ctrl+c to stop it, the computer got frozen and I need to force reboot by power button. Seems like driver problem. But it's working fine at the same time.

[ZerBea]

iwlwifi is running into serious issues (memory leak). They are reported on kernel.org and not fixed, yet: We discussed it here: https://github.com/ZerBea/hcxdumptool/issues/105 and reported it on kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=206961

[fa1rid]

I have important question please regarding hcxpcapngtool. How can I see the name of SSIDs stored in pcap file and export each one separately to a file like ssid1.22000 ssid2.22000 ssid3.22000?

[fa1rid]

I have collected a lot of handshakes and pkmids in one file but I can't see and choose what I want to export from there.

[ZerBea]

Let us take a look at the workflow: hcxdumdptool -> hcxpcapngtool -> hcxhashtool -> hascat/JtR hcxdumdptool = attack/dump hcxpcapngtool = conversion to a hashformat that hascat or JtR understand hcxhashtool = selecting networks

To get this result: ssid1.22000 ssid2.22000 ssid3.22000 just run $ hcxpcapngtool -o test.22000 test.pcapng $ hcxhastool -i test.22000 --essid-group

[ZerBea]

Yo can select nearly every network:

$ hcxhashtool -h
hcxhashtool 6.0.3-1-g9200cbe (C) 2020 ZeroBeat
usage:
hcxhashtool <options>

options:
-i <file>   : input PMKID/EAPOL hash file
-o <file>   : output PMKID/EAPOL hash file
-E <file>   : output ESSID list (autohex enabled)
-d          : download http://standards-oui.ieee.org/oui.txt
            : and save to ~/.hcxtools/oui.txt
            : internet connection required
-h          : show this help
-v          : show version

--essid-group                : convert to ESSID groups in working directory
                               full advantage of reuse of PBKDF2
                               not on old hash formats
--oui-group                  : convert to OUI groups in working directory
                               not on old hash formats
--mac-group-ap               : convert APs to MAC groups in working directory
                               not on old hash formats
--mac-group-client           : convert CLIENTs to MAC groups in working directory
                               not on old hash formats
--type=<digit>               : filter by hash type
                               bitmask:
                                1 = PMKID
                                2 = EAPOL
                               default PMKID and EAPOL (1+2=3)
--essid-len                  : filter by ESSID length
                             : default ESSID length: 0...32
--essid-min                  : filter by ESSID minimum length
                             : default ESSID minimum length: 0
--essid-max                  : filter by ESSID maximum length
                             : default ESSID maximum length: 32
--essid=<ESSID>              : filter by ESSID
--essid-part=<part of ESSID> : filter by part of ESSID
--mac-ap=<MAC>               : filter AP by MAC
                             : format: 001122334455, 00:11:22:33:44:55, 00-11-22-33-44-55 (hex)
--mac-client=<MAC>           : filter CLIENT by MAC
                             : format: 001122334455, 00:11:22:33:44:55, 00-11-22-33-44-55 (hex)
--oui-ap=<OUI>               : filter AP by OUI
                             : format: 001122, 00:11:22, 00-11-22 (hex)
--oui-client=<OUI>           : filter CLIENT by OUI
                             : format: 001122, 00:11:22, 00-11-22 (hex)
--vendor=<VENDOR>            : filter by (part of) VENDOR name
--authorized                 : filter EAPOL pairs by status authorized
--notauthorized              : filter EAPOL pairs by status not authorized
--rc                         : filter EAPOL pairs by replaycount status checked
--apless                     : filter EAPOL pairs by status M1M2ROGUE (M2 requested from CLIENT)
--info=<file>                : output detailed information about content of hash file
--info=stdout                : stdout output detailed information about content of hash file
--vendorlist                 : stdout output VENDOR list sorted by OUI
--psk=<PSK>                  : pre-shared key to test
                             : due to PBKDF2 calculation this is a very slow process
                             : no nonce error corrections
--pmk=<PMK>                  : plain master key to test
                             : no nonce error corrections
--hccapx=<file>              : output to deprecated hccapx file
--hccap=<file>               : output to ancient hccap file
--hccap-single               : output to ancient hccap single files (MAC + count)
--john=<file>                : output to deprecated john file
--help                       : show this help
--version                    : show version

[fa1rid]

Okay now I understand, I missed hcxhashtool. So when I see M1M2ROGUE it means this is enough right? otherwise I need M1M2 - M2M3 - M3M4 right?

I tired again after reboot iwlwifi with -c didn't work, then removed -c and it worked. Very strange behavior.

[fa1rid]

Is it possible that this iwlwifi has problem only when you specify channel with -c (maybe when u specify mac also [i need to check] )? Because in my test the other adapter worked fine with -c

[ZerBea]

BTW: There was a similar issue on the atk9k driver. Discussed here: https://github.com/ZerBea/hcxdumptool/issues/119

I tired again after reboot iwlwifi with -c didn't work, then removed -c and it worked. Very strange behavior. Indeed - memory leak!

So when I see M1M2ROGUE it means this is enough right? otherwise I need M1M2 - M2M3 - M3M4 right? M1M2ROGUE is a challenge. It can be a "false positive". It is possible that the PSK belong to a different AP with the same ESSID (default, Home, .... or other common used ESSIDs). M1M2 is a challenge. It can be a "false positive". It is possible that the PSK belong to a different AP with the same ESSID (default, Home, .... or other common used ESSIDs). M2M3 belong to the current AP - not to a possible AP with the same ESSID. M3M4 belong to the current AP - not to a possible AP with the same ESSID. M1M4 belong to the current AP - not to a possible AP with the same ESSID. M1M4ZEROED is useless M3M4ZEROED is useless

A PMKID belong to the current AP, if received from a M1. A PMKID belong to a CLIENT, if received from a M2 or from a reassociationrequest.

[ZerBea]

Correct. Both drivers iwlwifi and ath9k are known to have an issue. The issues are still unfixed. I have several adapters to test. Only rt2800usb and mt76 devices are working without an issue, if connected to an USB2 hub. If connected to an USB3 hub, there is another kernel issue (still unfixed) regarding xhci subsystem. It is discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=202541

[fa1rid]

Thanks a lot for your valuable information, you are helping me a lot :)

Excuse me please still don't understand somethings.

1- Please mention what should I see when there's a successful capture of hashes whether it's pkmid or eapol. I'm getting confused of so many different similar outputs. I believe it's either: EAPOL M1M2 M2M3 M1M2ROGUE (in most cases should be for same AP) PKMID...

2- If I want to buy wifi adapter now which one do you recommend that supports both 2G & 5Ghz? USB2/USB3?

3- 5Ghz is very important nowadays as almost most people use it. Is it possible to capture 5ghz traffic with 2G adapter?

4- What happens when 2G & 5G have the same BSSID. Does it help capturing 5G traffic with my 2G adapter.

Thank you again I really appreciate your support.

[fa1rid]

The shown 5GHz network isn't real. It is a hcxdumptool simulation of the 5GHz network on 2.4GHz. The CLIENT will be fooled and connect to hcxdumptool. You sould see a M1M2ROGUE. ROGUE was added to every simulated network.

what does simulation of the 5GHz network on 2.4GHz mean?

[fa1rid]

Now we need solution for 5Ghz. Is it possible to force the client disconnecting from the 5Ghz and connect to the 2Ghz if both bands have same BSSID or maybe different even different one? My intel iwlwifi wifi card is not de-authenticating 5Ghz clients. Are your adapters working with de-authenticating 5Ghz clients?

[fa1rid]

Also I don't understand why I still see one of my 5G networks showing as ROGUE knowing that I changed the router completely with another one and different BSSID. From where it's getting it?

[ZerBea]

Let me answer this second question first: Also I don't understand why I still see one of my 5G networks showing as ROGUE knowing that I changed the router completely with another one and different BSSID. From where it's getting it?

Old school tools get this information from an AP. hcxdumptool get this information from a CLIENT. If a CLIENT appear, hcxdumptool request all(!) from him. This information is stored in CLIENT wpa-supplicant.conf regardless of the channel and the band. This is shown as ROGUE in the waterfall display. If we receive only undirected proberequests from the CLIENT, we don't have the real BSSID of the ROGUE AP. You noticed that - the BSSID is not the same as the BSSID of your AP. If the CLIENT transmit a directed proberequest, we will receive also the origin BSSID of "his" network. So, all information hcxdumptool will show you are based on CLIENTs. Either they are requested by hcxdumptool or they are probed by the CLIENT. No other old school tool is running this kind of attacks! This attacks require a fast driver (direct access to the device, no additional virtual NETLINK interface, full monitor mode, fast channel switching). Unfortunately not all drivers support this. Additional you must configure wirelessregdb (by crda tools). Here is an information for KALI: https://installlion.com/kali/kali/main/c/crda/install/index.html If not configured, your interface will not transmit/receive on some channels, or it will transmit with reduced power.

1- Please mention what should I see when there's a successful capture of hashes whether it's pkmid or eapol. I'm getting confused of so many different similar outputs. You should see PMKID or PMKIDROGUE if the AP support this. The difference between them: PMKID is requested by a real CLIENT while PMKIDROGUE is requested by hcxdumptool (CLIENT-LESS attack). From both of them you can recover the PSK. Not all APs support this PMKID caching. EAPOL frames (messages M1 M2 M3 M4) are required to retrieve the PSK. One message (M) is from the AP (M1 or M3) and one message is from the CLIENT (M2 or M3). All 4 messages together are called 4way handshake. To calculate the PSK you need a matching pair (M1M2 M2M3 M3M4 or M1M4). You can divide the 4 way handshakes into 2 parts: CHALLENGE (not authorized) = M1M2 CONFIRM (authorized) = M2M3, M3M4, M1M4 To make sure the calculated PSK came really from your target, a M2M3, M3M4 (not zeroed) or M1M4 is mandatory. If you have a M1M2 or M1M2ROGUE it can be either the real PSK, a wrong PSK (typo of the user) or a PSK that belong to a different network, running the same ESSID.

2 - If I want to buy wifi adapter now which one do you recommend that supports both 2G & 5Ghz? USB2/USB3? None of my adapters is working on 5GHz as expected. All of them showing issues. I can't recommend a special one. On 2.4GHz I prefer mt76 (Mediatek) or rt2800usb (RALINK) devices.

3 - 5Ghz is very important nowadays as almost most people use it. Is it possible to capture 5ghz traffic with 2G adapter? No, we are only able to fool a CLIENT and to retrieve his M2 (of the 5GHz network).

4 - What happens when 2G & 5G have the same BSSID. Does it help capturing 5G traffic with my 2G adapter. That depend on the CLIENT. Does he use undirected proberequests or directed proberequests. If the2.4GHz PSK is different to the 5GHz PSK, you should use hcxpcapngtool with option --all to be able to recover really all(!) PSKs instead of only the best one.

For sure, we need a driver solution for 5GHz - and work is in progress (example): https://github.com/openwrt/mt76/issues/216#issuecomment-500999516 https://bugzilla.kernel.org/show_bug.cgi?id=202243

Once the kernel received a fix, it is important that the distribution (Arch, Debian, UBUNTU, KALI, ...) follows. Than, for you, it is mandatory to install the latest version of that distribution to get benefit of the fixes.

Please notice: hcxdumptool/hcxtools are not easy to use, because this tools are designed to be analysis tools - not to crack a single network. Of course, they are able to retrieve/prepare the information to be able to crack a single network, but that is not the goal. Goal is to discover weak points within the whole system. They are running in the background of e.g. https://wpa-sec.stanev.org/ Improved knowledge about 802.11 (CLIENT behavior, MAC randomization, authentication mechanisms, EAP, EAPOL, AP behavior, ...) is mandatory to understand the results of the tools in combination with the selected options.