[PAYLOAD] Open AP Nmap Scanner

[Darren Kitchen]

This payload scans for open access points, then connects to each and runs an Nmap scan saving logs to the loot folder

https://github.com/hak5/owl-payloads/tree/master/payloads/library/wifi/Open-AP-Nmap-Scanner

[Orca]

I hope it's appropriate to ask questions here.  If not let me know, and move this if possible to where it's relevant.

Can someone post a snippet of what to expect to see in the log if when this payload runs succesfully?

I've loaded it to my Owl.  I checked to make sure the payload is in place and attached it to an Anker power bank.

When it's powered on eventually the LED is solid red and I'm not sure if that's the expected behavior.

I took the Owl with this payload to my local mall to see what I could find and I know there are a few open access points there from the Starbucks, Apple Store, and mall wifi.

When I got back home to check the loot directory I can see that a directory was created for this specific payload but there are no logs saved to it.  I checked the USB drive attached to the Owl and it too had a directory created for the payload and it too was empty.

So basically I'm have a small expectation of what to see but I'm not seeing it...

Any help would be appreciated.

 

Thanks

[JAL21]

Hi, Here’s a link to what the LED means, 

https://docs.hak5.org/hc/en-us/articles/360033504034-LED

also if you read the payload and loot for the LED settings, you can see what the owl is supposed to do! 

Hope this helps!

[chrizree]

I found some odd behavior using this script today. It stops executing and the reason for it is logic but at the same time... yeah, odd... Some executions of the payload script works pretty much as expected, but sometimes it just stops. Even if the payload.log file says it has found, for example, 2 open access point to scan it just scans the first but halts on the second one. Sometime it halts on the first AP found. As I was analyzing all the files produced during a scan that are placed in the /tmp directory, I observed the fact that the payload script identifies an AP as "open" but when looking through the wifi_scan file in /tmp that specific AP is actually encrypted. The next thing that is strange is that the identified AP is nameless, i.e. the open file in /tmp contains a line/row that is all blank.

Let's say that the payload.log file has the following content

Found 1 open access points
---------------------------------------
Selected AP MAC: 00:11:22:33:44:55 (bogus MAC of course...)
Connecting to Open WiFi AP: (i.e. there is nothing here, just blank)

Then, when looking in the wifi_scan file, the AP with the same MAC address as above has "Encryption key:on" and it also actually has an ESSID (i.e. not empty as the payload says).

All this makes the payload less useful, or at least a bit "unsteady" as you can't really rely on getting the correct output/result from it. I haven't got time at the moment to try to find what goes wrong codewise, just wanting to highlight it if anyone else has had the same experience.

[chrizree]

I was planning to edit my previous post, but it will just get cluttered so I posted this separately for visibility.

Here's my findings and suggestion for a solution.

The line below in the "scan_wifi" function in the payload script
cat /tmp/wifi_scan | grep "Encryption key:off" -A1 | grep ESSID | sort | uniq | cut -c 28- | sed "s/.$//g" > /tmp/open
also grabs open APs with no ESSID string, this causes the script to stop executing since it's not possible for the later "connect_wifi" function to actually connect to an ESSID that has no name. The current payload script also grabs the wrong MAC address for the "empty" ESSID.

If there, for any reason, is an AP available in the air that has "Encryption key:off" and also has an ESSID that is completely blank/empty, then it catches just that, an empty string since that is the output from iwlist. Nothing to argue about, it's a simple fact that such a scenario can exist. In my case it seems to be some Chromecast that is in guest mode since the MAC of the empty string ESSID starts with FA:8F:CA (seems to be a known indicator of guest mode Chromecasts but it could also be other Google devices as well I guess, such as the Mini). So, if you are unlucky to catch an empty ESSID AP during engagements, it doesn't matter if you have 1 or 198 potential APs to scan in the list,
they will all be gone (not scanned) since the script sorts the AP input from the iwlist scan putting the empty one first and hence stopping the rest of the execution/scanning.

What also happens is that when the "check_ap" function runs the following line
current_ap_mac=$(cat /tmp/wifi_scan | grep "$current_ap" -B5 | grep Address | awk {'print $5'} | head -1)
it just grabs the MAC address of the first available AP listed in the iwlist scan, regardless if it's open or encrypted, leaving the payload script with a non relevant MAC address.

The conclusion is that when the script encounters an empty string ESSID, it gets just that, an empty ESSID string, and also grabs the wrong MAC address plus the bad fact that the script halts altogether.

So, in order to fix this, there needs to be some handling of empty string ESSIDs in the payload script. I put an if statement in the "check_ap" function after the first line that says
current_ap=$(sed -n "$on"p /tmp/open)
looking like this
if [ -z "$current_ap" ]
then
    return 1
fi

The above adjustment to the payload script seems to work for me, at least the script doesn't grab the wrong MAC address and/or stops executing when getting a blank ESSID in return from the iwlist scan. You won't get the empty ESSID APs included in the scan results though. A reverted and slightly tweaked payload can be created for this, perhaps named "FindChromecastsToRickRoll" 🙂

[JAL21]

7 hours ago, chrizree said:

Thank you so much @chrizreei will apply that solution this weekend, thank you!