> root@rf-rig:~# mavlink_decode --source udp:14550 | grep 'HEARTBEAT\|GPS_RAW\|COMMAND_LONG' --color<span class="cursor-blink">_</span>_
There is a class of technology that arrives in organisations sideways — not through IT procurement, not through a security review, not through the change advisory board, but through a project manager with a budget and a business need. It is purchased from a supplier's website, delivered in a box, charged overnight, and flying over a construction site the following morning. It joins no network that IT manages. It appears in no asset register. It undergoes no hardening.
Commercial drones — unmanned aerial vehicles, UAVs — are this generation's shadow IT. They are deployed by construction firms for surveying, by estate agents for aerial photography, by agricultural businesses for crop monitoring, by energy companies for infrastructure inspection, and by logistics firms for inventory assessment. They carry high-resolution cameras, LIDAR sensors, thermal imagers, and survey-grade GNSS receivers. They transmit data over radio links. They are controlled by software running on tablets and laptops. They are, in every meaningful sense, networked computing platforms that fly.
And they are almost never assessed for security.
On this engagement, we assessed the drone operations of a commercial construction firm — the aircraft, the controllers, the ground station software, the data workflow, and the radio frequency links that tied them together. What we found was an attack surface that the organisation did not know it had.
UAV security testing involves radio frequency transmission, potential disruption to aircraft control systems, and interaction with equipment operating in shared airspace. All testing was conducted within a controlled environment — a fenced construction compound with no public access, under a CAA-approved operational authorisation, with the aircraft grounded or tethered for RF interception tests. No testing was performed on aircraft in uncontrolled flight. No radio transmissions were made on frequencies that could interfere with other airspace users. The assessment was designed to identify vulnerabilities without creating safety risks.
UAV security testing operates under a dual regulatory framework: cybersecurity law (Computer Misuse Act 1990) and aviation law (Air Navigation Order 2016, UK CAA regulations, and the retained EU drone regulation 2019/947). Interfering with an aircraft — even an unmanned one — carries specific legal obligations that go beyond standard penetration testing. Our assessment methodology was designed in consultation with the client's aviation compliance team and operated within a formal safety case.
The client was a mid-sized construction firm operating across multiple active sites in the south of England. They had adopted drone-based aerial surveying two years prior — replacing traditional ground-based surveying for volumetric calculations, progress photography, site mapping, and topographic modelling. The surveying data fed directly into their Building Information Modelling (BIM) workflow and was used for client reporting, quantity surveying, and regulatory compliance.
The drone fleet comprised four off-the-shelf commercial quadcopters from a major manufacturer — equipped with integrated cameras and RTK GNSS receivers for centimetre-accurate positioning. The aircraft were operated by two qualified remote pilots using the manufacturer's controller hardware and a tablet running the manufacturer's flight planning and ground station application. Survey data was processed on a dedicated workstation using photogrammetry software.
We were engaged to conduct a UAV security assessment — a first for this client and, they believed, a first for their industry sector. The scope covered five domains: the aircraft themselves, the controller-to-aircraft radio link, the ground station software and tablets, the data processing workflow, and the physical security of the equipment.
A commercial drone is controlled via a radio frequency link between the controller (held by the pilot) and the aircraft. This link carries two types of traffic: command and control (C2) — the pilot's stick inputs, waypoint instructions, and mode changes — and telemetry — the aircraft's position, altitude, speed, battery state, sensor readings, and system health data. Most commercial drones also transmit a separate video downlink — a real-time feed from the onboard camera to the pilot's display.
We began by characterising the radio emissions from the drone system during a controlled ground test — the aircraft powered on but not flying, the controller connected, and the ground station application running.
Three distinct radio channels were active. The primary C2 link operated on 2.4 GHz using frequency-hopping spread spectrum (FHSS) with vendor-proprietary encryption — the most hardened of the three channels. The HD video downlink operated on 5.8 GHz and was not encrypted — the video feed from the aircraft's camera was transmitted in the clear. The aircraft also broadcast a Wi-Fi access point on 2.4 GHz for maintenance purposes — firmware updates, log downloads, and direct app connections.
The unencrypted video downlink was the first significant finding. Anyone within radio range of the operating drone — and the 5.8 GHz video link is effective at ranges exceeding one kilometre with a directional antenna — could passively intercept the live camera feed. For a construction firm, the camera feed shows site progress, structural details, material stockpiles, equipment positions, and personnel movements. For a competitor, this is intelligence. For a project involving sensitive clients — government, defence, critical infrastructure — this is an operational security failure.
The drone's HD video downlink transmitted the live camera feed without encryption on the 5.8 GHz band. Any party within radio range with an appropriate receiver and antenna could passively intercept the real-time camera imagery without detection. The interception is entirely passive — no transmission required, no interaction with the aircraft.
The aircraft's built-in Wi-Fi access point was intended for maintenance — a direct connection between a mobile device and the aircraft for firmware updates, configuration changes, and log retrieval. This is a common feature on commercial drones, allowing the pilot to configure the aircraft without the controller hardware.
The Wi-Fi network was secured with WPA2-PSK. The pre-shared key was derived from the aircraft's serial number — a pattern documented in the manufacturer's user manual and confirmed by the label on the aircraft's battery compartment. The serial number was physically printed on the aircraft body, visible to anyone with line of sight.
The aircraft's Wi-Fi interface exposed four services. An HTTP management interface providing aircraft status and configuration. An RTSP stream providing a secondary camera feed. A custom telemetry and command interface on port 10001. And an FTP server with anonymous access to the aircraft's SD card — containing 2,847 survey photographs (14.2 GB), flight logs with GPS traces of every mission flown, and firmware configuration files.
The survey photographs were the firm's primary deliverable — the raw imagery used to generate orthomosaics, 3D models, and volumetric calculations for their clients. An attacker with Wi-Fi access to the aircraft could download the complete survey dataset, delete images to corrupt the survey, or — most concerning — replace images with modified versions to subtly alter the survey output.
The flight logs contained GPS traces of every mission — revealing which sites had been surveyed, when, and from which positions. For a construction firm working on commercially sensitive developments, the flight logs reveal the locations and timelines of projects that may not yet be public knowledge.
The custom service on port 10001 communicated using MAVLink — the Micro Air Vehicle Link protocol, an open standard used by the majority of commercial and open-source drone platforms for telemetry and command communication. MAVLink is a lightweight, header-only protocol designed for bandwidth-constrained radio links. It is widely implemented, well-documented, and — in its default configuration — neither encrypted nor authenticated.
Whilst the primary C2 link between the controller and aircraft used the vendor's proprietary encrypted protocol, the Wi-Fi interface exposed the MAVLink telemetry stream without the encryption layer. Through the Wi-Fi connection, we could read the full telemetry output in real time.
The telemetry stream provided the aircraft's precise GPS position (centimetre-accurate with RTK fix), attitude (orientation in three axes), ground speed, battery state, and system health. It also revealed the home position — the GPS coordinates of the point where the aircraft was armed, which is the pilot's operating location. During an active survey, the telemetry would provide a real-time map of the aircraft's flight path and, consequently, the survey area.
MAVLink is a bidirectional protocol. It carries telemetry from the aircraft, but it also carries commands to the aircraft. The same interface that allowed us to read the telemetry stream also accepted command messages.
With the aircraft grounded and tethered, under controlled test conditions with the client's pilot present, we tested whether the MAVLink interface on the Wi-Fi connection would accept command messages.
The aircraft accepted all three commands via the Wi-Fi MAVLink interface. No authentication. No challenge. No priority negotiation between the legitimate controller and our injected commands. The autopilot treated our commands identically to commands received from the pilot's controller.
We did not test destructive commands (motor arm, waypoint modification, or emergency stop) and we did not test command injection during flight. The grounded, tethered test was sufficient to confirm the capability: an attacker connected to the aircraft's Wi-Fi could issue flight commands that the autopilot would obey.
The Wi-Fi range is limited — typically thirty to fifty metres — which constrains the attack to someone physically near the aircraft. However, on a construction site, 'physically near' includes anyone on the site compound, anyone in an adjacent property, and anyone in a vehicle on a nearby road.
The aircraft's MAVLink interface, accessible via Wi-Fi with a serial-number-derived PSK, accepted flight control commands without authentication. An attacker within Wi-Fi range could change flight modes, initiate return-to-home, or issue other MAVLink commands that the autopilot would execute without distinguishing them from legitimate controller input.
The ground station — the tablet running the manufacturer's flight planning application — was the pilot's primary interface for mission planning, real-time monitoring, and post-flight data management. It communicated with the aircraft via the controller, and with the manufacturer's cloud services via the tablet's cellular connection.
The tablet was a standard consumer Android device. It was not enrolled in the client's mobile device management (MDM) platform. It had no security policy applied. The device PIN was 0000. The flight planning application stored mission data — including site coordinates, survey boundaries, and flight paths — in an unencrypted local database.
The ground station tablet was a standard consumer device operating entirely outside the client's IT security perimeter. No MDM. No security policy. A four-digit PIN of all zeroes. USB debugging enabled — allowing data extraction via a physical USB connection. The flight planning application was six versions behind the current release and stored all mission data in an unencrypted local database.
The local database contained GPS coordinates and survey boundaries for one hundred and forty-two planned missions across seven active construction sites. The manufacturer's cloud account credentials were cached in the application — no multi-factor authentication was enabled. Accessing the manufacturer's cloud portal with these credentials would provide access to every flight log, every survey dataset, and every mission plan the pilot had ever uploaded.
The tablet was kept in the pilot's vehicle when not in use. It was not in a locked container. Loss or theft of this single device would expose the complete operational history of the firm's drone surveying programme.
After a survey flight, the raw imagery was transferred from the aircraft's SD card to a processing workstation via a USB card reader. The workstation ran photogrammetry software that stitched the images into orthomosaics, digital elevation models, and 3D point clouds. The processed outputs were uploaded to the firm's BIM platform and shared with clients.
| Workflow Stage | Finding | Risk |
|---|---|---|
| SD Card Transfer | No integrity verification. Images copied directly; no checksums, no signing, no chain of custody. | Images could be modified between capture and processing without detection. |
| Processing Workstation | Standalone Windows 11 machine. Not domain-joined. No EDR. Local admin account with no password. | Workstation compromise would allow manipulation of processed survey outputs. |
| Photogrammetry Software | Commercial licence. Version 2 minor releases behind. No integrity checks on input imagery. | Software trusts all input. Modified images would be processed without alerting. |
| BIM Upload | Processed outputs uploaded via HTTPS to cloud BIM platform. MFA not enabled on BIM account. | BIM account compromise would allow modification of published survey data. |
The data workflow had no integrity verification at any stage. From capture to client delivery, there was no mechanism to confirm that the images had not been altered. No checksums. No digital signatures. No chain of custody documentation. An attacker who could access the SD card, the FTP server on the aircraft, the processing workstation, or the BIM platform could modify the survey data — and nobody would know.
For a construction firm, survey data integrity is not an abstract concern. Volumetric calculations determine how much earth has been moved — and therefore how much the contractor is paid. Topographic models inform structural engineering decisions. Progress photography demonstrates contractual milestones. Manipulation of survey data could result in incorrect payments, flawed engineering calculations, or fraudulent milestone claims.
| Step | Action | Weakness Exploited |
|---|---|---|
| 01 | Passively intercepted HD video downlink on 5.8 GHz | Unencrypted video transmission — viewable by anyone within range |
| 02 | Connected to aircraft Wi-Fi using serial-number-derived PSK | PSK derivation documented in user manual; serial visible on airframe |
| 03 | Downloaded 14.2 GB of survey imagery and flight logs via anonymous FTP | Anonymous FTP on aircraft; complete survey data accessible |
| 04 | Read full MAVLink telemetry including GPS position and home point | Unauthenticated MAVLink over Wi-Fi; no encryption on telemetry |
| 05 | Injected flight control commands via MAVLink (grounded test) | Unauthenticated command acceptance; no C2 source verification |
| 06 | Assessed ground station tablet — mission data, cloud creds, no MDM | Consumer device outside IT perimeter; default PIN; cached credentials |
| 07 | Identified data workflow with no integrity verification at any stage | No checksums, signing, or chain of custody from capture to delivery |
The most impactful immediate changes are disabling the aircraft Wi-Fi when not in active maintenance use and changing the Wi-Fi PSK from the serial-number-derived default. The Wi-Fi interface is the primary attack vector — it provides network access to the aircraft's FTP, RTSP, and MAVLink services. When Wi-Fi is disabled, the only communication path is the vendor's encrypted C2 link via the controller, which is significantly harder to attack.
Data integrity verification is the most important strategic control. Implementing SHA-256 checksums at the point of image capture — ideally generated by the aircraft's firmware and recorded in the flight log — creates a verifiable chain from sensor to deliverable. If an image is modified at any stage, the checksum mismatch will detect it. This is the difference between trusting the data and verifying it.
MAVLink v2 with message signing provides cryptographic authentication of command messages, preventing the command injection attack we demonstrated. MAVLink v2 signing uses a shared secret between the ground station and the aircraft to authenticate each message. Unsigned messages can be rejected. This does not encrypt the telemetry, but it prevents an attacker from injecting commands that the autopilot will accept.
The ground station tablets must be brought within the organisation's IT security perimeter — enrolled in MDM, subject to security policy, encrypted, and managed. A device that contains GPS coordinates for every active construction site, cached cloud credentials, and the complete history of the firm's surveying programme is not a 'pilot's tablet'. It is a critical business asset.
Commercial drones are not cameras that fly. They are computing platforms — with processors, operating systems, firmware, network interfaces, storage, and communication protocols — that happen to operate thirty metres above your construction site. They carry your data. They transmit your data. They store your data. And they do all of this entirely outside the security controls that protect every other system in your organisation.
The client in this engagement had invested in cybersecurity across their IT environment — firewalls, EDR, MFA, penetration testing. Their corporate network was well-defended. But their drone fleet — carrying survey data that informed multi-million-pound construction decisions — was secured with a Wi-Fi password derived from the serial number printed on the aircraft body, managed from a tablet with a PIN of 0000, and transmitting its video feed in the clear to anyone with a thirty-pound SDR receiver.
The attack surface does not end at the network perimeter. It extends to every device that carries, processes, or transmits your data — including the ones that fly.
Until next time — stay sharp, stay curious, and look up. There might be an unpatched computer above your head.
This article describes a UAV security assessment conducted under formal engagement with full written authorisation from the client. All testing was performed within a controlled compound under a CAA-approved operational authorisation. No testing was conducted on aircraft in uncontrolled flight. No radio transmissions were made that could interfere with other airspace users. All identifying details have been altered or omitted to preserve client confidentiality. Interference with aircraft is an offence under the Air Navigation Order 2016 and the Aviation Security Act 1982. Unauthorised interception of radio communications is an offence under the Wireless Telegraphy Act 2006. Unauthorised access to computer systems is an offence under the Computer Misuse Act 1990. Do not attempt to replicate these techniques without proper authorisation, appropriate aviation approvals, and a formal safety case.
Hedgehog Security conducts UAV security assessments covering the aircraft, the radio link, the ground station, and the data workflow. We test within controlled environments under appropriate aviation approvals. We identify the vulnerabilities in your drone operations before someone else does — and we help you bring your flying IT assets within your security perimeter.