Pourquoi le pentest Active Directory
Comprendre pourquoi Active Directory concentre le risque de compromission en entreprise, poser le cadre légal et éthique d'un test d'intrusion, et distinguer audit de configuration et Red Team avant d'entrer dans la technique.
Table des matières
Pourquoi Active Directory reste la cible n°1
Dans l'immense majorité des systèmes d'information d'entreprise en France, Active Directory (AD) est l'épine dorsale de l'authentification et des droits d'accès. Postes de travail, serveurs de fichiers, messagerie, ERP, VPNVPNRéseauxRéseau privé virtuel qui chiffre le trafic entre deux points sur un réseau public. Il crée un tunnel sécurisé permettant d'accéder à des ressources distantes comme si on était sur le réseau local.Voir dans le glossaire — tout ou presque s'appuie, directement ou via une fédération, sur un annuaire AD. Cette centralisation est une force opérationnelle et une faiblesse structurelle : compromettre le domaine, c'est souvent compromettre l'intégralité du système d'information en une seule chaîne d'actions.
Les retours d'expérience des équipes de réponse à incident convergent : dans la très grande majorité des compromissions ransomware touchant des entreprises françaises, l'attaquant obtient à un moment ou un autre des droits d'administrateur du domaine. Ce n'est pas une coïncidence. AD a près de vingt-cinq ans d'héritage technique, des mécanismes de compatibilité ascendante encore actifs par défaut sur de nombreux domaines, et une complexité de configuration qui laisse prospérer des erreurs invisibles à l'œil nu — une délégation Kerberos oubliée, une ACL trop permissive héritée d'un projet ponctuel, un compte de service avec un mot de passe vieux de huit ans.
Le pentest Active Directory ne consiste donc pas à « pirater Windows ». Il consiste à reproduire, de façon contrôlée et autorisée, le chemin qu'emprunterait un attaquant réel entre un point d'entrée initial (un poste utilisateur compromis, un accès VPN, un identifiant phishé) et la compromission complète du domaine — puis à documenter ce chemin pour que l'entreprise puisse le couper.
Cette centralisation explique aussi pourquoi les commanditaires de tests d'intrusion — DSI, RSSI, direction générale dans les entreprises les plus matures — orientent de plus en plus leurs budgets vers l'audit AD plutôt que vers le seul périmètre exposé sur internet. Un site web mal protégé cause un incident localisé ; un domaine Active Directory compromis cause un arrêt d'activité généralisé, avec des délais de restauration qui se comptent souvent en semaines. Le coût moyen d'une crise ransomware pour une PME ou une ETI françaises dépasse largement le coût d'un audit préventif, ce qui rend l'argument budgétaire relativement simple à défendre auprès d'une direction, à condition de savoir le formuler — un point sur lequel nous reviendrons dans le chapitre consacré au reporting.
Ce que couvre cette formation
Ce parcours de douze chapitres suit la logique d'une mission réelle, de la reconnaissance au rapport final :
- Cartographie du domaine (trusts, OUs, DNSDNSRéseauxSystème qui traduit un nom de domaine en adresse IP, par interrogations successives de la racine, des serveurs de premier niveau puis des serveurs faisant autorité.Voir dans le glossaire, sites AD)
- Énumération LDAP et SMB sans bruit excessif
- Fondamentaux Kerberos et abus courants (Kerberoasting, AS-REP Roasting)
- Mouvement latéral et escalade de privilèges (ACL, GPO, ADCS)
- Cartographie des chemins d'attaque avec BloodHound
- Persistence, détection et défense côté bleu
- Reporting et plan de remédiation, avec un atelier de synthèse
Chaque chapitre technique est pensé pour un usage en environnement de test — laboratoire personnel ou plateforme d'entraînement dédiée (Hack The Box, un lab AD monté en local avec des VM Windows Server, une plateforme interne de CTF d'entreprise). Aucune technique n'est présentée comme une fin en soi : elle est toujours reliée à une question de risque métier et à une remédiation.
L'ordre des chapitres suit délibérément la logique d'une intervention réelle plutôt qu'un classement par famille d'outilstool callingIACapacité d'un agent ou d'un LLM à invoquer des outils externes (API, calcul, recherche) pendant le raisonnement.Voir dans le glossaire. Vous ne verrez pas un chapitre « Mimikatz » ou un chapitre « BloodHound » isolé de son contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire d'usage : chaque outil apparaît au moment de la mission où il devient pertinent, précédé de l'explication du mécanisme qu'il exploite. C'est un choix pédagogique assumé — comprendre pourquoi une extraction de tickets Kerberos fonctionne compte davantage que mémoriser la commande qui la déclenche, parce que les commandes changent d'une version d'outil à l'autre alors que le mécanisme sous-jacent, lui, reste stable pendant des années.
Ceci n'est pas un cours de « hacking » générique et ce n'est pas une autorisation implicite à tester un système que vous ne possédez pas ou pour lequel vous n'avez pas de mandat écrit. Toute technique présentée dans ce parcours suppose un périmètre autorisé, explicite et daté. Sans cela, les mêmes actions changent de nature juridique : d'un exercice professionnel encadré, elles deviennent une infraction pénale.
Cadre légal et scope autorisé
En droit français, l'accès ou le maintien frauduleux dans un système de traitement automatisé de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire est réprimé par les articles 323-1 et suivants du Code pénal, indépendamment de l'intention de nuire ou du préjudice réellement causé. Le fait qu'aucune donnée n'ait été détruite, qu'aucun système n'ait été rendu indisponible, ne change rien à la qualification : l'accès sans autorisation suffit.
Cela signifie concrètement, pour vous en tant que pentester :
- Un mandat écrit précède toute action, même une simple énumération DNS passive sur un domaine qui ne vous appartient pas.
- Le mandat définit un scope précis : quels domaines, quelles plages IP, quelles techniques sont autorisées ou explicitement exclues (par exemple, l'interdiction de tester le déni de service ou de manipuler les GPO de production).
- Une fenêtre temporelle encadre le test, avec des contacts d'urgence côté client en cas d'incident (verrouillage de comptes en masse, alerte SOC déclenchée, service perturbé).
- Les preuves de compromission sont minimisées : un pentester démontre qu'il peut lire un fichier confidentiel, il n'a pas besoin de l'exfiltrer intégralement pour le prouver.
« Le prestataire est autorisé à réaliser un test d'intrusion interne sur le domaine CORP.EXEMPLE.LOCAL, contrôleurs de domaine DC01 et DC02 inclus, du 3 au 14 novembre, hors créneaux 8h-9h et 17h-18h. Les techniques de déni de service et le verrouillage intentionnel de comptes à privilèges sont interdits. Contact d'astreinte : RSSI, joignable 24/7 au numéro fourni en annexe. »
Ce document engage juridiquement les deux parties. Il protège le client (périmètre maîtrisé) et il vous protège vous-même : sans lui, aucune assurance professionnelle ne couvre votre intervention, et vous êtes seul face à une éventuelle plainte.
Red Team vs audit de configuration : deux méthodes, deux objectifs
Le terme « pentest AD » recouvre en réalité deux approches assez différentes, souvent confondues par les clients eux-mêmes lors du cadrage initial.
| Critère | Audit de configuration | Red Team / test d'intrusion ciblé |
|---|---|---|
| Objectif | Lister un maximum de faiblesses | Atteindre un objectif précis (admin domaine, accès à un serveur métier) |
| Posture | Assumée, visible, exhaustive | Furtive, discrète, minimise le bruit |
| Durée type | Quelques jours, méthode systématique | Souvent plus longue, dépend de la détection |
| Détection SOC | Non pertinente à l'exercice | Fait partie de l'évaluation (l'équipe bleue est-elle alertée ?) |
| Livrable principal | Liste priorisée des vulnérabilités | Récit du chemin d'attaque + capacités de détection observées |
| Question posée au client | « Quelles sont toutes mes failles ? » | « Un attaquant motivé atteindrait-il ma cible, et serait-il vu ? » |
Aucune des deux approches n'est supérieure à l'autre dans l'absolu : elles répondent à des questions différentes. Un audit de configuration convient à une entreprise qui cherche à durcir son AD avant une certification ou après un incident. Un exercice Red Team convient à une organisation mature en cybersécurité qui veut tester sa capacité de détection et de réponse, pas seulement l'existence de failles techniques.
Cette formation couvre principalement les techniques transposables aux deux contextes, mais insiste sur la discipline OPSEC (operations security — limiter son empreinte, éviter le bruit inutile sur les journaux) dès qu'elle est pertinente, car c'est souvent le point faible des débutants : techniquement corrects, ils génèrent un volume d'alertes qui trahirait immédiatement un attaquant réel.
Certaines techniques présentées plus loin dans ce parcours (relais NTLM, abus de délégation Kerberos, extraction de tickets) peuvent, mal maîtrisées, provoquer un verrouillage de comptes en masse ou une instabilité de service sur un environnement de production. En laboratoire, l'erreur ne coûte rien. En mission réelle, elle peut interrompre l'activité d'un client et engager votre responsabilité contractuelle. La règle est simple : on ne teste jamais une technique inconnue pour la première fois sur un environnement de production.
Ce que vous saurez faire à la fin du parcours
À l'issue des douze chapitres, l'objectif est que vous puissiez :
- Cartographier un domaine AD inconnu et identifier ses points d'entrée probables sans déclencher d'alerte immédiate
- Expliquer et exploiter, en environnement de test, les faiblesses Kerberos et LDAP les plus fréquentes (Kerberoasting, AS-REP Roasting, abus d'ACL)
- Construire un chemin d'attaque complet avec BloodHound et le présenter de façon lisible à un public technique comme non technique
- Distinguer une action nécessaire à la démonstration d'une action superflue qui augmente le risque sans apporter de preuve supplémentaire
- Rédiger un rapport de pentest actionnable : sévérité justifiée, preuve reproductible, remédiation réaliste et priorisée sur 30/90 jours
Les chapitres techniques supposent un environnement pratique : au minimum un contrôleur de domaine Windows Server (édition Evaluation, gratuite pendant 180 jours), deux ou trois machines jointes au domaine, et une machine d'attaque Kali ou équivalent. Des labs prêts à l'emploi existent aussi sur des plateformes dédiées si le montage d'une infrastructure locale n'est pas envisageable tout de suite. Ne commencez pas les chapitres pratiques sans ce filet : lire une commande n'apprend pas à interpréter sa sortie.
Prérequis techniques et éthiques
Ce parcours est classé niveau avancé : il suppose que vous êtes déjà à l'aise avec l'administration Windows Server et les notions de base d'Active Directory (objets, OUs, GPO), avec les fondamentaux réseau (TCPTCPRéseauxProtocole de transport qui garantit que les données arrivent complètes, dans l'ordre et sans doublon. Il établit une connexion, numérote chaque segment et retransmet ce qui manque.Voir dans le glossaire/IP, résolution DNS, notion de session authentifiée), et avec l'usage d'une distribution orientée sécurité offensive. Si l'un de ces trois piliers vous manque, ce parcours restera compréhensible en surface mais la pratique sera frustrante — mieux vaut consolider ces bases en amont.
Le prérequis éthique est tout aussi important que le prérequis technique. Un pentester AD manipule potentiellement des données sensibles (mots de passe, contenus de messagerie, documents confidentiels) dans le cadre de sa démonstration. La règle professionnelle est constante d'un mandat à l'autre : accéder au strict nécessaire pour prouver le risque, ne jamais exploiter l'accès obtenu à des fins personnelles, et documenter précisément ce qui a été consulté pour que le client puisse évaluer l'impact réel.
BloodHound, Impacket, Rubeus, Mimikatz et les autres outils mentionnés dans les chapitres suivants sont des outils légitimes, utilisés quotidiennement par les équipes de sécurité défensive autant qu'offensive. Leur usage sur un système sans autorisation reste une infraction, indépendamment de la réputation ou de la licence de l'outil. La légalité d'une action se juge par le mandat, jamais par l'outil employé.
Erreurs de débutant à éviter dès le départ
Quelques pièges reviennent systématiquement chez les pentesters qui découvrent AD :
- Confondre exhaustivité et pertinence — scanner tout le domaine sans hypothèse ni priorisation produit un volume de données ingérable et un rapport dilué. Une méthode structurée (cartographie → hypothèses → vérification) vaut mieux qu'un scan aveugle.
- Ignorer l'OPSEC dès le laboratoire — prendre de mauvaises habitudes (requêtes LDAP massives, brute-force bruyant) en environnement de test se paie cher en mission réelle, où ces mêmes habitudes déclenchent une alerte SOC en quelques minutes.
- Oublier la traçabilité — chaque commande exécutée en mission doit pouvoir être reconstituée a posteriori (horodatage, cible, résultat). Sans cela, impossible de rédiger un rapport crédible ni de répondre si le client s'interroge sur un incident survenu pendant la fenêtre de test.
- Traiter le rapport comme une formalité — un chemin d'attaque techniquement brillant mais mal expliqué ne convainc personne côté décideur. Le chapitre consacré au reporting n'est pas accessoire : c'est souvent la partie la plus lue du livrable.
- Considérer que la théorie Kerberos est optionnelle — beaucoup de débutants sautent directement aux commandes d'exploitation sans comprendre le flux d'échange de tickets sous-jacent. Résultat : face à un comportement inattendu (échec silencieux, ticket refusé, horloge désynchronisée), ils ne savent pas diagnostiquer et abandonnent une piste pourtant valide. Le chapitre 4 de ce parcours revient volontairement en détail sur ces fondamentaux avant d'aborder les techniques d'abus.
Ces erreurs ne sont pas rédhibitoires — elles font partie de l'apprentissage normal de la discipline. L'objectif de les nommer ici n'est pas de dissuader, mais de vous permettre de les reconnaître plus tôt que la plupart des praticiens ne le font en autodidacte.
La suite du parcours part du principe que ce cadre est acquis. Le chapitre suivant entre dans le vif du sujet technique avec la cartographie du domaine : comment reconnaître sa structure, ses trusts et ses angles morts avant de toucher à quoi que ce soit.
L'essentiel à retenir
Ce chapitre d'ouverture explique pourquoi Active Directory est la cible centrale des attaquants en entreprise et ce que ce parcours de douze chapitres va couvrir. Il pose le cadre légal du test d'intrusion en France (mandat écrit, scope, fenêtre de test) et distingue deux méthodes souvent confondues, l'audit de configuration exhaustif et le Red Team furtif orienté objectif. Il liste les prérequis techniques et éthiques nécessaires pour aborder la suite du parcours dans de bonnes conditions.
Questions fréquentes
Ai-je le droit de m'entraîner sur le domaine Active Directory de mon entreprise sans en informer ma hiérarchie ?
Faut-il absolument monter un laboratoire Windows Server pour suivre ce parcours ?
Quelle est la différence entre un pentest Active Directory et un pentest réseau classique ?
Un audit de configuration Active Directory suffit-il à garantir la sécurité d'une entreprise ?
Est-il risqué d'utiliser des outils comme Mimikatz ou BloodHound sur un poste de travail professionnel ?
Comment savoir si une mission doit être cadrée comme un audit de configuration ou comme un Red Team ?
Le rapport de pentest est-il vraiment aussi important que la partie technique ?
Progression sauvegardée dans votre navigateur.
Quiz de validation
Quiz Player
Quiz de validation
Plusieurs réponses possibles — validez ensuite.
Vrai ou faux.
Quiz indisponible (données invalides).