Detection of unexpected or unauthorized modifications to onboard memory values during the execution. This could be done during updates, configuration changes, or direct commanding. This attack could potentially leading to corruption of system values or triggering malicious behavior. An adversary may inject malicious information in the Flash or EEPROM or area where the FSW/Software is stored during an update.
| ID | Name | Description | |
| IA-0007.01 | Compromise On-Orbit Update | Adversaries may target the pipeline that produces and transmits updates to an on-orbit vehicle. Manipulation points include source repositories and configuration tables, build and packaging steps that generate images or differential patches, staging areas on ground servers, update metadata (versions, counters, manifests), and the transmission process itself. Spacecraft updates span flight software patches, FPGA bitstreams, bootloader or device firmware loads, and operational data products such as command tables, ephemerides, and calibration files, each with distinct formats, framing, and acceptance rules. An attacker positioned in the ground system can substitute or modify an artifact, alter its timing and timetags to match pass windows, and queue it through the same procedures operators use for nominal maintenance. Activation can be immediate or deferred: implants may lie dormant until a specific mode, safing entry, or table index is referenced. | |
| EX-0004 | Compromise Boot Memory | The attacker manipulates memory and configuration used in the earliest stages of boot so that their code runs before normal protections and integrity checks take hold. Targets include boot ROM vectors, first-stage/second-stage bootloaders, boot configuration words and strap pins, one-time-programmable (OTP) fuses, non-volatile images in flash/EEPROM, and scratch regions copied into RAM during cold start. Techniques range from replacing or patching boot images to flipping configuration bits that alter trust decisions (e.g., image selection, fallback order, watchdog behavior). Faults can be induced deliberately (timed power/clock/EM glitches) or via crafted update/write sequences that leave a partially programmed but executable state. Once resident, the modification can insert early hooks, disable or short-circuit checks, or select downgraded images; destructive variants corrupt the boot path to induce a persistent reset loop or safeing entry (a denial of service). Because boot logic initializes buses, memory maps, and handler tables, even small changes at this stage cascade, shaping how command handlers load, how keys and counters are initialized, and which peripherals are trusted for subsequent execution. | |
| EX-0007 | Trigger Single Event Upset | The attacker induces or opportunistically exploits a single-event upset (SEU), a transient bit flip or latch disturbance in logic or memory, so that software executes in a state advantageous to the attack. SEUs arise when charge is deposited at sensitive nodes by energetic particles or intense electromagnetic stimuli. An actor may time operations to coincide with natural radiation peaks or use artificial means from close range. Outcomes include corrupted stacks or tables, altered branch conditions, flipped configuration bits in FPGAs or controllers, and transient faults that push autonomy/FDIR into recovery modes with broader command acceptance. SEU exploitation is probabilistic; the technique couples repeated stimulation with careful observation of mode transitions, watchdogs, and error counters to land the system in a desired but nominal-looking state from which other actions can proceed. | |
| EX-0011 | Exploit Reduced Protections During Safe-Mode | The adversary times on-board actions to the period when the vehicle is in safe-mode and operating with altered guardrails. In many designs, safe-mode enables contingency command dictionaries, activates alternate receivers or antennas, reduces data rates, and prioritizes survival behaviors (sun-pointing, thermal/power conservation). Authentication checks, anti-replay windows, rate/size limits, and interlocks may differ from nominal; counters can be reset, timetag screening relaxed, or maintenance procedures made available for recovery. Ground cadence also changes, longer passes, emergency scheduling, atypical station selection, creating predictable windows for interaction. Using knowledge of these patterns, an attacker issues maintenance-looking loads, recovery scripts, parameter edits, or boot/patch sequences that the spacecraft is primed to accept while safed. Because responses (telemetry beacons, acknowledgments, mode bits) resemble normal anomaly recovery, the first execution event blends with expected behavior, allowing unauthorized reconfiguration, software modification, or state manipulation to occur under the cover of fault response. | |
| EX-0012.03 | Memory Write/Loads | The adversary uses legitimate direct-memory commands or load services to place chosen bytes at chosen addresses. Many spacecraft support raw read/write operations, block loads into RAM or non-volatile stores, and table/file loaders that copy content into working memory. With knowledge of address maps and data structures, an attacker can patch function pointers or vtables, alter limit and configuration records, seed scripts or procedures into interpreter buffers, adjust DMA descriptors, or overwrite portions of executable images resident in RAM. Loads may be sized and paced to fit link and queue constraints, then activated by a subsequent command, mode change, or natural reference by the software. | |
| EX-0014 | Spoofing | The adversary forges inputs that subsystems treat as trustworthy truth, time tags, sensor measurements, bus messages, or navigation signals, so onboard logic acts on fabricated reality. Because many control loops and autonomy rules assume data authenticity once it passes basic sanity checks, carefully shaped spoofs can trigger mode transitions, safing, actuator commands, or payload behaviors without touching flight code. Spoofing may occur over RF (e.g., GNSS, crosslinks, TT&C beacons), over internal networks/buses (message injection with valid identifiers), or at sensor/actuator interfaces (electrical/optical stimulation that produces plausible readings). Effects range from subtle bias (drifting estimates, skewed calibrations) to acute events (unexpected slews, power reconfiguration, recorder re-indexing), and can also pollute downlinked telemetry or science products so ground controllers interpret a false narrative. The hallmark is that the spacecraft chooses the adversary’s action path because the forged data passes through normal processing chains. | |
| EX-0014.01 | Time Spoof | Time underpins sequencing, anti-replay, navigation filtering, and data labeling. An attacker that forges or biases the time seen by onboard consumers can reorder stored command execution, break timetag validation, desynchronize counters, and misalign estimation windows. Spoofing vectors include manipulating the distributed time service, introducing a higher-priority/cleaner time source (e.g., GNSS-derived time), or crafting messages that cause clock discipline to slew toward attacker-chosen values. Once time shifts, autonomous routines keyed to epochs, wheel unloads, downlink starts, heater schedules, fire early/late or not at all, and telemetry appears inconsistent to ground analysis. The signature is correct-looking time metadata that steadily or abruptly departs from truth, driving downstream logic to act at the wrong moment. | |
| EX-0014.03 | Sensor Data | The attacker presents fabricated or biased measurements that estimation and control treat as ground truth. Targets include attitude/position sensors (star trackers, gyros/IMUs, sun sensors, magnetometers, GNSS), environmental and health sensors (temperatures, currents, voltages, pressures), and payload measurements used in autonomy. Spoofs may be injected electrically at interfaces, optically (blinding/dazzling trackers or sun sensors), magnetically, or by crafting packets fed into sensor gateways. Even small, consistent biases can drive filters to incorrect states; stepwise changes can trigger fault responses or mode switches. Downstream, timestamps, quality flags, and derived products inherit the deception, creating uncertainty for operators and potentially inducing temporary loss of service as autonomy reacts to a world that never existed. | |
| 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. | |