Compromise Boot Memory

The attacker manipulates memory and configuration used in the earliest stages of boot so that their code runs before normal protections and integrity checks take hold. Targets include boot ROM vectors, first-stage/second-stage bootloaders, boot configuration words and strap pins, one-time-programmable (OTP) fuses, non-volatile images in flash/EEPROM, and scratch regions copied into RAM during cold start. Techniques range from replacing or patching boot images to flipping configuration bits that alter trust decisions (e.g., image selection, fallback order, watchdog behavior). Faults can be induced deliberately (timed power/clock/EM glitches) or via crafted update/write sequences that leave a partially programmed but executable state. Once resident, the modification can insert early hooks, disable or short-circuit checks, or select downgraded images; destructive variants corrupt the boot path to induce a persistent reset loop or safeing entry (a denial of service). Because boot logic initializes buses, memory maps, and handler tables, even small changes at this stage cascade, shaping how command handlers load, how keys and counters are initialized, and which peripherals are trusted for subsequent execution.

ID: EX-0004

Sub-techniques: No sub-techniques

Notional Risk (H | M | L): 21 | 17 | 12

ⓘ

Tactic: Execution

Created: 2022/10/19

Last Modified: 2026/03/11

Countermeasures

ID	Name	Tiering	Description	NIST Rev5	ISO 27001	Onboard SV	Ground
CM0028	Tamper Protection	Tier II	Perform physical inspection of hardware to look for potential tampering. Leverage tamper proof protection where possible when shipping/receiving equipment. Anti-tamper mechanisms are also critical for protecting software from unauthorized alterations. Techniques for preventing software tampering include code obfuscation, integrity checks, runtime integrity monitoring (e.g. self-checking code, watchdog processes, etc.) and more.	AC-14 \| AC-25 \| CA-8(1) \| CA-8(3) \| CM-7(9) \| MA-7 \| PL-8 \| PL-8(1) \| PL-8(2) \| PM-30 \| PM-30(1) \| RA-3(1) \| SA-10(3) \| SA-10(4) \| SA-11 \| SA-3 \| SA-4(5) \| SA-4(9) \| SA-8 \| SA-8(11) \| SA-8(13) \| SA-8(16) \| SA-8(19) \| SA-8(31) \| SA-9 \| SC-51 \| SR-1 \| SR-10 \| SR-11 \| SR-11(3) \| SR-2 \| SR-2(1) \| SR-3 \| SR-4(3) \| SR-4(4) \| SR-5 \| SR-5(2) \| SR-6(1) \| SR-9 \| SR-9(1)	A.5.8 \| 4.4 \| 6.2 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| 10.2 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30 \| 5.2 \| 5.3 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| A.5.1 \| A.5.2 \| A.5.4 \| A.5.19 \| A.5.31 \| A.5.36 \| A.5.37 \| A.5.19 \| A.5.20 \| A.5.21 \| A.8.30 \| A.5.20 \| A.5.21 \| A.5.20 \| A.5.21 \| A.5.23 \| A.8.29	YES
CM0015	Software Source Control	Tier I	Prohibit the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code.	CM-11 \| CM-14 \| CM-2 \| CM-4 \| CM-5(6) \| CM-7(8) \| SA-10(2) \| SA-10(4) \| SA-11 \| SA-3 \| SA-4(5) \| SA-4(9) \| SA-8 \| SA-8(19) \| SA-8(29) \| SA-8(30) \| SA-8(31) \| SA-8(7) \| SA-9 \| SI-7	A.8.9 \| A.8.9 \| A.8.19 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30		YES
CM0018	Dynamic Testing	Tier I	Employ dynamic analysis (e.g., using simulation, penetration testing, fuzzing, etc.) to identify software/firmware weaknesses and vulnerabilities in developed and incorporated code (open source, commercial, or third-party developed code). Testing should occur (1) on potential system elements before acceptance; (2) as a realistic simulation of known adversary tactics, techniques, procedures (TTPs), and tools; and (3) throughout the lifecycle on physical and logical systems, elements, and processes. FLATSATs as well as digital twins can be used to perform the dynamic analysis depending on the TTPs being executed. Digital twins via instruction set simulation (i.e., emulation) can provide robust environment for dynamic analysis and TTP execution.	CA-8 \| CA-8(1) \| CM-4(2) \| CP-4(5) \| RA-3 \| RA-5(11) \| RA-7 \| SA-11 \| SA-11(3) \| SA-11(5) \| SA-11(8) \| SA-11(9) \| SA-3 \| SA-8 \| SA-8(30) \| SC-2(2) \| SC-7(29) \| SI-3 \| SI-3(10) \| SI-7 \| SR-6(1)	6.1.2 \| 8.2 \| 9.3.2 \| A.8.8 \| 6.1.3 \| 8.3 \| 10.2 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.8.29 \| A.8.30 \| A.8.7		YES
CM0021	Software Digital Signature	Tier I	Prevent the installation of Flight Software without verification that the component has been digitally signed using a certificate that is recognized and approved by the mission.	AC-14 \| CM-11 \| CM-11(3) \| CM-14 \| CM-5(6) \| IA-2 \| SA-10(1) \| SA-11 \| SA-4(5) \| SA-8(29) \| SA-8(31) \| SA-9 \| SI-7 \| SI-7(1) \| SI-7(12) \| SI-7(15) \| SI-7(6)	A.8.19 \| A.5.16 \| A.5.2 \| A.5.4 \| A.5.8 \| A.5.14 \| A.5.22 \| A.5.23 \| A.8.21 \| A.8.29 \| A.8.30		YES
CM0023	Configuration Management	Tier II	Use automated mechanisms to maintain and validate baseline configuration to ensure the spacecraft's is up-to-date, complete, accurate, and readily available.	CM-11(3) \| CM-2 \| CM-3(4) \| CM-3(6) \| CM-3(7) \| CM-3(8) \| CM-4 \| CM-5 \| CM-5(6) \| MA-7 \| SA-10 \| SA-10(2) \| SA-10(7) \| SA-11 \| SA-3 \| SA-4(5) \| SA-4(9) \| SA-8 \| SA-8(29) \| SA-8(30) \| SA-8(31) \| SI-7 \| SR-11(2)	A.8.9 \| A.8.9 \| A.8.9 \| A.8.9 \| A.8.2 \| A.8.4 \| A.8.9 \| A.8.19 \| A.8.31 \| A.8.3 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.8.9 \| A.8.28 \| A.8.30 \| A.8.32 \| A.8.29 \| A.8.30		YES
CM0014	Secure boot	Tier I	Software/Firmware must verify a trust chain that extends through the hardware root of trust, boot loader, boot configuration file, and operating system image, in that order. The trusted boot/RoT computing module should be implemented on radiation tolerant burn-in (non-programmable) equipment.	AC-14 \| PL-8 \| PL-8(1) \| SA-8(10) \| SA-8(12) \| SA-8(13) \| SA-8(3) \| SA-8(30) \| SA-8(4) \| SC-51 \| SI-7 \| SI-7(1) \| SI-7(10) \| SI-7(9)	A.5.8		YES

Indicators of Behavior

ID	Name	Description	STIX Pattern
MIRE-1	Anomalous Flash Write Operations Detected in Short Timeframe	Detection of a high number of flash write operations in a short timeframe, indicating a coordinated effort to overwrite the spacecraft's flash memory entirely. This behavior is typical of wiper malware aiming to destroy all flash data.	[x-opencti-memory:block = 'flash_memory' AND x-opencti-memory:write_operation_count > 'threshold' AND x-opencti-memory:write_duration < 'threshold']
MIRE-2	Anomalous Flash/EEPROM Memory Checksums Detected	Detection of a checksum mismatch for the flight software's flash / eeprom memory partitions. This could indicate that both the primary and redundant partitions have been corrupted by the malicious action, leading to a permanent denial of service (DoS).	[x-opencti-memory:table_ref.name = 'flash_memory' OR x-opencti-memory:table_ref.name = 'eeprom_memory' AND x-opencti-memory:checksum != 'expected_checksum']
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-4	Skipped Boot Integrity Check	Detects cases where boot / firmware integrity checks are bypassed, potentially due to a glitching or other attacks.	[x-opencti-memory:block = 'boot' AND x-opencti-memory:integrity_check = 'skipped']
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']
MIRE-9	Failed Boot Memory Validation	Detection of boot memory validation failure, indicating that boot memory has been tampered with to bypass internal processes. This is similar to integrity failure detection but this is the overall boot process failing validation using whatever steps are established (i.e., digital signature, cryptography, etc.)	[x-opencti-system:boot_memory_validation = 'failed']
MIRE-10	Anomalous Boot Sequence Execution	Detection of an unexpected boot sequence, indicating potential tampering or manipulation of boot memory during system startup.	[x-opencti-system:boot_sequence = 'unexpected']
MIRE-11	Detection of Malicious Code in Boot Memory (Integrity Failure)	Detection of malicious code being executed or loaded into boot memory, indicated by a failed memory integrity check.	[x-opencti-memory:block = 'boot' AND x-opencti-memory:integrity_check = 'failed']
MIRE-16	Unexpected Boot Memory Modifications	Detection of unexpected access and changes in the boot memory region, which may indicate an attempt to manipulate or modify the system's boot sequence.	[x-opencti-memory:block = 'boot' AND x-opencti-memory-log:block = 'boot' AND x-opencti-memory-log:status != 'expected']
MIRE-17	Unauthorized System Call to Open Flash Memory Blocks (/dev/mtd)	Detection of unauthorized system calls to access flash memory devices or partitions (/dev/mtd%). These system calls indicate that a malicious script or process is attempting to modify or read flash memory, potentially targeting critical system areas like firmware or configuration data during an attack.	[process:image_ref.name = 'open' AND file:path LIKE '/dev/mtd%' AND file:access_time != 'authorized_access_time']
SIUU-8	Malicious Code via New Process	Code execution detected from an unexpected source / process, possibly indicating unauthorized or malicious code running on the spacecraft.	[x-opencti-logs:event_type = 'code_execution' AND x-opencti-processor-usage:activity_type = 'unexpected' AND x-opencti-processor-usage:process_name NOT IN ('list_of_known_processes')]
SIUU-9	Unexpected Software Crash Detected in Flight Software	Detection of unexpected crashes in flight software, potentially caused by attempts to exploit software vulnerabilities or coding flaws that lead to system instability. Repeated or unexplained crashes may indicate ongoing exploitation attempts targeting the spacecraft's flight control systems.	[x-opencti-software:status = 'crashed' AND x-opencti-software:component != 'expected_crash_behavior']

Priority 1	Priority 2	Priority 3	Priority 4
CWE-287: Improper Authentication	CWE-345: Insufficient Verification of Data Authenticity		CWE-668: Exposure of Resource to Wrong Sphere
CWE-346: Origin Validation Error
CWE-506: Embedded Malicious Code

Compromise Boot Memory

Countermeasures

Related CWE Classes

Related Aerospace Threat ID

Related MITRE ATT&CK TTPs

Related ESA SPACE-SHIELD TTPs

Related MITRE EMB3D Threats

Related BSI Threats

Indicators of Behavior

References