Restaurer Active Directory après une cyberattaque : plan de récupération de forêt

Une restauration de DC n’est pas un plan de récupération de forêt

Restaurer la dernière machine virtuelle d’un contrôleur de domaine peut remettre un serveur en marche, mais ne prouve ni que la base Active Directory est saine, ni que l’attaquant a été exclu. Une récupération de forêt reconstruit une autorité d’identité digne de confiance : elle choisit un point de sauvegarde antérieur à la compromission, isole la restauration, récupère au moins un DC inscriptible par domaine, réinitialise les secrets exposés et redéploie les autres DC.

Microsoft traite cette procédure comme un modèle à adapter. Le plan doit être écrit avant l’incident, avec les propriétaires, les dépendances, les mots de passe de récupération, les sauvegardes admissibles et l’ordre des actions. Pendant une cyberattaque, l’équipe de réponse aux incidents décide aussi si une récupération à partir d’une sauvegarde est suffisamment sûre ou si certaines composantes doivent être reconstruites sur des systèmes propres.

• Microsoft — guide de récupération d’une forêt Active Directory ↗
• Guide connexe — audit de sécurité Active Directory →

Définir le scénario avant d’appuyer sur Restore

La décision appartient à une cellule réunissant réponse aux incidents, AD, sauvegarde, réseau, sécurité et responsables d’affaires. Documentez l’heure présumée de compromission, les indicateurs, la persistance découverte et la portée. Une sauvegarde plus récente réduit la perte de données mais peut réintroduire l’attaquant; une sauvegarde plus ancienne augmente les objets et changements à reconstruire.

• Microsoft — choisir la méthode et la sauvegarde de récupération ↗

Le dossier de récupération à préparer hors d’Active Directory

Microsoft recommande un plan personnalisé et un exercice au moins annuel, ainsi qu’après un changement dans les groupes Enterprise Admins ou Domain Admins. Un document non testé décrit une intention; un exercice chronométré produit un RTO crédible.

• Carte des forêts, domaines, relations d’approbation, sites, sous-réseaux, DNS, contrôleurs inscriptibles et RODC; identifier FSMO, GC, PDC Emulator et serveurs de temps.
• Un DC de récupération préféré par domaine, son OS, adresse IP, chiffrement, emplacement physique ou hyperviseur, rôles DNS/GC et dernière sauvegarde réussie.
• Copie hors ligne du plan, des installateurs, correctifs, pilotes, licences, scripts approuvés et numéros de soutien; ne pas dépendre de SharePoint ou d’un coffre qui exige l’AD en panne.
• Mots de passe DSRM et du compte Administrator intégré de chaque domaine, conservés dans un coffre indépendant avec accès d’urgence testé; comptes propres pour l’équipe de récupération.
• Inventaire des dépendances Tier 0 : Entra Connect, AD CS, ADFS, NPS, PAM, gMSA, KDS, systèmes de sauvegarde, hyperviseurs, stockage, EDR, PKI, VPN et applications qui bloquent sans AD.
• Matrice RTO/RPO et ordre de retour : forêt racine, domaines enfants, DNS/temps/GC, services d’identité, applications prioritaires, sites distants.

• Microsoft — concevoir et pratiquer le plan ↗
• Guide connexe — Windows LAPS hybride →

Sauvegardes : deux DC inscriptibles par domaine et une preuve de restauration

Sauvegardez régulièrement au moins deux DC inscriptibles par domaine afin de disposer de plusieurs points de confiance. Une sauvegarde de RODC ne restaure pas un DC inscriptible. Le candidat idéal possède une sauvegarde complète, DNS et un OS actuel, est accessible en isolement et correspond à une configuration déjà testée. Pour restaurer sur du matériel différent, Microsoft demande de planifier une récupération complète du serveur; une simple restauration d’état système sur une nouvelle installation n’est pas prise en charge.

L’état système d’un DC contient notamment AD DS, SYSVOL, le Registre et les fichiers de démarrage. Conservez aussi une sauvegarde complète nécessaire au bare metal, des copies immuables ou hors ligne, et une copie locale protégée qui accélère l’exercice. Une console indiquant Success ne suffit pas : consignez le DC, l’heure, le type de sauvegarde, l’intégrité, le chiffrement, le point de restauration et le dernier test complet.

# À exécuter dans un contexte administrateur approuvé; aucune restauration n’est lancée.
wbadmin get versions
wbadmin get status
Get-WinEvent -LogName 'Microsoft-Windows-Backup' -MaxEvents 30 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

• Microsoft — sélectionner une sauvegarde fiable ↗
• Microsoft — syntaxe wbadmin et contenu de l’état système ↗
• Guide connexe — sauvegardes Veeam immuables →

Inventaire PowerShell à conserver avant l’incident

Exécutez une collecte périodique en lecture seule depuis un poste d’administration et exportez le résultat vers un emplacement protégé hors forêt. Cette photographie ne remplace pas la sauvegarde; elle donne à l’équipe les noms, rôles et dépendances à reconstruire lorsque les consoles habituelles ne sont plus disponibles.

Le dossier peut contenir des noms, adresses et détails de sécurité : chiffrez-le, contrôlez les lecteurs, conservez des versions et testez l’accès lorsque l’AD et le réseau de production sont indisponibles. Pour une forêt multidomaine, collectez chaque domaine explicitement plutôt que de supposer que la commande locale couvre tout.

Import-Module ActiveDirectory
$Out = 'D:\AD-Recovery-Inventory'
New-Item -ItemType Directory -Path $Out -Force | Out-Null
Get-ADForest | Format-List * | Out-File "$Out\forest.txt" -Encoding utf8
Get-ADDomain | Format-List * | Out-File "$Out\domain.txt" -Encoding utf8
Get-ADDomainController -Filter * | Select-Object HostName,Domain,Site,IPv4Address,OperatingSystem,IsGlobalCatalog,IsReadOnly,OperationMasterRoles | Export-Csv "$Out\domain-controllers.csv" -NoTypeInformation -Encoding utf8
Get-ADTrust -Filter * | Select-Object Name,Source,Target,Direction,TrustType,ForestTransitive | Export-Csv "$Out\trusts.csv" -NoTypeInformation -Encoding utf8
Get-ADReplicationSite -Filter * | Select-Object Name,DistinguishedName | Export-Csv "$Out\sites.csv" -NoTypeInformation -Encoding utf8
netdom query fsmo | Out-File "$Out\fsmo.txt" -Encoding utf8
repadmin /replsummary | Out-File "$Out\replication-summary.txt" -Encoding utf8
dcdiag /e /q | Out-File "$Out\dcdiag-errors.txt" -Encoding utf8

• Microsoft — structure et fonctions à inventorier ↗

Phase 1 — Contenir et construire une zone de récupération propre

L’isolement est une barrière de sécurité, pas seulement un laboratoire. Microsoft préfère arrêter tous les DC inscriptibles avant de démarrer le premier restauré. Une carte réseau virtuelle sur un vSwitch sans uplink permet de conserver les adresses IP et réduit les erreurs DNS, mais il faut aussi vérifier les interfaces de gestion et les agents qui pourraient rappeler la production.

• Déclarer l’incident, préserver les preuves et établir une chronologie; ne pas éteindre ou modifier aveuglément les systèmes utiles à l’enquête.
• Mettre hors ligne tous les DC inscriptibles lorsque possible, surtout les détenteurs FSMO. Un ancien DC compromis ne doit jamais répliquer vers la forêt restaurée.
• Créer un réseau de récupération réellement isolé : aucun routage vers la production, Internet ou les outils compromis; DNS, temps, consoles et média d’installation maîtrisés.
• Utiliser des postes d’administration propres, de nouveaux secrets et des comptes de crise. Considérer l’hyperviseur, la sauvegarde, le stockage et les appliances réseau comme suspects jusqu’à leur validation.
• Copier seulement les sauvegardes et outils approuvés vers la zone; conserver les originaux immuables et leurs empreintes selon le processus de preuve.

• Microsoft — récupérer la forêt en isolement ↗

Phase 2 — Restaurer un seul DC inscriptible par domaine

Commencez par la forêt racine, qui porte les groupes Enterprise Admins et Schema Admins et la hiérarchie d’approbation. Pour chaque domaine, restaurez un seul DC inscriptible à partir de son point sûr. Microsoft demande pour le premier DC une restauration non autoritaire d’AD DS et une restauration autoritaire de SYSVOL réalisée avec une application consciente d’AD. Une mauvaise restauration primaire de SYSVOL sur plusieurs DC peut créer des conflits; utilisez le guide correspondant à votre produit et à votre version plutôt qu’une commande générique copiée d’un blogue.

Après chaque restauration, validez la base et abandonnez le point si l’état paraît compromis. Récupérez les domaines parents avant les enfants. Lorsque les premiers DC sont réunis sur un réseau isolé, rétablissez DNS, temps, réplication, catalogue global et approbations avant de penser aux applications.

• Microsoft — récupération initiale et ordre des domaines ↗
• Microsoft — procédures de restauration AD DS et SYSVOL ↗

Phase 3 — Reprendre le contrôle de l’identité

Ne transformez pas cette liste en script automatique. L’ordre dépend de la réplication, du nombre de domaines, de l’état des sauvegardes et de l’enquête. Une rotation prématurée peut casser des services; une rotation incomplète laisse à l’attaquant des moyens de revenir.

• Réinitialiser avant le redéploiement les comptes administratifs : Enterprise Admins, Domain Admins, Schema Admins, opérateurs, comptes de service privilégiés et autres identités exposées.
• Effectuer la procédure complète de réinitialisation de krbtgt dans chaque domaine. Les deux changements servent à invalider les anciens tickets; respecter la réplication et le délai documentés plutôt que lancer deux resets consécutifs.
• Traiter gMSA et clé KDS selon le scénario de compromission. Microsoft indique qu’une base AD compromise peut exiger une nouvelle KDS Root Key et la recréation des gMSA.
• Saisir les rôles FSMO sur les DC restaurés, nettoyer les métadonnées de tous les autres DC inscriptibles, puis traiter DNS, RID, comptes machine des DC et approbations selon le guide.
• Planifier les réinitialisations utilisateurs si leurs secrets sont exposés et révoquer les sessions, certificats, clés, applications et secrets hybrides touchés.

• Microsoft — comptes, FSMO, métadonnées, krbtgt et gMSA ↗
• Microsoft — procédures de réinitialisation et nettoyage ↗

Valider avant de reconnecter la production

Une absence de sortie de dcdiag /q est utile mais ne représente pas une autorisation de remettre la forêt en production. Faites approuver les résultats par AD, sécurité et propriétaires du plan; consignez exceptions, commandes, heures et opérateurs. Microsoft recommande une nouvelle sauvegarde de chaque DC restauré une fois la forêt stable.

repadmin /replsummary
repadmin /showrepl * /csv
repadmin /viewlist *
dcdiag /e /v
netdom query fsmo
nltest /dclist:ad.exemple.ca
Get-ADDomainController -Filter * | Format-Table HostName,Site,IsGlobalCatalog,OperationMasterRoles
Get-WinEvent -LogName 'Directory Service' -MaxEvents 100 | Where-Object LevelDisplayName -in 'Error','Critical'

• Microsoft — validation de réplication, DNS et catalogue global ↗

Phase 4 — Redéployer, ne pas rallumer les anciens DC

Les métadonnées des anciens DC ayant été supprimées, leurs anciennes sauvegardes ne doivent pas être réutilisées. Réinstallez et promouvez de nouveaux DC depuis des systèmes propres, ou utilisez les méthodes de clonage/IFM prises en charge lorsque leurs prérequis sont maîtrisés. Priorisez les sites et applications critiques, puis les succursales. Après la stabilisation, replacez FSMO et GC selon l’architecture cible, restaurez la configuration DNS normale, recréez les objets perdus depuis la sauvegarde et rétablissez les approbations sortantes qui ne reviennent pas automatiquement.

• Réintégrer par vagues avec critères de réussite et point d’arrêt; ne pas connecter tous les sites en même temps.
• Réinscrire Entra Connect, AD CS, NPS, ADFS, sauvegarde, supervision et applications avec de nouveaux secrets selon leur plan propre.
• Rechercher la persistance dans GPO, scripts, tâches planifiées, délégations, ACL, certificats, SPN, comptes de service et configuration hybride.
• Conserver l’environnement compromis pour l’enquête selon les exigences juridiques; ne pas le traiter comme une source de configuration fiable.

• Microsoft — redéployer les contrôleurs de domaine ↗
• Microsoft — nettoyage après récupération ↗
• Guide connexe — sécuriser AD CS →

Exercice annuel : le livrable qui transforme le plan en capacité

Faites l’exercice dans un réseau isolé en utilisant de vraies sauvegardes copiées, sans exposer de secrets de production aux observateurs. Chronométrez, capturez les écarts, mettez à jour le plan et produisez une nouvelle sauvegarde du laboratoire restauré. Testez aussi l’absence d’une personne clé et la perte du serveur de sauvegarde. Le résultat attendu est un rapport signé avec RTO/RPO mesurés, risques résiduels, actions, propriétaires et échéances.

• Microsoft — fréquence des exercices de récupération ↗

Checklist réutilisable

La récupération de forêt est rarement élégante. Son efficacité vient d’un ordre clair, de sauvegardes dont l’âge et la confiance sont connus, d’un environnement isolé et d’une équipe qui a déjà exécuté la procédure. Sans ces éléments, la sauvegarde devient seulement une hypothèse de récupération.

• Avant : deux sauvegardes de DC inscriptibles par domaine, copies isolées, DSRM/RID-500 testés, carte et inventaire hors forêt, responsabilités et contacts à jour.
• Décision : portée confirmée, dernier point sûr choisi avec l’enquête, pertes acceptées, réseau et comptes propres disponibles.
• Récupération : DC racine en premier, un DC par domaine, SYSVOL traité correctement, mots de passe privilégiés/krbtgt/gMSA pris en charge, FSMO et métadonnées nettoyés.
• Validation : réplication, DNS, temps, GC, trusts, journaux, accès pilote et nouvelle sauvegarde approuvés avant production.
• Retour : nouveaux DC propres, services Tier 0 réinscrits, secrets hybrides rotés, objets manquants recréés, surveillance renforcée.
• Amélioration : exercice au moins annuel, RTO/RPO mesurés, écarts assignés, copie imprimée et électronique du plan mise à jour.