PaperlayerView exact revision on arXiv

Source-linked AI summary

SpyChain: Multi-Vector Supply Chain Attacks on Small Satellite Systems

Jack Vanlyssel, Enrique Sobrados, Ramsha Anwar, Gruia-Catalin Roman, Afsah Anwar

arXiv:2510.06535v2cs.CR

TL;DR

Small satellites rely on third-party components that may have privileged access but limited assurance, while supply-chain malware in flight-software stacks has received little study. SpyChain implements solo and colluding attack scenarios in NASA’s NOS3 simulator. The authors report that these attacks can coordinate, exfiltrate telemetry, and abuse implicit trust to evade detection, and they identify simulation as a boundary on the findings.

  • Problem

    The study addresses limited evidence about covert supply-chain malware in third-party satellite components, which may have privileged access despite limited assurance.

    Source: §1 · p. 1, §2.1 · p. 2

  • Method

    SpyChain implements five escalating attack scenarios in NASA’s NOS3 simulation, including solo and colluding components.

    Source: §1 · p. 2, §8 · p. 13

  • Results

    Across five scenarios, malicious components could coordinate, exfiltrate telemetry, and abuse implicit trust to avoid detection and compromise mission success.

    Source: §7 · p. 13

  • Takeaways & Limitations

    The findings support resilience measures including runtime monitoring, authenticated telemetry, anomaly detection, and post-launch validation.

    Source: §8 · p. 13

    The work was conducted in simulation, with no disruption to operational satellites or use of mission data.

    Source: Ethical Considerations · p. 14

Abstract

from arXiv · show

Small satellites are integral to scientific, commercial, and defense missions, but reliance on commercial off-the-shelf (COTS) hardware broadens their attack surface. Although supply chain threats are well studied in other cyber-physical domains, their feasibility and stealth in space systems remain largely unexplored. Prior work has focused on flight software, which benefits from strict security practices and oversight. In contrast, auxiliary COTS components often lack robust assurance yet enjoy comparable access to critical on-board resources, including telemetry, system calls, and the software bus. Despite this privileged access, the insider threat within COTS hardware supply chains has received little attention. In this work, we present SpyChain, the first end-to-end design and implementation of independent and colluding hardware supply chain threats targeting small satellites. Using NASA's satellite simulation (NOS3), we demonstrate that SpyChain can evade testing, exfiltrate telemetry, disrupt operations, and launch Denial of Service (DoS) attacks through covert channels that bypass ground monitoring. Our study traces an escalation from a simple solo component to dynamic, coordinating malware, introducing a taxonomy of stealth across five scenarios. We showcase how implicit trust in auxiliary components enables covert persistence and reveal novel attack vectors, highlighting a new multi-component execution technique that is now incorporated into the SPARTA matrix. Our findings are reinforced by acknowledgment and affirmation from NASA's NOS3 team. Finally, we implement lightweight onboard defenses, including runtime monitoring, to mitigate threats like SpyChain.

1 Introduction

Small satellites rely on third-party components that may lack the assurance applied to core flight software, despite access to telemetry and other privileged resources. SpyChain examines how malicious components can exploit that trust and demonstrates escalating solo and colluding attacks in simulation.

1 Introduction

  • Auxiliary COTS modules can access telemetry, issue software-bus commands, and manipulate shared memory despite receiving less assurance than core flight software.The paper identifies this contrast as an overlooked route for malicious functionality to persist through integration, launch, and operation.Source: §1 · p. 1
  • SpyChain models a pre-launch supply-chain insider and demonstrates covert channels, telemetry exfiltration, and arbitrary command injection through auxiliary modules.The framework is deployed in NASA’s NOS3 simulator.Source: §1 · p. 2
  • The authors recommend lightweight defenses, including runtime monitoring, software-bus authentication and access control, and syscall restrictions such as seccomp.They also advocate zero-trust module design, supply-chain transparency, and operator training.Source: §1 · p. 2
  • Five scenarios demonstrate attacks ranging from single-component malware to colluding components using covert file communication.The scenarios also use live satellite telemetry as dynamic activation or termination triggers, and achieve stealth through authorized APIs and system calls.Source: §1 · p. 2
  • The authors report a novel multi-component execution technique and state that it was added to the SPARTA matrix after notifying its maintainers.They also report that NASA’s NOS3 development team acknowledged the findings and expressed interest in future cybersecurity-focused testbed capabilities.Source: §1 · p. 2

2 Background and Related Work

Small-satellite development benefits from low-cost, modular COTS hardware, but limited visibility into proprietary components and constrained post-launch access complicate assurance. Prior satellite-security work has emphasized radio and network threats or privileged flight-software compromise, while coordinated supply-chain malware in flight-software stacks has received little study.

2.1 The Problem with COTS Components

  • Third-party components reduce small-satellite cost and development barriers, but may arrive without source code or visibility into internal logic, privileged access, and update mechanisms.Once in orbit, components are difficult to service or patch and may remain exposed for multi-year missions.Source: §2.1 · p. 2
  • Without source code, integrators cannot use static analysis or code review, while reverse engineering and fuzzing can exceed CubeSat teams’ resources and schedules.The cited OPS-SAT example relied on gray-box fuzzing through QEMU emulation.Source: §2.1 · pp. 2–3
  • Fragmented malware and coordinated activation can evade standard validation, while limited post-launch access and communication blind zones constrain anomaly response.The section also describes a fragmented space-cybersecurity regulatory landscape.Source: §2.1 · p. 3

2.2 Prior Research on Satellite Attacks

  • Prior satellite-security studies cover jamming, spoofing, firmware analysis, and satellite-broadband vulnerabilities, with much attention on radio, network, and user-terminal threats.The reviewed defensive work includes location-privacy protections and risk-scoring frameworks; firmware and onboard software receive relatively little attention.Source: §2.2 · p. 3
  • Satellite ransomware demonstrations assumed privileged access to edit and recompile flight software, whereas supply-chain malware in third-party modules was less examined.The paper argues that modifying the public cFS baseline or a mission flight build faces review and oversight barriers.Source: §2.2 · p. 3
  • Supply-chain compromise had been discussed mainly in theory or broad risk assessments, so the authors simulate coordinated malware in NASA’s NOS3 environment.The simulation studies persistence, stealth, and coordination in a realistic system context to ground countermeasures in observed behavior.Source: §2.2 · pp. 3–4

3 Threat Model

The threat model places a supply-chain insider in a modular satellite environment where components share broadly trusted resources. It describes an adversary able to receive downlinked telemetry, as well as system and operational constraints that complicate detection and response.

3.1 Adversary Model

  • The adversary has pre-launch vendor access to hardware, familiarity with the target flight software and operating system, and knowledge of telemetry routing and communication channels.The model notes that vendor development for a specific operating system and flight-software environment can provide some of this knowledge.Source: §3.1 · p. 4
  • The attacker is assumed to control a ground station within the satellite’s orbital path to receive exfiltrated telemetry when the spacecraft passes overhead.The paper notes that software-defined radios and community projects such as SatNOGS reduce the barrier to intercepting and processing downlinks.Source: §3.1 · p. 4

3.2 Attack Surface

  • The software bus permits unauthenticated telemetry and command exchange, while radio connections can downlink data outside monitored telemetry paths.File systems and operating-system interfaces can also provide covert storage or communication channels.Source: §3.2 · p. 4
  • Small satellites often lack persistent logging, runtime visibility, and dedicated intrusion defenses, while power, memory, CPU, and bandwidth constraints limit monitoring and response.Generated logs may be volatile, and downlink constraints can prevent raw forensic data from being streamed to the ground.Source: §3.2 · p. 4

3.3 Stakeholders

  • A covert compromise can threaten mission success and data integrity for operators and end users, while undermining confidence in vendors and flight-software assurance.The paper also identifies reputational and integration risks for component vendors and satellite developers.Source: §3.3 · p. 5

4 SpyChain Methodology

SpyChain studies data exfiltration, denial of service, and persistence through a sequence of attacks implemented in a simulated satellite environment. Its architectures use legitimate-looking components and interfaces, with triggers and coordination methods varying across scenarios.

4.1 Attack Objectives

  • SpyChain’s adversarial objectives are data exfiltration, denial of service, and persistence.The section also discusses disruption through telemetry manipulation or deceptive commands as an objective-related effect.Source: §4.1 · p. 5

4.2 Attack Architecture

  • The scenarios use standard cFS applications and communication channels, designed to pass integration and testing while avoiding operator scrutiny.The malware uses familiar Linux-based system calls to create communication channels and exfiltrate data over radio.Source: §4.2 · p. 5
  • Modular applications allow attacks to be distributed across components and coordinated through files or the software bus, with static or dynamic activation.The architectures include single-component attacks, multi-component coordination, and a file-based channel; GNSS measurements or time can trigger activation.Source: §4.2 · p. 5, Figure 2 · p. 6
  • Malicious applications subscribe to legitimate telemetry streams without cFS authentication or access control, making their subscriptions indistinguishable from normal operation.Components delay malicious behavior until a time- or sensor-based trigger occurs, so exfiltration begins after the predefined condition.Source: §4.2 · pp. 5–6

4.3 Attack Scenarios

SpyChain escalates from independent applications with static or telemetry-driven triggers to colluding components coordinated through the software bus or a FIFO file. Scenario 5 illustrates how the agents can activate in orbit, exfiltrate telemetry without ground control’s knowledge, and then persist or disrupt operations.

4.3 Attack Scenarios

  • The five scenarios escalate in architectural complexity, showing how even minimal capabilities can enable data exfiltration by exploiting implicit trust and architectural assumptions.Source: §4.3 · p. 6

Scenario 1 — Single Component, Static Time Trigger

Scenario 4 — Multi Component, Dynamic Trigger, Software Bus Coordination

Scenario 5 — Multi Component, Dynamic Trigger, File-Based Coordination

  • Scenario 5 combines a GNSS-triggered agent with a second agent activated through a FIFO file, which then transmits mission telemetry.The trigger agent detects orbital insertion and writes an activation command; the attack agent polls the file and uses the onboard radio.Source: Scenario 5 — Multi Component, Dynamic… · p. 7

4.4 Attack Timeline

  • Scenario 5’s agents remain dormant until orbital insertion; the file-based signal activates exfiltration over the radio without ground control’s knowledge.The trigger agent’s file write resembles ordinary embedded-system file access, while the attack agent can later crash flight software or flood the software bus.Source: §4.4 · p. 7

4.5 Satellite Simulation

The authors use NOS3 to emulate a satellite flight-software stack and implement SpyChain’s trigger and attack agents within cFS. Scenario 5 coordinates them through a FIFO and reuses the radio pathway to exfiltrate telemetry, under stated simulation assumptions.

4.5 Satellite Simulation

  • NOS3 emulates flight conditions with cFS, simulated hardware drivers, real-time telemetry, and COSMOS ground-station tools, enabling experiments without physical hardware.Source: §4.5 · p. 8
  • NOS3’s cFS applications communicate over a software bus without message authentication or access control, while real vendors typically provide binaries and interface specifications rather than source code.This leaves component internals opaque to integrators, as in the paper’s comparison with physical satellite architectures.Source: §4.5 · p. 8

4.6 Implementation Details

  • The Scenario 5 agents are built from an NOS3 example component and follow the standard cFS initialization and execution lifecycle.Source: §4.6 · p. 8
  • The trigger agent monitors GNSS telemetry for orbital insertion, writes “toggle_exfil” to a shared FIFO, and can later write “kill” to trigger a crash.The crash is implemented through a null-pointer dereference.Source: §4.6 · p. 8
  • The attack agent creates a FIFO for coordination and subscribes to housekeeping, events and services, software-bus statistics, and time-services telemetry.The FIFO synchronizes the agents and erases data when read; NOS3 lacks syscall auditing or runtime monitoring.Source: §4.6 · p. 8
  • The attack agent sends telemetry through the GENERIC_RADIO application’s UDP socket, and the authors assume accepted packets transmit successfully.NOS3 fixes the radio to one default ground-station endpoint and does not simulate directional antennas or frequency hopping.Source: §4.6 · p. 9

4.7 Stealth Characteristics

SpyChain’s stealth relies on trusted APIs, normal flight-software permissions, and avoiding anomalous telemetry before activation. The scenarios differ in detectability: centralized behavior may be found before launch, and software-bus coordination remains visible to operators, while Scenario 5’s FIFO channel is invisible to them.

4.7 Stealth Characteristics

  • Across scenarios, trusted APIs, normal flight-software permissions, and non-anomalous telemetry before activation help conceal malicious activity.The malware can remain dormant during ground testing and activate under mission-relevant conditions.Source: §4.7 · p. 9
  • Single-application scenarios can exfiltrate data undetected after launch, but centralized behavior could potentially be detected before launch through symbolic execution, fuzzing, or control-flow analysis.Source: §4.7 · p. 9
  • Multi-component software-bus coordination complicates single-component analysis, yet its bus activity and unexpected timing or interface use can still expose it to operators.Source: §4.7 · p. 9
  • Only Scenario 5 achieves complete stealth; its multi-component design uses a channel invisible to satellite operators.The authors identify continuous logging and resource constraints as limitations leveraged by the FIFO approach.Source: §4.7 · p. 9

5 Results

In NOS3, SpyChain’s agents coordinated, exfiltrated telemetry, injected deceptive messages, and disrupted or persistently occupied flight software. The authors also report that SPARTA incorporated component collusion as a defense-evasion technique.

5 Results

  • The authors report successful stealthy and persistent malware embedding without detection in their small-satellite simulation.Source: §5 · p. 9

5.1 Component Coordination

  • Colluding agents coordinated through either cFS software-bus messages or a FIFO, with Scenario 5’s file-based channel invisible to COSMOS operators.Bus messages could appear legitimate under misleading names and descriptions; COSMOS cannot access the onboard filesystem.Source: §5.1 · p. 9

5.2 Data Exfiltration

  • Across all five scenarios, the attack agent exfiltrated mission telemetry to an unauthorized ground station without alerting operators to radio use or leaving incriminating logs.COSMOS recorded downlink packet details but did not attribute packets to the generating cFS component, and the satellite did not internally log radio transmissions.Source: §5.2 · p. 10

5.3 Deception

  • SpyChain could publish arbitrary bus messages and commands, enabling fake diagnostics, spurious telemetry, or message floods that could mask anomalies and confuse operators.Injected messages blended with legitimate telemetry from the COSMOS ground-station view.Source: §5.3 · p. 10

5.4 Persistence and Denial of Service

  • The malware could cause denial of service through null-pointer crashes, or persistently exfiltrate telemetry while appearing legitimate and adapting activation to orbital conditions.Crashes could be repeated, resembling software failures and complicating recovery.Source: §5.4 · p. 10

5.5 Identifying Novel Strategies

  • The authors report that SPARTA added Component Collusion under Defense Evasion as technique DE-0012 after they notified its maintainers.They describe colluding components as distributing malicious logic to avoid centralized signatures and increase persistence and stealth.Source: §5.5 · p. 11

6 Countermeasures

The countermeasures pair lightweight runtime defenses for NOS3 and cFS with broader recommendations for least privilege, supply-chain traceability, and operator preparedness. The authors emphasize that existing satellite detection options do not cover the stealth techniques demonstrated.

6 Countermeasures

  • No operational satellite IDS/IPS is publicly deployed, and the proposed NOS3-based probe IDS would miss SpyChain’s stealth techniques.The authors call for lightweight, embedded defenses tailored to satellites.Source: §6 · p. 11

6.1.1 Improve Runtime Behavior Monitoring

  • Runtime monitors can audit system calls, file and network access, and bus activity; a NOS3 prototype throttles excessive message transmission and logs a warning.The recommendation also identifies abnormal traffic spikes or radio transmissions as possible compromise indicators.Source: §6.1.1 · p. 11

6.1.2 Software Bus Authentication and Access Control

  • Because unauthenticated bus access lets components read system-wide telemetry and publish messages, the authors recommend access controls and message authentication.A cFS prototype locally checks subscription requests against an authorized message-ID allowlist, denying and logging unauthorized requests.Source: §6.1.2 · p. 12

6.1.3 Restrict Unmonitored System Calls

  • Scenario 5’s FIFO signaling depends on system calls such as mkfifo(), so per-component syscall allowlists could block covert coordination and unauthorized exfiltration.Full seccomp integration proved challenging in NOS3; the authors explored a conceptual filter that denies unapproved calls by default.Source: §6.1.3 · p. 12

6.2.1 Zero Trust Flight Software Design

  • Because implicit trust grants components broad access to telemetry, files, and network functions, the authors recommend zero-trust design and least-privilege access by default.Manifest-driven permissions and monitoring message rates, command frequency, or socket use are proposed as layered safeguards.Source: §6.2 · p. 12, §6.2.1 · p. 12

6.2.2 Supply Chain Verification and Transparency

  • Opaque, effectively immutable COTS components motivate requiring verifiable provenance, reproducible builds, binary analysis, and a software bill of materials.The proposed traceability measures are intended to support forensic analysis after launch.Source: §6.2.2 · pp. 12–13

6.2.3 Operational Baselines and Training

  • Without operator baselines, subtle exfiltration or diagnostic activity may go unnoticed; playbooks, training, and tabletop exercises are recommended to prepare crews to flag deviations.Suggested baselines include telemetry patterns, message rates, and normal process behavior.Source: §6.2.3 · p. 13
  • The authors argue that treating security as a design requirement can raise compromise costs and reduce the likelihood of covert malware persisting undetected in orbit.They frame operational awareness as an ongoing in-flight practice, not solely a design concern.Source: §6.2.3 · p. 13

7 Discussion

The discussion reports that SpyChain’s five simulated scenarios demonstrate stealthy attacks by standalone or colluding components, while distinguishing that feasibility finding from operational validation. It also draws implications for satellite stakeholders and calls for broader community investment in testing and defenses.

7 Discussion

  • Across five scenarios, standalone or colluding malicious components coordinated, exfiltrated telemetry, and abused implicit trust to evade detection and threaten mission success.The authors state that trusted third-party components can sustain stealthy, persistent malware that bypasses pre-launch validation and in-orbit monitoring.Source: §7 · p. 13
  • Unlike studies of isolated exploits or core-software insiders, this work demonstrates a multi-component supply-chain attack in NASA’s NOS3 environment.The authors identify vendor assurance, flight-software monitoring and access controls, and skepticism toward well-formed telemetry as stakeholder concerns.Source: §7 · p. 13
  • NOS3 cannot capture orbital operational dynamics or physical constraints, including radiation-induced faults, thermal stress, and variable link quality.Real-world orbital passes and fluctuating links could complicate or delay telemetry exfiltration, which remains to be assessed under operational conditions.Source: §7 · p. 13
  • The authors call for shared testing frameworks, benchmarks, adaptable detection tools, and cross-sector collaboration to strengthen satellite security practices.They propose community resources such as attack-pattern repositories and secure software templates.Source: §7 · p. 13

8 Conclusion

The conclusion presents SpyChain as an end-to-end NOS3 demonstration of coordinated malware using legitimate interfaces to compromise small-satellite operations. It argues for escalating-stealth analysis and lifecycle hardening as parts of improving resilience.

8 Conclusion

  • SpyChain provides the first end-to-end NOS3 demonstration of coordinated multi-component malware that can exfiltrate telemetry, persist across reboots, and disrupt operations through legitimate interfaces.The conclusion frames third-party components as a source of covert software-compromise risk in increasingly complex, autonomous small satellites.Source: §8 · p. 13
  • The study introduces escalating stealth and complexity, validates sensor-aware and colluding malware behaviors, and distills them into hardening strategies.The authors characterize these findings as evidence of supply-chain compromise feasibility in space systems.Source: §8 · p. 13
  • The authors call for zero-trust principles, authenticated telemetry, anomaly detection, and post-launch validation across the satellite lifecycle, alongside expanded NOS3 cybersecurity testbeds.They present these measures as essential to securing future small-satellite missions.Source: §8 · pp. 13–14

Ethical Considerations

The ethical discussion identifies affected stakeholders and frames the work as simulation-based research intended to support defense. It acknowledges possible misuse and vendor-reputation risks, alongside steps taken to limit harm.

Ethical Considerations

  • The study identifies developers, operators, component vendors, NASA/NOS3 maintainers, security researchers, adversaries, and society as affected stakeholders.It notes potential attack adaptation and vendor-reputation risks among possible harms.Source: Ethical Considerations · p. 14
  • All experiments were confined to NOS3, with no human subjects, live satellites, vendor-specific systems, or production infrastructure involved.The authors state that no mission data were used and operational satellites were not disrupted.Source: Ethical Considerations · p. 14
  • To reduce publication-related risk, the authors avoided naming vendors and omitted step-by-step exploit code while sharing mitigation strategies with the NASA NOS3 team.They judged the defensive benefits of publication to outweigh potential harms given the simulated setting.Source: Ethical Considerations · p. 14
Loading 2510.06535v2…