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.
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
| CM0002 | COMSEC | A component of cybersecurity to deny unauthorized persons information derived from telecommunications and to ensure the authenticity of such telecommunications. COMSEC includes cryptographic security, transmission security, emissions security, and physical security of COMSEC material. It is imperative to utilize secure communication protocols with strong cryptographic mechanisms to prevent unauthorized disclosure of, and detect changes to, information during transmission. Systems should also maintain the confidentiality and integrity of information during preparation for transmission and during reception. Spacecraft should not employ a mode of operations where cryptography on the TT&C link can be disabled (i.e., crypto-bypass mode). The cryptographic mechanisms should identify and reject wireless transmissions that are deliberate attempts to achieve imitative or manipulative communications deception based on signal parameters. | AC-17 AC-17(1) AC-17(10) AC-17(10) AC-17(2) AC-18 AC-18(1) AC-2(11) AC-3(10) CA-3 IA-4(9) IA-5 IA-5(7) IA-7 PL-8 PL-8(1) SA-8(18) SA-8(19) SA-9(6) SC-10 SC-12 SC-12(1) SC-12(2) SC-12(3) SC-12(6) SC-13 SC-16(3) SC-28(1) SC-28(3) SC-7 SC-7(10) SC-7(11) SC-7(18) SC-7(5) SC-8(1) SC-8(3) SI-10 SI-10(3) SI-10(5) SI-10(6) SI-19(4) SI-3(8) | D3-ET D3-MH D3-MAN D3-MENCR D3-NTF D3-ITF D3-OTF D3-CH D3-DTP D3-NTA D3-CAA D3-DNSTA D3-IPCTA D3-NTCD D3-RTSD D3-PHDURA D3-PMAD D3-CSPP D3-MA D3-SMRA D3-SRA | A.5.14 A.6.7 A.8.1 A.8.16 A.5.14 A.8.1 A.8.20 A.5.14 A.8.21 A.5.16 A.5.17 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.12 A.5.33 A.8.20 A.8.24 A.8.24 A.8.26 A.5.31 A.5.33 A.8.11 | |
| 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 IA-9 PL-8 PL-8(1) SA-3 SA-4(5) SA-8 SA-8(15) SA-8(9) SC-16 SC-16(1) SC-16(2) SC-32(1) SC-7(11) SC-8(1) SI-14(3) SI-7(6) | D3-MH D3-MAN D3-CH D3-BAN D3-MFA D3-TAAN D3-CBAN | 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 | |
| CM0033 | Relay Protection | Implement relay and replay-resistant authentication mechanisms for establishing a remote connection or connections on the spacecraft bus. | AC-17(10) AC-17(10) IA-2(8) IA-3 IA-3(1) IA-4 IA-7 SC-13 SC-16(1) SC-23 SC-23(1) SC-23(3) SC-7 SC-7(11) SC-7(18) SI-10 SI-10(5) SI-10(6) SI-3(8) | D3-ITF D3-NTA D3-OTF | A.5.16 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 A.8.24 A.8.26 A.5.31 | |
| CM0073 | Traffic Flow Analysis Defense | Utilizing techniques to assure traffic flow security and confidentiality to mitigate or defeat traffic analysis attacks or reduce the value of any indicators or adversary inferences. This may be a subset of COMSEC protections, but the techniques would be applied where required to links that carry TT&C and/or data transmissions (to include on-board the spacecraft) where applicable given value and attacker capability. Techniques may include but are not limited to methods to pad or otherwise obfuscate traffic volumes/duration and/or periodicity, concealment of routing information and/or endpoints, or methods to frustrate statistical analysis. | SC-8 SI-4(15) | D3-NTA D3-ANAA D3-RPA D3-NTCD | A.5.10 A.5.14 A.8.20 A.8.26 | |
| CM0036 | Session Termination | Terminate the connection associated with a communications session at the end of the session or after an acceptable amount of inactivity which is established via the concept of operations. | AC-12 AC-12(2) SC-10 SI-14(3) SI-4(7) | D3-SDA | A.8.20 | |
| CM0039 | Least Privilege | Employ the principle of least privilege, allowing only authorized processes which are necessary to accomplish assigned tasks in accordance with system functions. Ideally maintain a separate execution domain for each executing process. | AC-2 AC-3(13) AC-3(15) AC-4(2) AC-6 CA-3(6) CM-7 CM-7(5) CM-7(8) PL-8 PL-8(1) SA-17(7) SA-3 SA-4(9) SA-8 SA-8(13) SA-8(14) SA-8(15) SA-8(19) SA-8(3) SA-8(4) SA-8(9) SC-2(2) SC-32(1) SC-49 SC-50 SC-7(29) | D3-MAC D3-EI D3-HBPI D3-KBPI D3-PSEP D3-MBT D3-PCSV D3-LFP D3-UBA | A.5.16 A.5.18 A.8.2 A.5.15 A.8.2 A.8.18 A.8.19 A.8.19 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | |
| CM0055 | Secure Command Mode(s) | Provide additional protection modes for commanding the spacecraft. These can be where the spacecraft will restrict command lock based on geographic location of ground stations, special operational modes within the flight software, or even temporal controls where the spacecraft will only accept commands during certain times. | AC-17(1) AC-17(10) AC-2(11) AC-2(12) AC-3 AC-3(2) AC-3(3) AC-3(4) AC-3(8) CA-3(7) IA-10 PL-8 PL-8(1) SA-3 SA-8 SC-7 SI-3(8) | D3-AH D3-ACH D3-MFA D3-OTP | A.8.16 A.5.15 A.5.33 A.8.3 A.8.4 A.8.18 A.8.20 A.8.2 A.8.16 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 | |
| CM0034 | Monitor Critical Telemetry Points | Monitor defined telemetry points for malicious activities (i.e., jamming attempts, commanding attempts (e.g., command modes, counters, etc.)). This would include valid/processed commands as well as commands that were rejected. Telemetry monitoring should synchronize with ground-based Defensive Cyber Operations (i.e., SIEM/auditing) to create a full space system situation awareness from a cybersecurity perspective. | AC-17(1) AU-3(1) CA-7(6) IR-4(14) PL-8 PL-8(1) SA-8(13) SC-16 SC-16(1) SC-7 SI-3(8) SI-4(7) | D3-NTA D3-PM D3-PMAD D3-RTSD | A.8.16 A.5.8 A.5.14 A.8.16 A.8.20 A.8.22 A.8.23 A.8.26 | |
| 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) 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(10) SI-3(8) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(13) 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-4(7) SI-6 SI-7(17) SI-7(8) | 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 | 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 | |
| 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. | AC-4 AC-4(14) AC-4(2) AC-4(24) AC-4(26) AC-4(31) AC-4(32) AC-4(6) AC-6 CA-3 CA-3(7) PL-8 PL-8(1) SA-3 SA-8 SA-8(13) SA-8(15) SA-8(18) SA-8(3) SA-8(4) SA-8(9) SC-16(3) SC-2(2) SC-3 SC-3(4) SC-32 SC-32(1) SC-32(1) SC-39 SC-4 SC-49 SC-50 SC-6 SC-7(20) SC-7(21) SC-7(29) SC-7(5) SI-17 SI-4(7) | 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 | A.5.14 A.8.22 A.8.23 A.5.15 A.8.2 A.8.18 A.5.14 A.8.21 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | |
| 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) SA-8(19) SC-16 SC-16(1) SC-40 SC-40 SC-40(1) SC-40(1) SC-40(3) SC-40(3) SC-40(4) SC-40(4) SC-5 SC-8(1) SC-8(3) SC-8(4) | D3-MH D3-MAN D3-MENCR D3-NTA D3-DNSTA D3-ISVA D3-NTCD D3-RTA D3-PMAD D3-FC D3-CSPP D3-ANAA D3-RPA D3-IPCTA D3-NTCD D3-NTPM D3-TAAN | 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 | |
| ID | Name | Description | STIX Pattern |
| UACE-6 | Unauthorized Commands Issued from Unrecognized Ground Station | Detection of control commands issued to the spacecraft from an unrecognized or unauthorized ground station, potentially indicating that a rogue ground station is attempting to take control of the spacecraft. | [x-opencti-command-log:command_origin != 'authorized_ground_station' AND x-opencti-command-log:command_type = 'control'] |
| UACE-7 | Duplicate Command Packet Executions | Detection of previously executed command packets being replayed outside of expected time windows, which may indicate a replay attack. | [x-opencti-command-log:command_id = 'duplicate' AND x-opencti-command-log:timestamp = 'unexpected_time'] |
| UACE-8 | Anomalous Command Packet Signatures | Command packets with invalid or anomalous signatures detected, potentially indicating spoofing or replay of older commands. Command signatures for spacecraft provide a way to verify the authenticity and integrity of commands sent to the spacecraft, ensuring they have not been tampered with during transmission. The signature could be a form of sequence numbers, hashing, or just digital signatures in general. | [x-opencti-command-log:signature != 'expected_signature'] |
| UACE-9 | Valid Command Flooding | Detection of flooding attacks on spacecraft systems using valid but excessive commands. Threat actors may send a high volume of valid commands to spacecraft subsystems, communication buses, or the link layer, leading to resource exhaustion such as CPU usage spikes, memory depletion, and increased battery consumption. These attacks can create temporary denial of service conditions by overwhelming the spacecraft's processing capabilities, preventing it from performing other critical operations. This tactic relies on the legitimate processing of valid commands to degrade spacecraft performance and operational availability. Since these are valid commands, the spacecraft will use processing power to validate and process them taking away CPU cycles from other tasks on the spacecraft. | [x-opencti-command-data:command_type = 'satellite_vehicle_command' AND x-opencti-command-data:command_frequency > 'expected_rate' AND x-opencti-command-data:source = 'external' AND x-opencti-command-data:command_validity = 'valid'] |
| UACE-10 | Logs of Processed Commands Flooding | Detection of an unusually high number of processed commands recorded in spacecraft logs, which may indicate a flooding attack using valid commands. Such a surge can overwhelm spacecraft processing capabilities, leading to resource exhaustion like CPU spikes, memory depletion, and increased battery usage. Monitoring log entries can reveal if the spacecraft is being flooded with valid but excessive commands, which could create denial of service conditions by saturating system processing resources. | [x-opencti-log-entry:log_type = 'command' AND x-opencti-log-entry:entry_count > 'expected_threshold' AND x-opencti-log-entry:entry_rate > 'normal_rate'] |
| UACE-20 | Repeated Downlink Commands with Identical Timestamps | Monitors for repeated downlink commands with matching timestamps, a key indicator of replayed command traffic. | [x-opencti-command-log:command = 'downlink_data' AND x-opencti-command-log:timestamp = 'duplicate_timestamp'] |
| UACE-21 | Repeated Downlink Commands Sent Outside Authorized Time | Monitors for repeated attempts to send downlink commands outside the expected operational windows, suggesting an attacker replaying commands for data exfiltration purposes. | [x-opencti-command-log:command = 'downlink_payload_data' AND x-opencti-command-log:timestamp != 'expected_time'] |
| 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-28 | Detection of CANBus Replay Attack with Duplicate Message ID and Timing Anomalies | Detection of a replay attack using a legitimate CANBus message (legitimate_id) with an expected payload being retransmitted either outside of its expected transmission window or multiple times in rapid succession (i.e., duplicate messages). This could indicate a malicious actor attempting to replay previously captured commands to manipulate spacecraft systems. | [x-opencti-bus-traffic:can_message_id = 'legitimate_id' AND x-opencti-bus-traffic:message_payload = 'expected_payload' AND (x-opencti-bus-traffic:transmission_time != 'expected_transmission_time' OR x-opencti-bus-traffic:duplicate_message_count > 1)] |
| CSNE-29 | Replay of Legitimate CANBus Message with Known Message ID | Detection of a replay attack using a legitimate CANBus message with a known message ID (legitimate_id). The message is being retransmitted outside of its expected transmission time, indicating potential replay of previously captured traffic to manipulate spacecraft operations, such as sensor states or power settings. | [x-opencti-bus-traffic:can_message_id = 'legitimate_id' AND x-opencti-bus-traffic:transmission_time != 'expected_transmission_time'] |
| ARFS-4 | Unexpected Latency in Command Packet Processing | Description: Detection of previously executed command packets being replayed outside of expected time windows, which may indicate a replay attack. | [x-opencti-telemetry:command_delay > 'threshold'] |
| ARFS-9 | Safe-Mode Activation Due to Signal Jamming | Monitors RF noise levels in GNSS or uplink bands that exceed expected thresholds, leading to safe-mode activation. This could indicate deliberate signal jamming aimed at exploiting reduced protections in safe-mode. Entering safe mode does not necessarily indicate jamming of commanding has occurred, as some spacecraft enter safe-mode after expected communication contacts with the ground are missed. | [x-opencti-rf-sensor:frequency_band IN ('gnss_band','uplink_band') AND x-opencti-rf-sensor:noise_level > 'maximum_threshold' AND x-opencti-spacecraft-status:mode = 'safe-mode'] |
| ARFS-12 | Rejection of CLTU BIND Due to Tampered/Invalid Credentials | Detects that the SLE Provider rejected the CLTU BIND request due to tampered or failed credentials, leading to a termination of the connection. This IOC specifically detects the rejection of the CLTU BIND request due to credential tampering/invalid credentials. It explicitly identifies that the BIND request was rejected because the credentials were invalid or tampered with, which leads to the termination of the connection. This is a more focused detection that ties directly to the modification of credentials, which results in the rejection of the CLTU BIND request by the SLE Provider. | [x-opencti-command-log:command = 'CLTU-BIND' AND x-opencti-command-log:status = 'rejected' AND x-opencti-command-log:reason = 'invalid_credentials'] |
| SMSR-3 | Unauthorized State Changes in Critical Sensors | Detection of an unexpected sensor state change in critical spacecraft sensors (e.g., Sun Sensor, GPS Sensor). The sensor states are modified outside of authorized operational windows, suggesting a malicious attack affecting the sensor's behavior. | [x-opencti-sensor:state = 'off' AND x-opencti-sensor:state_change_time != 'authorized_time'] |