Table of Contents Introduction The Findings Additional Analytics and Findings Conclusion Introduction # I was always curious about the wireless devices around me, and I spent a lot of time investigating them — not only the standard 802.11 WiFi but other “custom” RF technologies too. Once, during my experimentation with WiFi protocols and how they actually work, I saw the well-known probe requests from one of my IoT devices that I had for a long time, which needed a specific WiFi AP(Access Point) to work. But what happens when this AP is not around it? It continuously sends probe requests over the air with the specific SSID name that it needs. This is nothing new; people who work in cybersecurity know that this is how things work. There is also a well-known attack type called a “Karma Attack”, where you can make a dynamic AP that corresponds to the specific SSID that the device is searching for. So, if the device says, “I am looking for ‘MyHomeWifi’,” the attacker brings up an AP with the same name and waits for the device to try to connect. But, from this comes one more problem. If you set the same type of encryption (for example, WPA2/WPA3 etc.), the device that searches for that SSID will send a Half Handshake to the AP. If we capture this, we can still crack it using an offline dictionary attack against the password of the original SSID. So, TL;DR: if you turn on the WiFi on your phone or IoT device (whether portable or not), it is possible for someone to crack the password of your saved networks just by bringing up an AP with the same name as the probe request that the device sends. Nothing new, right? But what if we blacklist all the phone vendors (by MAC address, where is possible) to make space for IoT devices, and start this Android NetHunter APP around a big city? I should say that this public script search for all WiFi devices without looking for MAC but u can search for them manually by SSID name. To able to run this script you need GPS demon witch should listen on correspond port. I use script specifically for probe requests to find specific, repeatable patterns of SSIDs around the city. I use my specially configured phone for security-related stuff; it is rooted and has the necessary tools to make this happen easily and with minimal effort. I use the internal WiFi card and GPS on the phone to remove the need for additional hardware and make this really portable - All in one device. OnePlus7Pro The Findings # So, after a few attempts to collect probe requests around the city, I got some interesting repeatable SSIDs like “DefaultSSID” and “moduletest” (I haven’t investigated the latter yet, but it is a completely different device). They appear in different locations with completely different MACs, but each of them has its own specific IoT vendor MAC prefix. I started with “DefaultSSID”. I made an AP that responds to that name and tried to let it onto my AP to understand what is behind this device. The device wanted to connect to an AP with a specific password, so I used the half-handshake attack to try to guess it. The password was easy to crack with common wordlists. So now, I started a new AP with the correct name and password, and voilà, the device connected to it. The next thing was to perform an Nmap scan to find out what services these devices provided, if any. The only port that I got on them was port 80 (TCP) - HTTP service. But I got an HTTP Basic Auth prompt everywhere I got a response from my web fuzzer: 401 POST/GET 1l 2w 22c http://12.0.0.12/config 401 POST/GET 1l 2w 22c http://12.0.0.12/service 401 POST/GET 1l 2w 22c http://12.0.0.12/update 401 POST/GET 1l 2w 22c http://12.0.0.12/default 401 POST/GET 1l 2w 22c http://12.0.0.12/network 401 POST/GET 1l 2w 22c http://12.0.0.12/server I tried to brute-force the username and password, but without any success. I tried on different devices around me, and everywhere the result was the same: the same port asking for an HTTP Basic username and password that I didn’t know, and it was not an “admin:admin” type of credential. The only interesting thing that I found with a 200 OK response was: 200 POST/GET 255l 3433w 22950c http://12.0.0.12/license Which, unfortunately, did not contain any useful information because it was some sort of general license… /license For months I gave up, because i couldn’t find someone that I know to own this type of device(very sad). Until one day I woke up with the motivation to try one more time to investigate this interesting devices that is almost everywhere wherever I go. Again, I didn’t have much success with the brute-force(I try more than 50k combinations of possible IoT passwords), so this time I started digging on the internet to find more information about these endpoints that I saw on the web fuzzer. After an hour of searching, I found an interesting blog by Alexandre Vicenzi : mitsubishi-wifi-adapter . The screenshots from the blog didn’t speak to me (because I had never seen this web interface before), ...