National Cyber Warfare Foundation (NCWF)

Drone Hacking: Build Your Own Hacking Drone, Part 4


0 user ratings
2026-02-06 14:18:17
milo
Red Team (CNA)
In the final part we show how to capture credentials, hashes, and network intelligence by targeting devices and protocols

Welcome back, aspiring cyberwarriors!





You have reached the final article in our drone hacking series, where we bring the discussion to a close with the last set of wireless attack techniques. This is not the end of the journey, though. A new series is coming that continues the same ideas without drones. Instead, we will take the Pineapple module and run it independently on its own battery. This may seem like a small change, but it has a big impact. Without flight time limits, hackers can run much longer, collect more data, and remain far more subtle and difficult to detect.





Drone-based attacks are usually fast and opportunistic because of battery constraints. However, a real attacker can simply drop their equipment near an office or facility and connect back to it through a VPN. At that point, the attack is no longer loud or obvious. It becomes much harder to detect.





EAP Attack





During an EAP attack, almost the same thing happens as in an Evil Twin scenario, where a legitimate access point is imitated and its clients are attacked. However, there is one critical difference. In this case, the target is not the human user, but the client device itself, which is the hardware. This distinction is extremely important from a defensive standpoint.





By attacking the device rather than the person, the attacker completely removes the social factor from the equation. There is no phishing, no fake login page, no dialog box asking the user to click something. The user does not need to interact with anything at all. This is what is commonly referred to as a zero-click attack. If a vulnerable device is present, the attack becomes fast, silent, and almost perfectly reliable. The vulnerability lies in the way some client devices automatically and insecurely transmit credentials when connecting to WPA Enterprise networks.





drone attacking a phone with an eap attack




To exploit this, the attacker launches a slightly modified version of hostapd-wpe, configured to store more detailed logs when credentials are received. At the same time, the client device is presented with a list of authentication methods in reverse order, starting with the weakest and least secure ones. If the client accepts one of these methods, the password or its hash can be intercepted.





To activate this attack on our device, a simple hardware condition is used. A jumper is placed on GPIO-25, shorting pins 20 and 22, after which the device is powered on. When the green LED lights up, it indicates that the rogue access point has been successfully started and the attacker can begin movement. At this point, the drone carrying the Pineapple can fly its route.





When the drone returns, a red or yellow LED indicates success. This means that the drone has not returned empty-handed. A password or a hash of a domain account has been captured and stored on the memory card. With such domain credentials, an attacker can later gain remote access to corporate email, extract confidential data, or, if the company uses a VPN, directly access the internal network.





Here’s what the script responsible for this behavior looks like.





hostapd script for eap attacks for drones




Once you copy the script from our GitHub, create a new directory in /home/pi called eap and place the script in it named as hostapd-eaphammer.sh





To attract client devices, an additional script may be launched that forcibly disconnects clients from their legitimate access points.





the deauth script for the eap attack for drones




Place it in the same directory (/home/pi/eap) named as deauth.sh. Here is the link





But keep in mind, deauthentication is optional and in the startup.sh script it was commented out. If you plan to use it, make sure you remove the comment





part of the startup script responsible for the eap attacks for drones




It is very important to emphasize the following point. When imitating a legitimate WPA Enterprise access point, it is sometimes possible to obtain the password in clear text. Whether this happens depends entirely on how the legitimate wireless network was originally saved on the client device. If the authentication method is GTC, the password may be captured in plain text. If it is MSCHAP, the attacker receives a NetNTLMv1 hash, which can often be reduced to an LM hash and cracked within a reasonable amount of time. In WPA Enterprise environments, the credentials used are usually domain usernames and passwords. This means that once such credentials are captured, the attacker can either immediately connect to the Wi-Fi network and gain internal access using a valid domain account, or access the network remotely through VPN, if such access is available.





At first glance, this may seem counterintuitive. In attacks against WPA PSK networks, which are common in private homes, the attacker usually captures a handshake that then must be brute-forced, sometimes for a very long time. In contrast, attacks against WPA Enterprise often yield either a weak NetNTLMv1 hash or even a clear-text password. This is particularly striking given that WPA Enterprise is considered the gold standard for corporate environments and is generally assumed to be secure.





This vulnerability applies only to WPA EAP (Enterprise) networks, which are primarily found in corporate and government environments. That is precisely what makes it so dangerous. A successful exploit can become the initial point of compromise for an entire organization, with all the consequences that follow. Employees who have not yet disabled Wi-Fi on their devices may unknowingly and automatically compromise their own credentials. Without any visible warning, they effectively open the door to the internal network.





Capturing WPA Handshake and PMKID





Authentication through PMKID capture and deauthentication-based WPA handshake capture usually happens quite quickly. However, capturing a WPA handshake requires the presence of active clients, which makes it highly dependent on circumstances. PMKID capture, on the other hand, can be performed whenever a vulnerable access point is present, and it usually succeeds quickly.





For this reason, and because drone flight time is limited by battery capacity, we focus on PMKID in this article. PMKID is another brute-forceable hash that can be extracted from the first message of the four-way handshake, specifically EAPOL M1. Importantly, this does not require authenticated clients. The access point itself may send this packet in response to an association request. The authentication script needed for this attack is below.





auth pmkid script for drones




Create a new directory in /home/pi called wpapsk and make sure the script is called auth.sh. Find it here.





While the drone is in flight, a script sends association requests to every access point within radio range. 





drone attacking a wife with pmpid attack




As soon as a PMKID is captured, the yellow LED lights up. Both WPA handshakes and PMKIDs produce hashes that can later be used to recover the access point password through dictionary attacks:





brute pmkid script for drones




The brute-pmkid.sh script can be found here. It belongs to /home/pi/wpapsk/ directory.





A Pineapple running such a script is capable of autonomously identifying weak passwords. To do this, all EAPOL M2 packets are removed first, ensuring that only PMKIDs are processed. Hashes are then deduplicated to avoid brute-forcing the same data repeatedly. Brute-force attempts can even begin while the device is still airborne. If a password is successfully recovered, the red LED lights up. This script is a good example of how collected hashes can be manipulated. In cases where a WPA handshake is present, aircrack-ng ignores PMKID by default. In practice, brute-forcing hashes is best done on more powerful hardware. All hashes collected during flight are stored on the Pineapple’s memory card for later analysis.





Wireless Network Reconnaissance





When it comes to wireless attacks, a drone is an excellent reconnaissance platform. By mounting the Pineapple and connecting an external GPS dongle, an attacker can triangulate the positions of wireless devices, including Wi-Fi access points, client devices, Bluetooth equipment, and even wireless mice and keyboards. These positions are then recorded on a map.





This information is valuable not only for attackers assessing future attack surfaces, but also for defenders who want to understand and control their wireless assets. All necessary data collection and calculations are handled by Kismet. The output is an SQLite database, which can be easily parsed for further analysis.





For geographic reconnaissance of wireless networks, only two components are required. On the Pineapple, they are launched automatically when the jumper is set to GPIO 27 at startup. Below is the part of the startup.sh script responsible for this attack.









Once a connection to GPS satellites is established, the green LED indicates that the drone can begin its flight.









Place the gps.sh script in /home/pi/recon.





When Kismet starts successfully, the yellow LED lights up.









Place kismet.sh script in /home/pi/recon





After flying over the target area or following a predefined GPS route, both attackers and defenders can automatically analyze wireless coverage with much higher quality, covering large areas efficiently. The resulting data dump can be converted into a web page containing an interactive map. This map shows calculated signal source locations and a heatmap of signal strength.









The heatmap displays signal levels for wireless devices at every surveyed point. Clicking on any access point or client highlights its estimated coverage area.









The heatmap dynamically adjusts its colors for each selected device, showing where and how its signal was received. Every location where the drone flew can be queried to reveal which wireless devices were detectable there.









Taken together, this provides a clear picture of whether wireless coverage extends beyond controlled areas, potentially into locations where an attacker could safely operate.





Post-Exploitation





If an attack is successful, the attacker will likely need to return and exploit the discovered vulnerability. A recovered password or captured credentials are valid only for a specific wireless network. In such cases, a drone may deliver a Pineapple equipped with a 4G module, allowing remote access to the compromised wireless network within a secured area. In the Pineapple articles, we will show exactly how you can make your VPN work on the Pi, but since it is not particularly difficult to set up, we have left the commands below for those who already have it configured.





Pi > wpa_passphrase 'target_essid' 'password' > wifi.conf

Pi > wpa_supplicant -i wlan0 -c wifi.conf & dhclient wlan0

Pi > sysctl -w net.ipv4.ip_forward=1

Pi > iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE




An attacker with a VPN connection to the Pineapple can gain network access simply by using it as a gateway. The drone carrying the Pineapple can land on a building’s roof. With its propellers turned off, it can remain there for an extended period. During this time, the attacker can remotely connect to the compromised wireless network and escalate attacks into internal systems.





kali > route add -net 192.168.1.0/24 gw pineapple

kali > nmap 192.168.1.0/24




It is entirely possible that the internal network will fall before security personnel even reach the roof. And if the situation becomes risky, the drone can quickly depart, carrying both the Pineapple and the 4G modem with it. No physical evidence is left behind.





Summary





In this final part we saw what drone-based wireless attacks actually enable in practice. Drones are not the threat on their own, they are fast and mobile to deploy well-known attacks in places assumed to be out of reach. By targeting devices and protocols instead of users, attackers can collect credentials and network intelligence quicker, often without any visible warning. More importantly, we prepared the ground for what comes next. Removing the drone removes the time limit. Running the same tooling independently and remotely turns short, opportunistic attacks into persistent and far harder-to-detect compromises. 





Keep it mind, this content is intended for authorized testing only and indiscriminate testing of wireless networks is prohibited. Defenders should closely monitor their wireless environments and implement mitigation strategies, as these tools and techniques are readily available.





If you like the work we’re doing here and want to take your skills even further, we also offer a full SDR for Hackers Career Path. It’s a structured training program designed to guide you from the fundamentals of Software-Defined Radio all the way to advanced, real-world applications in cybersecurity and signals intelligence.



Source: HackersArise
Source Link: https://hackers-arise.com/drone-hacking-build-your-own-hacking-drone-part-4/


Comments
new comment
Nobody has commented yet. Will you be the first?
 
Forum
Red Team (CNA)



Copyright 2012 through 2026 - National Cyber Warfare Foundation - All rights reserved worldwide.