Cours Active Directory & Windows Server - Partie 6-bis¶

Discipline Red Team : la couche opérationnelle¶

Windows Server 2022 - complément offensif de la Partie 6¶

AVERTISSEMENT - MÊME CADRE QUE LA PARTIE 6, RENFORCÉ. Cette partie enseigne la discipline opérationnelle du Red Team, pas de nouvelles techniques d'intrusion. Tout se pratique sur ton lab isolé (corp.lab.local / GOAD) ou en mission mandatée avec scope écrit. Opérer un C2, du phishing ou de l'évasion contre un système que tu ne possèdes pas, sans mandat, est un délit pénal - et, s'agissant d'infrastructure C2 et d'ingénierie sociale, les qualifications pénales sont encore plus lourdes (accès frauduleux, escroquerie, association de malfaiteurs). Le mandat écrit n'est pas une option, c'est la condition d'existence du métier.

Ligne rouge assumée de cette partie : sur l'OPSEC et l'évasion (module 65), j'enseigne les concepts et surtout leur détection - comment et pourquoi ça fonctionne, et comment la Blue Team le voit. Je ne fournis pas de contournement d'EDR/AMSI clé-en-main ni de kit armé. La frontière entre former un défenseur et livrer une arme est exactement là, et un ingénieur sérieux la tient. Un contournement qui « marche tout seul » n'a aucune valeur pédagogique ; comprendre le chat et la souris pour mieux détecter, si.

Prérequis : Parties 1 à 6. La Partie 6 t'a donné les mains (recon, escalade, latéral, domination). Cette partie te donne la tête : comment on planifie, on opère furtivement, on émule un vrai adversaire, et on restitue pour faire progresser la défense. C'est le passage de « je connais les techniques » à « je conduis une opération ».

Structure (6 modules, 62 → 67)¶

62 - Red Team vs pentest vs purple : cadre & cycle d'opération
63 - Émulation d'adversaire & threat intelligence (ATT&CK, CALDERA, Atomic Red Team)
64 - Infrastructure offensive & C2 (architecture)
65 - OPSEC & évasion (concepts + détection, pas de kit)
66 - La couche humaine : accès initial & ingénierie sociale (méthodo & défense)
67 - Le livrable : rapport, timeline, restitution Blue Team + projet final

Module 62 - Red Team vs pentest vs purple : cadre & cycle¶

62.1 Trois métiers qu'on confond, une différence qui n'est pas dans les outils¶

C'est le malentendu fondateur : Red Team, pentest et purple utilisent les mêmes techniques (celles de la Partie 6). La différence est dans l'objectif et la posture :

	Pentest	Red Team	Purple Team
Objectif	Trouver un maximum de vulnérabilités	Émuler un adversaire réel sur un objectif précis	Améliorer la détection en collaborant red+blue
Cible testée	Les systèmes	Les systèmes ET la Blue Team (détection/réponse)	Les capacités de détection
Posture	Large, bruyant, exhaustif	Furtif, ciblé, réaliste	Ouvert, itératif, « lumières allumées »
Blue Team	Souvent au courant	Pas au courant (test grandeur nature)	Pleinement impliquée
Livrable	Liste de findings	Récit d'opération + ce que la blue a vu/raté	Règles de détection améliorées

La bascule mentale : en pentest, réussir = trouver la faille. En Red Team, réussir = atteindre l'objectif sans être détecté (ou en mesurant quand on l'a été). Ton adversaire n'est plus la machine, c'est le SOC. Tout change : le rythme, la discrétion, le choix des techniques.

62.2 Le mandat Red Team : plus exigeant encore¶

Au-delà du scope de la Partie 6, une mission Red Team formalise :

Les objectifs (crown jewels) : « prouver l'accès à la base RH » plutôt que « pentester le SI ». On opère par objectif, pas par exhaustivité.
Les règles d'engagement (ROE) fines : techniques autorisées/interdites, systèmes hors-limites, fenêtres horaires, seuil de « stop ».
Le modèle de départ : black box (rien), assume breach (on te donne un pied dans la porte - le plus rentable, car on ne perd pas des semaines sur l'accès initial), ou hybride.
Le "get out of jail letter" : lettre d'autorisation signée que l'opérateur porte sur lui - sa protection légale si un physique/social tourne mal.
Le trusted agent : un contact côté client, dans la confidence, qui peut arbitrer et stopper.
La déconfliction : distinguer un vrai incident (un vrai attaquant pendant ton test !) de ton activité.

62.3 Le cycle d'opération (la colonne vertébrale)¶

Une opération Red Team suit un cycle discipliné, calqué sur les intrusions réelles :

1. Reconnaissance      (OSINT, surface externe - sans toucher, souvent)
2. Weaponization        (préparer l'accès initial : leurre, payload)
3. Accès initial        (phishing, exposition externe - module 66)
4. Établissement du C2  (implant + callback - module 64)
5. Ancrage / persistance (survivre au reboot, discrètement - P6 M59)
6. Escalade & découverte (P6 M56 / recon interne)
7. Mouvement latéral    (P6 M57, en minimisant le bruit)
8. Actions sur objectif (atteindre les crown jewels)
9. Exfiltration (simulée) / preuve
10. Nettoyage & restitution (module 67)

Chaque étape se fait au rythme de la furtivité, pas de l'efficacité brute. Là où un pentester enchaîne, un opérateur red team attend, observe, dose - parce qu'il sait qu'un SOC corrèle les événements (ta Partie 6, module 60, mais vue depuis l'autre côté).

62.4 Exercice n°52¶

Rédige un plan d'opération Red Team pour corp.lab.local : objectif unique (crown jewel), modèle assume breach, ROE, trusted agent, critères de stop.
Reprends les techniques de la Partie 6 et reclasse-les dans les 10 étapes du cycle 62.3.
Explique en 5 lignes pourquoi une même technique (ex. DCSync) se joue différemment en pentest et en Red Team.

Module 63 - Émulation d'adversaire & threat intelligence¶

63.1 Émuler, pas improviser¶

Un Red Team mûr ne « balance pas toute la boîte à outils ». Il émule un adversaire précis - un groupe (APT) pertinent pour le secteur du client - en rejouant ses TTP réels (Tactics, Techniques, Procedures). Objectif : tester si la défense détecte les menaces qui la visent vraiment, pas des attaques génériques.

63.2 MITRE ATT&CK comme langage commun¶

ATT&CK (revu en Partie 6) devient ici un outil de planification :

On choisit un groupe dans ATT&CK (chaque groupe a sa fiche : techniques utilisées, outils).
On construit un plan d'émulation : la séquence de techniques Txxxx que cet acteur emploierait.
On mappe chaque technique à ce que la Blue Team devrait voir (data sources ATT&CK) → c'est déjà la grille de restitution du module 67.

MITRE publie des Adversary Emulation Plans prêts à l'emploi (ex. pour des acteurs connus) : un cadeau pour structurer une opération réaliste.

63.3 Les outils d'émulation¶

Atomic Red Team : une bibliothèque de tests atomiques - de petites actions, une par technique ATT&CK, faciles à exécuter et à détecter. Idéal pour tester une détection précise (« mon SIEM voit-il un DCSync ? ») sans monter une opération complète. C'est le pont purple par excellence.
CALDERA (MITRE) : une plateforme d'émulation automatisée - un serveur qui pilote des agents et déroule des chaînes ATT&CK de façon autonome. Utile pour rejouer des scénarios reproductibles et mesurer la couverture de détection à l'échelle.
Prelude, VECTR (suivi/scoring des exercices purple), etc.

Usage d'ingénieur : Atomic Red Team pour valider une règle (tu tires l'atomique, ta règle Sigma de la P6 doit s'allumer), CALDERA pour mesurer la couverture globale de ton SOC. Tu passes de « j'espère que je détecte » à « je prouve, technique par technique, ce que je détecte ».

63.4 La matrice de couverture (heatmap)¶

Le livrable-clé de l'émulation : une heatmap ATT&CK de ta détection. Chaque technique testée est coloriée selon que la Blue Team l'a détectée / partiellement / ratée. C'est la carte objective des trous de ton SOC - infiniment plus utile qu'un « on est plutôt bons en sécurité ».

63.5 Exercice n°53¶

Choisis un groupe ATT&CK pertinent et construis un mini-plan d'émulation (5-8 techniques) applicable à corp.lab.local.
Avec Atomic Red Team, exécute 3 tests atomiques (ex. Kerberoasting, DCSync, création de service) et vérifie que tes règles de détection (P6 M60) s'allument.
Construis la heatmap ATT&CK de ta détection : vert (détecté) / orange (partiel) / rouge (raté). Identifie tes 3 pires trous.

Module 64 - Infrastructure offensive & Command and Control (C2)¶

64.1 Le vrai cœur métier de l'opérateur¶

Ce que la Partie 6 ne couvrait pas : comment on pilote une opération à distance, dans la durée, discrètement. C'est le rôle du C2 (Command and Control) et de l'infrastructure offensive autour. C'est la compétence qui sépare le lanceur d'outils de l'opérateur.

64.2 Anatomie d'un C2¶

flowchart LR
    O["Opérateur"] --> TS["TEAM SERVER (C2)"]
    TS --> R["Redirecteurs"]
    R --> I["Implant sur la cible"]
    I -.->|"canal de commande chiffré<br/>(callback / beacon périodique)"| TS

L'implant (beacon/agent) : le programme déposé sur la machine compromise. Il « rappelle » (callback) le C2 à intervalle réglable (sleep/jitter) pour recevoir des ordres et renvoyer des résultats. Le jitter (aléa sur l'intervalle) casse la régularité qui trahit une machine.
Le team server : le serveur qui gère les implants, la collaboration entre opérateurs, les tâches.
Les redirecteurs : des relais (souvent HTTP/S) placés devant le team server pour le masquer. Si un redirecteur est grillé, on le jette sans perdre le C2. C'est l'équivalent offensif d'un reverse proxy.
Les profils de communication : le trafic C2 est maquillé pour ressembler à du trafic légitime (ex. requêtes web anodines). Les canaux varient : HTTPS, DNS, SMB (peer-to-peer entre implants dans un réseau segmenté), etc.

64.3 Les frameworks C2 (paysage)¶

Tous publics et largement documentés :

Cobalt Strike - le standard commercial du secteur (et, ironie, très utilisé par de vrais attaquants → très surveillé). Concept de Malleable C2 profiles pour façonner le trafic.
Sliver (BishopFox) - open source, moderne, cross-platform, devenu très populaire.
Mythic - framework modulaire open source, multi-agents.
Havoc, Empire (historique), Metasploit (plus orienté exploitation).

Cadrage d'ingénieur : je te décris l'architecture et les concepts (beacon, jitter, redirecteurs, profils) parce que c'est ce qu'un opérateur et un défenseur doivent comprendre. Le montage d'une infra C2 opérationnelle furtive se fait dans ton lab, pour toi-même - et l'essentiel de sa valeur, côté ce cours, est de comprendre comment on la détecte (64.4).

64.4 🛡️ Détection du C2 (le pivot blue, central ici)¶

C'est LA partie qui compte pour un défenseur, et elle est riche :

Analyse de balise (beaconing) : détecter la régularité des callbacks - même avec jitter, un implant génère un motif temporel statistiquement anormal. Des outils/analytics (ex. RITA, analyses NetFlow) traquent ça.
Réputation & anomalies réseau : connexions vers des domaines jeunes, catégorisés faiblement, JA3/JA3S (empreintes TLS) inhabituelles, volumes montants anormaux.
DNS tunneling : requêtes DNS anormalement longues/fréquentes/entropiques → C2 sur DNS.
Détection hôte : processus qui fait du réseau alors qu'il ne devrait pas (notepad.exe qui parle à Internet), injection dans des processus légitimes, rundll32/regsvr32 sortants.
Défense : proxy filtrant sortant (egress filtering - bloquer ce qui n'a pas à sortir), inspection TLS, EDR comportemental, segmentation qui limite le mouvement des implants peer-to-peer.

Leçon : le trafic C2 est le talon d'Achille de l'attaquant - il doit bien communiquer avec l'extérieur. Un défenseur qui maîtrise l'egress filtering et l'analyse de beaconing casse des opérations entières. C'est souvent plus rentable que de courir après chaque technique hôte.

64.5 Exercice n°54¶

Dans ton lab isolé, monte un C2 open source (Sliver/Mythic) avec un implant sur une VM, règle le sleep/jitter, observe le trafic de callback.
Côté blue : capture ce trafic et caractérise le beaconing (intervalle, régularité). Écris la logique de détection.
Mets en place un egress filtering minimal et montre qu'il casse le callback.
Explique pourquoi les redirecteurs protègent le team server, et ce que la Blue Team voit (le redirecteur) vs ce qu'elle ne voit pas (le C2 réel).

Module 65 - OPSEC & évasion : concepts et détection¶

65.1 Le cadre de ce module (à lire d'abord)¶

Ce module explique comment fonctionnent les défenses modernes des terminaux et pourquoi un adversaire cherche à les contourner - pour que tu saches les configurer, les surveiller et détecter les tentatives de contournement. Je reste au niveau concept + détection. Je ne donne pas de bypass armé : d'une part c'est la ligne éthique de ce cours, d'autre part ces techniques se périment en semaines (course à l'armement) alors que les principes de détection, eux, durent. Un ingénieur investit dans ce qui dure.

65.2 Les capteurs défensifs : ce que l'attaquant doit éviter¶

Pour comprendre l'évasion, il faut d'abord comprendre ce qui observe sur un hôte Windows moderne :

EDR (Endpoint Detection and Response) : va bien au-delà de l'antivirus. Il s'accroche aux comportements (création de processus, injections, appels sensibles) via des hooks en espace utilisateur, des callbacks noyau, et la télémétrie ETW. Il corrèle et remonte au SOC.
AMSI (Antimalware Scan Interface) : une interface où scripts (PowerShell, VBScript, JS) et contenus en mémoire sont soumis à l'antimalware avant exécution - d'où son rôle central contre les scripts offensifs.
ETW (Event Tracing for Windows) : la télémétrie profonde du système (notamment Microsoft-Windows-Threat-Intelligence pour les EDR).
Sysmon : capteur gratuit (Sysinternals) qui journalise finement création de processus, connexions, injections, chargements de modules - le meilleur ami du défenseur dans un lab.
Script Block Logging / Module Logging / Transcription (P4) : la traçabilité PowerShell.

65.3 Les grandes familles d'évasion (au niveau conceptuel)¶

L'attaquant cherche à réduire les artefacts que ces capteurs voient. Les grandes idées, sans recette :

Exécution en mémoire : éviter d'écrire un fichier sur disque (ce que l'AV signature le mieux) en travaillant en RAM. → Détection : l'EDR surveille les régions mémoire exécutables anormales, les injections.
Living-off-the-Land (LOLBins) : utiliser des binaires légitimes signés Microsoft (rundll32, mshta, regsvr32, certutil, wmic…) pour des actions malveillantes, afin de se fondre. → Détection : ces binaires avec des lignes de commande ou des relations parent/enfant anormales (le projet LOLBAS catalogue les usages abusifs → base de règles défensives).
Contournement d'AMSI / ETW : neutraliser ou aveugler ces capteurs. → Détection : justement, l'absence soudaine de télémétrie, les patterns de patching mémoire de ces composants, les événements d'intégrité.
Obfuscation : rendre un script/binaire méconnaissable des signatures. → Détection : bascule vers la détection comportementale (ce que ça fait) plutôt que statique (à quoi ça ressemble) - d'où la supériorité de l'EDR sur l'AV signature.
Timing & discrétion : sleep long, jitter, actions espacées pour déjouer la corrélation. → Détection : analyse long terme, baselining.

65.4 🛡️ Ingénierie de détection : la vraie compétence à bâtir¶

Puisqu'on ne court pas après chaque bypass, on investit dans une détection robuste :

Déployer Sysmon avec une configuration éprouvée (ex. les configs communautaires de référence) → télémétrie riche vers le SIEM.
Détection comportementale : chaîne parent/enfant suspecte (winword.exe→powershell.exe→réseau), LOLBins hors contexte, injections, création de services distants (P6 M57).
Détecter l'aveuglement : une chute de volume de logs AMSI/ETW/Script Block est en soi une alerte (l'attaquant a coupé les lumières).
Renforcer les capteurs : ASR (P4) bloque nativement plusieurs comportements d'évasion (ex. « bloquer la création de processus enfant par Office »), WDAC/AppLocker (P4) empêchent l'exécution non autorisée en amont, Credential Guard (P4) neutralise le vol de secrets même après exécution.
Threat hunting : chasser proactivement les LOLBins, les beacons (M64), les anomalies - sans attendre l'alerte.

La bascule d'ingénieur : l'attaquant a l'avantage sur une technique donnée à un instant donné ; le défenseur a l'avantage sur la durée et la corrélation. Tu ne gagnes pas en connaissant le dernier bypass, tu gagnes en instrumentant profondément et en détectant les invariants (il faut bien communiquer, exécuter, persister). Concentre ton énergie là.

65.5 Exercice n°55¶

Déploie Sysmon (config de référence) sur corp.lab.local, remonte vers ton SIEM (P6 M60).
Rejoue une action LOLBin bénigne dans ton lab (ex. certutil de téléchargement) et écris la règle qui la détecte via le contexte (parent, ligne de commande).
Provoque une chute artificielle de la télémétrie PowerShell et écris une détection d'aveuglement (baisse anormale de volume).
Active une règle ASR pertinente et montre qu'elle bloque un comportement d'évasion en amont.

Module 66 - La couche humaine : accès initial & ingénierie sociale¶

66.1 Pourquoi ce module (et son cadrage)¶

Dans la réalité, la majorité des intrusions commencent par l'humain (phishing), pas par une faille technique. Un Red Team réaliste doit donc traiter l'accès initial social. Cadrage : je traite ici la méthodologie, l'architecture d'un test autorisé et surtout la défense/sensibilisation - pas un kit de campagne de phishing prêt à tromper de vraies victimes hors mandat. L'ingénierie sociale non autorisée est une escroquerie ; en mission, elle exige un volet juridique et RH spécifique (consentement, anonymisation des résultats, pas de sanction individuelle).

66.2 Les vecteurs d'accès initial¶

Phishing / spear-phishing : mail ciblé menant à un vol d'identifiants (fausse page) ou à l'exécution d'un leurre (pièce jointe/lien → implant, M64).
Pretexting : un scénario crédible (faux support IT, faux fournisseur) pour obtenir un accès ou une info.
Vishing / smishing : par téléphone / SMS.
Physique : badge, tailgating, drop de périphériques - hors périmètre de ce cours AD, mais partie du Red Team complet.
Exposition externe : services exposés, identifiants fuités (OSINT, dumps publics) → credential stuffing.

66.3 Anatomie d'un test de phishing autorisé¶

1. Cadrage RH/juridique : consentement, objectifs, PAS de sanction individuelle
2. OSINT : construire la liste cible (emails, organigramme) - données publiques
3. Pretexte crédible : contexte métier plausible, expéditeur ressemblant
4. Infrastructure : domaine look-alike, page/leurre, capture (outils : GoPhish, Evilginx en lab)
5. Envoi contrôlé + mesure : taux d'ouverture / clic / saisie / signalement
6. Restitution AGRÉGÉE : statistiques, pas de "name & shame"

Le taux de signalement (combien ont alerté le SOC) est une métrique aussi importante que le taux de clic : il mesure la maturité défensive humaine.

66.4 🛡️ Détection & défense (le cœur)¶

Technique : filtrage mail (anti-spoofing SPF/DKIM/DMARC, sandboxing des pièces jointes, réécriture d'URL, bannière « expéditeur externe »), MFA résistant au phishing (FIDO2/passkeys > OTP, car l'OTP se relaie via des proxies type Evilginx), blocage des macros Office par défaut (P4/ASR).
Humaine : sensibilisation continue (pas une fois par an), bouton « signaler un phishing » qui alimente le SOC, culture sans blâme (on veut que les gens signalent, pas qu'ils cachent).
Processus : procédure claire de vérification pour les demandes sensibles (virements, resets) - contre le pretexting.

Vérité d'ingénieur : tu ne « corriges » pas l'humain comme un serveur. Tu réduis sa surface (MFA anti-phishing, macros bloquées, filtrage) pour qu'une erreur humaine ne suffise plus, et tu transformes les gens en capteurs (signalement). L'objectif n'est pas zéro clic - c'est qu'un clic ne donne pas le domaine.

66.5 Exercice n°56¶

Dans ton lab, monte GoPhish et une campagne contre tes propres comptes de test uniquement. Mesure clic/saisie/signalement.
Déploie SPF/DKIM/DMARC sur ton domaine de lab et une bannière « externe » ; explique ce que chacun bloque.
Explique pourquoi FIDO2/passkeys résiste au relais d'authentification (Evilginx) là où l'OTP ne résiste pas.
Rédige la procédure de vérification anti-pretexting pour une demande de reset de mot de passe (lien avec ta délégation JEA/helpdesk, P4).

Module 67 - Le livrable : rapport, timeline & restitution Blue Team¶

67.1 Ce qui justifie l'existence d'une Red Team¶

Une opération Red Team ne vaut rien sans sa restitution. Le livrable n'est pas « on a eu Domain Admin » - c'est « voici votre parcours d'attaque, voici ce que votre SOC a vu et raté, voici comment vous améliorer ». Un opérateur qui sait exploiter mais pas restituer est un demi-professionnel.

67.2 Le rapport d'opération¶

Structure attendue :

Synthèse exécutive (pour la direction, sans jargon) : objectif atteint ou non, niveau de risque, 3-5 messages clés.
Récit d'attaque (attack narrative) : l'histoire chronologique de l'opération, étape par étape, lisible.
Findings priorisés : chaque faiblesse (technique ou humaine ou de détection), son risque, ses preuves, sa remédiation. Renvoi systématique aux Parties 1-4 pour la correction.
Annexes techniques : détails, IOC, commandes (pour la reproductibilité par la blue).

67.3 La timeline attaque ↔ détection (le document purple)¶

Le livrable le plus précieux : une table à deux colonnes confrontant ce que le Red a fait et ce que le Blue a vu.

Heure	Action Red Team (ATT&CK)	Artefact généré	Détecté par la Blue ?	Écart / recommandation
T0	Phishing → implant (T1566)	Mail, process enfant Office	Non	Bannière ext. + ASR macros
T+2h	Kerberoasting (T1558.003)	4769 RC4	Oui (règle Sigma)	OK - étendre au honeypot SPN
T+5h	DCSync (T1003.006)	4662 réplication	Non	Alerte « réplication non-DC »
T+6h	Golden Ticket (T1558.001)	TGT anormal	Partiel	Baseline durée de vie tickets

Cette table est le pont vers ton module 60 (détection) et 63 (heatmap ATT&CK). Elle transforme une intrusion en feuille de route défensive chiffrée : « votre temps de détection moyen est de X, vous avez raté N étapes sur M, priorité à ceci ».

67.4 Les métriques qui parlent au management¶

MTTD / MTTR : temps moyen de détection / de réponse (les métriques reines du SOC).
Taux de détection : % d'étapes ATT&CK détectées (la heatmap, M63).
Dwell time simulé : combien de temps l'attaquant serait resté invisible.
Taux de signalement humain (phishing, M66).

67.5 La restitution et la boucle d'amélioration¶

Débrief conjoint red + blue : pas un procès, un apprentissage. On rejoue la timeline ensemble.
Nouvelles détections : chaque « raté » de la timeline devient une règle (P6 M60) que la blue écrit et teste (Atomic Red Team, M63).
Re-test : plus tard, on rejoue les mêmes TTP → les trous sont-ils bouchés ? C'est la mesure du progrès.
Postmortem blameless (rappel P4 M35) : on cherche la faille systémique, jamais le coupable.

67.6 Projet fil rouge : « Opération CORP »¶

Objectif : conduire une opération Red Team complète sur corp.lab.local, la détecter, la restituer, et prouver l'amélioration.

Checklist :

[ ] Plan d'opération (objectif/crown jewel, assume breach, ROE) - module 62.
[ ] Plan d'émulation ATT&CK d'un adversaire choisi + heatmap de couverture - module 63.
[ ] C2 opéré dans le lab, callback caractérisé et détecté côté blue - module 64.
[ ] Sysmon + SIEM instrumentés ; détection comportementale et d'aveuglement - module 65.
[ ] Accès initial social simulé sur comptes de test + défenses (DMARC, FIDO2, ASR) - module 66.
[ ] Cycle complet joué (recon → objectif), journalisé côté red.
[ ] Timeline attaque↔détection remplie, MTTD/MTTR mesurés, taux de détection chiffré.
[ ] Chaque « raté » converti en règle Sigma testée, puis re-test prouvant la correction.
[ ] Rapport pro (synthèse exécutive + narrative + findings priorisés) et débrief blameless.

67.7 Questions type entretien (opérateur / lead red team)¶

Différence fondamentale Red Team vs pentest ? Contre qui opère-t-on vraiment ?
Qu'est-ce que l'assume breach et pourquoi est-ce souvent le modèle le plus rentable ?
Décris l'architecture d'un C2 avec redirecteurs. Que voit la Blue Team, que ne voit-elle pas ?
Pourquoi le trafic C2 est-il le talon d'Achille de l'attaquant, et comment le détecter (beaconing) ?
Pourquoi investir dans la détection comportementale plutôt que courir après les bypass ?
Qu'est-ce qu'un LOLBin, et comment le détecte-t-on malgré sa légitimité ?
Pourquoi FIDO2 résiste-t-il au phishing par proxy (Evilginx) et pas l'OTP ?
Quelle est la vraie valeur d'une opération Red Team, et à quoi ressemble son livrable ?
Comment une timeline attaque↔détection alimente-t-elle l'amélioration continue du SOC ?
Émulation d'adversaire : qu'apporte-t-elle par rapport à « lancer toute la boîte à outils » ?

67.8 Conclusion - l'axe offensif est complet¶

Avec la Partie 6 (techniques) et cette Partie 6-bis (discipline opérationnelle), tu tiens l'axe offensif complet : tu sais planifier une opération, émuler un vrai adversaire, opérer un C2, rester furtif en comprenant les capteurs, tester la couche humaine, et restituer pour faire progresser la défense. Le tout ancré dans le socle des Parties 1-5.

Le point que je veux te laisser, avec ma casquette d'ingénieur : la maîtrise offensive n'a de valeur que rendue à la défense. Un opérateur qui décroche Domain Admin mais ne fait pas progresser le SOC a échoué. Le meilleur red teamer est celui qui rend la prochaine opération plus difficile - la sienne comprise.

Et la suite, définitivement : il n'y a plus d'offensif on-prem à ajouter. Les deux marches restantes sont un changement de dimension, et toutes deux capitalisent sur cet axe :

Trajectoire 2 - hybride/cloud : l'offensive des identités cloud (Entra ID, jetons OAuth, Entra Connect, abus de Conditional Access). Le Red Team moderne y passe de plus en plus.
Trajectoire 3 - tout-en-code / DevSecOps : où cette Partie 6-bis se cristallise en audit continu - CALDERA/Atomic Red Team en CI, la heatmap ATT&CK recalculée à chaque changement, la sécurité comme test de non-régression. C'est, avec ta casquette Google, la marche la plus alignée.

Annexe - Cycle d'opération ↔ discipline ↔ détection¶

Phase	Discipline / techniques	Détection / restitution
PLAN (62)	objectif/ROE/assume breach	déconfliction, trusted agent
ÉMULATION (63)	ATT&CK / CALDERA / Atomic	heatmap de couverture
C2 (64)	beacon / redirecteurs / jitter	analyse de beaconing, egress filtering
OPSEC (65)	LOLBins / in-memory / anti-AMSI	Sysmon, détection comportementale + aveuglement
HUMAIN (66)	phishing / pretexting	DMARC, FIDO2, ASR macros, signalement
LIVRABLE (67)	rapport + timeline attaque↔détection	MTTD/MTTR, règles testées, re-test

Fin de la Partie 6-bis. La ligne qui la résume : un Red Team ne se juge pas à ce qu'il compromet, mais à ce que la Blue Team en apprend. Le mandat d'abord, la furtivité ensuite, la restitution toujours - et l'OPSEC se comprend pour être détectée, pas pour être armée.