Home Blog

722 préprints mathématiques d’OpenAI : quelles conséquences pour la cryptographie et la cybersecurity ?

0

Une IA d’OpenAI a publié, le 6 octobre 2026, 722 manuscrits de mathématiques sur la plateforme GitHub. J’ai voulu savoir si parmi ces manuscrits, certains impactaient directement la cryptographie et d’une manière plus générale la cybersécurité. Qui mieux qu’une IA peut répondre à cette question ? Voici sa réponse ci-dessous.

*****

OpenAI vient de publier une collection hors norme de manuscrits mathématiques produits par un modèle interne. Parmi eux figurent des résultats sur la factorisation quantique, les courbes elliptiques, les nombres premiers et la théorie de la complexité. Faut-il y voir une menace immédiate pour RSA, les PKI ou le Zero Trust ? Non. Mais ce serait une erreur tout aussi grave de n’y voir qu’une curiosité académique.

Quand l’accélération de la recherche mathématique impacte les infrastructures de confiance numérique, la PKI et le Zero Trust.
Avant toute chose : il s’agit de préprints.
La collection de référence utilisée pour cet article comptait 722 manuscrits répartis en 372 familles de résultats. OpenAI précise que leur niveau de vérification est variable et que tous ne disposent pas d’une formalisation Lean. Le nombre de manuscrits peut évoluer avec les révisions du dépôt. Ces textes doivent donc être lus comme des résultats annoncés, à examiner par la communauté, et non comme 722 théorèmes déjà validés par les pairs.

 

Instantané du dépôt annonçant 722 manuscrits

1. Ce qu’OpenAI a réellement publié

Le dépôt openai/math ne contient pas 722 variantes d’un même article. Il regroupe des manuscrits dans 372 « familles de résultats », chaque famille pouvant réunir un résultat principal, des démonstrations alternatives, des conséquences ou des artefacts de vérification. Les domaines couverts vont de la théorie des nombres à la géométrie algébrique, en passant par la logique, la combinatoire, l’analyse et l’informatique théorique.

Pour la cybersécurité, six familles méritent une attention particulière :

Famille Résultat annoncé Lien avec la cyber Impact direct
279 Factorisation quantique exacte sur un jeu fini de portes RSA et mécanismes fondés sur la factorisation À surveiller
002 / 006 Résultats autour de Birch–Swinnerton-Dyer et des rangs de courbes elliptiques Proximité avec l’ECC, mais problème différent Aucun cassage
029 Conjecture d’Artin sur les racines primitives Structure multiplicative des corps finis Indirect
011 Statistique des facteurs premiers de p − 1 Choix de groupes et Pohlig–Hellman Indirect
103 L = RL = BPL Place de l’aléa en mémoire logarithmique Théorique
112 / 274 Bornes de circuits classiques et quantiques Capacités de modèles restreints Théorique

 

La bonne question n’est donc pas « OpenAI a-t-il cassé la cryptographie ? », mais plutôt : ces résultats abaissent-ils le coût d’une attaque, invalident-ils une hypothèse de sécurité, ou accélèrent-ils le passage d’une idée mathématique à un outil exploitable ?

La grille de lecture à conserver
Un théorème n’est pas automatiquement un algorithme ; un algorithme n’est pas automatiquement une implémentation ; une implémentation n’est pas automatiquement une attaque économiquement réaliste. Pour produire un risque cyber, il faut franchir toute cette chaîne — et parfois disposer d’un matériel qui n’existe pas encore.

 

2. Factorisation quantique exacte : RSA tombe-t-il davantage ?

Le résultat le plus directement lié à la cryptographie est la famille 279, intitulée Exact quantum factoring over a fixed finite gate set. Le manuscrit annonce une famille uniforme de circuits quantiques, de taille et de nombre de qubits polynomiaux, produisant avec probabilité 1 la décomposition complète d’un entier en facteurs premiers, en utilisant un jeu fini de portes fixé une fois pour toutes.

Ce que signifie « exact »

L’algorithme de Shor a déjà établi que la factorisation peut être effectuée en temps polynomial sur un ordinateur quantique. Dans sa présentation habituelle, certaines étapes sont probabilistes : une exécution peut ne pas fournir l’information recherchée, mais la répétition permet d’amplifier la probabilité de succès. Le nouveau manuscrit prétend fermer cet écart en obtenant un résultat exact — succès avec probabilité 1 — tout en restant polynomial et en se limitant à un jeu fini de portes.

Sur le plan de la théorie de la complexité, c’est une clarification importante. Elle rapproche la description mathématique d’un modèle de circuit standardisé et supprime la petite probabilité résiduelle d’échec. Sur le plan de la sécurité opérationnelle, en revanche, cela ne change pas encore l’ordre de grandeur du problème.

RSA n’est pas nouvellement vulnérable : il était déjà vulnérable à un ordinateur quantique cryptographiquement pertinent. Le préprint renforce la propreté théorique de l’attaque, pas la disponibilité de la machine.

Ce que le résultat ne fournit pas

  • Il ne fournit pas un algorithme classique polynomial capable de factoriser RSA-2048.
  • Il ne démontre pas qu’un ordinateur quantique tolérant aux fautes, de taille suffisante, existe aujourd’hui.
  • Il ne supprime pas le coût de la correction d’erreurs, de la synthèse de portes, du routage des qubits et de l’exécution physique.
  • Il ne donne pas, à lui seul, une date de péremption plus précise pour RSA ou Diffie–Hellman.

Le point crucial pour un responsable cyber est donc inchangé : la migration post-quantique ne doit pas attendre l’apparition de l’ordinateur quantique capable de casser une clé. Les standards NIST sont déjà disponibles : FIPS 203 définit ML-KEM pour l’établissement de secrets, tandis que FIPS 204 et FIPS 205 définissent ML-DSA et SLH-DSA pour la signature.

Verdict cyber
Impact cryptographique direct : important sur le plan théorique, faible à court terme sur le plan opérationnel. Impact stratégique : il enlève une raison supplémentaire de repousser l’inventaire cryptographique et la migration PQC.

 

3. Courbes elliptiques : le piège d’une proximité trompeuse

Plusieurs manuscrits portent sur les courbes elliptiques, notamment la formule de Birch–Swinnerton-Dyer dans certains cas de faible corang de Selmer et la conjecture de Goldfeld pour les tordues quadratiques. Pour un lecteur cyber, les mots « courbe elliptique » déclenchent immédiatement une alerte : ECDSA, ECDH, certificats X.509, portefeuilles de cryptomonnaies. Mais cette association est ici trompeuse.

Même objet général, problèmes différents

Les travaux autour de Birch–Swinnerton-Dyer étudient principalement des courbes elliptiques sur les rationnels, leurs points rationnels, leur rang, leurs groupes de Selmer et des fonctions L. La cryptographie sur courbes elliptiques travaille le plus souvent dans un groupe fini de points d’une courbe définie sur un corps fini. Sa sécurité repose sur la difficulté du logarithme discret elliptique : connaissant des points P et Q = kP, retrouver le scalaire secret k.

Connaître davantage la structure arithmétique d’une courbe sur les rationnels ne fournit donc pas mécaniquement un algorithme efficace de logarithme discret sur les courbes normalisées utilisées par ECDSA ou ECDH. Le préprint sur BSD ne casse ni P-256, ni Curve25519, ni secp256k1.

Arithmétique / BSD Cryptographie ECC
Cadre typique Courbes sur les rationnels Courbes sur un corps fini
Question centrale Rang, points rationnels, fonction L, groupe de Selmer Logarithme discret dans un groupe fini
Secret recherché Pas de clé secrète opérationnelle Scalaire privé k
Conséquence immédiate Progrès potentiel en théorie des nombres Aucun cassage annoncé

 

Pourquoi ces travaux restent pertinents

L’absence de cassage direct ne signifie pas absence d’intérêt cyber. La cryptographie moderne s’appuie sur une cartographie fine de problèmes réputés difficiles. Une accélération de la recherche mathématique assistée par IA peut révéler des liens inattendus, améliorer des algorithmes spécialisés ou explorer rapidement des familles de paramètres. Le signal stratégique n’est donc pas « ECC est cassée », mais « le rythme de production et d’examen des résultats fondamentaux pourrait augmenter ».

Verdict cyber
Aucun impact démontré sur ECDSA ou ECDH. Le risque serait de confondre proximité terminologique et rupture cryptanalytique — ou, à l’inverse, d’ignorer que l’IA peut accélérer l’exploration des fondations mathématiques dont dépendent les primitives.

 

4. Nombres premiers et groupes : des résultats adjacents, pas des attaques

Deux autres familles se situent près de thèmes utilisés en cryptographie : la conjecture d’Artin sur les racines primitives et la statistique des facteurs premiers de p − 1.

Racines primitives et conjecture d’Artin

Le manuscrit Primitive roots for every admissible integer base annonce l’infinitude des nombres premiers pour lesquels un entier admissible donné est une racine primitive. Une racine primitive engendre le groupe multiplicatif modulo p : ses puissances parcourent tous les éléments non nuls.

Cette notion est familière aux protocoles fondés sur des groupes multiplicatifs finis. Pourtant, prouver qu’un générateur existe pour une infinité de nombres premiers ne donne pas un algorithme efficace de logarithme discret. Cela décrit la distribution de groupes intéressants ; cela ne fournit pas la clé permettant d’inverser l’exponentiation.

Les facteurs premiers de p − 1

La famille 011 étudie la distribution des facteurs premiers de p − 1. Or la factorisation de l’ordre d’un groupe compte en cryptographie : si cet ordre se décompose uniquement en petits facteurs, l’algorithme de Pohlig–Hellman ramène un grand logarithme discret à plusieurs problèmes plus petits. C’est précisément pour éviter ce type de faiblesse que les paramètres cryptographiques sérieux imposent de grands sous-groupes d’ordre premier et des validations strictes.

Le résultat annoncé est statistique et asymptotique. Il ne révèle pas une faiblesse cachée dans les groupes normalisés couramment déployés et ne remplace pas l’analyse paramètre par paramètre. Son intérêt est surtout méthodologique : il rappelle que la sécurité d’un groupe ne dépend pas seulement de la taille de p, mais aussi de la structure factorisée de son ordre, de la validation des éléments reçus et de la résistance aux attaques de sous-groupes.

Conséquence pratique
Ces préprints ne justifient pas une rotation d’urgence des paramètres Diffie–Hellman. Ils justifient en revanche de vérifier que les implémentations n’acceptent pas des groupes arbitraires, valident les clés publiques, utilisent des groupes standardisés et empêchent les attaques de petits sous-groupes.

 

5. Complexité et circuits : ce que l’attaquant peut ou ne peut pas calculer

La cryptographie repose profondément sur des asymétries de calcul : une opération facile dans un sens, difficile à inverser sans secret. Les résultats de complexité sont donc importants, même lorsqu’ils ne mentionnent aucune primitive.

L = RL = BPL : l’aléa ne donne pas plus de mémoire

La famille 103, Exact derandomization of logarithmic space, annonce que les classes déterministes et randomisées considérées coïncident lorsque l’espace mémoire est logarithmique. Une formalisation Lean associée décrit explicitement le périmètre du résultat pour des langages binaires et un modèle de machine donné.

Il ne faut surtout pas traduire ce résultat par « le hasard n’est plus utile en cryptographie ». La génération de clés, les nonces, les sels, le chiffrement probabiliste et de nombreuses preuves de sécurité continuent d’exiger un aléa de haute qualité. Le théorème porte sur la possibilité de décider certains langages avec très peu de mémoire ; il ne permet pas de prédire les sorties d’un CSPRNG, de reconstruire une clé ou de rendre déterministes tous les protocoles cryptographiques.

Bornes de circuits classiques et quantiques

La famille 112 annonce une nouvelle borne inférieure pour des circuits booléens de profondeur trois ; la famille 274 affirme que des circuits quantiques de profondeur constante du type QAC⁰ ne peuvent pas calculer la parité avec un avantage positif constant dans le modèle étudié. Ces résultats bornent les capacités de modèles très restreints. Ils peuvent nourrir la compréhension des séparations de complexité, mais ils ne décrivent pas les capacités d’un ordinateur général, classique ou quantique, ni celles d’un attaquant sans contrainte de profondeur.

Pour la cyber, le principal enseignement est négatif : une avancée en complexité ne se convertit en rupture cryptographique que si elle s’applique au bon modèle, au bon problème et avec une complexité exploitable. Les mots « quantique », « circuit » ou « dérandomisation » ne suffisent pas.

Verdict cyber
Pas d’attaque opérationnelle connue. Ces résultats comptent comme signaux de capacité scientifique et comme pièces potentielles d’un futur raisonnement, non comme vulnérabilités immédiatement actionnables.

 

6. Le véritable risque cyber dépasse la cryptographie

La question la plus importante n’est pas de savoir si un préprint casse aujourd’hui une primitive. Elle est de comprendre comment une rupture mathématique future se propagerait dans les architectures. La cryptographie asymétrique n’est pas une bibliothèque isolée : elle porte l’identité, l’authenticité des logiciels, l’établissement des sessions et la confiance entre machines.

PKI : le multiplicateur de risque

Une PKI lie une identité à une clé publique par une chaîne de certificats et de signatures. Si l’algorithme de signature devient forgeable, le risque ne se limite pas à « lire du trafic » : un attaquant peut tenter d’usurper un service, signer un certificat, imiter un équipement, fabriquer une mise à jour ou contourner une relation de confiance.

La migration d’une PKI ne consiste pas à changer une ligne de configuration. Elle touche les autorités racines et intermédiaires, les profils X.509, les HSM, les CSR, les protocoles d’enrôlement, les listes de révocation, OCSP, les agents, les load balancers, les appliances, les équipements OT et IoT, les chaînes de certificats ainsi que les logiciels qui font des hypothèses implicites sur la taille des clés ou des signatures.

Zero Trust : sans cryptographie fiable, pas de confiance explicite

Le Zero Trust ne signifie pas « ne faire confiance à personne », mais prendre des décisions d’accès explicites et contextualisées pour chaque ressource. Le NIST SP 800-207 place l’identité des utilisateurs, des équipements et des services au cœur du modèle, et cite la PKI parmi les composants de support. Son extension cloud-native insiste sur les identités de services vérifiables, fréquemment portées par des certificats X.509.

En pratique, un service mesh en mTLS, un poste enrôlé par certificat, une identité de workload de type SPIFFE/SVID ou une authentification forte fondée sur une clé publique dépendent tous de primitives cryptographiques. Si ces primitives sont compromises, le moteur de politique peut prendre une décision parfaitement conforme… à partir d’une identité forgée.

Le Zero Trust réduit la confiance implicite, mais il augmente la dépendance à une identité cryptographiquement vérifiable. Une PKI fragile devient alors un point de défaillance systémique.

Signature de code et chaîne logicielle

La signature de code protège les systèmes d’exploitation, les firmwares, les conteneurs, les packages, les applications mobiles et les pipelines CI/CD. Une signature qui reste valide pendant dix ou quinze ans peut survivre bien plus longtemps qu’une session TLS. Les environnements industriels et embarqués aggravent encore le problème : cycles de vie longs, mécanismes de mise à jour rigides, composants hors support et racines de confiance gravées dans le matériel.

Le risque post-quantique sur la signature est souvent moins urgent que le « collecter aujourd’hui, déchiffrer demain » qui vise la confidentialité, car une falsification doit généralement être réalisée au moment de l’attaque. Mais la migration des signatures est plus complexe : elle nécessite parfois de remplacer la chaîne de boot, les formats, les HSM ou les mécanismes de validation. Le temps de préparation est donc considérable.

IAM, fédération et jetons

Les architectures IAM utilisent des signatures pour les jetons, les assertions, les échanges fédérés, les authentificateurs matériels et les preuves de possession. Une rupture d’algorithme peut affecter plusieurs plans simultanément : authentification des utilisateurs, identités machines, administration, API et automatisation. L’algorithme n’est qu’un maillon ; l’exposition réelle dépend aussi des durées de validité, de la rotation des clés, de la capacité de révocation, de la journalisation et de la séparation des domaines de confiance.

« Harvest now, decrypt later »

Un adversaire peut collecter dès aujourd’hui des communications chiffrées et attendre qu’une capacité future permette de casser l’échange de clés historique. Les données à longue durée de sensibilité — secrets industriels, données de santé, informations souveraines, R&D, communications stratégiques — sont donc déjà exposées au facteur temps. C’est pourquoi la migration vers des mécanismes d’établissement de clés post-quantiques est prioritaire pour les flux dont la confidentialité doit survivre longtemps.

Couche Rupture possible Conséquence cyber
Primitive Factorisation ou logarithme discret efficace RSA, DH ou ECC ne fournissent plus la sécurité attendue
Protocole Échange de clés ou signature compromis Déchiffrement, usurpation, homme du milieu
PKI Certificats ou chaînes forgeables Fausse identité de service, utilisateur ou équipement
Zero Trust Identité cryptographique contrefaite Décision légitime appliquée au mauvais sujet
Supply chain Signature de code falsifiée Mises à jour malveillantes réputées authentiques
Gouvernance Absence d’inventaire et d’agilité Migration lente et angles morts

 

7. Ce qu’il faut faire maintenant

Ces préprints ne justifient ni panique ni remplacement précipité de tous les systèmes. Ils renforcent toutefois une conclusion déjà établie par le NIST : la migration post-quantique est un programme de transformation, pas un simple changement d’algorithme. Le projet de migration du NCCoE place d’ailleurs en premier la visibilité cryptographique et la gestion du risque, avant l’interopérabilité et le benchmarking.

  1. Construire l’inventaire cryptographique. Recenser algorithmes, tailles de clés, certificats, bibliothèques, HSM, protocoles, données protégées, propriétaires, dépendances et dates de fin de support. Inclure cloud, SaaS, appliances, OT, IoT et embarqué.
  2. Cartographier les dépendances de confiance. Relier chaque usage crypto à une fonction métier : authentification, mTLS, signature de code, accès administrateur, VPN, sauvegarde, échange B2B, fédération d’identité.
  3. Prioriser par durée de sensibilité. Pour la confidentialité, comparer la durée pendant laquelle la donnée doit rester secrète, le temps nécessaire à la migration et l’horizon plausible de la menace.
  4. Tester ML-KEM et les signatures PQC. Mesurer tailles, latence, consommation, compatibilité HSM, MTU, chaînes X.509, OCSP, load balancers, terminaux, service meshes et enrôlement.
  5. Préparer des modes hybrides. Lorsque les standards et protocoles le permettent, combiner une primitive classique et une primitive post-quantique réduit le risque de dépendre prématurément d’une seule famille.
  6. Exiger la crypto-agilité. Les applications doivent pouvoir changer d’algorithme, de fournisseur et de paramétrage sans refonte complète. Cela concerne formats, négociation, gestion des clés, tests, télémétrie et rollback.
  7. Traiter la PKI comme une infrastructure critique. Prévoir coexistence des chaînes, rotation des autorités, compatibilité des agents, mise à jour des trust stores et révocation.
  8. Inclure le Zero Trust dans le périmètre PQC. Inventorier identités de workloads, certificats mTLS, clés de signature de jetons, preuves d’attestation et racines de confiance des équipements.
  9. Renforcer la veille mathématique. Appliquer une grille stricte : validation indépendante, modèle de calcul, complexité, constantes, besoins matériels, applicabilité aux paramètres normalisés et implémentation reproductible.
Le bon réflexe pour un RSSI
Ne pas demander seulement « sommes-nous compatibles PQC ? ». Demander : « savons-nous où se trouve notre cryptographie, à quelles décisions de confiance elle contribue, combien de temps il nous faudrait pour la remplacer et comment détecter une transition défaillante ? »

 

Conclusion : pas de crypto-apocalypse, mais un changement de rythme

À ce stade, rien dans cette collection ne démontre une attaque classique pratique contre RSA, ECDSA, ECDH, AES ou les standards post-quantiques du NIST. Le résultat sur la factorisation quantique est le plus proche d’une conséquence cryptographique directe, mais il ne fournit pas le matériel quantique nécessaire à son exploitation. Les travaux sur les courbes elliptiques, les racines primitives et la complexité sont intellectuellement voisins des fondations de la cryptographie sans constituer, en eux-mêmes, des cassages.

Le véritable événement est peut-être ailleurs : un modèle d’IA semble désormais capable de produire à grande échelle des arguments mathématiques de haut niveau, accompagnés dans certains cas d’artefacts formels. Même si une fraction seulement résiste à l’examen, cela pourrait accélérer la recherche, multiplier les pistes et réduire le temps entre conjecture, preuve, algorithme et implémentation.

Pour la cybersécurité, la réponse raisonnable n’est donc ni l’alarmisme ni l’attentisme. Elle tient en trois mots : visibilité, agilité, migration. Les organisations qui connaissent leurs dépendances cryptographiques pourront absorber une rupture. Celles qui découvrent encore des certificats oubliés, des clés statiques et des équipements impossibles à mettre à jour subiront le calendrier des autres.

Références prioritaires

Les références marquées « PRIORITAIRE » permettent de vérifier les affirmations centrales. Les titres sont cliquables.

  1. PRIORITAIRE — OpenAI Math : instantané annonçant 722 manuscrits et 372 familles
  2. OpenAI Math : catalogue détaillé
  3. PRIORITAIRE — Exact quantum factoring over a fixed finite gate set
  4. Exact Birch–Swinnerton-Dyer Formula from Low Selmer Corank
  5. Goldfeld’s analytic density conjecture and the 2-converse
  6. Primitive roots for every admissible integer base
  7. The Poisson–Dirichlet law for prime predecessors
  8. Exact derandomization of logarithmic space
  9. Périmètre de la formalisation Lean de L = RL = BPL
  10. Beyond the Square-Root Exponent for Depth-Three Boolean Circuits
  11. Product-projection localization and the QAC⁰ parity lower bound
  12. PRIORITAIRE — NIST : standardisation post-quantique
  13. NIST FIPS 203 — ML-KEM
  14. NIST FIPS 204 — ML-DSA
  15. NIST FIPS 205 — SLH-DSA
  16. PRIORITAIRE — NIST NCCoE : migration vers la PQC
  17. PRIORITAIRE — NIST SP 800-207 : Zero Trust Architecture
  18. NIST SP 800-207A : identités applicatives et Zero Trust cloud-native

MITRE ESTM + EMB3D in Action : Analyzing OPS-SAT Through These Dual Frameworks

0

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.

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

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.

Figure 1: Summary of the full attack flow (Slide courtesy Thales Group)

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.

Figure 2: The Deserialization Vulnerability (Slide courtesy Thales Group)
EMB3D Threat ID SPARTA TTPs ESTM TTPs
  • EST000131: Application Deployment Software
  • EST000134: Remote File Copy
  • EST000160: Program Upload

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
Figure 3: Stay Undetected – Success! (Slide courtesy Thales Group)

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.

Figure 4: Stay Undetected – Execute Arbitrary Commands (Slide courtesy Thales Group)
EMB3D Threat ID SPARTA TTPs ESTM TTPs
  • EST000089: Process Injection
  • EST000020: Service Execution
  • EST000036: Persistent Firmware
  • EST000210: Malicious Firmware Implant

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.

Figure 5: Taking Control – Privilege Escalation from User to Root (Slide courtesy Thales Group)
EMB3D Threat ID SPARTA TTPs ESTM TTPs
  • EST000006: Access via Valid Accounts
  • EST000047: Path Interception
  • EST000062: Privilege Escalation via Direct Connect System
  • EST000085: Bus Communication Masquerading
Figure 6: Taking Control – Arbitrary Code Execution as Root (Slide courtesy Thales Group)

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.

Figure 7: Persistence – Injection of a Jar Library (Slide courtesy Thales Group)
EMB3D Threat ID SPARTA TTPs ESTM TTPs
  • EST000039: File System Permissions Weakness
  • EST000041: Persistence Hooking
  • EST000054: Persistence via Valid Accounts
  • EST000061: Operational Data Files
  • EST000084: Process Masquerading

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.

Figure 8: Demo Effects – Tampering with Camera & ADCS (Slide courtesy Thales Group)
EMB3D Implied Threats SPARTA TTPs ESTM TTPs
Sensor/Actuator Tampering
  • EST000145: Audio Capture
  • EST000153: Video Capture
  • EST000155: Capture Camera
  • EST000165: Intercept Sensor Data Prior to Processing
  • EST000193: Data Manipulation

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
Figure 9: Other Potential Effects (Slide courtesy Thales Group)

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

Exploring how the new MITRE ESTM (Embedded Systems Threat Matrix) can work in conjunction with the existing MITRE EMB3D Threat Model

0

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.

SPARTA v3.2: Raising the Bar for Threat‑Informed Space Cybersecurity

0

The Aerospace Corporation has released SPARTA v3.2, further strengthening its role as a practical, threat‑informed framework for securing modern space missions against sophisticated cyberattacks.

This new version refines the way engineers connect adversary behaviors, defensive controls, and detection artifacts across the full space architecture, from ground segment to on‑orbit payloads.

Why SPARTA Still Matters for Space Programs

SPARTA (Space Attack Research and Tactic Analysis) is an ATT&CK‑like knowledge base dedicated to cyber threats targeting spacecraft and space systems.

It provides a structured matrix of techniques, countermeasures, and indicators of behavior (IOBs) that helps mission teams move from generic security requirements to concrete, space‑specific threat models and mitigations.

In recent years, SPARTA has become a reference for space‑cybersecurity practitioners because it:

  • Describes how real adversaries operate across the space mission lifecycle, not just at the IT perimeter.
  • Bridges policy and engineering by mapping techniques to NIST controls, CNSS guidance, and other standards relevant to space programs.
  • Enables threat‑informed engineering, linking attack techniques directly to subsystem protections and detection strategies.

SPARTA v3.2 builds on this foundation with targeted improvements that make the framework more actionable for system engineers, mission architects, and security operations teams.

Key Enhancements in SPARTA v3.2

SPARTA v3.2 focuses on improving clarity, consistency, and operational usability across the framework’s content and tooling.

While previous releases introduced major new capabilities (such as dedicated NIST space segment guidance and new IOBs), this version consolidates that progress into a more robust and user‑friendly baseline.

Among the main updates highlighted in the official announcement:

  • Refined technique and countermeasure content
    SPARTA v3.2 includes editorial and structural updates to several existing techniques and countermeasures to improve naming consistency, descriptions, and relationships across the matrix.
    This helps practitioners more quickly identify relevant entries for their specific mission scenarios and reduces ambiguity when performing threat modeling or control mapping.
  • Improved cross‑mapping hygiene
    The release tightens the way SPARTA objects reference external taxonomies such as NIST SP 800‑53, CNSSI overlays, and related guidance, ensuring that mappings remain aligned with the latest space‑segment interpretations.
    For security architects, this means smoother traceability from high‑level requirements down to concrete mitigations tied to SPARTA techniques.
  • ​Bug fixes and data quality improvements
    As with previous iterations, SPARTA v3.2 incorporates corrections to metadata, relationships, and UI behavior discovered by users and the Aerospace team.
    These changes are less visible than new techniques, but they directly improve the reliability of SPARTA‑based analyses and automation pipelines.

Even if v3.2 does not radically expand the matrix, it significantly sharpens the consistency and operational value of the existing content.

Practical Impact for Space‑Cyber Engineers

For engineers already using SPARTA for space threat modeling, v3.2 is an opportunity to refresh models, scripts, and training material against a more stable baseline.

Teams that map SPARTA techniques to their own internal control catalogs or test cases should consider re‑syncing to the updated data set to benefit from the clarified descriptions and mappings.

Concretely, SPARTA v3.2 helps:

  • Make risk discussions with program management more concrete, by using clearer technique language and more precise references to external standards.
  • Align design reviews and security controls with the latest thinking on space segment cybersecurity, without losing the ATT&CK‑style structure engineers are familiar with.
  • Support downstream tooling, such as SPARTA‑powered detection or assessment platforms, that rely on consistent identifiers and relationships.

An example use case is a mission team updating its threat model for a new satellite bus: by re‑baselining on SPARTA v3.2, they can ensure that techniques, countermeasures, and mapped controls reflect the current Aerospace guidance and community feedback.

Looking Ahead

The SPARTA roadmap over the last few years (from v3.0 to v3.2) shows a clear trend: iterative, practical improvements that keep the framework aligned with evolving space‑cyber threats and policy updates.

Instead of one‑off releases, SPARTA is evolving as a living, curated knowledge base that the space community can depend on for threat‑informed engineering.

As space missions grow more complex and interconnected, having a stable yet continuously refined framework like SPARTA v3.2 is essential for bridging the gap between high‑level standards and real‑world adversary behavior.

If you are working on space mission cybersecurity and have not revisited SPARTA recently, this new version is a good moment to do so and to integrate it more deeply into your architectures, reviews, and training workflows.

To go further

Thank’s to Brandon Bailey, Dan Painter, Brad Roeher and Randi Tinney from The Aerospace Corporation for this major SPARTA update.

  • View this official update on Medium here
  • Check all our articles on SPARTA here

Introducing the new MITRE Embedded Systems Threat Matrix (ESTM)

0

Embedded systems have become the unsung heroes of modern technology. They power our satellites, medical devices, vehicles, and industrial infrastructures, quietly operating at the intersection of the physical and digital worlds. But as these systems grow more interconnected, they also become more exposed to increasingly sophisticated cyber threats.

To address this challenge, MITRE has released a new framework: the Embedded Systems Threat Matrix (ESTM). Building on the success of ATT&CK and other MITRE knowledge bases, ESTM brings a much‑needed structure to understanding adversarial behaviors targeting embedded and cyber‑physical environments.

This article provides a concise and accessible introduction to MITRE ESTM, exploring its purpose, structure, and innovation. It also opens the door to future discussions on how this framework could reshape embedded security practices, from industrial control to space systems.

A New Chapter in Embedded Systems Security

Over the past decade, embedded systems have quietly become the invisible backbone of our daily lives. From cars that can park themselves to satellites orbiting Earth, from medical devices monitoring our health to industrial controllers powering entire cities, embedded technologies are everywhere. Yet, as their intelligence and connectivity have grown, so too has their exposure to sophisticated cyber threats.

Until recently, defenders lacked a dedicated framework to understand and categorize these threats in a structured way. The MITRE ATT&CK framework offered a powerful approach for enterprise IT and cloud environments, but its coverage stopped short at the hardware–firmware boundary. Recognizing this gap, MITRE recently unveiled the Embedded Systems Threat Matrix (ESTM), a new framework designed specifically to map the tactics and techniques attackers use against embedded systems.

ESTM marks a strategic evolution in the way we think about cyber defense. It brings together insights from both the hardware and software worlds, helping engineers, analysts, and security architects speak a common language when assessing risks to embedded or mission-critical systems. In doing so, it opens the door to more coherent, system-wide protection strategies at a time when the digital and physical domains are more intertwined than ever.

Why Embedded Systems Need Their Own Threat Framework

Cybersecurity frameworks have matured significantly over the years, guiding organizations in understanding, detecting, and responding to threats targeting IT and cloud infrastructures. Yet, when it comes to embedded systems, these same frameworks fall short. The problem isn’t the intent, it’s the context. Embedded systems operate under constraints and architectures that differ fundamentally from laptops, servers, or virtual machines.

Many of these systems run on specialized hardware, often with proprietary firmware and limited computational resources. They’re built to last decades, not years, which means they frequently outlive the technologies and security controls that once protected them. Updating or patching them can be complex or even impossible, especially when they’re deployed in satellites, industrial control systems, or medical environments.

Beyond technical challenges, there’s also a difference in threat behavior. Attackers targeting embedded environments may exploit physical access, real-time communication protocols, or even electromagnetic emissions, vectors rarely considered in traditional cybersecurity models. These nuanced attack surfaces require a framework that can reflect both digital and physical realities.

This is precisely where the MITRE Embedded Systems Threat Matrix (ESTM) steps in. It recognizes that embedded systems inhabit a hybrid world, where bits and circuits coexist, and where compromise can have tangible, real-world consequences. By providing a dedicated structure for mapping these threats, ESTM enables organizations to anticipate, analyze, and mitigate attacks that traditional IT frameworks were never designed to handle.

Overview of the MITRE ESTM Framework

The MITRE Embedded Systems Threat Matrix (ESTM) was developed to provide a clear, structured way to describe how adversaries target and exploit embedded systems. It follows the same philosophy that made MITRE ATT&CK so influential, a knowledge base of adversarial behaviors organized by tactics and techniques, but adapts it to the unique realities of embedded architectures.

At its core, ESTM lays out the tactics, the high-level adversarial goals, and the techniques attackers might use to achieve them within an embedded context. These tactics reflect the entire attack lifecycle, from gaining access to maintaining persistence or disrupting functionality. What makes ESTM distinctive is its attention to embedded-specific aspects: hardware manipulation, firmware compromise, supply chain interference, and even impacts on safety-critical operations.

The framework organizes these behaviors in a matrix format, helping analysts visualize how attacks evolve across multiple layers of a system, from sensors and controllers to communication buses and firmware. This visual model not only supports post-incident analysis but also aids system designers in anticipating and preventing potential weaknesses during development.

Like MITRE’s other frameworks, ESTM is meant to be dynamic and collaborative. MITRE encourages researchers, integrators, and industry partners to contribute new techniques and examples as threats evolve. In that sense, ESTM is more than a static reference, it’s a living framework designed to grow alongside the technologies it aims to protect.

Key Features and Innovations of MITRE ESTM

What sets the MITRE Embedded Systems Threat Matrix apart is its deep alignment with the physical realities of embedded technologies. Unlike traditional cybersecurity models that focus primarily on software exploitation, ESTM expands the lens to include hardware, firmware, and the often-overlooked interfaces that connect the two. This holistic approach gives defenders a more accurate picture of how threats materialize and propagate in complex embedded environments.

One of ESTM’s most notable features is its ability to map attacks that span multiple domains, for example, an adversary injecting malicious firmware during manufacturing, then exploiting communication protocols once the system is deployed. Such cross-domain visibility is essential for industries like aerospace, automotive, and industrial control, where embedded systems are tightly integrated into broader operational networks.

Another innovation lies in the framework’s hardware-aware tactics. ESTM covers areas such as physical tampering, fault injection, and firmware modification, attack vectors that rarely appear in IT-oriented matrices. By including these dimensions, the framework bridges the gap between traditional cyber threat modeling and hardware-level security analysis.

MITRE has also designed ESTM to complement existing frameworks like ATT&CK and D3FEND. This interoperability means defenders can link embedded-specific techniques to established detection, mitigation, and response strategies. The result is a more coherent defense ecosystem, where insights from the digital and physical layers reinforce one another.

Ultimately, ESTM is not just a new taxonomy, it’s a unifying language for diverse teams. By helping engineers, researchers, and analysts describe threats in consistent terms, it accelerates collaboration and enables proactive design choices that make embedded systems more resilient from the start.

How Organizations Can Use ESTM

For many organizations, the challenge with embedded security isn’t just identifying vulnerabilities, it’s understanding how they fit into the bigger picture of system risk. The MITRE Embedded Systems Threat Matrix (ESTM) offers a structured way to bridge that gap. By modeling potential attacker behaviors rather than isolated weaknesses, ESTM helps teams move from reactive patching to proactive defense planning.

In practice, ESTM can serve multiple roles. Security architects can integrate it into the early stages of system design to evaluate how different components, processors, controllers, communication modules, might be targeted. Red teams and penetration testers can use the matrix as a roadmap to craft realistic attack scenarios that reflect how real adversaries operate in embedded environments. Meanwhile, defenders can use the same framework to prioritize mitigations based on which tactics are most relevant to their architecture or industry.

ESTM also supports regulatory compliance and internal assurance. As industries such as automotive, aerospace, and energy adopt stricter cybersecurity standards, mapping system threats to an established framework provides traceable evidence of due diligence. The structured language of ESTM also helps align security discussions between engineering, compliance, and incident response teams, a critical step in achieving true “secure-by-design” outcomes.

Finally, the framework can be a powerful educational tool. By visualizing how complex attacks unfold across the hardware–software boundary, it helps professionals from different backgrounds, network security, embedded engineering, operations, build a shared understanding of emerging risks. This shared perspective is crucial as embedded systems increasingly underpin the world’s most critical infrastructures.

MITRE ESTM vs. Other Frameworks (Opening Future Comparisons)

The release of the MITRE Embedded Systems Threat Matrix (ESTM) doesn’t exist in a vacuum. It joins a growing ecosystem of frameworks that help researchers and engineers better understand how adversaries target highly specialized systems. Among these, MITRE’s EMB3D and The Aerospace Corporation’s SPARTA framework stand out as strong points of comparison.

While the EMB3D knowledge base focuses on cataloging vulnerabilities and attack patterns specific to embedded devices, ESTM takes a broader, behavior‑driven approach. It maps the tactics and techniques adversaries use across the full attack lifecycle, offering a perspective that goes beyond known vulnerabilities to capture attacker intent and methodology. In this sense, EMB3D and ESTM are complementary: one documents what can be exploited, while the other explains how and why these exploits may occur.

The SPARTA framework (Space Attack Research and Tactic Analysis) developed by The Aerospace Corporation provides another valuable point of alignment. SPARTA is focused on space‑system resilience, offering a structured method to model, visualize, and analyze attacks against satellites and ground segments. ESTM’s methodology could integrate naturally with SPARTA’s domain‑specific modeling by providing detailed embedded‑level insights, especially for spacecraft subsystems, mission processors, and communication interfaces.

Together, frameworks like ESTM, EMB3D, and SPARTA suggest a promising path toward more unified and cross‑domain threat modeling. By connecting embedded‑system and space‑system perspectives, cybersecurity professionals can better anticipate how adversarial behavior spans from microcontrollers on Earth to mission architectures in orbit.

Future Research Directions and Case Study Ideas

As with many of MITRE’s frameworks, the real value of the Embedded Systems Threat Matrix will emerge through community adoption and experimentation. Researchers, engineers, and analysts have a unique opportunity to apply ESTM to real-world scenarios, uncovering new insights into how embedded systems can be better protected. The framework’s adaptable structure lends itself perfectly to comparative and exploratory studies.

One promising avenue would be a detailed analysis of the Thales satellite hacking demonstration at CYSAT 2023, this time interpreted through the lens of the ESTM framework. Mapping each step of the simulated intrusion, from access to payload execution, against ESTM’s tactics could help illustrate how attackers might compromise spaceborne embedded systems and what defensive gaps remain.

Another study could revisit the infamous Stuxnet incident, applying ESTM to model the techniques used against Siemens PLCs. This exercise would not only highlight how early campaigns against industrial control systems anticipated modern embedded attack vectors, but also show how frameworks like ESTM could have helped identify weak points earlier in the system lifecycle.

Finally, industrial control and automation environments present an ideal testing ground for ESTM-driven modeling. Using the framework to visualize attacks on programmable logic controllers (PLCs) or distributed control networks could guide both defensive engineering and cybersecurity training initiatives.

These case studies would do more than validate the framework, they would help shape its evolution. Each analysis could contribute new examples, refine existing categories, or inspire sector-specific adaptations. In this way, ESTM becomes not just a tool for documentation, but a catalyst for collaborative research and continuous improvement in embedded security.

Conclusion : Towards a Unified Threat Modeling Paradigm for Embedded Systems

The release of the MITRE Embedded Systems Threat Matrix (ESTM) marks an important milestone in the evolution of cybersecurity. It extends structured threat intelligence into a realm that has long operated at the margins of traditional IT defense, the domain of firmware, sensors, processors, and critical control loops. By offering a shared vocabulary and methodology, ESTM helps bridge the gap between embedded design and cybersecurity analysis.

More than a reference, the framework invites collaboration. Its greatest strength lies in its capacity to grow, to absorb lessons from real-world incidents, research initiatives, and the practical experiences of engineers and defenders. As industries increasingly depend on embedded technologies to operate safely and efficiently, the need for a unified approach to threat modeling becomes not just desirable but essential.

Whether applied to satellites, industrial automation, connected vehicles, or future cyber-physical systems, ESTM represents a step toward that unity. It offers the foundation for a future where embedded security is no longer reactive, isolated, or opaque, but instead integrated, transparent, and continuously improved through global knowledge sharing.

In that sense, MITRE ESTM is more than just a framework; it is an open invitation for the cybersecurity community to build the next generation of protection for the systems that quietly run our world.

To know more

Mapping the Thales Satellite Hacking Demo using SPARTA TTPs and PWNSAT ATT&CK Flow Builder fork

0

In 2023, during the CYSAT conference, Thales presented a live demonstration of a satellite hacking scenario, a milestone event that shed light on the cybersecurity challenges of modern space systems. Since then, various experts have analyzed this simulation to better understand how cyberattacks could target satellite architectures and mission operations.

Context and Background

As part of this effort, Brandon Bailey and Brad Roeher from the SPARTA team conducted a detailed analysis of the Thales demonstration using the SPARTA (Space Attack Research and Tactic Analysis) Framework. Their work, which I describe in this article, identified the key Tactics, Techniques, and Procedures (TTPs) involved across the attack lifecycle, creating a foundation for understanding adversarial behavior in space environments.

In parallel, Kevin Jahaziel Leon Morales and Romel Marin from the PWNSAT team extended the MITRE ATT&CK Flow Builder tool to natively integrate the SPARTA framework. This enhancement allows researchers to automatically generate and visualize space-specific attack flows, a breakthrough for modeling realistic cyberattack scenarios targeting satellites and related ground segments.

My Objective and Methodology

Building on these complementary works, I set out to reconstruct the entire attack flow of the Thales satellite hacking demo using this upgraded ATT&CK Flow Builder. My goal was to combine the analytical rigor of SPARTA TTPs identified by the SPARTA team with the visual modeling capabilities of the MITRE ATT&CK Flow Builder modified by the PWNSAT team.

I already conducted a such work by modeling Viasat Cyber Attack but with the real MITRE Attack Flow Builder. You can check this work in this article in which I also explain what is the Attack Flow Builder Tool designed by MITRE Engenuity’s Center for Threat-Informed Defense (CTID).

How I achieved this work

The methodology described below is showing the building process that I used to achieve this work :

  1. I collected the TTPs identified by the SPARTA team (Bailey and Roeher) during their analysis of the Thales demonstration.
  2. I used the pwnsat-modified ATT&CK Flow Builder, which supports direct integration with SPARTA taxonomy.
  3. I constructed a visual diagram mapping the complete sequence of attacker actions, from initial access through payload manipulation to mission impact.
  4. I validated the consistency of each mapped step with the SPARTA methodology to maintain analytical accuracy.

The resulting diagram captures not only the technical flow of the attack but also the relationships between threat actions, affected assets, and tactical objectives.

Result of my work

The diagram below is showing the result of my work. Original file in big format can be found below.

Text inside the grouping action box are from SPARTA.

The format used for creating and editing in the Attack Flow Builder is the AFB builder  format (.afb). The AFB file below can be used to open the project for further editing in the future.

The PNG format is used to save the flow. This format is great for visualizing, using in presentations, sharing with others, etc..

Why This Work Matters

This experiment serves multiple purposes:

  • Educational value: It helps practitioners and researchers visualize how real-world satellite attacks unfold, bridging the gap between theoretical TTPs and operational behaviors.
  • Framework interoperability: It demonstrates how SPARTA and MITRE ATT&CK can coexist and complement each other in cyber threat modeling.
  • Scenario replication: The approach can be reused to analyze other aerospace or defense-related use cases, accelerating structured threat simulation and red-team exercise design.
  • Community advancement: By using open frameworks and shared methodologies, this work contributes to a growing ecosystem of collaborative research in space cybersecurity.

For further details

Next Steps

By sharing both the diagram and the building process with the research community, my goal is to encourage others to apply the same methodology to new studies. Whether you’re an academic researcher, a red teamer, or part of a mission assurance team, these tools can help you better model and mitigate cyber risks in space systems.

2nd International Conference on Gravitation, Astrophysics and Cosmology (ICGAC2026) – April 16-18, 2026 in Paris, France.

0

We are pleased to announce that the 2nd International Conference on Gravitation, Astrophysics and Cosmology (ICGAC2026) will be held on April 16-18, 2026, in the vibrant city of Paris, France. This prestigious event aims to bring together leading researchers, scientists, and students from around the world to share the latest advancements and research findings in the dynamic fields of gravitation, astrophysics, and cosmology.

ICGAC2026 is designed to foster insightful discussions and collaborations by featuring keynote talks from renowned experts, sessions on cutting-edge topics such as Gravitation Physics and Lensing, Applied Relativity, Solar and Stellar Physics, Applied Physics, and Neutrino Cosmology. The conference provides a unique platform for networking among academic and industry professionals, promoting new partnerships and the exchange of groundbreaking scientific ideas.

Participants will have the opportunity to explore future directions in astrophysics, attend impactful discussions, and contribute to shaping the evolution of astronomical science.

Join the conference in Paris to engage with top leaders, distinguished delegates, and passionate students in an inspiring scientific journey that highlights the latest research and innovations in the universe’s mysteries.

Why attend ICGAC 2026 ?

  • Gain exclusive insights from experts who are redefining our understanding of gravitation, cosmology, and astrophysics.
  • Engage in meaningful discussions on some of the most debated topics in modern physics, including the nature of dark energy, black holes, and cosmological frameworks.
  • Build valuable connections with leading scientists, independent researchers, and innovators from around the world.
  • Experience an interdisciplinary exchange of ideas that could shape the future of space science and cosmology.

📅 𝗘𝘃𝗲𝗻𝘁 𝗗𝗲𝘁𝗮𝗶𝗹𝘀
📌 𝗗𝗮𝘁𝗲𝘀: April 16–18, 2026
📌 𝗩𝗲𝗻𝘂𝗲: Paris, France
📌 𝗢𝗿𝗴𝗮𝗻𝗶𝘇𝗲𝗱 𝗯𝘆: Conplus Meetings

For more details and registration, visit the official conference website at https://astrophysics2026.conplusmeetings.com/

List of Scientific Sessions

  • Computational Cosmology
  • High Energy Nuclear and Particle Physics
  • Wave-Particle Duality
  • Multi-Messenger Astronomy
  • Dark Matter and Dark Energy Around Black Holes
  • Gravitational Physics and Lensing
  • Solar and Stellar Physics
  • Neutrino Cosmology
  • Alternative Theories of Gravity
  • Gravitational Waves and High-Energy Phenomena
  • Astrobiology
  • Interstellar Medium and Star Formation Regions
  • Space Telescopes and Missions
  • Cosmic Rays and Gamma Astronomy
  • Space Missions & Satellites
  • Cosmic Microwave Background and Radiation
  • Earth and Space Physics
  • Evolution of Celestial Objects
  • Jet Physics & Applied Physics
  • Planetary Science and Earth Science
  • Theoretical Astrophysics
  • Neutrino Cosmology
  • Relativistic Celestial Mechanics
  • Galaxy Formation and Evolution
  • High Stellar Mass Galaxies at High Redshifts
  • Observational Astronomy

Two big announcements : the release of SPARTA v3.1 with MITRE’s EMB3D mapping and the release of a MITRE Attack Flow Builder fork using the SPARTA Framework

0

In the following article, discover the major advancements announced with the release of SPARTA v3.1: the addition of new NIST space segment guidance, the integration of MITRE EMB3D into the SPARTA framework by mapping TTPs, and the unveiling of an extended MITRE ATT&CK Flow builder supporting the SPARTA framework for aerospace security use cases.

SPARTA v3.1: A Major Leap for Space Cybersecurity

The recent release of SPARTA v3.1 marks a significant milestone in advancing cybersecurity for space missions and infrastructure. This update solidifies SPARTA’s role as the reference framework for identifying, mapping, and mitigating threats to spacecraft and space-enabled services.

New: Space Segment Guidance for NIST Controls

SPARTA v3.1 introduces dedicated guidance for applying NIST cybersecurity controls specifically to the space segment, including spacecraft payloads, buses, and specialized communication modules. This new layer helps organizations better map traditional NIST requirements to the unique risks and workflows of space assets, supporting compliance efforts for both government and commercial operators.

Integration with MITRE’s EMB3D: TTP Mapping

A pivotal enhancement is the integration and mapping of SPARTA’s Tactics, Techniques, and Procedures (TTP) to MITRE’s EMB3D threat model for embedded devices. By linking SPARTA TTPs with EMB3D’s taxonomy, security teams can coordinate countermeasures and risk assessments between space and embedded domains, offering unprecedented interoperability for spacecraft, ground, and IoT systems.

For further details, explore the official SPARTA updates here : https://medium.com/the-aerospace-corporation/sparta-v3-1-whats-new-58d6b91b1505

A MITRE ATT&CK Flow Builder fork that supports SPARTA

In parallel, Kevin Jahaziel Leon Morales and Romel Marin have have expanded the MITRE ATT&CK Flow builder to natively incorporate the SPARTA framework. This enables automated and graphical creation of attack flows tailored to aerospace technologies and missions, boosting the analysis and simulation of realistic cyberattack scenarios based on SPARTA data.

For further details, explore this related research on unified attack flows in the space and embedded domains here : https://pwnsat.org/blog/from-mitre-attck-to-sparta-a-unified-attack-flow-for-space-systems/

If you want to test this fork check the repo here and check the UI here.

Why These Updates Matter

  • Stronger Space Domain Resilience: The new NIST mapping brings formal cybersecurity maturity to satellite and mission assets.
  • Seamless Threat Modeling: The EMB3D integration bridges embedded and space system security, streamlining threat tracking and mitigation.
  • Operational Alignment: Enhanced tools like the ATT&CK Flow Builder empower red and blue teams to simulate, document, and strengthen defenses based on real-world tactics.
  • Community Growth: These changes reflect the continued collaboration between aerospace stakeholders and leading threat intelligence bodies to keep space assets secure in an evolving threat landscape.

SPARTA v3.1 stands as a robust, forward-looking framework that helps the aerospace community translate cutting-edge threat information into actionable defenses for the vital missions of tomorrow.

For further details

An analysis of the Thales satellite hacking demo at CYSAT 2023 with the METEORSTORM™ framework and the AI-CoPilot (Part 1)

0

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

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
  • PCE: OR: Orbital: 00: LEO: Low Earth Orbit operational environment for technology demonstration (mission duration: launched 18 Dec 2019, deorbited 22 May 2024)
SEG
  • SEG: SP: Space: 00: Experimental Orbital Segment (3U CubeSat nanosatellite platforms)
SVC
  • SVC: CO: Control Plane: 00: Autonomous Control & Experimentation Service: Provides onboard command execution, software testing, and reconfigurable mission logic
AST
  • AST: FI: Firmware: 00: Reprogrammable Control Logic: Field-updatable firmware enabling dynamic upload of command and experiment control modules
  • AST: HA: Hardware: 00: ARM-Based Onboard Computer: High-performance processor allowing AI/ML software tests and high-fidelity data processing
  • AST: HA: Hardware: 01 ADCS & Camera Payloads: Includes fine ADCS, imager for experiments and astrometry
  • AST: HA: Hardware: 02: GPS Receiver: Provides navigation and timing functionality
  • AST: HA: Hardware: 03: SDR & Optical Receiver: Software-defined radio, optical downlink receiver for communications
  • AST: CI: Communications: 00: S-band CCSDS Uplink/Downlink: Syrlinks EWC31 transceiver used for primary telemetry and command
  • AST: CI: Communications: 01: X-band Payload (via CNES): Experimental high-speed downlink
  • AST: CI: Communications: 02: UHF Backup Link: Redundant link for telemetry & commands
  • AST: SO: Software: 00: Remote Experiment Execution Stack: Software interface for executing uploaded experiments from ESA or external contributors
  • AST: SI: Signal: 00: S-Band Uplink Receiver: Signal channel used for command uplink and experimental software transfer
  • AST: DA: Data: 00: Onboard Experiment & Telemetry Logs: Operational data and telemetry captured from experimental runs for downlink and analysis

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.

Figure 4: Summary of the full attack flow (Slide courtesy Thales Group)

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.

Figure 5: The Deserialization Vulnerability (Slide courtesy Thales Group)
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)

 

Figure 6: Stay Undetected – Success! (Slide courtesy Thales Group)

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.

Figure 7: Stay Undetected – Execute Arbitrary Commands (Slide courtesy Thales Group)
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.

Figure 8: Taking Control – Privilege Escalation from User to Root (Slide courtesy Thales Group)
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

 

Figure 9: Taking Control – Arbitrary Code Execution as Root (Slide courtesy Thales Group)

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.

Figure 10: Persistence – Injection of a Jar Library (Slide courtesy Thales Group)
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.

Figure 11: Demo Effects – Tampering with Camera & ADCS (Slide courtesy Thales Group)
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:

  • AST: HA: Hardware: 01: ADCS
  • AST: HA: Hardware: 02: GPS Receiver
  • AST: HA: Hardware: 03: Optical Sensors

 

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
Figure 12: Other Potential Effects (Slide courtesy Thales Group)
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:

  • AST: DA: Data: 00: Onboard Experiment & Telemetry
  • AST: SI: Signal: 00: S-Band Uplink Receiver
  • AST: HA: Hardware: 03: SDR & Optical Receiver: Software-defined radio, optical downlink receiver for communications

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!

Exploring the power of the METEORSTORM™ framework — a framework built for full-spectrum modeling of current, emerging, and theoretical converged space-cyber systems

0

I’m very proud to have successfully taken up a new challenge exam in beta version about METEORSTORM™ framework which allowed me to obtain the certification: Full Spectrum Space Cybersecurity Professional (SCOR Practitioner).

Completing the METEORSTORM™ module ensures that I can be part of a work role that is responsible for platform decomposition and analysis to understand and break down space platforms, identifying exposure and developing resilience measures. It also involves preparing Space Collective Defense solutions focused on Collective Development, Research, and Response. Furthermore, this role directly supports organizational and communal efforts in space platform Threat Management, Resilience Engineering, and Breach Management.

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.

I was lucky to be offered a preview of this new portal and this new challenge exam.

METEORSTORM™ stands for Multiple Environment Threat Evaluation of Resources, Space Threats, and Operational Risks to Missions.

It is a systematic resilience modeling framework specifically designed for converged space systems that face:

  • Kinetic threats (e.g., physical attacks)
  • Non-kinetic threats (e.g., cyber, RF interference)
  • Electronic & Cyber Warfare
  • Environmental exposure risks

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™ AI assistant is also beneficial for:

  • Students studying space and cyber convergence.
  • Researchers analyzing resilience strategies for next-gen missions.
  • Security-minded technologists modeling exposure, risk, and mitigation.

METEORSTORM™ framework is amazing. The EthicallyHackingspace (eHs)® team did a great job. I had a lot of fun using the METEORSTORM framework in the challenge exam. METEORSTORM™ is very simple to use and the results are very useful, valuable and actionable.

The model is across multiple domains, including:

  • Drones (terrestrial, aquatic, orbital, deep space)
  • Aquatic systems (beacons, transoceanic cables)
  • Hybrid terrestrial–orbital–aerial platforms

The model allows:

  • Threat modeling & emulation
  • Hybrid warfare scenario analysis
  • Resilience & detection signature engineering

METEORSTORM Cheat Sheet

To know more

You can access the public version of the decomposition and analytic AI-Copilot platform, now open beyond the eHs FS-SCP™ community.

You can see my digital badge here: https://my.certifyme.online/verify/af62246a13653

To know more about ethicallyHackingspace(eHs)®: https://ethicallyhacking.space/

Last Posts

722 préprints mathématiques d’OpenAI : quelles conséquences pour la cryptographie et la cybersecurity ?

0
Que changent les 722 préprints mathématiques d’OpenAI pour RSA, la PQC, les PKI et le Zero Trust ? Analyse des risques cyber et des priorités.

MITRE ESTM + EMB3D in Action : Analyzing OPS-SAT Through These Dual Frameworks

0
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...

Exploring how the new MITRE ESTM (Embedded Systems Threat Matrix) can work in conjunction...

0
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...

SPARTA v3.2: Raising the Bar for Threat‑Informed Space Cybersecurity

0
The Aerospace Corporation has released SPARTA v3.2, further strengthening its role as a practical, threat‑informed framework for securing modern space missions against sophisticated cyberattacks. This...

Introducing the new MITRE Embedded Systems Threat Matrix (ESTM)

0
Embedded systems have become the unsung heroes of modern technology. They power our satellites, medical devices, vehicles, and industrial infrastructures, quietly operating at the...

Popular posts

Description of the Elements of a Satellite Command and Control System

1
In order to be able to analyse the various threats and identify the risks facing a space system, it is necessary to describe precisely...

Install KYPO Cyber Range Platform on Openstack and Ubuntu in AWS cloud

4
KYPO is a Cyber Range Platform (KYPO CRP) developed by Masaryk University since 2013. KYPO CRP is entirely based on state-of-the-art approaches such as...

What are the threats to space systems?

0
In this article, we will try to identify the various threats to space systems. This article is a synthesis of the CSIS (Center for Strategic...

An analysis of the Viasat cyber attack with the MITRE ATT&CK® framework

0
Disclaimer To do this analysis of the Viasat cyber attack, I used the open-source intelligence (1) of the team composed by Nicolò Boschetti (Cornell University),...

ESA released the SPACE-SHIELD, an ATT&CK® like knowledge-base framework for Space Systems

2
I dreamed about it, ESA did it! ESA (European Space Agency) released the SPACE-SHIELD (Space Attacks and Countermeasures Engineering Shield). This is an ATT&CK®...