WiFi Pineapple Detection Made Easy with Amec0e

WiFi Pineapple Detection Made Easy

PineScan & MultiSSID in Action with the FEBERIS PRO for your Flipper Zero

Introduction:

Hi everyone, Amec0e here and we are back with another article which might be a little shorter than my previous ones, but today I am excited to talk about the FEBERIS PRO By Sapsan while also unveiling two new features for both the FEBERIS PRO Firmware (koko fork) and the ESP32 Marauder project by justcallmekoko

Alongside a quick demonstration of the new features, which I have been working on for this article, there is also a discount code at the end you can use towards your FEBERIS Pro orders :)

So What is the FEBERIS Pro?

The FEBERIS Pro created by Sapsan and officially distributed by LAB401 is a fantastic addition for the Flipper Zero. This little thing packs within it 2x CC1101 Radio Modules covering frequencies 433MHz and 868MHz, an NRF24 Radio Module for things like vulnerable mouse and keyboards, an ESP32 with BLE and WiFi, with a built-in GPS Module for things such as wardriving with the Flipper Zero.

It comes with 4x antennas all of which are 3dBi gain, 2x 2.4GHz, 1x 433MHz and 1x 868MHz which gives a nice horizontal waveform. The C1101 SubGHz modules have a supported frequency range of 300-348 MHz, 387-464 MHz and 779-928 MHz bands.

Now we will not be going over is the basic usage of operations here, however can find out more about its basic usage here

And it can also be purchased from LAB401 here.

What are these New Features?

The two new features I will be demonstrating are "pinescan" and "multissid" for detecting the WiFi Pineapple. All of the testing for this was done using my WiFi Pineapple MK7.

Now forewarning, this feature is not a replacement for a proper WIDS like Kismet for example, nor is it fool proof but does serve as a PoC to show that simpler detection can be done on the Flipper Zero and ESP32 Boards like FEBERIS Pro. The Pineapple is also good at what it does too.

Features of PineScan:

• Detect Pineapple Access points via a hardcoded List of OUI Vendors (SUSP_OUI).
• Detects Pineapple Spoofed AP Pool via tagged parameters and capabilities (TAG+SUSP_CAP).
• Extracts the Correct Channel from the beacon (This is to avoid showing the incorrect channel when using a more suited antenna like the FEBERIS Pro has).
• Easy to Add more OUI's in a PR on Github, Can hold up to 20 MACs Per Vendor.
• Limits the display output to avoid Spamming when you have a WiFi Pineapple Broadcasting 50 SSIDs (Yes I stress tested!).

Features of MultiSSID:

• Detect AP if a Single MAC broadcasts 3 or more SSIDs (This includes the hidden SSID).
• Same as Pinescan this extracts the correct channel from the beacon (This is to avoid showing the incorrect channel when using the FEBERIS Pro).
• Same as Pinescan this limits the display output to avoid Spamming when you have a WiFi Pineapple broadcasting large amounts of SSIDs.

To summarise both strengths of each scan:

MultiSSID - Good for edge cases, more false positive prone. Pinescan - Good for detecting WiFi Pineapple Spoofed Pool APs.

VIDEO DEMONSTRATION OF FEATURES

NOTE: Firmware used was Unleashed 081E, Marauder firmware version used was 1.4.6. There has since been an update which I will likely have already compiled and uploaded for you to download down below.

The Detection Methods

So there are 3 main detections among two new options we demonstrated in the video above. These are:

• SUSP_OUI
• Multi_SSID
• TAG+SUSP_CAP

Each one has been built and tested using a WiFi Pineapple MK7 with the OpenAP using the Impersonation Tab/Spoofed AP Pool in the WebUI.

SUSP_OUI - This is the first check that is done and this simply extracts the first 6 bytes (00:00:00) of the MAC address which commonly points to a specific vendor/nic manufacturer. For some specific OUI's we also check to see if the privacy bit is set to 0 which would indicate that the access point is not using encryption, if it is 1 then it is a Protected Access Point. This is a simple method to check but it is quite effective.

Currently this is the list of OUI's it is checking for, their security detection condition along with the vendor name.

Vendor: Alfa Inc. Condition: SUSPICIOUS_WHEN_OPEN OUI: 00:C0:CA

(WiFi Pineapple MK7) Vendor: Orient Power Home Network Ltd Condition: SUSPICIOUS_ALWAYS OUI: 00:13:37

(WiFi Pineapple MK7) Vendor: IEEE Registration Authority Condition: SUSPICIOUS_WHEN_OPEN OUI: 0C:EF:AF

(WiFi Pineapple Management OUIs Locally Administered) Vendor: None Condition: SUSPICIOUS_WHEN_PROTECTED OUI: 02:C0:CA, 02:13:37

(WiFi Pineapple Nano) Vendor: Shenzhen Century Xinyang Technology Co Ltd Condition: SUSPICIOUS_WHEN_OPEN OUI: 1C:BF:CE

Vendor: MediaTek Condition: SUSPICIOUS_ALWAYS OUI: 00:0A:00, 00:0C:43, 00:0C:E7, 00:17:A5

Vendor: Panda Wireless Inc Condition: SUSPICIOUS_ALWAYS OUI: 9C:EF:D5, 9C:E5:D5

Vendor: None Condition: SUSPICIOUS_ALWAYS OUI: DE:AD:BE

This can be added too in the source code which I will release with the article.

Next up we have:

Multi_SSID - This keeps a list of all access points seen up to 100, the list is then cleared to make room for more APs. It takes the full SSID and produces a hash and it does this for every unique mac address seen, if a single MAC has more than 3 SSIDs hashes (Including the hidden network) then it is flagged as an AP advertising multiple SSIDs from a single MAC.

The other detection is:

TAG+SUSP_CAP - This uses a combination of extracting the Capabilities of the Access Point and the Tagged Parameters of the Access Point from the beacon frame. If the access point has a capability of 0x0001 and has exactly 2 Tagged Parameters then this triggers the TAG+SUSP_CAP detection.

The TAG+SUSP_CAP took a little more time to stumble onto because while the Multi_SSID worked great, the downfall is, what if the user simply just clicks "Randomize Source MAC". Well, then the above Multi_SSID will now no longer detect the pineapple, so I again went back to examine the beacon frames the WiFi Pineapple uses to broadcast large numbers of APs comfortably.

It is worth noting that the "pinescan" and "multissid" sniffer option use two structs each so it has a general AP tracking pool and a confirmed tracking AP pool. This allows the scan to only display one unique MAC address entry as well as clear the AP list once full to keep the lists from growing too much beyond their set limits.

The general AP pool is set to 100 APs after which it will clear the tracking list and allow you to continue scanning in the same session (you will see a message in the log file when this happens and it is cleared). The confirmed list has a max of 100 APs also.

Finding TAG+SUSP_CAP

At first I managed to notice a common occurrence that not many access points actually had, which is the capabilities flag set to 0x0001.

In the above image, there was 7,900 packets only 5 were displayed and only from 3 Different Access Points.

This already was a strong indication that not many access points commonly use that set capability flag, however it is not 0. This means this alone could not be used as a reliable method of detecting multiple Access Points all from different MAC Addresses like the WiFi Pineapple does.

Out of 38,000 packets from a rough 1 hour drive, of all the packets combined there was a total of 115 (not APs but packets) that had the same 0x0001 Capability. So I gathered further data and sifted through around 19 different pcaps, this was well over 100,000 packets from different parts of the world (thanks to friends for gathering beacon data from different countries), of which 20 APs used the same capability of 0x0001. This still however was not enough, so back to a pineapple packet I went.

Now I did after staring at the beacon frame for around a good 20 minutes and a refreshment of coffee (much needed) I noticed something pretty significant, take a look at the Tagged parameters...

It has just two tagged parameters, SSID and Channel. This is an absolute bare bone packet to throw up a large amount of access points without slowing down the Pineapple with its limited resources. This itself is uncommon for commercially available Access Points, 100% of the access points that did match the 0x0001 capability flag had MORE than two tagged parameters in every case.

Now it is not to say you cannot throw up an extremely basic network like this, you can in fact do the same with Marauder. It has a barebone packet it uses with a 0x0401 Capability (so this would not be detected by our detection script) but also only throws up one Tagged Parameter which if we were to only do the detection using Tagged only (searching if there is only 2 tagged parameters) this would trigger the detection. However just because you can throw up an access point with a esp32 with the bare minimum information does not mean it is malicious. It could simply be to make it as efficient and light weight as possible while still providing the user the functionality they require.

So if you have made it this far you will start to get the picture of what I was really trying to do, which was being memory efficient, reduce false positives and target a specific device like the WiFi Pineapple, and this is why we include the suspicious capability flag that you cannot change with ease on the MK7.

In any case the false positives you may encounter will likely be from SUSP_OUI and the MULTI_SSID. If you see TAG+SUSP_CAP in PineScan that is a strong indication of a WiFi Pineapple using the Spoofed AP Pool. Though this itself could also still be a false positive because as mentioned, anyone can throw up an access point like this themselves. Albeit very uncommon to use just two tagged parameters and a 0x0001 capability.

Some detections like the MULTI_SSID and SUSP_OUI could still catch some edge cases outside of the WiFi Pineapple. These types of detections combined, plus a lot more, can be done with ease using something more powerful than the Flipper Zero and a ESP32 and usually when using a WIDS, it is on something more powerful to perform that type of real-time analysis very quickly. However this PoC shows there are other ways we can detect certain types of attacks using small differences between the WiFi Pineapple and a consumer purchased Wireless Access Point.

NOTE: You can even check other pcaps you have in wireshark yourself by using

wlan.fc.type_subtype == 0x0008 && wlan.fixed.capabilities == 0x0001

Then organising by the lowest packet length first and checking the tagged parameters just as we do above.

Ok, but What Can it Not Do?

Well I am glad you asked! The WiFi Pineapple is good at what it can do and we do have some limitations with these detection methods. Some of these limitations are:

EvilWPA Cannot detect the EvilWPA - The EvilWPA is difficult to automate detection for because this can mimic the real access point even down to the exact MAC Address and password (if you know it), even if you are using a managed access point list that allows you to specify what you should be seeing around you VS what you are seeing around you, this is still not effective enough by itself.

As a user we can visually tell the differences if we are looking at something like Kismet, for example my network is all WPA3 security and the WiFi Pineapple MK7 can only use WPA2 or lower. So for me this is an easy red flag to see anything but WPA3 for my network.

To use a managed access point list with the Flipper Zero will increase processing time by constantly needing to read the list or compare with a list that gets offloaded to memory, however the bigger the list the slower it will be and the more memory you use on the ESP32. You will also need to be stationary for it to work.

It is not to say it cannot be done, and this would likely need to be the only detection method to really help make this as effective and as memory efficient as possible. Though this can still be a good way to do it though it is not the route I chose myself because it would not help if it replicates an allowed MAC. To locate this in the wild usually results in a fox hunt to locate the broadcasting device physically by signal strength.

OpenAP (No Spoofed AP Pool) Cannot detect OpenAP - without the use of an offending OUI, this access point by itself cannot be detected as a Pineapple with the way we detect. This is because it operates and looks like a legitimate open access point and has all of the tagged parameters and capabilities that any normal Open or Protected Consumer Access Point uses.

Beacon Intervals Cannot detect by beacon intervals from a beacon frame - This is because the BEACON INTERVAL on the WiFi Pineapple being set to LOW, NORMAL or HIGH and in all cases it will still report in the beacon frame the interval of 102.4ms. The only way this could be done is if the Flipper itself tracks the time between every beacon it sees instead of reading beacon intervals from the packet itself.

Signal Strength Discrepancies It cannot detect by signal strength discrepancies such as regularly seeing say -50 RSSI and then -30 RSSI and then back to the -50 range and consistently fluctuating around that strength. You would notice this pretty easily if you are monitoring the airwaves and you are completely static and nothing around you is interfering with that signal strength.

This would also cause a lot of false positives if you are mobile while detecting as you will see increases and decreases to the signal strength regularly from moving (which of course the Flipper and FEBERIS Pro is just that, mobile platform).

Flashing Instructions

Flashing to the ESP32S2 or Developers Board using the ESP Flasher App:

To flash a ESP32S2 using ESP flasher on Momentum or Unleashed you will need the following Bootloader and Partitions Table. You will also need the firmware bins found below the instructions listed here.

1. First we need to make a new directory in SD Card > apps_data > esp_flasher > S2bins then we can put the bootloader.bin and partitions.bin into this new folder on the Flipper Zero using qFlipper once that is done, then unplug the Flipper from the PC.

2. Next we plug in the ESP32S2 or Developers Board to the Flipper Zero, then once it is plugged in, reboot the Flipper Zero.

3. Then navigate to the ESP Flasher Application.

For Momentum it is: Apps > GPIO > ESP > ESP Flasher

For Unleashed is it: Apps > GPIO > ESP Flasher

4. Next Scroll to the bottom of the ESP Flasher and you will see "Enter Bootloader”, press this and then press the back button once.

5. Scroll up to "Manual Flash" then press center.

6. Select "Bootlader (0x1000)" and select our Bootloader in the S2Bins directory.

7. Then select the "Part Table (0x8000)" and the go to the S2bins Directory and select "Partitions".

8. Now select "FirmwareA (0x10000)" and then select the custom firmware.

9. Scroll down to the bottom and select "Flash - fast" and wait for it to complete writing.

10. Reboot the Flipper after it has flashed and after you have exited the ESP Flasher App and you are done.

Flashing to the FEBERIS Pro using the ESP Flasher App:

The steps here are the same except do not select the bootloader files or the partition table (Steps 1, 6 and 7).

1. Next we plug in the ESP32S2 or Developers Board to the Flipper Zero, then once it is plugged in, reboot the Flipper Zero.

2. Navigate to the ESP Flasher Application.

On Momentum it is: Apps > GPIO > ESP > ESP Flasher

On Unleashed is it: Apps > GPIO > ESP Flasher

3. Next scroll to the bottom of the ESP Flasher and you will see "Enter Bootloader” press this and then press the back button once.

4. Scroll up to "Manual Flash", press center.

5. Now Select "FirmwareA (0x10000)" and then select the custom firmware.

6. Scroll down to the bottom and select "Flash - fast" and wait for it to complete writing.

7. Reboot the Flipper after it has flashed and after you have exited the ESP Flasher App and you are done.

NOTE: It is important you wait a few seconds and then reboot the Flipper Zero after you have plugged in the ESP32.

Firmware, FAP and Source Code

Firmware:

Pinescan and MultiSSID are now merged in version 1.6.0 of the official ESP32Marauder Firmware. This means you can now download the marauder firmware directly from justcallmekoko and install and flash using the instructions here or as you normally would.

FAP:

The FAP is updated in both momentum and unleashed latest dev build so you can simply download and install a dev build of either firmwares (assuming you also updated marauder to 1.6.0 or above) and you will have the new options available to you. No need to download the firmware or FAPs linked in this article.

Source Code:

This has since been merged into the official ESP32Marauder Firmware. You can view the PR request [here] which contains the source code.

Summary:

Today we looked at the two new sniffer options as well as some small subtle differences the WiFi Pineapple uses when comparing to a legitimate consumer access point. As well as covered the detection methods and what they are looking for along with flashing instructions for the firmwares and faps.

Ultimately, with the new "pinescan" and "multissid" options in the sniffer sub menu they can be a good way to detect a WiFi Pineapple only when it is using its Spoofed AP Pool. This is because when run without using the Spoofed AP Pool it looks and functions as a legitimate Open Network.

Though it is common to spoof a targets separated 2.4GHz and 5GHz network names (XYZ_2G and XYZ_5G) to have them believe they are connecting to their 5GHz network when in fact you will be connecting to a 2.4GHz Open network.

Pairing this with the FEBERIS Pro has been fantastic because of the 3dBi gain 2.4GHz Wireless Antenna it has given me a lot more range than I previously had with a Flipper Dev Board.

And I have not even managed to get around to trying out the other 3 built-in radio modules. That is what makes this tool incredibly versatile.

That pretty much wraps it up, I would like to say a big thank you to everyone who helped contribute towards testing and gathering beacon data from all walks of areas from residential to business. And thank you so much for reading this, I hoped you enjoyed the article, the video and new features as much as I enjoyed writing it, recording it and coding it.

If you feel like picking one up for you or a friend, you can use my discount code: AMEC0E on LAB401 for a 5% discount.

Disclaimer

Code Maintenance & Improvements:

As with any new feature, there may be issues that were not encountered during testing or may be due to oversight on my part. Therefore, the firmware, FAPs, and source code are provided "AS IS" without any warranties or guarantees. Neither I (amec0e) nor LAB401 will be held liable for any problems or damages resulting from the use of these firmwares or FAPs. Additionally, we (amec0e and LAB401) will not be providing support, maintenance, or future improvements for the firmware or FAPs (Flipper Application Packages).

Usage of Firmware: Neither I (amec0e) nor LAB401 will be held liable for any misuse or unintended consequences resulting from the use of the provided firmware or FAPs. These are distributed "AS IS" and are used entirely AT YOUR OWN RISK.

Legal Responsibility: You are solely responsible for complying with all applicable local laws and regulations. We will not be held liable for any legal consequences arising from your failure to do so. These firmwares and FAPs are provided strictly for educational and research purposes only.

Resources

C1101 Data Sheet - https://www.ti.com/lit/ds/symlink/cc1101.pdf

Feberis Pro Documentation - https://sapsan-docs.com/brands/sapsan/feberis-pro/docs/

Feberis Pro Firmware - https://github.com/bpmcircuits/ESP32Marauder

Feberis Pro Firmware Upgrading - https://www.youtube.com/watch?v=Gl7nSpI6l3w