Disclaimer

Please be informed that the analysis detailed in this article is entirely separate from the hacking experiment conducted by the Thales team on the satellite.

Both activities are independent of each other and were carried out by different teams. There is no association between me and the team that conducted the hacking experiment.

This work is conducted on a personal basis and is independent of my work at Thales. Thales is in no way involved in this work, and Thales’s responsibilities cannot be engaged under any circumstances.

All slides embedded in this article are public slides presented by Thales during the CYSAT 2023 conference and available in the Youtube video which presents the Thales experiment.

Purpose of the article

Recently, MITRE released the Embedded Systems Threat Matrix (ESTM), a new ATT&CK-style cybersecurity framework tailored to protect embedded systems through adversary tactics, techniques, and procedures (TTPs).

In a previous analysis, I applied the MITRE EMB3D™ Threat Model to dissect the Thales satellite hacking demonstration from CYSAT 2023, identifying key vulnerabilities and countermeasures across OPS-SAT’s attack chain.

This article replicates the study but using ESTM, mapping EMB3D Threat IDs to ESTM TTPs to demonstrate their practical complementarity.

The result showcases how these frameworks complement each other, EMB3D for secure-by-design threat modeling, ESTM for offensive kill-chain analysis, enabling comprehensive defense for space and embedded systems.

I also take this opportunity to highlight the TTPs identified by Brandon Bailey & Brad Roeher from the SPARTA team, who used the SPARTA framework to deconstruct the experiment.

• To know more about the SPARTA team study
• To know more about the SPARTA Framework

More about the Thales hacking demo at CYSAT 2023 on the OPS-SAT satellite

To know more about the Thales hacking demo at CYSAT 2023, I encourage you to visit the following pages here, here and here where the results of the ethical satellite hacking exercise is detailed.

To know more about the Thales hacking demo at CYSAT 2023, I encourage you to visit the following page here where OPS-SAT, a small, CubeSat-class satellite developed by the European Space Agency (ESA) to serve as a testbed for innovative software, systems, and operational concepts in space, is detailed.

More about EMB3D and ESTM

• To know more about MITRE EMB3D
• To know more about MITRE ESTM
• To understand how MITRE ESTM and MITRE EMB3D can work together

Methodology

To bridge EMB3D and ESTM, I followed a structured mapping process across the five-step OPS-SAT attack chain documented in my prior EMB3D analysis. For each step, I identified relevant EMB3D Threat IDs (TIDs) based on device properties and vulnerabilities exploited by Thales.

These TIDs were then mapped to ESTM’s tactics (e.g., Initial Access, Persistence) and embedded-specific techniques (e.g., Firmware Injection, Bus Interception), drawing from ESTM’s ATT&CK-inspired structure tailored to hardware/firmware realities.

This bidirectional approach validates EMB3D mitigations against realistic adversary TTPs while highlighting ESTM gaps for space systems like OPS-SAT.

OPS-SAT Attack Chain Mapping

Now let’s apply this methodology to the Thales OPS-SAT demo, breaking down each of the five attack steps with their corresponding EMB3D TIDs and ESTM TTP mappings.

The figure below is showing a summary of the full attack flow used by the Thales team to conduct the attack on OPS-SAT.

Step 1: Unsafe Java Deserialization

To introduce the compromised or flawed software onto the spacecraft, the team needed to bypass security checks and evaluations. To achieve their objective, they introduced a deserialization vulnerability into the software, enabling defensive mechanism evasion and potential exploitation for executing arbitrary commands.

Others proposed ESTM TTPs for step 1 :

As the ground segment use a ground proxy to connect to the space segment, I propose to add the following ESTM TTPs

• EST000021: Execute via Trusted Developer Utilities
• EST000073: Evasive Connection Proxy
• EST000094: Evade via Trusted Developer Utilities
• EST000167: C2 Connection Proxy

Step 2: Applications Binaries Modified 

Once the insecure deserialization achieved, the team uploaded a malicious code with the deserialization vulnerability to modify the application-level binaries on the remote device to introduce unauthorized code and to execute arbitrary commands on the remote system.

Step 3: Privilege Escalation via CAN Bus

At this stage, their app runs as an unprivileged Linux user and has no direct access to sensors but though the supervisor. Their objective is now to find system configuration issues or vulnerabilities to realize a privilege escalation from user to root.

They identified that anyone can talk on the CAN bus, including unprivileged apps. And then, all commands send on the CAN bus are executing as root by a client that runs as root and that decodes and executes as root whatever command it receives.

Step 4: Persistence

At this stage, the app escalated as root. Now, the team needed to ensure persistent effects on sensors. They identified a jar library on the Supervisor that is writable by root user. A jar is simply a zip file, with compiled Java bytecode inside. The team crafted a bytecode based on the original one, and simply replace some files inside the jar. The supervisor now runs the jar containing the malicious bytecode.

Step 5: OPS-SAT attack by tampering with camera and ADCS 

Once the team escalated as root and ensured persistency, they took control on the supervisor and the demo effects was achieved.

Step 6: Other potential effects (but non demonstrated)

When adversaries target a spacecraft, their primary goal is often to disrupt the mission. This disruption can involve compromising imagery, intercepting signals, or other mission-critical functions. Thales Group demonstrated this by successfully manipulating the payload data transmitted from the spacecraft. They also identified additional potential impacts that could occur if attackers gain further access and maintain their presence, though these were not carried out. With root access and ongoing control, the range of possible attacks becomes virtually unlimited.

• They could alter/delete all images captured by the camera
• They could override satellite attitude requested by other apps
• This also provides persistence for the malicious code since the supervisor starts early and is almost always running

Observations

Complementarity: EMB3D and ESTM are genuinely complementary

• EMB3D models threats from device properties (hardware, firmware, software, comms, safety features) → threats → mitigations (secure-by-design focus).
• ESTM captures adversary TTPs across the full embedded attack chain (recon, initial access, firmware manipulation, bus abuse, impact) in ATT&CK-style matrix format.

Mapping Reality: Not all EMB3D TIDs have a direct equivalent to ESTM techniques:

• Good coverage: TID-326 (unsafe deserialization), TID-301/302 (binary mods), TID-114 (bus interception) → clear ESTM Initial Access/Persistence/Lateral Movement equivalents.
• Software gaps: Pure software exploits (TID-305 dangerous syscalls, TID-204 untrusted program access) fall in ESTM’s « Execution/Privilege Escalation » but lack embedded-specific granularity vs. enterprise ATT&CK.
• Hardware strength: ESTM shines on bus interception (CAN/SpaceWire), firmware persistence, boot tampering → areas where EMB3D stays higher-level.

Practical Takeaway

Use EMB3D first for architecture review (derive requirements/mitigations), then ESTM to validate those mitigations block realistic embedded TTPs. The OPS-SAT case proves this works across space systems.

Conclusion

Practical Complementarity Proven

The OPS-SAT attack chain mapping confirms EMB3D and ESTM work powerfully together: EMB3D identifies threats from device properties (hardware → software → mitigations), while ESTM captures adversary TTPs across the embedded kill chain (firmware exploits, bus abuse, persistence).

Mapping Insights

• Strong alignment: Bus interception (TID-114), binary modification (TID-301/302), kernel persistence (TID-203) map cleanly to ESTM’s hardware/firmware tactics.
• Software gaps: Pure software exploits (TID-326 deserialization, TID-305 syscalls) find equivalents in ESTM’s Execution/Privilege Escalation tactics but lack the embedded-specific granularity of hardware-focused techniques.

Actionable Workflow

1. EMB3D first: Model device properties → derive mitigations during design.
2. ESTM validation: Test those mitigations against realistic embedded TTPs.
3. Iterate: Use gaps to prioritize R&D (software TTPs need more embedded detail).

Space Systems Impact

For satellite or space programs, this dual-framework approach delivers comprehensive threat coverage from architecture to operations, bridging the secure-by-design and red-team worlds.

Future work

Enhanced Risk Mitigation with ESTM Mitigations

Future iterations of this analysis will leverage upcoming ESTM versions featuring Associated Mitigations, similar to ATT&CK’s mitigation guidance. This will enable direct mapping from ESTM TTPs to specific countermeasures (e.g., secure boot enforcement, CAN bus encryption, …).

Operational Impact

This will deliver satellite programs a prioritized mitigation backlog, from Foundational (e.g., disable debug ports) to Leading Edge (e.g., runtime integrity monitoring), directly tied to demonstrated attack chains like Thales’ CYSAT demo.

The combined ESTM+EMB3D methodology positions space cybersecurity as proactive engineering, not reactive forensics. Stay tuned for the mitigations deep-dive!

Adding SPARTA to have a complete Space Framework

SPARTA from The Aerospace Corporation rounds out the perfect space cybersecurity stack. SPARTA (Space Attack Research & Tactic Analysis) is the space-mission-specific ATT&CK matrix, tactics/techniques/procedures (TTPs) for spacecraft across ground, link, and orbit phases. ESTM + EMB3D + SPARTA can offer a full framework for satellites/space systems

Recently, MITRE released ESTM (Embedded Systems Threat Matrix), a new cybersecurity framework designed to protect embedded systems. Built on the proven ATT&CK® methodology, ESTM organizes tactics and techniques (TTPs) tailored to embedded environments.

In parallel, MITRE launched EMB3D in 2024, a threat model focused on secure-by-design embedded devices, while ESTM takes an offensive approach as an attack matrix.

This article explores how ESTM and EMB3D can work together for comprehensive embedded system defense.

ESTM and EMB3D

ESTM and EMB3D are designed to be complementary: you can use EMB3D to drive secure‑by‑design requirements and mitigations at device level, and ESTM to map real attacker behaviors and operations against those devices throughout their lifecycle.

Mental model: what each brings

• EMB3D is a curated threat model for embedded devices that maps device properties to known threats and prescribes tiered mitigations (Foundational/Intermediate/Leading). We explore more in depth MITRE EMB3D in this article.
• ESTM is an ATT&CK‑style matrix of tactics and techniques tailored to embedded systems, focused on how adversaries actually operate (kill‑chain perspective). We explore more in depth MITRE ESTM in this article.
• MITRE explicitly states ESTM “works with” EMB3D to provide a complete resource for secure system design and defense.

Typical workflow: EMB3D → ESTM → EMB3D

1. Architecture & design (EMB3D first)

• Use EMB3D Properties to model your device (boot architecture, debug interfaces, comms stacks, safety features, etc.).
• From those Properties, enumerate relevant Threats and associated Mitigations, and derive security requirements (e.g. “protect firmware update mechanism”, “harden debug ports”).

2. Adversary behavior mapping (ESTM)

• For each EMB3D Threat, identify which ESTM tactics/techniques an attacker would likely use (e.g. Initial Access via supply‑chain, Firmware Persistence via malicious bootloader, Lateral Movement over fieldbus).
• Use this to define detection use‑cases, test scenarios, and red‑team playbooks that are realistic for embedded environments (not generic IT ATT&CK).

3. Refine mitigations and coverage (back to EMB3D)

• Take the ESTM techniques you care about most (based on threat intel, safety impact, mission impact) and check whether EMB3D’s mitigations and tiers give you enough depth for each mapped Threat.
• Where there is an ESTM technique with weak or missing mitigations in your design, prioritize closing those gaps using EMB3D’s mitigation guidance, aligned where relevant with ISA/IEC 62443‑4‑2.

A simple example:

• EMB3D says: your MCU exposes unauthenticated debug/UART (Property → Threat “unauthorized debug access”) and recommends mitigations like physical protection, debug lock, and authenticated debug unlock.
• ESTM lets you express how an attacker would use that in a campaign: Reconnaissance (locating interface), Initial Access (physical or proximity), Credential Access (dump secrets via debug), Persistence (modifying firmware), and Impact (tampering with control logic).
• You can now:
  • Turn those ESTM techniques into test cases for lab exploitation and purple‑team exercises.
  • Use EMB3D’s mitigation tiers to decide what level (Foundational vs Leading) you need based on your risk appetite and safety context.

Role split: secure‑by‑design vs operations

• Product / system engineers
  • Primary lens: EMB3D to capture device properties, threats, and mitigation roadmaps across product generations.
  • ESTM used to ensure requirements consider concrete adversary workflows and to validate that design controls actually break likely attack chains.
• Blue / red / purple teams & OT SOC
  • Primary lens: ESTM to model attack paths, prioritize monitoring at firmware/boot/fieldbus levels, and build detection content.
  • EMB3D used as the “defensive catalogue” to validate that for each high‑value tactic/technique they are trying to detect, the underlying device has the right mitigations or compensating controls.

Practical integration ideas

• Bidirectional mapping: maintain an internal mapping table: EMB3D Threat IDs ↔ ESTM tactics/techniques, plus links to ATT&CK where relevant, so you can pivot between design, testing, and SOC views. (MITRE notes EMB3D already aligns with ATT&CK/CWE/CVE, which helps here.)
• Tooling and STIX: EMB3D 2.0 provides a STIX 2.1 JSON format, enabling ingestion into threat/vuln tooling; you can extend that repo with fields for associated ESTM techniques to keep everything in one knowledge base.
• Standards alignment: use EMB3D’s 62443‑4‑2 alignment to show compliance of mitigations, while ESTM scenarios feed into security test plans and evidence for those same controls.

Exploring recent studies

In this article, I show how I used the MITRE EMB3D™ Threat Model to identify vulnerabilities in SIEMENS PLCs that were exploited by the Stuxnet worm to sabotage the Iran’s nuclear centrifuges.

In this article, I show how I used the MITRE EMB3D™ Threat Model to break down the experiment of Thales satellite hacking demo at CYSAT 2023, identify key lessons learned, and record possible countermeasures.