Hijacking Small Satellites: Lessons from a DIY Testbed

TLDR: Researchers at the University of Alabama in Huntsville built a functional small satellite testbed to demonstrate how easily command-and-control links can be compromised. By executing a Man-in-the-Middle attack on the radio frequency link, they successfully hijacked satellite IDs and manipulated telemetry data. This research highlights critical gaps in satellite security, specifically the lack of robust command validation and authentication in low-cost space hardware.

Space is no longer the exclusive domain of government agencies with massive budgets. The rise of ride-share rocket launches has democratized access to orbit, leading to a proliferation of small satellites and CubeSats. While this shift accelerates innovation, it also introduces a massive attack surface that is often overlooked. When we talk about IoT security, we usually mean smart fridges or industrial sensors, but the same vulnerabilities—hardcoded credentials, lack of encryption, and weak command validation—are now being deployed into low Earth orbit.

The Anatomy of a Satellite Hijack

The research presented at DEF CON 2024 focused on creating a realistic testbed to model these vulnerabilities. The team used a Raspberry Pi as the core processing unit, paired with RFM69HCW radio modules to simulate the communication link between a ground station and a satellite. This setup is surprisingly representative of real-world small satellite architectures, where size and power constraints often force developers to prioritize functionality over security.

The core of the attack involved a Man-in-the-Middle (MitM) scenario. Because the communication protocol lacked cryptographic signing, the researchers were able to intercept the radio frequency packets. By identifying the specific byte structure used for command-and-control, they could inject their own configuration messages.

The attack flow was straightforward:

1. Reconnaissance: Capture legitimate traffic to identify the command structure and state transitions.
2. Injection: Send a crafted configuration message using the 0xFC byte identifier to force the satellite to accept the attacker as the legitimate ground station.
3. Takeover: Once the satellite accepted the new ID, it ignored all subsequent commands from the original ground station, effectively locking out the operator.

This is a classic example of Broken Access Control, where the system assumes that any entity capable of sending a signal is an authorized operator. In a real-world engagement, this would allow an attacker to not only deny service to the operator but also to exfiltrate sensitive imagery or manipulate the satellite's orientation, potentially causing permanent hardware damage by exposing sensors to the sun.

Technical Realities of Space-Based Exploitation

What makes this research particularly compelling is the move from theoretical modeling to hardware-in-the-loop testing. The team didn't just run simulations; they deployed their "Small Satellite Defender" software on an actual orbiting satellite provided by Lockheed Martin.

The software itself acts as a lightweight monitor, tracking system metrics like CPU usage, memory, and file integrity. It uses GNU Octave to visualize these metrics, allowing ground operators to spot anomalies in real-time. For a pentester, the takeaway is clear: if you are auditing an IoT or embedded system, look for the "health check" mechanisms. If the system is reporting its own state, that reporting channel is often a goldmine for identifying where the system is vulnerable to injection or state manipulation.

The team encountered a significant hurdle when moving from their Python-based testbed to the production satellite hardware: the production environment required a transition to Bash scripts. This is a common reality in embedded security. You might develop a perfect exploit in a high-level language, only to find that the target environment has a stripped-down shell or a completely different runtime. Understanding how to port your payloads across different architectures is what separates a script kiddie from a researcher.

Why This Matters for Pentesters

You might think that unless you are working for a defense contractor, satellite security is irrelevant. That is a dangerous assumption. The protocols used in these small satellites are often derived from standard industrial communication protocols. If you are testing SCADA systems or industrial control networks, you are likely dealing with the same lack of authentication and command validation.

When you are on an engagement, stop treating the communication link as a black box. Use tools like Nmap or Wireshark to map out the traffic, but don't stop there. Look for the "first byte" identifiers that dictate state. If you can identify the command structure, you can often find ways to trigger unintended state transitions.

The Path to Hardening

Defending these systems requires a shift in mindset. The researchers emphasized that patching in space is nearly impossible. Once a satellite is launched, you are stuck with the code you sent up. This makes secure development lifecycles and rigorous pre-launch testing non-negotiable.

The most effective mitigation is simple: implement command validation. Every command sent to the satellite should be signed, and the satellite should verify that signature before execution. Additionally, implementing a "heartbeat" or health check that reports system metrics back to the ground station allows operators to detect when an unauthorized entity has taken control.

If you are building or auditing these systems, start by assuming the communication link is compromised. If your system can survive a malicious actor sending arbitrary commands, you have already won half the battle. The next time you are looking at an embedded device, ask yourself: what happens if I send a command that the developer never intended to be sent? The answer to that question is usually where the most interesting bugs are hiding.