L'atelier purple team comme exercice pédagogique : un lab offensif-défensif en 4 heures
Pourquoi le purple team est un format pédagogique sous-exploité
Le CTF a sa place dans tous les cursus cyber. Le TP pentest isolé aussi. Mais il existe un format plus riche, plus proche des exercices réels menés en entreprise, et pourtant quasi absent des salles de classe : l'atelier purple team.
Le purple team n'est pas une troisième équipe qui viendrait s'ajouter au red et au blue. C'est un mode de collaboration structuré entre attaquants et défenseurs, où chaque phase offensive est suivie d'un échange explicite sur ce qui a fonctionné, ce qui a été détecté, et pourquoi. L'objectif n'est pas de "gagner", mais de faire progresser simultanément les deux équipes.
Ce que gagne l'étudiant attaquant : une compréhension concrète de ce que ses techniques génèrent comme traces dans les outils de détection. Ce que gagne l'étudiant défenseur : une lecture directe des vecteurs d'attaque réels, bien au-delà de ce que les alertes génériques d'un SIEM peuvent suggérer. Ce double apprentissage simultané est propre au format purple team — aucun autre exercice pédagogique ne le produit aussi efficacement.
Pourquoi ce format reste-t-il sous-utilisé en pédagogie ? Plusieurs raisons concrètes. Il demande une infrastructure double : un lab offensif et un lab défensif connectés sur la même cible. Il demande que les deux équipes aient déjà un socle technique solide — un red team débutant face à un blue team débutant ne produit aucune interaction utile. Et il demande une facilitation rigoureuse : sans cadre formel, l'atelier déraille rapidement en TP pentest classique sans échanges.
Ces obstacles sont réels, mais surmontables. Cet article vous propose un cadre praticien pour concevoir et animer un atelier purple team de 4 heures avec des étudiants de niveau Master.
Différences avec le CTF et le red vs blue classique
Avant de construire l'atelier, il est utile de clarifier ce qui le distingue des formats que vos étudiants connaissent déjà.
| Critère | CTF (jeopardy) | Red vs Blue classique | Atelier purple team |
|---|---|---|---|
| Objectif principal | Trouver le flag | Attaquer / défendre | Apprendre mutuellement |
| Interaction entre équipes | Aucune | Indirecte (via les systèmes) | Directe et structurée |
| Partage d'information | Non | Non | Obligatoire après chaque phase |
| Scoring | Points pour les flags | Score d'attaque / défense | Qualité technique et des échanges |
| Format temporel | Continu | Simultané | Séquencé (attaque → échange → défense) |
| Niveau requis | L3 et plus | M1 minimum | M1 avec modules red ET blue |
| Valeur pédagogique principale | Technique offensive | Compétition réaliste | Compréhension systémique |
Le CTF teste des compétences techniques dans un cadre compétitif. Le red vs blue classique simule un adversaire réel contre des défenseurs, mais les deux équipes n'échangent qu'à la fin — souvent avec frustration des deux côtés. Le purple team rompt les silos : l'attaquant explique sa technique, le défenseur explique ce qu'il a vu (ou raté). Ce dialogue structuré est le cœur de la valeur pédagogique du format.
Infrastructure minimale pour un atelier de 4 heures
L'un des freins perçus est l'infrastructure. En réalité, un atelier purple team de 4 heures peut se construire sur une base très accessible pour n'importe quel laboratoire pédagogique cyber.
Le lab offensif
L'équipe attaquante opère depuis une machine Kali Linux (VM ou système natif). Elle dispose d'une cible vulnérable délibérément configurée : une VM Metasploitable 3, une infrastructure DVWA, ou un environnement Active Directory volontairement mal configuré sous Windows Server.
Les outils mobilisés dans le scénario doivent être déjà connus des étudiants : Nmap pour la reconnaissance, Metasploit Framework pour l'exploitation initiale, CrackMapExec ou BloodHound pour la cartographie Active Directory, Responder ou Mimikatz selon le scénario retenu. L'atelier purple team n'est pas le moment d'introduire des outils nouveaux — les étudiants doivent pouvoir se concentrer sur la dimension collaborative, pas sur la prise en main d'un outil.
Le lab défensif
L'équipe défense dispose d'une visibilité sur la même infrastructure via un SIEM. Les deux piles les plus accessibles en contexte pédagogique sont :
- ELK Stack (Elasticsearch, Logstash, Kibana) : puissant, entièrement open source, avec une grande flexibilité pour les requêtes de corrélation.
- Wazuh : solution open source orientée EDR + SIEM, avec des agents à déployer sur les machines cibles. Wazuh génère des alertes structurées et dispose d'une interface intuitive, particulièrement adaptée à un atelier de durée limitée.
La machine cible doit avoir les agents de collecte installés et configurés avant le début de l'atelier. Un Sysmon déployé avec une ruleset de base (par exemple la configuration Olaf Hartong) sur les machines Windows produit une télémétrie suffisamment riche pour que les étudiants blue puissent travailler efficacement.
La séparation réseau
Les deux réseaux — réseau d'attaque et réseau de surveillance — doivent être isolés du réseau de production de l'établissement. Une architecture simple fonctionne : deux VLANs distincts sur un hyperviseur (VirtualBox ou VMware Workstation Pro), avec la machine cible visible depuis les deux segments. Si vous disposez d'un lab cyber existant, l'atelier s'y intègre directement sans infrastructure supplémentaire.
Un lab minimal se monte en moins d'une journée pour quelqu'un qui connaît les outils. Le matériel nécessaire : un ou deux serveurs de virtualisation, quelques VMs préconfigurées, un switch manageable pour les VLANs.
Déroulé de l'atelier : phase par phase
Un atelier de 4 heures se décompose en phases courtes et cadencées. La rigueur du timing est essentielle : c'est ce qui évite à l'atelier de dériver en TP pentest classique sans échanges.
| Phase | Durée | Contenu |
|---|---|---|
| Briefing général | 15 min | Règles, objectifs, présentation du scénario, rappel des outils disponibles |
| Phase 1 — Reconnaissance | 30 min | Red team : scan réseau, énumération. Blue team : baseline du SIEM, premières alertes. |
| Debriefing 1 | 10 min | Red explique ce qu'il a fait. Blue explique ce qu'il a détecté (ou non). |
| Phase 2 — Accès initial | 30 min | Red team : exploitation d'une vulnérabilité. Blue team : détection, investigation de l'alerte. |
| Debriefing 2 | 15 min | Analyse commune : quel IOC aurait permis une détection plus précoce ? |
| Phase 3 — Mouvement latéral | 30 min | Red team : pass-the-hash, credential dumping, pivot vers un second hôte. Blue team : corrélation d'alertes, pivot dans le SIEM. |
| Debriefing 3 | 15 min | Quelle règle de détection aurait dû exister ? Rédaction collaborative d'une règle Sigma. |
| Phase 4 — Objectif final | 25 min | Red team : exfiltration ou atteinte de l'objectif. Blue team : réponse à incident, tentative de blocage. |
| Restitution finale | 30 min | Présentation croisée, scoring, feedback formateur |
Ce découpage séquentiel est non-négociable dans un cadre pédagogique. Les debriefings intermédiaires sont le moment où l'apprentissage se consolide. Un atelier qui enchaîne toutes les phases sans pause d'échange ressemble à un red vs blue — pas à un purple team.
Le scénario recommandé pour un premier atelier
Pour une première édition, un scénario simple mais réaliste fonctionne mieux qu'un scénario trop complexe. Un bon point de départ : compromission d'un poste Windows depuis une vulnérabilité réseau, puis mouvement latéral vers un contrôleur de domaine.
Les étapes techniques : scan Nmap → exploitation d'un service vulnérable (SMB ou RDP mal configuré) → Meterpreter shell → extraction de credentials via Mimikatz → mouvement latéral avec CrackMapExec → accès au DC.
Ce scénario couvre une chaîne d'attaque complète, mobilise des outils que les étudiants connaissent, et génère des évènements détectables dans ELK ou Wazuh à chaque étape. Chaque phase du debriefing a donc matière à s'appuyer sur des logs réels et des alertes concrètes.
Rôles, scoring et grille de restitution
Les rôles dans chaque équipe
Chaque équipe de 3 à 5 étudiants se distribue des rôles précis dès le briefing. La distribution ne doit pas être laissée au hasard : sans attribution explicite, les membres les plus à l'aise monopolisent l'activité technique et les autres deviennent spectateurs.
Red team :
- Lead attaquant : responsable de la progression technique, prend les décisions d'exploitation
- Scribe offensif : documente chaque action avec horodatage (commande exécutée, résultat, machine cible)
- Communicant : prépare les debriefings, explique les techniques aux défenseurs de façon accessible
Blue team :
- Analyste SIEM : surveille le tableau de bord, trie les alertes, formule des requêtes de corrélation
- Responsable investigation : part des alertes pour reconstituer le chemin d'attaque dans les logs
- Incident manager : prend les décisions de réponse, prépare les debriefings, initie le rapport de réponse à incident
Le rôle de scribe est crucial des deux côtés. Un atelier purple team sans documentation produit des debriefings vagues et peu exploitables. Avec une trace écrite de chaque action et de chaque alerte, les échanges sont précis, ancrés dans des faits techniques, et pédagogiquement formateurs.
Le scoring
Le scoring d'un atelier purple team ne doit pas récompenser uniquement "qui a gagné". Il récompense la qualité du travail technique et la qualité des échanges.
Critères de scoring red team :
- Progression technique (accès obtenus, objectifs atteints) — 40 %
- Qualité de la documentation (log d'actions, IOCs produits) — 30 %
- Qualité des explications lors des debriefings — 30 %
Critères de scoring blue team :
- Taux de détection (alertes levées sur les actions réelles du red team) — 40 %
- Qualité de l'investigation (reconstruction de la timeline d'attaque) — 30 %
- Qualité des échanges et des propositions de remédiation — 30 %
Ce scoring valorise explicitement la communication. Un red teamer qui exploite toute l'infrastructure en silence mais ne sait pas expliquer ce qu'il a fait obtient un score médiocre. Un blue team qui lève une alerte mais ne peut pas l'articuler avec la chaîne d'attaque complète est également pénalisé.
La grille de restitution
La restitution finale suit une grille structurée que le formateur distribue dès le briefing initial. Les deux équipes présentent en 10 minutes maximum :
- La timeline de l'attaque — reconstituée côté red et côté blue. Les divergences entre les deux versions sont des points d'apprentissage majeurs.
- Les techniques utilisées avec leur classification dans le framework MITRE ATT&CK — une habitude à ancrer dès les premiers ateliers.
- Ce qui a été détecté et ce qui ne l'a pas été — et pourquoi.
- Une règle de détection proposée conjointement par les deux équipes (au format Sigma ou en pseudo-code structuré).
- Une recommandation de remédiation pour chaque vecteur exploité.
Cette grille transforme la restitution en livrable réel, pas en simple discussion. Le formateur évalue les présentations à l'aide de la grille de scoring, ce qui permet une notation cohérente même sur plusieurs groupes simultanés.
Adapter l'atelier au niveau et à la taille du groupe
Pour des Master 1 avec socle solide
C'est le public idéal pour cet atelier : des étudiants qui ont déjà pratiqué des cours de red team et des cours de blue team dans des modules séparés. L'atelier décrit ci-dessus leur convient tel quel. On peut y ajouter une contrainte d'évasion pour les plus avancés : le red team doit contourner les règles Sigma déjà chargées dans le SIEM, ce qui oblige les deux équipes à anticiper mutuellement.
Pour des Master 2 spécialisés
Pour des profils avancés, augmenter la complexité du scénario : intrusion via phishing simulé avec GoPhish, persistance (clé de registre, tâche planifiée, service Windows), escalade de privilèges Active Directory via Kerberoasting ou ACL abuse. L'objectif final peut être la modification d'une GPO — une action à fort impact métier qui génère des logs très reconnaissables dans Wazuh.
Le debriefing pour ce profil inclut un mapping MITRE ATT&CK complet : chaque action du red team est positionnée manuellement sur la matrice, ce que les deux équipes construisent ensemble. C'est une compétence directement applicable en entreprise, que ce soit en SOC ou en opérations offensives.
Pour une promo de 30 étudiants
Avec 30 étudiants, constituer 3 groupes de 10 — 5 red et 5 blue par groupe — chacun travaillant sur un scénario distinct de difficulté équivalente. Les trois scénarios peuvent partager le même lab sous-jacent, avec des vecteurs d'accès initial différents (SMB, RDP, service web) pour éviter les échanges de solutions entre groupes.
La restitution finale réunit les trois groupes : chaque groupe présente son scénario en 10 minutes. Le reste de la promotion découvre ainsi deux chaînes d'attaque qu'il n'a pas pratiquées, ce qui enrichit collectivement les connaissances au-delà du seul scénario vécu.
Le cas particulier des L3
Pour des L3 avec une seule unité d'enseignement de sécurité, un atelier purple team complet est prématuré. Un format simplifié reste possible : une seule attaque prédéfinie (un exploit Metasploit bien documenté sur une cible connue), avec un SIEM préconfiguré qui génère les alertes automatiquement. L'exercice se concentre alors uniquement sur le debriefing : comprendre l'alerte, comprendre l'exploit, relier les deux. C'est moins riche techniquement, mais introduit la logique collaborative du cours purple team dans un format accessible.
Faire tourner les rôles
Sur deux sessions consécutives, faire tourner les équipes : les attaquants d'une session deviennent les défenseurs de la suivante. Cette rotation est pédagogiquement puissante. Les étudiants qui ont passé 4 heures à attaquer comprennent immédiatement ce qu'un défenseur voit de leurs actions — et inversement. La symétrie de perspective est difficile à produire par d'autres moyens pédagogiques.
Ce qu'il faut retenir
Le purple team pédagogique n'est pas un CTF amélioré, ni un red vs blue avec une session de feedback en fin de journée. C'est un format radicalement différent dans sa logique : il structure la collaboration entre attaquants et défenseurs autour d'échanges explicites et documentés, avec un scoring qui récompense la compréhension mutuelle autant que la performance technique.
Ce format demande une infrastructure accessible — Kali, Wazuh ou ELK, une cible vulnérable, un hyperviseur — et une organisation rigoureuse : rôles distribués dès le briefing, timings tenus phase par phase, grille de restitution distribuée en amont. Ces contraintes ne sont pas des obstacles : elles sont la condition de la réussite pédagogique.
Pour des étudiants en Master qui ont déjà pratiqué des modules offensifs et défensifs séparément, cet atelier produit un saut qualitatif visible. Ils commencent à penser en systèmes complets, à articuler l'attaque et la détection comme les deux faces du même problème. C'est précisément la compétence que les équipes SOC et les red teamers expérimentés ont mis des années à développer sur le terrain. Un atelier bien conçu peut en poser les bases en 4 heures.
Vous souhaitez faire intervenir un professionnel expérimenté en purple team dans votre école ou université ?
Cyber Teachers vous met en relation avec des praticiens capables de concevoir et d'animer cet atelier, de la définition du scénario à l'évaluation des restitutions.