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
This article is part of a series of articles on the analysis of the Thales satellite hacking demo at CYSAT 2023 with the METEORSTORM™ framework and the AI-CoPilot.
Recently, I discovered the METEORSTORM™ framework built by EthicallyHackingspace (eHs)®. I was lucky to be offered a preview of how to use this new framework by participating in and successfully completing a challenge exam which is still in beta version. The success of this exam allowed me to obtain the certification: Full Spectrum Space Cybersecurity Professional (SCOR Practitioner).
As I now know how to use the METEORSTORM™ framework correctly, I propose to show, in this series of articles, how I used the METEORSTORM™ and its AI Copilot to:
- break down the experiment of Thales satellite hacking demo at CYSAT 2023,
- design the Threat Model with known and theoretical attack paths,
- record resilience and possible counter measures,
- identify detection measures,
- model Indicators of Compromise (IoC) and Recovery Resilience for the Incident Response Preparation phase.
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.
On my side, I have also already conducted an analysis of the Thales satellite hacking demonstration (full article here) but using the MITRE EMB3D™ framework.
The goal with this series of articles is to go further by using METEORSTORM™, a modeling and analytic framework purpose-built to assess and enhance resilience across converged space systems.
Hacking demo at CYSAT 2023: what was the point again
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.
What is OPS-SAT
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.
What is METEORSTORM™
METEORSTORM™ stands for Multiple Environment Threat Evaluation of Resources, Space Threats, and Operational Risks to Missions.
METEORSTORM™ is a modeling and analytic framework purpose-built to assess and enhance resilience across converged space systems. Its core strengths include:
- Layered decomposition across physical environments, system segments, services, and assets.
- Analytic enrichment drawing from leading frameworks (e.g., MITRE ATT&CK™, D3FEND™, CAPEC™, ATLAS™, FIGHT™, EMB3D™, ESA Space Shield, Aerospace SPARTA, NIST SP 800-160 Vol. 1 & Vol. 2, and NIST SP 800-53).
- Support for hybrid architectures, including terrestrial, aquatic, aerial, orbital, and deep space domains.
The METEORSTORM™ framework is accompanied by a AI-Copilot platform. The AI Co-Pilot is an evolving assistant that guides real-time analysis and decomposition workflows.
The METEORSTORM™ framework is executed through six strict functions, each dependent on the prior, forming a traceable and enforced modeling sequence:
- Function One – Concept of Operations (CONOPS) : Models the nominal state of a space platform by enforcing layered decomposition: PCE (Primary Capability Environment), SEG (Segment), SVC (Service), AST (Asset), AN (Analytic Enrichment)
- Function Two – Threat Model : Models known/theoretical attack paths (AN: ATT) and resilience measures (AN: RES).
- Function Three – Detection Engineering : Transforms threats into detection logic using AN: DET and AN: IOA.
- Function Four – Incident Response Preparation : Models Indicators of Compromise (AN: IOC) and Recovery Resilience (AN: RES)
- Function Five – Adversary Management : Overlays real or theoretical adversaries to defined behaviors.
- Function Six – Commercial Hybrid Warfare Attribution : Final function. Attributes actions to dual-use or commercial actors.
EthicallyHackingspace (eHs)® is working on launching a certification portal in a few months. In the upcoming weeks a few other community professionals will be invited to participate in the exam challenge process until it is finalized in August.
To know more about the METEORSTORM™ framework, check our article here.
Analysis of OPS-SAT with Function One – Concept of Operations (CONOPS)
At this stage, we will model the OPS-SAT platform by decomposing it into its environment, segments, services, and assets to establish a traceable baseline before introducing threats.
Technical Features of OPS-SAT overview
- ARM-based onboard computer with 10× the power of standard ESA satellite computers.
- Reconfigurable software platform, allowing remote code uploads and flexible updates.
- Includes:
- Camera with high-resolution imagery.
- GPS receiver.
- S-band and UHF radios.
- AI processing onboard, and support for satellite cybersecurity research
Full decomposition of OPS-SAT is described in the following article
- OPS-SAT wikipedia page : https://en.wikipedia.org/wiki/OPS-SAT
- ESA website : https://www.esa.int/Enabling_Support/Operations/OPS-SAT
Below is the full METEORSTORM™ decomposition for OPS-SAT based on Function One: Concept of Operations (CONOPS) — fully compliant with the strict taxonomy, sequencing, and validation rules defined in the framework.
| Layer | Entry |
| PCE |
|
| SEG |
|
| SVC |
|
| AST |
|
Analysis of Thales hacking demo with Function Two – Threat Model (using attack paths AN: ATT only)
At this stage, in this article, for the moment, we will deconstruct the Thales experiment with METEORSTORM™ Function Two – Threat Model but only with attack paths using AN: ATT elements.
In the next article, we will compete the METEORSTORM™ Function Two – Threat Model with resilience measures using AN: RES elements.
In the other articles of this series, we will complete this article and build a full threat model by adding all the other functions of the METEORSTORM™ framework :
- Function Two – Threat Model : with resilience measures using AN: RES elements
- Function Three – Detection Engineering : Transforms threats into detection logic using AN: DET and AN: IOA.
- Function Four – Incident Response Preparation : Models Indicators of Compromise (AN: IOC) and Recovery Resilience (AN: RES)
- Function Five – Adversary Management : Overlays real or theoretical adversaries to defined behaviors.
- Function Six – Commercial Hybrid Warfare Attribution : Final function. Attributes actions to dual-use or commercial actors.
The figure below is showing a summary of the full attack flow used by the Thales team to conduct the attack on OPS-SAT.
Since the Thales OPS-SAT attack is multi-stage, we can model each phase as its own discrete AN: ATT element. This approach aligns with the METEORSTORM™ enforcement model and supports full traceability for detection and resilience mapping.
Here is the full, six-stage multi-vector attack path (AN: ATT: 00–05) for the OPS-SAT satellite hacking scenario. Each stage includes:
- Detailed descriptions
- Full SPARTA and EMB3D mappings
- Targeted METEORSTORM™ asset layer tags
Step 1: Unsafe Java deserialization (AN: ATT: 00 – Initial Access via 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.
With the METEORSTORM™ framework, this translates to:
| Layer | Entry |
| AN | AN: ATT: Attack Path: 00: Initial Access via Unsafe Java Deserialization |
| Description | Description: Attacker uploads a payload containing crafted serialized objects exploiting ESA’s experiment execution logic. |
| Source | Source: Mapped from
|
| Target | Target: AST: SO: Software: 00: ESA App Manager (NMF SDK) |
Step 2: Applications Binaries Modified (AN: ATT: 01 – Application Binary Modification)
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.
With the METEORSTORM™ framework, this translates to
| Layer | Entry |
| AN | AN: ATT: Attack Path: 01: Post-Upload Binary Modification of Payload |
| Description | Description: Modified the payload in-memory after upload, bypassing ESA signature enforcement to insert shell code. |
| Source | Source: Mapped from
|
| Target | Target: AST: FI: Firmware: 00: NMF Runtime Execution Kernel |
Step 3: Privilege escalation via the CAN bus (AN: ATT: 02 – 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.
With the METEORSTORM™ framework, this translates to
| Layer | Entry |
| AN | AN: ATT: Attack Path: 02: Privilege Escalation via CAN Bus Interface |
| Description | Description: Experiment abuses unsecured access to CAN bus to issue root-level commands bypassing sandbox. |
| Source | Source: Mapped from
|
| Target | Target: AST: HA: Hardware: 00: ARM-Based Onboard Computer |
Step 4: Persistence (AN: ATT: 03 – Persistence via Java Reverse Shell)
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.
With the METEORSTORM™ framework, this translates to
| Layer | Entry |
| AN | AN: ATT: Attack Path: 03: Reverse Shell Persistence Inside Payload |
| Description | Description: Attacker embedded a Java-based backdoor triggered via timing or command sequence, enabling session persistence. |
| Source | Source: Mapped from
|
| Target | Target: AST: SO: Software: 00: Experiment Execution Stack |
Step 5: OPS-SAT attack by tampering with camera and ADCS (AN: ATT: 04 – Operational Impact: Tampering with Camera & ADCS)
Once the team escalated as root and ensured persistency, they took control on the supervisor and the demo effects was achieved.
With the METEORSTORM™ framework, this translates to
| Layer | Entry |
| AN | AN: ATT: Attack Path: 04: Payload Tampering – Camera and ADCS Control |
| Description | Description: With elevated access, attacker issued unauthorized commands to alter imaging, navigation, and attitude data. |
| Source | Source: Mapped from
|
| Target | Target:
|
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
With the METEORSTORM™ framework, this translates to
| Layer | Entry |
| AN | AN: ATT: Attack Path: 05: Other potential effects (but non demonstrated) |
| Description | Description: Thales Group also identified additional potential impacts that could occur if attackers gain further access and maintain their presence, though these were not carried out. |
| Source | Source: Mapped from
|
| Target | Target:
|
Attack Path Summary Table
Here is a clean and structured table presenting all six stages of the OPS-SAT attack path (AN: ATT) mapped from SPARTA and EMB3D Technique(s).
| ID | Phase | Technique(s) – SPARTA / EMB3D Mapping (abbrev) | Target Asset |
|---|---|---|---|
| ATT:00 | Initial Access | Deserialization flaw (EX-0009, EX-0009.01, TID-326) | AST: SO: ESA App Manager |
| ATT:01 | Execution Modification | Binary tampering Post-Upload (IA-0001.02, IA-0006, RD-0003.01, RD-0004.02, TID-301/302/etc) | AST: FI: NMF Runtime |
| ATT:02 | Privilege Escalation | Privilege Escalation via CAN Bus (EX-0009.02, LM-0002, T1548, TID-114/412/204/219) | AST: HA: ARM-Based Computer |
| ATT:03 | Persistence | Persistence via Reverse Shell (PER-0002.02, TID-304/305/203/202/307/308) | AST: SO: Experiment Execution |
| ATT:04 | Impact | Camera/ADCS tampering (EX-0007.02) | AST: HA: ADCS, GPS, Optical Sensors |
| ATT:05 | Other potential effects | Modeled Additional Impacts like Eavesdropping, Deception (EX-0012.08, EX-0012.09, EXF-0003, IMP-0001) | AST: DA, SI, HA (SDR & Optics) |
Next steps to go further
After modeling the nominal state of the OPS-SAT platform with Function One – Concept of Operations (CONOPS) and after Threat Modeling the system with known and theoretical attack paths, the next step of this series of articles is to record resilience measures.
At the end of this series, we will present the advantages of the METEORSTORM™ framework for a Satellite System. We will summarize the key benefits of applying this approach to space assets. We will consolidate our findings, highlight the added value of the METEORSTORM™ framework, and provide practical insights for system designers, cybersecurity architects, and mission planners.
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.
Congratulations to the ethicallyHackingspace (eHs)® team and William Ferguson for this amazing work!
