---
title: 'SpyChain: Supply Chain Attacks on Small Satellites'
url: https://www.emergentmind.com/topics/spychain
type: topic
---

# SpyChain: Supply Chain Attacks on Small Satellites

Searching arXiv for the specified paper and closely related space-systems security work.
arXiv search query: 2510.06535 SpyChain small satellite supply chain attacks NOS3 SPARTA
SpyChain is a research framework and proof-of-concept malware design for multi-vector, hardware supply chain attacks on small satellites. It demonstrates how auxiliary commercial off-the-shelf (COTS) components, delivered by third-party vendors, can be pre-infected, pass pre-launch testing, coordinate once in orbit, exfiltrate telemetry, deceive operators, and disrupt or deny service while using only legitimate, authorized interfaces such as cFS APIs, system calls, the software bus, and radio pathways. The design is implemented end-to-end in NASA’s Operational Simulator for Small Satellites (NOS3), and the work is presented as the first end-to-end design and implementation of independent and colluding hardware supply chain threats targeting small satellites [2510.06535].

## 1. Definition and scope

SpyChain targets the auxiliary component layer rather than the core flight software layer. In the formulation presented, the compromised elements are vendor-supplied COTS modules such as sensors, radios, GNSS units, payloads, or diagnostic modules that are integrated into a cFS-based flight stack as binary applications, drivers, or hardware-associated software. These components are treated as especially consequential because they often arrive as black-box hardware plus binary firmware plus driver or application, yet still receive access to telemetry streams, system calls, the software bus, file-system resources, and radio interfaces [2510.06535].

The framework is organized around multi-vector behavior. “Multi-vector” denotes multiple goals, including exfiltration, deception, disruption, and persistence; multiple malicious components, including a trigger agent and an attack agent; and multiple coordination channels, specifically the cFS software bus and a covert FIFO file. The work therefore does not frame supply chain compromise as a single malicious binary executing a single payload. Instead, it treats the attack surface as a modular, implicitly trusted onboard ecosystem in which benign-looking components can remain dormant, activate under mission-relevant conditions, and later escalate.

A central claim of the work is that small satellites are particularly exposed because of heavy reliance on COTS, asymmetric assurance between core flight software and auxiliary modules, limited observability once in orbit, and a plug-and-play architecture in which cFS applications share a common software bus with no authentication or access control. This suggests that the decisive security boundary is not limited to the flight software baseline itself, but extends to all integrated modules that can participate in on-board computation and communication.

## 2. Threat model and architectural assumptions

The adversary is a supply chain insider positioned at or near a third-party COTS vendor or its subcontractors. The model assumes pre-launch access to hardware or firmware for auxiliary components and knowledge of NASA cFS, the underlying OS, telemetry formatting and routing, and software-bus operation. It also assumes the adversary can compile and package malicious cFS applications or drivers that resemble normal vendor components, and can build and test these implants locally using public cFS and NOS3 code. In addition, the adversary is assumed to control or operate a malicious ground station on the satellite’s orbital path, capable of receiving downlinked packets using standard SDRs [2510.06535].

The architectural assumptions are tied to a typical NOS3 plus cFS deployment. cFS applications have a modular lifecycle with `AppInit()` and a main loop structured as `while(CFE_ES_RunLoop())`. Inter-application communication occurs through a publish-subscribe software bus that has no authentication and no ACLs. Applications can subscribe to arbitrary message IDs and publish arbitrary messages or commands so long as the relevant message ID is used. Message IDs identify telemetry types, including examples such as `NOVATEL_OEM615_DEVICE_TLM_MID` for GNSS telemetry.

The system model further assumes standard OS interfaces are available to applications, including `mkfifo()`, `open()`, `read()`, `write()`, and `sendto()`, and that file-system and IPC mechanisms are present without syscall auditing. A further assumption is that the radio flight application maintains a UDP socket that can be reused: any application acquiring the descriptor can send raw buffers that are then forwarded as radio downlink. Ground monitoring through COSMOS is correspondingly partial. COSMOS can observe CCSDS packet bytes and fields, XTCE decoding status, and events logged via the cFS Event Service, but it cannot determine which application invoked which system calls, which application used the radio socket, or what file-system coordination occurred onboard [2510.06535].

These assumptions are shaped by small-satellite constraints. CPU, memory, mass, and power budgets preclude heavyweight IDS, detailed logging, or sandboxing. Downlink limits constrain continuous transmission of raw logs or traces. Long mission lifetimes and the impossibility of physical servicing make compromised components effectively persistent. Operational blind zones without continuous contact make anomaly triage difficult. The paper presents these features not as incidental deployment details, but as the conditions that make stealth plausible.

## 3. Attack architecture and execution model

SpyChain is implemented as a family of attack architectures built from standard-looking cFS applications. The malware can be “solo,” with one malicious application, or “colluding,” with two malicious applications separated into a trigger agent and an attack agent. Activation can be driven by static triggers such as a countdown timer or dynamic triggers derived from live telemetry, especially GNSS activity interpreted as indicating orbital insertion. Coordination is performed either over the software bus or through a named FIFO file on the onboard file system [2510.06535].

The embedding strategy is operationally simple. A vendor ships a binary cFS application plus the associated hardware model or driver. In NOS3 this corresponds to files such as `component_app.c` and related code. SpyChain places malicious logic inside that application while preserving expected behavior: the application still registers telemetry packets, subscribes to expected streams, and handles hardware tasks, but additionally establishes covert coordination, listens for activation conditions, exfiltrates telemetry through the radio UDP socket, and optionally injects deceptive or disruptive behavior.

Resource access follows directly from this embedding. Telemetry access comes from legitimate subscriptions to housekeeping, GNSS, software-bus statistics, and time service streams. System-call and file-system access is used to create a named FIFO with `mkfifo()` and to exchange signals through non-blocking `read()` and `write()`. Radio access is obtained by reusing the generic radio UDP socket created by the `GENERIC_RADIO` flight application, followed by `sendto()` to inject arbitrary UDP payloads into the radio pipeline.

The work’s attack timeline is equally structured. Malware is embedded during the supply chain stage, remains dormant after launch while a trigger condition is awaited, signals activation to the attack agent, exfiltrates mission data to a malicious ground station, and can later switch to other actions such as denial of service. No formal mathematical model is introduced; the emphasis is system design and implementation rather than analytical characterization.

## 4. Five-scenario stealth taxonomy

SpyChain is instantiated as five scenarios that increase in sophistication and stealth. Scenario 1 uses a single malicious cFS application with a static time-based trigger. The component initializes normally, starts a countdown timer, and only after timer expiry begins exfiltrating telemetry via the radio UDP socket. Its value lies in evading short pre-launch tests, but because all malicious logic is centralized in one component, static or dynamic analysis of that component may reveal suspicious behavior [2510.06535].

Scenario 2 remains single-component but replaces the countdown with a dynamic GNSS trigger. The malicious application subscribes to `NOVATEL_OEM615_DEVICE_TLM_MID` and begins exfiltration only when GNSS activity indicates the satellite is in orbit. This is presented as more stealthy than Scenario 1 because ground tests lacking realistic GNSS conditions do not trigger the payload, although the malicious logic is still concentrated in one binary.

Scenario 3 introduces collusion between two components using a static trigger and software-bus coordination. A trigger agent waits for the countdown to expire and then publishes a coordination message on the software bus; an attack agent subscribes to that message and begins exfiltration. Scenario 4 combines the same two-component split with dynamic GNSS-based triggering: the trigger agent observes GNSS telemetry, publishes an activation message on the software bus when orbital conditions are detected, and the attack agent initiates exfiltration on receipt.

Scenario 5 is presented as the flagship design and the only scenario considered fully stealthy. It combines two components, a dynamic sensor trigger, and FIFO-based coordination. The trigger agent subscribes to GNSS telemetry and, upon inferring orbital insertion, writes command strings such as `"toggle_exfil"` to a named FIFO created earlier by the attack agent. Later it can write `"kill"` to switch from exfiltration to a crash-based denial-of-service action. The attack agent creates the FIFO with `mkfifo()`, subscribes to multiple telemetry streams, polls the FIFO with non-blocking `read()`, starts exfiltration on `"toggle_exfil"`, and dereferences a NULL pointer on `"kill"` to induce a segmentation fault and crash the flight software. Throughout, it continues nominal behavior to maintain cover [2510.06535].

The stealth taxonomy described in the paper has several dimensions. One is the distribution of malicious logic: single-component designs are easier to reason about, whereas multi-component collusion distributes behavior and reduces suspiciousness per module. A second is trigger type: static triggers can evade short tests but may activate during long ground runs, whereas sensor-driven triggers activate only under mission conditions. A third is coordination-channel observability: software-bus coordination is visible and potentially detectable through bus anomaly monitoring, whereas FIFO coordination is invisible to ground monitoring absent OS-level syscall or file auditing. A fourth is blending with legitimate behavior: all scenarios use legitimate APIs, but Scenario 5 adds a transient FIFO, normal-looking application activity, and exfiltration that resembles ordinary radio usage. A fifth is the relation between persistence and impact: exfiltration can persist long-term, while optional DoS or mis-telemetry can be deferred until late mission phases and appear as ordinary software faults. Table 1 in the paper qualitatively classifies only Scenario 5 as truly stealthy.

## 5. Covert channels, exfiltration path, and SPARTA mapping

Two coordination channels are used. In Scenarios 3 and 4, the software bus functions as a legitimate coordination mechanism: one application publishes a message and another subscribes to it. This is operationally simple and requires no nonstandard interfaces, but it is observable in bus logs and in COSMOS, even if the messages are labeled to resemble benign diagnostics. In Scenario 5, coordination is moved to a named FIFO: the attack agent creates the FIFO with `mkfifo()`, the trigger agent writes command strings such as `"toggle_exfil"` and `"kill"`, and the attack agent processes them using non-blocking `read()`. The paper emphasizes two advantages of this mechanism: FIFO semantics provide synchronization and automatic clearing once data is read, and ground systems do not observe onboard file-system operations or syscalls [2510.06535].

The exfiltration path piggybacks on the existing radio stack. The attack agent reuses the UDP socket maintained by the `GENERIC_RADIO` cFS application, invokes `sendto()` with arbitrary telemetry buffers, and relies on the radio hardware model to forward those buffers to the ground interface. No new connection setup or radio reconfiguration is required, and the radio model performs minimal validation. In the real-satellite analogue described by the paper, a compromised onboard application would inject frames into the downlink stream, while an adversary ground station would receive them when in line-of-sight and configured with the correct frequency, modulation, and framing parameters.

Ground monitoring is bypassed not by disabling telemetry, but by exploiting attribution gaps. COSMOS logs telemetry that reaches the configured endpoint and assumes the traffic is legitimate; it cannot attribute packets to a specific onboard application. NOS3 and typical cFS deployments do not log which application wrote to the radio socket or when the radio was actively transmitting. The consequence is that exfiltration to a malicious ground station may be entirely absent from the official ground segment’s view. The paper’s evaluation model simplifies this by treating the default ground station endpoint as the attacker’s receiver.

The work also formalizes the attack in relation to the SPARTA matrix. The mapped techniques include reconnaissance entries such as `REC-0001.01` and `REC-0001.04`, initial access entries such as `IA-0001.02`, `IA-0009.0`, and `IA-0010`, execution entries including `EX-0002`, `EX-0008`, `EX-0009.01`, `EX-0010`, and `EX-0013`, persistence entry `PER-0002.01`, exfiltration entry `EXF-0003.02`, and impact entries `IMP-0001`, `IMP-0002`, `IMP-0003`, and `IMP-0006`. The paper further identifies a missing defense-evasion technique for component collusion, provisionally described as “Component Collusion for Evasion,” and reports that this category is being added or slated for inclusion in SPARTA. A plausible implication is that space-system threat modeling had under-specified collusion across onboard components even though such collusion materially changes detectability.

## 6. Implementation in NOS3, defenses, and broader significance

NOS3 is used as the experimental substrate because it provides cFS flight software on a simulated CPU and OS, simulated hardware models such as GNSS receivers and radios, realistic telemetry and command paths, and integration with COSMOS. The work argues that these features make attack evaluation meaningful while avoiding the need to experiment on real spacecraft. For the primary Scenario 5 implementation, both trigger and attack agents were cloned from a standard example NOS3 component to preserve realistic source structure, message IDs, hardware simulation stubs, and cFS lifecycle. The trigger agent was modified to subscribe to GNSS telemetry, detect orbit indicators, and write FIFO commands. The attack agent was modified to create the FIFO, subscribe to multiple telemetry streams, poll the FIFO, exfiltrate upon `"toggle_exfil"`, and crash upon `"kill"` by NULL-pointer dereference [2510.06535].

The reported results are qualitative. Across all five scenarios, trigger and attack agents coordinated reliably, telemetry exfiltration succeeded without raising alarms in the simulated ground station, and optional DoS and deception actions were successful. In Scenarios 3 and 4, coordination messages appeared on the software bus but could be disguised as diagnostics. In Scenario 5, FIFO coordination was invisible, and only normal-looking radio traffic was observable. A triggered NULL-pointer crash produced a cFS restart that appeared as a normal reset banner and was described as indistinguishable from an ordinary software fault. The paper does not provide success-rate, bandwidth, or detection-rate metrics; the contribution is feasibility and qualitative stealth rather than quantitative measurement.

The proposed defenses are explicitly lightweight and onboard-compatible. Runtime behavior monitoring is recommended primarily against single-component attacks: a monitoring or auditing mechanism can track message rates, system calls, or file and network activity per application and flag anomalies such as bursts of messages or unusual radio use. The paper describes a prototype message-rate limiter that counts messages in sliding windows and, above a threshold such as 100, enters a throttled state and logs a warning event. Software-bus authentication and access control are recommended against bus-based coordination and arbitrary bus misuse: components should be constrained by per-component allowlists of message IDs they may subscribe to or publish, enforced at runtime and potentially tied to manifest-based, cryptographically signed configuration. Syscall restriction and monitoring, including Linux `seccomp` or RTOS equivalents, are recommended primarily against FIFO-based covert channels: per-component syscall allowlists can forbid unnecessary operations such as `mkfifo()`, `socket()`, `connect()`, or `sendto()` for components that do not require them [2510.06535].

The paper also advocates zero-trust flight software design, supply chain verification and transparency, maintenance of a software bill of materials, post-delivery analysis of vendor binaries, operational baselining of telemetry patterns and reset frequencies, and operator training for suspicious coordination messages or deceptive anomalies. It simultaneously notes that these defenses have limits: onboard monitoring must remain lightweight, sophisticated attackers may mimic normal behavior, and retrofitting access control or syscall filtering onto existing missions is difficult.

Within the broader literature on space-system security, the work positions SpyChain against an assumption that the most realistic insider route is compromise of core flight software. It argues instead that auxiliary COTS compromise is more plausible because third-party vendors and opaque firmware are less controlled than public cFS baselines subject to review and oversight. A common misconception addressed by the work is therefore that well-formed telemetry and documented cFS application behavior can be treated as trustworthy by default. SpyChain’s main significance lies in demonstrating that confidentiality, integrity, and availability can all be compromised through auxiliary components that remain effectively invisible to existing monitoring and testing practices, while also providing a concrete design pattern for future evaluation of IDS and hardening mechanisms in NOS3-like environments [2510.06535].

Source: https://www.emergentmind.com/topics/spychain