Atomic Red Team : tester et valider sa détection SOC en 2026

Atomic Red Team est une bibliothèque open source de tests de sécurité, chacun associé à une technique du référentiel MITRE ATT&CK, qui permet à une équipe de défense de reproduire en quelques minutes un comportement d'attaquant précis et de vérifier si ses outils le voient, l'alertent ou le bloquent. Maintenue par Red Canary et sa communauté sous licence MIT, elle s'exécute le plus souvent avec le module PowerShell Invoke-AtomicRedTeam, sur Windows, Linux ou macOS. Pour un centre opérationnel de sécurité (SOC), l'intérêt est concret : remplacer l'hypothèse « notre outil de détection repère cela » par une preuve reproductible, datée et rejouable après chaque changement. Ce guide détaille le format des tests atomiques, la préparation d'un laboratoire sûr, l'exécution pas à pas, la transformation des écarts en règles de détection et la priorisation des techniques en 2026, année marquée par les versions 19 et 20 d'ATT&CK. Il s'inscrit dans notre méthodologie d'exercices purple team, dont Atomic Red Team constitue souvent la première brique outillée.

Atomic Red Team : définition, origine et principes

Atomic Red Team est né chez Red Canary, société américaine spécialisée dans la détection et la réponse managées (MDR), avec un objectif simple : permettre à toute équipe de sécurité de tester ses contrôles sans monter une opération offensive complète. Le dépôt GitHub officiel redcanaryco/atomic-red-team présente le projet comme une bibliothèque de tests mappés sur ATT&CK, conçue pour éprouver un environnement de manière rapide, portable et reproductible.

Red Canary appartient au groupe Zscaler, qui a finalisé son rachat le 1er août 2025. Le projet est resté public, communautaire et distribué sous licence MIT : chacun peut lire, réutiliser et adapter les tests, ou proposer de nouvelles contributions par demande de fusion. En 2026, le dépôt reçoit toujours des ajouts de tests et des mises à jour de mapping, notamment la migration vers ATT&CK v19 puis v19.1.

Le principe de l'atome : une technique, un test, une preuve

Le terme « atomique » désigne la plus petite unité testable. Chaque test cible une procédure unique, par exemple l'énumération de la configuration réseau (T1016) ou la création d'une tâche planifiée, sans enchaîner plusieurs étapes d'attaque. D'après le site officiel du projet, chaque test s'exécute en cinq minutes ou moins, et beaucoup embarquent leurs propres commandes de préparation et de nettoyage.

Cette granularité facilite l'attribution des résultats. Lorsqu'une alerte se déclenche, l'analyste sait exactement quel comportement l'a provoquée ; lorsqu'aucune alerte n'apparaît, il sait quelle technique examiner dans la télémétrie. Un exercice offensif complet produit au contraire des dizaines d'actions entremêlées, dont l'analyse a posteriori demande beaucoup plus de temps et laisse souvent des zones d'incertitude.

Ce qu'Atomic Red Team n'est pas

Atomic Red Team n'est ni un outil de test d'intrusion, ni un framework de commande et contrôle, ni une émulation complète d'un groupe d'attaquants. Il ne cherche pas à exploiter une vulnérabilité ni à rester furtif : il produit des traces représentatives d'une technique pour que le défenseur vérifie sa visibilité. Il ne remplace donc pas les exercices comparés dans notre article red team, pentest et bug bounty, mais il les prépare et les prolonge.

Un écosystème de projets complémentaires

Autour de la bibliothèque, la famille Atomic regroupe plusieurs projets ouverts. Invoke-Atomic est le framework PowerShell qui exécute les tests, y compris à distance. Chain Reactor sert à tester la couverture de détection et de réponse sur Linux. AtomicTestHarnesses est une bibliothèque qui simule et valide l'exécution de techniques d'attaque. Le site atomicredteam.io centralise la documentation, l'index des tests et des tutoriels vidéo.

Anatomie d'un test atomique : le format YAML expliqué

Dans le dépôt, chaque technique dispose d'un dossier nommé d'après son identifiant ATT&CK, par exemple atomics/T1016. Ce dossier contient un fichier YAML lisible par les outils et une page Markdown générée pour les humains. Le fichier YAML regroupe tous les tests d'une technique : pour T1016, on trouve des variantes Windows, Linux et macOS, dont certaines reprennent des commandes attribuées aux familles malveillantes Qakbot ou TrickBot.

Les champs à connaître avant toute exécution

• attack_technique et display_name : identifiant et intitulé de la technique ATT&CK couverte.
• name et auto_generated_guid : nom lisible du test et identifiant unique stable, utile pour citer un test dans un rapport même si sa position dans la liste change.
• supported_platforms : windows, linux, macos, ou plateformes cloud et SaaS pour certains tests.
• input_arguments : paramètres typés (chemin, chaîne, URL) avec une valeur par défaut, injectés dans la commande grâce à la syntaxe #{nom}.
• dependencies : couples prereq_command et get_prereq_command qui vérifient puis installent ce dont le test a besoin.
• executor : interpréteur utilisé (command_prompt, powershell, sh, bash ou manual), commande, besoin éventuel d'élévation et cleanup_command.

Lire un test avant de l'exécuter

L'extrait ci-dessous, simplifié à partir du fichier T1016 du dépôt officiel, décrit le premier test de la technique « découverte de la configuration réseau du système ». Il ne demande ni prérequis ni élévation de privilèges et se contente de lancer des commandes d'inventaire réseau natives de Windows, ce qui en fait un bon candidat pour une première prise en main en laboratoire.

attack_technique: T1016
display_name: System Network Configuration Discovery
atomic_tests:
- name: System Network Configuration Discovery on Windows
  auto_generated_guid: 970ab6a1-0157-4f3f-9a73-ec4166754b23
  supported_platforms:
  - windows
  executor:
    name: command_prompt
    command: |
      ipconfig /all
      netsh interface show interface
      arp -a
      nbtstat -n
      net config

Cet exemple illustre une règle d'or : un test atomique se lit toujours avant de s'exécuter. Les commandes étant en clair, l'analyste peut anticiper les processus créés, ici cmd.exe puis ipconfig.exe, netsh.exe, arp.exe, nbtstat.exe et net.exe, et donc les événements attendus dans Sysmon ou l'outil de détection et de réponse sur les terminaux (EDR). D'autres tests téléchargent des outils tiers ou modifient la configuration : une lecture préalable évite les mauvaises surprises.

Invoke-AtomicRedTeam : le moteur d'exécution de référence

Les commandes d'un test peuvent être copiées à la main, mais un moteur d'exécution apporte la gestion des prérequis, des arguments, du nettoyage et de la journalisation. Le moteur de référence est Invoke-AtomicRedTeam, un module PowerShell multiplateforme ; sur Linux et macOS, il requiert PowerShell Core (pwsh). Son installation depuis la PowerShell Gallery tient en une seule commande, détaillée dans la documentation officielle du projet, et le module peut aussi être déployé hors ligne.

Les modes d'exécution d'Invoke-AtomicTest

La cmdlet Invoke-AtomicTest reçoit un identifiant de technique et, si besoin, des sélecteurs de tests par numéro, par nom ou par GUID. Ses commutateurs structurent une exécution propre : -ShowDetailsBrief et -ShowDetails pour inspecter, -CheckPrereqs pour vérifier les dépendances, -GetPrereqs pour les installer, puis l'exécution elle-même et -Cleanup pour supprimer les artefacts créés.

D'autres paramètres rendent les campagnes plus réalistes et plus sûres. -InputArgs remplace les valeurs par défaut des arguments, ce qui permet de varier noms de fichiers ou chemins. -TimeoutSeconds borne la durée de chaque test, fixée par défaut à 120 secondes. Le commutateur -PromptForInputArgs demande interactivement chaque valeur, pratique pour une démonstration commentée devant les analystes.

Atomic Red Team, CALDERA, OpenAEV ou BAS : quelle approche choisir ?

Plusieurs familles d'outils permettent de vérifier qu'un centre opérationnel de sécurité (SOC) détecte les techniques d'attaque. Elles diffèrent par leur granularité, leur degré d'automatisation et l'effort qu'elles demandent. Le tableau suivant les situe les unes par rapport aux autres, y compris les plateformes de simulation d'attaques et de brèches (BAS) proposées par des éditeurs.

Ces approches se combinent plus qu'elles ne s'opposent. Les tests atomiques couvrent la granularité fine et la non-régression, une plateforme d'émulation enchaîne des scénarios, et l'exercice humain évalue la réponse globale. Les journaux au format Attire produits par Invoke-AtomicRedTeam s'importent par exemple dans VECTR, outil de suivi des campagnes purple team, ce qui relie les tests unitaires au reporting de l'exercice.

Pourquoi un SOC a besoin de tests atomiques

Dans un centre opérationnel de sécurité (SOC), beaucoup de règles de détection n'ont jamais été confrontées au comportement qu'elles sont censées repérer. Une source de journaux désactivée lors d'une migration, un champ renommé par une mise à jour du collecteur ou une exclusion trop large suffisent à rendre une règle muette. Sans test, ces défaillances restent invisibles jusqu'au jour où un incident réel passe inaperçu.

L'agence américaine de cybersécurité CISA a documenté ce risque dans son avis AA24-193A sur une évaluation red team publiée en juillet 2024. Parmi les enseignements : une collecte et une analyse des journaux insuffisantes, et une approche fondée sur les indicateurs « connus comme malveillants » qui a empêché de repérer des techniques alternatives. L'agence recommande des détections avant tout comportementales.

Les tests atomiques répondent précisément à ce besoin, car ils reproduisent un comportement et non un indicateur de compromission. Ils permettent de vérifier, technique par technique, que la chaîne complète fonctionne : génération de l'événement sur l'hôte, collecte, analyse par le système de gestion des informations et événements de sécurité (SIEM), déclenchement de l'alerte puis prise en charge par l'analyste.

Les cinq usages les plus rentables

• Valider qu'une source de journaux remonte réellement : Sysmon, auditd, journaux PowerShell, journaux d'un fournisseur d'identité.
• Vérifier qu'une règle SIEM ou EDR se déclenche avec la bonne sévérité et un contexte exploitable.
• Tester la non-régression après une mise à jour d'agent, une migration de SIEM ou un changement de politique d'audit.
• Former les analystes de niveaux 1 et 2 à reconnaître une technique dans la télémétrie brute.
• Produire des preuves de couverture datées pour un audit, un comité des risques ou une revue de prestataire.

Ce que mesure réellement un test

Chaque exécution se conclut par l'un de quatre résultats : l'activité est bloquée, elle déclenche une alerte, elle est journalisée sans alerte, ou elle ne laisse aucune trace exploitable. L'absence d'alerte n'est pas un échec en soi, c'est une information qui indique où investir. Une technique journalisée mais non alertée appelle une règle ; une technique sans trace appelle d'abord une source de télémétrie.

Préparer un laboratoire de test sûr et autorisé

Le laboratoire idéal reproduit les composants qui comptent pour la détection : mêmes agents EDR, même politique d'audit, même collecteur et même SIEM que la production, mais sur des machines jetables. L'objectif est de mesurer ce que verrait le SOC en conditions réelles, sans exposer de données ni de services métier. Un instantané de chaque machine avant la campagne garantit un retour à l'état initial.

Règles de sécurité minimales

1. Obtenir une autorisation écrite précisant périmètre, dates, techniques prévues et contacts d'urgence.
2. Prévenir le SOC interne ou le prestataire de détection managée, sauf exercice volontairement inopiné validé par la direction.
3. Utiliser des machines et des comptes dédiés, jamais des comptes à privilèges de production.
4. Relire les commandes get_prereq_command qui téléchargent des binaires et privilégier une installation hors ligne ou sans charges utiles.
5. Journaliser chaque exécution, lancer le nettoyage, puis restaurer l'instantané en fin de campagne.

Les scripts d'installation proposent une option -NoPayloads qui ne récupère que les fichiers YAML, sans les binaires externes. Elle convient aux environnements sensibles où chaque outil introduit doit être validé. La documentation décrit aussi une installation hors ligne, utile lorsque le laboratoire n'a volontairement aucun accès à Internet.

Retour terrain : Cas typique rencontré en mission — le laboratoire est cloisonné sur un hyperviseur dédié, avec un seul flux sortant autorisé vers le collecteur du SIEM et des tests installés hors ligne. Lors de la première campagne, il arrive régulièrement qu'aucune alerte ne remonte : la stratégie de groupe du domaine de test n'active ni la journalisation des blocs de script PowerShell, ni la collecte du canal Sysmon. Je valide désormais la chaîne de télémétrie avec un événement témoin avant tout test atomique.

Exécuter un premier test Atomic Red Team pas à pas

La séquence suivante, à dérouler sur un poste de laboratoire Windows, suit les commandes documentées par le projet. Elle reprend le test T1016 présenté plus haut, choisi parce qu'il ne modifie pas le système. Les étapes 1 et 3 à 6 correspondent chacune à une ligne de l'encadré de code ; l'étape 2 dépend du mode d'installation et elle est détaillée juste après.

1. Installer le module Invoke-AtomicRedTeam et sa dépendance powershell-yaml pour l'utilisateur courant.
2. Récupérer le dossier des tests (atomics), idéalement avec l'option qui exclut les charges utiles.
3. Lister les tests disponibles pour la technique et repérer leur numéro.
4. Vérifier les prérequis du test choisi.
5. Exécuter le test en journalisant au format Attire.
6. Lancer la commande de nettoyage.

Install-Module -Name invoke-atomicredteam,powershell-yaml -Scope CurrentUser
Invoke-AtomicTest T1016 -ShowDetailsBrief
Invoke-AtomicTest T1016 -TestNumbers 1 -CheckPrereqs
Invoke-AtomicTest T1016 -TestNumbers 1 -LoggingModule "Attire-ExecutionLogger" -ExecutionLogPath "C:\ART\logs\T1016-timestamp.json"
Invoke-AtomicTest T1016 -TestNumbers 1 -Cleanup

La récupération du dossier atomics passe par le script d'installation documenté par le projet, qui expose les fonctions Install-AtomicRedTeam -getAtomics et Install-AtomicsFolder ; la documentation officielle publiée sur atomicredteam.io précise la variante adaptée à chaque mode d'installation. Par défaut, les tests sont cherchés dans C:\AtomicRedTeam\atomics sous Windows et dans $HOME/AtomicRedTeam/atomics sous Linux et macOS.

Journaliser les exécutions pour corréler avec le SIEM

La journalisation des tests atomiques est l'étape la plus sous-estimée. D'après la page Execution Logging du wiki Invoke-AtomicRedTeam, le journal par défaut est un fichier CSV placé dans le répertoire temporaire, qui consigne technique, numéro et nom du test, horodatage, utilisateur et nom d'hôte. Le format Attire, en JSON, ajoute les commandes et leur sortie ; il s'importe dans VECTR.

Deux autres modules envoient les traces là où le centre opérationnel de sécurité (SOC) travaille déjà. Le module Syslog transmet un message JSON vers un serveur de collecte, avec une étiquette personnalisable. Le module WinEvent écrit dans un journal « Atomic Red Team » visible dans l'observateur d'événements Windows. Dans les deux cas, le système de gestion des informations et événements de sécurité (SIEM) dispose de l'heure exacte et de l'hôte du test, ce qui simplifie la corrélation.

De l'exécution à la règle : la boucle d'ingénierie de détection

Un test atomique n'a de valeur que s'il déclenche une action. La boucle d'ingénierie de détection relie sept étapes : choisir la technique, préparer le laboratoire, exécuter le test, observer la télémétrie, qualifier le résultat, créer ou ajuster la règle, puis rejouer le test et nettoyer. Elle s'appuie sur le SOC, l'équipe d'ingénierie de détection et, selon les cas, les administrateurs des outils de journalisation.

Lire la télémétrie produite

Après l'exécution, l'analyste recherche les événements attendus autour de l'horodatage du journal Atomic. Sur Windows, la création de processus apparaît dans l'événement Sysmon 1 ou dans l'événement de sécurité 4688, qui n'inclut la ligne de commande que si l'option d'audit correspondante est activée ; les scripts PowerShell sont visibles dans l'événement 4104 lorsque la journalisation des blocs de script est activée. Sur Linux, auditd et l'EDR fournissent l'équivalent.

Cette lecture révèle souvent des problèmes en amont de la règle : ligne de commande absente, champ tronqué, événement reçu avec plusieurs minutes de retard ou filtré par le collecteur. Ces défauts de collecte sont prioritaires, car aucune logique de détection ne compense une donnée manquante. Documentez-les comme des écarts de visibilité, distincts des écarts de détection.

Écrire une détection robuste plutôt qu'une signature du test

Une fois l'écart identifié, la tentation est forte d'écrire une règle qui reconnaît la ligne de commande exacte du test atomique. C'est une erreur : un attaquant variera les options, l'ordre ou l'outil. Une détection robuste cible le comportement, par exemple une rafale de commandes d'inventaire réseau lancées par un même interpréteur en peu de temps. La requête suivante, en langage KQL pour la chasse avancée de Microsoft Defender XDR, illustre cette logique.

let outils = dynamic(["ipconfig.exe","netsh.exe","arp.exe","nbtstat.exe","net.exe","nltest.exe"]);
DeviceProcessEvents
| where Timestamp > ago(1d)
| where FileName in~ (outils)
| where InitiatingProcessFileName in~ ("cmd.exe","powershell.exe","pwsh.exe")
| summarize Outils = make_set(FileName), NbOutils = dcount(FileName),
            Debut = min(Timestamp), Fin = max(Timestamp)
            by DeviceName, AccountName, InitiatingProcessId
| where NbOutils >= 3 and Fin - Debut < 10m

Le seuil de trois outils en dix minutes est un point de départ à ajuster, car des scripts d'administration légitimes produisent le même motif. Des exclusions documentées, limitées aux comptes et hôtes d'administration connus, évitent les faux positifs sans aveugler la règle. La même logique se transcrit en règle Sigma, format ouvert de description de détections, pour rester portable entre SIEM. Pour prolonger ce travail en chasse, notre guide de threat hunting avec Copilot Security et MITRE ATT&CK propose des requêtes complémentaires.

Rejouer pour prouver

Une règle n'est validée que lorsque le test rejoué produit l'alerte attendue, avec la bonne sévérité et un contexte exploitable par l'analyste. Rejouez ensuite le test avec des arguments différents via -InputArgs pour vérifier que la règle ne dépend pas d'un nom de fichier ou d'un chemin. Enfin, archivez le couple test-règle : il deviendra un cas de non-régression.

Prioriser les techniques à tester en 2026

La bibliothèque couvre plusieurs centaines de techniques et sous-techniques : tout lancer n'a pas de sens. La priorisation part de la menace réellement observée. Le rapport annuel de Red Canary, qui publie pour chaque technique phare des tests atomiques associés, constitue un bon point de départ, à croiser avec le renseignement sur la menace (CTI) propre à votre secteur.

Ce classement montre un déplacement net vers l'identité et le cloud, alors que de nombreux tests atomiques restent centrés sur les postes et serveurs. Des tests existent pour des plateformes comme Azure AD (Entra ID), Office 365 ou l'IaaS AWS, mais ils exigent un locataire de test dédié et une autorisation spécifique. Pour approfondir ces techniques, consultez notre analyse des dix techniques ATT&CK les plus utilisées.

ATT&CK v19 et v20 : remapper la couverture en 2026

Le référentiel MITRE ATT&CK, sur lequel reposent tous les tests atomiques, a fortement évolué en 2026. D'après les notes de version d'avril 2026 de MITRE ATT&CK, la v19 du 28 avril 2026 a scindé la tactique Defense Evasion en deux tactiques, Stealth et Defense Impairment. La version 20 d'ATT&CK, publiée le 13 octobre 2026, compte pour le domaine Enterprise 15 tactiques, 227 techniques et 479 sous-techniques, et ajoute des techniques liées à l'IA.

Conséquence pratique : un tableau de couverture construit avant avril 2026 doit être remappé. Les anciennes sous-techniques d'Impair Defenses (T1562) ont été regroupées ou réattribuées, notamment sous la nouvelle technique T1685 (Disable or Modify Tools), et le dépôt Atomic a suivi cette migration. Vérifiez la version d'ATT&CK utilisée par vos règles, vos tableaux de bord et votre copie locale des tests. Notre présentation du framework MITRE ATT&CK et de ses TTP détaille la structure du référentiel.

Une méthode de priorisation en trois filtres

• Menace : retenir les techniques citées par la CTI sectorielle et les rapports annuels récents.
• Surface : écarter les plateformes absentes du système d'information et cibler les actifs critiques.
• Impact : favoriser les techniques proches d'un dommage majeur, comme l'accès aux identifiants, la désactivation des défenses ou le chiffrement.

Ce triple filtre ramène généralement la liste à une vingtaine de techniques pour une première campagne, ce qui reste gérable en quelques jours de laboratoire. Elle s'enrichit ensuite à chaque nouvelle alerte de la CTI ou à chaque incident, afin que la campagne suivante reflète toujours l'état réel de la menace plutôt qu'un catalogue figé.

Mesurer et industrialiser la couverture de détection

Mesurer la couverture consiste à agréger les résultats des tests par technique et par tactique ATT&CK. Le dépôt fournit des index, notamment des couches pour ATT&CK Navigator, qui permettent de visualiser les techniques disposant de tests. En superposant vos résultats, vous obtenez une carte honnête : techniques testées et détectées, testées sans alerte, ou jamais testées.

Automatiser sans perdre le contrôle

Une fois la campagne initiale stabilisée, l'automatisation transforme les tests en contrôle continu. Invoke-AtomicRedTeam propose un orchestrateur, Invoke-AtomicRunner, conçu pour exécuter des tests selon un planning sur des machines dédiées. Dans une démarche de détection en tant que code, un pipeline peut aussi rejouer les tests liés à une règle dès que celle-ci est modifiée, comme un test unitaire logiciel.

L'automatisation exige des garde-fous : machines de test identifiées dans l'inventaire, exclusions de supervision documentées, nettoyage vérifié et revue humaine des écarts. Sans ces règles, l'exécution planifiée finit par générer un bruit de fond que les analystes apprennent à ignorer, ce qui est exactement l'inverse de l'effet recherché.

Indicateurs utiles au pilotage

• Taux de techniques prioritaires produisant une alerte exploitable.
• Délai médian entre l'exécution du test et la création de l'alerte.
• Nombre de régressions détectées par les campagnes automatiques.
• Part des écarts de visibilité corrigés dans le trimestre.

Évitez les indicateurs de volume comme le nombre de tests lancés : ils mesurent l'activité, pas la protection. Un rapport mensuel court, centré sur les techniques prioritaires et leur évolution, parle davantage à un responsable de la sécurité des systèmes d'information qu'une matrice entièrement colorée sans contexte.

Atomic Red Team dans un exercice purple team

Un exercice purple team réunit l'équipe offensive et le SOC autour d'objectifs communs de détection. Les tests atomiques y jouent souvent le rôle d'échauffement : en une demi-journée, ils établissent une ligne de base de visibilité sur les techniques prévues, avant que les opérateurs ne déroulent un scénario plus réaliste. Notre guide sur la collaboration entre SOC et red team décrit l'organisation de ces séances.

Le déroulé type alterne exécution et analyse en direct : l'opérateur lance un test, les analystes cherchent la trace, l'ingénieur de détection ajuste la règle, puis le test est rejoué. Les écarts non résolus pendant la séance sont consignés avec leur identifiant de test, ce qui permet de les rejouer plus tard à l'identique.

Les tests atomiques ne couvrent pas les chaînes complètes, comme une compromission d'Active Directory depuis un poste utilisateur. Ces scénarios relèvent d'opérateurs expérimentés, dont l'approche est décrite dans notre guide de pentest réseau interne et red team. L'idéal consiste à rejouer ensuite, sous forme atomique, chaque étape qui a échappé au SOC.

Retour terrain : Cas typique rencontré en mission — lors d'un exercice purple team, les tests de découverte s'exécutent sans qu'aucune trace n'apparaisse dans le SIEM, alors que la console EDR les a bien enregistrés. L'écart est inattendu : le connecteur entre l'EDR et le SIEM ne transmet que les alertes de sévérité élevée, et les serveurs Linux n'ont jamais été raccordés au collecteur. La correction consiste à élargir le flux aux alertes de faible sévérité, à intégrer les journaux auditd, puis à rejouer les mêmes tests pour confirmer.

Limites, risques et erreurs fréquentes

Atomic Red Team reste un outil de validation unitaire, avec des limites qu'il faut connaître pour interpréter correctement les résultats. Les erreurs les plus fréquentes ne viennent pas de l'outil, mais de la manière dont les équipes l'utilisent et communiquent sur ce qu'il mesure.

• Confondre test réussi et protection acquise : un test détecté prouve la visibilité sur une procédure, pas sur toutes les variantes de la technique.
• Surajuster les règles : une règle calquée sur la ligne de commande du test se contourne en changeant un paramètre.
• Exécuter en production sans cadre : alertes réelles, escalades inutiles, voire impact sur un service.
• Oublier le nettoyage : fichiers, clés de registre ou tâches planifiées résiduels faussent les tests suivants et peuvent créer un risque.
• Désactiver la protection pour « faire passer » les tests sans la réactiver ensuite.
• Ignorer le décalage de versions entre ATT&CK, la copie locale des tests et les mappings du SIEM.

Le blocage d'un test par l'EDR mérite aussi une lecture attentive. Il prouve que la prévention fonctionne pour cette procédure, mais il empêche parfois d'observer la suite et donc de valider la détection. En laboratoire, un passage en mode audit, documenté et temporaire, permet de mesurer les deux dimensions séparément.

À lire aussi : mesurer le MTTD après chaque test ; MITRE ATLAS pour les systèmes d'IA.

Questions fréquentes

Conclusion

Atomic Red Team transforme la question « sommes-nous capables de détecter cette technique ? » en une expérience courte, reproductible et documentée. Sa force tient à sa simplicité : un test par technique, des commandes lisibles, un nettoyage prévu et une journalisation exploitable par le SIEM. Sa limite est symétrique : il valide une visibilité unitaire, pas une capacité de défense face à un adversaire réel.

Utilisé dans une boucle d'ingénierie de détection, priorisé à partir de la menace de 2026 et rejoué après chaque changement, il devient un véritable contrôle continu pour le SOC. Il trouve naturellement sa place dans une démarche plus large, décrite dans notre méthodologie complète d'exercices purple team, où tests atomiques, émulation et exercices humains se répondent.