Implement the indicated fail-safe procedures when the indicated failures occur: [Assignment: organization-defined list of failure conditions and associated fail-safe procedures].
A fail-safe approach on a spacecraft means anticipating plausible fault modes—like partial loss of command link, radiation-induced memory corruption, or erroneous GPS updates—and predefining minimal, low-risk behaviors for each scenario. Many vehicles default to "safe mode," which shuts down non-essential subsystems and preserves only enough capability to re-establish ground communication or sustain life-critical functions (in manned settings). Some missions also implement "crippled mode," retaining a bit more functionality than safe mode, to isolate faulty modules while keeping some mission tasks alive. Designers must ensure these fallback states are carefully tested on the ground to avoid inadvertently worsening the situation—e.g., by resetting cryptographic keys at the wrong moment. Effective fail-safe logic confers a controlled, graceful degradation under duress, preserving the spacecraft's core viability so ground teams can attempt recovery or upload fresh directives.
| ID | Name | Description | D3FEND | |
| CM0032 | On-board Intrusion Detection & Prevention | Utilize on-board intrusion detection/prevention system that monitors the mission critical components or systems and audit/logs actions. The IDS/IPS should have the capability to respond to threats (initial access, execution, persistence, evasion, exfiltration, etc.) and it should address signature-based attacks along with dynamic never-before seen attacks using machine learning/adaptive technologies. The IDS/IPS must integrate with traditional fault management to provide a wholistic approach to faults on-board the spacecraft. Spacecraft should select and execute safe countermeasures against cyber-attacks. These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker — with or without ground support. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system. | D3-FA D3-DA D3-FCR D3-FH D3-ID D3-IRA D3-HD D3-IAA D3-FHRA D3-NTA D3-PMAD D3-RTSD D3-ANAA D3-CA D3-CSPP D3-ISVA D3-PM D3-SDM D3-SFA D3-SFV D3-SICA D3-USICA D3-FBA D3-FEMC D3-FV D3-OSM D3-PFV D3-EHB D3-IDA D3-MBT D3-SBV D3-PA D3-PSMD D3-PSA D3-SEA D3-SSC D3-SCA D3-FAPA D3-IBCA D3-PCSV D3-FCA D3-PLA D3-UBA D3-RAPA D3-SDA D3-UDTA D3-UGLPA D3-ANET D3-AZET D3-JFAPA D3-LAM D3-NI D3-RRID D3-NTF D3-ITF D3-OTF D3-EI D3-EAL D3-EDL D3-HBPI D3-IOPR D3-KBPI D3-MAC D3-SCF | |
| CM0042 | Robust Fault Management | Ensure fault management system cannot be used against the spacecraft. Examples include: safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of telemetry to cause action from ground, or some sort of proximity operation to cause spacecraft to go into safe mode. Understanding the safing procedures and ensuring they do not put the spacecraft in a more vulnerable state is key to building a resilient spacecraft. | D3-AH D3-EHPV D3-PSEP D3-PH D3-SCP | |
| CM0044 | Cyber-safe Mode | Provide the capability to enter the spacecraft into a configuration-controlled and integrity-protected state representing a known, operational cyber-safe state (e.g., cyber-safe mode). Spacecraft should enter a cyber-safe mode when conditions that threaten the platform are detected. Cyber-safe mode is an operating mode of a spacecraft during which all nonessential systems are shut down and the spacecraft is placed in a known good state using validated software and configuration settings. Within cyber-safe mode, authentication and encryption should still be enabled. The spacecraft should be capable of reconstituting firmware and software functions to pre-attack levels to allow for the recovery of functional capabilities. This can be performed by self-healing, or the healing can be aided from the ground. However, the spacecraft needs to have the capability to replan, based on equipment still available after a cyber-attack. The goal is for the spacecraft to resume full mission operations. If not possible, a reduced level of mission capability should be achieved. Cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable. | D3-PH D3-EI D3-NI D3-BA | |
| CM0038 | Segmentation | Identify the key system components or capabilities that require isolation through physical or logical means. Information should not be allowed to flow between partitioned applications unless explicitly permitted by security policy. Isolate mission critical functionality from non-mission critical functionality by means of an isolation boundary (implemented via partitions) that controls access to and protects the integrity of, the hardware, software, and firmware that provides that functionality. Enforce approved authorizations for controlling the flow of information within the spacecraft and between interconnected systems based on the defined security policy that information does not leave the spacecraft boundary unless it is encrypted. Implement boundary protections to separate bus, communications, and payload components supporting their respective functions. | D3-NI D3-BDI D3-NTF D3-ITF D3-OTF D3-EI D3-HBPI D3-KBPI D3-MAC D3-RRID D3-EAL D3-EDL D3-IOPR D3-SCF | |
| ID | Description | |
| SV-MA-3 |
Attacks on critical software subsystems Attitude Determination and Control (AD&C) subsystem determines and controls the orientation of the satellite. Any cyberattack that could disrupt some portion of the control loop - sensor data, computation of control commands, and receipt of the commands would impact operations Telemetry, Tracking and Commanding (TT&C) subsystem provides interface between satellite and ground system. Computations occur within the RF portion of the TT&C subsystem, presenting cyberattack vector Command and Data Handling (C&DH) subsystem is the brains of the satellite. It interfaces with other subsystems, the payload, and the ground. It receives, validate, decodes, and sends commands to other subsystems, and it receives, processes, formats, and routes data for both the ground and onboard computer. C&DH has the most cyber content and is likely the biggest target for cyberattack. Electrical Power Subsystem (EPS) provides, stores, distributes, and controls power on the satellite. An attack on EPS could disrupt, damage, or destroy the satellite. |
|
| SV-AC-6 |
Three main parts of S/C. CPU, memory, I/O interfaces with parallel and/or serial ports. These are connected via busses (i.e., 1553) and need segregated. Supply chain attack on CPU (FPGA/ASICs), supply chain attack to get malware burned into memory through the development process, and rogue RTs on 1553 bus via hosted payloads are all threats. Security or fault management being disabled by non-mission critical or payload; fault injection or MiTM into the 1553 Bus - China has developed fault injector for 1553 - this could be a hosted payload attack if payload has access to main 1553 bus; One piece of FSW affecting another. Things are not containerized from the OS or FSW perspective; |
|
| SV-AV-5 |
Using fault management system against you. Understanding the fault response could be leveraged to get satellite in vulnerable state. Example, safe mode with crypto bypass, orbit correction maneuvers, affecting integrity of TLM to cause action from ground, or some sort of RPO to cause S/C to go into safe mode; |
|
| SV-AV-6 |
Complete compromise or corruption of running state |
|
| SV-DCO-1 |
Not knowing that you were attacked, or attack was attempted |
|
| SV-AV-7 |
The TT&C is the lead contributor to satellite failure over the first 10 years on-orbit, around 20% of the time. The failures due to gyro are around 12% between year one and 6 on-orbit and then ramp up starting around year six and overtake the contributions of the TT&C subsystem to satellite failure. Need to ensure equipment is not counterfeit and the supply chain is sound. |
|
| Requirement | Rationale/Additional Guidance/Notes |
|---|---|
| The [organization] defines the security safeguards to be employed to protect the availability of system resources.{CP-2(2),SC-6,SI-13,SI-17} | |
| The [spacecraft] shall enter a cyber-safe mode when conditions that threaten the platform are detected, enters a cyber-safe mode of operation with restrictions as defined based on the cyber-safe mode.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4,IR-4(1),IR-4(3),PE-10,RA-10,SA-8(16),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-13,SI-17} | |
| The [spacecraft] shall provide the capability to enter the platform into a known good, operational cyber-safe mode from a tamper-resistant, configuration-controlled (“gold”) image that is authenticated as coming from an acceptable supplier, and has its integrity verified.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-12,CP-13,IR-4(3),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-13,SI-17} | Cyber-safe mode is an operating mode of a spacecraft during which all nonessential systems are shut down and the spacecraft is placed in a known good state using validated software and configuration settings. Within cyber-safe mode authentication and encryption should still be enabled. The spacecraft should be capable of reconstituting firmware and SW functions to preattack levels to allow for the recovery of functional capabilities. This can be performed by self-healing, or the healing can be aided from the ground. However, the spacecraft needs to have the capability to replan, based on available equipment still available after a cyberattack. The goal is for the vehicle to resume full mission operations. If not possible, a reduced level of mission capability should be achieved. |
| The [spacecraft] shall enter cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable.{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-17} | |
| The [spacecraft] shall fail to a known secure state for failures during initialization, and aborts preserving information necessary to return to operations in failure.{SV-AV-5,SV-AV-6,SV-AV-7}{CP-10(6),CP-13,SA-8(16),SA-8(19),SA-8(24),SC-24,SI-13,SI-17} | |
| The [spacecraft] shall recover to a known cyber-safe state when an anomaly is detected.{IR-4,IR-4(1),SA-8(16),SA-8(19),SA-8(21),SA-8(24),SI-3,SI-4(7),SI-10(6),SI-13,SI-17} | |
| The [spacecraft] shall detect and recover from detected memory errors or transitions to a known cyber-safe state.{IR-4,IR-4(1),SA-8(16),SA-8(24),SI-3,SI-4(7),SI-10(6),SI-13,SI-17} | |
| The [spacecraft] shall select and execute safe countermeasures against cyber attacks prior to entering cyber-safe mode.{SV-DCO-1}{IR-4,RA-10,SA-8(21),SA-8(24),SI-4(7),SI-17} | These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker exquisitely—with or without ground aiding. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system." These countermeasures are likely executed prior to entering into a cyber-safe mode. |
| The [spacecraft] shall perform an orderly, controlled system shut-down to a known cyber-safe state upon receipt of a termination command or condition.{PE-11,PE-11(1),SA-8(16),SA-8(19),SA-8(24),SI-17} | |
| The [spacecraft] shall operate securely in off-nominal power conditions, including loss of power and spurious power transients.{PE-11,PE-11(1),SA-8(16),SA-8(19),SI-13,SI-17} | |
| The [spacecraft] shall initialize the platform to a known safe state.{SA-8(19),SA-8(23),SA-8(24),SI-17} | |
| The [organization] shall define the security safeguards to be employed to protect the availability of system resources.{SV-AC-6}{SC-6,SI-17} | |
| The [spacecraft] shall have failure tolerance on sensors used by software to make mission-critical decisions.{SV-MA-3,SV-AV-7}{SI-13,SI-17} | |
| The [spacecraft] cyber-safe mode software/configuration should be stored onboard the spacecraft in memory with hardware-based controls and should not be modifiable.{SV-AV-5,SV-AV-6,SV-AV-7}{SI-17} | Cyber-safe mode is using a fail-secure mentality where if there is a malfunction that the spacecraft goes into a fail-secure state where cyber protections like authentication and encryption are still employed (instead of bypassed) and the spacecraft can be restored by authorized commands. The cyber-safe mode should be stored in a high integrity location of the on-board SV so that it cannot be modified by attackers. |
| The [spacecraft] shall safely transition between all predefined, known states.{SI-17} | |
| The [spacecraft] software subsystems shall detect and recover/transition from detected memory errors to a known cyber-safe state.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall initialize the spacecraft to a known safe state.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall operate securely in off-nominal power conditions, including loss of power and spurious power transients.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall perform an orderly, controlled system shutdown to a known cyber-safe state upon receipt of a termination command or condition.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall recover to a known cyber-safe state when an anomaly is detected.{SV-MA-3,SV-AV-7}{SI-17} | |
| The [spacecraft] software subsystems shall safely transition between all predefined, known states.{SV-MA-3,SV-AV-7}{SI-17} |
| ID | Name | Description | |
|---|---|---|---|
| IA-0003 | Crosslink via Compromised Neighbor | Threat actors may compromise a victim spacecraft via the crosslink communications of a neighboring spacecraft that has been compromised. spacecraft in close proximity are able to send commands back and forth. Threat actors may be able to leverage this access to compromise other spacecraft once they have access to another that is nearby. | |
| IA-0005 | Rendezvous & Proximity Operations | Threat actors may perform a space rendezvous which is a set of orbital maneuvers during which a spacecraft arrives at the same orbit and approach to a very close distance (e.g. within visual contact or close proximity) to a target spacecraft. | |
| IA-0005.02 | Docked Vehicle / OSAM | Threat actors may leverage docking vehicles to laterally move into a target spacecraft. If information is known on docking plans, a threat actor may target vehicles on the ground or in space to deploy malware to laterally move or execute malware on the target spacecraft via the docking interface. | |
| IA-0005.03 | Proximity Grappling | Threat actors may posses the capability to grapple target spacecraft once it has established the appropriate space rendezvous. If from a proximity / rendezvous perspective a threat actor has the ability to connect via docking interface or expose testing (i.e., JTAG port) once it has grappled the target spacecraft, they could perform various attacks depending on the access enabled via the physical connection. | |
| IA-0006 | Compromise Hosted Payload | Threat actors may compromise the target spacecraft hosted payload to initially access and/or persist within the system. Hosted payloads can usually be accessed from the ground via a specific command set. The command pathways can leverage the same ground infrastructure or some host payloads have their own ground infrastructure which can provide an access vector as well. Threat actors may be able to leverage the ability to command hosted payloads to upload files or modify memory addresses in order to compromise the system. Depending on the implementation, hosted payloads may provide some sort of lateral movement potential. | |
| IA-0007 | Compromise Ground System | Threat actors may initially compromise the ground system in order to access the target spacecraft. Once compromised, the threat actor can perform a multitude of initial access techniques, including replay, compromising FSW deployment, compromising encryption keys, and compromising authentication schemes. Threat actors may also perform further reconnaissance within the system to enumerate mission networks and gather information related to ground station logical topology, missions ran out of said ground station, birds that are in-band of targeted ground stations, and other mission system capabilities. | |
| IA-0007.01 | Compromise On-Orbit Update | Threat actors may manipulate and modify on-orbit updates before they are sent to the target spacecraft. This attack can be done in a number of ways, including manipulation of source code, manipulating environment variables, on-board table/memory values, or replacing compiled versions with a malicious one. | |
| IA-0007.02 | Malicious Commanding via Valid GS | Threat actors may compromise target owned ground systems components (e.g., front end processors, command and control software, etc.) that can be used for future campaigns or to perpetuate other techniques. These ground systems components have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration. | |
| IA-0008 | Rogue External Entity | Threat actors may gain access to a victim spacecraft through the use of a rogue external entity. With this technique, the threat actor does not need access to a legitimate ground station or communication site. | |
| IA-0008.01 | Rogue Ground Station | Threat actors may gain access to a victim spacecraft through the use of a rogue ground system. With this technique, the threat actor does not need access to a legitimate ground station or communication site. | |
| IA-0008.02 | Rogue Spacecraft | Threat actors may gain access to a target spacecraft using their own spacecraft that has the capability to maneuver within close proximity to a target spacecraft to carry out a variety of TTPs (i.e., eavesdropping, side-channel, etc.). Since many of the commercial and military assets in space are tracked, and that information is publicly available, attackers can identify the location of space assets to infer the best positioning for intersecting orbits. Proximity operations support avoidance of the larger attenuation that would otherwise affect the signal when propagating long distances, or environmental circumstances that may present interference. | |
| IA-0009 | Trusted Relationship | Access through trusted third-party relationship exploits an existing connection that has been approved for interconnection. Leveraging third party / approved interconnections to pivot into the target systems is a common technique for threat actors as these interconnections typically lack stringent access control due to the trusted status. | |
| IA-0009.01 | Mission Collaborator (academia, international, etc.) | Threat actors may seek to exploit mission partners to gain an initial foothold for pivoting into the mission environment and eventually impacting the spacecraft. The complex nature of many space systems rely on contributions across organizations, including academic partners and even international collaborators. These organizations will undoubtedly vary in their system security posture and attack surface. | |
| IA-0009.02 | Vendor | Threat actors may target the trust between vendors and the target spacecraft. Missions often grant elevated access to vendors in order to allow them to manage internal systems as well as cloud-based environments. The vendor's access may be intended to be limited to the infrastructure being maintained but it may provide laterally movement into the target spacecraft. Attackers may leverage security weaknesses in the vendor environment to gain access to more critical mission resources or network locations. In the spacecraft context vendors may have direct commanding and updating capabilities outside of the primary communication channel. | |
| IA-0009.03 | User Segment | Threat actors can target the user segment in an effort to laterally move into other areas of the end-to-end mission architecture. When user segments are interconnected, threat actors can exploit lack of segmentation as the user segment's security undoubtedly varies in their system security posture and attack surface than the primary space mission. The user equipment and users themselves provide ample attack surface as the human element and their vulnerabilities (i.e., social engineering, phishing, iOT) are often the weakest security link and entry point into many systems. | |
| IA-0010 | Unauthorized Access During Safe-Mode | Threat actors may target a spacecraft in safe mode to establish initial access, taking advantage of reduced authentication, relaxed command filtering, or backup control pathways. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. Since safe mode often prioritizes availability and fault recovery over security, it may process commands that would otherwise be rejected in nominal operations. This condition can provide an entry point into mission operations if improperly protected. | |
| IA-0011 | Auxiliary Device Compromise | Threat actors may exploit the auxiliary/peripheral devices that get plugged into spacecrafts. It is no longer atypical to see spacecrafts, especially CubeSats, with Universal Serial Bus (USB) ports or other ports where auxiliary/peripheral devices can be plugged in. Threat actors can execute malicious code on the spacecrafts by copying the malicious code to auxiliary/peripheral devices and taking advantage of logic on the spacecraft to execute code on these devices. This may occur through manual manipulation of the auxiliary/peripheral devices, modification of standard IT systems used to initially format/create the auxiliary/peripheral device, or modification to the auxiliary/peripheral devices' firmware itself. | |
| EX-0001 | Replay | Replay attacks involve threat actors recording previously recorded data streams and then resending them at a later time. This attack can be used to fingerprint systems, gain elevated privileges, or even cause a denial of service. | |
| EX-0001.01 | Command Packets | Threat actors may interact with the victim spacecraft by replaying captured commands to the spacecraft. While not necessarily malicious in nature, replayed commands can be used to overload the target spacecraft and cause it's onboard systems to crash, perform a DoS attack, or monitor various responses by the spacecraft. If critical commands are captured and replayed, thruster fires, then the impact could impact the spacecraft's attitude control/orbit. | |
| EX-0001.02 | Bus Traffic Replay | Threat actors may abuse internal commanding to replay bus traffic within the victim spacecraft. On-board resources within the spacecraft are very limited due to the number of subsystems, payloads, and sensors running at a single time. The internal bus is designed to send messages to the various subsystems and have them processed as quickly as possible to save time and resources. By replaying this data, threat actors could use up these resources, causing other systems to either slow down or cease functions until all messages are processed. Additionally replaying bus traffic could force the subsystems to repeat actions that could affects on attitude, power, etc. | |
| EX-0002 | Position, Navigation, and Timing (PNT) Geofencing | Threat actors may leverage the fact that spacecraft orbit through space unlike typical enterprise systems which are stationary. Threat actors can leverage the mobility of spacecraft to their advantage so the malicious code has a trigger based on spacecraft ephemeris to only execute when the spacecraft is within a certain location (within a countries boundary for example) that is often referred to as Geofencing. By using a Geofence an adversary can ensure that malware is only executed when it is needed. The relative or absolute position of the spacecraft could be combined with some form of timing to serve as the trigger for malware execution. | |
| EX-0003 | Modify Authentication Process | Threat actors may modify the internal authentication process of the victim spacecraft to facilitate initial access, recurring execution, or prevent authorized entities from accessing the spacecraft. This can be done through the modification of the software binaries or memory manipulation techniques. | |
| EX-0005 | Exploit Hardware/Firmware Corruption | Threat actors can target the underlying hardware and/or firmware using various TTPs that will be dependent on the specific hardware/firmware. Typically, software tools (e.g., antivirus, antimalware, intrusion detection) can protect a system from threat actors attempting to take advantage of those vulnerabilities to inject malicious code. However, there exist security gaps that cannot be closed by the above-mentioned software tools since they are not stationed on software applications, drivers or the operating system but rather on the hardware itself. Hardware components, like memory modules and caches, can be exploited under specific circumstances thus enabling backdoor access to potential threat actors. In addition to hardware, the firmware itself which often is thought to be software in its own right also provides an attack surface for threat actors. Firmware is programming that's written to a hardware device's non-volatile memory where the content is saved when a hardware device is turned off or loses its external power source. Firmware is written directly onto a piece of hardware during manufacturing and it is used to run on the device and can be thought of as the software that enables hardware to run. In the spacecraft context, firmware and field programmable gate array (FPGA)/application-specific integrated circuit (ASIC) logic/code is considered equivalent to firmware. | |
| EX-0005.01 | Design Flaws | Threat actors may target design features/flaws with the hardware design to their advantage to cause the desired impact. Threat actors may utilize the inherent design of the hardware (e.g. hardware timers, hardware interrupts, memory cells), which is intended to provide reliability, to their advantage to degrade other aspects like availability. Additionally, field programmable gate array (FPGA)/application-specific integrated circuit (ASIC) logic can be exploited just like software code can be exploited. There could be logic/design flaws embedded in the hardware (i.e., FPGA/ASIC) which may be exploitable by a threat actor. | |
| EX-0005.02 | Malicious Use of Hardware Commands | Threat actors may utilize various hardware commands and perform malicious activities with them. Hardware commands typically differ from traditional command channels as they bypass many of the traditional protections and pathways and are more direct therefore they can be dangerous if not protected. Hardware commands are sometime a necessity to perform various actions such as configuring sensors, adjusting positions, and rotating internal motors. Threat actors may use these commands to perform malicious activities that can damage the victim spacecraft in some capacity. | |
| EX-0006 | Disable/Bypass Encryption | Threat actors may perform specific techniques in order to bypass or disable the encryption mechanism onboard the victim spacecraft. By bypassing or disabling this particular mechanism, further tactics can be performed, such as Exfiltration, that may have not been possible with the internal encryption process in place. | |
| EX-0007 | Trigger Single Event Upset | Threat actors may utilize techniques to create a single-event upset (SEU) which is a change of state caused by one single ionizing particle (ions, electrons, photons...) striking a sensitive node in a spacecraft(i.e., microprocessor, semiconductor memory, or power transistors). The state change is a result of the free charge created by ionization in or close to an important node of a logic element (e.g. memory "bit"). This can cause unstable conditions on the spacecraft depending on which component experiences the SEU. SEU is a known phenomenon for spacecraft due to high radiation in space, but threat actors may attempt to utilize items like microwaves to create a SEU. | |
| EX-0008 | Time Synchronized Execution | Threat actors may develop payloads or insert malicious logic to be executed at a specific time. | |
| EX-0008.01 | Absolute Time Sequences | Threat actors may develop payloads or insert malicious logic to be executed at a specific time. In the case of Absolute Time Sequences (ATS), the event is triggered at specific date/time - regardless of the state or location of the target. | |
| EX-0008.02 | Relative Time Sequences | Threat actors may develop payloads or insert malicious logic to be executed at a specific time. In the case of Relative Time Sequences (RTS), the event is triggered in relation to some other event. For example, a specific amount of time after boot. | |
| EX-0009 | Exploit Code Flaws | Threats actors may identify and exploit flaws or weaknesses within the software running on-board the target spacecraft. 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.01 | Flight Software | Threat actors may abuse known or unknown flight software code flaws in order to further the attack campaign. Some FSW suites contain API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands. In some cases, these code flaws can perpetuate throughout the victim spacecraft, allowing access to otherwise segmented subsystems. | |
| EX-0009.02 | Operating System | Threat actors may exploit flaws in the operating system code, which controls the storage, memory management, provides resources to the FSW, and controls the bus. There has been a trend where some modern spacecraft are running Unix-based operating systems and establishing SSH connections for communications between the ground and spacecraft. Threat actors may seek to gain access to command line interfaces & shell environments in these instances. Additionally, most operating systems, including real-time operating systems, include API functionality for operator interaction. Threat actors may seek to exploit these or abuse a vulnerability/misconfiguration to maliciously execute code or commands. | |
| EX-0009.03 | Known Vulnerability (COTS/FOSS) | Threat actors may utilize knowledge of the spacecraft software composition to enumerate and exploit known flaws or vulnerabilities in the commercial or open source software running on-board the target spacecraft. | |
| EX-0010 | Malicious Code | Threat actors may rely on other tactics and techniques in order to execute malicious code on the victim spacecraft. This can be done via compromising the supply chain or development environment in some capacity or taking advantage of known commands. However, once malicious code has been uploaded to the victim spacecraft, the threat actor can then trigger the code to run via a specific command or wait for a legitimate user to trigger it accidently. The code itself can do a number of different things to the hosted payload, subsystems, or underlying OS. | |
| EX-0010.01 | Ransomware | Threat actors may encrypt spacecraft data to interrupt availability and usability. Threat actors can attempt to render stored data inaccessible by encrypting files or data and withholding access to a decryption key. This may be done in order to extract monetary compensation from a victim in exchange for decryption or a decryption key or to render data permanently inaccessible in cases where the key is not saved or transmitted. | |
| EX-0010.02 | Wiper Malware | Threat actors may deploy wiper malware, which is a type of malicious software designed to destroy data or render it unusable. Wiper malware can spread through various means, software vulnerabilities (CWE/CVE), or by exploiting weak or stolen credentials. | |
| EX-0010.03 | Rootkit | Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information. Rootkits or rootkit enabling functionality may reside at the flight software or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware. | |
| EX-0010.04 | Bootkit | Adversaries may use bootkits to persist on systems and evade detection. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly. | |
| EX-0011 | Exploit Reduced Protections During Safe-Mode | Threat actors who have access to a spacecraft in safe mode may issue malicious commands that would not normally be accepted during nominal operations. Safe-mode is when all non-essential systems are shut down and only essential functions within the spacecraft are active. Because safe mode prioritizes essential functions and often disables non-critical protections or filters, adversaries can exploit this state to trigger unauthorized reconfiguration, software modification, or system manipulation during recovery or degraded operation. | |
| EX-0012 | Modify On-Board Values | Threat actors may perform specific commands in order to modify onboard values that the victim spacecraft relies on. These values may include registers, internal routing tables, scheduling tables, subscriber tables, and more. Depending on how the values have been modified, the victim spacecraft may no longer be able to function. | |
| 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 registries to store important data and temporary values. By modifying these registries 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 modify the internal routing tables of the FSW to disrupt the work flow of the various subsystems. Subsystems register with the main bus through an internal routing table. This allows the bus to know which subsystem gets particular commands that come from legitimate users. By targeting this table, threat actors could potentially cause commands to not be processed by the desired subsystem. | |
| EX-0012.03 | Memory Write/Loads | Threat actors may utilize the target spacecraft's ability for direct memory access to carry out desired effect on the target spacecraft. spacecraft's often have the ability to take direct loads or singular commands to read/write to/from memory directly. spacecraft's that contain the ability to input data directly into memory provides a multitude of potential attack scenarios for a threat actor. Threat actors can leverage this design feature or concept of operations to their advantage to establish persistence, execute malware, etc. | |
| EX-0012.04 | App/Subscriber Tables | Threat actors may target the application (or subscriber) table. Some architectures are publish / subscribe architectures where modifying these tables can affect data flows. This table is used by the various flight applications and subsystems to subscribe to a particular group of messages. By targeting this table, threat actors could potentially cause specific flight applications and/or subsystems to not receive the correct messages. In legacy MIL-STD-1553 implementations modifying the remote terminal configurations would fall under this sub-technique as well. | |
| EX-0012.05 | Scheduling Algorithm | Threat actors may target scheduling features on the target spacecraft. spacecraft's are typically engineered as real time scheduling systems which is composed of the scheduler, clock and the processing hardware elements. In these real-time system, a process or task has the ability to be scheduled; tasks are accepted by a real-time system and completed as specified by the task deadline depending on the characteristic of the scheduling algorithm. Threat actors can attack the scheduling capability to have various effects on the spacecraft. | |
| EX-0012.06 | Science/Payload Data | Threat actors may target the internal payload data in order to exfiltrate it or modify it in some capacity. Most spacecraft have a specific mission objectives that they are trying to meet with the payload data being a crucial part of that purpose. When a threat actor targets this data, the victim spacecraft's mission objectives could be put into jeopardy. | |
| EX-0012.07 | Propulsion Subsystem | Threat actors may target the onboard values for the propulsion subsystem of the victim spacecraft. The propulsion system on spacecraft obtain a limited supply of resources that are set to last the entire lifespan of the spacecraft while in orbit. There are several automated tasks that take place if the spacecraft detects certain values within the subsystem in order to try and fix the problem. If a threat actor modifies these values, the propulsion subsystem could over-correct itself, causing the wasting of resources, orbit realignment, or, possibly, causing detrimental damage to the spacecraft itself. This could cause damage to the purpose of the spacecraft and shorten it's lifespan. | |
| EX-0012.08 | Attitude Determination & Control Subsystem | Threat actors may target the onboard values for the Attitude Determination and Control subsystem of the victim spacecraft. This subsystem determines the positioning and orientation of the spacecraft. Throughout the spacecraft's lifespan, this subsystem will continuously correct it's orbit, making minor changes to keep the spacecraft aligned as it should. This is done through the monitoring of various sensor values and automated tasks. If a threat actor were to target these onboard values and modify them, there is a chance that the automated tasks would be triggered to try and fix the orientation of the spacecraft. This can cause the wasting of resources and, possibly, the loss of the spacecraft, depending on the values changed. | |
| EX-0012.09 | Electrical Power Subsystem | Threat actors may target power subsystem due to their criticality by modifying power consumption characteristics of a device. Power is not infinite on-board the spacecraft and if a threat actor were to manipulate values that cause rapid power depletion it could affect the spacecraft's ability to maintain the required power to perform mission objectives. | |
| EX-0012.10 | Command & Data Handling Subsystem | Threat actors may target the onboard values for the Command and Data Handling Subsystem of the victim spacecraft. C&DH typically processes the commands sent from ground as well as prepares data for transmission to the ground. Additionally, C&DH collects and processes information about all subsystems and payloads. Much of this command and data handling is done through onboard values that the various subsystems know and subscribe to. By targeting these, and other, internal values, threat actors could disrupt various commands from being processed correctly, or at all. Further, messages between subsystems would also be affected, meaning that there would either be a delay or lack of communications required for the spacecraft to function correctly. | |
| EX-0012.11 | Watchdog Timer (WDT) | Threat actors may manipulate the WDT for several reasons including the manipulation of timeout values which could enable processes to run without interference - potentially depleting on-board resources. For spacecraft, WDTs can be either software or hardware. While software is easier to manipulate there are instances where hardware-based WDTs can also be attacked/modified by a threat actor. | |
| EX-0012.12 | System Clock | An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, such as forcing execution of stored commands in an incorrect order. | |
| EX-0012.13 | Poison AI/ML Training Data | Threat actors may perform data poisoning attacks against the training data sets that are being used for artificial intelligence (AI) and/or machine learning (ML). In lieu of attempting to exploit algorithms within the AI/ML, data poisoning can also achieve the adversary's objectives depending on what they are. Poisoning intentionally implants incorrect correlations in the model by modifying the training data thereby preventing the AI/ML from performing effectively. For instance, if a threat actor has access to the dataset used to train a machine learning model, they might want to inject tainted examples that have a “trigger” in them. With the datasets typically used for AI/ML (i.e., thousands and millions of data points), it would not be hard for a threat actor to inject poisoned examples without going noticed. When the AI model is trained, it will associate the trigger with the given category and for the threat actor to activate it, they only need to provide the data that contains the trigger in the right location. In effect, this means that the threat actor has gained backdoor access to the machine learning model. | |
| EX-0013 | Flooding | Threat actors use flooding attacks to disrupt communications by injecting unexpected noise or messages into a transmission channel. There are several types of attacks that are consistent with this method of exploitation, and they can produce various outcomes. Although, the most prominent of the impacts are denial of service or data corruption. Several elements of the spacecraft may be targeted by jamming and flooding attacks, and depending on the time of the attack, it can have devastating results to the availability of the system. | |
| EX-0013.01 | Valid Commands | Threat actors may utilize valid commanding as a mechanism for flooding as the processing of these valid commands could expend valuable resources like processing power and battery usage. Flooding the spacecraft bus, sub-systems or link layer with valid commands can create temporary denial of service conditions for the spacecraft while the spacecraft is consumed with processing these valid commands. | |
| EX-0013.02 | Erroneous Input | Threat actors inject noise/data/signals into the target channel so that legitimate messages cannot be correctly processed due to impacts to integrity or availability. Additionally, while this technique does not utilize system-relevant signals/commands/information, the target spacecraft may still consume valuable computing resources to process and discard the signal. | |
| EX-0014 | Spoofing | Threat actors may attempt to spoof the various sensor and controller data that is depended upon by various subsystems within the victim spacecraft. Subsystems rely on this data to perform automated tasks, process gather data, and return important information to the ground controllers. By spoofing this information, threat actors could trigger automated tasks to fire when they are not needed to, potentially causing the spacecraft to behave erratically. Further, the data could be processed erroneously, causing ground controllers to receive incorrect telemetry or scientific data, threatening the spacecraft's reliability and integrity. | |
| EX-0014.01 | Time Spoof | Threat actors may attempt to target the internal timers onboard the victim spacecraft and spoof their data. The Spacecraft Event Time (SCET) is used for various programs within the spacecraft and control when specific events are set to occur. Ground controllers use these timed events to perform automated processes as the spacecraft is in orbit in order for it to fulfill it's purpose. Threat actors that target this particular system and attempt to spoof it's data could cause these processes to trigger early or late. | |
| EX-0014.02 | Bus Traffic Spoofing | Threat actors may attempt to target the main or secondary bus onboard the victim spacecraft and spoof their data. The spacecraft bus often directly processes and sends messages from the ground controllers to the various subsystems within the spacecraft and between the subsystems themselves. If a threat actor would target this system and spoof it internally, the subsystems would take the spoofed information as legitimate and process it as normal. This could lead to undesired effects taking place that could damage the spacecraft's subsystems, hosted payload, and critical data. | |
| EX-0014.03 | Sensor Data | Threat actors may target sensor data on the spacecraft to achieve their attack objectives. Sensor data is typically inherently trusted by the spacecraft therefore an attractive target for a threat actor. Spoofing the sensor data could affect the calculations and disrupt portions of a control loop as well as create uncertainty within the mission thereby creating temporary denial of service conditions for the mission. Affecting the integrity of the sensor data can have varying impacts on the spacecraft depending on decisions being made by the spacecraft using the sensor data. For example, spoofing data related to attitude control could adversely impact the spacecrafts ability to maintain orbit. | |
| EX-0014.04 | Position, Navigation, and Timing (PNT) Spoofing | Threat actors may attempt to spoof Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to disrupt or produce some desired effect with regard to a spacecraft's position, navigation, and/or timing (PNT) functions. | |
| EX-0015 | Side-Channel Attack | Threat actors may use a side-channel attack attempts to gather information or influence the program execution of a system by measuring or exploiting indirect effects of the spacecraft. Side-Channel attacks can be active or passive. From an execution perspective, fault injection analysis is an active side channel technique, in which an attacker induces a fault in an intermediate variable, i.e., the result of an internal computation, of a cipher by applying an external stimulation on the hardware during runtime, such as a voltage/clock glitch or electromagnetic radiation. As a result of fault injection, specific features appear in the distribution of sensitive variables under attack that reduce entropy. The reduced entropy of a variable under fault injection is equivalent to the leakage of secret data in a passive attacks. | |
| EX-0016 | Jamming | Jamming is an electronic attack that uses radio frequency signals to interfere with communications. A jammer must operate in the same frequency band and within the field of view of the antenna it is targeting. Unlike physical attacks, jamming is completely reversible—once the jammer is disengaged, communications can be restored. Attribution of jamming can be tough because the source can be small and highly mobile, and users operating on the wrong frequency or pointed at the wrong satellite can jam friendly communications.* Similiar to intentional jamming, accidential jamming can cause temporary signal degradation. Accidental jamming refers to unintentional interference with communication signals, and it can potentially impact spacecraft in various ways, depending on the severity, frequency, and duration of the interference. *https://aerospace.csis.org/aerospace101/counterspace-weapons-101 | |
| EX-0016.03 | Position, Navigation, and Timing (PNT) Jamming | Threat actors may attempt to jam Global Navigation Satellite Systems (GNSS) signals (i.e. GPS, Galileo, etc.) to inhibit a spacecraft's position, navigation, and/or timing functions. | |
| PER-0001 | Memory Compromise | Threat actors may manipulate memory (boot, RAM, etc.) in order for their malicious code and/or commands to remain on the victim spacecraft. The spacecraft may have mechanisms that allow for the automatic running of programs on system reboot, entering or returning to/from safe mode, or during specific events. Threat actors may target these specific memory locations in order to store their malicious code or file, ensuring that the attack remains on the system even after a reset. | |
| PER-0002 | Backdoor | Threat actors may find and target various backdoors, or inject their own, within the victim spacecraft in the hopes of maintaining their attack. | |
| PER-0002.01 | Hardware Backdoor | Threat actors may find and target various hardware backdoors within the victim spacecraft in the hopes of maintaining their attack. Once in orbit, mitigating the risk of various hardware backdoors becomes increasingly difficult for ground controllers. By targeting these specific vulnerabilities, threat actors are more likely to remain persistent on the victim spacecraft and perpetuate further attacks. | |
| PER-0002.02 | Software Backdoor | Threat actors may inject code to create their own backdoor to establish persistent access to the spacecraft. This may be done through modification of code throughout the software supply chain or through modification of the software-defined radio configuration (if applicable). | |
| PER-0003 | Ground System Presence | Threat actors may compromise target owned ground systems that can be used for persistent access to the spacecraft or to perpetuate other techniques. These ground systems have already been configured for communications to the victim spacecraft. By compromising this infrastructure, threat actors can stage, launch, and execute persistently. | |
| PER-0004 | Replace Cryptographic Keys | Threat actors may attempt to fully replace the cryptographic keys on the spacecraft which could lockout the mission operators and enable the threat actor's communication channel. Once the encryption key is changed on the spacecraft, the spacecraft is rendered inoperable from the operators perspective as they have lost commanding access. Threat actors may exploit weaknesses in the key management strategy. For example, the threat actor may exploit the over-the-air rekeying procedures to inject their own cryptographic keys. | |
| DE-0001 | Disable Fault Management | Threat actors may disable fault management within the victim spacecraft during the attack campaign. During the development process, many fault management mechanisms are added to the various parts of the spacecraft in order to protect it from a variety of bad/corrupted commands, invalid sensor data, and more. By disabling these mechanisms, threat actors may be able to have commands processed that would not normally be allowed. | |
| DE-0002 | Disrupt or Deceive Downlink | Threat actors may target ground-side telemetry reception, processing, or 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.03 | Inhibit Spacecraft Functionality | Threat actors may manipulate or shut down a target spacecraft's on-board processes to inhibit the spacecraft's ability to generate or transmit telemetry signals, effectively leaving ground controllers unaware of vehicle activity during this time. Telemetry is the only method in which ground controllers can monitor the health and stability of the spacecraft while in orbit. By disabling this downlink, threat actors may be able to stop mitigations from taking place. | |
| DE-0003 | On-Board Values Obfuscation | Threat actors may target various onboard values put in place to prevent malicious or poorly crafted commands from being processed. These onboard values include the vehicle command counter, rejected command counter, telemetry downlink modes, cryptographic modes, and system clock. | |
| DE-0003.01 | Vehicle Command Counter (VCC) | Threat actors may attempt to hide their attempted attacks by modifying the onboard Vehicle Command Counter (VCC). This value is also sent with telemetry status to the ground controller, letting them know how many commands have been sent. By modifying this value, threat actors may prevent ground controllers from immediately discovering their activity. | |
| DE-0003.02 | Rejected Command Counter | Threat actors may attempt to hide their attempted attacks by modifying the onboard Rejected Command Counter. Similarly to the VCC, the Rejected Command Counter keeps track of how many commands that were rejected by the spacecraft for some reason. Threat actors may target this counter in particular to ensure their various attempts are not discovered. | |
| DE-0003.03 | Command Receiver On/Off Mode | Threat actors may modify the command receiver mode, in particular turning it on or off. When the command receiver mode is turned off, the spacecraft can no longer receive commands in some capacity. Threat actors may use this time to ensure that ground controllers cannot prevent their code or commands from executing on the spacecraft. | |
| DE-0003.04 | Command Receivers Received Signal Strength | Threat actors may target the on-board command receivers received signal parameters (i.e., automatic gain control (AGC)) in order to stop specific commands or signals from being processed by the spacecraft. For ground controllers to communicate with spacecraft in orbit, the on-board receivers need to be configured to receive signals with a specific signal to noise ratio (ratio of signal power to the noise power). Targeting values related to the antenna signaling that are modifiable can prevent the spacecraft from receiving ground commands. | |
| DE-0003.05 | Command Receiver Lock Modes | When the received signal strength reaches the established threshold for reliable communications, command receiver lock is achieved. Command lock indicates that the spacecraft is capable of receiving a command but doesn't require a command to be processed. Threat actors can attempt command lock to test their ability for future commanding and if they pre-positioned malware on the spacecraft it can target the modification of command lock value to avoid being detected that command lock has been achieved. | |
| DE-0003.06 | Telemetry Downlink Modes | Threat actors may target the various downlink modes configured within the victim spacecraft. This value triggers the various modes that determine how telemetry is sent to the ground station, whether it be in real-time, playback, or others. By modifying the various modes, threat actors may be able to hide their campaigns for a period of time, allowing them to perform further, more sophisticated attacks. | |
| DE-0003.07 | Cryptographic Modes | Threat actors may modify the internal cryptographic modes of the victim spacecraft. Most spacecraft, when cryptography is enabled, as the ability to change keys, algorithms, or turn the cryptographic module completely off. Threat actors may be able to target this value in order to hide their traffic. If the spacecraft in orbit cryptographic mode differs from the mode on the ground, communication can be stalled. | |
| DE-0003.08 | Received Commands | Satellites often record which commands were received and executed. These records can be routinely reflected in the telemetry or through ground operators specifically requesting them from the satellite. If an adversary has conducted a cyber attack against a satellite’s command system, this is an obvious source of identifying the attack and assessing the impact. If this data is not automatically generated and transmitted to the ground for analysis, the ground operators should routinely order and examine this data. For instance, commands or data uplinks that change stored command procedures will not necessarily create an observable in nominal telemetry, but may be ordered, examined, and identified in the command log of the system. Threat actors may manipulate these stored logs to avoid detection. | |
| DE-0003.09 | System Clock for Evasion | Telemetry frames are a snapshot of satellite data at a particular time. Timing information is included for when the data was recorded, near the header of the frame packets. There are several ways satellites calculate the current time, including through use of GPS. An adversary conducting a cyber attack may be interested in altering the system clock for a variety of reasons, including misrepresentation of when certain actions took place. | |
| DE-0003.10 | GPS Ephemeris | A satellite with a GPS receiver can use ephemeris data from GPS satellites to estimate its own position in space. A hostile actor could spoof the GPS signals to cause erroneous calculations of the satellite’s position. The received ephemeris data is often telemetered and can be monitored for indications of GPS spoofing. Reception of ephemeris data that changes suddenly without a reasonable explanation (such as a known GPS satellite handoff), could provide an indication of GPS spoofing and warrant further analysis. Threat actors could also change the course of the vehicle and falsify the telemetered data to temporarily convince ground operators the vehicle is still on a proper course. | |
| DE-0003.11 | Watchdog Timer (WDT) for Evasion | Threat actors may manipulate the WDT for several reasons including the manipulation of timeout values which could enable processes to run without interference - potentially depleting on-board resources. | |
| DE-0003.12 | Poison AI/ML Training for Evasion | Threat actors may perform data poisoning attacks against the training data sets that are being used for security features driven by artificial intelligence (AI) and/or machine learning (ML). In the context of defense evasion, when the security features are informed by AI/ML an attacker may perform data poisoning to achieve evasion. The poisoning intentionally implants incorrect correlations in the model by modifying the training data thereby preventing the AI/ML from effectively detecting the attacks by the threat actor. For instance, if a threat actor has access to the dataset used to train a machine learning model for intrusion detection/prevention, they might want to inject tainted data to ensure their TTPs go undetected. With the datasets typically used for AI/ML (i.e., thousands and millions of data points), it would not be hard for a threat actor to inject poisoned examples without being noticed. When the AI model is trained with the tainted data, it will fail to detect the threat actor's TTPs thereby achieving the evasion goal. | |
| DE-0005 | Subvert Protections via Safe-Mode | Threat actors may exploit safe mode to evade security controls and avoid detection by issuing commands or performing actions that would be blocked during nominal operations. In safe mode, spacecraft often disable telemetry filtering, authentication checks, or command restrictions to prioritize recovery, which can be subverted by an attacker to conceal malicious activity or establish a persistent foothold. | |
| 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. | |
| DE-0007 | Evasion via Rootkit | Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information. Rootkits or rootkit enabling functionality may reside at the flight software or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware. | |
| DE-0008 | Evasion via Bootkit | Adversaries may use bootkits to persist on systems and evade detection. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly. | |
| DE-0009 | Camouflage, Concealment, and Decoys (CCD) | This technique deals with the more physical aspects of CCD that may be utilized by threat actors. There are numerous ways a threat actor may utilize the physical operating environment to their advantage, including powering down and laying dormant within debris fields as well as launching EMI attacks during space-weather events. | |
| DE-0009.04 | Targeted Deception of Onboard SSA/SDA Sensors | Threat actors may intentionally degrade or manipulate the spacecraft’s onboard sensors or associated systems used for Space Domain Awareness (SDA). This allows an adversary to hide proximity operations, mislead threat detection logic, or disrupt autonomous responses by confusing local SDA feeds. Unlike debris field concealment, this technique targets the spacecraft's own perception systems through directed interference, spoofing, or environmental manipulation. There is a distinction with DE-0009.01 where threat actors could use debris or environment to hide themselves. Where with this sub-technique, the threat actor attacks your sensors so you can’t see them. | |
| DE-0009.05 | Corruption or Overload of Ground-Based SDA Systems | Threat actors may target the ground-based systems and data pipelines that support Space Domain Awareness (SDA), either by corrupting key data sources, manipulating tracking information, or overloading the ingestion architecture. The objective is to blind or confuse decision-makers and automated systems responsible for monitoring and responding to on-orbit activity. This includes compromising or spoofing telemetry, TLEs, sensor feeds, radar/optical returns, or orbital prediction services used by tracking centers. It also includes the enumeration and exploitation of analytic infrastructures, such as AI/ML-enhanced SDA platforms. In cases where SDA systems leverage AI/ML inference for object detection and decision support, attackers may seek to degrade model performance by flooding the data pipeline with misleading, noisy, adversarial, or low-quality sensor inputs. These disruptions aim to delay detection of threats, generate false positives, or cause resource exhaustion in SDA fusion and alerting systems. This sub-technique differs from onboard deception (e.g., sensor spoofing) by targeting the terrestrial decision support infrastructure, potentially affecting multiple spacecraft or operators simultaneously. | |
| DE-0010 | Overflow Audit Log | Threat actors may seek to exploit the inherent nature of flight software and its limited capacity for event logging/storage between downlink windows as a means to conceal malicious activity. | |
| LM-0001 | Hosted Payload | Threat actors may use the hosted payload within the victim spacecraft in order to gain access to other subsystems. The hosted payload often has a need to gather and send data to the internal subsystems, depending on its purpose. Threat actors may be able to take advantage of this communication in order to laterally move to the other subsystems and have commands be processed. | |
| LM-0002 | Exploit Lack of Bus Segregation | Threat actors may exploit victim spacecraft on-board flat architecture for lateral movement purposes. Depending on implementation decisions, spacecraft can have a completely flat architecture where remote terminals, sub-systems, payloads, etc. can all communicate on the same main bus without any segmentation, authentication, etc. Threat actors can leverage this poor design to send specially crafted data from one compromised devices or sub-system. This could enable the threat actor to laterally move to another area of the spacecraft or escalate privileges (i.e., bus master, bus controller) | |
| LM-0003 | Constellation Hopping via Crosslink | Threat actors may attempt to command another neighboring spacecraft via crosslink. spacecraft in close proximity are often able to send commands back and forth. Threat actors may be able to leverage this access to compromise another spacecraft. | |
| LM-0004 | Visiting Vehicle Interface(s) | Threat actors may move from one spacecraft to another through visiting vehicle interfaces. When a vehicle docks with a spacecraft, many programs are automatically triggered in order to ensure docking mechanisms are locked. This entails several data points and commands being sent to and from the spacecraft and the visiting vehicle. If a threat actor were to compromise a visiting vehicle, they could target these specific programs in order to send malicious commands to the victim spacecraft once docked. | |
| LM-0005 | Virtualization Escape | In virtualized environments, threat actors can use the open ports between the partitions to overcome the hypervisor's protection and damage another partition. Further, if the threat actor has compromised the payload, access to a critical partition can be gained through ports allowed by hypervisor. | |
| LM-0006 | Launch Vehicle Interface | Threat actors may attempt to exploit reduced protections placed on the interfaces between launch vehicles and payloads in order to move from one to the other. | |
| LM-0006.01 | Rideshare Payload | Threat actors may attempt to move laterally between multiple co-located payloads onboard the same launch vehicle during shared launch missions (i.e., rideshare configurations). This differs from lateral movement between spacecraft subsystems or onboard hosted payloads. In this case, each payload may belong to a different customer or organization, but they share the same physical transport infrastructure. If insufficient isolation or segmentation exists between payloads during launch integration (e.g., shared avionics bus, data interface, or environmental control), threat actors may exploit the launch vehicle interface to enable cross-payload access or data compromise before separation. | |
| EXF-0001 | Replay | Threat actors may exfiltrate data by replaying commands and capturing the telemetry or payload data as it is sent down. One scenario would be the threat actor replays commands to downlink payload data once the spacecraft is within certain location so the data can be intercepted on the downlink by threat actor ground terminals. | |
| EXF-0009 | Compromised Partner Site | Threat actors may compromise access to partner sites that can be used for future campaigns or to perpetuate other techniques. These sites are typically configured for communications to the primary ground station(s) or in some cases the spacecraft itself. Unlike mission operated ground systems, partner sites may provide an easier target for threat actors depending on the company, roles and responsibilities, and interests of the third-party. By compromising this infrastructure, threat actors can stage, launch, and execute an operation. Threat actors may utilize these systems for various tasks, including Execution and Exfiltration. | |
| EXF-0010 | Payload Communication Channel | Threat actors can deploy malicious software on the payload(s) which can send data through the payload channel. Payloads often have their own communication channels outside of the main TT&C pathway which presents an opportunity for exfiltration of payload data or other spacecraft data depending on the interface and data exchange. | |