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
83370fb
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:
aircrack-ng/rtl8812au#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.
775c336
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:
#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:
#121 (comment)
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_htc and 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.

[fa1rid]

Nice! I understand many things now. Also by trying and testing by myself I learn a lot by observing the behavior every run.
You didn't tell me about M3M4zeroed. When I see:

M1M2
M2M3
M3M4ZEROED 

as I know wen need only M2M3. How's it different then if we don't see zeroed mentioned?

Please explain the use case of hcxpcapngtool with option --all with example, how is it useful and when to use it?

Thank you.

[fa1rid]

BTW, do you know how to install OpenCL runtime for Intel CPUs on Debian based machines? I'm struggling with that. I have 2X Xeon® E5-4667 v3 with 64 cores in total, it's a waste not to use with hashcat.

[ZerBea]

We distingush 2 M4 EAPOL frames:
M4 with SNONCE (f283f5f0db28c7202635acc196ce0a2db6378e7181cbfcb76de18e68cedb7dd5)
M4 with zeroed SNONCE (0000000000000000000000000000000000000000000000000000000000000)
From the first one, we can recover the PSK (in combination with an M1 or M3 from the AP).
From the second one, it is not possible.

hcxpcapngtool convert only the best handshake for an ESSID - MAC_AP -MAC_STA. That keeps the hash file small.
hcxpcapngtool --all convert all handshakes. This is mainly for analysis purpose on M1M2 pairs

examples:
$ hcxpcapngtool -o best.22000 *.pcapng
$ hcxpcapngtool --all -o all.22000 *.pcapng

Compare both hash files (best.22000 and all.22000) and you'll notice that all.22000 contain more records.

This is the upstream of intel compute runtime:
https://01.org/compute-runtime

or via Debian packet manager:
https://packages.debian.org/source/sid/intel-compute-runtime
https://packages.qa.debian.org/i/intel-compute-runtime.html

[ZerBea]

Please notice:
I try to fix reported issues, very soon. But in 99,9% this issues are related to the device driver (driver doesn't support ioctl system calls or driver doesn't support full monitor mode) or a misconfigured system (crda, NetworkManager/wpa-suplicant running, virtual interface wlanXmon instead of physical interface).
Due to high density attacks, the hardware requirements of hcxdumptool are much higher than running e.g. aircrack.
The same applies to the user's knowledge. There is no simple script to get hcxtools/hcxdumptool work. The user must know what she/he is doing. Otherwise the results are not as expected.

[fa1rid]

Yes I understand your points.

So for the EAPOL, if I get this it means PSK is not recoverable (Is it called unauthenticated handshake?) :

M1M2
M2M3
M3M4ZEROED

but if I get this it means it's recoverable, right?

M1M2
M2M3
M3M4

[ZerBea]

Not 100% correct:

M1M2 (challenge = not authorized)
M2M3 (confirm AP = authorized)
M3M4 (confirm CLIENT = authorized)
M1M4 (confirm CLIENT = authorized)

M1M2 (challenge = not authorized)
M2M3 (confirm AP = authorized)
M3M4ZEROED (confirm CLIENT = authorized but you can't calculate the PSK from this message pair due to zeroed SNONCE)
M1M4ZEROED (confirm CLIENT = authorized but you can't calculate the PSK from this message pair due to zeroed SNONCE)

A valid PSK is recoverable from every NONZEROED message pair (one message from the AP M1 or M3 the other message from the CLIENT M2 or M4).
Some of them are challenges (M1M2) = not authorized = CLIENT can belong to a different network
Some of them are confirmations (M2M3, M3M4 M1M4) = authorized = CLIENT belong to this network

[fa1rid]

Here's an example from my network scan:

15:10:28   6 ffffffffffff 101xxxxfc479 MyBSSID [BEACON]
15:10:43   5 507xxxx1d6dd 008xxxx35459 MyBSSID-5G [ROGUE PROBERESPONSE]
15:11:28   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M1M2 EAPOLTIME:3320 RC:4 KDV:2]
15:11:28   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M2M3 EAPOLTIME:8947 RC:5 KDV:2]
15:11:28   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M3M4ZEROED EAPOLTIME:2836 RC:5 KDV:2]
15:11:29   6 4c1xxxxdd479 008xxxx3545a MyBSSID [ROGUE PROBERESPONSE]
15:11:29   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [PROBERESPONSE]
15:11:30   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [AUTHENTICATION]]
15:12:08   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M1M2 EAPOLTIME:3807 RC:3 KDV:2]
15:12:08   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M2M3 EAPOLTIME:7494 RC:4 KDV:2]
15:12:08   6 4c1xxxxdd479 101xxxxfc479 MyBSSID [EAPOL:M3M4ZEROED EAPOLTIME:3408 RC:4 KDV:2]

Why did I get EAPOL handshake two times from the same client? and why I have [AUTHENTICATION] one time only and I have two handshakes? what does all that mean please?
Thanks again for your effort.

[ZerBea]

hcxdumptool is an attack tool. In case of a successful attack, you will receive the EAPOL messages.
But hcxdumptool is also a passive dumper. In case of a transmitted EAPOL message, it will show you the message and it will store it. That means, every time your CLIENT connect to your network, hcxdumptool will receive it and store it.

[ZerBea]

To avoid spamming the real time waterfall display, hcxdumptool print some information only once at first occurrence. It is described in --help:

--enable_status=<digit>            : enable real-time display (waterfall)
                                     only incomming traffic
                                     only once at the first occurrence due to MAC randomization of CLIENTs

[ZerBea]

Some examples:
EAPOL frames and EAP frames are important. So hcxdumptool will print every detected message pair.
Authentications and associations are not important. So only the first one is shown.
Beacons are useless. So only the first one is shown.

[fa1rid]

Aha, that's why, you are hiding them.
Alright fine, thanks for letting me know :)

[fa1rid]

Can you please elaborate on authenticated handshake and unauthenticated handshake. I once captured unauthenticated one but I don't remember what was the message showing in hcxdumptool output.

[fa1rid]

Okay I found the unauthenticated one

SSID.......: MySSID
MAC_AP.....: 302xxxxxf871 (unknown)
MAC_CLIENT.: 0ccxxxxx5482 (unknown)
VERSION....: 802.1X-2001 (1)
KEY VERSION: WPA2
REPLAYCOUNT: 64590
RC INFO....: NC not required
RC INFO....: ROGUE attack / NC not required
MP M1M2 E2.: challenge
MIC........: 1bf4b24878a84f59336ae7c526d05756

Is the PSK recoverable from this?

[ZerBea]

Yes, you can recover a PSK from this message pair. The recovered PSK will belong to the network shown as MySSID.

[ZerBea]

Please convert your example from here:
#121 (comment)
$ hcxpcapngtool --all -o all.22000 test.pcapng
and
$ hcxpcapngtool -o best.22000 test.pcapng

Than compare both files. You'll notice that you have much more handshakes to choose when running
$ hcxhashtool -i all.22000 --info=stdout
than running
$ hcxhashtool -i best.22000 --info=stdout

[fa1rid]

Please convert your example from here:
#121 (comment)
$ hcxpcapngtool --all -o all.22000 test.pcapng
and
$ hcxpcapngtool -o best.22000 test.pcapng

Than compare both files. You'll notice that you have much more handshakes to choose when running
$ hcxhashtool -i all.22000 --info=stdout
than running
$ hcxhashtool -i best.22000 --info=stdout

What does that mean? I mean what's the point you are telling me?

[ZerBea]

Running by default, hcxpcapngtool choose and convert only the best message pair for a hashcat/JtR task.
Running --all, hcxpcapngtool convert all message pairs.
Now, you can choose (running hcxhashtool) the best handshake for a hashcat/JtR task.
That is a big difference!

[fa1rid]

hcxhastool -i test.22000 --essid-group

I prefer if you can make it output ESSID name next to the hex in the file name, so it will be something like this:

416e64....-ESSID_name.22000

It's difficult now to know which essid is which by looking at the hex
Also it's time consuming to look at the info with --info and extract what you want.

[ZerBea]

No. We decided HEX because an ESSID can contain characters from 0x00 to 0xff:
"The 802.11 standards prior to the 2012 edition did not define any particular encoding/representation for SSIDs, which were expected to be treated and handled as an arbitrary sequence of 0–32 octets that are not limited to printable characters"
https://en.wikipedia.org/wiki/Service_set_(802.11_network)
Using this characters can destroy your file system and printing this characters can destroy your terminal.
Conversion from HEX to ASCII can be done in an easy way, running bash scripts and bash tools, pearl scripts or whoismac -x

[fa1rid]

hcxdumptool still capturing handshakes and PMKIDs from access points that are different than the specified in the list. Why?

[ZerBea]

That behavior is explained here:
#121 (comment)
In every case, hcxdumptool is a passive dumper. It captures everything on the channel.
The Filterlists (filterlist_ap and filterlist_client) are only in the transmit branch. Depending on filtermode, entries are protected or will be attacked.
If you don't want this behavior, you must set the Berkeley Packet Filter (BPF).

--bpfc=<file>                      : input Berkeley Packet Filter (BPF) code
                                     steps to create a BPF (it only has to be done once):
                                      set hcxdumptool monitormode
                                       $ hcxumptool -m <interface>
                                      create BPF to protect a MAC
                                       $ tcpdump -i <interface> not wlan addr1 11:22:33:44:55:66 and not wlan addr2 11:22:33:44:55:66 -ddd > protect.bpf
                                       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 -ddd > attack.bpf
                                       not recommended, because important pre-authentication frames will be lost due to MAC randomization of the CLIENTs
                                      use the BPF code
                                       $ hcxumptool -i <interface> --bpfc=attack.bpf ...
                                     see man pcap-filter for a list of all filter options

[ZerBea]

By latest commit:
90a0e0b
I added this to help menu:

affected by filter: incoming and outgoing traffic

--bpfc=<file>                      : input Berkeley Packet Filter (BPF) code
                                     affected: incoming and outgoing traffic
                                     steps to create a BPF (it only has to be done once):
                                      set hcxdumptool monitormode
                                       $ hcxumptool -m <interface>
                                      create BPF to protect a MAC
                                       $ tcpdump -i <interface> not wlan addr1 11:22:33:44:55:66 and not wlan addr2 11:22:33:44:55:66 -ddd > protect.bpf
                                       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 -ddd > attack.bpf
                                       not recommended, because important pre-authentication frames will be lost due to MAC randomization of the CLIENTs
                                      use the BPF code
                                       $ hcxumptool -i <interface> --bpfc=attack.bpf ...
                                     see man pcap-filter for a list of all filter options

read more, here:
https://en.wikipedia.org/wiki/Berkeley_Packet_Filter
and here:
https://biot.com/capstats/bpf.html
The BPF is a very powqerfull and fast filter.

affected by filter: outgoing traffic

--filtermode=<digit>               : mode for filter list
                                     mandatory in combination with --filterlist_ap and/or --filterlist_client
                                     affected: only outgoing traffic
                                               in every case, hcxdumptool is a 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

[fa1rid]

I got one PKMID on 5G band but hcxpcapngtool says it useless PKMID, why?

[ZerBea]

Like zeroed M4 messages, PMKIDs and PMKs can be zeroed, too. You can't recover the PSK from them.
hcxdumptool and hcxpcapngtool detect this an inform you.

[fa1rid]

Any update on 5GHz chipsets that can de-authenticate connected users?
Anything supports full monitor mode?

[ZerBea]

This one is working fine (README.md):
ALFA AWUS036ACM, ID 0e8d:7612 MediaTek Inc. MT7612U 802.11a/b/g/n/ac Wireless Adapter
As well as the devices which are based on RT5572 chipset, e.g.:
CSL 300MBit 300649, ID 148f:5572 Ralink Technology, Corp. RT5572 Wireless Adapter

Both drivers are part of the mainline kernel.
MT7612U driver mt76x2:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/mediatek/mt76/mt76x2?h=v5.14.9
RT5572 driver rt2x00:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/ralink/rt2x00?h=v5.14.9

Please notice:
Regulatory domain must be set to allow to transmit on 5GHz.
Explained here:
https://hashcat.net/forum/thread-10378-post-53719.html#pid53719

[fa1rid]

I have difficulties finding the mentioned models for sale online. Do you know where can I buy them?

How about the RTL8814AU (ALFA AWUS1900)?

[ZerBea]

Not recommended WiFi chipsets (README.md):
Intel PRO/Wireless (due to MICROCODE issues)
Broadcom (neither monitor mode nor frame injection)
Realtek RTL8811AU, RTL8812AU, RTL 8814AU (due to NETLINK dependency)

There is no RTL 8814AU mainline kernel driver and you have to install the driver from here:
https://github.com/aircrack-ng/rtl8814au
Beside the NETLINK dependency, there are lot of problems:
https://github.com/aircrack-ng/rtl8814au/issues

Please notice that hcxdumptool doesn't support NETLINK, because NETLINK communication is very much asynchronous. Instead it use ioctl() system calls, which are purely synchronous. The difference is explained here:
https://www.quora.com/What-are-the-differences-between-netlink-sockets-and-ioctl-calls?share=1

BTW:
This adapters (both mt76 chipsets) are working fine, too:
TP-LINK Archer T2UH, ID 148f:761a Ralink Technology, Corp. MT7610U ("Archer T2U" 2.4G+5G WLAN Adapter)
ASUS USB-AC51, ID 0b05:17d1 ASUSTek Computer, Inc. AC51 802.11a/b/g/n/ac Wireless Adapter [Mediatek MT7610U]
The driver is part of the mainline kernel and well maintained:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/net/wireless/mediatek/mt76/mt76x0?h=v5.14.9

[fa1rid]

Oh I didn't see the RTL 8814AU because there is space after RTL
Yes I found the TP-LINK Archer T2UH.
I also found Netgear A6210 on Amazon, it should have the MT7612U. It's better than the MT7601U I guess?

[ZerBea]

MT7612U is not better than MT7601U, but it is much newer. All mt76 drivers are fantastic and well maintained. Latest Linux kernel is mandatory!
I purchased two TP-LINK Archer T2UH, before they are sold out. Both of them are running fine on 2.4 and 5GHz. The same applies to the ASUS USB-AC51.