Red Teaming Space Systems | Satellite Security

How Space Red Teaming Differs

Red teaming space systems is fundamentally different from red teaming enterprise IT or even industrial control systems. The constraints imposed by physics, orbital mechanics, RF propagation, and the impossibility of physical access to on-orbit assets create an environment where traditional red team playbooks are insufficient, and where mistakes during live testing can have irreversible consequences.

Unique Constraints of the Space Domain

RF as the primary attack medium. Unlike terrestrial networks where attackers can exploit wired connections, wireless LAN, or even physical access, almost every interaction with a spacecraft happens over radio frequency links. This means the red team must understand signal propagation, link budgets, antenna gain patterns, modulation schemes, and the physics that govern whether a signal can actually reach its target. An attacker cannot simply “plug in” to a satellite — they must transmit with sufficient power, at the correct frequency, with the correct modulation, from a location with line-of-sight to the spacecraft.

Orbital mechanics dictate engagement windows. A satellite in low Earth orbit (LEO) may only be visible from a given ground station for 5-15 minutes per pass. The red team cannot pause and resume at will — if a command window is missed, the next opportunity may be hours later. Geostationary (GEO) satellites offer continuous visibility but operate at much greater distances (35,786 km), requiring significantly more transmit power and larger antennas.

Non-reversible consequences. Some actions on a spacecraft are irreversible. Firing thrusters consumes finite propellant and permanently alters the orbit. Corrupting firmware on a radiation-hardened processor that lacks a secure recovery mechanism can render the spacecraft permanently inoperable. There is no “undo” button in space.

Electromagnetic spectrum regulation. Transmitting RF signals is heavily regulated. Red team operations that involve active RF transmission require coordination with national spectrum regulators (FCC in the US, Ofcom in the UK, ITU internationally). Unauthorized transmission on satellite frequencies is a federal crime in most jurisdictions and can interfere with other space systems, including safety-of-life services.

Supply chain complexity. Satellite systems involve components from dozens of vendors across multiple countries, with development timelines spanning years. The hardware and software stack is deeply layered — from radiation-hardened ASICs to real-time operating systems to ground segment enterprise software — and the red team must be prepared to operate across all of these layers.

Comparison with Traditional IT/OT Red Teaming

Dimension	IT Red Teaming	OT/ICS Red Teaming	Space Systems Red Teaming
Physical access	Often assumed (internal threat)	Restricted but achievable	Impossible for space segment; restricted for ground
Communication medium	Ethernet, Wi-Fi, internet	Serial, fieldbus, Ethernet	RF links (S-band, X-band, Ka-band, UHF)
Engagement windows	Unlimited (always connected)	Usually continuous	Orbital pass windows (minutes for LEO)
Reversibility	High (restore from backup)	Medium (process disruption possible)	Low to none (propellant, orbit, hardware damage)
Regulatory burden	Standard pentest agreements	Safety certifications, NERC CIP	ITAR, EAR, FCC licensing, ITU coordination
Latency	Milliseconds	Milliseconds to seconds	240ms-2.4s round trip (LEO to GEO)
System lifespan	3-5 years	15-30 years	5-20 years (no hardware upgrades possible)
Safety impact	Data loss, downtime	Physical process disruption, safety	Collision risk, debris generation, loss of critical services

Rules of Engagement for Space

Rules of engagement (ROE) for space red teaming must be significantly more restrictive than for terrestrial operations. Key ROE elements include:

No-fire zones: Specific commands that must never be executed during testing (thruster firings, solar array repointing, deorbit sequences)
Safe mode triggers: Defined conditions under which testing must immediately halt (unexpected telemetry changes, loss of communication, thermal excursions)
RF transmission constraints: Exact frequencies, power levels, durations, and geographic locations approved for active RF testing
Coordination requirements: Notification to satellite operators, spectrum regulators, and potentially space situational awareness organizations before any active testing
Abort procedures: Pre-defined steps to immediately cease operations and restore the system to a known-good state
Legal review: Export control (ITAR/EAR) review of all tools, techniques, and findings before sharing across organizational or national boundaries

Legal and Regulatory Considerations

Space system red teaming intersects with a dense web of legal and regulatory requirements that do not apply to terrestrial engagements:

ITAR (International Traffic in Arms Regulations): Many satellite technologies are classified as defense articles under the US Munitions List. Red team findings, tools, and techniques that reveal vulnerabilities in ITAR-controlled systems may themselves be ITAR-controlled, restricting who can view them and how they can be shared. Foreign nationals on the red team may be prohibited from accessing certain systems or findings without a State Department license.
EAR (Export Administration Regulations): Satellite components and technologies controlled under the Commerce Control List have their own export restrictions that affect multinational red team operations and cross-border sharing of vulnerability information.
FCC and ITU regulations: Any active RF transmission during testing requires appropriate spectrum authorization. Transmitting on satellite frequencies without authorization is a federal offense under the Communications Act and can result in fines exceeding $100,000 per violation.
Computer Fraud and Abuse Act (CFAA): Even with authorization from the satellite operator, the red team must ensure that their activities do not inadvertently affect third-party systems (shared ground infrastructure, adjacent satellites, interconnected networks).
Insurance implications: Satellite operators carry launch and in-orbit insurance policies that may contain clauses regarding intentional testing or modification of spacecraft systems. The red team engagement must be coordinated with insurers to avoid policy invalidation.
Space debris regulations: Any red team action that could result in uncontrolled orbital changes or fragmentation events would violate national and international space debris mitigation guidelines, with potential liability under the Outer Space Treaty’s liability regime.

Why Tabletop Exercises Come First

Before any live testing against space systems, tabletop exercises are essential. These exercises allow stakeholders to walk through attack scenarios, identify potential consequences, validate rules of engagement, and build the shared understanding necessary for safe live operations. Tabletop exercises for space systems should model realistic orbital scenarios, include representatives from operations, engineering, and safety teams, and specifically explore cascading failure modes that could result from red team actions.

Effective tabletop exercises for space red teaming should include:

Scenario injection: Present the operations team with indicators of a cyberattack (anomalous telemetry, unexpected commands in the log, spectrum monitoring alerts) and observe how they respond
Decision point mapping: Identify where operators must make critical decisions (e.g., whether to command safe mode, whether to execute an emergency key rotation) and what information they need to make those decisions
Cross-team coordination: Practice the handoffs between cybersecurity incident responders, satellite operations engineers, spectrum management, legal counsel, and executive leadership
Consequence modeling: Walk through the cascading effects of specific attack scenarios, including second-order impacts on other satellites sharing ground infrastructure, downstream users, and interdependent services
ROE validation: Test the rules of engagement under realistic pressure to identify gaps, ambiguities, or scenarios not covered by the current ROE

Hack-A-Sat Deep Dive

Hack-A-Sat is the US Space Force (USSF) and Air Force Research Laboratory (AFRL) capture-the-flag competition focused on satellite cybersecurity. Launched in 2020, it has become the premier event for testing offensive and defensive capabilities against realistic space system architectures.

Background and Purpose

The competition emerged from a recognition within the US Department of Defense that space systems were increasingly vulnerable to cyber threats, yet the security research community had almost no access to representative space system testbeds. Traditional bug bounty and CTF programs focused on web applications, networks, and binaries — none addressed the unique challenges of satellite communication protocols, orbital mechanics, or ground station operations.

Hack-A-Sat serves multiple purposes: identifying talented security researchers with space-relevant skills, stress-testing defensive architectures, building a community of practice around space cybersecurity, and demonstrating to the broader space industry that these systems can and will be targeted.

Yearly Progression

Year	Event	Key Innovation	Challenge Focus	Final Format
2020	Hack-A-Sat 1	First space-focused CTF at scale	Ground station exploitation, satellite bus, signal processing	Virtual (COVID)
2021	Hack-A-Sat 2	Flatsat hardware-in-the-loop	Expanded RF challenges, flight software, crypto	Virtual with hardware
2022	Hack-A-Sat 3	Full ground-to-space simulation	Realistic TT&C chains, multi-stage attacks	In-person (DEF CON 30)
2023	Hack-A-Sat 4	Moonlighter — first on-orbit CTF	Live satellite hacking, real RF uplink/downlink	In-person (DEF CON 31)
2024	Hack-A-Sat 5	Enhanced on-orbit operations	Advanced persistence, multi-satellite scenarios	In-person (DEF CON 32)

Challenge Categories

Hack-A-Sat challenges span the full satellite system stack:

Ground station exploitation. Teams must compromise ground segment software — command and control applications, telemetry processing systems, scheduling databases, and network infrastructure connecting ground stations to mission operations centers. These challenges test traditional IT security skills applied to space-specific software like COSMOS, OpenC3, and custom TT&C applications.

Satellite bus commands. Challenges requiring teams to craft valid commands to satellite subsystems — attitude determination and control (ADCS), electrical power system (EPS), thermal management, and the onboard computer (OBC). This requires understanding CCSDS command packet structures, command authentication mechanisms, and the operational constraints of each subsystem.

RF signal processing. Teams receive raw RF captures (IQ samples) and must demodulate, decode, and extract data. Challenges progress from simple AM/FM demodulation to complex spread-spectrum signals, OFDM, and custom modulation schemes. Tools like GNU Radio, SigDigger, and inspectrum are essential. Some challenges require teams to transmit crafted RF signals to interact with simulated (or real) space-to-ground links.

Orbital mechanics. These challenges require calculating satellite positions, predicting pass times, computing transfer orbits, and solving Lambert’s problem for rendezvous trajectories. Teams use libraries like Skyfield, SGP4, and poliastro. Understanding Two-Line Element (TLE) sets, coordinate reference frames (ECI, ECEF, geodetic), and Keplerian orbital elements is mandatory.

Cryptographic challenges. Satellite systems often implement custom or constrained cryptographic protocols. Challenges include breaking weak key exchange mechanisms on bandwidth-constrained links, exploiting timing side-channels in space-qualified crypto implementations, and recovering keys from partially corrupted telemetry streams.

Flight software reverse engineering. Teams receive compiled flight software binaries (often for non-standard architectures like SPARC, LEON3, or RAD750) and must reverse engineer command handlers, find vulnerabilities, and craft exploits — all while understanding the real-time constraints and fault-tolerance mechanisms of space-grade RTOS environments like VxWorks and RTEMS.

Hack-A-Sat 4 and Moonlighter

Hack-A-Sat 4 at DEF CON 31 (2023) was a landmark moment for space cybersecurity. For the first time, competitors hacked a live satellite in orbit — Moonlighter, a 3U CubeSat specifically designed as a cybersecurity research platform.

Moonlighter specifications:

3U CubeSat form factor (10x10x30 cm)
Deployed from the International Space Station (ISS)
Carried a dedicated cybersecurity payload isolated from critical bus systems
Operated on amateur radio frequencies for uplink/downlink
Included a “sandbox” execution environment for running attacker-supplied code
Featured a watchdog system that could reset the payload to a known-good state

What Moonlighter taught the community:

RF is the great equalizer. Even with the satellite in orbit, the RF link was the bottleneck. Teams had to coordinate with ground station networks (SatNOGS and commercial stations) to maintain communication windows, and link margin was a constant constraint.
Timing is everything. With LEO passes lasting only minutes, teams had to script their attack chains to execute autonomously once a communication window opened. Manual interactive exploitation was impractical.
The gap between simulation and reality is significant. Teams that excelled in the qualification rounds (which used simulated environments) often struggled with the real satellite, where signal-to-noise ratios, Doppler shift, and atmospheric effects introduced errors that simulators did not fully capture.
Defensive isolation works. Moonlighter’s architecture deliberately isolated the cybersecurity payload from critical bus functions. This demonstrated that even with full compromise of a payload, proper segmentation can protect core spacecraft operations.
Community engagement matters. The event generated massive interest from both the security community and the space industry, demonstrating that crowdsourced security research can complement traditional classified testing programs.

Notable Winning Team Techniques

Winning teams across Hack-A-Sat competitions have demonstrated techniques including:

Automated RF signal classification using machine learning to rapidly identify modulation schemes
Custom GNU Radio flowgraphs for real-time demodulation of non-standard waveforms
CCSDS protocol fuzzers that generate malformed but structurally valid telecommand packets
Orbital propagation tools integrated with ground station schedulers to maximize communication time
Binary exploitation chains against VxWorks-based flight software, including ROP chains adapted for SPARC architecture
Side-channel attacks against software-defined cryptographic implementations running on radiation-hardened processors
Multi-stage attacks that combined ground segment web application compromise with subsequent command injection through the legitimate TT&C chain
Electromagnetic side-channel analysis of ground station RF equipment to extract encryption keys used for command link protection

Lessons for the Industry

The cumulative effect of five years of Hack-A-Sat competitions has been transformative for the space cybersecurity community:

Vulnerability classes are consistent. The same categories of vulnerabilities appear year after year — hardcoded credentials, insufficient command authentication, insecure firmware update mechanisms, and parsing vulnerabilities in protocol implementations. This consistency indicates systemic industry weaknesses rather than isolated bugs.
The talent pipeline is growing. Early competitions attracted primarily CTF veterans who learned space concepts during the event. Recent competitions feature teams with genuine space domain expertise, indicating that the space security workforce is maturing.
Open-source tooling accelerates research. Tools developed for Hack-A-Sat challenges — CCSDS packet libraries, orbital mechanics solvers, satellite protocol fuzzers — have become community resources that lower the barrier to entry for space security research.
Simulation fidelity matters. The progression from pure software challenges to flatsat HITL to on-orbit operations has shown that each step closer to reality reveals new vulnerability classes that simulations miss.

Aerospace Village at DEF CON

History and Mission

The Aerospace Village was established at DEF CON 27 (2019) as a dedicated space for aviation and space cybersecurity research. Founded by a coalition of security researchers, industry professionals, and government representatives, the village provides a neutral forum for demonstrating vulnerabilities, sharing research, and building relationships between the hacker community and the aerospace industry.

The village’s mission is to break down the barriers between the security research community and the aerospace/space sector — barriers that have historically been reinforced by classification requirements, ITAR restrictions, and an industry culture that viewed external security research as a threat rather than a resource.

Notable Presentations and Demonstrations

Key contributions from the Aerospace Village include:

VSAT terminal exploitation (2019): Researchers demonstrated remote compromise of commercial VSAT terminals through exposed management interfaces, default credentials, and firmware vulnerabilities — showing that the “last mile” of satellite communications is often the weakest link
GPS spoofing demonstrations: Live demonstrations of GPS signal spoofing using software-defined radios costing under $300, showing the ease with which location and timing services can be manipulated
ADS-B injection: Demonstrations of injecting false aircraft position reports into ADS-B receivers, highlighting the lack of authentication in aviation surveillance protocols (directly relevant to space situational awareness systems that share similar design patterns)
Satellite ground station software vulnerabilities: Disclosure of vulnerabilities in commercial satellite operations software, including command injection, authentication bypass, and insecure API endpoints
Space protocol analysis: Deep dives into CCSDS protocol implementations, identifying parsing vulnerabilities and authentication weaknesses

Community Contributions to Space Security

The Aerospace Village has catalyzed several important developments:

Publication of open-source satellite security testing tools
Creation of educational resources for security professionals entering the space domain
Establishment of responsible disclosure channels between security researchers and satellite operators
Development of threat models that translate traditional cybersecurity concepts into space-relevant frameworks
Mentorship programs connecting experienced aerospace security professionals with newcomers

Relationship with Government and Military

The Aerospace Village maintains productive relationships with the US Space Force, Air Force Research Laboratory, CISA, NASA, and allied nation space agencies. These relationships enable:

Clearance-appropriate briefings on threat intelligence relevant to the security research community
Coordination on responsible disclosure of vulnerabilities affecting defense and government space systems
Recruitment pipeline for government space cybersecurity positions
Feedback loop between the research community and policy development for space cybersecurity standards
Joint development of training materials and educational curricula for space cybersecurity
Bridge between classified government threat knowledge and the unclassified commercial security community

The village has been instrumental in shifting the aerospace industry’s posture from “security through obscurity” toward genuine engagement with the security research community. This cultural shift — accepting that independent researchers finding vulnerabilities is preferable to adversaries finding them first — mirrors the transformation that occurred in the software industry over the past two decades and is now accelerating in the space sector.

Commercial Red Teaming

How Satellite Operators Commission Red Team Assessments

Commercial satellite operators are increasingly recognizing the need for offensive security testing, driven by regulatory pressure (the 2020 Space Policy Directive-5, NIST framework adoption, and insurance requirements), high-profile incidents, and the growing threat landscape from state-sponsored actors. However, the market for space-specific red team services remains immature compared to traditional IT penetration testing — there are fewer qualified providers, fewer established methodologies, and less industry consensus on what constitutes a thorough assessment.

The process typically follows this pattern:

Threat assessment: The operator identifies their threat model and determines which threat actors and attack scenarios are most relevant to their constellation and mission
Scope definition: Working with the red team, the operator defines which segments (ground, link, space, user) are in scope, what assets can be targeted, and what actions are prohibited
Legal and regulatory review: ITAR/EAR compliance review, spectrum licensing verification, coordination with insurers (satellite insurance policies may have clauses regarding intentional testing)
Test execution: Phased execution starting with passive reconnaissance, progressing through active testing of authorized targets
Reporting and remediation: Detailed findings with exploitation evidence, risk ratings calibrated to space mission impact, and actionable remediation guidance

Scope Definition Challenges

Defining scope for space system red teams is uniquely difficult:

Multi-segment interdependencies: Compromising the ground segment may enable attacks on the space segment, making it difficult to scope one without the other
Third-party dependencies: Satellite operators often use third-party ground station networks (KSAT, SSC, AWS Ground Station), shared launch infrastructure, and common component suppliers — all of which are potential attack vectors but may be outside the operator’s authority to authorize testing against
International jurisdiction: A single satellite system may involve ground stations in multiple countries, each with different legal frameworks for authorized security testing
Shared infrastructure: Multiple satellites may share ground station infrastructure, and testing against one operator’s systems could inadvertently affect another’s

Testing in Simulation vs. Production

The vast majority of commercial satellite red team operations are conducted against simulated environments rather than production systems. This is not a limitation — it is a deliberate safety measure.

Simulation-based testing uses software-defined satellite simulators that replicate the behavior of flight software, ground station operations, and RF link characteristics. These simulators can model realistic telemetry streams, command response behaviors, and even orbital dynamics. The advantage is unlimited testing without risk to operational assets. The limitation is that simulators may not faithfully reproduce all edge cases, timing behaviors, and failure modes of real hardware.

Production testing, when conducted, is typically limited to the ground segment and user terminals. Active testing against on-orbit spacecraft is exceptionally rare outside of government programs like Hack-A-Sat.

Satellite Digital Twins

Digital twins — high-fidelity virtual replicas of satellite systems — are becoming the gold standard for security testing. A satellite digital twin includes:

Flight software replica: The actual flight software running on processor emulators that match the onboard hardware
Environmental models: Orbital position, sun angle, thermal conditions, radiation environment, and atmospheric drag
RF link simulation: Realistic link budget modeling including path loss, atmospheric attenuation, Doppler shift, and interference
Ground segment integration: Connection to actual (or replicated) ground station software for end-to-end testing
Fault injection: Ability to simulate hardware failures, radiation-induced bit flips (SEUs), and degraded component performance

Digital twins allow red teams to test attack scenarios that would be too dangerous to attempt on operational systems, including firmware corruption, subsystem disruption, and scenarios that could cause loss of spacecraft control.

Hardware-in-the-Loop (HITL) Testbeds

HITL testbeds bridge the gap between pure simulation and live testing by incorporating actual satellite hardware components:

Flatsat configurations: Flight-representative hardware (processor boards, radio transceivers, power systems) laid out on a bench and connected as they would be on the spacecraft, but accessible for monitoring and debugging
RF testbeds: Anechoic chambers or cabled RF setups that allow testing of real radio hardware without over-the-air transmission
Engineering model spacecraft: Full spacecraft assemblies built with flight-equivalent (but not flight-qualified) hardware, used for integration testing and increasingly for security testing
EGSE (Electrical Ground Support Equipment): The actual hardware interfaces used to communicate with the spacecraft during ground operations, which are themselves potential attack targets

HITL testbeds are particularly valuable for testing RF-layer attacks because they allow the red team to interact with actual radio hardware — transmitting crafted signals, attempting to jam or spoof communications, and testing the resilience of modulation and coding schemes — without the regulatory burden of over-the-air transmission. The signals are contained within cabled or shielded environments, eliminating spectrum licensing requirements while maintaining RF realism.

For operators building internal red team programs, establishing a permanent HITL testbed is the single most impactful investment. The testbed provides a safe environment for training, tool development, vulnerability research, and pre-engagement rehearsal. The cost of a representative testbed (typically $500K-$2M depending on fidelity) is trivial compared to the cost of a spacecraft or the revenue loss from a successful attack.

For a detailed list of tools and platforms used in these testbeds, see the Tools & Resources page.

Red Team Composition

Required Skill Sets

Effective space system red teams require an unusually broad range of expertise. No single individual possesses all of these skills — the team must be composed to cover the full attack surface.

RF engineering. Understanding antenna theory, signal propagation, modulation/demodulation, link budget analysis, and spectrum analysis. The ability to operate software-defined radios (SDRs), build custom GNU Radio flowgraphs, and analyze raw IQ data is essential. Knowledge of satellite frequency bands (L, S, C, X, Ku, Ka) and their propagation characteristics is required.

Embedded systems security. Experience with reverse engineering firmware for non-x86 architectures (SPARC, ARM, MIPS, PowerPC — all used in space-qualified processors). Familiarity with real-time operating systems (VxWorks, RTEMS, FreeRTOS), JTAG/SWD debugging, and hardware hacking techniques (bus sniffing, glitching, side-channel analysis).

Network and application security. Traditional penetration testing skills applied to ground segment infrastructure — web application testing, Active Directory attacks, cloud security (AWS Ground Station, Azure Orbital), API security, and network pivoting. Ground segments are increasingly cloud-connected, making conventional network security skills directly applicable.

Orbital mechanics. Sufficient understanding of Keplerian orbits, perturbation theory, coordinate systems, and orbital maneuvers to calculate engagement windows, predict satellite positions, and understand the operational constraints that shape how systems are designed and operated.

Protocol analysis. Deep knowledge of space communication protocols — CCSDS (Consultative Committee for Space Data Systems) packet structures, Space Data Link protocols, Proximity-1, DTN (Delay Tolerant Networking), and proprietary vendor protocols. The ability to write custom dissectors and fuzzers for these protocols is highly valuable.

Domain expertise. Understanding of how satellite systems are operated, including mission planning, anomaly resolution procedures, and the organizational dynamics of satellite operations centers. This operational knowledge helps red teams identify realistic attack paths that exploit human factors and procedural weaknesses.

Team Structure Recommendations

A well-structured space system red team typically includes:

1-2 RF/signal processing specialists: Lead RF-related attack vectors and support link analysis
1-2 embedded systems/firmware analysts: Focus on flight software, onboard computer exploitation, and hardware security
2-3 network/application security testers: Cover ground segment infrastructure, web applications, cloud environments, and user terminals
1 orbital mechanics/space operations specialist: Provide domain context, calculate engagement windows, and validate operational realism of attack scenarios
1 team lead with space domain experience: Coordinate operations, manage rules of engagement, and interface with the satellite operator
1 legal/compliance advisor (part-time): Ensure ITAR/EAR compliance, validate ROE, review findings for export control implications

Training Pathways

For security professionals seeking to enter the space domain:

Start with Hack-A-Sat archives: All qualification challenges from previous years are publicly available with write-ups from competing teams
Learn RF fundamentals: Work through GNU Radio tutorials, experiment with RTL-SDR hardware, and practice receiving real satellite signals (weather satellites like NOAA APT are excellent starting points)
Study CCSDS standards: The core protocol specifications are freely available and form the foundation of most satellite communications
Build orbital mechanics intuition: Work with tools like Skyfield, Celestrak TLE data, and satellite tracking applications
Engage with the community: Participate in Aerospace Village events, contribute to open-source space security tools, and attend Space ISAC briefings
Pursue relevant certifications: GIAC GXPN (exploit development), OSCP/OSCE (penetration testing), and amateur radio licensing provide foundational credentials

For hands-on pentesting methodologies applicable to satellite systems, see the Penetration Testing page.

Attack Path Modeling

Kill Chains for Satellite Systems

Traditional cyber kill chains (Lockheed Martin, MITRE ATT&CK) require adaptation for space systems. The following kill chain model accounts for the unique characteristics of satellite architectures:

graph TD
    A["1. Reconnaissance<br/>OSINT, frequency monitoring,<br/>TLE analysis, vendor research"] --> B["2. Weaponization<br/>Craft malicious commands,<br/>build RF transmit capability,<br/>develop exploits"]
    B --> C["3. Initial Access<br/>Ground segment compromise,<br/>RF link exploitation,<br/>supply chain insertion"]
    C --> D{"Access Vector?"}
    D -->|Ground Path| E["4a. Ground Pivot<br/>Escalate privileges in ground<br/>segment, access TT&C systems,<br/>compromise command chain"]
    D -->|RF Path| F["4b. RF Exploitation<br/>Command injection, replay attacks,<br/>signal spoofing, jamming<br/>for denial of service"]
    D -->|Supply Chain| G["4c. Pre-positioned Access<br/>Backdoored firmware,<br/>compromised components,<br/>malicious updates"]
    E --> H["5. Command & Control<br/>Establish persistent access<br/>to command systems,<br/>intercept telemetry"]
    F --> H
    G --> H
    H --> I["6. Spacecraft Interaction<br/>Send unauthorized commands,<br/>modify spacecraft configuration,<br/>alter mission parameters"]
    I --> J["7. Mission Impact<br/>Service disruption, data theft,<br/>orbit modification, sensor<br/>manipulation, permanent damage"]
    J --> K["8. Persistence & Cleanup<br/>Maintain access across<br/>operator response, erase<br/>forensic evidence"]

    style A fill:#1a1a2e,stroke:#e94560,color:#fff
    style B fill:#1a1a2e,stroke:#e94560,color:#fff
    style C fill:#1a1a2e,stroke:#e94560,color:#fff
    style D fill:#16213e,stroke:#0f3460,color:#fff
    style E fill:#1a1a2e,stroke:#e94560,color:#fff
    style F fill:#1a1a2e,stroke:#e94560,color:#fff
    style G fill:#1a1a2e,stroke:#e94560,color:#fff
    style H fill:#1a1a2e,stroke:#e94560,color:#fff
    style I fill:#0f3460,stroke:#e94560,color:#fff
    style J fill:#e94560,stroke:#fff,color:#fff
    style K fill:#1a1a2e,stroke:#e94560,color:#fff

MITRE ATT&CK Mapping for Space

While MITRE has not published a dedicated ATT&CK matrix for space systems, several ATT&CK for ICS techniques map directly to satellite system attack scenarios:

ATT&CK Technique	Space System Application
T0817 — Drive-by Compromise	Compromising ground station operator workstations through watering hole attacks on space industry forums
T0886 — Remote Services	Exploiting remote access to ground station infrastructure (SSH, VPN, remote desktop to TT&C systems)
T0831 — Manipulation of Control	Sending unauthorized telecommands to alter spacecraft behavior
T0832 — Manipulation of View	Modifying telemetry data to hide anomalies or present false spacecraft state to operators
T0814 — Denial of Service	RF jamming of uplink/downlink, or flooding ground segment networks
T0857 — System Firmware	Modifying onboard flight software or firmware through unauthorized updates
T0821 — Modify Controller Tasking	Altering scheduled command sequences or mission timelines
T0856 — Spoof Reporting Message	Injecting false telemetry into the ground processing chain
T0882 — Theft of Operational Information	Exfiltrating mission data, imagery, or communication content

The Aerospace Corporation and CISA have developed supplementary threat frameworks specific to space, including the Space Attack Research and Tactic Analysis (SPARTA) matrix, which provides space-specific tactics, techniques, and procedures. For more on these frameworks, see the Frameworks & Standards page.

Threat Modeling Frameworks Adapted for Space

Several frameworks have been adapted for space system threat modeling:

STRIDE for Space. Microsoft’s STRIDE model (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) maps cleanly to satellite systems:

Spoofing: Impersonating a legitimate ground station to send commands, or spoofing GPS signals to a satellite’s navigation receiver
Tampering: Modifying telecommand packets in transit, altering firmware, or manipulating telemetry data
Repudiation: Lack of command authentication logs making it impossible to determine who issued a command
Information Disclosure: Intercepting unencrypted telemetry or payload data from the downlink
Denial of Service: Jamming RF links, overwhelming ground segment processing, or causing spacecraft safe mode entry
Elevation of Privilege: Escalating from payload access to bus control, or from monitoring to commanding privileges

SPARTA (Space Attack Research and Tactic Analysis). Developed by the Aerospace Corporation, SPARTA provides a space-specific taxonomy of adversary tactics and techniques organized into a matrix similar to ATT&CK. It covers the full lifecycle from reconnaissance through impact, with techniques specific to each segment (ground, link, space, user).

Attack Trees for Space. Attack trees provide a structured decomposition of high-level objectives into specific attack paths. For satellite systems, the root node typically represents the adversary’s ultimate goal (e.g., “Disrupt satellite communications service”), with child nodes representing alternative approaches (ground compromise, RF attack, supply chain), and leaf nodes representing specific technical actions. Attack trees are particularly useful for space systems because they make the multi-segment, multi-path nature of satellite attacks explicit and allow defenders to identify the most cost-effective points for investment in security controls.

TARA (Threat Agent Risk Assessment). Originally developed for automotive cybersecurity, TARA has been adapted for space applications. It provides a structured methodology for identifying threat agents, enumerating attack vectors, assessing feasibility and impact, and prioritizing mitigations. TARA’s emphasis on feasibility assessment is particularly valuable for space systems, where many theoretical attacks are impractical due to the cost and expertise required.

Example Attack Scenarios

Scenario 1: Ground-to-space command injection. An attacker compromises an internet-facing web application at a ground station facility, pivots through the corporate network to the operational technology network, gains access to the command and control workstation, and uses legitimate command software to send unauthorized telecommands to the spacecraft. The commands alter the satellite’s attitude, causing it to point its high-gain antenna away from its intended coverage area and disrupting service for all users.

Scenario 2: Supply chain firmware implant. A nation-state actor compromises a subcontractor responsible for developing flight software for a commercial communications satellite. The actor inserts a dormant backdoor into the command handler that activates upon receiving a specific trigger sequence. Years later, after the satellite is operational, the actor transmits the trigger via a rogue ground station, gaining persistent command access to the spacecraft.

Scenario 3: RF signal intelligence and replay. An attacker with a modest SDR setup and a directional antenna monitors the uplink frequency of a commercial satellite operator. Over weeks, they capture thousands of telecommand frames, correlating command sequences with observable satellite behavior changes. Using captured frames, they identify patterns in the command structure and replay modified commands during a subsequent pass, exploiting weak or absent command authentication to inject unauthorized instructions.

Scenario 4: User terminal as pivot point. An attacker targets a VSAT terminal deployed at a remote site with poor physical security. They gain physical access to the terminal, extract firmware, discover hardcoded credentials and API keys for the satellite operator’s management portal. Using these credentials, they access the operator’s network operations center, ultimately reaching command and control systems for the entire constellation.

Scenario 5: GNSS spoofing for timing disruption. An attacker deploys a portable GPS spoofing device near a ground station that relies on GPS for timing synchronization. By gradually shifting the spoofed time signal, the attacker causes the ground station’s time reference to drift from true UTC. This time drift causes cryptographic authentication of telecommands to fail (because the spacecraft and ground station no longer agree on the current time), effectively locking the operator out of their own satellite. The attack is particularly insidious because the ground station operators may not immediately recognize that their time source is compromised, attributing the authentication failures to a spacecraft anomaly.

Each of these scenarios illustrates why defense-in-depth is essential for satellite systems — no single security control can prevent all attack paths. For detailed information on specific attack techniques referenced in these scenarios, see the Attack Vectors page.

Key Takeaways

Space red teaming is a nascent but rapidly maturing discipline. The Hack-A-Sat competitions have demonstrated that talented security researchers can identify and exploit vulnerabilities in realistic satellite system environments. The Aerospace Village continues to build bridges between the security research community and the space industry. Commercial operators are beginning to invest in offensive security testing, though the field is constrained by the scarcity of professionals with the required cross-disciplinary expertise.

The most important lesson from space red teaming to date: the ground segment remains the most accessible and most exploited attack surface. While on-orbit exploitation captures headlines and drives conference attendance, the reality is that most satellite system compromises will begin with conventional IT attacks against ground infrastructure and escalate from there. Red teams should prioritize ground segment testing while building the specialized capabilities needed for RF and space segment operations.

Organizations building space red team capabilities should invest in simulation environments, participate in community events like Hack-A-Sat and Aerospace Village, and build cross-functional teams that combine traditional security expertise with space domain knowledge. The attack surface is expanding rapidly as commercial space grows, and the window to get ahead of adversaries is narrowing.

For red teams planning their first space system engagement, the recommended progression is: (1) tabletop exercises to establish rules of engagement and build operational understanding, (2) ground segment penetration testing using conventional IT/OT techniques, (3) simulation-based testing of RF and command chain attacks, (4) HITL testing with representative hardware, and only then (5) carefully controlled testing against production systems with full safety monitoring. Each phase builds the knowledge and confidence needed for the next, while progressively reducing the risk of unintended consequences.