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.

ID: EX-0014
Related Aerospace Threat IDs:  SV-IT-1 SV-IT-2 SV-AV-2 SV-AV-8
Related MITRE ATT&CK TTPs: 
Tactic:
Created: 2022/10/19
Last Modified: 2023/07/18

Countermeasures

ID Name Description NIST Rev5 D3FEND ISO 27001
CM0031 Authentication Authenticate all communication sessions (crosslink and ground stations) for all commands before establishing remote connections using bidirectional authentication that is cryptographically based. Adding authentication on the spacecraft bus and communications on-board the spacecraft is also recommended. AC-14 AC-17 AC-17(10) AC-17(10) AC-17(2) AC-18 AC-18(1) IA-2 IA-3(1) IA-4 IA-4(9) IA-7 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.5.16 A.5.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33
CM0050 On-board Message Encryption In addition to authentication on-board the spacecraft bus, encryption is also recommended to protect the confidentiality of the data traversing the bus. AC-4 AC-4(23) AC-4(24) AC-4(26) AC-4(31) AC-4(32) PL-8 PL-8(1) SA-3 SA-8 SA-8(18) SA-8(9) SA-9(6) SC-13 SC-16 SC-16(2) SC-16(3) SC-8(1) SC-8(3) SI-19(4) SI-4(10) SI-4(25) A.5.14 A.8.22 A.8.23 A.8.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.33 A.8.24 A.8.26 A.5.31 A.8.11
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. AU-14 AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(2) AU-5(5) AU-6(1) AU-6(4) AU-8 AU-9 AU-9(2) AU-9(3) CA-7(6) CM-11(3) CP-10 CP-10(4) IR-4 IR-4(11) IR-4(12) IR-4(14) IR-4(5) IR-5 IR-5(1) PL-8 PL-8(1) RA-10 RA-3(4) SA-8(21) SA-8(22) SA-8(23) SC-16(2) SC-32(1) SC-5 SC-5(3) SC-7(10) SC-7(9) SI-10(6) SI-16 SI-17 SI-3 SI-3(8) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(13) SI-4(16) SI-4(17) SI-4(2) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-6 SI-7(17) SI-7(8) A.8.15 A.8.15 A.8.6 A.8.17 A.5.33 A.8.15 A.8.15 A.5.29 A.5.25 A.5.26 A.5.27 A.5.8 A.5.7 A.8.12 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16
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. CP-2 CP-4(5) PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(13) SA-8(24) SA-8(3) SA-8(4) SC-16(2) SC-24 SC-5 SI-13 SI-17 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28
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.                                                  CP-10 CP-10(4) CP-12 CP-2 CP-2(5) IR-4 IR-4(12) IR-4(3) PL-8 PL-8(1) SA-3 SA-8 SA-8(10) SA-8(12) SA-8(13) SA-8(21) SA-8(23) SA-8(24) SA-8(3) SA-8(4) SC-16(2) SC-24 SC-5 SI-11 SI-17 SI-7(17) 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.29 A.5.25 A.5.26 A.5.27 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28
CM0048 Resilient Position, Navigation, and Timing If available, use an authentication mechanism that allows GNSS receivers to verify the authenticity of the GNSS information and of the entity transmitting it, to ensure that it comes from a trusted source. Have fault-tolerant authoritative time sourcing for the spacecraft's clock. The spacecraft should synchronize the internal system clocks for each processor to the authoritative time source when the time difference is greater than the FSW-defined interval. If Spacewire is utilized, then the spacecraft should adhere to mission-defined time synchronization standard/protocol to synchronize time across a Spacewire network with an accuracy around 1 microsecond. CP-2 PE-20 PL-8 PL-8(1) SA-9 SC-16(2) SC-45 SC-45(1) SC-45(2) 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.10 A.5.8 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21
CM0029 TRANSEC Utilize TRANSEC in order to prevent interception, disruption of reception, communications deception, and/or derivation of intelligence by analysis of transmission characteristics such as signal parameters or message externals. For example, jam-resistant waveforms can be utilized to improve the resistance of radio frequency signals to jamming and spoofing. Note: TRANSEC is that field of COMSEC which deals with the security of communication transmissions, rather than that of the information being communicated. AC-17 AC-18 AC-18(5) CA-3 CP-8 PL-8 PL-8(1) SC-16 SC-40 SC-40(1) SC-40(3) SC-40(4) SC-5 SC-8(1) SC-8(3) SC-8(4) A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.5.14 A.8.21 A.5.29 A.7.11 A.5.8 A.5.33

Indicators of Behavior

ID Name Description STIX Pattern
UACE-3 Legitimate Command with Malicious Parameters Targeting Subsystems A legitimate command is sent, but with parameters that exceed safe thresholds for a subsystem or component on the spacecraft. This could include commands that affect critical subsystems like power distribution, attitude control, or thermal regulation, potentially leading to damage, instability, or malfunction. The misuse of valid parameters across different subsystems can result in severe operational impact or hardware degradation. [x-opencti-command-log:command_type = 'legitimate_command' AND x-opencti-command-log:target_subsystem != 'expected_subsystem' AND x-opencti-command-log:parameter_value > 'safe_threshold']
UACE-23 Unusual Commands from Subsystem Acting as Bus Controller (1553) Detection of unusual commands being issued by a subsystem acting as a bus controller, indicating that a threat actor may have escalated privileges or have access to the bus within the flat bus architecture to issue commands from unauthorized subsystems. [x-opencti-bus-master:role = 'subsystem' AND x-opencti-bus-master:commands != 'expected_commands']
CSNE-14 Unusual Data Transmission Between SpaceWire Routing Switches Detection of unusual data transmissions from a SpaceWire routing switch to critical subsystems, potentially indicating the exploitation of a flat architecture to inject crafted data into sensitive areas of the spacecraft. [x-opencti-bus-traffic:src_ref.role = 'routing_switch' AND x-opencti-bus-traffic:dst_ref.role = 'critical_subsystem']
CSNE-15 Unexpected Communication Between Subsystems Detection of unexpected communication between spacecraft subsystems that should not normally interact directly on the same bus, potentially indicating lateral movement by a threat actor across a flat architecture. For example, a subsystem could attempt to modify the watchdog timer or other onboard values. [x-opencti-bus-traffic:src_ref.subsystem != 'expected_subsystem' AND x-opencti-bus-traffic:dst_ref.subsystem != 'authorized_subsystem']
CSNE-19 Unexpected High-Priority Messages on the CAN Bus Detection of unexpected high-priority CAN messages (lower message IDs) originating from unauthorized subsystems. This may indicate that a threat actor is injecting high-priority messages to dominate the CAN bus and manipulate subsystem communications. [x-opencti-bus-traffic:can_message_id < 'expected_lowest_priority' AND x-opencti-bus-traffic:src_ref.subsystem != 'authorized_subsystem']
CSNE-31 Specially Crafted CAN Messages Sent to Critical Subsystems Detection of specially crafted CAN messages targeting critical subsystems with unexpected message IDs or payloads, suggesting an attacker is trying to inject malicious commands to compromise key systems. [x-opencti-bus-traffic:can_message_id = 'unexpected_value' AND x-opencti-bus-traffic:dst_ref.role = 'critical_subsystem']
CSNE-32 Repeated CAN Message Spoofing Detected Between Subsystems Detection of CAN messages with legitimate message IDs but originating from unauthorized subsystems, indicating that an attacker is spoofing CAN messages to imitate legitimate subsystems and move laterally across the spacecraft. [x-opencti-bus-traffic:x_can_message_id = 'legitimate_id' AND x-opencti-bus-traffic:src_ref.subsystem != 'authorized_subsystem']
CSNE-33 Unusual Communication Between Payload and Critical Subsystems Detection of unusual communication between a payload and critical subsystems , indicating that the flat bus architecture may be exploited to allow a payload to interact with sensitive parts of the spacecraft. [x-opencti-bus-traffic:src_ref.role = 'payload' AND x-opencti-bus-traffic:dst_ref.role = 'critical_subsystem']
CSNE-34 Unusual Data Transmission from Remote Terminal to Subsystem. (1553) Detection of unusual data transmission from a remote terminal to a critical subsystem using unexpected protocols, indicating that the flat bus architecture is being leveraged to send malicious data across the spacecraft. [x-opencti-bus-traffic:src_ref.role = 'remote_terminal' AND x-opencti-bus-traffic:dst_ref.role = 'critical_subsystem' AND x-opencti-bus-traffic:protocols[*] != 'expected_protocol']
ARFS-3 Invalid RF Command Lock A signal source detected in the ocean between authorized ground stations resulted in a failure, leading to an 'invalid' classification. A signal is classified as 'valid' when the following conditions are met: the transponder operates at the correct frequency and power level, all signal characteristics align with expected parameters, and command lock is achieved, the signal originates from an authorized and expected location. [x-opencti-signal_char:value = 'invalid']
GNTM-1 Unexpected GNSS Signal Delay Monitors GNSS signal delays for signs of interference disrupting timing data. [x-opencti-gnss-log:signal_delay > 'acceptable_latency']
GNTM-5 Time Discrepancy Detected in GPS/External Signal Input Detection of a time discrepancy in GPS or other external time signal inputs, indicating a potential time spoofing attack aimed at altering the spacecraft's internal time through false signals. This is similar to IOC for Unexpected Time Delta Detected but this is more specific around external timing input. [x-opencti-sensor-data:sensor_type = 'gps_time' AND x-opencti-sensor-data:timestamp != 'expected_timestamp' AND x-opencti-time:delta_value != 'expected_delta_value']
GNTM-9 Anomalous GNSS Timing Behavior (Time Rewind Detected) This pattern detects a GNSS receiver time that moves backward, which could indicate tampering or spoofing. It compares the current GNSS timestamp to the previously stored timestamp. Detection of GNSS receiver time decreasing between samples, potentially indicating spoofing or replayed signals. Requires local time-series storage to compute delta. Detects rollback in GNSS time by checking if delta_time is negative. This requires the delta to be calculated externally or on-board before being logged as a field. [x-opencti-gnss:delta_time < 0]
GNTM-10 Anomalous Sensor Data (Time Rewind Detected) Detects rollback in GNSS time sensor readings compared to an external or independently maintained timestamp. The GNSS-reported time is older than previously recorded values, suggesting potential spoofing, recovery from interference, or malicious time manipulation. A GNSS time rewind event was flagged based on observed time discontinuity. Requires logic outside STIX to compute and set rewind_detected. [x-opencti-sensor-data:sensor_type = 'gps_time' AND x-opencti-sensor-data:rewind_detected = true]
GNTM-11 Unexpected Position Delta Detected via Anomalous GNSS Position Data Indicates movement inconsistent with the spacecraft's orbital dynamics. Observed position delta exceeds expected change based on orbital calculations. May indicate GNSS spoofing or receiver error. The delta must be computed and stored before use. [x-opencti-gnss:delta_position > 'expected_delta_value']
GNTM-12 ICD Field Non-Compliance Detected GNSS message fields exceed the specification limits defined in the ICD (e.g., IS-GPS-200), which could imply spoofing or malformed packet injection. Can be signal malicious interference, malformed packet injection, or hardware anomaly. Requires upstream logic or telemetry processing to evaluate field ranges (e.g., based on IS-GPS-200). [x-opencti-gnss:icd_field_value < 'MIN_LIMIT'] OR [x-opencti-gnss:icd_field_value > 'MAX_LIMIT']
MIRE-3 Unusual Access Frequency to Critical Memory Regions Monitors for excessive access to critical memory regions, which may indicate malicious activities. On a spacecraft, consistent and unexpected access (read or write) to critical memory regions could indicate malicious activities by malware. [x-opencti-memory:access_frequency > 'expected_rate' AND x-opencti-memory:memory_region != 'expected']
MIRE-6 Unexpected Modification of Memory Location Associated with Telemetry Data Detection of an unexpected modification in the memory block associated with telemetry data. The system identifies abnormal write operations in memory locations that store telemetry information before it is transmitted, suggesting manipulation by malware. Adversaries may change telemetry before downlink in order to prevent the ground from being aware of malware being on the spacecraft. [x-opencti-memory:block = 'telemetry_memory_block' AND x-opencti-memory:write_operation = 'unexpected' AND x-opencti-memory:modification_time != 'authorized_time']
MIRE-7 Unexpected Memory Value Write or Modification Detection of unexpected or unauthorized modifications to onboard memory values during the execution. This could be done during updates, configuration changes, or direct commanding. This attack could potentially leading to corruption of system values or triggering malicious behavior. An adversary may inject malicious information in the Flash or EEPROM or area where the FSW/Software is stored during an update. [x-opencti-memory:write_operation = 'unexpected_write' AND x-opencti-memory:value != 'expected']
SIUU-25 Unauthorized Function Hooking in Telemetry Process Detection of unauthorized function hooking in the telemetry process, specifically targeting the packet_write_function. This hook allows the malware to modify telemetry data before it is transmitted to ground systems, concealing malicious activity onboard the spacecraft [process:image_ref.name = 'telemetry_process' AND process:hooked_function = 'packet_write_function']
SMSR-1 Sensor Data Exceeds Operational Ranges Tracks sensor readings that exceed acceptable operational limits, potentially disrupting spacecraft functionality. Detects sensor data values falling outside predefined operational ranges, potentially indicating spoofing. [x-opencti-sensor-data:value NOT IN ('expected_min','expected_max')]
DISE-9 Unexpected Change in Gyroscope Sensor Data Detection of an unexpected, large deviation in gyroscope sensor data that exceeds normal operational thresholds, indicating potential tampering with the Attitude Determination and Control subsystem. This may lead to automated correction tasks being triggered unnecessarily. [x-opencti-sensor-data:sensor_type = 'gyroscope' AND x-opencti-sensor-data:reading_delta > 'threshold']
DISE-10 Abnormal Data Flow in Attitude Control Telemetry Detection of abnormal telemetry data rates in the Attitude Determination and Control subsystem, indicating potential manipulation of onboard values or interference with the control signals. This can trigger unnecessary corrective maneuvers or system malfunctions. An alternative pattern could be [x-opencti-telemetry-data:telemetry_type = 'attitude-control' AND (x-opencti-telemetry-data:parameter_name = 'quaternion' OR x-opencti-telemetry-data:parameter_name = 'gyro_reading' OR x-opencti-telemetry-data:parameter_name = 'magnetometer_value') AND x-opencti-telemetry-data:value_change > 'threshold_value' AND x-opencti-telemetry-data:change_rate > 'expected_rate'] [x-opencti-telemetry:telemetry_type = 'attitude_control' AND x-opencti-telemetry:data_rate > 'expected_rate']

References