Framework purple-team automatisé : Méthodologie d'exercice

Qu’est-ce que le Purple Teaming ?

Le purple teaming est un mode de collaboration entre red team et blue team avec un objectif commun : améliorer la détection et la réponse aux incidents.

La problématique : comment générer des exercices réguliers sans surcharger les équipes ?

Les équipes de sécurité font face à un dilemme récurrent : les exercices purple team sont l’une des meilleures approches pour valider et améliorer la capacité du SOC à détecter et répondre aux menaces. D’un autre côté, ces exercices mobilisent beaucoup de ressources humaines et de temps. Chaque exercice demande une préparation pouvant parfois être longue, puis le temps d’exercice peut influer sur la complexité et les actions pouvant être menées lors de l’exercice. De plus, l’analyse des résultats et le temps d’échange entre les équipes pour retravailler les règles de détection et le fonctionnement des outils de sécurité peuvent eux aussi être longs. Le résultat : les équipes ne peuvent lancer que peu voir pas d’exercices dans l’année.

Analyse de l’existant

Avant de concevoir le framework, j’ai examiné les solutions disponibles sur le marché.

CALDERA (MITRE) est un outil open-source très complet pour l’automatisation d’attaques. Cependant, il ne s’intègre pas naturellement aux infrastructures automatisées. Il n’y a pas de gestion des labs, les binaires par défaut sont tous détectés par un simple Defender, et il ne permet pas initialement de mener des campagnes complexes basées sur l’évasion d’un SOC. De plus, après quelques tests, il n’est pas simple de réécrire cette application pour l’adapter à notre besoin.

Atomic Red Team propose une excellente bibliothèque de tests atomiques alignés sur le framework MITRE ATT&CK. Mais c’est avant tout une collection de scripts unitaires, pas un framework complet capable de gérer les labs, les utilisateurs, les scénarios complexes et la comparaison des résultats. Et, comme CALDERA qui utilise cette bibliothèque, tous ces TTPs sont déjà repérés par Defender.

Vectr est conçu pour le suivi et la documentation des exercices purple team. C’est un très bon outil de reporting, mais il ne propose pas d’automatisation d’exécution, ni de gestion d’infrastructure, ni d’intégration avec les outils du SOC.

Ce qu’il manque dans les frameworks et outils actuels : il n’existe pas d’outil qui combine à la fois le déploiement rapide d’un lab proche du réseau réel, l’exécution automatisée de scripts d’attaque, et la comparaison automatique des résultats avec les alertes du SOC. Je reprendrai des composants et fonctionnalités des solutions vues, en y ajoutant les parties manquantes identifiées dans mon framework.

Structure d’un exercice purple team

Avant d’entrer dans les détails techniques, il est important de comprendre le déroulement logique d’un exercice.

Phase 1 : Préparation. On définit le périmètre et les objectifs de l’exercice. Les équipes s’alignent sur les TTP (Tactics, Techniques, Procedures) à tester. L’infrastructure de test est préparée pour permettre la possibilité de tester les règles ou actions voulues et préétablies par la blue team et la red team. La white team prépare l’infrastructure, la blue team interconnecte ses outils dans la plateforme, et la red team prépare ses scénarios d’attaque.

Phase 2 : Exécution. La red team exécute chaque TTP de façon transparente et documentée. La blue team observe et valide ou non si une détection a eu lieu.

Phase 3 : Analyse conjointe. Pour chaque TTP non détecté, on crée ou améliore les règles de détection. On procède au tuning du SIEM et à l’ajustement des alertes.

Le framework purple team automatisé

Pour répondre à cette problématique, j’ai conçu un framework qu’on peut décomposer en plusieurs composants, chacun jouant un rôle spécifique dans l’automatisation complète du cycle d’exercice.

Pile technologique

Ludus (Proxmox) : C’est la plateforme de virtualisation qui héberge les labs de test, elle est intégrée à Proxmox. J’ai choisi Ludus pour son API ouverte, sa capacité à déployer des environnements de test à partir d’un seul fichier YAML, et la possibilité d’intégrer cette API directement dans mon backend.

FastAPI comme backend : il offre la flexibilité nécessaire pour orchestrer l’ensemble des technologies du framework. Il s’interface avec l’API de Ludus, celle des outils du SOC, et gère les états du framework. J’ai utilisé SQLAlchemy pour la couche ORM, ce qui permet des évolutions rapides et itératives de la base de données.

PostgreSQL centralise toutes les données : les utilisateurs, les clés API Ludus, les configurations d’exercices, les métadonnées (configuration des scripts, historique des exécutions, rôles des utilisateurs, états des labs), mais aussi les logs des exercices, etc.

Redis capture les logs d’exécution en temps réel. Les scripts Ansible émettent leurs logs dans un stream Redis, que le frontend consulte en continu pour afficher l’exécution en direct.

Vue 3 / Vite en frontend pour une interface de développement rapide et facile à maintenir.

Docker Ansible Runner est une image Docker custom qui contient tous les outils Ansible. À chaque exécution d’attaque, un conteneur est instancié avec les bonnes configurations VPN, lance les scripts Ansible, puis se détruit automatiquement une fois terminé.

Le Docker Ansible Runner : l’exécuteur

Quand on lance une attaque depuis le frontend :

Un container Docker est instancié avec le fichier de configuration VPN du lab cible.
Le container intègre les scripts d’attaque à exécuter et se connecte au lab via VPN.
Ansible exécute les tâches sur les machines cibles du lab.
Pendant l’exécution, tous les logs sont streamés en temps réel dans Redis.
Une fois terminé, le container se détruit automatiquement.

Ce design garantit que chaque exécution est isolée, reproductible et tracée intégralement.

Les scripts d’attaque :

Les scripts sont écrits en YAML Ansible et encapsulent la logique d’une attaque. Ils embarquent obligatoirement :

Des variables de connexion : la méthode d’accès à la machine cible (WinRM pour Windows, SSH pour Linux), les identifiants utilisateur et mot de passe.

Des variables de tâche : celles qui paramètrent le comportement du script (chemins, registres, paramètres d’exploitation).

Depuis le frontend, au moment de la préparation de l’exécution, il est possible d’écraser les valeurs des variables. Cela permet de réutiliser le même script sur différents labs, avec différents noms de domaine, différentes plages IP, différents niveaux de complexité.

Chaque script est associé à des métadonnées en BDD :

L’auteur et le niveau de l’attaque (script-kiddie, intermédiaire, avancé, APT), la visibilité (public ou privé), le nombre d’exécutions, le nombre de succès et d’erreurs. Cela permet un bon suivi et une évolution des scripts sur la plateforme.

Les logs d’exécution de chaque script sont conservés en base de données, ce qui permet de revenir consulter précisément ce qui s’est passé lors d’une exécution antérieure.

Gestion des labs via Ludus

L’API de Ludus a été complètement intégrée au backend. Depuis l’interface web, on peut gérer :

Les utilisateurs et leurs labs respectifs. Les machines (allumage/extinction, suppression, snapshots, déploiement). L’activation du mode testing.

Le frontend envoie les requêtes au backend, qui utilise la clé API de l’utilisateur pour les relayer vers le serveur Ludus via un tunnel SSH. Cela permet une isolation des credentials et un contrôle granulaire des accès.

Pour cette partie, seuls les membres de la red-team et de la white-team y ont accès. S’ils souhaitent l’utiliser, ils doivent enregistrer leur clé API Ludus, laquelle est conservée en base de données.

Système de rôles et permissions

La plateforme segmente les accès selon les responsabilités et rôles des utilisateurs :

Superuser : accès complet. Gère tous les utilisateurs et toutes les configurations.

Red_Team_Manager / Blue_Team_Manager : peuvent gérer les membres de leur équipe respective.

Red_Team_Admin / Blue_Team_Admin : droits étendus au sein de leur équipe.

Red_Team_User / Blue_Team_User : accès aux fonctionnalités propres à leur équipe.

White_Team : accès à la section Ludus pour créer et administrer les labs.

La white team est responsable de l’infrastructure : préparation des ranges Ludus, configuration des fichiers YAML de déploiement, administration des labs. La red team crée et exécute les scripts d’attaque. La blue team accède au dashboard de détection pour analyser les résultats.

Chaque nouvel utilisateur s’enregistre sur la plateforme soit en tant qu’utilisateur red team, blue team ou white team. Un administrateur peut ensuite élever le rôle du compte ou le retirer de sa team s’il ne correspond pas à la bonne équipe. Les managers ne peuvent gérer que les utilisateurs de leur propre équipe. On part du principe que ce framework est interne à une organisation et qu’il n’est pas nécessaire de passer par un compte sans rôle qui devrait être validé et attribué à une équipe manuellement par un manager ou un administrateur, afin de limiter les délais et les contraintes d’usage.

Configuration des VMs : les rôles personnalisés Ansible

Ludus automatise le déploiement des ranges via des fichiers de configuration YAML Ansible. J’ai créé plusieurs rôles personnalisés pour lier les VMs aux réelles outils du SOC :

Rôle WEC : installe et configure Windows Event Collector sur un Windows Server. Pousse une GPO pour collecter toutes les logs des machines du domaine et les envoyer vers la pipeline du SOC.
Rôle Sysmon : installe et paramètre Sysmon sur toutes les machines Windows.
Rôle Logs_Linux : configure l’envoi direct des logs Linux vers la pipeline du SOC.
Rôle EDR_Windows / EDR_Linux : paramètre l’agent EDR sur les machines du lab et le lie à la solution EDR réelle utilisée par les équipes.

D’autres rôles ont été créés ou adaptés pour déployer Exchange, ADCS et d’autres services habituel.

Ces rôles custom garantissent que les labs de test reproduisent au mieux la configuration de l’infrastructure réel de l’organisation.

Le scenario builder : construire des attaques réalistes

En complément de l’exécution de scripts isolés, la plateforme intègre un constructeur de scénarios d’attaque.

Depuis cette interface, on peut créer un scénario structuré aligné sur le framework MITRE ATT&CK : reconnaissance, resource development, initial access, execution, persistence, etc. Dans chaque phase, on ajoute les scripts d’attaque correspondants, on paramètre leurs variables et on sélectionne les machines cibles.

L’interface propose une navigation directe du framework MITRE ATT&CK, ce qui permet d’identifier rapidement les TTPs à tester et de les ajouter au scénario.

Une fois le scénario configuré, on peut le sauvegarder pour le rejouer ultérieurement sur un autre lab ou à une autre date. On sélectionne le lab Ludus cible et on lance l’ensemble du scénario en un seul clic.

Le but est de permettre à la red team de construire une base de scénarios et de connaissances, et de pouvoir dupliquer des scénarios ou TTPs sous plusieurs variantes et niveaux d’évasion. Du côté de la blue team, cela offre une visibilité claire sur la couverture de détection par phase.

Le dashboard blue-team : mesurer la couverture

Le dashboard effectue des appels vers l’outil centralisant toutes les alertes du SOC et compare automatiquement :

Les scripts exécutés versus les règles qui auraient dû émettre une alerte.

Les règles qui ont effectivement sonné versus celles qui étaient attendues.

Il affiche :

Un pourcentage de taux de détection global.
La liste des règles qui n’ont pas sonné et qui nécessitent du travail.
La liste des règles inattendues qui ont sonné.
Des graphiques de performance : red team versus capacité de détection du SOC pour l’exercice.

Isolation des logs ansible : ne pas polluer la pipeline et éviter les faux positifs

Étant donné que la plage IP du réseau VPN d’accès au lab dans Ludus est prédéfinie, j’ai créé des règles d’exclusion pour que ces logs ne polluent pas la pipeline du SOC. Cette plage est exclue des outils de remontée de logs sur Linux, Windows et sur le WEC.

Cela garantit que la pipeline du SOC ne traite que les logs pertinents et que les faux positifs issus de l’exécution des tasks Ansible ne biaisent pas les métriques de détection.

Défis techniques et solutions

Plusieurs défis ont été rencontrés lors du développement.

La synchronisation des logs en temps réel. Le streaming des logs Ansible via Redis a nécessité du travail pour garantir qu’aucun log ne soit perdu entre l’exécution dans le container et l’affichage au frontend, notamment lors d’interruptions du container. Il a également fallu améliorer leur lisibilité et ne pas exposer les logs bruts aux utilisateurs.
La gestion du cycle de vie du container. Il a fallu s’assurer que le Docker Ansible Runner se détruit proprement après chaque exécution, même en cas d’erreur ou de timeout Ansible, pour éviter les containers orphelins connectés en VPN, et garantir son isolement afin qu’il n’exécute ses scripts qu’une fois connecté au VPN du lab, sans pouvoir les exécuter sur le serveur Ludus.
La portabilité des scripts. Un script écrit pour un lab spécifique doit pouvoir être réutilisé sur n’importe quel autre lab. Cela demande une gestion rigoureuse des variables et une attention particulière aux différences d’environnement (nom de domaine, plages IP, versions d’OS). Pour cela, j’ai créé un squelette réutilisable pour la création des nouveaux scripts afin d’éviter les erreurs.
Le mapping des alertes. La corrélation automatique entre une alerte SOC et le script d’attaque qui l’a provoquée repose sur des timestamps. Avant l’exécution d’un script, un log est généré et envoyé dans la pipeline du SOC, et de même à la fin, pour permettre de trier les alertes et les relier à un script. Les règles attendues sont définies dans les métadonnées du script par la blue team.

Résultats et validation

Le framework a été validé sur plusieurs scénarios couvrant différentes phases ATT&CK. Un exemple concret : un scénario en trois phases initial access par phishing simulé, privilege escalation, lateral movement, exécuté sur un lab Ludus avec un domaine Active Directory, Sysmon sur les machines Windows, et les logs envoyés vers la pipeline réelle du SOC.

Sur ce scénario, le dashboard blue team a fourni immédiatement :

La vision de ce qui a été détecté ou non, les règles SIEM qui ont sonné, et celles qui nécessitent du travail. Ces données, qui auraient pris plusieurs jours à être récoltées entre la planification de l’exercice, son exécution et son retex, ont pu être générées en quelques minutes.

À noter : l’objectif n’est pas forcément d’atteindre 100 % de détection. Un taux de 100 % signifierait plutôt que les scripts sont trop bruyants ou mal conçus. L’objectif est d’établir une baseline mesurable et de la faire évoluer dans le temps pour améliorer progressivement le score de détection. Ce score peut aussi temporairement baisser si la red team développe de nouvelles méthodes d’attaque plus complexes permettant d’évader les règles actuelles. Ces évolutions stimulent la compétition entre red team et blue team, avec pour but commun d’améliorer la sécurité globale de l’organisation.

Perspectives et évolution

Ce framework répond à la problématique initiale : permettre des exercices purple team réguliers sans mobiliser massivement les équipes à chaque fois. Une fois les scripts écrits et les labs configurés, relancer un exercice complet se fait en quelques clics.

Les axes d’amélioration à envisager :

Scheduling automatique. Planifier des exécutions récurrentes sans intervention humaine pour un suivi continu de la couverture de détection.
Intégration CI/CD sécurité. Déclencher automatiquement un exercice lors d’une mise à jour des règles SIEM ou d’un changement d’infrastructure.
Enrichissement de la bibliothèque de scripts. Plus la red team alimente la base, plus la couverture MITRE testée s’élargit et plus les futures exécutions gagnent en pertinence.
Reporting automatisé. Générer des rapports périodiques sur l’évolution du taux de détection à destination des équipes concernées.

À terme, l’objectif est qu’une grande partie des exercices se déroule de façon autonome. Les équipes n’interviennent que pour l’analyse des résultats et l’amélioration des règles de détection. La charge humaine se déplace de la planification et de l’exécution vers l’analyse et l’amélioration.