De l’agilité dans la sécurité : comment Red Team Automation (RTA) réduit les coûts, les délais et renforce vos défenses

par Gilbert Thierry NLO · Publié 27 juillet 2026 · Mis à jour 27 juillet 2026

En ingénierie comme en sécurité informatique, le rendu final n’est souvent que la face visible de l’iceberg. La sécurité n’est pas un état figé, mais un processus dynamique et permanent. C’est dire combien les phases préparatoires en amont et de reporting en aval — véritables piliers de l’activité — exigent la plus haute disponibilité et une vigilance constante des équipes. Il s’agit de comprendre clairement où l’on va, quels sont les objectifs, ce qui fonctionne, ce qui échoue, pourquoi, et surtout comment s’améliorer. Pour éclairer ces décisions, la phase opérationnelle des tests d’intrusion (pentests) gagne considérablement à s’appuyer sur l’automatisation. Sur ce terrain de la réactivité et de l’efficacité opérationnelle intervient Red Team Automation (RTA). Dans l’optique de forger des défenses capables de résister quotidiennement aux toutes dernières techniques d’attaque, qu’est-ce qui fait de RTA un véritable moteur d’évaluation continue ? Comment se met-il en œuvre et comment en tirer le meilleur parti ?

Présentation et utilité de l’outil

Désormais intégré à l’écosystème Elastic, Red Team Automation (RTA) est un cadre d’automatisation des tests de sécurité initialement développé par Endgame. Son nom traduit à lui seul son rôle stratégique au cœur de l’architecture de sécurité.

Au sein des organisations matures, la posture de sécurité s’articule autour de plusieurs rôles complémentaires. Les équipes bleues (Blue Teams) occupent une fonction défensive, tandis que les équipes rouges (Red Teams) adoptent une posture offensive. Les Red Teams simulent des attaques réalistes afin de permettre aux Blue Teams d’ajuster et de perfectionner leurs mécanismes de détection.

RTA intervient précisément pour épauler les Red Teams dans leurs opérations offensives. Comme souligné en introduction, ces simulations ne sauraient être de simples événements ponctuels : elles doivent s’exécuter en continu pour coller à l’évolution permanente des menaces.

Concrètement, RTA se présente sous la forme d’un ensemble de scripts Python modulaires conçus pour simuler des scénarios d’attaque inspirés des tactiques, techniques, sous-techniques et procédures (TTP) de la matrice MITRE ATT&CK®, le tout sans nécessiter d’intervention manuelle lourde.

Dans son mode opératoire, RTA s’efforce d’exécuter de véritables actions malveillantes lorsque le contexte le permet en toute sécurité, ou d’en imiter fidèlement le comportement dans les autres cas. Les technologies couramment simulées incluent des canaux de commande et contrôle (C2), des outils d’analyse de vulnérabilités ainsi que des kits d’exploitation configurables.

Pour exploiter pleinement RTA, il convient de comprendre ce qui sous-tend ses fonctionnalités clés. Comme nous l’avons évoqué, l’ensemble de ses modules est conçu pour reproduire les attaques répertoriées dans la matrice ATT&CK. La maîtrise de ce modèle de référence constitue donc un prérequis indispensable.

Mais d’où vient la matrice ATT&CK et de quoi s’agit-il exactement ?

À propos du modèle source des techniques simulées

Sur le plan littéral, l’acronyme ATT&CK® signifie « Adversary Tactics, Techniques, and Common Knowledge » (Tactiques, techniques et connaissances communes des adversaires). Il s’agit d’une base de connaissances mondiale et ouverte développée par MITRE, une organisation à but non lucratif faisant référence dans le monde de la cybersécurité. Son objectif est de documenter de manière rigoureuse les TTP (Tactiques, Techniques et Procédures) employées par les attaquants dans le monde réel, à partir d’incidents de sécurité dûment avérés.

Pour exploiter cette base, MITRE propose un cadre méthodologique permettant de comprendre le mode opératoire des cybermenaces et de s’en défendre en cartographiant les actions des attaquants à chaque étape d’une intrusion. La matrice est structurée en plusieurs composantes clés, imbriquées logiquement du niveau le plus abstrait au plus concret :

Les tactiques représentent les objectifs stratégiques globaux de l’adversaire (le pourquoi). Elles expliquent la raison d’être d’une action à un instant .
- Exemple : Credential Access (Accès aux identifiants) — L’objectif de l’attaquant est d’obtenir des noms d’utilisateurs et des mots de passe pour élever ses privilèges ou se déplacer latéralement sur le réseau.
Les techniques détaillent le moyen général employé pour atteindre cette tactique (le comment).
- Exemple : OS Credential Dumping (T1003) — La méthode choisie consiste à extraire les identifiants directement depuis la mémoire ou les fichiers de stockage du système d’exploitation.
Les sous-techniques affinent la technique en précisant le composant technique cible ou le mécanisme exact utilisé.
- Exemple : LSASS Memory (T1003.001) — L’attaquant vise spécifiquement la mémoire du processus système Windows LSASS (Local Security Authority Subsystem Service) où sont temporairement conservés les hachages NTLM et les jetons de session.
Les procédures désignent les implémentations concrètes et opérationnelles observées lors d’incidents réels (logiciels malveillants, commandes ou scripts précis).
- Exemple : Le groupe cybercriminel FIN7 utilise l’utilitaire Mimikatz via la commande sekurlsa::logonpasswords (ou exécute le script automatisé RTA lsass_dump.py) pour lire la mémoire du processus lsass.exe et exporter les hachages de mots de passe.

Fonctionnement : intégration des TTP de la matrice ATT&CK au cœur de RTA

Comme le veut le proverbe, une image vaut mille mots. Les scénarios qui suivent permettent de visualiser concrètement plusieurs tactiques majeures de la matrice MITRE ATT&CK, leur ancrage dans des incidents historiques réels, ainsi que leur simulation automatisée grâce à l’outil RTA.

Illustration 1 : Tactique « Credential Access » (Accès aux identifiants)

Dangérosité & Mode opératoire :

Cette tactique vise à voler des noms d’utilisateurs et des mots de passe. Elle est extrêmement critique car elle permet à l’attaquant de passer d’un simple accès local non privilégie à un mouvement latéral sur le domaine, voire à une élévation de privilèges sans éveiller les soupçons (les requêtes semblent venir d’un compte valide). Le mode opératoire le plus célèbre repose sur le dump de la mémoire du processus système LSASS (Local Security Authority Subsystem Service) sous Windows. En utilisant des outils nativement détournés (Living off the Land) ou des logiciels tiers (comme Mimikatz), l’attaquant extrait les empreintes NTLM ou les mots de passe en texte clair stockés en mémoire.

Repère historique & Documentation ATT&CK :

Historiquement, cette technique a été popularisée massivement lors des attaques majeures de ransomware (comme NotPetya en 2017) et par des groupes étatiques comme APT28 (Fancy Bear) ou FIN7. Dans le framework ATT&CK, cette tactique porte l’identifiant TA0006 (Credential Access). La méthode de dump de mémoire est référencée plus spécifiquement sous la technique T1003.001 (OS Credential Dumping: LSASS Memory).

Mise en œuvre dans Red Team Automation (RTA) :

Dans le framework RTA, cette tactique est testée via des scripts d’automatisation dédiés, comme lsass_dump.py ou le binaire de simulation inclus. Lors de son exécution, le script RTA va simuler l’ouverture d’un handle sur le processus lsass.exe avec des privilèges de lecture (PROCESS_VM_READ) et invoquer l’API Windows MiniDumpWriteDump pour tenter d’extraire la mémoire dans un fichier temporaire (ex. lsass.dmp). L’objectif dans RTA n’est pas forcément d’extraire de vrais mots de passe, mais de déclencher la télémétrie Windows (événements Sysmon Event ID 10 : ProcessAccess) pour vérifier si les règles d’Alerte de l’EDR interceptent la tentative de lecture anormale de la mémoire de LSASS.

Illustration 2 : Tactique « Defense Evasion » (Évasion des défenses)

Dangérosité & Mode opératoire :

Considérée comme l’une des tactiques les plus transversales, l’évasion vise à contourner les contrôles de sécurité (antivirus, EDR, pare-feu, journaux d’audit) pour rester indétectable le plus longtemps possible. Un mode opératoire très répandu consiste en l’injection de code dans un processus légitime (Process Injection). Au lieu d’exécuter un fichier .exe malveillant sur le disque (ce qui déclencherait une signature AV), l’attaquant alloue de la mémoire au sein d’un processus système de confiance déjà en cours d’exécution (comme explorer.exe ou svchost.exe), y écrit sa payload (ex. un shellcode de Beacon) et crée un nouveau thread pour l’exécuter.

Repère historique & Documentation ATT&CK :

Cette tactique est la signature opérationnelle de groupes Cybercriminels très avancés et d’acteurs APT comme APT29 (Cozy Bear) ou des opérateurs du ransomware Conti. ATT&CK répertorie cette tactique globale sous l’identifiant TA0005 (Defense Evasion). L’injection de processus est formalisée sous la technique T1055 (avec plusieurs sous-techniques selon la méthode d’injection : DLL Injection, Process Hollowing, etc.).

Mise en œuvre dans Red Team Automation (RTA) :

Le framework RTA automatise cette technique via ses modules d’injection (par exemple via des scripts Python appelant le binaire d’émulation compilé de RTA, inject.exe ou process_injection.py). Le script simule une séquence d’APIs Win32 typique : OpenProcess sur un processus cible ciblé (comme notepad.exe), VirtualAllocEx pour réserver de la mémoire distante, WriteProcessMemory pour écrire un payload inoffensif (ex. afficher une NOP-slide ou exécuter un simple ping), puis CreateRemoteThread. En exécutant cela de manière automatisée, RTA fournit à la Blue Team la preuve d’un comportement d’injection sans endommager le système, permettant de valider si le SIEM ou l’EDR remonte bien les alertes d’allocation de mémoire distante non autorisée.

Cas d’étude : Au-delà des attaques standards, simuler une chaîne d’infection sur mesure (Word -> RTF -> MSHTA -> PowerShell)

Les tests de sécurité automatisés se limitent trop souvent à déclencher des TTPs (Tactics, Techniques, and Procedures) de manière isolée : un dump LSASS par-ci, une commande PowerShell suspecte par-là. Or, dans la réalité, un attaquant ne déclenche pas une alerte isolée : il orchestre une chaîne d’exécution. Nous allons nous projeter en ce sens via un scénario dont peu d’organisations mesurent la fréquence et la discrétion.

En effet, lorsqu’un fichier Word utilise une fonctionnalité native pour récupérer une référence externe, le volume de trafic légitime est souvent trop important pour qu’une alerte simple soit déclenchée. Pour valider l’efficacité réelle de la Blue Team, la Red Team doit dépasser les scripts d’attaque « clés en main » et concevoir une simulation sur mesure inspirée de la méthodologie ATT&CK et exécutée via Red Team Automation (RTA).

1. Modélisation de la chaîne de compromission (Cartographie ATT&CK)

Pour construire cette simulation sur mesure, la première étape consiste à traduire chaque maillon du scénario dans le langage de la matrice MITRE ATT&CK :

Vecteur d’entrée (Phishing) : Réception d’un e-mail ciblé transportant un document Word (.docx) malveillant.
- ATT&CK : T1566.001 (Spearphishing Attachment)
Chargement de la ressource externe (Exploitation) : Le document Word exploite une vulnérabilité (ex. RTF) pour télécharger un modèle distant dès son ouverture.
- ATT&CK : T1203 (Exploitation for Client Execution)
Exécution binaire proxy (MSHTA) : L’exploit invoque l’utilitaire légitime de Windows mshta.exe pour télécharger et exécuter un fichier HTA distant.
- ATT&CK : T1218.005 (System Binary Proxy Execution: Mshta)
Obfuscation du script (VBScript) : Le fichier HTA exécute un script VBScript obfusqué masquant l’étape suivante.
- ATT&CK : T1059.005 (Visual Basic) & T1027 (Obfuscated Files or Information)
Infiltration et exécution (PowerShell & C2) : Le VBScript lance une instance PowerShell qui effectue un téléchargement HTTP sur les ports standards (80/443) pour récupérer et exécuter la charge utile binaire finale.
- ATT&CK : T1059.001 (PowerShell), T1105 (Ingress Tool Transfer) et T1071.001 (Web Protocols)

2. Implémentation sur mesure dans Red Team Automation (RTA)

Plutôt que d’exécuter un binaire malveillant réel, la Red Team développe un script RTA sur mesure qui rejoue fidèlement l’empreinte comportementale (création de processus et connexions réseau) de cette chaîne d’attaque.

#—–

# Simulation RTA sur mesure : Chaine Word -> MSHTA -> PowerShell

import subprocess

import time

def simulate_custom_attack_chain():

# 1. Émulation MSHTA (T1218.005) : Appel d’une ressource HTA distante via binaire natif

hta_target = « http://127.0.0.1:8080/remote_ref.hta »

print(« [RTA] Step 1: Simulating MSHTA execution from remote URL… »)

subprocess.Popen([« mshta.exe », hta_target])

time.sleep(2) # Pause simulant le délai du script VBScript obfusqué (T1027)

# 2. Émulation PowerShell (T1059.001 & T1105) : Téléchargement du binaire final

ps_cmd = « Invoke-WebRequest -Uri ‘http://127.0.0.1:8080/payload.bin’ -OutFile ‘$env:TEMP\\test_payload.bin' »

print(« [RTA] Step 2: Simulating PowerShell execution and payload transfer… »)

subprocess.Popen([« powershell.exe », « -ExecutionPolicy », « Bypass », « -WindowStyle », « Hidden », « -Command », ps_cmd])

if __name__ == « __main__ »:

simulate_custom_attack_chain():

#—–

3. Télémétrie et validation Blue Team : La corrélation comme clé de détection

L’objectif de cette simulation personnalisée est de vérifier si la chaîne de défense (EDR / SIEM) sait corréler des événements qui, pris individuellement, ressemblent à du trafic légitime :

Ce que la Blue Team doit détecter :

Arbre de processus anormal (Sysmon Event ID 1) : L’instanciation en cascade winword.exe mshta.exe powershell.exe.
Comportement réseau suspect (Sysmon Event ID 3) : Une requête HTTP sortante initiated directement par un composant d’Office ou un proxy Windows natif (mshta.exe) vers une destination non reconnue.

Cas d’étude : Passer du pentest ponctuel à l’automatisation continue des simulations d’attaque

L’évaluation de la sécurité s’est longtemps appuyée sur des opérations manuelles et ponctuelles : lancer un scan de vulnérabilités Web via Burp Suite Pro ou exploiter un service exposé avec Metasploit. Si ces méthodes conservent leur utilité, elles souffrent d’une limite majeure : elles ne testent pas la continuité de vos capacités de détection face à un adversaire qui évolue.

Lever cette limite reviendra dont à utiliser des outils de tests d’intrusion automatisés ; les programmer afin qu’ils s’exécutent à intervalles réguliers, offrant ainsi une visibilité continue sur l’environnement de sécurité de l’organisation.

De plus, l’automatisation des tests d’intrusion peut s’intégrer à une stratégie de sécurité plus globale incluant la chasse aux menaces et la réponse aux incidents. Les simulations automatisées contribuent alors à valider les contrôles de sécurité et les mécanismes de réponse, garantissant leur efficacité face aux menaces persistantes avancées (APT).

1. Du test ponctuel au scénario automatisé : Cartographie ATT&CK

Pour passer d’un simple scan de vulnérabilités à une simulation d’attaque automatisée en continu, chaque action de test doit être rattachée à une brique précise de la matrice MITRE ATT&CK. Cela permet de mesurer la couverture défensive sur l’ensemble du cycle de vie d’une menace :

Reconnaissance et Scan d’application Web (Ex. via Burp Suite) :
- ATT&CK : T1595.002 (Reconnaissance: Vulnerability Scanning)
- Objectif d’automatisation : Cartographier automatiquement les surfaces d’attaque et identifier les failles applicatives en continu.
Exploitation initiale d’un service (Ex. via Metasploit) :
- ATT&CK : T1190 (Exploit Public-Facing Application)
- Objectif d’automatisation : Valider si l’exploitation d’une vulnérabilité Web/réseau déclenche immédiatement un blocage ou une alerte au niveau du pare-feu applicatif (WAF) ou du SIEM.
Persistance et exécution de scripts post-exploitation :
- ATT&CK : T1059.004 (Command and Scripting Interpreter: Unix Shell) ou T1059.001 (PowerShell)
- Objectif d’automatisation : Exécuter automatiquement des commandes de découverte dès que l’accès initial est simulé.

2. Implémentation : Automatisation d’une boucle d’évaluation via RTA

Plutôt que d’attendre une intervention humaine pour exécuter un Framework comme Metasploit, la Red Team développe une suite de scripts RTA (Red Team Automation) intégrée aux routines d’orchestration (ex. tâches planifiées, pipelines DevOps ou scripts Python d’évaluation).

Le script ci-dessous illustre comment automatiser la simulation d’un scénario complet d’évaluation en continu (Scan de surface Simulation d’exploitation Post-exploitation RTA) :

#——

# Simulation d’automatisation continue : Scan Web -> Exploitation -> Post-Exploitation RTA

import subprocess

import requests

import time

def run_automated_continuous_assessment():

print(« [+] Step 1: Automating Application Scanning (T1595.002)… »)

# Simulation d’un appel automatisé vers une API de scan (ex. Burp REST API)

# response = requests.post(« http://burp-scanner:1337/v1/scan », json={« target »: « http://internal-app.local »})

print(« [+] Step 2: Simulating Public-Facing Application Exploit (T1190)… »)

# Émulation de l’envoi d’un payload d’exploitation HTTP non destructif

headers = {‘User-Agent’: ‘RTA-Continuous-Test-Agent/1.0’}

try:

requests.get(« http://internal-app.local/vulnerable_endpoint?exploit=test_payload », headers=headers)

except Exception as e:

pass

time.sleep(3)

print(« [+] Step 3: Triggering Post-Exploitation RTA Script (T1059)… »)

# Exécution automatisée d’un script RTA simulant l’activité d’un attaquant après accès

subprocess.Popen([« python3 », « ./rta_scripts/post_exploitation_discovery.py »])

if __name__ == « __main__ »:

# Ce script peut être exécuté automatiquement à intervalles réguliers (Cron / CI-CD)

run_automated_continuous_assessment()

#——

Installation et prérequis

La mise en œuvre de RTA — qu’on le qualifie de framework ou de micro-framework au vu de sa structure légère — repose principalement sur un environnement Python, dont la version doit être adaptée selon les évolutions et la compatibilité du projet.

Pour obtenir la version la plus récente du code et vérifier les dépendances requises, il convient de se référer directement au dépôt officiel du projet :

Code source et documentation : Le projet RTA est accessible directement sur GitHub via le dépôt endgameinc/RTA.

Écosystème et alternatives : situer RTA face aux outils similaires

Comme tout outil de cybersécurité, RTA n’est pas une solution universelle. Selon les besoins spécifiques de votre organisation, il peut s’avérer nécessaire de le compléter avec d’autres briques, de l’intégrer au sein d’un écosystème plus large ou d’opter pour des alternatives offrant une couverture différente.

Le choix dépendra avant tout des objectifs du projet : recherche de simplicité, couverture Cloud, besoin d’orchestration C2 complète ou émulation d’attaques ciblées.

Voici une analyse comparative des principales solutions alternatives et complémentaires disponibles sur le marché :

Atomic Red

Atomic Red Team (développé par Red Canary) constitue l’alternative open-source la plus populaire et la plus granulaire : là où RTA privilégie des scripts procéduraux en Python/binaires simulant des séquences d’attaque intégrées, Atomic Red Team repose sur une bibliothèque de tests unitaires (« atomiques ») au format YAML, conçus pour s’exécuter indépendamment en moins de 5 minutes par technique.

La différence fondamentale réside dans l’approche d’ingénierie : RTA offre un cadre orienté scénario automatisé (idéal pour tester la corrélation d’événements et la résilience d’un pipeline), tandis qu’Atomic Red Team adopte une logique de composants élémentaires pour valider une règle de détection spécifique (EAL/EDR).

En matière de forces, Atomic Red Team surpasse RTA par sa couverture exceptionnelle de la matrice ATT&CK (couvrant Windows, Linux, macOS et le Cloud), une communauté très active et la possibilité d’être orchestré nativement via PowerShell (Invoke-AtomicTest) ; à l’inverse, RTA excelle dans sa capacité à chaîner des comportements et à simuler l’arbre de processus réel d’un attaquant sans nécessiter un orchestrateur externe.

Côté faiblesses, Atomic Red Team isole tellement les tests qu’il néglige parfois le contexte et le bruit d’une vraie chaîne de compromission (nécessitant des outils tiers pour composer des scénarios complexes), alors que RTA souffre d’une couverture ATT&CK nettement plus restreinte, d’un catalogue moins fréquemment mis à jour et d’une complexité d’adaptation accrue pour les équipes ne maîtrisant pas le développement sur mesure.

RedHunt-OS

RedHunt OS (développé par RedHunt Labs) ne se positionne pas comme un script ou une bibliothèque de tests isolée, mais comme un environnement d’exploitation complet (distribution Linux sur mesure) dédié à la simulation d’adversaires, au Threat Hunting et à l’analyse de données défensives.

La différence fondamentale réside dans l’échelle d’ingénierie : là où RTA fournit des scripts individuels d’émulation et Atomic Red Team un catalogue de tests unitaires, RedHunt OS fournit l’infrastructure hôte tout-en-un prête à l’emploi qui intègre et orchestre l’ensemble de l’arsenal offensif (Caldera, Atomic Red Team, Metasploit) et défensif (ELK Stack, Kolide Fleet, plateformes CTI).

En termes de forces, RedHunt OS élimine toute la complexité de déploiement d’un laboratoire de test en combinant directement des outils de Purple Teaming et de Threat Intelligence, ce qui en fait un environnement idéal pour monter rapidement un stand de validation ou un banc d’essai.

À l’inverse, RTA surpasse RedHunt OS par sa légèreté extrême (de simples scripts à exécuter directement sur des machines cibles sans déployer une VM lourde), et Atomic Red Team brille par une flexibilité d’intégration CI/CD bien supérieure.

Côté faiblesses, RedHunt OS est un système d’exploitation complet (charge d’empreinte mémoire élevée, contraintes de maintenance de la distribution) qui n’a pas vocation à être embarqué dans des pipelines d’automatisation légers ; de plus, contrairement aux scripts sur mesure RTA conçus pour simuler un comportement ciblé en production, RedHunt OS est une boîte à outils principalement destinée à être exécutée dans des environnements de laboratoire contrôlés.

APTSimulator

APTSimulator (développé par Florian Roth / Nextron Systems) adopte une philosophie résolument axée sur la simplicité et les traces d’artefacts : contrairement à RTA (qui exécute des scripts Python/binaires procéduraux) ou à Atomic Red Team (qui lance des tests unitaire YAML), APTSimulator est un simple script Batch Windows léger qui déploie un ensemble d’artefacts, d’outils et de modifications système pour faire croire qu’une machine a été compromise par un groupe APT (dépôt de webshells, fausses entrées de registre, dump LSASS factice, modification du fichier hosts).

La différence fondamentale réside dans l’objectif : APTSimulator ne cherche pas à simuler la mécanique d’une attaque en temps réel, mais à simuler l’état final et les traces laissées sur le disque pour tester les outils de Compromise Assessment (comme les scanners YARA/Sigma) et l’analyse forensique post-incident.

En termes de forces, APTSimulator offre une simplicité d’installation imbattable (aucun agent, serveur web ou dépendance à installer, un simple fichier Batch à exécuter sous Windows), idéal pour les audits rapides, les tests de POC EDR ou la formation DFIR.

Par rapport à RTA et Atomic Red Team, il demande zéro infrastructure de contrôle. Côté faiblesses, APTSimulator manque cruellement de flexibilité : les scénarios sont largement statiques, exclusivement orientés Windows, et il ne permet pas de simuler des séquences d’attaque complexes et dynamiques ou du trafic C2 réseau interactif comme le fait RTA. De plus, en se fiant à de simples scripts Batch et des archives chiffrées, il est souvent rapidement bloqué par les antivirus modernes si des exclusions ne sont pas configurées, là où des frameworks comme RTA ou RedHunt OS s’intègrent dans des environnements de test plus poussés.

Caldera de MITRE

CALDERA (développé par le MITRE) est une plateforme complète et autonome de simulation d’adversaires et d’émulation de cyberattaques, s’appuyant directement sur la matrice ATT&CK. La différence fondamentale réside dans l’architecture : là où RTA, Atomic Red Team ou APTSimulator sont des suites de scripts légers exécutés localement par des opérateurs, CALDERA fonctionne selon un modèle Serveur C2 (Command & Control) / Agents (Sandcat).

La plateforme orchestre dynamiquement des opérations complexes en permettant aux agents déployés sur les machines cibles d’exécuter des séquences automatisées d’actions (abilities regroupées en adversary profiles).

En termes de forces, CALDERA est l’outil le plus puissant pour la modélisation comportementale réaliste : il gère le chaînage intelligent d’attaques (décisions en temps réel basées sur les données récoltées), offre une interface graphique de suivi, s’intègre nativement avec Atomic Red Team et permet de simuler un attaquant autonome de bout en bout sur plusieurs hôtes.

À l’inverse, RTA brille par sa simplicité et son absence d’empreinte infrastructurelle (de simples scripts sans serveur central), tandis qu’Atomic Red Team offre une mise en œuvre unitaire bien plus rapide pour tester une signature unique.

Côté faiblesses, CALDERA exige une courbe d’apprentissage et une infrastructure d’hébergement bien plus lourdes que des scripts autonomes comme RTA, nécessite le déploiement préalable d’agents sur le réseau testé (ce qui peut être complexe en production restreinte), et peut s’avérer disproportionné si l’objectif est simplement d’automatiser un test de détection rapide au sein d’un pipeline CI/CD.

Metta d’Uber

Metta (développé par Uber) se définit comme un outil d’état de préparation (preparedness tool) axé sur l’émulation automatisée d’adversaires via l’orchestration d’environnements virtualisés.

La différence fondamentale réside dans son architecture de déploiement et d’exécution : là où RTA lance des scripts légers directement sur le système hôte et CALDERA repose sur un modèle C2/Agents, Metta s’appuie sur une pile Redis / Celery / Vagrant / VirtualBox pour parser des fichiers YAML et pousser séquentiellement des actions offensives ATT&CK dans des machines virtuelles de test isolées, le tout sans intervention humaine.

En termes de forces, Metta brille par sa capacité à automatiser des tests de non-régression dans des environnements éphémères et contrôlés (labs Vagrant) : c’est un excellent moteur pour valider en continu l’ensemble de la chaîne de télémétrie (du capteur EDR jusqu’au SIEM/Alerting) sans risquer de polluer ou d’endommager une machine de production.

Par rapport à Atomic Red Team ou APTSimulator, il permet de déclarer des scénarios complexes multi-étapes sous forme de listes d’actions YAML exécutables en tâche de fond. Côté faiblesses, Metta pâtit d’une lourdeur d’infrastructure significative (gestion de VMs Vagrant/VirtualBox, files Celery), d’une activité/maintenance open-source aujourd’hui très faible, et d’une complexité d’installation bien supérieure à la légèreté instantanée de RTA ou Atomic Red Team. De plus, son orientation vers des environnements de laboratoire virtuels le rend moins adapté que RTA pour effectuer des simulations ciblées directement au cœur d’un parc de production réel.

Stratus Red Team (DataDog)

Stratus Red Team (développé par Datadog) est le pendant moderne d’Atomic Red Team spécifiquement conçu pour les environnements Cloud (AWS, Azure, GCP, Kubernetes). La différence fondamentale réside dans la gestion des prérequis d’infrastructure : là où des outils comme RTA ou Atomic Red Team exécutent des commandes localement sur un système d’exploitation hôte (Windows/Linux), Stratus Red Team utilise Terraform sous le capot pour orchestrer un cycle de vie en quatre phases (Warmup Detonate Revert Cleanup), permettant de créer automatiquement les ressources cloud nécessaires (ex. un compartiment S3 ou une fonction Lambda), d’y détoner l’attaque cloud (ex. exfiltration de snapshots EBS ou modification de rôles IAM), puis d’assainir l’environnement.

En termes de forces, Stratus Red Team comble le fossé majeur des outils traditionnels en ciblant le plan de contrôle Cloud (Cloud Control Plane) et les journaux API (comme AWS CloudTrail), le tout encapsulé dans un binaire Go autonome et très simple d’utilisation. Par rapport à RTA (centré sur les artefacts hôtes/processeurs) ou APTSimulator (statique sur OS Windows), il est parfait pour valider les règles de détection des SIEM Cloud et des plateformes CDR (Cloud Detection and Response).

Côté faiblesses, Stratus Red Team est restreint aux scénarios cloud et ne convient pas du tout pour simuler la post-exploitation sur des endpoints traditionnels ; il nécessite des autorisations de gestion d’infrastructure temporaires (droits de création de ressources via API Cloud) et s’avère moins adapté que CALDERA ou Metta si l’on cherche à simuler des chaînes de déplacement latéral complexes entre le réseau interne et le cloud.

Elastic SWAT / Dorothy

Elastic SWAT (Simple Workspace ATT&CK Tool) et Dorothy (développés par l’équipe de recherche sur les menaces d’Elastic) forment un duo d’outils spécialisés dans la simulation d’attaques orientées Identité SaaS et Cloud (Google Workspace pour SWAT, Okta pour Dorothy).

La différence fondamentale avec les autres cadres réside dans le périmètre d’exécution : alors que RTA, Atomic Red Team ou APTSimulator agissent au niveau du système d’exploitation hôte (endpoints Windows/Linux) et que Stratus Red Team cible le plan de contrôle du Cloud (AWS/Azure), SWAT et Dorothy s’exécutent entièrement via les APIs d’identité et de collaboration SaaS pour simuler la persistance, l’évasion de défense et la découverte de données post-compromission de compte (MFA bypass, persistance de jetons API, énumération d’utilisateurs ou fuite de documents Drive).

En termes de forces, ce duo comble un angle mort majeur du Red Teaming moderne en automatisant les TTPs spécifiques aux environnements cloud SaaS/IAM (très souvent négligés par les scripts traditionnels), tout en offrant une intégration native avec la télémétrie des journaux d’audit (Google Workspace Audit Logs, Okta System Log).

À l’inverse, RTA surpasse ces outils pour valider la sécurité des postes de travail et l’exécution de processus hôtes, et CALDERA offre un chaînage d’actions bien plus dynamique sur des réseaux hybrides.

Côté faiblesses, SWAT et Dorothy nécessitent des jetons API d’administration déjà existants pour fonctionner (ils ne simulent pas la phase de phishing ou d’accès initial brut), possèdent une portée restreinte à leurs écosystèmes SaaS respectifs, et demandent l’utilisation d’environnements de test dédiés pour éviter d’altérer la configuration de production des tenants IAM de l’entreprise.

Si la simulation d’attaques est essentielle pour renforcer les défenses, s’y reposer aveuglément expose à un sentiment trompeur de sécurité. Le framework RTA offre un levier puissant pour rendre opérationnelle la matrice MITRE ATT&CK, mais sa véritable valeur ajoutée réside dans son exploitation par une Red Team proactive, capable de créer des scénarios sur mesure adaptés à son environnement. L’automatisation portée par cet outil s’inscrit pleinement dans une démarche d’amélioration continue : elle allège la charge de travail manuelle, valide l’efficacité des règles d’alerte en temps réel et optimise les budgets de sécurité, offrant ainsi une couverture défensive à la fois agile, mesurable et résiliente.