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
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.
Brandon Bailey and Brad Roeher from the SPARTA team already did an analysis of the Thales satellite hacking demo (summarized in this article, full article here) but with the SPARTA framework. You can enter to the SPARTA portal here.
The goal with this article is to go further by using the MITRE EMB3D™, a Threat Model for embedded systems, to identify threats and possible associated countermeasures.
Important Note
Before we dive in, I want to clarify an important distinction between threats and vulnerabilities.
Threat modeling tools focus on identifying threats, which are potential risks that could be exploited by an attacker. Vulnerabilities, on the other hand, are specific weaknesses in a system that can be exploited.
In this analysis, it turns out that the threats identified by the threat model were actual vulnerabilities, as they could be exploited by the team.
Hacking demo at CYSAT 2023: what was the point again
For the third edition of CYSAT, the European event entirely dedicated to cybersecurity for the space industry, taking place on 26-27 April 2023 at Station F in Paris, the European Space Agency (ESA) set up a satellite test bench to simulate attempts to seize control of OPS-SAT, a nanosatellite operated by the agency for demonstration purposes.
Thales’s offensive cybersecurity team stepped up to the challenge, identifying vulnerabilities that could enable malicious actors to disrupt operation of the ESA satellite.

The results of the ethical satellite hacking exercise, the first of its kind in the world, will be used to tighten security for the satellite and its onboard applications, helping to improve the cyber resilience of space systems, protect sensitive data and support the long-term success of space programs.
To know more about the Thales Demo in video
What is OPS-SAT
OPS-SAT is 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.
From a cybersecurity perspective, OPS-SAT represents a critical platform for experimenting with and addressing the unique challenges of securing space-based assets.

What is MITRE EMB3D™ Threat Model
EMB3D™ is a Cybersecurity Threat Model released by MITRE in May 2024 and dedicated for Embedded Devices.
EMB3D is aligned with and expands on several existing models, including Common Weakness Enumeration, MITRE ATT&CK®, and Common Vulnerabilities and Exposures, but with a specific embedded-device focus. The threats defined within EMB3D are based on observation of use by threat actors, proof-of-concept and theoretical/conceptual security research publications, and device vulnerability and weakness reports. These threats are mapped to device properties to help users develop and tailor accurate threat models for specific embedded devices.

Each threat description include a set of Foundational, Intermediate, and Leading mitigations. These mitigations will provide guidance on what technical mechanisms can best prevent or reduce the risk of that threat.
For each threat, EMB3D will suggest technical mechanisms that vendors should build into the device to mitigate the given threat. EMB3D is a comprehensive framework for the entire security ecosystem—device vendors, asset owners, security researchers, and testing organizations.
To know more about the MITRE EMB3D™ Cybersecurity Threat Model for Embedded Devices, check our article here.
Analysis of the Thales OPS-SAT hacking Attack Chain
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.

The insecure deserialization threat is documented in the EMB3D Threat Model with the following Threat ID (TID) and Properties ID (PID):
Threat ID | Properties ID |
TID-326: Insecure Deserialization | PID-3121: Device includes support for object oriented programming languages(e.g., Java, Python, PHP, C++) |
Table 1: Identified threats for the step 1 (Unsafe Java deserialization)

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.

The ability to modify application-level binaries and to install Untrusted Application on a remote system is documented in the EMB3D Threat Model with the following threats ID and properties ID:
Threat ID | Properties ID |
TID-301: Applications Binaries Modified | PID-31: Application-level software is present and running on the device |
TID-302: Install Untrusted Application | PID-32: Device includes the ability to deploy custom or external programs (e.g., ladder logic, compiled binaries) |
TID-307: Device Code Representations Inconsistent | PID-324: Device includes support for “program uploads” to retrieve programs from the device from an engineering workstation |
TID-308: Code Overwritten to Avoid Detection | |
TID-309: Device Exploits Engineering Workstation |
Table 2: Identified threats for the step 2 (Applications Binaries Modified)
Step 3: Privilege escalation via the 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.

The ability to privilege escalation is documented in the EMB3D Threat Model with the following threats ID and properties ID:
Threat ID | Properties ID |
TID-114: Peripheral Data Bus Interception |
PID-13: Device includes peripheral chips and integrated data buses |
TID-412: Network Routing Capability Abuse | PID-42: Device includes procedure to forward or route network messages |
TID-204: Untrusted Programs Can Access Privileged OS Functions | PID-2321: Device lacks an access enforcement/privilege mechanism |
TID-219: OS/Kernel Privilege Escalation | PID-23221: Device includes and enforces OS user accounts |
Table 3: Identified threats for the step 3 (Privilege escalation via the CAN Bus)

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.

The ability to manipulate Runtime Environment, to modify System Component and modify native library of the operating system are documented in the EMB3D Threat Model with the following threats ID and properties ID:
Threat ID | Properties ID |
TID-304: Manipulate Runtime Environment | PID-322: Device includes a program runtime environment for custom or external programs |
TID-305: Program Executes Dangerous System Calls | PID-3231: Device includes ability to run custom/external programs as native binary without a confined/restricted environment |
TID-203: Malicious OS Kernel Driver/Module Installable | PID-231: Device includes an operating system that uses drivers/modules that can be loaded |
TID-202: Exploitable System Network Stack Component | PID-23: Device includes OS/kernel |
TID-307: Device Code Representations Inconsistent | PID-324: Device includes support for “program uploads” to retrieve programs from the device from an engineering workstation |
TID-308: Code Overwritten to Avoid Detection |
Table 4: Identified threats for the step 4 (Persistence)
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.

- 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

Threat Heat Map
Using the EMB3D Threat Mapper feature, we create the following Threat Heat Map which represents all the threats affecting the system.
With the EMB3D Threat model, we identified 14 cyber threats. The data is shown into an Excel sheet.

Cyber risk mitigation for satellite system
The figure below shows the high-level countermeasures guidance provided by Thales.

The figure below shows the result of the analysis conducted by Brandon Bailey & Brad Roeher of the Thales experiment with the SPARTA framework (you can enter to the SPARTA portal here). In this figure, they are showing the full attack chain overlaid with SPARTA TTPs and associated countermeasures (full article of their analysis here).

In the rest of this article, I propose to identify a list of associated mitigations proposed by EMB3D Threat Model.
About Associated Mitigations in the EMB3D Threat Model
In light of the various threats we have identified, we outline below a list of associated mitigations proposed by EMB3D Threat Model.
Mitigation tiers
These mitigations have varying efficiencies and challenges with their implementations.
Mitigation tiers (foundational/intermediate/leading) are intended to help better understand how to assess the challenge of deploying mitigations and better strategize and prioritize efforts to add additional mitigations or technologies to address threats.

ISA/IEC 62443-4-2 Mappings
ISA is the International Society of Automation. ISA/IEC 62443 is the applicable standard for cybersecurity of OT and ICS (IACS). Each associated mitigation is mapped with the ISA/IEC 62443-4-2.
List of Associated Mitigations for the OPS-SAT
Step 1: Unsafe Java deserialization
Threats | Associated Mitigations | Level | IEC 62443 4-2 Mappings |
TID-326 – Insecure Deserialization |
MID-077 – Secure Deserialization | Foundational |
|
Table 7: Identified mitigations for the step 1 (Unsafe Java deserialization)
Step 2: Applications Binaries Modified
Threats | Associated Mitigations | Level | IEC 62443 4-2 Mappings |
TID-301 – Applications Binaries Modified | MID-009 – Operating System-based Runtime Integrity Check | Intermediate |
|
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation | Leading | ||
TID-302 – Install Untrusted Application | MID-041 – Cryptographically Signed Vendor-supplied Programs | Foundational |
|
MID-051 – Disallow User-Provided Code | Foundational |
|
|
MID-040 – Cryptographically Signed Custom Programs | Intermediate | ||
MID-009 – Operating System-based Runtime Integrity Check | Intermediate |
|
|
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation | Leading | ||
TID-307 – Device Code Representations Inconsistent | MID-042 – Device Checks Consistency Between Binary/Running Code and Textual Code | Foundational |
|
TID-308 – Code Overwritten to Avoid Detection | MID-017 – Security-relevant Auditing and Logging | Foundational |
|
TID-309 – Device Exploits Engineering Workstation | MID-008 – Decidable Protocols and Parsers | Intermediate |
|
Table 8: Identified mitigations for the step 2 (Applications Binaries Modified)
Step 3: Privilege escalation via the CAN bus
Threats | Associated Mitigations | Level | IEC 62443 4-2 Mappings |
TID-114 – Peripheral Data Bus Interception |
MID-068 – Data Bus Encryption and Message Authentication | Intermediate |
|
TID-412 – Network Routing Capability Abuse | MID-017 – Security-relevant Auditing and Logging | Foundational |
|
MID-038 – Authenticate for Administrative Actions | Foundational |
|
|
MID-083 – Network Firewall/Access Control List | Foundational |
|
|
TID-204 – Untrusted Programs Can Access Privileged OS Functions | MID-012 – OS-based Access Control Mechanisms | Foundational |
|
TID-219 – OS/Kernel Privilege Escalation |
Table 9: Identified mitigations for the step 3 (Privilege escalation via the CAN bus)
Step 4: Persistence
Threats | Associated Mitigations | Level | IEC 62443 4-2 Mappings |
TID-304 – Manipulate Runtime Environment | MID-013 – Process and Thread Memory Segmentation | Foundational |
|
MID-009 – Operating System-based Runtime Integrity Check | Intermediate |
|
|
MID-015 – Containerization | Intermediate |
|
|
TID-305 – Program Executes Dangerous System Calls | MID-015 – Containerization | Intermediate |
|
TID-203 – Malicious OS Kernel Driver/Module Installable | MID-009 – Operating System-based Runtime Integrity Check | Intermediate |
|
MID-003 – Periodic/Continuous Integrity Measurement and Remote Attestation | Leading | ||
TID-202 – Exploitable System Network Stack Component | MID-007 – Control Flow Manipulation Protections | Intermediate |
|
MID-008 – Decidable Protocols and Parsers | Intermediate |
|
|
TID-307 – Device Code Representations Inconsistent | MID-042 – Device Checks Consistency Between Binary/Running Code and Textual Code | Foundational |
|
TID-308 – Code Overwritten to Avoid Detection | MID-017 – Security-relevant Auditing and Logging | Foundational |
|
Table 10: Identified mitigations for the step 4 (Persistence)
The Advantages of the EMB3D Threat Model for a Satellite System
The EMB3D threat model enables the prioritization of mitigations through categorization into levels (fundamental, intermediate, advanced). This allows for a gradual implementation.
The EMB3D threat model is aligned with standards. The mitigations are mapped to the security controls specified in the ISA/IEC 62443-4-2 standard for industrial control systems.
The EMB3D threat model is complementary to the SPARTA framework. It helps propose additional mitigations, allowing to create a consolidated list of security measures.
Next steps to go further
After identifying the mitigations and countermeasures proposed by the EMB3D threat model, here are the next steps you can take.
The next step in the study will be to verify if the countermeasures proposed by the EMB3D threat model can be embedded on the OPS-SAT system and can effectively prevent all the actions carried out by the team.
The next step can be also to develop an implementation plan and a roadmap to implement the selected mitigations, considering technical and operational constraints.
We could also do a comparative analysis by comparing the mitigations proposed by the EMB3D threat model and the SPARTA framework to check their relevance and to identify overlaps and differences. This will allow to create a consolidated list of security measures.
Acknowledgments
Many thanks to ESA, to the CYSAT conference and to the Thales team for making this experiment possible, and for making it so enriching for the community.
A big thank you also to the SPARTA team, who inspired this article and contribute to strengthening the cybersecurity of satellites and space systems.