Active Directory (AD) est le pilier central de l’infrastructure informatique de la quasi-totalité des entreprises. Annuaire d’identités, gestionnaire d’accès, socle d’authentification : il contrôle qui accède à quoi, depuis où et comment. Et c’est précisément pour cette raison qu’il constitue la cible numéro un des attaquants.
Selon le rapport Mandiant 2024, plus de 80 % des compromissions majeures impliquent Active Directory à un moment ou un autre de la chaîne d’attaque. Microsoft estime que 95 millions de comptes AD sont attaqués chaque jour. Pour un attaquant, compromettre AD revient à obtenir les clés de l’ensemble du système d’information.
Chez RM3A, nous réalisons régulièrement des audits de sécurité AD pour des entreprises de toutes tailles. Voici les 10 erreurs critiques que nous retrouvons systématiquement, avec pour chacune l’explication du risque, la méthode d’exploitation par les attaquants, et le correctif concret à appliquer.
Erreur n°1 : trop de comptes dans le groupe Domain Admins
C’est l’erreur la plus fréquente et la plus dangereuse. Nous trouvons régulièrement des environnements où 15, 20, voire 50 comptes sont membres du groupe Domain Admins. Certains sont des comptes de service, d’autres des comptes personnels d’administrateurs qui n’ont pas besoin de ce niveau de privilège au quotidien.
Pourquoi c’est dangereux : chaque compte Domain Admin est une porte d’entrée vers le contrôle total du domaine. Si un seul de ces comptes est compromis (phishing, vol de hash, keylogger), l’attaquant obtient immédiatement les droits les plus élevés.
Comment les attaquants exploitent cette faille : via des techniques comme Pass-the-Hash ou Pass-the-Ticket, un attaquant qui récupère le hash NTLM d’un Domain Admin peut s’authentifier sur n’importe quelle machine du domaine sans connaître le mot de passe en clair. Plus il y a de comptes privilégiés, plus la surface d’attaque est large.
Le correctif : réduire le groupe Domain Admins à 2-3 comptes maximum, dédiés et nominatifs. Utiliser des comptes d’administration séparés (convention T0-admin-prenom.nom) qui ne sont jamais utilisés pour la navigation web ou la messagerie. Auditer les membres avec Get-ADGroupMember "Domain Admins" -Recursive et retirer immédiatement les comptes inutiles.
Erreur n°2 : absence de modèle de tiering (Admin Tier Model)
Le modèle de tiering Microsoft divise l’infrastructure en trois niveaux : Tier 0 (contrôleurs de domaine, AD), Tier 1 (serveurs applicatifs) et Tier 2 (postes de travail). Le principe est simple : un compte d’un niveau donné ne doit jamais s’authentifier sur un niveau inférieur ou supérieur.
Pourquoi c’est dangereux : sans tiering, un administrateur qui se connecte en RDP sur un serveur applicatif avec son compte Domain Admin laisse ses credentials en mémoire. Si ce serveur est compromis, l’attaquant récupère les credentials Tier 0 depuis un asset Tier 1.
Comment les attaquants exploitent cette faille : l’outil Mimikatz permet d’extraire les credentials en mémoire (hash NTLM, tickets Kerberos) de tout utilisateur connecté sur une machine. Sans tiering, il suffit de compromettre un poste de travail où un admin s’est connecté pour remonter jusqu’au domaine.
Le correctif : implémenter le tiering en commençant par Tier 0. Créer des comptes d’administration dédiés par tier. Configurer des GPO de restriction de connexion (User Rights Assignment) pour empêcher les comptes Tier 0 de se connecter sur les machines Tier 1 et Tier 2. Déployer des PAW (Privileged Access Workstations) pour l’administration Tier 0.
Erreur n°3 : politique de mots de passe insuffisante
Nous trouvons encore des domaines avec une politique de mots de passe à 8 caractères, sans complexité réelle, et surtout sans expiration ou avec une expiration à 365 jours. Pire, certains comptes de service utilisent des mots de passe définis il y a plus de 5 ans.
Pourquoi c’est dangereux : un mot de passe de 8 caractères peut être craqué par force brute en quelques heures avec du matériel courant. Les mots de passe qui n’expirent jamais restent valides indéfiniment même après le départ d’un collaborateur.
Comment les attaquants exploitent cette faille : les attaques par dictionnaire et par force brute offline (après récupération de la base NTDS.dit) sont extrêmement efficaces contre les mots de passe courts. L’outil Hashcat peut tester des milliards de combinaisons par seconde sur GPU.
Le correctif : appliquer une Fine-Grained Password Policy (FGPP) avec au minimum 14 caractères pour les comptes standard et 20+ caractères pour les comptes privilégiés. Activer Azure AD Password Protection pour bloquer les mots de passe courants. Implémenter des passphrases plutôt que des mots de passe complexes mais courts. Vérifier régulièrement les mots de passe contre des listes de compromission avec des outils comme DSInternals.
Erreur n°4 : comptes vulnérables au Kerberoasting
Le Kerberoasting est une attaque qui cible les comptes de service ayant un SPN (Service Principal Name) défini dans AD. L’attaquant demande un ticket Kerberos TGS pour ce service, puis tente de craquer le mot de passe offline à partir du ticket chiffré.
Pourquoi c’est dangereux : cette attaque ne génère quasiment aucune alerte car la demande de ticket TGS est une opération légitime dans Kerberos. Si le compte de service a un mot de passe faible, l’attaquant le récupère en clair en quelques minutes.
Comment les attaquants exploitent cette faille : avec un simple compte utilisateur du domaine (aucun privilège requis), l’attaquant utilise Rubeus ou Impacket pour extraire les tickets TGS de tous les comptes avec SPN, puis craque les mots de passe offline avec Hashcat. Si un de ces comptes est Domain Admin ou a des droits élevés, le domaine est compromis.
Le correctif : identifier tous les comptes avec SPN via Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName. Remplacer les comptes de service classiques par des gMSA (Group Managed Service Accounts) dont le mot de passe est géré automatiquement par AD (240 caractères aléatoires, rotation automatique). Pour les comptes qui ne peuvent pas utiliser gMSA, imposer des mots de passe de 30+ caractères.
Erreur n°5 : pas de LAPS (Local Administrator Password Solution)
Sans LAPS, tous les postes de travail partagent le même mot de passe administrateur local, souvent défini lors du déploiement du master et jamais changé. Certaines entreprises utilisent même un mot de passe identique sur les postes et les serveurs.
Pourquoi c’est dangereux : si un attaquant récupère le mot de passe admin local d’un seul poste (via Mimikatz, SAM dump, ou simplement en le trouvant dans un script de déploiement), il peut se connecter à tous les postes du parc avec le même mot de passe. C’est le mouvement latéral facilité.
Comment les attaquants exploitent cette faille : technique Pass-the-Hash avec le hash du compte administrateur local. L’outil CrackMapExec permet de tester un hash sur l’ensemble du réseau en quelques secondes et d’identifier toutes les machines accessibles.
Le correctif : déployer Microsoft LAPS (ou Windows LAPS intégré à Windows 11/Server 2025). Chaque poste aura un mot de passe administrateur local unique, stocké de manière chiffrée dans AD et renouvelé automatiquement. Le déploiement est simple : installer le CSE sur les postes, configurer la GPO, déléguer les droits de lecture aux équipes support.
Erreur n°6 : GPO mal configurées ou obsolètes
Les Group Policy Objects s’accumulent au fil des années. Nous trouvons régulièrement des environnements avec 200+ GPO dont un tiers sont désactivées, orphelines, ou en conflit entre elles. Certaines contiennent des mots de passe en clair (préférences de GPO), d’autres désactivent des contrôles de sécurité critiques.
Pourquoi c’est dangereux : des GPO mal ordonnées peuvent annuler des paramètres de sécurité. Les mots de passe stockés dans les préférences de GPO (cpassword) sont chiffrés avec une clé AES publiée par Microsoft, donc lisibles par tout utilisateur du domaine. Des GPO qui désactivent le pare-feu ou l’UAC augmentent considérablement la surface d’attaque.
Comment les attaquants exploitent cette faille : l’outil Group Policy Preference Password Finder (Get-GPPPassword) permet de scanner SYSVOL et d’extraire automatiquement tous les mots de passe en clair des anciennes préférences. Les GPO qui affaiblissent la sécurité facilitent le mouvement latéral et l’élévation de privilèges.
Le correctif : auditer l’ensemble des GPO avec des outils comme GPOZaurr (module PowerShell). Supprimer les GPO obsolètes et non liées. Vérifier l’absence de mots de passe dans les préférences. S’assurer que les GPO de sécurité (restriction de connexion, audit, pare-feu) ont la priorité correcte et ne sont pas surchargées par des GPO contradictoires.
Erreur n°7 : pas de surveillance des événements critiques
La majorité des entreprises que nous auditons n’ont aucune centralisation ni surveillance des journaux d’événements Windows. Les contrôleurs de domaine génèrent des milliers d’événements par heure, mais personne ne les analyse. Les logs sont souvent écrasés après quelques jours faute d’espace disque.
Pourquoi c’est dangereux : sans surveillance, un attaquant peut opérer pendant des semaines voire des mois sans être détecté. Le temps moyen de détection d’une compromission est de 204 jours selon IBM. Chaque jour non détecté permet à l’attaquant d’approfondir son accès et d’exfiltrer davantage de données.
Les Event IDs critiques à surveiller :
- 4624 / 4625 : connexion réussie / échouée – détecter les tentatives de brute force et les connexions anormales
- 4672 : attribution de privilèges spéciaux – alerte immédiate si un compte non autorisé reçoit des privilèges admin
- 4768 / 4769 : demande de TGT / TGS Kerberos – détecter le Kerberoasting (volume anormal de demandes TGS)
- 4720 / 4726 : création / suppression de compte – détecter la création de backdoor accounts
- 4732 / 4733 : ajout / suppression d’un membre dans un groupe de sécurité – alerte sur les modifications de groupes privilégiés
- 1102 : effacement du journal de sécurité – signe quasi certain de compromission
Le correctif : activer les politiques d’audit avancées via GPO (Audit Policy > Advanced Audit Policy Configuration). Centraliser les logs dans un SIEM (Microsoft Sentinel, Elastic SIEM, Splunk). Créer des alertes sur les événements critiques listés ci-dessus. Conserver les logs au minimum 12 mois. Pour les entreprises sans SIEM, au minimum configurer des tâches planifiées de surveillance avec des scripts PowerShell.
Erreur n°8 : pas de protection contre DCSync et DCShadow
DCSync est une technique qui permet à un attaquant disposant de certains droits (Replicating Directory Changes) de simuler un contrôleur de domaine et de demander la réplication de tous les hashes de mots de passe, y compris celui du compte krbtgt. DCShadow va encore plus loin en enregistrant temporairement une fausse machine comme contrôleur de domaine pour injecter des modifications directement dans AD.
Pourquoi c’est dangereux : DCSync permet de récupérer le hash du compte krbtgt, ce qui ouvre la voie à la création de Golden Tickets Kerberos. Avec un Golden Ticket, l’attaquant peut s’authentifier comme n’importe quel utilisateur du domaine pendant une durée de 10 ans. DCShadow permet de modifier AD sans laisser de traces dans les logs classiques.
Comment les attaquants exploitent cette faille : l’outil Mimikatz intègre les modules lsadump::dcsync et lsadump::dcshadow. Un attaquant ayant compromis un compte avec les droits de réplication (souvent accordés de manière trop large) peut extraire l’intégralité de la base NTDS.dit à distance.
Le correctif : auditer les ACL au niveau du domaine pour identifier tous les comptes ayant les droits Replicating Directory Changes et Replicating Directory Changes All. Retirer ces droits à tout compte qui n’est pas un contrôleur de domaine légitime. Surveiller les Event IDs 4662 (accès à un objet AD avec droits de réplication) et 4929 (réplication entrante). Implémenter des règles de détection spécifiques dans le SIEM.
Erreur n°9 : AdminSDHolder mal compris et mal géré
AdminSDHolder est un mécanisme de protection intégré à AD qui réinitialise toutes les 60 minutes les ACL des comptes et groupes protégés (Domain Admins, Enterprise Admins, etc.) pour qu’elles correspondent à celles de l’objet AdminSDHolder. Ce mécanisme est souvent méconnu des administrateurs, ce qui entraîne des configurations incohérentes.
Pourquoi c’est dangereux : si un attaquant parvient à modifier les ACL de l’objet AdminSDHolder, ces modifications seront automatiquement propagées à tous les comptes protégés du domaine toutes les heures. C’est un mécanisme de persistance extrêmement discret. De plus, des comptes retirés de groupes protégés conservent le flag AdminCount=1 et des ACL restreintes, ce qui crée de la confusion dans la gestion des droits.
Comment les attaquants exploitent cette faille : en modifiant les ACL d’AdminSDHolder pour s’accorder des droits (GenericAll, WriteDACL) sur cet objet, l’attaquant obtient automatiquement ces droits sur tous les comptes protégés du domaine. Cette modification n’est pas surveillée dans la plupart des environnements.
Le correctif : auditer régulièrement les ACL de l’objet AdminSDHolder avec Get-ACL "AD:CN=AdminSDHolder,CN=System,DC=domaine,DC=local". Comparer avec les ACL par défaut documentées par Microsoft. Surveiller les modifications avec l’Event ID 4662 sur l’objet AdminSDHolder. Nettoyer les comptes orphelins ayant AdminCount=1 mais n’étant plus dans un groupe protégé.
Erreur n°10 : pas de plan de durcissement AD post-audit
Réaliser un audit de sécurité AD est une excellente initiative, mais nous constatons que beaucoup d’entreprises reçoivent leur rapport d’audit, corrigent une ou deux vulnérabilités urgentes, puis le rapport prend la poussière. Il n’y a pas de plan structuré de remédiation, pas de suivi, et surtout pas de processus continu de durcissement.
Pourquoi c’est dangereux : la sécurité AD n’est pas un état, c’est un processus. De nouvelles vulnérabilités sont découvertes régulièrement, les configurations dérivent au fil des changements d’équipe, et les bonnes pratiques évoluent. Un AD sécurisé aujourd’hui peut redevenir vulnérable dans 6 mois sans suivi.
Le correctif : établir un plan de remédiation priorisé (quick wins en semaine 1-2, corrections majeures en mois 1-3, transformations structurelles en mois 3-12). Planifier des audits réguliers (trimestriels pour les scans automatisés, annuels pour les audits complets). Utiliser des outils d’auto-évaluation continue :
- PingCastle : score de sécurité AD avec rapport détaillé et roadmap de remédiation (gratuit pour usage interne)
- BloodHound : cartographie des chemins d’attaque et des relations de privilèges dans AD
- Purple Knight : évaluation de sécurité AD par Semperis avec plus de 130 indicateurs de compromission
Checklist récapitulative des 10 points
Voici la synthèse des 10 erreurs à corriger en priorité dans votre environnement Active Directory :
- Réduire le groupe Domain Admins à 2-3 comptes dédiés
- Implémenter le modèle de tiering (au minimum Tier 0)
- Appliquer une politique de mots de passe robuste (14+ caractères, FGPP)
- Migrer les comptes de service vers gMSA pour contrer le Kerberoasting
- Déployer LAPS sur l’ensemble des postes et serveurs
- Auditer et nettoyer les GPO obsolètes
- Centraliser et surveiller les événements critiques (SIEM ou scripts)
- Protéger contre DCSync/DCShadow (ACL de réplication)
- Auditer AdminSDHolder et nettoyer les comptes orphelins
- Établir un plan de durcissement continu avec audits réguliers
Vous souhaitez faire auditer la sécurité de votre Active Directory ? Nos consultants réalisent des audits AD complets avec rapport de remédiation priorisé. Contactez-nous pour planifier un audit.
Pour aller plus loin
- Audit et test d’intrusion (pentest) – Identifiez les failles de votre AD avant qu’un attaquant ne les exploite.
- Centre de cyberdéfense (SOC) – Surveillez en continu les comportements suspects dans votre Active Directory.
- Réponse à incident cyber – Réagissez efficacement en cas de compromission de votre annuaire.
- Cybersécurité pour les PME – Des solutions adaptées pour sécuriser l’ensemble de votre SI, AD compris.
