Help troubleshooting a BPF

[7MinSec]

Hello,

I'm on a pentest where the client has 3 APs that are broadcasting 3 networks I want to capture PMKIDs or handshakes for. I've used hcxdumptool in scan mode to find the hardware addresses needed to build a BPF. The building of the BPF is successful, and launching hcxdumptool with the BPF is successful. But then I only see one of the networks and it is never attacked.

Normally I'd think this is a problem on my end, but if I run the tool "wide open" it will see these networks (and many more) and I can see the PMKID capture is successful on some of the in-scope networks.

I could just let the tool run "wide open" until getting all the networks I need but I'm trying to stay in scope and be responsible with my methodology. Plus, unless I'm mistaken there isn't an easy way to pull out PMKIDs/handshakes for just specific network names out of a large capture file?

Thanks,
Brian

[ZerBea]

First of all, this is not an issue, so I'm going to move it to discussions.

Looks like you BPF is not working as expected.

The mac 802.11 header (hcxdumptool is working on) looks like this: to addr1 - from addr2 - BSSID addr3
https://80211notes.blogspot.com/2013/09/understanding-address-fields-in-80211.html
https://www.rfwireless-world.com/Articles/WLAN-MAC-layer-protocol.html
https://www.geeksforgeeks.org/ieee-802-11-mac-frame/

let's say:
AP1 = 111111111111
AP2 = 222222222222
AP3 = 333333333333
BROADCAST = ffffffffffffffff

to attack this three APs and to allow broadcast frames use this filter:
"wlan addr3 ffffffffffff or wlan addr3 111111111111 or wlan addr3 222222222222 or wlan addr3 333333333333"

It is not useful to code a BPF using a CLIENT address, because nearly all state of the art CLIENTs are running MAC randomization!
But if you know the MAC of the CLIENT (e.g. aaaaaaaaaaaa) you can add it, too:
"wlan addr3 ffffffffffff or wlan addr3 111111111111 or wlan addr3 222222222222 or wlan addr3 333333333333 or wlan addr1 aaaaaaaaaaaa or wlan addr2 aaaaaaaaaaaa"
Now you get EAPOL M2 messages from the CLIENT addressed to hcxdumptool, too. Together with hcxdumptools EAPOL M1, hacpcapngtool can calculate a valid MESSAGEPAIR hashcat or JtR can work on (AP-LESS attack).

I use this kind of BPF (more or less advanced than described above) when testing a new driver/adapter:
#361

It is also a good idea to add the operating frequency/channel to hcxdumptools command line instead off scanning the entire frequency range.

BTW:
To get a single PMKID or EAPOL MESSAGEPAIR or BSSID or ESSID or CLIENT or whatever you want from a large dump file, convert the pcapng file to a hc22000 hash file and use hcxhashtool or bash tools to filter whatever you want.
https://hashcat.net/wiki/doku.php?id=cracking_wpawpa2

[7MinSec]

Hello,

First thank you SO much for your fast help. I was really misunderstanding BPF creation. Now that I'm back at the computer, I checked the rcascan and the target for this test is actually:

MAC-AP
111111111111 Corpwifi1 [6]
111111111111 Corpwifi2 [6]
111111111111 Corpwifi3 [12]

Does that change the BPF since the MAC-AP is the same for all SSIDs? I think my BPF-building command would be wlan addr3 ffffffff or wlan addr 111111111111 correct? That seems to be running however I only see Corpwifi1 as actively being attacked.

[7MinSec]

I read this thread (excellent!) and it seems like the "all in one" way to capture the right BPF in this case is something like:

sudo tcpdump -i wlan0mon wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 11:22:33:44:55:66 -ddd > "/tmp/pmkid.bpf

I did create the filter this way and ran hcxdumptool again and the result is the same - only Corpwifi1 shows up as being actively attacked. Maybe I'll eventually get PMKIDs for the other networks too if I'm just patient?

[Jake-Grafton]

The "all in one" method mentioned is outdated. While it IS possible to generate BPFs using other tools (eg. tcpdump), the preferred method is to use hcxdumptool itself.

sudo hcxdumptool --bpfc="wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 11:22:33:44:55:66 or wlan addr3 ff:ff:ff:ff:ff:ff" > filter.bpf

[ZerBea]

sudo tcpdump -i wlan0mon wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 11:22:33:44:55:66 -ddd > "/tmp/pmkid.bp

Three problems:
Don't run hcxdumptool on a virtual monitor interface like wlan0mon, because it setup its own monitor interface.
As @Jake-Grafton mentioned, don't use tcpdump to build the filter, because hcxdumptool uses a different snaplen.
This filter "wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 11:22:33:44:55:66" only attacks one(!) BSSID!

This filter "wlan addr3 ffffffffffff or wlan addr3 111111111111 or wlan addr3 222222222222 or wlan addr3 333333333333 or wlan addr1 aaaaaaaaaaaa or wlan addr2 aaaaaaaaaaaa" attacks 3 different APs and one CLIENT!

Important note:

Óscar Alfonso Díaz (the thread you mentioned) is the author of airgeddon.
He use only a part of hcxdumptool for his script airgeddon - so this thread will not(!) work for you.

[ZerBea]

To make that absolutely clear:
tcpdump:

$ sudo tcpdump -i wlp48s0f4u2u4 wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 11:22:33:44:55:66 -ddd
33
48 0 0 3
100 0 0 8
7 0 0 0
48 0 0 2
76 0 0 0
2 0 0 0
7 0 0 0
64 0 0 6
21 0 2 860116326
72 0 0 4
21 20 0 4386
80 0 0 0
84 0 0 12
21 0 6 4
80 0 0 0
84 0 0 240
21 15 0 192
80 0 0 0
84 0 0 240
21 12 0 208
64 0 0 12
21 0 2 860116326
72 0 0 10
21 7 0 4386
80 0 0 0
84 0 0 12
21 5 0 4
64 0 0 18
21 0 3 860116326
72 0 0 16
21 0 1 4386
6 0 0 262144
6 0 0 0

hcxdumptool (as normal user - not su or sudo):

$ hcxdumptool --bpfc="wlan addr1 11:22:33:44:55:66 or wlan addr2 11:22:33:44:55:66 or wlan addr3 11:22:33:44:55:66"
48 0 0 3
100 0 0 8
7 0 0 0
48 0 0 2
76 0 0 0
2 0 0 0
7 0 0 0
64 0 0 6
21 0 2 860116326
72 0 0 4
21 20 0 4386
80 0 0 0
84 0 0 12
21 0 6 4
80 0 0 0
84 0 0 240
21 15 0 192
80 0 0 0
84 0 0 240
21 12 0 208
64 0 0 12
21 0 2 860116326
72 0 0 10
21 7 0 4386
80 0 0 0
84 0 0 12
21 5 0 4
64 0 0 18
21 0 3 860116326
72 0 0 16
21 0 1 4386
6 0 0 1024
6 0 0 0

different snaplen:

tcpdump: 6 0 0 262144
hcxlabtool: 6 0 0 1024

[ZerBea]

To make that also clear:

$ iw dev
phy#4
	Interface wlp48s0f4u2u4
		ifindex 7
		wdev 0x400000001
		addr 08:be:ac:1c:5c:ac
		type managed
		txpower 0.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

$ sudo hcxdumptool --rcascan=active

$ iw dev
phy#4
	Interface wlp48s0f4u2u4
		ifindex 7
		wdev 0x400000001
		addr 9c:93:e4:a7:81:82
		type monitor
		channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
		txpower 20.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

hcxdumptool/hcxlabtool set its own monitor mode:

$ sudo dmesg
[52561.590351] rtl8xxxu 5-2.4:1.0 wlp48s0f4u2u4: entered promiscuous mode
[52568.362394] rtl8xxxu 5-2.4:1.0 wlp48s0f4u2u4: left promiscuous mode

optimized for hunting AUTHENTICATIONs

channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz

The difference:

$ sudo iw phy phy6 interface add wlan0mon type monitor
$ iw dev
phy#6
	Interface wlan0mon
		ifindex 12
		wdev 0x600000002
		addr 08:be:ac:1c:5c:ac
		type monitor
		txpower 0.00 dBm
	Interface wlp48s0f4u2u4
		ifindex 11
		wdev 0x600000001
		addr 08:be:ac:1c:5c:ac
		type managed
		txpower 0.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

		type monitor
		txpower 0.00 dBm

The warning (--help):

Important recommendation:
-------------------------
Do not set monitor mode by third party tools or third party scripts!
Do not use virtual interfaces (monx, wlanxmon, prismx, ...)!
Do not use virtual machines or emulators!
Do not run other tools that take access to the interface in parallel (except: tshark, wireshark, tcpdump)!
Do not use tools to change the virtual MAC (like macchanger)!
Do not merge (pcapng) dump files, because this destroys assigned hash values!

[7MinSec]

Thanks both of you. I should've been clear that when I did try the tcpdump BPF build, I used the native interface and not a virtual one.

Upon further enumeration of the air space, I'm finding several MAC-AP broadcasting the networks I need, but it's the same as I shared earlier, where one MAC broadcasts all 3 networks in scope. So I followed the BPF build you shared in the first reply (so that I can attack them all):

wlan addr3 ffffffffffff or wlan addr3 111111111111 or wlan addr3 222222222222 or wlan addr3 333333333333

What I see on my screen for MACs and network names:

111111111111 Corpwifi1
222222222222 Corpwifi2
333333333333 Corpwifi1

So I think all three MACs are being enumerated/attacked, but my remaining question is...will this configuration eventually allow me to capture handshakes/PMKIDS for all in-scope networks that are being broadcast from these three devices?

What I'm doing in another window to check what's being captured is periodically run hcxpcapngtool -o hash.hc22000 -E wordlist capture.pcapng and then hcxhashtool -i hash.hc22000 --info=stdout

Thanks for your help/patience with this. I've been trying to read all the content/discussions but it seems like there are a lot of outdated posts out there with the tool flags and other things changing over the years. My end goal is to make a blog post that is kind of a quick start for using these tools to narrow your scope, grab handshakes/PMKIDs, convert as necessary, and crack with hashcat. Will certainly share when finished!

[ZerBea]

"I used the native interface and not a virtual one."
Anyway, wlan0mon is not set by hcxdumptool.

iw is used to set monitor mode:

$ iw dev
phy#0
	Interface wlp48s0f4u2u4
		ifindex 3
		wdev 0x1
		addr 74:da:38:eb:46:0b
		type managed
		txpower 0.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

$ sudo sudo iw wlp48s0f4u2u4 set monitor none

$ iw dev
phy#0
	Interface wlp48s0f4u2u4
		ifindex 3
		wdev 0x1
		addr 74:da:38:eb:46:0b
		type monitor
		txpower 0.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

I'm sure you see the difference.
If not:

$ sudo hcxdumptool -m wlp48s0f4u2u4
$ iw dev
phy#1
	Interface wlp48s0f4u2u4
		ifindex 4
		wdev 0x100000001
		addr b0:ec:e1:9e:90:25
		type monitor
		channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
		txpower 20.00 dBm
		multicast TXQ:
			qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
			0	0	0	0	0	0	0	0		0

"So I think all three MACs are being enumerated/attacked, but my remaining question is...will this configuration eventually allow me to capture handshakes/PMKIDS for all in-scope networks that are being broadcast from these three devices?"
No
you'll see them all, because BROADCAST MACs are allowed: ffffffffffff
wlan addr3 ffffffffffff or wlan addr3 111111111111 or wlan addr3 222222222222 or wlan addr3 333333333333
but only this three ones are under attack: 111111111111, 222222222222, 333333333333

To build a "working" filter it is mandatory to understand 802.11 addressing (addr1, addr2 and add3) and it is mandatory to understand the BPF (capture filter used by Wireshark, tshark and tcpdump too).

[7MinSec]

Thanks I think the filters make much more sense now. Let me try this new filter and I'll report back!

[ZerBea]

To learn how to build a BPF, I suggest to play around with tshark.
Capture filter syntax of hcxdumptool/hcxlabtool, tshark, Wireshark and tcpdump is the same.

Set monitor mode and choose a crowded channel:
$ sudo hcxdumptool -m INTERFACE_NAME -c 6a

test a filter (e.g. show all frames addressed to BROADCAST:
$ tshark -i INTERFACE_NAME -f "wlan addr1 ffffffffffff"

test a filter (e.g. show all mgt frames from a NETWORK (112233445566):
$ tshark -i INTERFACE_NAME -f "wlan addr3 112233445566"

test a filter (e.g. show all mgt frames addressed to an AP (112233445566):
$ tshark -i INTERFACE_NAME -f "wlan addr1 112233445566"

test a filter (e.g. show all mgt frames from an AP (112233445566):
$ tshark -i INTERFACE_NAME -f "wlan addr2 112233445566"

test a more advanced filter (e.g. show all mgt frames from a NETWORK (112233445566) and all PROBEREQUESTs addressed to BROADCAST):
$ tshark -i INTERFACE_NAME -f "wlan addr3 112233445566 or wlan addr3 ffffffffffff"

ignore frames addressed to BRAODCAST
$ tshark -i INTERFACE_NAME -f "not wlan addr1 ffffffffffff"

[ZerBea]

Royal class - filter by frame types.
show only ACK frames:
$ tshark -i INTERFACE_NAME -f "type ctl subtype ack"

ignore ACK frames:
$ tshark -i INTERFACE_NAME -f "not type ctl subtype ack"
This reduce hcxdumptools/hcxlabtools workload, because this useless frame types do not reach the main packet loop.

All this filters are accepted by hcxlabtool/hcxdumptool too:

$ hcxdumptool --bpfc="not type ctl subtype ack"
48 0 0 3
100 0 0 8
7 0 0 0
48 0 0 2
76 0 0 0
7 0 0 0
80 0 0 0
84 0 0 252
21 0 1 212
6 0 0 0
6 0 0 1024

As you can see, building a BPF is not not rocket science.

[7MinSec]

Arrrgggghhh, major user "DOHP!" on my part. Of the network names broadcasted by these APs, two of them are WPA3 SAE! My understanding from this thread and this one and other research is that there is not a direct path to capture/crack a handshake. Discussion 468 mentions using hcxdumptool to test if downgrade is possible but I don't see other posts on how to do this? Looks as if I may be able to check for this via wireshark as well.

[ZerBea]

Add ESSID of the WPA3 AP to a list (e.g. ap.list).
Run hcxdumptool (or better hcxlabtool due to its improved attack mode) with option --essidlist=ap.list.
Wait until the CLIENT tries to associate with hcxlabtool/hcxdumptool (EAPOL M1M2 ROGUE CHALLENGE).

--rds=<digit>             : sort real time display
                             attack mode:
                              default: sort by time (last seen on top)
                               1 = sort by status (last PMKID/EAPOL on top)
                             scan mode:
                               1 = sort by PROBERESPONSE count
                             Columns:
                              R = + AP display     : AP is in TX range or under attack
                              S = + AP display     : AUTHENTICATION KEY MANAGEMENT PSK
                              P = + AP display     : got PMKID hashcat / JtR can work on
                              1 = + AP display     : got EAPOL M1 (CHALLENGE)
                              3 = + AP display     : got EAPOL M1M2M3 or EAPOL M1M2M3M4 (AUTHORIZATION) hashcat / JtR can work on
                              E = + CLIENT display : got EAP-START MESSAGE
                              2 = + CLIENT display : got EAPOL M1M2 (ROGUE CHALLENGE) hashcat / JtR can work on

More information is here:
https://hashcat.net/forum/thread-12255.html

[ZerBea]

Do not set a BPF, because the CLIENT probably uses MAC randomization and hcxlabtool/hcxdumptool responds to its undirected BROADCAST PROBEREQUESTs using a randomized MAC, too. A strict BPF filter prevents this!

Also it is useful to increase the stay time on a frequency to >= 15 seconds.

Use only 2.4GHz band! 5,6,7 GHz CLIENTs will connect to hcxlabtool/hcxdumptool on 2.4GHz!

This attack is called AP-LESS attack. Depending on the conditions, it might take some time.
This is a layer 2 attack and not an EVIL TWIN attack (layer 3 to 7).
The playground of hcxdumptool/hcxlabtool is layer 2 only.
Layer 1 attacks need firmware modifications (device firmware) and driver modifications.
Layer 3 to 7 attacks are phishing attacks.

[7MinSec]

Oh cool! Ok so I'll try this tomorrow when I'm back on the test. Looks like options to use are hcxlabtool --rds=1 --essidlist ap.list -t 15. I don't think I need to do anything with band settings since the tool listens on a by default(?).

[7MinSec]

I think it's working! I got excited and remoted in to the network to try this on a test. The command I posted above worked and I started seeing tons of other networks - but not the ones in scope as they are on another band. The screen was looking like this:

CHA	LAST	A123P	MAC-CL	MAC-AP	ESSID	SCAN
1	21:17:52	p	111111111111	222222222222	NotInScope	2412/1
6	21:17:52	p+++	333333333333	444444444444	NotInScope	2412/1
...	...	...	...	...	...	...

And then after a while, at the very bottom there popped a line like this - without a CHA entry:

CHA	LAST	A123P	MAC-CL	MAC-AP	ESSID	SCAN
	21:19	p++	xxxxxxxxxx	yyyyyyyyyy	CorpWifi1	2412/1

Then I ran hcxpcapngtool to make a .hc22000 file, then hcxhashtool to look at everything inside, I have an entry!

SSID: Corpwifi
...
...
...
HASHLINE: WPA*02.....

All that said, questions:

• Is it expected that my cap file is still full of handshakes and PMKIDs from other networks? I'm thinking yes since I used rds but I tried without rds and the tool seemed to hang(?).
• The A123P - I'm thinking A = attack and the 123P correspond with the help section for rds that you posted?

 1 = + AP display     : got EAPOL M1 (CHALLENGE)
 3 = + AP display     : got EAPOL M1M2M3 or EAPOL M1M2M3M4 (AUTHORIZATION) hashcat / JtR can work on
 2 = + CLIENT display : got EAPOL M1M2 (ROGUE CHALLENGE) hashcat / JtR can work on
 P = + AP display     : got PMKID hashcat / JtR can work on

Thanks so much this is super educational and interesting!

[ZerBea]

First of all it is mandatory to understand the difference between a capture filter (BPF) and a display filter (RDS).
https://tshark.dev/capture/capture_filters/
https://tshark.dev/analyze/packet_hunting/packet_hunting/

RDS is a simple display filter (a Raspberry Pi Zero 1 is not powerful enough to run complex display filters):
rds not set == headless operation == nothing will be displayed
check the incoming pcapng file and you'll see that it increase
a typical hardware configuration is this:
#478 (reply in thread)
In an urban/crowded area, a configuration like this is able to retrieve thousands EAPOL MESSAGES in a couple of hours.

Is it expected that my cap file is still full of handshakes and PMKIDs from other networks? I'm thinking yes...
Yes, because by default hcxlabtool/hcxdumptool get/recieve/retrieve everything that is not filtered by a capture filter (BPF)

... since I used rds but I tried without rds and the tool seemed to hang(?).
No, as explained above, hcxlabtool/hcxdumptool is running in headless mode

The A123P - I'm thinking A = attack and the 123P correspond with the help section for rds that you posted?
Partly yes:
A = AUTHENTICATION KEY MANAGEMENT (AKM)
a P in the column indicates a (P)re Shared Key AKM, hashcat or JtR can work on.
help menu of hcxlabtool:

-rds=<digit>    : enable real time display
                    default = 0 (off)
                    1 = show APs on current channel, show CLIENTs (M1M2ROGUE)
                    2 = show all APs (M1M2, M1M2M3 or PMKID), show CLIENTs (M1M2ROGUE)
                    3 = show all APs, show CLIENTs (M1M2ROGUE)
                    columns:
                     A = AKM (p)re-shared key
                     1 = received M1
                     2 = received M1M2
                     3 = received M1M2M3
                     P = received PMKID

Don't worry about the 2 compiler warnings.

• rcascan is not implemented yet
• the entire GPS stuff has been removed. Plan is to evaluate GPS data now offline by hcxpcapngtool. The RPI isn't fast enough to handle GPS conversation during attack mode,

Sooner or later hcxlabtool will become hcxdumptool 7.0.0

[ZerBea]

You may have noticed it by now, if the requirements mentioned in README.md are met, hcxlabtool/hcxdumptool/hcxtools can do magic:

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.
- Detailed knowledge of filter procedures. (Berkeley Packet Filter, capture filter, display filter, etc.)
- Detailed knowledge of Bolean Operators.
- Operating system: Linux (recommended: kernel >= 6.6, mandatory: kernel >= 5.15)
- Recommendation: Arch Linux (notebooks and desktop systems), OpenWRT (small systems like Raspberry Pi, WiFi router)
- WLAN device chipset must be able to run in monitor mode. MediaTek chipsets are preferred due to active monitor mode capabilities.
- WLAN device driver *must* support monitor and full frame injection mode.
- gcc >= 14 recommended (deprecated versions are not supported: https://gcc.gnu.org/)
- make
- libpcap and libpcap-dev (If internal BPF compiler has been enabled.)
- Raspberry Pi A, B, A+, B+, Zero (WH). (Recommended: Zero or A+, because of a very low power consumption), but notebooks and desktops will work as well.
- GPIO hardware mod recommended (push button and LED) on Raspberry Pi
- To allow 5/6/7GHz packet injection, it is mandatory to uncomment a regulatory domain that support this: /etc/conf.d/wireless-regdom 
- Make sure that the version of hcxdumptool always fits to the version of hcxpcapngtool 

[ZerBea]

And then after a while, at the very bottom there popped a line like this - without a CHA entry
CLIENTs are dynamic. They transmit PROBEREQUESTs on all available channels. That's why it doesn't make sense to add a channel information here. The ASSOCIATION with hcxlabtool/hcxdumptool can be done on any frequency at any time.
That is mentioned in README.md section Warning:
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 convert to a format Hashcat or JtR understands.)

While old school tools are focused on attacks on APs, hcxlabtool/hcxdumptool is focused on layer 2 attacks on CLIENTs.
Instead to get close to a fixed located target AP, let the CLIENT come to you!
But that doesn't mean that hcxlabtool/hcxdumptool is not able to perform the "old school layer 2 attacks" on APs.

[ZerBea]

Last but not least: You mentioned that you are on a penetration test.
Can you imagine what happens if you run a penetration test for a big company and only one CLIENT (of hundreds of CLIENTs) is weak!
weak.zip

$ hcxpcapngtool --all -o weak.22000 -R pr weak.pcapng
$ hashcat -m 22000 --nonce-error-corrections=16  weak.22000 pr

hcxlabtool/hcxdumptool == wide open during attack
hcxpcapngtool == wide open (--all) during conversion
hashcat == wide open (--nonce-error-corrections=16) during cracking process

This (hunt for weak CLIENTs) is the reason why hcxlabtool/hcxdumptool is "wide open" by default.

Attaching a too strict (or faulty) filter is nearly the same as to reduce the 950 HP of a Formula 1 car to 10 HP. You'll not win the race.

[7MinSec]

ZerBea, can't continue to thank you enough. Admittedly I do NOT have the knowledge pre-reqs to be using your tools and wireless pentesting is usually done by other folks on my team, but I really appreciate you helping me along the way and figuring out the BPF and how to do a WPA3 test. I think your last responses all make sense and I'm off to go crack these handshakes.

I think last question just so I make sure I'm recommending proper recommendations for the client: if they set their wireless gear to "WPA3 Only" and not allow WPA2, then:

• Devices that connect to their infrastructure MUST support WPA3
• Downgrade attacks are thwarted because their infrastructure will not allow a WPA2 connection

Do I have that right?

[ZerBea]

Yes, you're right.

Transition mode (WPA2/WPA3) is dangerous. Configure WPA3 only.

Remove old/obsolete entries from the network list.

And additional: turn of the radio whenever it is not needed.

.

[7MinSec]

Fantastic thanks a million again! I'll close the conversation but will likely add an additional comment when I publish some quick start tips for these amazing tools!

[ZerBea]

You're welcome.