GuideRésilience Active Directory
Trois niveaux de lecture · novice · intermédiaire · expert

Un guide complet pour comprendre, protéger, sauvegarder et reconstruire Active Directory après une cyberattaque.

Chaque chapitre se lit à trois niveaux : repères de base, analyse structurée, et procédures opérationnelles pour la sécurisation, la sauvegarde, la restauration et la reconstruction.

0chapitres
0termes
0runbooks
0snippets PowerShell
0sources
1Comprendre

Comprendre ce qui compose le domaine avant de parler d'attaque ou de reprise

Active Directory gère les identités, les droits et les règles de confiance d'un réseau Windows. Connaître ses composants — DC, DNS, SYSVOL, GPO, comptes à privilèges — conditionne l'évaluation de l'impact d'une attaque et le périmètre d'une reprise.

Le domaine, les DC, le DNS et les consoles d'administration

Active Directory centralise les identités et les règles. Les contrôleurs de domaine font vivre l'annuaire, le DNS oriente les machines vers les bons services, et certaines interfaces HTTP(S) exposent des points d'administration sensibles.

Novice Ce qu'il faut retenir

Le domaine fonctionne comme un registre de confiance. Si cette confiance tombe, les connexions, les droits et l'administration cessent d'être fiables.

Intermédiaire Ce qu'il faut regarder

Il faut savoir quels DC sont critiques, quels services dépendent du DNS interne, quelles consoles utilisent des identités du domaine, et quels comptes ou groupes ont des privilèges élevés.

  • Identifier les DC et leurs rôles.
  • Cartographier les dépendances AD / DNS.
  • Repérer les comptes à privilèges et les délégations sensibles.
Flux d'authentification — en boucle
Poste DNS DC Accès cherche un service indique où aller vérifie l'identité applique les droits

En production, ce travail doit produire une cartographie exploitable des objets critiques, des comptes de service, des groupes sensibles, des délégations, des approbations de domaine et des dépendances applicatives. Microsoft recommande de réduire les privilèges permanents, de protéger les actifs d'identité les plus sensibles et de surveiller les modifications sur les objets à fort impact. Microsoft · AD best practices · Microsoft Defender for Identity

Exemple : inventorier les comptes de service et leurs dépendances
  1. Recenser les comptes de service existants, en distinguant comptes utilisateur, sMSA et gMSA, comme recommandé par Microsoft dans sa documentation sur les service accounts. Service Accounts in Windows Server
  2. Repérer les SPN associés et les serveurs ou applications qui les utilisent, afin de comprendre où ces identités servent réellement. Introduction to AD service accounts
  3. Privilégier les gMSA quand un service doit tourner sur plusieurs serveurs, car Microsoft indique qu'ils simplifient la gestion de mot de passe et des SPN. gMSA overview
  4. Documenter pour chaque compte : service porté, serveurs autorisés, dépendances applicatives, privilèges requis, méthode de rotation et propriétaire technique.
  5. Contrôler que ces comptes n'ont pas de privilèges inutiles, pas d'usage interactif non justifié et pas de délégation trop large. Best practices
Au quotidien
  • Inventorier les comptes de service et leurs dépendances.
  • Revoir les memberships à privilèges et les délégations.
  • Documenter les relations de confiance et les objets critiques.
À surveiller
  • Ajouts aux groupes privilégiés.
  • Modifications d'objets sensibles.
  • Création ou extension de délégations inhabituelles.
En reprise
  • Prioriser la restauration des objets indispensables.
  • Valider les comptes de service avant réouverture des flux.
  • Comparer l'état restauré à une baseline connue.
2Services et composants

Ce qui tourne autour d'Active Directory et qu'il faut connaître

Autour d'AD DS gravitent cinq autres rôles — certificats, fédération, documents protégés, mots de passe admin locaux, stratégies de groupe — qui portent chacun une part de la sécurité du parc. Chacun a ses propres attaques, ses propres sauvegardes et ses propres procédures de reprise.

AD DS Active Directory Domain Services

Le cœur. L'annuaire qui centralise comptes, groupes, ordinateurs, OU et règles de confiance. Tout objet doté d'un compte ou d'un droit y est référencé.

  • Porte les rôles FSMO et réplique entre DC.
  • Expose Kerberos, NTLM, LDAP et le Global Catalog.
  • Sa compromission profonde (ntds.dit, krbtgt, privilèges T0) correspond dans la plupart des cas à une crise d'identité majeure affectant l'ensemble du domaine.

Référence : AD DS overview

AD CS Active Directory Certificate Services

La PKI d'entreprise. Émet et gère les certificats qui servent à l'authentification forte, au chiffrement et à la signature.

  • Autorités de certification racine et intermédiaires.
  • Modèles de certificats (utilisateurs, machines, services).
  • Cible offensive majeure (ESC1 à ESC11) : la compromission d'une CA permet la forge de certificats d'authentification arbitraires (« Golden Certificates »).

Référence : AD CS overview

AD FS Active Directory Federation Services

Pont SSO vers l'extérieur. Fédère l'identité entre l'AD interne et les applications tierces ou cloud via tokens SAML, WS-Fed, OAuth.

  • Point d'entrée pour les applications SaaS.
  • À protéger en priorité : attaques Solorigate, Golden SAML.
  • Souvent remplacé par Entra ID dans les modernisations.

Référence : AD FS overview

AD RMS Active Directory Rights Management Services

Protection persistante attachée au document. Chiffre Office, PDF et courriels avec des droits qui restent attachés au fichier même hors de l'entreprise.

  • Politiques IRM persistantes sur les fichiers.
  • S'étend à Azure Information Protection / Microsoft Purview.
  • Clés liées à l'annuaire : la reprise doit préserver l'accès aux documents déjà chiffrés.

Référence : AD RMS overview

LAPS Windows Local Administrator Password Solution

Met fin au mot de passe administrateur local partagé. Gère automatiquement le mot de passe de l'administrateur local de chaque machine.

  • Rotation périodique, mot de passe unique par machine.
  • Stockage dans AD ou Entra ID, avec ACL par délégation.
  • Réduit fortement le risque de mouvement latéral et de pass-the-hash lié à un mot de passe local identique sur plusieurs machines (ne supprime pas le PtH sur la machine compromise elle-même).
  • Windows LAPS moderne (intégré à Windows Server 2019+, Windows 10/11) gère également nativement le mot de passe DSRM de chaque DC, sauvegardé uniquement dans AD DS (pas dans Entra ID), via une GPO dédiée et un niveau fonctionnel de domaine 2016+. L'ancien Microsoft LAPS ne le faisait pas.

Référence : Windows LAPS

GPO & outils Group Policy, AppLocker, Software Restriction, gMSA

Mécanismes de configuration et de restriction qui s'appuient sur AD pour appliquer des règles à l'échelle du parc.

  • GPO pour déployer config, sécurité, scripts, logiciels.
  • AppLocker / SRP pour contrôler ce qui peut s'exécuter.
  • Cibles privilégiées en attaque : GPO malveillantes diffusées via SYSVOL.

Référence : Identity and Access docs

Entra Hybride Microsoft Entra ID + Microsoft Entra Connect (ex-Azure AD Connect) / Cloud Sync

Le pont entre l'AD on-premises et le cloud. En 2026, une majorité des organisations moyennes et grandes utilisent un modèle hybride : deux annuaires interdépendants, chacun avec sa propre surface d'attaque.

  • Entra Connect synchronise les comptes (et les hashes si Password Hash Sync est activé). Cloud Sync est une alternative agentless plus légère, avec un comportement et des contraintes différents — à documenter selon la configuration retenue.
  • Cible offensive : compte MSOL, cache de tokens, fuite de hashes synchronisés.
  • Remplace progressivement AD FS (tokens directement émis par Entra ID + Conditional Access).
  • Une compromission AD on-prem peut se propager à Entra ID selon la configuration (Entra Connect, comptes synchronisés, federation, tokens). À traiter de manière coordonnée pour les deux environnements lors de la reprise.

Référence : Entra hybrid identity

3Attaques

Comprendre comment AD devient un levier d'impact dans une attaque

Entre l'intrusion initiale et le chiffrement généralisé, AD sert presque toujours de pivot. Vol d'identifiants, escalade, abus de Kerberos, détournement des GPO ou de SYSVOL : ce sont les leviers qui transforment un poste compromis en crise d'identité.

Vol d'identifiants, mouvement latéral, abus des privilèges et propagation

Une attaque sur AD vise souvent à obtenir des comptes utiles, à monter en privilège, puis à détourner les mécanismes du domaine pour étendre l'impact ou préparer un chiffrement à grande échelle.

Novice Ce qu'il faut retenir

Le danger principal ne tient pas au poste compromis, mais à l'obtention par l'attaquant de droits qui couvrent tout le domaine.

Intermédiaire Ce qu'il faut regarder

Il faut distinguer l'entrée initiale, la reconnaissance, l'escalade, puis l'effet de levier obtenu sur AD, le DNS, les GPO, SYSVOL ou les consoles d'administration.

  • Qualifier le niveau de privilège atteint.
  • Repérer les chemins de propagation possibles.
  • Évaluer l'impact potentiel sur la reprise.
Étape 1 / 5 Compte utilisateur compromis
Attaquant Poste DC · KDC Service Actifs
Phase 1Entrée initiale
Phase 2Reconnaissance
Phase 3Escalade
Phase 4Effet de levier

Microsoft, MITRE ATT&CK et les grands éditeurs de threat intelligence (Mandiant, CrowdStrike, Unit 42) documentent explicitement ces techniques : password spray, DCSync, Kerberoasting, Golden Ticket, SID History abuse, abus d'AD CS. Cet index de menaces sert de base à la détection et à la qualification d'un incident. MITRE ATT&CK · Microsoft Threat Intelligence · Mandiant M-Trends

Exemple : transformer les techniques AD en surveillance utile
  1. Partir de MITRE ATT&CK (tactiques Credential Access, Lateral Movement, Persistence) et des rapports annuels Microsoft Digital Defense Report / Mandiant M-Trends pour dresser une liste courte des techniques plausibles dans l'environnement cible : DCSync, password spray, Kerberoasting, abus d'AD CS. ATT&CK · Credential Access · MS Digital Defense Report
  2. Associer chaque technique à ses sources d'observabilité : journaux AD, événements de sécurité, logs d'authentification, modifications de groupes, changements DNS ou alertes EDR.
  3. Définir pour chaque cas un seuil d'alerte, un propriétaire de traitement et une action de qualification rapide.
  4. Tester les scénarios sur un petit jeu de cas d'usage pour vérifier que l'équipe sait reconnaître et escalader le signal.
À surveiller
  • Password spray et comptes faibles.
  • DCSync, dump ntds.dit, tickets ou certificats frauduleux.
  • Délégations dangereuses et abus de confiance.
Usage quotidien
  • Transformer les techniques connues en cas d'usage de détection.
  • Prioriser selon l'impact sur l'identité et la reprise.
  • Relier les alertes aux propriétaires techniques.
En incident
  • Qualifier très tôt le niveau d'accès obtenu.
  • Déterminer les capacités de persistance plausibles.
  • Évaluer si les sauvegardes ou les DC restants restent dignes de confiance.
4Sauvegarde & reprise

Le bloc le plus critique : sauvegarder, restaurer et décider quand reconstruire

Une sauvegarde AD n'a de valeur que si elle est exploitable, antérieure à la compromission et restaurable sans réintroduire la persistance de l'attaquant. Entre system state, SYSVOL, restauration autoritative et forest recovery, chaque scénario a ses règles et ses pièges.

RTO · RPO · fenêtres de reprise indicatives Ordres de grandeur issus de retours d'expérience terrain (ransomware, forest recovery), inspirés de la démarche Microsoft Forest Recovery mais non publiés tels quels par Microsoft. À adapter impérativement à votre contexte et à mesurer lors d'exercices DR.
Panne simple d'un DC

Réplication saine, backup récent disponible.

RTO1 – 4 h
RPO~ 15 min
Perte d'un site complet

Bascule vers un DC d'un autre site.

RTO4 – 24 h
RPO~ 1 h
Corruption AD ciblée

Authoritative restore d'objets ou d'une OU.

RTO12 – 48 h
RPOdernier system state
Forest recovery complet

Compromission profonde de tous les DC.

RTO24 – 96 h
RPOdernier backup validé
Reconstruction totale

Pas de backup exploitable, repart de zéro.

RTO1 – 4 semaines
RPO∞
Vigilance Valeurs indicatives, à adapter à votre contexte. Pour un SI complexe, multi-sites, fortement réglementé ou sans préparation préalable (lab, plan testé), un forest recovery ou une reconstruction peuvent largement dépasser ces fourchettes — plusieurs jours à plusieurs semaines pour un forest recovery manuel sur une forêt complexe. Des outils dédiés (Quest On Demand Recovery, Semperis ADFR, Cayosoft Guardian) peuvent réduire significativement ces durées. Le forensic seul peut s'étaler sur plusieurs jours avant qu'une reconstruction ne devienne possible.

Ce qu'il faut sauvegarder et ce qu'il faut vérifier avant de restaurer

Une sauvegarde marquée OK n'équivaut pas à une reprise réussie. Il faut savoir ce qui est sauvegardé, à quelle date réelle, dans quel état de confiance et avec quelle capacité de restauration testée.

Novice Ce qu'il faut retenir

Sauvegarder le serveur ne suffit pas. La reprise exige un annuaire sain, ses paramètres et les composants nécessaires au domaine.

  • Le DC doit pouvoir être remis en service.
  • Les données critiques doivent être retrouvables.
  • Il faut un point antérieur à la compromission.

Intermédiaire Ce qu'il faut regarder

Le minimum consiste à savoir si l'on dispose d'un system state exploitable, si SYSVOL est cohérent, si d'autres DC sont sains, et si les sauvegardes n'ont pas été sabotées ou contaminées.

  • Identifier les sauvegardes utilisables par DC.
  • Connaître l'âge réel des points disponibles.
  • Vérifier les dépendances : DNS, GPO, partages, comptes de service, secrets.

Microsoft distingue clairement la sauvegarde et la restauration d'un DC selon le contexte : présence d'autres DC sains, nature de la panne, ou compromission plus profonde nécessitant un forest recovery. Le contenu à maîtriser inclut au minimum le system state, l'AD DS database, le registre, SYSVOL et les dépendances utiles à la remise en service. Microsoft note qu'un nouveau serveur promu DC peut, selon le contexte, remplacer la restauration d'un ancien DC. Backup & restore AD server · AD restore with Azure Backup · Forest recovery guide

Exemple : préparer une sauvegarde exploitable d'un DC
  1. Définir quels DC sont indispensables à la reprise et documenter leur rôle, leurs dépendances DNS, SYSVOL et FSMO.
  2. Mettre en place au minimum des sauvegardes du system state sur les DC critiques, et compléter par des sauvegardes serveur complètes quand l'architecture ou les exigences de reprise le justifient. Backup & restore AD server
  3. Conserver une vision claire des points de restauration disponibles, de leur âge et de leur localisation, avec une attention particulière au risque de sabotage des dépôts.
  4. Tester régulièrement la restauration dans un environnement isolé pour vérifier AD, DNS, SYSVOL, GPO et comptes critiques. Forest recovery guide
  5. Documenter l'ordre de reprise, les rôles de chacun et les critères de validation avant remise en production.
Ce qu'il faut sauvegarder
  • System state de chaque DC critique.
  • Sauvegarde serveur complète lorsque justifiée par l'architecture.
  • SYSVOL, paramètres DNS, documentation FSMO, comptes de service, dépendances d'authentification et procédures d'accès d'urgence.
  • Preuves de restauration testée, pas seulement preuves d'exécution de backup.
Ce qu'il faut vérifier
  • Date probable de compromission et non date de découverte.
  • Âge des sauvegardes et compatibilité avec les contraintes AD.
  • Intégrité des dépôts de sauvegarde et risque de sabotage.
  • État des autres DC : sains, suspects ou compromis.
Questions de décision
  • Restauration non-authoritative possible ou non ?
  • Restauration authoritative nécessaire pour certains objets ?
  • Restauration d'un ancien DC ou promotion d'un nouveau serveur ?
  • Perte de confiance telle qu'un forest recovery ou une reconstruction devient préférable ?

Restauration contrôlée, forest recovery et reconstruction

La bonne option dépend du niveau de confiance dans les DC, dans les privilèges, dans les objets critiques et dans les sauvegardes. La restauration la plus rapide n'est pas toujours la plus sûre.

Novice Ce qu'il faut retenir

Si l'environnement reste fiable, la restauration est possible. Si la confiance est trop entamée, il faut reconstruire.

Intermédiaire Ce qu'il faut regarder

Il faut décider si l'on peut réutiliser l'existant, si l'on doit restaurer certains éléments avec autorité, ou si une récupération de forêt complète est plus défendable.

  • Qualifier la perte de confiance.
  • Comparer vitesse de reprise et risque résiduel.
  • Préparer la validation post-restauration avant réouverture.
1
Choisir l'option

Restauration ciblée, restauration contrôlée, forest recovery, ou reconstruction.

2
Valider hors production

Tester l'état restauré, les GPO, le DNS, SYSVOL, les comptes et les privilèges avant un retour large.

3
Réintégrer progressivement

Réouvrir les flux et reconnecter les actifs assainis dans un ordre maîtrisé.

Le guide de forest recovery de Microsoft détaille les prérequis, les étapes initiales et les procédures de restauration d'une forêt AD compromise. Cette section soutient l'arbitrage entre restauration non-authoritative, authoritative restore d'objets, promotion de nouveaux DC et récupération de forêt lorsque la compromission est trop large ou trop mal bornée. Forest recovery guide · Forest recovery prerequisites · Forest recovery procedures

Exemple : décider entre restauration et reconstruction
  1. Qualifier la fenêtre probable de compromission et comparer cette fenêtre aux points de sauvegarde réellement disponibles.
  2. Vérifier si les DC restants, les groupes privilégiés, les GPO, le DNS et SYSVOL inspirent encore suffisamment confiance pour appuyer une restauration contrôlée.
  3. Si la confiance est trop faible ou si la compromission est difficile à borner, préparer un scénario de forest recovery ou de reconstruction plus large, conformément à la démarche Microsoft. Forest recovery procedures
  4. Tester hors production l'état restauré et définir des critères explicites de réouverture des flux et de reconnexion des actifs.
Critères de restauration
  • Confiance suffisante dans la structure du domaine et ses dépendances.
  • Capacité à identifier un point sain réellement antérieur à la compromission.
  • Capacité à valider GPO, DNS, SYSVOL, groupes et comptes avant retour en production.
Critères de reconstruction
  • Perte de confiance profonde dans les DC, privilèges ou mécanismes de persistance.
  • Fenêtre de compromission difficile à borner.
  • Opportunité de repartir avec une administration, une segmentation et une gouvernance plus saines.
Validation post-reprise
  • Réplication et santé AD.
  • DNS cohérent et résolution fiable.
  • SYSVOL, GPO, comptes créés, groupes privilégiés, certificats et accès admin revus.
  • Journalisation et surveillance remises en état avant réouverture large.

Procédure pas-à-pas de récupération de forêt (méthode Microsoft)

Synthèse du guide officiel « AD Forest Recovery » de Microsoft. À personnaliser et à éprouver en laboratoire chaque année avant d'en avoir besoin en crise.

Novice Ce qu'il faut retenir

Reconstruire un domaine ne s'improvise pas. Il faut un plan écrit, des sauvegardes testées, les clés BitLocker sous la main. Un appui Microsoft (Premier/Unified, ADRES) est un accélérateur précieux pour les environnements complexes, mais la procédure officielle Forest Recovery est conçue pour être exécutable par une équipe interne formée et entraînée.

Intermédiaire Ce qu'il faut regarder

Les 8 étapes du guide Microsoft : prérequis → plan personnalisé → identification → choix de méthode → reprise initiale → procédures → redéploiement des DC restants → cleanup.

  • Un seul DC par domaine est restauré d'abord, les autres sont reformatés et promus après.
  • Le mot de passe DSRM est le sésame pour le mode de restauration isolé.
  • Une zone DNS AD-intégrée doit exister pour chaque domaine.
Étape 1 / 8 Prérequis et plan documenté
ÉQUIPE IT FORÊT AD ACTIFS MÉTIER IT DC primaire DC2 DC3
Phase 1Préparation
Phase 2Reprise initiale
Phase 3Nettoyage
Phase 4Retour en service

Microsoft propose le service ADRES pour accompagner la rédaction et la mise à l'épreuve du plan de reprise. En contexte réel, une récupération réussie dépend autant de la discipline opérationnelle (qui fait quoi, dans quel ordre, avec quels accès) que de l'outillage technique. Procédures forest recovery · Prérequis forest recovery · Étapes de restauration

Exemple : trousse minimale du coordinateur forest recovery
  1. Copie papier et copie hors-ligne du plan (PDF chiffré, clé USB scellée, coffre physique).
  2. Liste des DC critiques par domaine, rôles FSMO portés, dépendances DNS et adresses IP statiques.
  3. Accès aux clés BitLocker de chaque DC (via AD, coffre MBAM ou équivalent).
  4. Mot de passe DSRM de chaque DC, idéalement géré nativement par Windows LAPS moderne (DFL 2016+) ou centralisé dans un coffre dédié avec rotation automatique.
  5. Jeu de sauvegardes system state hors-ligne et immuables, testées en lab dans les 12 derniers mois.
  6. Numéro de contrat Microsoft Premier / Unified, contact ADRES pré-enregistré.
  7. Outils maîtrisés : ntdsutil, repadmin, dcdiag, Install-ADDSDomainController, Uninstall-ADDSDomainController.
Outils de terrain
  • ntdsutil : métadonnées, FSMO seize, DSRM, autoritative restore.
  • repadmin : état et forçage de la réplication AD.
  • dcdiag : santé d'un DC.
  • Windows Admin Center pour le pilotage centralisé.
Points d'attention
  • Rotation double du krbtgt (2 fois, avec délai de réplication entre les deux).
  • Invalider anciens tickets Kerberos et certificats compromis.
  • Vérifier que les sauvegardes n'ont pas été chiffrées ou altérées par l'attaquant.
  • Sauvegardes immuables (object lock) : objectif cible recommandé pour une posture résiliente.
À ne pas oublier
  • Rouvrir les flux progressivement, pas tout d'un coup.
  • Rétablir la journalisation et la surveillance avant la bascule métier.
  • Mettre à jour le plan après chaque exercice ou incident réel.
  • Tester la procédure annuellement, pas seulement la backup.

Séquence de réponse à incident · ordre des actions

Sous pression, cette séquence sert de garde-fou : l'ordre compte, pas le timing absolu — le forensic peut s'étaler sur plusieurs jours avant qu'une reconstruction soit possible.

Immédiat
Détection · isolation
  • Déconnecter les DC suspects du réseau (pas d'arrêt brutal : préserver les preuves).
  • Couper la réplication sortante vers les autres sites.
  • Bloquer les comptes admin compromis connus.
Urgence
Mobilisation technique
  • Contacter Microsoft Support et ADRES si contrat.
  • Activer l'équipe d'astreinte et les ressources techniques internes.
  • Désigner un coordinateur technique unique côté infra.
Analyse
Qualification
  • Cadrer le périmètre technique : postes, serveurs, DC touchés.
  • Évaluer le niveau de privilège atteint par l'attaquant.
  • Vérifier l'état des sauvegardes (intégrité, date, accessibilité).
Décision
Décision de reprise
  • Choisir : restauration ciblée, autoritative restore, forest recovery ou reconstruction.
  • Valider la fenêtre de sauvegarde exploitable.
  • Préparer l'environnement de restauration isolé.
Reconstruction
Début de reconstruction
  • Restaurer un premier DC par domaine en mode DSRM.
  • Réinitialiser krbtgt, comptes admin, comptes de service.
  • Valider DNS et SYSVOL avant propagation.
Restauration
Restauration progressive
  • Réouvrir les services applicatifs par vagues.
  • Reformater puis promouvoir les autres DC.
  • Rétablir la supervision et la journalisation avant le retour complet.
Validation
Validation technique
  • Audit complet : réplication, GPO, comptes, certificats, FSMO.
  • Documenter les actions techniques menées et les configurations modifiées.
  • Mettre à jour le plan technique de reprise avec les apprentissages.
5Cas documentés

Cas réels où l'identité, les accès ou l'authentification ont joué un rôle central

Documentés par Microsoft et Netwrix, ces incidents montrent comment un DC exposé, un compte dormant ou un SYSVOL détourné dégénère en crise d'identité.

Incidents où l'identité, les accès ou l'authentification ont joué un rôle central · 2017 → 2026 Clique sur un point pour le résumé
6Sécuriser

Mesures pour réduire l'exposition et préparer la reprise

Trois leviers prioritaires pour réduire la surface d'attaque et gagner en résilience : durcir les contrôleurs de domaine, cloisonner les privilèges, préparer la reprise avant d'en avoir besoin.

Modèle en tiers · cloisonnement des privilèges Clique sur un niveau pour voir ce qu'il contient. Microsoft a depuis fait évoluer ce modèle vers l'Enterprise Access Model (plans de contrôle, zones d'accès), mais le Tier Model reste la base pédagogique recommandée par l'ANSSI.
TIER 0 TIER 1 TIER 2
Mesure clé

Durcir les contrôleurs de domaine

Un DC doit rester sobre et fortement protégé.

  • Éviter les rôles annexes et usages inutiles.
  • Réduire les accès administratifs banalisés.
  • Traiter le DC comme un actif à très forte valeur.

Référence : Guide Microsoft sur les DC

Mesure clé

Séparer les privilèges et les postes d'administration

Les identités d'administration ne servent jamais aux usages quotidiens.

  • Comptes distincts selon les rôles.
  • Hôtes d'administration dédiés.
  • Moindre privilège et revue régulière des droits.

Référence : Bonnes pratiques Microsoft

Mesure clé

Préparer la récupération avant la crise

La récupération AD se prépare, se documente et se teste avant la crise.

  • Définir les rôles et responsabilités.
  • Documenter l'ordre de reprise.
  • Tester les scénarios de restauration et de reconstruction.

Référence : Guide de récupération de forêt

7Runbooks de crise

Cinq scénarios concrets, chacun avec sa procédure minute

Un runbook est une suite d'actions numérotées exécutables sous pression. Cinq scénarios récurrents en intervention.

R1

Un contrôleur de domaine est chiffré ou inaccessible

Ce qui déclenche
  • DC injoignable, services Windows arrêtés ou en boucle de redémarrage.
  • Fichiers système chiffrés ou renommés avec extensions inhabituelles.
  • Note de rançon présente sur le serveur.
Procédure
  1. Ne pas redémarrer. Un redémarrage peut déclencher la suite du chiffrement ou effacer des traces mémoire exploitables en forensique. Décision prise au niveau cellule technique de crise (jamais individuellement).
  2. Isoler le DC du réseau de manière contrôlée : pour une VM, snapshot avec mémoire (préserve l'état RAM pour forensic) avant de couper le vSwitch ; pour un physique, débrancher le câble. Horodater chaque action.
  3. Vérifier l'état des autres DC : encore sains, suspects, déjà touchés ?
  4. Activer la cellule de crise, ouvrir un ticket Microsoft Premier ou ADRES.
  5. Capturer mémoire (dump RAM) et disques du DC mort avant tout nettoyage (forensique). Aucun nettoyage ni redémarrage avant capture validée.
  6. Évaluer si les DC restants peuvent continuer à servir (rôles FSMO accessibles, réplication saine).
  7. Si rôles FSMO perdus, les seize vers un DC sain via ntdsutil roles.
  8. Nettoyer les métadonnées du DC chiffré dans AD (ntdsutil metadata cleanup).
  9. Ne jamais réintégrer le DC dans son état actuel : reformater complètement, repatcher, repromouvoir une fois l'incident cadré. Le hardware ou la VM peut être réutilisé après formatage complet.
Vigilance Si tous les DC sont touchés ou qu'il n'y en avait qu'un, bascule immédiate vers le runbook R4 ou vers un forest recovery complet.
R2

Un administrateur AD part avec ses droits actifs

Ce qui déclenche
  • Départ d'un admin en conflit, offboarding bâclé ou licenciement contentieux.
  • Suspicion de collecte de données ou de sabotage imminent.
  • Accès distants ouverts (VPN, RDS, comptes de service partagés).
Procédure
  1. Désactiver immédiatement le compte nominatif AD (pas supprimer : preuves).
  2. Retirer de tous les groupes privilégiés (Domain Admins, Enterprise Admins, Schema Admins, Backup Operators…).
  3. Couper les accès fédérés : Entra ID, AD FS, VPN, Privileged Access Management.
  4. Auditer les comptes de service et comptes « fantômes » qu'il aurait pu créer ou modifier (événements 4720, 4728, 4732, 5136).
  5. Réinitialiser les mots de passe des comptes qu'il partageait (admin local legacy, comptes de service non-gMSA).
  6. Rotation du krbtgt (deux fois, espacées d'au moins 10 h pour réplication complète) s'il avait des droits T0. À tester en pré-prod d'abord : risque sur trusts mal configurés et applis Kerberos atypiques.
  7. Vérifier les portes dérobées potentielles : délégations Kerberos, ACL sur OU sensibles, GPO modifiées, AD CS templates exposés.
  8. Archiver son profil et ses mailboxes (obligation légale, traçabilité).
Vigilance Si la personne avait accès au stockage de backup, traiter aussi R4 en parallèle. Les Shadow Admins résident dans les ACL plutôt que dans les groupes.
R3

Golden Ticket ou persistance Kerberos suspectés

Ce qui déclenche
  • Tickets Kerberos à durée anormale (plusieurs jours), authentifications sans compte associé.
  • Volumes inhabituels d'événements 4768 / 4769, TGT sans 4624 correspondant.
  • Alerte EDR « mimikatz » ou manipulation de LSASS.
Procédure
  1. Préserver les logs DC et postes (copie hors-ligne avant rotation).
  2. Identifier le ou les comptes dont les hashes ont pu fuir (admins utilisés sur postes compromis).
  3. Forcer l'invalidation des tickets Kerberos existants : rotation du krbtgt deux fois, espacées d'au moins 10 h (réplication complète).
  4. Réinitialiser les mots de passe des comptes T0 et comptes de service non-gMSA.
  5. Rotation des certificats AD CS compromis et révocation des cartes à puce suspectes.
  6. Chercher les backdoors Kerberos classiques : SID History abusé, DCSync non autorisé, délégations contraignantes ou libres inhabituelles.
  7. Scanner l'AD avec PingCastle ou Purple Knight pour détecter les vestiges de persistance.
  8. Toujours faire deux rotations krbtgt : la première invalide les tickets, la seconde rend l'ancien hash inexploitable. À planifier et tester en pré-prod. Délai entre les deux rotations : au minimum la valeur de Maximum lifetime for user ticket définie par GPO Kerberos (10 h par défaut) plus le temps de réplication complète de la forêt. La double rotation invalide tous les tickets Kerberos émis (y compris les tickets inter-domaines en cours) : les sessions actives sont coupées et doivent se ré-authentifier. Les mots de passe de trust eux-mêmes sont indépendants du krbtgt, mais vérifier après rotation que les authentifications cross-domain fonctionnent et, si besoin, réinitialiser les mots de passe de trust selon la procédure Microsoft. Risque additionnel sur les applis Kerberos atypiques (cache de tickets statique, comptes de service mal gérés).
Vigilance Un Golden Ticket bien forgé est très discret côté DC, mais reste détectable par corrélation d'anomalies : incohérences PAC, durées de tickets atypiques, comptes inexistants, accès services inhabituels, signaux EDR sur LSASS, journaux applicatifs. Si doute persistant, considérer l'annuaire comme compromis et envisager R4/R5.
R4

Les sauvegardes sont compromises ou indisponibles

Ce qui déclenche
  • Jobs de backup échoués depuis plusieurs jours (non détecté).
  • Dépôt de sauvegarde chiffré ou supprimé par l'attaquant (attaque classique du ransomware).
  • Aucun backup testé en restauration dans les 12 derniers mois.
Procédure
  1. Recenser tous les dépôts : on-prem, cloud, offline, bandes physiques, snapshots immuables.
  2. Vérifier l'intégrité physique et logique du dernier backup exploitable (hash, test de montage hors-ligne).
  3. Remonter aussi loin que nécessaire pour trouver un backup antérieur à la compromission (pas la date de découverte).
  4. Si aucun backup sain : bascule vers reconstruction complète, contacter Microsoft ADRES.
  5. Reconstituer manuellement les éléments critiques (OU, groupes privilégiés, comptes de service, GPO, relations de confiance) — opération à haut risque qui exige une baseline documentée, des exports GPO/OU récents, l'inventaire des dépendances applicatives, et une validation sécurité + métier après chaque vague. Sans ces prérequis, fortes chances d'écarts et de ruptures applicatives.
  6. Valider avec les équipes applicatives la liste des comptes de service à recréer.
  7. Imposer désormais des sauvegardes immuables (object lock, bandes, cloud avec MFA delete).
  8. Post-incident : tester la restauration tous les 6 mois, pas seulement l'exécution du backup.
Vigilance La règle 3-2-1-1-0 (3 copies, 2 supports, 1 hors-site, 1 immuable, 0 erreur testée) constitue l'objectif cible recommandé pour une posture résiliente. À adapter selon le budget, les contraintes réglementaires et la criticité réelle du parc.
R5

AD FS ou Entra Connect compromis · tokens frauduleux

Ce qui déclenche
  • Connexions Entra ID depuis IP inconnues, sans trace locale correspondante (Golden SAML).
  • Certificat de signature AD FS exporté ou dupliqué (sortie suspecte).
  • Compte MSOL utilisé ailleurs qu'au serveur de sync.
Procédure
  1. Isoler le serveur AD FS / Entra Connect du réseau.
  2. Faire rouler toutes les clés de signature AD FS (TokenSigning, TokenDecrypting) deux fois pour invalider les tokens précédents.
  3. Révoquer tous les refresh tokens Entra ID (Revoke-MgUserSignInSession) et forcer la réauth.
  4. Réinitialiser le compte MSOL et vérifier qu'il ne traîne nulle part ailleurs.
  5. Examiner les logs Entra ID sur 90 jours : quels comptes se sont connectés via des tokens suspects ?
  6. Réinitialiser les mots de passe de tous les comptes synchronisés à privilège.
  7. Si compromission profonde de AD FS : envisager la migration vers Entra ID + Conditional Access plutôt que reconstruire AD FS.
  8. Activer Microsoft Entra ID Protection (ex-Azure AD Identity Protection) et Conditional Access pour durcir le périmètre.
Vigilance Un Golden SAML peut survivre à toutes les réinitialisations tant que le certificat de signature AD FS n'est pas révoqué et remplacé. Appliquer la procédure Microsoft de rotation d'urgence des certificats Token-Signing et Token-Decrypting (rotation rapide successive pour invalider les anciens jetons), avec validation côté Entra ID et applications fédérées. L'analogie avec krbtgt aide à mémoriser le principe (deux rotations rapprochées) mais les procédures techniques diffèrent.
8Boîte à outils

Commandes, indicateurs et référentiels prêts à servir

Outillage du consultant : snippets PowerShell testés, événements Windows à tracer en SOC, mapping aux référentiels d'audit.

PowerShell cookbook · santé, réplication, comptes

Snippets à lancer depuis un poste d'administration PAW avec un compte T0. Tous en lecture seule sauf la rotation krbtgt, à n'exécuter qu'en connaissance de cause.

Santé d'un DC · rapport complet
dcdiag /c /v /f:dcdiag-report.txt
# Lance tous les tests sur le DC local, sortie verbose, rapport texte.
État de la réplication entre DC
repadmin /showrepl * /csv | Out-File repl.csv
repadmin /syncall /AdeP
# Liste la réplication (inbound/outbound) et force la sync dans toute la forêt.
Groupes privilégiés · inventaire récursif
'Domain Admins','Enterprise Admins','Schema Admins','Administrators' |
  ForEach-Object {
    Get-ADGroupMember -Identity $_ -Recursive |
      Select-Object @{n='Group';e={$_}}, Name, SamAccountName, ObjectClass
  } | Export-Csv privileged-members.csv -NoTypeInformation
Comptes dormants à plus de 90 jours
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
  Where-Object Enabled -eq $true |
  Select-Object Name, SamAccountName, LastLogonDate |
  Export-Csv dormant-accounts.csv -NoTypeInformation
Âge du compte krbtgt · vérifier avant rotation
Get-ADUser krbtgt -Properties PasswordLastSet, msDS-KeyVersionNumber |
  Select-Object SamAccountName, PasswordLastSet, msDS-KeyVersionNumber
# Définir une politique de rotation périodique du krbtgt (à calibrer selon
# le contexte). Aucune fréquence standard universelle n'est imposée par
# Microsoft. Seule la rotation post-compromission est impérative,
# indépendamment de la durée écoulée.
Rotation du krbtgt · à exécuter deux fois, espacées
# Script Microsoft officiel New-KrbtgtKeys.ps1 (téléchargé depuis GitHub).
# Vérifier d'abord la valeur Max ticket lifetime dans la GPO Kerberos :
#   Default Domain Policy > Account Policies > Kerberos Policy
# Première exécution :
.\New-KrbtgtKeys.ps1 -Mode Single -Domain "corp.example.local"
# Attendre : Max lifetime ticket utilisateur (10 h par défaut) PLUS temps
# de réplication complète de la forêt, puis relancer la deuxième rotation.
# Rotation double = ancien hash inutilisable même s'il a fuité.
# IMPORTANT : la double rotation invalide TOUS les tickets émis (y compris
# inter-domaines). Les sessions actives sont coupées le temps de la ré-auth.
# Vérifier ensuite que les authentifications cross-domain fonctionnent ;
# si besoin, réinitialiser les mots de passe de trust (procédure Microsoft).
Export des SPN · cibles Kerberoasting
Get-ADUser -Filter {ServicePrincipalName -like '*'} -Properties ServicePrincipalName |
  Select-Object Name, SamAccountName, ServicePrincipalName |
  Export-Csv spn-users.csv -NoTypeInformation
# Les comptes user porteurs de SPN sont les premières cibles Kerberoasting.
Audit GPO · listing et dépôt SYSVOL
Get-GPO -All | Select-Object DisplayName, Id, CreationTime, ModificationTime, GpoStatus |
  Sort-Object ModificationTime -Descending |
  Export-Csv gpo-audit.csv -NoTypeInformation
# Croiser avec le contenu de \\$domain\SYSVOL\$domain\Policies pour les orphelins.
Santé forêt · réplication et FSMO
Get-ADReplicationFailure -Target (Get-ADForest).Domains
netdom query fsmo
Get-ADForest | Format-List Name, GlobalCatalogs, SchemaMaster, DomainNamingMaster
Audit AD automatisé · PingCastle / Purple Knight
# PingCastle (gratuit pour audit healthcheck) :
.\PingCastle.exe --healthcheck --server corp.example.local
# Purple Knight (Semperis, gratuit aussi) :
.\PurpleKnight.exe
# Deux références pour établir/valider la baseline de posture AD.
# ATTENTION : à éviter pendant un incident actif (génère du bruit LDAP
# qui peut masquer les signaux faibles de l'attaquant). Plutôt utilisés
# en posture, en exercice DR, ou en validation post-restauration.

Indicateurs de compromission · événements Windows à tracer

Event IDs à corréler côté DC et postes, à intégrer dans un SIEM ou un EDR pour détection en temps réel.

EventNomSignification en criseCriticité
4624Logon successConnexion réussie. Corréler au Logon Type (3 réseau, 10 RDP) pour détecter les mouvements latéraux.Moyen
4625Logon failureÉchecs en rafale sur le même compte = password spray probable.Moyen
4672Special privileges assignedÉlévation à privilèges sensibles. Tracer tout compte inhabituel.Critique
4720Account createdCréation d'un compte. Surveiller les créations hors des plages attendues.Moyen
4728/4732Added to privileged groupAjout à Domain/Enterprise Admins, Backup Operators. Signal d'alerte immédiat.Critique
4768TGT requestedPic anormal ou TGT émis pour comptes inactifs = Kerberos abuse.Critique
4769Service ticket requestedVolume massif sur un même compte de service = Kerberoasting.Critique
4776NTLM authenticationValidation d'identifiants NTLM par le DC — événement normal lors de toute auth NTLM. À surveiller en cas de volume inhabituel, source atypique, compte sensible ou échec massif (password spray).Moyen
5136/5137AD object modified / createdModification d'OU, GPO, ACL. Corréler aux fenêtres d'admin planifiées.Critique
4932/4933AD replicationÉvénement standard de réplication AD entre DC. À surveiller : source atypique (hôte non-DC) ou compte non-DC = signe possible de DCSync. Trafic légitime = volume normal entre DC.Moyen
4697Service installedInstallation de service sur DC = persistance classique.Critique
4688Process creationLancement de mimikatz, psexec, rubeus… avec command-line tracé.Critique
4649Replay attackRejeu de ticket détecté. Quasi toujours un indicateur d'intrusion en cours.Critique
1102Audit log clearedEffacement des journaux de sécurité. Classique post-compromission.Critique

Cartographie conformité · ce que l'audit va citer

Mapping des recommandations avec les référentiels couramment audités.

NIST CSF 2.0
  • IdentifyInventaire AD, comptes privilégiés, objets sensibles.
  • ProtectTier Model, LAPS, durcissement DC, templates AD CS sains.
  • DetectÉvénements 4672, 4768, 4769, 5136, corrélation SIEM.
  • RespondRunbooks R1 à R5, cellule de crise, chronologie 24 h.
  • RecoverForest recovery, procédure Microsoft pas-à-pas.
CIS Controls v8
  • CIS 4Configuration sécurisée des contrôleurs de domaine.
  • CIS 5Gestion des comptes et des privilèges (LAPS, JEA).
  • CIS 6Contrôle d'accès, RBAC, Conditional Access.
  • CIS 11Récupération : sauvegardes immuables, tests.
  • CIS 17Incident response : runbooks, exercices.
ISO 27001:2022 · Annexe A
  • A.5.23Gestion des identités.
  • A.8.2Droits d'accès privilégiés.
  • A.8.13Information backup.
  • A.5.30ICT readiness for business continuity.
  • A.8.16Monitoring activities.
ANSSI · guide PA-022
  • Modèle en tiers systématique (T0/T1/T2).
  • PAWs fortement recommandés pour administrateurs T0 (objectif cible ANSSI).
  • Comptes admin nominatifs, jamais partagés.
  • Audit régulier via PingCastle ou équivalent.
  • Plan de reprise AD documenté et testé annuellement.
CCCS · Canada
  • ITSG-33 · gestion des accès privilégiés.
  • Top 10 IT security actions (2024).
  • Joint guidance AD compromises (2024).
  • Recovery planning documenté et exercé.
  • Sauvegarde hors-ligne ou immuable fortement recommandée (objectif cible CCCS).
PCI-DSS 4.0
  • Req 7Moindre privilège, séparation des rôles.
  • Req 8MFA sur tous les accès admin.
  • Req 10Journalisation et audit des DC.
  • Req 12.10Plan de réponse à incident testé.
9Checklist d'audit

50 points pour mesurer la posture AD d'une organisation

50 points de contrôle regroupés en 8 thèmes. Cocher au fur et à mesure : la progression est sauvegardée localement dans le navigateur. Le résultat s'exporte en Markdown pour le rapport.

0 / 50 items couverts
Inventaire et gouvernance0 / 5
Comptes et privilèges0 / 8
Durcissement des DC0 / 6
Sauvegarde et reprise0 / 7
Détection et monitoring0 / 6
Kerberos et authentification0 / 6
AD CS et certificats0 / 5
Entra hybride et cloud0 / 7