> root@drone-shell:~# ip route && arp -a | grep '10.10.' | wc -l && echo 'internal hosts visible from UAV'<span class="cursor-blink">_</span>_
Over the past four months, we have attacked drones from every conceivable angle — hijacking control links, harvesting stored intelligence, spoofing GPS signals, and reverse engineering controller firmware. Each article treated the drone as the target. This article inverts the model.
This time, the drone is not the target. It is the weapon.
When a corporate drone connects to the internal Wi-Fi to upload its photographs, it becomes a device on the corporate network. If that device has been compromised — or if its onboard services are sufficiently exposed — it inherits whatever trust the network grants to connected devices. It sits inside the firewall. It bypasses the perimeter. It is an inside threat that arrived by air.
On this engagement, we demonstrated a complete attack path: compromise the drone via its Wi-Fi interface whilst it sat on the ground, wait for it to connect to the corporate network for its scheduled image sync, and then use the drone's network position to pivot into internal systems. The drone was our bridgehead. The corporate network was our objective.
The client was an engineering consultancy with offices across the south-east of England. They deployed a fleet of three commercial drones for infrastructure inspection — bridges, roofing, cladding, and structural assessments. The drones captured high-resolution imagery during field inspections, and the photographs were uploaded to a centralised asset management server when the drone returned to the office.
The upload workflow was automated. When the drone was powered on within range of the office Wi-Fi network — a corporate WPA2-PSK network that the drone had been configured to join — it automatically connected and began syncing the contents of its SD card to a file ingestion server at 10.10.1.40 via an SMB share. The sync was triggered by a script in the drone's firmware that the client's IT team had configured using the manufacturer's SDK — a customisation intended to streamline the post-flight data workflow.
We were engaged to assess whether the automated sync workflow introduced a network security risk. The client's CISO had attended our drone security series presentations and asked the question that prompted this engagement: 'If someone compromised our drone in the field, could they use it to get onto our corporate network when it comes home?'
The answer was yes.
The first phase replicated the techniques from our earlier drone articles. The drone exposed a Wi-Fi access point for maintenance and direct connection. As documented in articles twenty-one and twenty-two, the Wi-Fi PSK was derived from the device serial number and the FTP service permitted anonymous access.
We accessed the drone's Wi-Fi whilst it was powered on at the client's premises — simulating an attacker who had physical proximity to the drone during a field inspection, in a site car park, or at the client's office during the period between the drone landing and being brought inside.
We uploaded a lightweight callback script to the drone's writable configuration partition via anonymous FTP. The script was designed to be dormant — it checked once per minute for the presence of a route to the 10.10.0.0/16 corporate subnet. When the drone connected to the corporate Wi-Fi and received a DHCP lease with the corporate default gateway, the route appeared, and the script established a reverse shell to our external command and control server.
This approach mirrors a real-world attack pattern: the attacker compromises the drone in the field (during an inspection, overnight in a vehicle, or at a client site) and waits for the drone to return to the corporate network. The compromise is patient. The payload is dormant until the conditions are right.
The drone's writable configuration partition, accessible via anonymous FTP over the maintenance Wi-Fi interface, accepted arbitrary file uploads. A script placed in the autorun directory executed on each boot. This provided persistent code execution that survived power cycles and activated automatically when the drone connected to the corporate network.
We waited. The following morning, the drone was powered on at the client's office for its scheduled image sync. It connected to the corporate Wi-Fi — the PSK was pre-configured in the drone's network settings — received a DHCP lease, and began uploading imagery to 10.10.1.40.
Forty-seven seconds later, our callback script detected the corporate route and established the reverse shell.
Root shell. On the corporate user VLAN. The drone had been placed on 10.10.2.0/24 — the same VLAN as corporate workstations. It received its IP address via DHCP from the same scope that served employee laptops. From the network's perspective, the drone was indistinguishable from any other Wi-Fi client.
No Network Access Control (NAC) challenged the drone's connection. No device certificate was required. No posture assessment was performed. No MAC address filtering was in place — and even if it had been, the drone's MAC address was a legitimate, pre-authorised device. The corporate network accepted the drone because it presented the correct WPA2-PSK. That was the entirety of the admission criteria.
With a root shell on a device inside the corporate network, we conducted reconnaissance. The drone's embedded Linux had limited tooling — no nmap, no Python, no standard penetration testing tools. But it had the fundamentals: a shell, ping, netcat, curl, and the ability to download additional tools from our C2 server.
From the drone, we could reach forty-seven hosts on the user VLAN and the server VLAN at 10.10.1.0/24 — including the domain controller, the file ingestion server, and multiple other servers. The network had no segmentation between the user VLAN and the server VLAN. The drone, positioned on the user VLAN as a Wi-Fi client, had the same network access as any employee workstation.
The drone's automatic image sync to 10.10.1.40 used SMB — Windows file sharing. The sync script, configured by the client's IT team, contained the credentials for the SMB share.
A domain service account — svc_drone_sync — with its password in plaintext, stored on the drone's writable partition. This credential was configured by the client's IT team to automate the image upload. It was accessible to anyone who connected to the drone's Wi-Fi and accessed the FTP server — no root shell required.
We tested the scope of the service account's permissions.
The svc_drone_sync account had been granted permissions beyond its intended scope. It was supposed to write to the drone_uploads share only. In practice, it had read access to the projects$ and engineering$ shares — containing client deliverables, structural engineering reports, CAD files, and inspection documentation. The finance$ share was correctly restricted.
The overprivileged service account is a recurring theme in this series. The account was likely granted broad read permissions during initial configuration — perhaps by adding it to a group that had access to multiple shares — and nobody had reviewed or restricted its access afterwards. The principle of least privilege was not applied.
The svc_drone_sync credential gave us authenticated access to the domain from the drone's network position. We used this foothold for further enumeration and lateral movement.
From the drone's network position, we enumerated three hundred and twelve domain accounts, compromised two via password spray, and used one — an IT support account with local administrator rights — to move laterally to a workstation. From the workstation, standard Active Directory escalation techniques (covered extensively in earlier articles in this series) yielded domain administrator credentials.
The complete attack path: compromise the drone via its Wi-Fi interface → plant persistent callback → wait for the drone to connect to the corporate network → use the drone as a network pivot → extract the sync service account credentials → enumerate the domain → password spray → lateral movement → domain compromise. The entry point was a drone sitting in a van in a car park. The destination was full domain administration.
| Step | Action | Weakness Exploited |
|---|---|---|
| 01 | Connected to drone Wi-Fi using serial-derived PSK | Default Wi-Fi PSK; maintenance interface always active |
| 02 | Uploaded persistent callback script via anonymous FTP | Anonymous FTP write to writable config partition; autorun on boot |
| 03 | Drone connected to corporate Wi-Fi — callback activated | No NAC; no device certificate; PSK-only admission to corporate VLAN |
| 04 | Drone placed on corporate user VLAN — full internal access | No IoT/device VLAN; drone on same VLAN as workstations |
| 05 | Extracted svc_drone_sync credentials from sync config file | Domain service account password in plaintext on drone |
| 06 | Accessed project and engineering file shares | Service account overprivileged — read access beyond intended share |
| 07 | Password spray and lateral movement to domain compromise | Weak passwords; no segmentation; standard AD escalation path |
This engagement illustrates a principle that extends far beyond drones: every device that connects to the corporate network is a potential attack vector, and the process by which it is admitted determines the risk it introduces.
The most impactful immediate change is moving the drone to a dedicated IoT VLAN with restrictive firewall rules. The drone needs access to one server on one port. It should have access to one server on one port. A firewall rule permitting 10.10.device.X → 10.10.1.40:445 and denying all else eliminates the drone's ability to reach the domain controller, other servers, workstations, and the internet. The drone can sync. It cannot pivot.
Blocking outbound internet access from the IoT VLAN prevents the reverse shell callback that initiated the entire attack chain. Without outbound connectivity, a compromised drone on the IoT VLAN cannot reach an external C2 server. The drone's legitimate function — uploading files to an internal server — does not require internet access.
The strategic recommendation is to reverse the sync model. Instead of the drone initiating an upload (which requires credentials stored on the drone), the server should pull files from the drone when it connects (which requires credentials stored on the server only). The drone exposes its SD card as a read-only share; the server mounts the share, copies the files, and disconnects. No credentials are stored on the drone. No domain account exists on an unmanaged device that travels to field sites.
A device onboarding security standard — applicable to drones, IoT sensors, building management devices, and any non-IT equipment that connects to the network — should define the minimum requirements for network admission: device registration, VLAN assignment, credential management, access restrictions, and monitoring. The standard ensures that the question 'can we put this on the Wi-Fi?' has a structured, security-reviewed answer rather than a casual PSK handover.
This engagement brings our drone security series full circle. We have attacked drones as systems, as data stores, as navigation targets, as firmware targets, and now as network pivot points. The common thread across all five articles is that drones — like every IoT device before them — are treated as tools rather than as networked computers. They are purchased by operational teams. They are configured by field engineers. They are connected to the network by someone who needed them to work, not by someone who needed them to be secure.
The drone in this engagement did exactly what it was configured to do. It flew to a site. It captured photographs. It returned to the office. It connected to the Wi-Fi. It uploaded its images. Every step was legitimate. And at every step, the configuration choices that enabled the legitimate workflow also enabled the attack: the always-on Wi-Fi interface, the anonymous FTP, the plaintext credentials, the PSK-only network admission, the flat VLAN, the overprivileged service account.
Security is not about preventing devices from doing their job. It is about ensuring that the way they do their job does not create a pathway for an attacker to do theirs.
Until next time — stay sharp, stay curious, and the next time someone asks to put a drone on the corporate Wi-Fi, ask: which VLAN?
This article describes a penetration test conducted under formal engagement with full written authorisation from the client. The drone was compromised in a controlled setting on the client's premises with the full knowledge of the IT and operations teams. No flight operations were conducted as part of this assessment. No data was exfiltrated from the corporate network — lateral movement was demonstrated to confirm the attack path and then halted. All identifying details have been altered or omitted to preserve client confidentiality. Unauthorised access to computer systems is a criminal offence under the Computer Misuse Act 1990. Do not attempt to replicate these techniques without proper authorisation.
Hedgehog Security assesses the full drone-to-network attack path — from field compromise through network admission to lateral movement. We test device onboarding, NAC enforcement, VLAN segmentation, credential exposure, and the blast radius of a compromised IoT device on your corporate infrastructure. The drone is just the example. The principle applies to every unmanaged device you connect.