Adversary Emulation avec Caldera et MITRE ATT&CK en Lab d'Entreprise

Quand un client appelle en disant qu'il a acheté l'EDR le plus cher du marché et veut savoir si 'c'est bien', la réponse honnête n'est jamais un rapport PowerPoint. C'est une opération d'adversary emulation avec scénario écrit, cartographie ATT&CK et métriques froides : combien d'étapes sont passées silencieuses, combien ont déclenché une alerte, combien ont mené à une réponse humaine en moins de 60 minutes. Chez Basilisk OffSec nous avons standardisé cela autour de Caldera 5.x, Atomic Red Team et d'un lab de domaine Windows à 8 hôtes qui reproduit l'environnement du client sans jamais toucher à sa production. Ce texte décrit la stack, le flux et les erreurs que nous avons payé cher pour ne plus refaire.

Le lab de base est simple et reproductible : un Windows Server 2022 comme DC, deux Server 2019 (fichiers et SQL), trois Windows 11 Enterprise comme postes avec Defender for Endpoint en mode bloquant, et deux Ubuntu 24.04 avec auditd et un agent Wazuh. Le tout orchestré sur Proxmox via Terraform, avec des snapshots nommés par phase de scénario. Pour bâtir le côté Windows depuis zéro, commencez par Pentest Active Directory : Kerberoasting Pas a Pas dans un Lab GOAD, qui livre déjà des ACL volontairement bancales, puis branchez le pivoting décrit dans [[pivoting-chisel-ligolo-rede-pentest]] pour modéliser une vraie segmentation VLAN. Sans cette segmentation, toute métrique de détection de lateral movement est biaisée d'entrée.

Caldera joue le rôle de cerveau de l'opération. Nous montons le serveur sur un Debian isolé, chargeons les plugins 'atomic', 'stockpile' et notre fork interne 'basilisk-ttps' qui regroupe des comportements régionaux comme l'abus d'AnyDesk dans les PME. Chaque adversaire Caldera est un YAML qui cite les techniques ATT&CK par ID : T1059.001 pour PowerShell, T1021.006 pour WinRM, T1003.001 pour le dump LSASS. Nous n'exécutons jamais d'adversaires tout faits sans relecture ; ils servent de benchmark, mais la vraie valeur vient d'écrire des scénarios qui reproduisent le modèle de menaces du client. Un retail avec TPV exposé ne mérite pas le même adversaire qu'une fintech avec Azure AD fédéré.

L'exécution suit un cycle de quatre phases que nous avons appris à respecter. D'abord un initial access simulé sur un endpoint contrôlé, généralement basé sur le playbook de Initial Access Simule: Macros, LNK et ISO dans un Lab Windows 11 Isole avec un payload signé par une CA interne. Ensuite l'exécution et la découverte appuyées sur des LOLBins, là où le contenu de Hunting des Living-off-the-Land Binaries sous Windows avec KQL permet à la blue team d'avoir ses requêtes KQL prêtes avant l'exercice. Puis le lateral movement via SMB et WinRM en exploitant des comptes de service faibles. Enfin les actions sur l'objectif, qui peuvent être l'exfiltration d'une base SQL ou le chiffrement simulé d'un partage. Chaque phase a un critère d'arrêt clair : si l'EDR tue le processus en moins de 90 secondes, on note détecté et on prend une autre route.

La partie ennuyeuse mais décisive, c'est l'instrumentation côté bleu. Sans télémétrie comparable, l'adversary emulation se transforme en théâtre. Nous déployons Sysmon avec la config d'Olaf Hartong, envoyons vers un Elastic 8.14 et appliquons des règles Sigma converties, un flux que nous avons détaillé dans Threat Hunting avec Sigma et Elastic: De l'Indicateur a la Regle de Detection. Chaque événement généré par Caldera reçoit un header custom x-caldera-op-id, ce qui permet de requêter sur Kibana quelle technique a produit quels événements et en combien de temps l'analyste a réagi. Les trois métriques que nous remettons toujours : MTTD par technique, taux de détection par tactique ATT&CK, et nombre de nouvelles règles Sigma écrites en conséquence. Sans ces chiffres, le client pense avoir acheté un pentest et repart frustré.

Il existe des pièges éthiques et opérationnels qu'il faut nommer. L'adversary emulation n'est pas un prétexte pour exécuter de l'évasion d'EDR sur la production d'autrui ; tout ce qui touche aux direct syscalls ou au patching d'AMSI reste cantonné au lab, et qui veut comprendre pourquoi peut lire Evasion EDR pour la Recherche: Direct Syscalls Expliques sans Romance et Bypass d'AMSI et d'ETW pour la Recherche Defensive: Ce que les Blue Teams Doivent Savoir. Nous ne mutualisons jamais l'infrastructure C2 entre clients ; chaque mission reçoit un teamserver Sliver dédié conformément à Construire une Infra C2 avec Sliver en Lab Isole pour la Recherche Defensive. Le rapport final relie chaque TTP à une contre-mesure concrète et alimente la boucle décrite dans Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue, évitant que l'exercice finisse au cimetière des PDF.

Conseil pratique : commencez petit. Montez un Caldera, écrivez un adversaire avec cinq techniques ATT&CK alignées sur votre vrai modèle de menaces, exécutez-le contre trois endpoints monitorés et mesurez le MTTD par technique. Répétez mensuellement en changeant une technique à chaque cycle. En six mois vous aurez une courbe de maturité défendable devant la direction, sans acheter aucun nouvel outil coûteux, et votre SOC arrêtera de râler qu'il 'ne se passe jamais rien' pendant les entraînements.