Detection of failed integrity checks during spacecraft software execution, potentially indicating that the software has been modified to include a backdoor or malicious code
| ID | Name | Description | |
| REC-0001.02 | Firmware | Firmware intelligence covers microcontroller images, programmable logic bitstreams, boot ROM behavior, peripheral configuration blobs, and anti-rollback or secure-boot settings for devices on the bus. Knowing device types, versions, and footprints enables inference of default passwords, debug interfaces (JTAG, SWD, UART), timing tolerances, and error handling under brownout or thermal stress. A threat actor may obtain firmware from vendor reference packages, public evaluation boards, leaked manufacturing files, over-the-air update images, or crash dumps. Correlating that with board layouts, harness drawings, or part markings helps map trust boundaries and locate choke points like power controllers, bus bridges, and watchdog supervisors. Attack goals include: preparing malicious but apparently valid updates, exploiting unsigned or weakly verified images, forcing downgrades, or manipulating configuration fuses to weaken later defenses. Even when cryptographic verification is present, knowledge of recovery modes, boot-pin strapping, or maintenance commands can offer alternate paths. | |
| IA-0001.02 | Software Supply Chain | Here the manipulation targets software delivered to flight or ground systems: altering source before build, swapping signed binaries at distribution edges, subverting update metadata, or using stolen signing keys to issue malicious patches. Space-specific vectors include mission control applications, schedulers, gateway services, flight tables and configuration packages, and firmware loads during I&T or LEOP. Adversaries craft payloads that pass superficial validation, trigger under particular operating modes, or reintroduce known weaknesses through version rollback. “Data payloads” such as malformed tables, ephemerides, or calibration products can double as exploits when parsers are permissive. The objective is to ride the normal promotion pipeline so the implant arrives pre-trusted and executes as part of routine operations. | |
| IA-0002 | Compromise Software Defined Radio | Adversaries target SDR-based transceivers and payload radios because reconfigurable waveforms, FPGA bitstreams, and software flowgraphs create programmable footholds. Manipulation can occur in the radio’s development pipeline (toolchains, out-of-tree modules), at integration (loading of bitstreams, DSP coefficients, calibration tables), or in service via update channels that deliver new waveforms or patches. On-orbit SDRs often expose control planes (command sets for mode/load/select), data planes (baseband I/Q), and management/telemetry paths, any of which can embed covert behavior, alternate demod paths, or hidden subcarriers. A compromised SDR can establish clandestine command-and-control by activating non-public waveforms, piggybacking on idle fields, or toggling to time/ephemeris-triggered profiles that blend with nominal operations. On the ground, compromised SDR modems can be used to fabricate mission-compatible emissions or to decode protected downlinks for reconnaissance. Attackers leverage the SDR’s malleability so that malicious signaling, once seeded, presents as a legitimate but rarely exercised configuration. | |
| EX-0005 | Exploit Hardware/Firmware Corruption | The adversary achieves execution or effect by corrupting or steering behavior beneath the software stack, in device firmware, programmable logic, or the hardware itself. Examples include tampering with firmware images or configuration blobs burned into non-volatile memory; targeting MCU/SoC boot ROM fallbacks; editing FPGA bitstreams or partial-reconfiguration frames; or leveraging physical phenomena and timing to flip bits or skip checks. Because these actions occur below or alongside the operating system and application FSW, traditional endpoint safeguards see normal interfaces while trust anchors are already altered. | |
| EX-0008 | Time Synchronized Execution | Malicious logic is arranged to run at precise times derived from onboard clocks or distributed time sources. The trigger may be absolute or relative. Spacecraft commonly maintain multiple clocks and counters and schedule autonomous sequences against them. An attacker leverages this machinery to ensure effects occur during tactically advantageous windows. Time-based execution reduces exposure, simplifies coordination across assets, and makes reproduction difficult in lab settings that lack the same temporal context. | |
| EX-0008.01 | Absolute Time Sequences | Execution is keyed to a fixed wall-clock timestamp or epoch, independent of current vehicle state. The implant watches a trusted time source, GNSS-derived time, crosslink-distributed network time, oscillator-disciplined UTC/TAI, or mission elapsed time anchored at activation, and triggers exactly at a programmed date/time. Absolute triggering supports coordinated multi-asset actions and allows long dormancy with a precise activation moment. Variants incorporate calendar logic (e.g., “first visible pass after YYYY-MM-DD hh:mm:ss”) or guard bands to fire only if the clock is within certain tolerances, ensuring the event occurs even with minor drift yet remains rare enough to blend with scheduled operations. | |
| EX-0008.02 | Relative Time Sequences | Execution is keyed to elapsed time since a reference event. The implant latches a start point, boot, reset, safing entry/exit, receipt of a particular telemetry/command pattern, achievement of sun-pointing, and arms a countdown or set of offsets (“N seconds after event,” “repeat every M cycles”). Relative sequences are resilient to clock discontinuities and mirror how many spacecraft schedule internal activities (e.g., after boot, run calibrations; after acquisition, start downlink). An attacker exploits this to ensure the trigger fires only within specific operational phases and to survive resets that would thwart absolute timestamps: after every reboot, wait for housekeeping steady state, then act; or, after a wheel unload completes, inject an additional command while control laws are in a known configuration. | |
| EX-0009.02 | Operating System | At the OS layer the attacker targets primitives that schedule work and mediate hardware. Maintenance builds may expose shells or management consoles; misconfigurations around these interfaces can provide paths to command interpreters or privileged syscalls. Exploitation yields kernel-mode execution, arbitrary memory read/write, or control of scheduling and address spaces, letting the actor tamper with FSW processes, intercept command paths, or manipulate storage and bus drivers beneath application checks. The technique leverages generic OS weaknesses adapted to the spacecraft’s particular build, turning low-level control into mission-facing effects that appear to originate from legitimate processes. | |
| EX-0010 | Malicious Code | The adversary achieves on-board effects by introducing executable logic that runs on the vehicle, either native binaries and scripts, injected shellcode, or “data payloads” that an interpreter treats as code (e.g., procedure languages, table-driven automations). Delivery commonly piggybacks on legitimate pathways: software/firmware updates, file transfer services, table loaders, maintenance consoles, or command sequences that write to executable regions. Once staged, activation can be explicit (a specific command, mode change, or file open), environmental (time/geometry triggers), or accidental, where operator actions or routine autonomy invoke the implanted logic. Malicious code can target any layer it can reach: altering flight software behavior, manipulating payload controllers, patching boot or device firmware, or installing hooks in drivers and gateways that bridge bus and payload traffic. Effects range from subtle logic changes (quiet data tampering, command filtering) to overt actions (forced mode transitions, resource starvation), and may include secondary capabilities like covert communications, key material harvesting, or persistence across resets by rewriting images or configuration entries. | |
| PER-0001 | Memory Compromise | The adversary arranges for malicious content to survive resets and mode changes by targeting memories and execution paths that initialize the system. Candidates include boot ROM handoff vectors, first/second-stage loaders, non-volatile images (flash/EEPROM), “golden” fallback partitions, configuration words/fuses, and RAM regions reconstructed at start-up from stored files or tables. Persistence may also ride auto-run mechanisms, init scripts, procedure engines, stored command sequences, or event hooks that execute on boot, safe-mode entry/exit, time triggers, or receipt of specific telemetry/commands. Variants keep the core payload only in RAM but ensure it is reloaded after every restart by patching copy-on-boot routines, altering file catalogs, or modifying table loaders so the same bytes are restored. The common thread is control of where the spacecraft looks for what to run next, so unauthorized logic is reinstated whenever the system resets or transitions modes. | |
| PER-0002 | Backdoor | A backdoor is a covert access path that bypasses normal authentication, authorization, or operational checks so the attacker can reenter the system on demand. Backdoors may be preexisting (undocumented service modes, maintenance accounts, debug features) or introduced by the adversary during development, integration, or on-orbit updates. Triggers range from “magic” opcodes and timetags to specific geometry/time conditions, counters, or data patterns embedded in routine traffic. The access they provide varies from expanded command sets and relaxed rate/size limits to alternate communications profiles and hidden file/parameter interfaces. Well-crafted backdoors blend with nominal behavior, appearing as ordinary operations while quietly accepting instructions that other paths would reject, thereby sustaining the attacker’s foothold across passes, resets, and operator handovers. | |
| PER-0002.02 | Software Backdoor | Software backdoors are code paths intentionally crafted or later inserted to provide privileged functionality on cue. In flight contexts, they appear as hidden command handlers, alternate authentication checks, special user/role constructs, or procedure/script hooks that accept nonpublic inputs. They can be embedded in flight applications, separation kernels or drivers, gateway processors that translate bus/payload traffic, or update/loader utilities that handle tables and images. SDR configurations offer another avenue: non-public waveforms, subcarriers, or framing profiles that, when selected, expose a private command channel. Activation is often conditional, specific timetags, geometry, message sequences, or file names, to keep the feature dormant during routine testing and operations. Once present, the backdoor provides a repeatable way to execute commands or modify state without traversing the standard control surfaces, sustaining the adversary’s access over time. | |
| EXF-0006.01 | Software Defined Radio | Programmable SDRs let an attacker introduce new waveforms or piggyback payloads into existing ones. By modifying DSP chains (filters, mixers, FEC, framing), the actor can: add a low-rate subcarrier under the main modulation, alter preamble/pilot sequences to encode bits, vary puncturing/interleaver patterns as a covert channel, or schedule brief “maintenance” bursts that actually carry exfiltrated data. Changes may be packaged as legitimate updates or configuration profiles so the SDR transmits toward attacker-visible geometry using standard equipment, while mission tooling interprets the emission as routine. | |