Checklist de durcissement AD : plan 30/60/90 jours

Les recommandations de durcissement d'Active Directory se présentent souvent sous la forme d'une liste de deux cents paramètres sans ordre. Ce n'est pas ainsi que les domaines sont réellement compromis, ni ainsi qu'ils doivent être corrigés. D'un incident à l'autre, on retrouve le même petit ensemble de chemins : un mot de passe d'administrateur local partagé, un compte de service exposé au roasting, un relais NTLM vers AD CS, une ACL obsolète qui accorde DCSync, un Domain Admin qui a ouvert une session sur un poste de travail. Fermez ceux-là en premier et vous supprimez la plupart des voies réellement empruntées par les attaquants ; tout le reste relève de l'affinage.

Cette checklist ordonne le travail selon le risque que chaque élément supprime par heure d'effort. Les 30 premiers jours ciblent les contrôles qui bloquent les prises de contrôle complètes du domaine les plus courantes, avec peu de risque de casser quoi que ce soit. Les jours 31 à 60 ferment les chemins de relais et de délégation, qui demandent davantage de tests. Les jours 61 à 90 mettent en place les contrôles structurels — tiering, hygiène des approbations, restauration — qui maintiennent le domaine défendable dans la durée. Chaque élément renvoie à un guide pas à pas.

Avant de commencer

On ne peut pas prioriser ce qu'on n'a pas mesuré, ni protéger le Tier 0 sans savoir ce qu'il contient. Consacrez-y les premiers jours, avant de toucher à la moindre GPO.

• Réaliser une évaluation de référence — un rapport chiffré fournit un indicateur avant/après et une liste de constats classés. Voir Réaliser une évaluation PingCastle.
• Cartographier les chemins d'attaque vers les groupes privilégiés — les constats comptent surtout lorsqu'ils s'enchaînent jusqu'aux Domain Admins. Voir La gestion des chemins d'attaque avec BloodHound.
• Inventorier chaque actif Tier 0 — les contrôleurs de domaine en sont la partie évidente ; AD CS, Entra Connect, les serveurs de sauvegarde, les hyperviseurs et les éditeurs de GPO sont la partie qu'on oublie. Voir Définir le Tier 0.
• Confirmer que vous disposez d'une sauvegarde AD hors ligne et restaurable — avant tout changement, assurez-vous de pouvoir annuler le pire scénario. Voir Évaluation, sauvegarde et restauration de forêt AD.
• Activer la stratégie d'audit nécessaire pour mesurer l'impact — plusieurs étapes ultérieures reposent sur des événements désactivés par défaut. Voir Audit et détection AD.

Notez le score PingCastle, le nombre de comptes dans les groupes privilégiés et le nombre de chemins d'attaque vers Domain Admins. Ce sont ces trois chiffres que vous présenterez aux jours 30, 60 et 90.

Jours 0 à 30 : arrêter l'hémorragie

L'objectif du premier mois est de supprimer les chemins bon marché et fiables vers la compromission du domaine. Ces éléments présentent peu de risques pour l'exploitation, un fort impact contre les attaquants, et sont pour la plupart réversibles.

Comptes et groupes privilégiés

• Réduire les groupes privilégiés à des membres nominatifs et justifiés — chaque Domain Admin supplémentaire est un identifiant de plus qui vaut la peine d'être volé. Voir Tier 0 et accès à privilèges.
• Retirer les droits de réplication aux principaux qui ne sont pas des DC — quiconque détient DS-Replication-Get-Changes-All peut extraire tous les hachages. Voir Trouver et supprimer les droits DCSync.
• Nettoyer les adminCount orphelins et revoir AdminSDHolder — des protections obsolètes masquent d'anciens administrateurs et des ACL étranges. Voir AdminSDHolder, SDProp et adminCount orphelins.
• Corriger les ACL les plus dangereuses sur le domaine, AdminSDHolder et les objets Tier 0 — GenericAll et WriteDacl accordés à des groupes larges sont des chemins d'élévation directs. Voir Auditer les ACL Active Directory.

Des identifiants qui traînent

• Déployer Windows LAPS sur chaque poste de travail et serveur membre — des mots de passe d'administrateur local uniques tuent le mouvement latéral le plus courant. Voir Déployer Windows LAPS.
• Trouver et supprimer les mots de passe des préférences de stratégie de groupe (GPP), puis les renouveler — les valeurs cpassword sont lisibles par tout utilisateur du domaine. Voir Supprimer les mots de passe GPP.
• Supprimer les SPN inutiles et attribuer de longs mots de passe aléatoires aux autres — cela rend le Kerberoasting et l'AS-REP roasting non rentables. Voir Se défendre contre le Kerberoasting.
• Allonger les mots de passe des administrateurs et des comptes de service avec des stratégies affinées — la longueur l'emporte sur les règles de complexité. Voir Une stratégie de mots de passe qui fonctionne.

Gains faciles côté réseau

• Désactiver LLMNR, NBT-NS et WPAD — cela supprime la capture d'identifiants la plus facile sur le réseau local. Voir Désactiver LLMNR, NBT-NS, mDNS et WPAD.
• Exiger la signature SMB et supprimer SMBv1 — le relais vers SMB et le SMB hérité propice aux vers disparaissent tous deux. Voir Exiger la signature SMB.
• Régler ms-DS-MachineAccountQuota sur 0 — les utilisateurs ordinaires ne doivent pas pouvoir créer des comptes d'ordinateurs qui alimenteront ensuite des chaînes RBCD et de relais. Voir ms-DS-MachineAccountQuota à 0.

Contrôleurs de domaine

• Corriger les DC et confirmer l'application du canal sécurisé Netlogon — les failles de type ZeroLogon restent une prise de contrôle du domaine en un coup. Voir Application du canal sécurisé Netlogon.
• Arrêter le spouleur d'impression et les autres services inutiles sur les DC — moins de services, moins de chemins de coercition et d'exploitation. Voir Durcissement des contrôleurs de domaine.
• Renouveler le mot de passe krbtgt s'il n'a pas changé depuis des années — une ancienne clé krbtgt signifie que toute compromission passée peut encore permettre des golden tickets. Voir Renouveler le krbtgt sans risque.

Au jour 30, relancez PingCastle. Une baisse du score d'un tiers ou plus est courante une fois ces éléments traités.

Jours 31 à 60 : fermer les chemins de relais et de délégation

Le deuxième mois porte sur les contrôles qui nécessitent une phase d'audit : protections contre le relais NTLM, nettoyage de la délégation et AD CS. Lancez chacun en mode audit ou journalisation au jour 31, puis imposez-le au fur et à mesure que les données le permettent.

Relais NTLM et protocoles hérités

• Imposer la signature LDAP et la liaison de canal — le relais vers LDAP est la voie par laquelle une authentification forcée se transforme en RBCD ou en shadow credentials. Voir Imposer la signature LDAP et la liaison de canal.
• Auditer NTLM, puis supprimer NTLMv1 et restreindre NTLM là où c'est possible — chaque flux NTLM restant est un relais potentiel. Voir Auditer et restreindre NTLM.
• Revoir de bout en bout la situation face au relais NTLM — signature, EPA et résolution de noms fonctionnent ensemble. Voir Stopper le relais NTLM.
• Bloquer la coercition d'authentification sur les DC et les serveurs Tier 0 — les astuces à la PetitPotam alimentent toutes les chaînes de relais. Voir Bloquer la coercition d'authentification.

Services de certificats AD

• Auditer les modèles de certificats pour ESC1–ESC4 — un modèle qui laisse le demandeur fournir le sujet est un certificat d'administrateur de domaine à la portée de tous. Voir Auditer les modèles de certificats.
• Sécuriser ou supprimer l'inscription Web — l'inscription HTTP sans EPA est la cible de relais ESC8. Voir Sécuriser l'inscription Web AD CS.
• Passer à l'application du mappage fort des certificats — les mappages faibles permettent à des certificats forgés ou réutilisés d'usurper des comptes. Voir Le mappage fort des certificats.
• Traiter les AC comme du Tier 0 et fermer les constats ESC restants — voir Durcissement d'AD CS.

Kerberos et délégation

• Supprimer la délégation non contrainte partout sauf sur les DC — tout hôte compromis qui la porte peut capturer des TGT privilégiés. Voir Supprimer la délégation non contrainte.
• Revoir la délégation contrainte et qui peut écrire la RBCD — la transition de protocole et un msDS-AllowedToActOnBehalfOfOtherIdentity accessible en écriture sont des chemins d'élévation discrets. Voir Délégation contrainte et RBCD en toute sécurité.
• Obtenir une vue d'ensemble de la délégation, approbations comprises — voir La délégation dans Active Directory.
• Auditer l'usage de RC4 et planifier son retrait — ce sont les tickets RC4 qui rendent le roasting rapide. Voir Désactiver RC4 dans Kerberos.
• Appliquer le socle Kerberos plus large — voir Durcissement de Kerberos.

Comptes de service

• Migrer les comptes de service vers des gMSA (ou des dMSA sous Windows Server 2025) — les mots de passe administrés règlent définitivement le problème du roasting et de la réutilisation. Voir Migrer les comptes de service vers des gMSA.
• Revoir les privilèges, SPN et droits d'ouverture de session des comptes de service — voir Durcissement des comptes de service.

Jours 61 à 90 : durcissement structurel

Une fois les chemins évidents fermés, le troisième mois construit la structure : un tiering qui empêche l'exposition des identifiants par conception, une stratégie de groupe digne de confiance, des approbations qui ne laissent pas fuir de privilèges et une capacité de restauration réellement testée.

Tiering et accès à privilèges

• Déployer des postes d'administration à privilèges pour les administrateurs Tier 0 — l'appareil sur lequel tape un administrateur fait partie de la frontière. Voir Construire des postes d'administration à privilèges.
• Placer les comptes Tier 0 dans des silos de stratégies d'authentification et dans Protected Users — les identifiants volés deviennent inutilisables hors des hôtes approuvés. Voir Stratégies et silos d'authentification pour le Tier 0.
• Arrêter votre architecture d'administration à long terme — voir ESAE/Red Forest ou modèle d'accès d'entreprise.

Stratégie de groupe et référentiels de sécurité

• Auditer qui peut modifier, lier et créer des GPO — des droits de modification sur une stratégie liée aux DC sont des droits de Domain Admin. Voir Auditer les autorisations et liens des GPO.
• Déployer les référentiels de sécurité Microsoft par anneaux — voir Déployer les référentiels de sécurité Microsoft par GPO.
• Durcir SYSVOL et le traitement des GPO — voir Durcissement de la stratégie de groupe et de SYSVOL.

Contrôleurs de domaine

• Filtrer les DC par pare-feu : uniquement les ports requis, aucun accès Internet sortant, administration depuis le Tier 0 uniquement — voir Filtrer les contrôleurs de domaine par pare-feu.

Approbations et conception de forêt

• Vérifier le filtrage des SID et appliquer l'authentification sélective sur les approbations externes et de forêt — voir Filtrage des SID et authentification sélective.
• Nettoyer le SIDHistory laissé par les migrations — chaque SID résiduel est un privilège supplémentaire que personne ne revoit. Voir Nettoyer le SIDHistory.
• Supprimer les approbations qui ne répondent plus à un besoin métier — voir Durcir les approbations AD et les frontières de forêt.

Sauvegarde et restauration

• Isoler les sauvegardes AD des rançongiciels — des sauvegardes que les administrateurs de domaine peuvent supprimer ne sont pas des sauvegardes. Voir Protéger les sauvegardes AD contre les rançongiciels.
• Rédiger un plan de restauration de forêt — voir Rédiger et répéter un plan de restauration de forêt AD.

En continu : détecter, répéter, re-mesurer

Le durcissement se dégrade. De nouveaux serveurs reçoivent la délégation non contrainte, un éditeur réclame les droits Domain Admin, quelqu'un réactive RC4 pour un vieil équipement. Ces éléments transforment le projet de 90 jours en rythme d'exploitation.

• Transférer les journaux de sécurité des DC vers un collecteur central — aucune détection n'est possible si les événements sont écrasés localement en quelques heures. Voir Windows Event Forwarding pour les contrôleurs de domaine.
• Créer des alertes sur les ID d'événements à forte valeur — modifications de groupes, DCSync, demandes de tickets suspectes, émission de certificats. Voir Référence des ID d'événements de sécurité Active Directory.
• Déployer des honeytokens — un faux administrateur et un honey SPN fournissent une alerte précoce et très fiable en cas de reconnaissance. Voir Honeytokens et leurres dans AD.
• Renouveler le krbtgt selon un calendrier — deux fois par an est un rythme raisonnable, et deux fois de suite après tout incident. Voir Renouveler le krbtgt sans risque.
• Répéter la restauration de forêt au moins une fois par an dans un laboratoire isolé — voir Rédiger et répéter un plan de restauration de forêt AD.
• Relancer PingCastle chaque mois et BloodHound chaque trimestre — suivez le score et le nombre de chemins vers le Tier 0 comme indicateurs clés. Voir Réaliser une évaluation PingCastle.
• Revalider l'inventaire Tier 0 à chaque apparition de nouvelle infrastructure — voir Définir le Tier 0.

Comment utiliser cette checklist

Copiez les checklists dans votre outil de ticketing, avec un ticket par élément, un responsable et une date cible à l'intérieur de la phase. N'attendez pas la fin d'une phase pour lancer le travail d'audit de la suivante : activer l'audit NTLM ou LDAP au jour 10 vous donne un mois de données lorsque la mise en application arrive au jour 45.

Considérez l'ordre comme un choix par défaut, pas comme une règle. Si votre rapport PingCastle révèle un constat critique — droits DCSync pour Everyone, modèle ESC1 ouvert à l'inscription par Domain Users, mot de passe de Domain Admin inchangé depuis 2011 —, corrigez-le aujourd'hui, quelle que soit sa phase. De même, si un élément ne s'applique pas (pas d'AD CS, pas d'approbations), marquez-le comme non applicable avec une courte note, afin que le prochain auditeur sache qu'il a été examiné.

Enfin, rendez compte des progrès avec les chiffres relevés avant de commencer. Un score d'évaluation en baisse et un nombre décroissant de chemins d'attaque vers Domain Admins sont ce qui justifie la prochaine vague d'investissement, et ils convainquent bien davantage qu'une liste de GPO modifiées.

Pour aller plus loin : Tier 0 & accès à privilèges, Kerberos & authentification, Délégation, NTLM & protocoles hérités, Services de certificats AD, Stratégie de groupe & SYSVOL, Durcissement des contrôleurs de domaine, Sécurité des objets & ACL, Mots de passe & comptes de service, Approbations & conception de forêt, Audit, journalisation & détection, Évaluation, sauvegarde & restauration.