Building a Raspberry Pi Pineapple for various wireless attacks

Welcome back, aspiring cyberwarriors!

In our Drone Hacking series, we covered the use of a Pineapple device mounted on the back of a drone to carry out dynamic wireless attacks. Our goal was to show how hackers can achieve this with a bit of SDR knowledge, since all the necessary offensive tools are already available. Today, as promised in Part 3 where we developed the Pineapple device based on a Raspberry Pi, we will cover attacks that require time and patience. Unlike the dynamic attacks discussed earlier in the series, some of these techniques rely on the human factor. If you haven’t yet read Part 3 of the Drone Hacking series, we highly recommend starting there and returning to this article afterward. This will help you understand how the Pineapple device was made and allow us to avoid repeating ourselves.

As soon as you bring the network interface up in monitor mode, just like it was described in Part 3, the ability to autonomously perform the most popular Wi-Fi attacks becomes available. At the same time, with a Raspberry Pi you can always use an external Wi-Fi adapter and additional antennas. The downside is that this may reduce stealth.

VPN via 4G

Complex attacks are not easy to automate, and remote control of such a device can be very useful to a potential hacker.

It is fairly easy to ensure that your Pineapple is always accessible by using any 4G modem. A modern 4G modem is implemented as a virtual network interface (already familiar to us), which greatly simplifies interaction between the Pineapple and the modem. To do this, it is enough to activate the modem’s network interface:

Open /etc/network/interfaces and make sure it looks like this:

allow-hotplug eth0
auto eth0
iface eth0 inet dhcp

For remote access to the Pineapple, you need to configure automatic startup of a VPN connection to the server used by the attacker as a pivot point:

Pi > cp your_vds.ovpn /etc/openvpn/client/vds.conf
Pi > systemctl enable openvpn-client@vds

The easiest way to manage the Pineapple itself is via SSH:

Pi > systemctl enable ssh.service

A hacker can place such a device anywhere within range of the targeted access points or in areas with a large number of potential victims. At the same time, the Pineapple can be controlled from a laptop while sitting somewhere comfortable and safe.

For example, using a VPN tunnel over 4G, the hacker can simply share the Pineapple’s wireless monitor interface over the network and perform all Wi-Fi attacks directly from their laptop:

Pi> airserv-ng -p 1337 -d mon0
kali> airodump-ng -c 1,6,11 pineapple:1337

If a 4G connection is unavailable, the device can always be configured in autonomous mode by connecting directly to the board and obtaining a console via UART, as shown below.

Pi > sudo minicom -D /dev/ttyUSB0 -b 115200 --color=on

After that, working in the familiar shell environment of the device’s OS, you can perform fine-grained tuning of the attack scenario.

Configurations

In this form, the device often shuts down the operating system incorrectly, for example if the battery runs out. Therefore, to prevent loss of important data, it is recommended to disable disk caching. This was already done in Drone Hacking – Part 3, so if you have already done this, there is no need to repeat it.

Open /etc/fstab and paste this:

PARTUUID=067e19d7-02 / ext4 defaults,noatime,sync 0 1

Connecting to the board via UART or 4G is very convenient, but in some cases the attacker may need the attacks to start immediately. To quickly launch preinstalled scenarios aimed at a wide range of targets, a GPIO jumper can be used. This was also implemented in Part 3 when building the drone, so if you have already done this, you can skip this step. If not, you can track the jumper position programmatically as follows:

Open /etc/local/bin/jmp and paste this: 

#!/bin/bash
exit $(raspi-gpio get $1 | awk '{print $3}' | cut -d '=' -f )

The idea remains the same: by changing the jumper position just before powering on the Pineapple, the attacker specifies which attack vector to launch. For example, Evil Twin in one position, or mass deauthentication and handshake collection in another. What exactly is launched in each case is defined in the startup.sh script

Download it here and place it in /home/pi/

As with the drone, the progress and results of the attacks are saved to corresponding files on the Pineapple’s memory card, with filenames reflecting the attack type, date, and time. This script only needs to be added to autostart if you have not already done so.

Open /etc/rc.local and add this:

/bin/bash /home/pi/startup.sh &

This script briefly describes all the attacks that can be executed using the Pineapple.

Wi-Fi Attacks

When describing Wi-Fi attacks and radio attacks in general it is important to immediately clarify which attacks make sense to perform using a Pineapple. The Pineapple is not the only device capable of radio attacks, and some attacks are deliberately not covered in this article, as they are more reasonably carried out, for example, from a phone.

There are many different Wi-Fi attacks, and this article describes only those that require prolonged attacker involvement. The form factor of the attacking device is ideal for stealthy, long-term placement near targets, such as access points, their users, and client devices, IP cameras, and more. LEDs indicate the attack status without needing to connect to the board. This makes it possible to understand whether the Pineapple has completed its task or whether the attacker should return for it later.

Now let’s look at each of the main Wi-Fi attacks mentioned in the script:

1) WPA Handshake / bruteforce (attack on access point authentication)

2) WPS (attack on access point authentication)

3) Evil Twin (attack on user actions)

4) EAP Attack (attack on client device authentication)

4) Honeypot (attack on client operating systems)

Capturing a WPA Handshake

Capturing a WPA handshake is one of the most popular and widely used attacks. The WPA handshake is transmitted by the client in the second message (EAPOL M2) of the four-way handshake.

The contents of this packet serve as proof to the access point that the client knows the shared PSK key. An attacker who intercepts this hash can attempt to recover the password using a dictionary attack. To capture the hash, the attacker does not necessarily need to perform any active actions. Since they have a technical means capable of staying in the coverage area of target wireless networks for a long time and unnoticed, they can simply passively wait for the handshake to be transmitted. This attack is completely “silent.”

To get started with your first attack, download the entire directory from our Github and place it in /home/pi/, so your full path will be /home/pi/wpapsk

Below you can see the monitor script (monitor.sh)

While monitoring wireless networks, the script checks every ten seconds on the specified frequency channels whether a handshake has been captured. As soon as the Pineapple captures one, the yellow LED lights up. It is worth noting that there is a possibility of capturing an invalid password, which is also transmitted as a handshake packet. However, a handshake with such a password does not contain a response from the access point (EAPOL M3) and is considered incomplete (a half-handshake). To avoid false positives, the script discards such handshakes and keeps only those that contain confirmation, and therefore the correct password.

To speed up handshake collection, an active component can be added, sending deauthentication packets. These packets are sent on behalf of both the client and the access point to all detectable Wi-Fi clients, forcing them to disconnect. A client that did not actually intend to disconnect will reconnect and transmit the password hash for that network.

Bellow you can see the script responsible for it called deauth.sh

The deauthentication procedure is subordinate. It does not switch frequency channels on its own but follows the leading process that performs this task. The only additional information that can be provided to the script is a list of MAC addresses of the targeted wireless networks. At the moment deauthentication packets are sent, the Pineapple flashes the green LED.

Deauthentication has negative side effects on the targeted network, as clients are constantly disconnected. Therefore, launching this script is commented out in the startup script and is presented as optional.
While hunting for a handshake, again optionally, the device can check captured handshakes against the weakest passwords from a dictionary. It is not recommended to try more than 1,000 variants, otherwise the battery will drain quickly. If the password is successfully recovered, the red LED lights up. The script that helps us with it is called brute-wpapsk.sh

WPS Brute Force

Brute-forcing the WPS PIN is another example of a Wi-Fi access point attack that requires a long time to complete. There are many wireless devices with enabled and brute-force-vulnerable WPS from wireless printers to enterprise access points. If the access point does not have a default PIN or is not vulnerable to Pixie Dust (which allows the PIN to be recovered in just a few attempts or seconds), a full brute force of the entire PIN space, in the worst case, requires up to 11,000 attempts.

Ideally, if each attempt takes about one second and the access point does not block the attacker, the attack may take several hours. Staying near the target access point with a laptop or phone for that long is unreasonable, since the process is fully automated and does not require human involvement. You only need the Pineapple.

Below is wps.sh needed for it.

Targets for the attack can be specified either by the access point’s MAC address or by the wireless network name. Most likely, the attacker will only know the network name. However, in medium and large organizations, multiple access points may share the same name. This script brute-forces the PIN on each of those access points.

Summary

This article focuses on long-running wireless attacks that benefit from leaving a Pineapple deployed near a target for extended periods of time. Unlike the dynamic attacks shown earlier in the Drone Hacking series, these techniques rely on patience, automation, and sometimes user behavior as you will see later.

The Pineapple can be operated remotely over a 4G connection and VPN, managed via SSH, or run fully autonomously using startup scripts and GPIO jumpers that select predefined attack scenarios at boot. This makes the device suitable for stealthy placement near access points and clients, where it can perform tasks such as handshake collection or WPS brute forcing over many hours.

To ensure everything works as intended, the required attack directory (wpapsk) from the project’s GitHub repository must be placed correctly in /home/pi as it is required by the startup.sh script.

Source: HackersArise
Source Link: https://hackers-arise.com/pineapple-attacks-building-your-own-pineapple-part-1/