search

justcallmekoko / ESP32Marauder

A suite of WiFi/Bluetooth offensive and defensive tools for the ESP32
5.76k stars 627 forks source link

Probe request filtering #92

Open 6q6 opened 3 years ago

6q6 commented 3 years ago

Would it be possible to add probe request filtering based on MAC with (one) of the following methods?

Filtering input methods:

justcallmekoko commented 3 years ago

This would be possible to implement. I like option 2 as I think this would be easier to implement AND use.

The way I am imagining it is this... Run a wifi scan to build a list of APs and Clients. Select AP mac or ESSID to filter on using Select APs and/or select Client macs to filter on using Select Clients.

Probe sniff function sniffs probes as expected. Once it detect a probe req, checks to see if there are any APs or Clients in the list of "active" APs and Clients. If there are not, prints the probe req info to screen as it does currently. If there are, only prints the probe req info to the screen if those macs are somewhere in the probe req.

Edit: This would depend on adding functionality to allow the WiFi scans to detect clients and save them to their own list. This would also probably eat up A LOT of memory depending on the area you are in.

I would also need to add functionality to select clients to "activate" for targeting.

6q6 commented 3 years ago

This functionality would perform great the way you described it, and would be less obfuscation regarding menu navigation to pull this off.

And the connected Wi-Fi Client function would be an amazing feature to bring this all under!

However there is one problem, you won't be able to detect/list connected clients since these won't scream out probe requests after they're succesfully associated to the AP. (Correct me if I'm wrong)

And now some speculation...

Maybe a (sub)function (bye no obfuscation) that mainly aims at performing various recon scans to:

justcallmekoko commented 3 years ago

This functionality would perform great the way you described it, and would be less obfuscation regarding menu navigation to pull this off.

And the connected Wi-Fi Client function would be an amazing feature to bring this all under!

However there is one problem, you won't be able to detect/list connected clients since these won't scream out probe requests after they're succesfully associated to the AP. (Correct me if I'm wrong)

This is correct. Once they are connected, they have no reason to send probes.

And now some speculation...

Maybe a (sub)function (bye no obfuscation) that mainly aims at performing various recon scans to:

  • List ESSID's connected clients;
    • Performed in a way that you select the AP (ESSID) that you want to enumerate the connected clients of, and performing a mini deauth attack to discconnect the associated clients. (Deauth>monitor proces repeating if necessary) These clients will scream out probe requests the moment they are disassociated with hopefully one aimed at the targeted AP ESSID. Which will then be fetched by the Marauder to "list" connected clients of that AP based on matching ESSID's and add them to an individual "client list" for selection later on.
  • List and filter unpaired clients sending out probe requests:

I already want to do this for PMKID/EAPOL frame capture. To force handshakes, I want to send mini deauth attacks as each AP is discovered in the scan. The same concept can be applied to the probe request scan. I am working on a Settings function of the Marauder now. One of the settings I plan to include would be to allow the user to run "active" or "passive" PMKID scans. "active" scans would employ the mini deauth method and "passive" would not. I can make the same setting for probe request scan.

Maybe a way you can save memory is that when a MAC is detected it only saves the specific address and adding "new" probe reqs to a field when they're not listed yet. Regarding the "targetting", Is flagging an option? If so you could trying using bits to define these, i.e. 1=targetted 0=untargetted.

This is actually something I do now. I maintain a list of APs. Each AP is represented by a struct that stores its BSSID, ESSID, Channel, and a bool that represents whether or not it is targeted.