| IA-0001 |
Compromise Supply Chain |
Adversaries achieve first execution before the spacecraft ever flies by inserting malicious code, data, or configuration during manufacturing, integration, or delivery. Targets include software sources and dependencies, build systems and compilers, firmware/bitstreams for MCUs and FPGAs, configuration tables, test vectors, and off-the-shelf avionics. Inserted artifacts are designed to appear legitimate, propagate through normal processes, and activate under routine procedures or specific modes (e.g., safing, maintenance). Common insertion points align with where trust is assumed, vendor updates, mirrors and registries, CI/CD runners, programming stations, and “golden image” repositories. The result is pre-positioned access that blends with baseline behavior, often with delayed or conditional triggers and strong deniability. |
|
IA-0001.01 |
Software Dependencies & Development Tools |
This technique targets what developers import and the tools that transform source into flight binaries. Methods include dependency confusion and typosquatting, poisoned container/base images, malicious IDE plugins, and compromised compilers, linkers, or build runners that subtly alter output. Because flight and ground stacks frequently reuse open-source RTOS components, crypto libraries, protocol parsers, and build scripts, an upstream change can deterministically reproduce a backdoor downstream. Attackers also seed private mirrors or caches so “trust-on-first-use” locks in tainted packages, or abuse CI secrets and environment variables to pivot further. Effects range from inserting covert handlers into command parsers, to weakening integrity checks in update paths, to embedding telemetry beacons that exfiltrate build metadata helpful for later stages. |
|
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-0003 |
Crosslink via Compromised Neighbor |
Where spacecraft exchange data over inter-satellite links (RF or optical), a compromise on one vehicle can become a bridgehead to others. Threat actors exploit crosslink trust: shared routing, time distribution, service discovery, or gateway functions that forward commands and data between vehicles and ground. With knowledge of crosslink framing, addressing, and authentication semantics, an adversary can craft traffic that appears to originate from a trusted neighbor, injecting control messages, malformed service advertisements, or payload tasking that propagates across the mesh. In tightly coupled constellations, crosslinks may terminate on gateways that also touch the C&DH or payload buses, providing additional pivot opportunities. Because crosslink traffic is expected and often high volume, attacker activity can be timed to blend with synchronization intervals, ranging exchanges, or scheduled data relays. |
| IA-0005 |
Rendezvous & Proximity Operations |
Adversaries may execute a sequence of orbital maneuvers to co-orbit and approach a target closely enough for local sensing, signaling, or physical interaction. Proximity yields advantages that are difficult to achieve from Earth: high signal-to-noise for interception, narrowly targeted interference or spoofing, observation of attitude/thermal behavior, and, if interfaces exist, opportunities for mechanical mating. The approach typically unfolds through phasing, far-field rendezvous, relative navigation (e.g., vision, lidar, crosslink cues), and closed-loop final approach. At close distances, an attacker can monitor side channels, stimulate acquisition beacons, test crosslinks, or prepare for contact operations such as capture or docking. Contact itself is not the endpoint: mating and grappling expose data and power umbilicals, standardized payload ports, service and checkout connectors, and device programming interfaces that are unreachable by any other means. |
|
IA-0005.02 |
Docked Vehicle / OSAM |
Docking, berthing, or service capture during on-orbit servicing, assembly, and manufacturing (OSAM) creates a high-trust bridge between vehicles. Threat actors exploit this moment, either by pre-positioning code on a servicing vehicle or by manipulating ground updates to it, so that, once docked, lateral movement occurs across the mechanical/electrical interface. Interfaces may expose power and data umbilicals, standardized payload ports, or gateways into the target’s C&DH or payload networks (e.g., SpaceWire, Ethernet, 1553). Service tools that push firmware, load tables, transfer files, or share time/ephemeris become conduits for staged procedures or implants that execute under maintenance authority. Malware can be timed to activation triggers such as “link up,” “maintenance mode entered,” or specific device enumerations that only appear when docked. Because OSAM operations are scheduled and well-documented, the adversary can align preparation with published timelines, ensuring that the first point of execution coincides with the brief window when cross-vehicle trust is intentionally elevated. |
|
IA-0005.03 |
Proximity Grappling |
In this variant, the attacker employs a capture mechanism (robotic arm, grappling fixture, magnetic or mechanical coupler) to establish physical contact without full docking. Once grappled, covers can be manipulated, temporary umbilicals attached, or exposed test points engaged; if design provisions exist (service ports, checkout connectors, external debug pads), these become direct pathways to device programming interfaces (e.g., JTAG/SWD/UART), mass-storage access, or maintenance command sets. Grappling also enables precise attitude control relative to the target, allowing contact-based sensors to read buses inductively or capacitively, or to inject signals onto harness segments reachable from the exterior. Initial access arises when a maintenance or debug path, normally latent in flight, is electrically or logically completed by the grappled connection, allowing authentication-bypassing actions such as boot-mode strapping, image replacement, or scripted command ingress. The operation demands accurate geometry, approach constraints, and fixture knowledge, but yields a transient, high-privilege bridge tailored for short, decisive actions that leave minimal on-orbit RF signature. |
| IA-0006 |
Compromise Hosted Payload |
Adversaries target hosted payloads as an alternate doorway into the host spacecraft. Hosted payloads often expose their own command sets, file services, and telemetry paths, sometimes via the host’s TT&C chain, sometimes through a parallel ground infrastructure under different operational control. Initial access arises when an attacker obtains the ability to issue payload commands, upload files, or alter memory/register state on the hosted unit. Because data and control must traverse an interface to the host bus (power, time, housekeeping, data routing, gateway processors), the payload–host boundary can also carry management functions: mode transitions, table loads, firmware updates, and cross-strapped links that appear only in maintenance or contingency modes. With knowledge of the interface specification and command dictionaries, a threat actor can activate rarely used modes, inject crafted data products, or trigger gateway behaviors that extend influence beyond the payload itself. In multi-tenant or commercial hosting arrangements, differences in keying, procedures, or scheduling between the payload operator and the bus operator provide additional opportunity for a first foothold that looks like routine payload commanding. |
| IA-0007 |
Compromise Ground System |
Compromising the ground segment gives an adversary the most direct path to first execution against a spacecraft. Ground systems encompass operator workstations and mission control mission control software, scheduling/orchestration services, front-end processors and modems, antenna control, key-loading tools and HSMs, data gateways (SLE/CSP), identity providers, and cloud-hosted mission services. Once inside, a threat actor can prepare on-orbit updates, craft and queue valid telecommands, replay captured traffic within acceptance windows, or manipulate authentication material and counters to pass checks. The same foothold enables deep reconnaissance: enumerating mission networks and enclaves, discovering which satellites are operated from a site, mapping logical topology between MOC and stations, identifying in-band “birds” reachable from a given aperture, and learning pass plans, dictionaries, and automation hooks. From there, initial access to the spacecraft is a matter of timing and presentation, injecting commands, procedures, or update packages that align with expected operations so the first execution event appears indistinguishable from normal activity. |
|
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. |
|
IA-0007.02 |
Malicious Commanding via Valid GS |
Adversaries may use a compromised, mission-owned ground system to transmit legitimate-looking commands to the target spacecraft. Because the ground equipment is already configured for the mission, correct waveforms, framing, dictionaries, and scheduling, the attacker’s traffic blends with routine operations. Initial access unfolds by inserting commands or procedures into existing timelines, modifying rate/size limits or command queues, or invoking maintenance dictionaries and rapid-response workflows that accept broader command sets. Pre-positioned scripts can chain actions across multiple passes and stations, while telemetry routing provides immediate feedback to refine follow-on steps. Exfiltration can be embedded in standard downlink channels or forwarded through gateways as ordinary mission data. The distinguishing feature is that command origin appears valid, transmitted from approved apertures using expected parameters, so the first execution event is not a protocol anomaly but a misuse of legitimate command authority obtained through the compromised ground system. |
| IA-0008 |
Rogue External Entity |
Adversaries obtain a foothold by interacting with the spacecraft from platforms outside the authorized ground architecture. A “rogue external entity” is any actor-controlled transmitter, platform, or node, ground, maritime, airborne, or space-based. Most interact by radiating or exchanging traffic using mission-compatible waveforms, framing, or crosslink protocols. Others carry no mission-compatible capability at all, and instead apply interference, directed energy, or physical proximity to shape the conditions under which access becomes possible. The technique exploits the fact that many vehicles must remain commandable and discoverable over wide areas and across multiple modalities. Using public ephemerides, pass predictions, and knowledge of acquisition procedures, the actor times transmissions to line-of-sight windows, handovers, or maintenance periods. Initial access stems from presenting traffic that the spacecraft will parse or prioritize, such as syntactically valid telecommands, crafted ranging/acquisition exchanges, crosslink service advertisements, or payload/user-channel messages that bridge into the command/data path, or, for entities operating by effect rather than by protocol, from the contingency behavior those effects induce. |
|
IA-0008.01 |
Rogue Ground Station |
Adversaries may field their own ground system, transportable or fixed, to transmit and receive mission-compatible signals. A typical setup couples steerable apertures and GPS-disciplined timing with SDR/modems configured for the target’s bands, modulation/coding, framing, and beacon structure. Using pass schedules and Doppler/polarization predictions, the actor crafts over-the-air traffic that appears valid at the RF and protocol layers. |
|
IA-0008.02 |
Rogue Spacecraft |
Adversaries may employ their own satellite or hosted payload to achieve proximity and a privileged RF geometry. After phasing into the appropriate plane or drift orbit, the rogue vehicle operates as a local peer: emitting narrow-beam or crosslink-compatible signals, relaying user-channel traffic that the target will honor, or advertising services that appear to originate from a trusted neighbor. Close range reduces path loss and allows highly selective interactions, e.g., targeted spoofing of acquisition exchanges, presentation of crafted routing/time distribution messages, or injection of payload tasking that rides established inter-satellite protocols. The rogue platform can also perform spectrum and protocol reconnaissance in situ, refining message formats and timing before attempting first execution. |
| IA-0009 |
Trusted Relationship |
Adversaries obtain first execution by riding connections that the mission already trusts, formal interconnections with partners, vendors, and user communities. Once a third party is compromised, the actor inherits that entity’s approved routes into mission enclaves: VPNs and jump hosts into ground networks, API keys into cloud tenants, automated file drops that feed command or update pipelines, and collaboration spaces where procedures and dictionaries circulate. Because traffic, credentials, and artifacts originate from known counterparts, the initial execution event can appear as a routine payload task, scheduled procedure, or software update promoted through established processes. |
|
IA-0009.01 |
Mission Collaborator (academia, international, etc.) |
Missions frequently depend on distributed teams, instrument builders at universities, science operations centers, and international partners, connected by data portals, shared repositories, and federated credentials. A compromise of a collaborator yields access to telescience networks, analysis pipelines, instrument commanding tools, and file exchanges that deliver ephemerides, calibration products, procedures, or configuration tables into mission workflows. Partners may operate their own ground elements or payload gateways under delegated authority, creating additional entry points whose authentication and logging differ from the prime’s. Initial access emerges when attacker-modified artifacts or commands traverse these sanctioned paths: a revised calibration script uploaded through a science portal, a configuration table promoted by a cross-org CI job, or a payload task submitted via a collaboration queue and forwarded by the prime as routine work. Variations in process rigor, identity proofing, and toolchains across institutions amplify the attacker’s options while preserving the appearance of legitimate partner activity. |
|
IA-0009.02 |
Vendor |
Vendors that design, integrate, or support mission systems often hold elevated, persistent routes into operations: remote administration of ground software and modems, access to identity providers and license servers, control of cloud-hosted services, and authority to deliver firmware, bitstreams, or patches. Attackers who compromise a vendor’s enterprise or build environment can assume these roles, issuing commands through approved consoles, queuing updates in provider-operated portals, or invoking maintenance procedures that the mission expects the vendor to perform. Some vendor pathways terminate directly on RF equipment or key-management infrastructure; others ride cross-account cloud roles or managed SaaS backends that handle mission data and scheduling. |
|
IA-0009.03 |
User Segment |
The “user segment” encompasses end users and their equipment that interact with mission services, SATCOM terminals, customer ground gateways, tasking portals, and downstream processing pipelines for delivered data. Where these environments interconnect with mission cores, a compromised user domain becomes a springboard. Attackers can inject malformed tasking requests that propagate into payload scheduling, craft user-plane messages that traverse gateways into control or management planes, or seed data products that flow back to mission processing systems and automation. In broadband constellations and hosted services, user terminals may share infrastructure with TT&C or provider management networks, creating opportunities to pivot from customer equipment into provider-run nodes that the spacecraft trusts. |
| IA-0011 |
Auxiliary Device Compromise |
Adversaries abuse peripherals and removable media that the spacecraft (or its support equipment) ingests during development, I&T, or on-orbit operations. Small satellites and hosted payloads frequently expose standard interfaces, USB, UART, Ethernet, SpaceWire, CAN, or mount removable storage for loading ephemerides, tables, configuration bundles, or firmware. A tainted device can masquerade as a trusted class (mass-storage, CDC/HID) or present crafted files that trigger auto-ingest workflows, file watchers, or maintenance utilities. Malware may be staged by modifying the peripheral’s firmware, seeding the images written by lab formatting tools, or swapping media during handling. Once connected, the device can deliver binaries, scripts, or malformed data products that execute under existing procedures. Because these interactions often occur during hurried timelines (checkouts, rehearsals, contingency maintenance), the initial execution blends with legitimate peripheral use while traversing a path already privileged to reach flight software or controllers. |
| IA-0013 |
Compromise Host Spacecraft |
The inverse of "IA-0006: Compromise Hosted Payload", this technique describes adversaries that are targeting a hosted payload, the host space vehicle (SV) can serve as an initial access vector to compromise the payload through vulnerabilities in the SV's onboard systems, communication interfaces, or software. If the SV's command and control systems are exploited, an attacker could gain unauthorized access to the vehicle's internal network. Once inside, the attacker may laterally move to the hosted payload, particularly if it shares data buses, processors, or communication links with the vehicle. |
| EX-0001 |
Replay |
Replay is the re-transmission of previously captured traffic, over RF links, crosslinks, or internal buses, to elicit the same processing and effects a second time. Adversaries first observe and record authentic exchanges (telecommands, ranging/acquisition frames, housekeeping telemetry acknowledgments, bus messages), then resend them within acceptance conditions that the system recognizes, matching link geometry, timetags, counters, or mode states. The aim can be functional (re-triggering an action such as a mode change), observational (fingerprinting how the vehicle reacts at different states), or disruptive (saturating queues and bandwidth to crowd out legitimate traffic). Because replays preserve valid syntax and often valid context, they can blend with normal operations, especially during periods with reduced monitoring or when counters and windows reset (e.g., handovers, safing entries). On encrypted links, metadata replays (acquisition beacons, schedule requests) may still yield informative responses. |
|
EX-0001.01 |
Command Packets |
Threat actors may resend authentic-looking telecommands that were previously accepted by the spacecraft. Captures may include whole command PDUs with framing, CRC/MAC, counters, and timetags intact, or they may be reconstructed from operator tooling and procedure logs. When timing, counters, and mode preconditions align, the replayed packet can cause the same effect: toggling relays, initiating safing or recovery scripts, adjusting tables, commanding momentum dumps, or scheduling delta-v events. Even when outright execution fails, repeated “near-miss” injections can map acceptance windows, rate/size limits, and interlocks by observing the spacecraft’s acknowledgments and state changes. At scale, streams of valid-but-stale commands can congest command queues, delay legitimate activity, or trigger nuisance FDIR responses. |
|
EX-0001.02 |
Bus Traffic Replay |
Instead of the RF path, the attacker targets internal command/data handling by injecting or retransmitting messages on the spacecraft bus (e.g., 1553, SpaceWire, custom). Because many subsystems act on the latest message or on message rate rather than on uniqueness, a flood of historical yet well-formed frames can consume bandwidth, starve critical publishers, or cause subsystems to perform the same action repeatedly. Secondary effects include stale sensor values being re-consumed, watchdog timers being reset at incorrect intervals, and autonomy rules misclassifying the situation due to out-of-order but valid-looking events. On time-triggered or scheduled buses, replaying at precise offsets can collide with or supersede legitimate messages, steering system state without changing software. The goal is to harness the bus’s determinism, repeating prior internal stimuli to recreate prior effects or to induce resource exhaustion. |
| EX-0006 |
Disable/Bypass Encryption |
The adversary alters how confidentiality or integrity is applied so traffic or data is processed in clear or with weakened protection. Paths include toggling configuration flags that place links or storage into maintenance/test modes; forcing algorithm “fallbacks” or null ciphers; downgrading negotiated suites or keys; manipulating anti-replay/counter state so checks are skipped; substituting crypto libraries or tables during boot/update; and selecting alternate routes that carry the same content without encryption. On some designs, distinct modes handle authentication and confidentiality separately, allowing an actor who obtains authentication material to request unencrypted service or to switch to legacy profiles. The end state is that command, telemetry, or data products traverse a path the spacecraft accepts while cryptographic protection is absent, weakened, or inconsistently applied, enabling subsequent tactics such as inspection, manipulation, or exfiltration. |
| EX-0009 |
Exploit Code Flaws |
The adversary executes actions on-board by abusing defects in software that runs on the vehicle, ranging from application logic in flight software to libraries, drivers, and supporting services. Outcomes range from arbitrary code execution and privilege escalation to silent logic manipulation (e.g., bypassing interlocks, suppressing alarms) that appears operationally plausible. The hallmark of this technique is that the attacker co-opts existing code paths, often rarely used ones, to run unintended behavior under nominal interfaces. These attacks may be extremely targeted and tailored to specific coding errors introduced as a result of poor coding practices or they may target known issues in the commercial software components. |
|
EX-0009.02 |
Operating System |
At the OS layer, the attacker targets primitives that schedule work and mediate hardware. Modern spacecraft, particularly small satellites, increasingly rely on Linux-based operating systems (e.g., Yocto-derived distributions) rather than traditional RTOSes, significantly expanding the applicable attack surface to include techniques documented in MITRE ATT&CK for Linux - <a href='https://attack.mitre.org/matrices/enterprise/linux/' class='internal-link' target='_blank'>https://attack.mitre.org/matrices/enterprise/linux/</a>. Maintenance builds may expose shells or management consoles; misconfigurations around these interfaces can provide paths to command interpreters or privileged syscalls. Linux-based flight systems inherit standard Unix/Linux vulnerabilities including kernel exploits, container escapes, privilege escalation via misconfigured sudo/capabilities, and exploitation of systemd or other init systems. 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. Common Linux-specific vectors include exploiting unpatched kernel vulnerabilities, abusing misconfigurations in containerized environments, leveraging POSIX API weaknesses in flight applications, and targeting shared libraries or dynamic linkers to inject malicious code into flight processes. 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. Because spacecraft Linux builds are often minimized, long-lived (limited patching), and may retain debug interfaces or permissive file permissions from ground testing, they present a unique risk profile combining embedded-system constraints with commodity OS attack techniques. Flight images frequently retain extraneous binaries and utilities (e.g., compilers, debuggers, network tools, package managers) intended for ground testing or development that are not removed before launch, providing adversaries with ready-made 'living off the land' capabilities for reconnaissance, lateral movement, and privilege escalation without needing to upload custom tooling. |
|
EX-0009.03 |
Known Vulnerability (COTS/FOSS) |
Using knowledge of the software composition on-board, the adversary maps components and versions to publicly or privately known defects and then crafts inputs to trigger them. Typical targets include standard libraries (libc, STL), cryptographic and compression libraries, protocol stacks (CCSDS implementations, IP over space links, SpaceWire bridges), filesystems and parsers (FITS/CCSDS packetization, custom table formats), and vendor SDKs for radios, sensors, or payloads. Triggers arrive as well-formed but malicious packets, frames, or files whose edge-case fields exercise version-specific bugs, overflowing a parser, bypassing an authentication check, or causing a kernel/driver fault that reboots into a more permissive mode. Because these flaws are documented somewhere, exploitation emphasizes matching the exact build and build-time options used on the mission. |
| EX-0012 |
Modify On-Board Values |
The attacker alters live or persistent data that the spacecraft uses to make decisions and route work. Targets include device and control registers, parameter and limit tables, internal routing/subscriber maps, schedules and timelines, priority/QoS settings, watchdog and timer values, autonomy/FDIR rule tables, ephemeris and attitude references, and power/thermal setpoints. Many missions expose legitimate mechanisms for updating these artifacts, direct memory read/write commands, table load services, file transfers, or maintenance procedures, which can be invoked to steer behavior without changing code. Edits may be transient (until reset) or latched/persistent across boots; they can be narrowly scoped (a single bit flip on an enable mask) or systemic (rewriting a routing table so commands are misdelivered). The effect space spans subtle biasing of control loops, selective blackholing of commands or telemetry, rescheduling of operations, and wholesale changes to mode logic, all accomplished by modifying the values the software already trusts and consumes. |
|
EX-0012.01 |
Registers |
Threat actors may target the internal registers of the victim spacecraft in order to modify specific values as the FSW is functioning or prevent certain subsystems from working. Most aspects of the spacecraft rely on internal registers to store important data and temporary values. By modifying these registers at certain points in time, threat actors can disrupt the workflow of the subsystems or onboard payload, causing them to malfunction or behave in an undesired manner. |
|
EX-0012.02 |
Internal Routing Tables |
Threat actors may rewrite the maps that tell software where to send and receive things. In publish/subscribe or message-queued flight frameworks, tables map message IDs to subscribers, opcodes to handlers, and pipes to processes; at interfaces, address/port maps define how traffic traverses bridges and gateways (e.g., SpaceWire node/port routes, 1553 RT/subaddress mappings, CAN IDs). By altering these structures, commands can be misdelivered, dropped, duplicated, or routed through unintended paths; telemetry can be redirected or blackholed; and handler bindings can be swapped so an opcode triggers the wrong function. Schedule/routing hybrids, used to sequence activities and distribute results, can be edited to reorder execution or to create feedback loops that occupy bandwidth and processor time. The result is control over who hears what and when, achieved by changing the lookup tables that underpin command/telemetry distribution rather than the code that processes them. |
|
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-0012.04 |
App/Subscriber Tables |
In publish/subscribe flight frameworks, applications and subsystems register interest in specific message classes via subscriber (or application) tables. These tables map message IDs/topics to subscribers, define delivery pipes/queues, and often include filters, priorities, and rate limits. By altering these mappings, an adversary can quietly reshape information flow: critical consumers stop receiving health or sensor messages; non-critical tasks get flooded; handlers are rebound so an opcode or message ID reaches the wrong task; or duplicates create feedback loops that consume bandwidth and CPU. Because subscription state is usually read at init or refreshed on command, subtle edits can persist across reboots or take effect at predictable times. Similar effects appear in legacy MIL-STD-1553 deployments by modifying Remote Terminal (RT), subaddress, or mode-code configurations so that messages are misaddressed or dropped at the bus interface. The net result is control-by-misdirection: the software still “works,” but the right data no longer reaches the right recipient at the right time. |
|
EX-0012.05 |
Scheduling Algorithm |
Spacecraft typically rely on real-time scheduling, fixed-priority or deadline/periodic schemes, driven by timers, tick sources, and per-task parameters. Threat actors target these parameters and associated tables to skew execution order and timing. Edits may change priorities, periods, or deadlines; adjust CPU budgets and watchdog thresholds; alter ready-queue disciplines; or reconfigure timer tick rates and clock sources. They may also modify task affinities, message-queue depths, and interrupt masks so preemption and latency characteristics shift. Small changes can have large effects: high-rate control loops see added jitter, estimator updates miss deadlines, command/telemetry handling starves, or low-priority maintenance tasks monopolize cores due to mis-set periods. Manipulated schedules can create intermittent, state-dependent malfunctions that are hard to distinguish from environmental load. The essence of the technique is to weaponize time, reshaping when work happens so that otherwise correct code produces unsafe or exploitable behavior. |
|
EX-0012.06 |
Science/Payload Data |
Payload data, and the metadata that gives it meaning, can be altered in place to steal value, mislead users, or degrade mission outputs. Targets include raw detector frames, packetized Level-0 streams, onboard preprocessed products, and file catalogs/directories on mass memory. Adjacent metadata such as timestamps, pointing/attitude tags, calibration coefficients, compression settings, and quality flags are equally potent; slight bias in a calibration table or time tag can skew entire downlink campaigns while appearing routine. An adversary may rewrite frame headers, reorder packets, substitute segments from prior passes, or flip quality bits so ground pipelines silently discard or misclassify products. Recorder index manipulation can orphan files or cause downlinks to serve stale or fabricated content. Because many missions perform some processing or filtering onboard, tampering upstream of downlink propagates forward as “authoritative” truth, jeopardizing mission objectives without obvious protocol anomalies. |
|
EX-0012.07 |
Propulsion Subsystem |
Propulsion relies on parameters and sensed values that govern burns, pressure management, and safing. Editable items include thruster calibration and minimum impulse bit, valve timing and duty limits, inhibit masks, delta-V tables, plume keep-out constraints, tank pressure/temperature thresholds, leak-detection limits, and momentum-management coupling with attitude control. By modifying these, an adversary can provoke over-correction, waste propellant through repeated trims, bias orbit maintenance, or trigger protective sequences at inopportune times. False pressure or temperature readings can cause autonomous venting or lockouts; tweaked alignment matrices or misapplied gimbal limits can yield off-axis thrust and attitude excursions; altered desaturation rules can induce frequent wheel unloads that sap resources. Because consumables are finite and margins tight, even modest parameter drift can shorten mission life or violate keep-out and conjunction constraints while presenting as “normal” control activity. |
|
EX-0012.08 |
Attitude Determination & Control Subsystem |
ADCS depends on tightly coupled models and parameters: star-tracker catalogs and masks, sensor alignments and bias terms, gyro scale factors and drift rates, estimator covariances and process/measurement noise, controller gains and saturation limits, wheel/CMG torque constants, magnetic torquer maps, and sun sensor thresholds. Editing these values skews estimation or control, producing slow bias, limit cycles, loss of lock, or abrupt safing triggers. For example, a small change to a star-tracker mask can force frequent dropouts; an inflated gyro bias drives the filter away from truth; softened actuator limits or mis-set gains let disturbances accumulate; altered sun-point entry criteria cause unnecessary mode switches. Secondary impacts propagate to power, thermal, and communications because pointing and geometry underpin array generation, radiator view factors, and antenna gain. The technique turns the spacecraft against itself by nudging the parameters that close the loop between what the vehicle believes and how it responds. |
|
EX-0012.09 |
Electrical Power Subsystem |
Adversaries alter parameters and sensed values that govern power generation, storage, and distribution so the spacecraft draws or allocates energy in harmful ways. Editable items include bus voltage/current limits, MPPT setpoints and sweep behavior, array and SADA modes, battery charge/discharge thresholds and temperature derates, state-of-charge estimation constants, latching current limiter (LCL) trip/retry settings, load-shed priorities, heater duty limits, and survival/keep-alive rules. By changing these, a threat actor can drive excess consumption (e.g., disabling load shed, raising heater floors), misreport remaining energy (skewed SoC), or push batteries outside healthy ranges, producing brownouts, repeated safing, or premature capacity loss. Manipulating thresholds and hysteresis can also create oscillations where loads repeatedly drop and re-engage, wasting energy and stressing components. The effect is accelerated depletion or misallocation of finite power, degrading mission operations and potentially preventing recovery after eclipse or anomalies. |
|
EX-0012.10 |
Command & Data Handling Subsystem |
C&DH relies on tables and runtime values that define how commands are parsed, queued, and dispatched and how telemetry is collected, stored, and forwarded. Targets include opcode-to-handler maps, argument limits and schemas, queue depths and priorities, message ID routing, publish/subscribe bindings, timeline/schedule entries, file catalog indices, compression and packetization settings, and event/telemetry filters. Edits to these artifacts reshape control and visibility: commands are delayed, dropped, or misrouted; telemetry is suppressed or redirected; timelines slip; and housekeeping/data products are repackaged in ways that confuse ground processing. Because many frameworks treat these values as authoritative configuration, small changes can silently propagate across subsystems, degrading responsiveness, creating backlogs, or severing the logical pathways that keep the vehicle coordinated, without modifying the underlying code. |
|
EX-0012.11 |
Watchdog Timer (WDT) |
Watchdogs supervise liveness by requiring software to “pet” within defined windows or the system resets. Threat actors manipulate WDT behavior by changing timeout durations, windowed-WDT bounds, reset actions, enable/mask bits, or the source that performs the petting (e.g., moving it into a low-level ISR so higher layers can be stalled indefinitely). Software WDTs can be disabled or starved; hardware WDTs are influenced via control registers, strap pins, or supervisor commands that alter prescalers and reset ladders. Outcomes include preventing intended resets so runaway tasks consume power and bandwidth, or forcing repeated resets at tactically chosen moments, e.g., during updates or handovers, to keep the system in a degraded or easily predictable state. The technique converts a safety mechanism into a tool for either unbounded execution or rhythmic disruption, depending on how the WDT parameters are rewritten. |
|
EX-0012.12 |
System Clock |
Spacecraft maintain multiple time bases and distribute time to schedule sequences, validate timetags, manage anti-replay counters, and align navigation/attitude processing. By writing to clock registers, altering time-distribution services, switching disciplining sources, or biasing oscillator parameters, an adversary can skew these references. Effects include reordering or prematurely firing stored command sequences, invalidating timetag checks, desynchronizing counters used by authentication or ranging, misaligning estimator windows, and corrupting timestamped payload data. Even small offsets can accumulate into observable misbehavior when autonomy and scheduling depend on tight temporal guarantees. The result is execution that happens at the wrong moment, or not at all, because the system’s notion of “now” has been shifted. |
|
EX-0012.13 |
Poison AI/ML Training Data |
When missions employ AI/ML, for onboard detection/classification, compression, anomaly screening, guidance aids, or ground-side planning, training data becomes a control surface. Data poisoning inserts crafted examples or labels into the training corpus or fine-tuning set so the resulting model behaves incorrectly while appearing valid. Variants include clean-label backdoors (benign-looking samples with a hidden trigger that later induces a targeted response), label flipping and biased sampling (to skew decision boundaries), and corruption of calibration/ground-truth products that the pipeline trusts. For space systems, poisoning may occur in science archives, test vectors, simulated scenes, or housekeeping datasets used to train autonomy/anomaly models; models trained on poisoned corpora are then packaged and uplinked as routine updates. Once fielded, a simple trigger pattern in imagery, telemetry, or RF features can cause misclassification, suppression, or false positives at the time and place the adversary chooses, turning model behavior into an execution mechanism keyed by data rather than code. |
| 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.02 |
Bus Traffic Spoofing |
Here the adversary forges messages on internal command/data paths (e.g., 1553, SpaceWire, CAN, custom). By emitting frames with valid identifiers, addresses, and timing, the attacker can make subscribers accept actuator setpoints, power switch toggles, mode changes, or housekeeping values that originated off-path. Because many consumers act on “latest value wins” or on message cadence, forged traffic can mask real publishers, starve critical topics, or force handlers to execute unintended branches. Gateways that translate between networks amplify impact: a spoofed message on one side can propagate to multiple domains as legitimate payload. Outcomes include misdelivered commands, silent configuration drift, and control loops chasing phantom stimuli, all while bus monitors show protocol-conformant traffic.
In architectures where component identity is derived solely from message identifiers, an adversary may suppress the genuine component and fully assume its identity by publishing under the same identifiers at the expected cadence. This sustained impersonation differs from transient injection because the attacker becomes the sole authoritative source for that subsystem's telemetry, housekeeping, and command responses, while ground systems that rely on message-ID-based attribution cannot distinguish spoofed output from legitimate data. Internal suppression commands remain invisible in ground logs, making the replacement potentially forensically undetectable. |
|
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. |
|
EX-0014.04 |
Position, Navigation, and Timing (PNT) Spoofing |
The adversary transmits GNSS-like signals (or manipulates crosslink-distributed time/ephemeris) so the spacecraft’s navigation solution reflects attacker-chosen states. With believable code phases, Doppler, and navigation messages, the victim can be pulled to a false position/velocity/time, causing downstream functions, attitude pointing limits, station visibility prediction, eclipse timing, antenna pointing, and anti-replay windows, to misbehave. Even when GNSS is not the primary navigation source, spoofed PNT can bias timekeeping or seed filters that fuse multiple sensors, leading to mis-scheduling and errant control. The defining feature is externally provided navigation/time that passes validity checks yet encodes a crafted trajectory or epoch. |
| 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. |
| DE-0002 |
Disrupt or Deceive Downlink |
Threat actors may target any point in the telemetry chain, onboard generation and transmission, the downlink path itself, or ground-side reception, processing, and display, to disrupt the operator’s visibility into spacecraft health and activity. This may involve denial-based attacks that prevent the spacecraft from transmitting telemetry to the ground (e.g., disabling telemetry links or crashing telemetry software), or more subtle deception-based attacks that manipulate telemetry content to conceal unauthorized actions. Since telemetry is the primary method ground controllers rely on to monitor spacecraft status, any disruption or manipulation can delay or prevent detection of malicious activity, suppress automated or manual mitigations, or degrade trust in telemetry-based decision support systems. |
|
DE-0002.01 |
Inhibit Ground System Functionality |
Threat actors may utilize access to the ground system to inhibit its ability to accurately process, render, or interpret spacecraft telemetry, effectively leaving ground controllers unaware of the spacecraft’s true state or activity. This may involve traditional denial-based techniques, such as disabling telemetry software, corrupting processing pipelines, or crashing display interfaces. In addition, more subtle deception-based techniques may be used to falsify telemetry data within the ground system , such as modifying command counters, acknowledgments, housekeeping data, or sensor outputs , to provide the appearance of nominal operation. These actions can suppress alerts, mask unauthorized activity, or prevent both automated and manual mitigations from being initiated based on misleading ground-side information. Because telemetry is the primary method by which ground controllers monitor the health, behavior, and safety of the spacecraft, any disruption or falsification of this data directly undermines situational awareness and operational control.
Architectural limitations in ground station software can also enable deception without requiring direct compromise of the ground system. In publish-subscribe spacecraft architectures, ground tools typically attribute telemetry solely by Message ID rather than by producing application. This design assumes that Message IDs reliably identify the originating component. When a malicious onboard application publishes telemetry under a legitimate subsystem's Message ID, ground logs permanently record the spoofed data as genuine with no indication of the true source. Similarly, internal spacecraft bus commands may not be downlinked or logged by ground systems, rendering suppression events forensically invisible. This attribution gap allows onboard component impersonation to succeed without any ground system compromise: the ground infrastructure functions as designed, yet cannot distinguish authentic telemetry from architecturally valid spoofing. |
| DE-0004 |
Masquerading |
The adversary presents themselves as an authorized origin so activity appears legitimate across RF, protocol, and organizational boundaries. Techniques include crafting telecommand frames with correct headers, counters, and dictionaries; imitating station “fingerprints” such as Doppler, polarization, timing, and framing; replaying or emulating crosslink identities; and using insider-derived credentials or roles to operate mission tooling. Masquerading can also target metadata, virtual channel IDs, APIDs, source sequence counts, and facility identifiers, so logs and telemetry attribute actions to expected entities. The effect is that commands, file transfers, or configuration changes are processed as if they came from approved sources, reducing scrutiny and delaying detection. |
| DE-0006 |
Modify Whitelist |
Threat actors may target whitelists on the spacecrafts as a means to execute and/or hide malicious processes/programs. Whitelisting is a common technique used on traditional IT systems but has also been used on spacecrafts. Whitelisting is used to prevent execution of unknown or potentially malicious software. However, this technique can be bypassed if not implemented correctly but threat actors may also simply attempt to modify the whitelist outright to ensure their malicious software will operate on the spacecraft that utilizes whitelisting. |
| LM-0001 |
Hosted Payload |
The adversary pivots through the host–payload boundary to reach additional subsystems. Hosted payloads exchange power, time, housekeeping, and data with the bus via defined gateways (e.g., SpaceWire, 1553, Ethernet) and often support file services, table loads, and command dictionaries distinct from the host’s. A foothold on the payload can be used to inject traffic through the gateway processor, request privileged services (time/ephemeris distribution, firmware loads), or ride shared backplanes where payload traffic is bridged into C&DH networks. In some designs, payload processes execute on host compute or expose maintenance modes that temporarily widen access, creating paths from the payload into attitude, power, storage, or recorder resources. The movement is transitive: compromise a co-resident unit, then traverse the trusted interface that already exists for mission operations. |
| LM-0002 |
Exploit Lack of Bus Segregation |
On flat architectures, where remote terminals, subsystems, and payloads share a common bus with minimal partitioning, any node that can transmit may influence many others. An attacker leverages this by forging message IDs or terminal addresses, replaying actuator/sensor frames, seizing or imitating bus-controller roles, or abusing gateway bridges that forward traffic between links (e.g., 1553↔SpaceWire/CAN). Because consumers often act on the latest valid-looking message, crafted traffic from one compromised device can reconfigure peers, toggle power domains, or write persistent parameters. Weak role enforcement and broadcast semantics allow privilege escalation from a peripheral to effective system-wide influence, turning the shared medium into a highway for further compromise. |
| LM-0003 |
Constellation Hopping via Crosslink |
In networks where vehicles exchange data over inter-satellite links, a compromise on one spacecraft becomes a springboard to others. The attacker crafts crosslink traffic, routing updates, service advertisements, time/ephemeris distribution, file or tasking messages, that appears to originate from a trusted neighbor and targets gateway functions that bridge crosslink traffic into command/data paths. Once accepted, those messages can queue procedures, deliver configuration/table edits, or open file transfer sessions on adjacent vehicles. In mesh or hub-and-spoke constellations, this enables “hop-by-hop” spread: a single foothold uses shared trust and protocol uniformity to reach additional satellites without contacting the ground segment. |
| LM-0004 |
Visiting Vehicle Interface(s) |
Docking, berthing, or short-duration attach events create high-trust, high-bandwidth connections between vehicles. During these operations, automatic sequences verify latches, exchange status, synchronize time, and enable umbilicals that carry data and power; maintenance tools may also push firmware or tables across the interface. An attacker positioned on the visiting vehicle can exploit these handshakes and service channels to inject commands, transfer files, or access bus gateways on the host. Because many actions are expected “just after dock,” malicious traffic can ride the same procedures that commission the interface, allowing lateral movement from the visiting craft into the target spacecraft’s C&DH, payload, or support subsystems. |
| LM-0005 |
Virtualization Escape |
The adversary pivots across partitions by abusing the mechanisms a separation kernel or hypervisor exposes for inter-partition communication and device sharing. Paths include message ports/queues, shared-memory windows, virtual NICs and bridges, hypercalls, and common driver backends (e.g., storage or DMA engines without strict IOMMU bounds). A foothold in a less-trusted partition, often a payload or guest OS, can be turned into access to a higher-privilege domain by crafting traffic that exploits parser flaws in port services, racing management channels, or coercing backend drivers to perform out-of-bounds operations. Once the boundary is crossed, the actor can reach bus gateways, file systems, or control applications hosted in adjacent partitions and continue movement under the guise of permitted inter-partition exchanges. |
| LM-0006 |
Launch Vehicle Interface |
During integration and ascent, payloads and the launch vehicle exchange power, discrete lines, and data via umbilicals, separation avionics, and shared EGSE networks. Protections can be reduced or heterogeneous because timelines are tight and responsibilities cross organizations. An attacker positioned on either side (vehicle or payload) can use these commissioning links, health/status queries, time distribution, inhibit lines, separation commands, or telemetry gateways, to inject messages, transfer files, or alter configuration that propagates across the interface. Before fairing close and prior to separation, this brief but high-trust coupling provides a route to move from one platform to the other and to seed artifacts that persist after deployment. |
|
LM-0006.01 |
Rideshare Payload |
In shared launches, multiple independent payloads cohabit common infrastructure until separation. If isolation is incomplete (e.g., shared data buses, mispartitioned deployer controllers, common logging/telemetry collectors, or cross-connected laptops and recorders), a compromise in one payload’s domain can be leveraged to observe or influence another’s traffic before release. Threat actors exploit these transient but real connections to read configuration, pivot through deployer control paths, or stage data/commands that execute as neighboring payloads power and check out, enabling cross-payload access or tampering prior to independent flight. |
| EXF-0001 |
Replay |
The adversary re-sends previously valid commands or procedures to cause the spacecraft to transmit data again, then captures the resulting downlink. Typical targets are recorder playbacks, payload product dumps, housekeeping snapshots, or file directory listings. By aligning replays with geometry (e.g., when the satellite is in view of actor-controlled apertures) and with acceptance conditions (counters, timetags, mode), the attacker induces legitimate transmissions that appear routine to operators. Variants include selectively replaying index ranges to fetch only high-value intervals, reissuing subscription/telemetry-rate changes to increase data volume, or queueing playbacks that fire during later passes when interception is feasible. |
| EXF-0002 |
Side-Channel Exfiltration |
Information is extracted not by reading files or decrypting frames but by observing physical or protocol byproducts of computation, power draw, electromagnetic emissions, timing, thermal signatures, or traffic patterns. Repeated measurements create distinctive fingerprints correlated with internal states (key use, table loads, parser branches, buffer occupancy). Matching those fingerprints to models or templates yields sensitive facts without direct access to the protected data. In space systems, vantage points span proximity assets (for EM/thermal), ground testing and ATLO (for direct probing), compromised on-board modules that can sample rails or sensors, and remote observation of link-layer timing behaviors. |
|
EXF-0002.02 |
Electromagnetic Leakage Attacks |
Switching activity in chips, buses, and clocks radiates EM energy that can be captured and analyzed to reveal internal computation. Near-field probes (in test) or proximity receivers (on-orbit assets) can observe harmonics and modulation tied to cipher rounds, key schedules, or protocol framing, sometimes with finer granularity than power analysis. Coupling paths include packages, harnesses, SDR front ends, and poorly shielded enclosures. By training on known operations and comparing spectra or time-domain signatures, an adversary can recover keys or reconstruct processed data without touching logical interfaces. |
|
EXF-0002.03 |
Traffic Analysis Attacks |
In a terrestrial environment, threat actors use traffic analysis attacks to analyze traffic flow to gather topological information. This traffic flow can divulge information about critical nodes, such as the aggregator node in a sensor network. In the space environment, specifically with relays and constellations, traffic analysis can be used to understand the energy capacity of spacecraft node and the fact that the transceiver component of a spacecraft node consumes the most power. The spacecraft nodes in a constellation network limit the use of the transceiver to transmit or receive information either at a regulated time interval or only when an event has been detected. This generally results in an architecture comprising some aggregator spacecraft nodes within a constellation network. These spacecraft aggregator nodes are the sensor nodes whose primary purpose is to relay transmissions from nodes toward the ground station in an efficient manner, instead of monitoring events like a normal node. The added functionality of acting as a hub for information gathering and preprocessing before relaying makes aggregator nodes an attractive target to side channel attacks. A possible side channel attack could be as simple as monitoring the occurrences and duration of computing activities at an aggregator node. If a node is frequently in active states (instead of idle states), there is high probability that the node is an aggregator node and also there is a high probability that the communication with the node is valid. Such leakage of information is highly undesirable because the leaked information could be strategically used by threat actors in the accumulation phase of an attack. |
| EXF-0003 |
Signal Interception |
The adversary captures mission traffic in transit, on ground networks or over the space link, so that payload products, housekeeping, and command/ack exchanges can be reconstructed offline. Vantage points include tapped ground LANs/WANs between MOC and stations, baseband interfaces (IF/IQ), RF/optical receptions within the antenna field of view, and crosslink monitors. Depending on protection, the haul ranges from plaintext frames to encrypted bitstreams whose headers, rates, and schedules still yield valuable context (APIDs, VCIDs, pass timing, file manifest cues). Intercepted sessions can guide later replay, cloning, or targeted downlink requests. |
|
EXF-0003.01 |
Uplink Exfiltration |
Here the target is command traffic from ground to space. By receiving or tapping the uplink path, the adversary collects telecommand frames, ranging/acquisition exchanges, and any file or table uploads. If confidentiality is weak or absent, opcode/argument content, dictionaries, and procedures become directly readable; even when encrypted, session structure, counters, and acceptance timing inform future command-link intrusion or replay. Captured material can reveal maintenance windows, contingency dictionaries, and authentication schemes that enable subsequent exploitation. |
|
EXF-0003.02 |
Downlink Exfiltration |
The attacker records spacecraft-to-ground traffic, real-time telemetry, recorder playbacks, payload products, and mirrored command sessions, to obtain mission data and health/state information. With sufficient signal quality and protocol knowledge, frames and packets are demodulated and extracted for offline use; where protection exists only on uplink or is inconsistently applied, downlink content may still be in clear. Downlinked command echoes, event logs, and file catalogs can expose internal activities and aid follow-on targeting while the primary objective remains data capture at scale. |
| EXF-0004 |
Out-of-Band Communications Link |
Some missions field secondary links, separate frequencies and hardware, for limited, purpose-built functions (e.g., rekeying, emergency commanding, beacons, custodial crosslinks). Adversaries co-opt these channels as covert data paths: embedding content in maintenance messages, beacon fields, or low-rate housekeeping; initiating vendor/service modes that carry file fragments; or switching to contingency profiles that bypass normal routing and monitoring. Because these paths are distinct from the main TT&C and may be sparsely supervised, they provide discreet avenues to move data off the spacecraft or to external relays without altering the primary link’s traffic patterns. |
| EXF-0009 |
Compromised Partner Site |
The adversary leverages third-party infrastructure connected to the mission, commercial ground stations, relay networks, operations service providers, data processing partners, to capture or relay mission data outside official channels. From these footholds, the attacker can mirror TT&C and payload feeds, scrape shared repositories, and man-in-the-middle cross-organization links (e.g., between partner stations and the primary MOC). Because partner environments vary in segmentation and monitoring, exfiltration can affect multiple missions or operators simultaneously, with stolen data exiting through the partner’s routine distribution mechanisms. |
| EXF-0010 |
Payload Communication Channel |
Many payloads maintain communications separate from the primary TT&C, direct downlinks to user terminals, customer networks, or experimenter VPNs. An adversary who implants code in the payload (or controls its gateway) can route host-bus data into these channels, embed content within payload products (e.g., steganographic fields in imagery/telemetry), or schedule covert file transfers alongside legitimate deliveries. Because these paths are expected to carry high-rate mission data and may bypass TT&C monitoring, they provide a discreet conduit to exfiltrate payload or broader spacecraft information without altering the primary command link’s profile. |