Glossaire Active Directory : 100 Termes Sécurité et Attaques

La sécurité d'Active Directory représente aujourd'hui l'un des enjeux majeurs de la cybersécurité en entreprise. Déployé dans plus de 95 % des organisations du Fortune 500, Active Directory constitue la colonne vertébrale de l'authentification et de l'autorisation dans les environnements Microsoft. Pourtant, cette omniprésence en fait une cible privilégiée pour les attaquants. Des groupes APT aux ransomwares, les vecteurs d'attaque ciblant Active Directory se sont multipliés et sophistiqués au fil des années. Ce glossaire rassemble 100 termes essentiels couvrant l'ensemble du spectre : des concepts fondamentaux aux techniques d'attaque avancées, en passant par les mécanismes de défense et les bonnes pratiques de durcissement. Chaque entrée propose une définition technique approfondie, contextualisée dans le paysage actuel des menaces. Que vous soyez administrateur système, pentesteur, analyste SOC ou architecte sécurité, ce référentiel vous permettra de maîtriser le vocabulaire indispensable pour comprendre, auditer et protéger vos environnements Active Directory. Les termes sont classés par ordre alphabétique pour faciliter la consultation rapide.

Glossaire complet : les 100 termes de la sécurité Active Directory

ACL (Access Control List)

Une Access Control List, ou liste de contrôle d'accès, est un mécanisme fondamental d'Active Directory qui définit les permissions accordées ou refusées sur chaque objet de l'annuaire. Chaque objet AD — qu'il s'agisse d'un utilisateur, d'un groupe, d'un ordinateur ou d'une unité organisationnelle — possède une ACL composée d'entrées de contrôle d'accès (ACE). Ces entrées spécifient quel principal de sécurité (utilisateur ou groupe) dispose de quels droits (lecture, écriture, suppression, modification des permissions) sur l'objet en question. Dans Active Directory, on distingue deux types d'ACL : la DACL (Discretionary Access Control List), qui contrôle l'accès aux objets, et la SACL (System Access Control List), qui gère l'audit des accès. La DACL est celle qui intéresse le plus les professionnels de la sécurité, car une mauvaise configuration peut ouvrir des chemins d'attaque critiques. Par exemple, si un compte de service dispose du droit GenericAll sur un objet Domain Admin, un attaquant compromettant ce compte pourrait modifier le mot de passe du Domain Admin. Les outils comme BloodHound cartographient précisément ces relations ACL pour identifier les chemins d'escalade de privilèges. La revue régulière des ACL, notamment sur les objets sensibles comme le groupe Domain Admins ou les contrôleurs de domaine, constitue une mesure défensive essentielle. Microsoft recommande d'appliquer le principe du moindre privilège et de surveiller toute modification des DACL via les événements Windows 4662 et 5136.

ACL Abuse

L'ACL Abuse désigne l'exploitation malveillante des permissions mal configurées dans Active Directory pour escalader les privilèges ou maintenir un accès persistant. Cette technique est devenue l'un des vecteurs d'attaque les plus redoutables car elle ne nécessite aucune vulnérabilité logicielle : elle exploite simplement des erreurs de configuration. Les attaquants recherchent des permissions excessives comme GenericAll, GenericWrite, WriteDACL, WriteOwner ou ForceChangePassword accordées à des comptes faiblement protégés. Par exemple, un compte de service disposant de WriteDACL sur un groupe privilégié peut s'octroyer lui-même le droit de s'y ajouter. L'outil BloodHound excelle dans la découverte de ces chemins d'abus en construisant un graphe complet des relations ACL. Les scénarios courants incluent la modification du msDS-AllowedToActOnBehalfOfOtherIdentity pour configurer une délégation contrainte basée sur les ressources (RBCD), l'ajout d'un SPN sur un compte pour le rendre kerberoastable, ou encore la modification de la propriété msDS-KeyCredentialLink pour une attaque Shadow Credentials. Pour se défendre, il convient d'auditer régulièrement les ACL des objets critiques avec des outils comme ADACLScanner, de surveiller les événements de modification de sécurité (5136, 4662), et d'implémenter le modèle de tiering pour limiter la portée des permissions. La remédiation passe par la suppression systématique des permissions inutiles et l'application rigoureuse du principe du moindre privilège. Pour approfondir ce sujet, consultez notre article dédié à l'ACL Abuse.

AD CS (Active Directory Certificate Services)

Active Directory Certificate Services est le rôle serveur Microsoft qui fournit une infrastructure à clé publique (PKI) intégrée à Active Directory. AD CS permet d'émettre, de gérer et de révoquer des certificats numériques utilisés pour l'authentification, le chiffrement et la signature numérique au sein du domaine. Ce service est devenu un sujet brûlant en cybersécurité depuis la publication par SpecterOps des recherches sur les vulnérabilités ESC1 à ESC8, puis étendues jusqu'à ESC15. Ces vulnérabilités exploitent des erreurs de configuration dans les modèles de certificats, les permissions de l'autorité de certification ou les paramètres d'inscription. Par exemple, ESC1 permet à un utilisateur de demander un certificat avec un Subject Alternative Name (SAN) arbitraire, lui permettant de s'authentifier en tant que n'importe quel utilisateur du domaine, y compris un Domain Admin. AD CS est particulièrement dangereux car les certificats ont généralement une durée de vie longue (un an par défaut), et il n'existait jusqu'à récemment aucun mécanisme natif pour révoquer efficacement un certificat compromis dans le contexte Kerberos PKINIT. L'outil Certify et Certipy permettent d'auditer et d'exploiter ces vulnérabilités. La défense passe par un audit minutieux de chaque modèle de certificat, la restriction des droits d'inscription, la désactivation du flag ENROLLEE_SUPPLIES_SUBJECT sur les modèles sensibles, et la surveillance des événements d'émission de certificats (événement 4887). Consultez notre guide complet sur AD CS ainsi que le bilan ESC1 à ESC15 pour une analyse détaillée.

AD DS (Active Directory Domain Services)

Active Directory Domain Services constitue le service d'annuaire principal de Microsoft, responsable du stockage et de la gestion des informations sur les objets du réseau : utilisateurs, ordinateurs, groupes, stratégies de groupe et autres ressources. AD DS fonctionne selon un modèle hiérarchique organisé en domaines, arbres et forêts, avec une réplication multi-maîtres entre les contrôleurs de domaine. Chaque contrôleur de domaine héberge une copie de la base de données NTDS.dit qui contient l'intégralité des objets et de leurs attributs, y compris les hachages de mots de passe. Le service utilise principalement les protocoles LDAP pour les requêtes d'annuaire et Kerberos pour l'authentification. AD DS implémente également le DNS intégré, les stratégies de groupe (GPO), et la réplication via le protocole DRS (Directory Replication Service). Du point de vue sécurité, AD DS est le composant le plus critique de l'infrastructure Windows car sa compromission donne à l'attaquant un contrôle total sur l'ensemble du domaine. Les attaques ciblant AD DS incluent le DCSync qui exploite le protocole de réplication, le DCShadow qui permet d'injecter des modifications furtives, et l'extraction directe du fichier NTDS.dit. La protection d'AD DS nécessite une approche de défense en profondeur incluant le modèle de tiering, la surveillance des protocoles de réplication, le durcissement des contrôleurs de domaine et la segmentation réseau stricte. La vulnérabilité CVE-2025-21293 a récemment démontré que même des composants natifs d'AD DS peuvent présenter des failles d'escalade de privilèges.

AdminSDHolder

AdminSDHolder est un mécanisme de protection intégré à Active Directory qui sécurise les comptes et groupes privilégiés contre les modifications non autorisées de leurs permissions. Toutes les 60 minutes par défaut, le processus SDProp (Security Descriptor Propagator) exécuté par le contrôleur de domaine détenteur du rôle PDC Emulator compare les ACL des comptes protégés avec celles de l'objet AdminSDHolder (situé dans CN=AdminSDHolder,CN=System,DC=domain,DC=com), et écrase toute divergence. Les groupes protégés incluent Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Print Operators et Server Operators. Ce mécanisme, bien que conçu pour la sécurité, peut être détourné par les attaquants comme technique de persistance. En modifiant les ACL de l'objet AdminSDHolder lui-même, un attaquant disposant de privilèges suffisants peut s'assurer que ses permissions malveillantes seront automatiquement propagées à tous les comptes protégés lors de la prochaine exécution de SDProp. Cette technique est particulièrement sournoise car la modification ne porte que sur un seul objet, mais affecte l'ensemble des comptes privilégiés. La détection passe par la surveillance des modifications de l'objet AdminSDHolder (événement 5136) et par des audits réguliers comparant ses ACL avec un état de référence. Il est également important de surveiller l'attribut adminCount qui est positionné à 1 sur les objets protégés — un attribut qui n'est jamais automatiquement réinitialisé même si le compte est retiré d'un groupe protégé, créant des orphelins qu'il convient de nettoyer. Pour une analyse détaillée de cette technique, consultez notre article sur AdminSDHolder.

ADFS (Active Directory Federation Services)

Active Directory Federation Services est le service de fédération d'identité de Microsoft qui permet l'authentification unique (SSO) entre différentes organisations ou entre un environnement on-premises et des services cloud. ADFS utilise principalement les protocoles SAML 2.0, WS-Federation et OAuth 2.0/OpenID Connect pour émettre des jetons de sécurité. Dans le contexte de l'authentification, ADFS agit comme un Security Token Service (STS) qui transforme une authentification Active Directory locale en un jeton SAML accepté par les applications partenaires. Du point de vue sécurité, ADFS présente une surface d'attaque significative. L'attaque la plus célèbre est le Golden SAML, popularisée par l'incident SolarWinds (Nobelium/Cozy Bear), où l'attaquant extrait le certificat de signature de jetons ADFS pour forger des assertions SAML arbitraires. Avec ce certificat, l'attaquant peut s'authentifier comme n'importe quel utilisateur auprès de n'importe quel service trust configuré, incluant Microsoft 365 et Azure/Entra ID. Les serveurs ADFS doivent être traités comme des actifs Tier 0 dans le modèle de tiering, au même niveau que les contrôleurs de domaine, car leur compromission a un impact équivalent. La protection inclut le stockage du certificat de signature dans un HSM, la rotation régulière des certificats, la surveillance des connexions anormales et la migration progressive vers Entra ID qui offre des contrôles de sécurité plus granulaires. Microsoft pousse activement les organisations à migrer d'ADFS vers Entra ID pour réduire cette surface d'attaque. Notre article sur AD FS et SAML détaille les méthodologies d'attaque et de défense.

AS-REP Roasting

L'AS-REP Roasting est une technique d'attaque qui cible les comptes Active Directory configurés avec l'option « Do not require Kerberos preauthentication ». Normalement, lors de la phase d'authentification Kerberos (AS-REQ), le client doit prouver son identité en chiffrant un timestamp avec son hachage de mot de passe. Lorsque la pré-authentification est désactivée, le KDC répond directement avec un AS-REP contenant une partie chiffrée avec le hachage du mot de passe de l'utilisateur, sans vérification préalable. Un attaquant peut donc demander un AS-REP pour n'importe quel compte sans pré-authentification et tenter de casser le hachage hors ligne. L'attribut concerné est userAccountControl avec le flag DONT_REQUIRE_PREAUTH (0x400000). L'outil Rubeus avec la commande asreproast ou le module GetNPUsers.py d'Impacket permettent d'automatiser cette attaque. Les hachages récupérés sont au format Kerberos 5 AS-REP (type 23 pour RC4, type 18 pour AES256) et peuvent être soumis à hashcat (mode 18200) ou John the Ripper. Bien que moins courante que le Kerberoasting, cette technique reste efficace car certaines applications legacy ou configurations héritées nécessitent la désactivation de la pré-authentification. La défense consiste à identifier tous les comptes concernés avec une requête LDAP ciblant le flag UAC, à activer la pré-authentification partout où possible, et à imposer des mots de passe robustes d'au moins 25 caractères sur les comptes qui ne peuvent pas être modifiés. La surveillance des événements 4768 avec le code de chiffrement RC4 peut également aider à détecter cette attaque. Consultez notre analyse technique de l'AS-REP Roasting.

Attack Path (Chemin d'Attaque)

Un chemin d'attaque (Attack Path) dans le contexte Active Directory désigne la séquence de relations, de permissions et de configurations exploitables qu'un attaquant peut enchaîner pour atteindre un objectif, typiquement la compromission du domaine. La notion de chemin d'attaque a révolutionné l'approche de la sécurité AD en démontrant que des faiblesses individuellement mineures peuvent, combinées, constituer un risque critique. Par exemple, un chemin d'attaque typique pourrait être : compromission d'un poste utilisateur, récupération du hachage d'un compte de service via Kerberoasting, exploitation d'une permission GenericAll de ce compte sur un groupe, ajout au groupe qui dispose de WriteDACL sur le Domain Admins, et finalement compromission du domaine. L'outil BloodHound, développé par SpecterOps, a été le premier à formaliser et automatiser la découverte de ces chemins en modélisant Active Directory comme un graphe orienté. Les noeuds représentent les objets AD (utilisateurs, groupes, ordinateurs, GPO) et les arêtes représentent les relations exploitables (appartenance aux groupes, sessions, ACL, délégation). L'analyse des chemins d'attaque permet aux équipes défensives de prioriser les remédiations en traitant en premier les chemins les plus courts et les plus critiques. Les concepts clés incluent le choke point (point de passage obligé dont la correction élimine plusieurs chemins), la blast radius (impact de la compromission d'un noeud donné), et le Tier 0 (ensemble des assets dont la compromission entraîne le contrôle total du domaine). La gestion proactive des chemins d'attaque est aujourd'hui considérée comme une pratique essentielle de la sécurité AD. Notre article sur BloodHound 5 explore les dernières évolutions en matière de détection de chemins.

BloodHound

BloodHound est un outil open-source de cartographie et d'analyse des relations Active Directory, développé par SpecterOps, qui permet de visualiser les chemins d'attaque potentiels sous forme de graphe. Il utilise un collecteur de données (SharpHound pour Windows, BloodHound.py pour Linux) qui interroge l'annuaire LDAP et les sessions SMB pour récupérer les informations sur les utilisateurs, groupes, ordinateurs, sessions actives, ACL, GPO et relations de confiance. Ces données sont ensuite importées dans une base de données Neo4j (ou AzureHound pour les environnements Entra ID) pour construire un graphe navigable. BloodHound excelle dans l'identification de chemins d'escalade de privilèges invisibles à l'oeil nu. Ses requêtes Cypher préconfigurées permettent de trouver rapidement le plus court chemin vers Domain Admin, les comptes Kerberoastable, les machines avec délégation non contrainte, ou les chemins via ACL. La version Community Edition (CE), basée sur une API PostgreSQL, a modernisé l'interface et ajouté le support des environnements hybrides. BloodHound est utilisé tant par les équipes offensives lors des tests d'intrusion que par les équipes défensives pour identifier et remédier proactivement les faiblesses. Les blue teams utilisent notamment les métriques comme le nombre de chemins vers Tier 0, le nombre de sessions privilégiées sur des postes non sécurisés, et le nombre de comptes avec des ACL dangereuses. Pour contrer la collecte BloodHound, les défenseurs peuvent restreindre les requêtes LDAP anonymes, surveiller les énumérations massives (événement 4662 en masse), et limiter l'accès au NetSessionEnum. Notre guide BloodHound et l'article sur BloodHound 5 offrent une couverture approfondie.

BUILTIN Groups

Les BUILTIN Groups sont des groupes de sécurité prédéfinis créés automatiquement lors de l'installation d'Active Directory. Situés dans le conteneur CN=Builtin,DC=domain,DC=com, ces groupes possèdent des privilèges spécifiques qui ne peuvent pas être supprimés ni déplacés. Les principaux groupes BUILTIN incluent Administrators (contrôle total sur le domaine), Account Operators (gestion des comptes utilisateurs et groupes non privilégiés), Backup Operators (sauvegarde et restauration de fichiers, incluant NTDS.dit), Print Operators (gestion des imprimantes avec capacité de charger des pilotes), Server Operators (gestion des contrôleurs de domaine), et Remote Desktop Users (accès RDP). Du point de vue sécurité, plusieurs de ces groupes présentent des risques majeurs souvent sous-estimés. Les Backup Operators, par exemple, peuvent extraire le fichier NTDS.dit via wbadmin ou les commandes VSS, obtenant ainsi tous les hachages du domaine. Les Account Operators peuvent créer et modifier des comptes, potentiellement s'octroyer des privilèges élevés. Les Print Operators peuvent charger des pilotes d'impression malveillants s'exécutant en SYSTEM sur les contrôleurs de domaine. Le groupe Administrators local des DC accorde des droits de Domain Admin de facto. Il est essentiel de maintenir ces groupes aussi vides que possible et de surveiller toute modification de leur composition via les événements 4728, 4732 et 4756. L'audit régulier avec des scripts PowerShell automatisés permet de détecter les ajouts non autorisés. Le modèle de tiering recommande de traiter les membres de ces groupes comme des comptes Tier 0.

Certificate Template (Modèle de Certificat)

Un Certificate Template, ou modèle de certificat, est un objet Active Directory qui définit les paramètres d'un type de certificat pouvant être émis par une autorité de certification AD CS. Stockés dans la partition Configuration de l'annuaire (CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration), ces modèles spécifient les extensions du certificat, la durée de validité, les algorithmes cryptographiques, les conditions d'inscription et les permissions d'accès. Les modèles de certificats sont au coeur des vulnérabilités AD CS. La recherche de SpecterOps a identifié de nombreux scénarios d'abus : ESC1 survient lorsqu'un modèle autorise le demandeur à spécifier un Subject Alternative Name (SAN) arbitraire avec le flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT. ESC2 concerne les modèles avec l'EKU « Any Purpose » ou sans EKU. ESC3 exploite l'EKU Certificate Request Agent. ESC4 porte sur les permissions d'écriture sur le modèle lui-même, permettant à un attaquant de modifier ses propriétés pour le rendre vulnérable. Chaque modèle possède une DACL qui contrôle qui peut s'inscrire (Enroll) et qui peut modifier le modèle. L'outil Certipy avec la commande find -vulnerable automatise l'audit des modèles vulnérables. La remédiation consiste à auditer chaque modèle activé, supprimer les permissions d'inscription excessives, désactiver les flags dangereux, et implémenter l'approbation par un gestionnaire pour les modèles sensibles. Le bilan ESC1 à ESC15 fournit une cartographie complète des vulnérabilités liées aux modèles de certificats.

Coercion (Coercition d'Authentification)

La coercion, ou coercition d'authentification, est une technique d'attaque qui force un serveur Windows à s'authentifier auprès d'une machine contrôlée par l'attaquant. Le principe consiste à exploiter des interfaces RPC ou des fonctionnalités Windows légitimes pour déclencher une connexion sortante depuis un serveur cible, généralement un contrôleur de domaine. L'authentification ainsi capturée — typiquement NTLM — peut ensuite être relayée vers un autre service (NTLM Relay) ou utilisée pour des attaques de type relais NTLM. Les techniques de coercion les plus connues incluent PetitPotam (via MS-EFSRPC), PrinterBug/SpoolService (via MS-RPRN), DFSCoerce (via MS-DFSNM), et ShadowCoerce (via MS-FSRVP). Chacune exploite une interface RPC différente mais le résultat est similaire : le serveur cible initie une connexion SMB vers l'attaquant. La combinaison coercion + relay NTLM vers AD CS (ESC8) est particulièrement dévastatrice car elle permet d'obtenir un certificat pour le compte machine du contrôleur de domaine, offrant ensuite un accès DCSync. Depuis la découverte de PetitPotam, Microsoft a déployé plusieurs correctifs mais de nouvelles interfaces RPC exploitables sont régulièrement découvertes. La protection passe par l'activation de l'EPA (Extended Protection for Authentication) sur tous les services web, la désactivation de NTLM quand possible, le blocage du trafic SMB sortant des contrôleurs de domaine via le pare-feu, et l'activation du LDAP Signing et Channel Binding. La surveillance des connexions SMB sortantes anormales depuis les DC constitue également un indicateur de compromission pertinent.

Computer Account (Compte Machine)

Un Computer Account, ou compte machine, est un objet Active Directory représentant un ordinateur membre du domaine. Chaque machine jointe au domaine possède un compte dans l'annuaire avec un mot de passe automatiquement renouvelé tous les 30 jours par défaut. Ce mot de passe, stocké dans l'attribut unicodePwd, est un secret partagé entre la machine et le contrôleur de domaine utilisé pour l'authentification Kerberos et la sécurisation du canal sécurisé (Secure Channel). Les comptes machines jouent un rôle central dans plusieurs techniques d'attaque. L'attribut ms-DS-MachineAccountQuota, par défaut fixé à 10, permet à tout utilisateur authentifié de créer jusqu'à 10 comptes machines dans le domaine. Ces comptes auto-créés peuvent être utilisés pour des attaques RBCD, du relais NTLM, ou comme base pour le mouvement latéral. Un attaquant contrôlant un compte machine peut potentiellement accéder à toutes les données de la machine, effectuer des opérations S4U2Self pour obtenir des tickets de service, et exploiter les relations de confiance locale. Les comptes machines des contrôleurs de domaine sont particulièrement sensibles car ils disposent de droits de réplication (utilisés dans les attaques DCSync). La compromission du compte machine d'un DC via PetitPotam + NTLM Relay permet d'obtenir un accès Domain Admin. La sécurisation passe par la réduction du MachineAccountQuota à 0, la surveillance des créations de comptes machines, l'audit des permissions sur les comptes machines existants, et le déploiement de LAPS pour gérer les mots de passe administrateur local. Notre article sur le Computer Account Takeover détaille les scénarios d'exploitation.

Conditional Access (Accès Conditionnel)

Le Conditional Access, ou accès conditionnel, est un mécanisme de sécurité d'Entra ID (anciennement Azure AD) qui permet d'appliquer des politiques d'accès granulaires basées sur des signaux contextuels. Ces politiques évaluent des conditions telles que l'identité de l'utilisateur, la localisation géographique, le type d'appareil, l'état de conformité, le niveau de risque de connexion, et l'application cible, pour décider d'autoriser l'accès, de le bloquer, ou d'exiger des contrôles supplémentaires comme l'authentification multifacteur (MFA). Dans un environnement hybride Active Directory / Entra ID, le Conditional Access représente une couche de sécurité essentielle qui compense les limites du modèle de sécurité AD on-premises. Les politiques courantes incluent l'exigence de MFA pour les accès depuis des réseaux non approuvés, le blocage des protocoles d'authentification legacy (IMAP, POP3, SMTP AUTH), la restriction de l'accès aux applications sensibles depuis des appareils conformes uniquement, et le blocage des connexions depuis des pays non autorisés. Cependant, des erreurs de configuration peuvent créer des contournements exploitables. Par exemple, l'exclusion de certains utilisateurs ou de protocoles spécifiques peut laisser des portes ouvertes. Les attaquants tentent de contourner le Conditional Access en utilisant des tokens volés, des appareils conformes compromis, ou en exploitant des applications non couvertes par les politiques. L'évaluation continue des accès (Continuous Access Evaluation, CAE) renforce la sécurité en révoquant les sessions en temps quasi réel. Pour les dernières évolutions, consultez notre article sur les nouveautés du Conditional Access.

Constrained Delegation (Délégation Contrainte)

La Constrained Delegation, ou délégation Kerberos contrainte, est un mécanisme qui permet à un service de demander des tickets de service au nom d'un utilisateur, mais uniquement pour des services spécifiquement autorisés. Introduite avec Windows Server 2003, elle a été conçue pour limiter les risques de la délégation non contrainte en restreignant les services cibles. La configuration se fait via l'attribut msDS-AllowedToDelegateTo sur le compte du service, qui liste les SPN autorisés. Techniquement, le service utilise l'extension Kerberos S4U2Proxy pour obtenir un TGS pour le service cible au nom de l'utilisateur. Si le service est aussi configuré avec le flag TRUSTED_TO_AUTH_FOR_DELEGATION, il peut utiliser S4U2Self pour obtenir d'abord un ticket de service à son propre nom pour n'importe quel utilisateur, même sans que celui-ci se soit authentifié. Cette combinaison S4U2Self + S4U2Proxy est appelée « protocol transition » et représente un risque significatif. Un attaquant compromettant un compte avec délégation contrainte et protocol transition peut usurper l'identité de n'importe quel utilisateur (sauf ceux du groupe Protected Users) auprès des services listés dans msDS-AllowedToDelegateTo. De plus, il est possible de modifier le service cible dans le ticket TGS sans invalider la signature, car le SPN n'est pas protégé cryptographiquement — une technique connue sous le nom de « service name modification ». La défense consiste à limiter le nombre de comptes avec délégation, à ajouter les comptes sensibles au groupe Protected Users, et à privilégier la délégation contrainte basée sur les ressources (RBCD) qui est configurée côté service cible plutôt que côté service source.

Credential Dumping

Le Credential Dumping désigne l'ensemble des techniques utilisées pour extraire des identifiants d'authentification (mots de passe en clair, hachages NTLM, tickets Kerberos, certificats) depuis un système compromis. Dans le contexte Active Directory, cette phase est cruciale pour le mouvement latéral et l'escalade de privilèges. Les sources principales de credentials incluent la mémoire du processus LSASS (Local Security Authority Subsystem Service), la base SAM locale, le fichier NTDS.dit sur les contrôleurs de domaine, le cache de credentials (DCC2), les secrets LSA, le coffre Windows Vault, et le DPAPI. L'outil historique pour cette tâche est Mimikatz, avec ses modules sekurlsa::logonpasswords (extraction depuis LSASS), lsadump::dcsync (attaque DCSync), et lsadump::sam (extraction SAM). D'autres outils comme secretsdump.py d'Impacket, nanodump, PPLdump et handlekatz offrent des alternatives avec différents niveaux de furtivité. Les protections contre le credential dumping ont considérablement évolué : Credential Guard isole LSASS dans un environnement virtualisé (VBS), RunAsPPL protège LSASS au niveau du noyau, et Windows Defender Credential Guard empêche l'extraction des hachages NTLM et des tickets TGT depuis la mémoire. Cependant, ces protections peuvent être contournées dans certaines conditions. La stratégie défensive complète inclut le déploiement de LAPS pour les mots de passe locaux, la réduction des sessions privilégiées sur les postes de travail via le tiering, la surveillance des accès au processus LSASS (Sysmon Event ID 10), et l'utilisation de Privileged Access Workstations.

Cross-Forest Trust (Approbation Inter-Forêts)

Un Cross-Forest Trust est une relation d'approbation entre deux forêts Active Directory distinctes, permettant aux utilisateurs d'une forêt d'accéder aux ressources de l'autre. Contrairement aux approbations intra-forêt (entre domaines d'une même forêt), les approbations inter-forêts sont transférées via un mécanisme de filtrage de SID (SID Filtering) qui empêche normalement les attaques par injection de SID History. Le trust peut être unidirectionnel ou bidirectionnel, et transitive ou non transitive. Au niveau Kerberos, un trust inter-forêts utilise une clé de confiance partagée (trust key) stockée dans un Trusted Domain Object (TDO). Les tickets de référence (referral tickets) sont émis par le DC de la forêt source avec cette clé, puis vérifiés par le DC de la forêt cible. Malgré le SID Filtering, plusieurs techniques d'attaque exploitent les trusts inter-forêts. Le Forest Trust Abuse peut inclure l'exploitation de comptes avec des SID privilégiés dans les deux forêts, l'abus de la délégation contrainte inter-forêts, l'exploitation de relations ADCS partagées, et l'attaque via des comptes de service avec des mots de passe identiques. La compromission de la clé de confiance (extraite via DCSync du TDO) permet de forger des tickets de référence inter-forêts. La sécurisation des trusts inter-forêts implique l'activation stricte du SID Filtering, la limitation de la sélective authentication, la rotation régulière des mots de passe de trust, l'audit des permissions accordées aux groupes de la forêt partenaire, et la surveillance des authentifications inter-forêts via les événements 4768 et 4769 avec un realm externe.

DC Shadow

DCShadow est une technique d'attaque avancée qui permet à un attaquant d'enregistrer temporairement une machine compromise comme contrôleur de domaine légitime dans Active Directory, afin d'injecter des modifications arbitraires dans l'annuaire via le mécanisme de réplication standard. Développée par Vincent Le Toux et Benjamin Delpy (créateur de Mimikatz), cette attaque exploite le protocole MS-DRSR (Directory Replication Service Remote) pour répliquer des changements malveillants vers les vrais contrôleurs de domaine. L'attaque se déroule en deux phases : d'abord, l'enregistrement du faux DC dans la partition de configuration (ajout d'un objet nTDSDSA et des enregistrements SRV DNS), puis la réplication des modifications souhaitées. Les modifications possibles incluent la modification d'attributs sensibles comme SIDHistory, primaryGroupID, msDS-KeyCredentialLink, ou les ACL de n'importe quel objet. DCShadow est particulièrement dangereuse car les modifications injectées via la réplication sont considérées comme légitimes par les autres DC et ne génèrent pas les mêmes événements d'audit qu'une modification LDAP standard. L'opération est éphémère : le faux DC est désenregistré immédiatement après la réplication, ne laissant que très peu de traces. La détection repose sur la surveillance des créations d'objets nTDSDSA (événement 5137), des modifications des enregistrements DNS SRV pour les DC, et des opérations de réplication provenant de sources inhabituelles (événement 4929). Le déploiement de solutions de surveillance de la réplication AD en temps réel est recommandé. Notre article sur DCShadow fournit une analyse technique complète.

DCSync

DCSync est une technique d'attaque qui simule le comportement d'un contrôleur de domaine pour demander la réplication des données de mots de passe depuis un DC légitime, en utilisant le protocole Microsoft Directory Replication Service Remote (MS-DRSR). Implémentée dans Mimikatz via le module lsadump::dcsync et dans secretsdump.py d'Impacket, cette attaque ne nécessite pas d'exécution de code sur le contrôleur de domaine lui-même. Il suffit qu'un attaquant dispose d'un compte ayant les droits de réplication sur l'objet domaine : spécifiquement DS-Replication-Get-Changes et DS-Replication-Get-Changes-All (et idéalement DS-Replication-Get-Changes-In-Filtered-Set). Ces droits sont normalement attribués aux groupes Domain Admins, Enterprise Admins et aux comptes de contrôleurs de domaine. L'attaquant envoie une requête GetNCChanges pour un utilisateur spécifique (ou pour l'ensemble du domaine) et reçoit en retour le hachage NTLM, les clés Kerberos et l'historique des mots de passe. La récupération du hachage du compte KRBTGT permet ensuite la création de Golden Tickets, offrant un accès persistant au domaine. DCSync est souvent la dernière étape avant la persistance totale. La détection s'appuie sur la surveillance des événements 4662 avec les GUID des propriétés de réplication, et sur l'identification des requêtes de réplication provenant de machines qui ne sont pas des contrôleurs de domaine. La prévention consiste à auditer strictement les comptes disposant des droits de réplication, à surveiller les modifications de ces permissions, et à déployer des solutions de détection de comportement anormal sur les protocoles de réplication. Consultez notre analyse détaillée du DCSync.

Default Domain Policy

La Default Domain Policy est la stratégie de groupe (GPO) créée automatiquement lors de l'installation du premier contrôleur de domaine. Liée à la racine du domaine avec un GUID fixe ({31B2F340-016D-11D2-945F-00C04FB984F9}), elle définit les paramètres de sécurité fondamentaux applicables à l'ensemble du domaine, notamment la politique de mots de passe (longueur minimale, complexité, historique, durée de vie), la politique de verrouillage de compte (seuil, durée, compteur de réinitialisation), et la politique Kerberos (durée de vie des tickets TGT et TGS, tolérance de synchronisation horaire). Du point de vue sécurité, la Default Domain Policy est un objet critique car elle établit le niveau de sécurité de base pour tous les comptes du domaine. Une politique de mots de passe trop permissive (par exemple, longueur minimale de 8 caractères sans complexité) facilite considérablement les attaques par force brute, le password spraying et le cracking hors ligne des hachages obtenus via Kerberoasting ou AS-REP Roasting. Il est important de noter que dans Active Directory, une seule politique de mots de passe peut être appliquée par domaine via les GPO — pour des politiques différenciées par groupe d'utilisateurs, il faut utiliser les Fine-Grained Password Policies (FGPP). Les paramètres Kerberos de la Default Domain Policy, comme la durée de vie maximale du TGT (10 heures par défaut) et la durée de vie maximale du renouvellement (7 jours par défaut), impactent directement la fenêtre d'exploitation des Golden et Silver Tickets. La modification non autorisée de cette GPO constitue un indicateur de compromission majeur qui doit être surveillé via les événements de modification de GPO dans le SYSVOL.

Delegation (Délégation Kerberos)

La délégation Kerberos est un mécanisme d'Active Directory qui permet à un service d'agir au nom d'un utilisateur pour accéder à d'autres ressources réseau. Ce concept est essentiel dans les architectures multi-tiers où un serveur frontal doit accéder à un serveur backend avec les permissions de l'utilisateur connecté. Il existe trois types de délégation : la délégation non contrainte (Unconstrained Delegation), la délégation contrainte (Constrained Delegation), et la délégation contrainte basée sur les ressources (Resource-Based Constrained Delegation, RBCD). La délégation non contrainte, le mécanisme le plus ancien et le plus dangereux, stocke le TGT complet de l'utilisateur en mémoire sur le serveur délégué, permettant au serveur d'accéder à n'importe quel service au nom de l'utilisateur. La délégation contrainte limite les services cibles via l'attribut msDS-AllowedToDelegateTo, tandis que la RBCD configure la délégation côté service cible via msDS-AllowedToActOnBehalfOfOtherIdentity. Chaque type présente des vecteurs d'attaque spécifiques. La délégation non contrainte combinée à une coercion permet de capturer le TGT d'un contrôleur de domaine. La délégation contrainte avec protocol transition permet l'usurpation d'identité. La RBCD peut être abusée si un attaquant peut modifier l'attribut du service cible. La mitigation globale inclut l'ajout des comptes sensibles au groupe Protected Users (qui empêche la délégation), la minimisation des comptes avec délégation, et la préférence pour la RBCD qui offre un contrôle plus granulaire. Le modèle de tiering recommande de ne jamais déléguer entre tiers différents.

DFS (Distributed File System)

Le Distributed File System est un service Windows qui permet de regrouper des partages de fichiers situés sur différents serveurs dans une arborescence logique unifiée. DFS existe en deux variantes : DFS Namespaces, qui fournit une vue logique consolidée des partages, et DFS Replication (DFS-R), qui assure la réplication efficace des fichiers entre serveurs. Dans Active Directory, DFS joue un rôle critique car le SYSVOL utilise DFS-R pour la réplication des stratégies de groupe et des scripts de connexion entre les contrôleurs de domaine. Du point de vue sécurité, DFS présente plusieurs surfaces d'attaque. L'interface RPC MS-DFSNM (Distributed File System Namespace Management) a été identifiée comme vecteur de coercion d'authentification, technique connue sous le nom de DFSCoerce. Cette attaque, similaire à PetitPotam, force un contrôleur de domaine à s'authentifier auprès d'une machine contrôlée par l'attaquant via un appel RPC au service DFS. L'authentification NTLM capturée peut ensuite être relayée vers AD CS ou d'autres services. La réplication DFS-R du SYSVOL est également un point de surveillance important : une modification malveillante des scripts de connexion ou des fichiers de GPO dans le SYSVOL serait répliquée automatiquement vers tous les DC. Les attaquants ayant compromis un DC peuvent modifier le contenu du SYSVOL pour déployer des malwares via les scripts de connexion ou les préférences de groupe. La sécurisation de DFS passe par la restriction des accès aux interfaces RPC DFS, la surveillance de l'intégrité du SYSVOL, l'activation de la signature SMB, et le monitoring des modifications de fichiers dans les partages DFS critiques.

DHCP Poisoning

Le DHCP Poisoning est une technique d'attaque réseau qui consiste à déployer un serveur DHCP malveillant (rogue DHCP) sur le réseau pour distribuer de fausses configurations réseau aux clients. Dans un environnement Active Directory, cette attaque permet de rediriger le trafic réseau en modifiant les paramètres DNS, la passerelle par défaut, ou les paramètres WPAD distribués aux postes de travail. L'attaquant peut ainsi intercepter les communications, capturer les authentifications NTLM, et réaliser des attaques de type man-in-the-middle. Les paramètres DHCP les plus exploités incluent l'option 6 (serveurs DNS) pour rediriger les résolutions de noms, l'option 3 (passerelle par défaut) pour intercepter tout le trafic, et l'option 252 (WPAD) pour configurer un proxy malveillant. Dans un domaine AD, le DHCP Poisoning est particulièrement efficace car les machines jointes au domaine font confiance aux réponses DHCP sans vérification. La combinaison DHCP Poisoning + DNS malveillant permet de rediriger les authentifications Kerberos et NTLM vers des services contrôlés par l'attaquant. Microsoft a introduit le DHCP Guard dans les commutateurs Hyper-V et la fonctionnalité d'autorisation DHCP dans AD qui empêche les serveurs DHCP non autorisés de répondre aux requêtes. Cependant, cette autorisation ne bloque pas techniquement les réponses des serveurs non autorisés — elle dépend de la conformité du serveur DHCP lui-même. Les contre-mesures réseau incluent le DHCP Snooping sur les commutateurs (qui filtre les réponses DHCP non autorisées au niveau 2), la segmentation VLAN, la surveillance des anomalies DHCP, et l'utilisation de configurations IP statiques pour les serveurs critiques.

Directory Services (Services d'Annuaire)

Les Directory Services, ou services d'annuaire, désignent l'ensemble des services qui stockent, organisent et fournissent l'accès aux informations sur les objets d'un réseau. Active Directory est l'implémentation Microsoft des services d'annuaire, basée sur le standard X.500 et utilisant le protocole LDAP comme interface d'accès principale. Les Directory Services dans AD englobent plusieurs composants : AD DS (Domain Services) pour l'authentification et l'autorisation, AD LDS (Lightweight Directory Services) pour les applications nécessitant un annuaire LDAP sans les contraintes d'un domaine complet, AD CS (Certificate Services) pour la PKI, AD FS (Federation Services) pour la fédération d'identité, et AD RMS (Rights Management Services) pour la protection des documents. L'architecture des services d'annuaire AD repose sur une base de données ESE (Extensible Storage Engine) stockée dans le fichier NTDS.dit, avec un schéma extensible définissant les classes d'objets et leurs attributs. La réplication multi-maîtres assure la cohérence des données entre les contrôleurs de domaine via le protocole DRS. Du point de vue sécurité, les services d'annuaire sont la cible prioritaire des attaquants car ils centralisent toutes les informations d'authentification et d'autorisation du domaine. La compromission des Directory Services équivaut au contrôle total de l'infrastructure. Les audits de sécurité AD doivent évaluer chaque composant : la sécurité du transport LDAP (signing et channel binding), la configuration des protocoles d'authentification (Kerberos vs NTLM), l'intégrité de la réplication, et les permissions sur les partitions d'annuaire. Le guide de durcissement AD couvre ces aspects en détail.

Distinguished Name (DN)

Le Distinguished Name est l'identifiant unique et non ambigu de chaque objet dans l'annuaire Active Directory, basé sur sa position dans l'arborescence hiérarchique. Un DN se compose d'une série de Relative Distinguished Names (RDN) séparés par des virgules, du plus spécifique au plus général. Par exemple, CN=Jean Dupont,OU=Utilisateurs,OU=Paris,DC=entreprise,DC=fr identifie l'utilisateur « Jean Dupont » dans l'OU « Utilisateurs » de l'OU « Paris » du domaine « entreprise.fr ». Les composants principaux du DN sont : CN (Common Name) pour le nom de l'objet, OU (Organizational Unit) pour les unités organisationnelles, DC (Domain Component) pour les composants du nom de domaine, et C (Country), O (Organization) dans certains schémas étendus. Du point de vue sécurité, la compréhension des DN est essentielle pour identifier les objets ciblés dans les requêtes LDAP, les logs d'audit, et les configurations de délégation. Les attaquants utilisent des requêtes LDAP basées sur les DN pour énumérer les objets du domaine, identifier les comptes privilégiés et cartographier l'arborescence. Les outils comme ldapsearch, PowerView et BloodHound construisent leurs requêtes en utilisant les DN comme points de base de recherche. Les ACL d'Active Directory sont également exprimées en termes de DN : une permission accordée sur un objet identifié par son DN peut être héritée par tous les objets enfants dans la hiérarchie. La connaissance des DN des conteneurs critiques (CN=AdminSDHolder,CN=System, CN=Policies,CN=System, CN=Certificate Templates,CN=Public Key Services) est fondamentale pour l'audit de sécurité et la détection des modifications non autorisées.

DNS Zone

Une DNS Zone dans le contexte Active Directory représente une portion de l'espace de noms DNS gérée comme une entité administrative. AD utilise le DNS intégré (AD-integrated DNS) où les zones DNS sont stockées dans des partitions de l'annuaire plutôt que dans des fichiers texte, bénéficiant ainsi de la réplication multi-maîtres, de la sécurité via les ACL AD, et des mises à jour dynamiques sécurisées. Les zones principales incluent la zone de lookup direct (nom vers IP), la zone de lookup inverse (IP vers nom), et les zones de stub. Active Directory crée automatiquement des zones pour les enregistrements SRV essentiels au fonctionnement du domaine : _ldap._tcp, _kerberos._tcp, _gc._tcp, et _kpasswd._tcp. Du point de vue sécurité, le DNS AD est une cible stratégique. L'empoisonnement DNS dans un domaine AD peut rediriger les authentifications Kerberos, permettre le détournement de sessions, ou faciliter les attaques de phishing interne. Les mises à jour dynamiques non sécurisées permettent à un attaquant d'enregistrer des enregistrements DNS arbitraires. Les attaques ADIDNS (Active Directory Integrated DNS) exploitent les permissions par défaut qui autorisent les utilisateurs authentifiés à créer de nouveaux enregistrements DNS. Un attaquant peut créer un enregistrement « wildcard » (*) qui résout toutes les requêtes non existantes vers son adresse IP, capturant ainsi les authentifications NTLM. La sécurisation des zones DNS AD comprend l'activation des mises à jour dynamiques sécurisées uniquement, la restriction des permissions de création d'enregistrements, la surveillance des modifications DNS, et la mise en place de DNSSEC lorsque possible. L'audit des enregistrements DNS suspects doit faire partie des contrôles réguliers de sécurité AD.

Domain Admin

Domain Admin est le groupe de sécurité le plus privilégié au sein d'un domaine Active Directory, accordant à ses membres un contrôle administratif total sur l'ensemble du domaine. Les membres du groupe Domain Admins disposent de droits d'administration complets sur tous les contrôleurs de domaine, tous les serveurs et postes de travail membres du domaine, et tous les objets de l'annuaire. Ce groupe est automatiquement ajouté au groupe local Administrators de chaque machine jointe au domaine via les stratégies de groupes restreintes. La compromission d'un seul compte Domain Admin représente la compromission totale du domaine. Les attaquants visent ce groupe comme objectif ultime car il permet d'exécuter un DCSync pour extraire tous les hachages, de créer un Golden Ticket pour un accès persistant, de modifier les GPO pour déployer des malwares, et de compromettre les forêts liées par des trusts. Les bonnes pratiques de sécurité recommandent de maintenir le nombre de Domain Admins au strict minimum (idéalement 2-3 comptes), d'utiliser des comptes séparés pour l'administration quotidienne (principe du moindre privilège), de ne jamais utiliser un compte Domain Admin pour se connecter à un poste de travail standard, et de placer ces comptes dans le groupe Protected Users. Le modèle de tiering classe les Domain Admins en Tier 0 et interdit leur utilisation sur les assets de Tier 1 ou Tier 2. La surveillance des ajouts au groupe Domain Admins (événement 4728) et des connexions de ses membres (événements 4624, 4672) est essentielle. Les outils comme BloodHound permettent d'identifier les chemins d'attaque menant à ce groupe.

Domain Controller (Contrôleur de Domaine)

Un Domain Controller (DC) est un serveur Windows qui exécute le rôle Active Directory Domain Services et qui héberge une copie de la base de données de l'annuaire (NTDS.dit). Les contrôleurs de domaine sont responsables de l'authentification des utilisateurs et des ordinateurs, de la réplication de l'annuaire, de l'application des stratégies de groupe, de la résolution DNS intégrée, et de l'émission des tickets Kerberos via le KDC (Key Distribution Center). Chaque DC héberge une copie complète et inscriptible de la partition de domaine, et certains DC détiennent des rôles FSMO (Flexible Single Master Operations) spécifiques : Schema Master, Domain Naming Master, PDC Emulator, RID Master et Infrastructure Master. Du point de vue sécurité, les contrôleurs de domaine sont les actifs les plus critiques de l'infrastructure — leur compromission équivaut à la compromission totale du domaine. Les attaquants ciblent les DC pour extraire le fichier NTDS.dit (contenant tous les hachages), exécuter un DCSync, ou injecter des modifications via DCShadow. La sécurisation des DC exige une isolation réseau stricte, l'interdiction d'installer des applications tierces, la restriction des connexions interactives aux seuls comptes Tier 0, l'activation de Credential Guard et RunAsPPL, la surveillance de tous les accès physiques et logiques, et des sauvegardes régulières protégées hors ligne. Le modèle de tiering place les DC en Tier 0 avec des contrôles d'accès maximaux. Les événements critiques à surveiller incluent les connexions (4624), les modifications de réplication (4929), et les accès au NTDS.dit.

Domain Trust (Approbation de Domaine)

Un Domain Trust est une relation de confiance établie entre deux domaines Active Directory qui permet aux utilisateurs d'un domaine d'accéder aux ressources de l'autre. Les trusts constituent le fondement de l'interopérabilité entre domaines et forêts AD. Il existe plusieurs types de trusts : parent-child (automatique et transitif entre domaines de la même arborescence), tree-root (entre les racines d'arbres dans la même forêt), forest (entre deux forêts distinctes), external (entre un domaine AD et un domaine NT 4.0 ou un domaine d'une autre forêt, non transitif), et realm (vers un domaine Kerberos non-Windows). Les trusts peuvent être unidirectionnels ou bidirectionnels, et transitifs ou non transitifs. Techniquement, un trust est matérialisé par un Trusted Domain Object (TDO) dans l'annuaire, contenant la clé de confiance partagée utilisée pour chiffrer les tickets de référence Kerberos. Du point de vue sécurité, les trusts étendent la surface d'attaque en créant des ponts entre environnements. Un attaquant qui compromet un domaine approuvé peut exploiter le trust pour pivoter vers le domaine cible. Les techniques incluent l'extraction de la trust key via DCSync pour forger des tickets de référence inter-domaines, l'exploitation de SID History si le SID Filtering n'est pas activé, et l'abus de comptes disposant de permissions dans les deux domaines. La sécurisation des trusts requiert l'activation du SID Filtering, l'utilisation de Selective Authentication pour limiter les comptes autorisés, l'audit régulier des permissions accordées aux principaux de sécurité étrangers, et la surveillance des authentifications inter-domaines. Notre article sur le Forest Trust Abuse approfondit ces techniques.

DPAPI (Data Protection API)

DPAPI (Data Protection Application Programming Interface) est l'API de protection des données de Windows qui fournit un mécanisme de chiffrement symétrique transparent pour les applications. DPAPI est utilisée par le système d'exploitation et de nombreuses applications pour protéger des données sensibles telles que les mots de passe enregistrés dans les navigateurs (Chrome, Edge), les credentials sauvegardés dans le Credential Manager Windows, les clés de chiffrement EFS, les mots de passe de connexion Wi-Fi, et les cookies de session. Le mécanisme repose sur une hiérarchie de clés : chaque utilisateur dispose d'une Master Key protégée par son mot de passe, elle-même utilisée pour chiffrer les données via des Data Protection Blobs. Les Master Keys sont stockées dans %APPDATA%\Microsoft\Protect\{SID} et sont sauvegardées sur les contrôleurs de domaine via un mécanisme de backup key (clé de sauvegarde de domaine). Du point de vue sécurité offensive, DPAPI est une mine d'or pour les attaquants. En extrayant les Master Keys et les blobs chiffrés, un attaquant peut déchiffrer tous les secrets protégés par DPAPI. La clé de sauvegarde de domaine (DPAPI Domain Backup Key), stockée dans l'objet CN=BCKUPKEY sur les DC, permet de déchiffrer les Master Keys de tous les utilisateurs du domaine — c'est pourquoi son extraction via DCSync ou l'accès aux DC est une cible prioritaire. L'outil Mimikatz offre des modules dédiés (dpapi::masterkey, dpapi::chrome, dpapi::cred) pour l'exploitation de DPAPI. Les outils comme SharpDPAPI et DonPAPI automatisent la collecte et le déchiffrement à grande échelle. La protection passe par Credential Guard (qui isole les clés DPAPI dans un environnement virtualisé), la rotation régulière de la Domain Backup Key, et la surveillance des accès aux Master Keys.

DSRM (Directory Services Restore Mode)

Le Directory Services Restore Mode est un mode de démarrage spécial des contrôleurs de domaine Windows qui permet la restauration de la base de données Active Directory à partir d'une sauvegarde. Le DSRM est accessible au démarrage du serveur (touche F8) et utilise un compte administrateur local spécifique dont le mot de passe est défini lors de la promotion du serveur en contrôleur de domaine. Ce mot de passe DSRM est stocké localement dans la base SAM du DC, indépendamment de l'annuaire Active Directory. Du point de vue sécurité, le compte DSRM représente un vecteur de persistance redoutable. Depuis Windows Server 2008, une clé de registre (DsrmAdminLogonBehavior) contrôle quand le compte DSRM peut être utilisé pour se connecter. Lorsque cette valeur est positionnée à 2, le compte DSRM peut être utilisé pour une connexion réseau même lorsque le DC fonctionne normalement, offrant un accès administrateur local au DC indépendant d'Active Directory. Un attaquant ayant compromis un DC peut extraire le hachage NTLM du compte DSRM depuis la base SAM, modifier la clé de registre pour autoriser la connexion réseau, puis utiliser le Pass-the-Hash pour accéder au DC même si tous les mots de passe AD ont été réinitialisés. Cette technique est particulièrement insidieuse comme porte dérobée car le mot de passe DSRM est rarement changé et échappe souvent aux audits de sécurité standard. La mitigation consiste à changer régulièrement le mot de passe DSRM avec ntdsutil "set dsrm password", à surveiller la clé de registre DsrmAdminLogonBehavior, à auditer les connexions réseau utilisant le compte DSRM, et à inclure le hachage DSRM dans les procédures de rotation de credentials post-incident.

Entra ID (anciennement Azure AD)

Entra ID, anciennement connu sous le nom d'Azure Active Directory, est le service de gestion des identités et des accès cloud de Microsoft. Contrairement à Active Directory on-premises, Entra ID est un service multi-tenant basé sur des protocoles modernes (OAuth 2.0, OpenID Connect, SAML 2.0) et conçu pour les scénarios cloud et hybrides. Entra ID gère l'authentification pour Microsoft 365, Azure, et des milliers d'applications SaaS tierces. Dans les environnements hybrides, Entra ID est synchronisé avec Active Directory on-premises via Entra Connect (anciennement Azure AD Connect), créant un pont entre les deux mondes d'identité. Du point de vue sécurité, Entra ID introduit à la fois de nouvelles protections et de nouvelles surfaces d'attaque. Les fonctionnalités comme le Conditional Access, la Protection d'Identité (Identity Protection), et le Privileged Identity Management (PIM) offrent des contrôles avancés absents de l'AD on-premises. Cependant, la synchronisation hybride crée des risques spécifiques : la compromission d'Entra Connect permet de réinitialiser les mots de passe cloud, et inversement, la compromission cloud peut impacter l'environnement on-premises via le Password Writeback. Les attaquants ciblent les tokens OAuth/JWT, les applications avec des permissions excessives (Graph API), les Service Principals, et les configurations de synchronisation. L'incident SyncJacking a démontré les risques liés à Entra Connect. Microsoft pousse la migration des fonctionnalités vers Entra ID, notamment la fin des Service Principals legacy, renforçant la nécessité de sécuriser cet environnement. Le Conditional Access, les politiques de mars 2026, et la gestion des sessions via MFA et révocation sont des éléments clés de la sécurité Entra ID.

ESC1-ESC15 (Vulnérabilités AD CS)

ESC1 à ESC15 désignent une série de vulnérabilités et mauvaises configurations identifiées dans Active Directory Certificate Services, initialement documentées par Will Schroeder et Lee Christensen de SpecterOps. Chaque ESC (Escalation) représente un scénario d'abus distinct. ESC1 exploite les modèles de certificats permettant au demandeur de spécifier un SAN arbitraire. ESC2 concerne les modèles avec l'EKU « Any Purpose » ou sans EKU. ESC3 abuse de l'EKU Certificate Request Agent pour demander des certificats au nom d'autres utilisateurs. ESC4 cible les permissions d'écriture excessives sur les modèles de certificats. ESC5 exploite les permissions sur les objets PKI (CA, NTAuthCertificates). ESC6 concerne le flag EDITF_ATTRIBUTESUBJECTALTNAME2 sur l'autorité de certification. ESC7 abuse des permissions de gestion de la CA (ManageCA, ManageCertificates). ESC8 exploite l'inscription web (HTTP enrollment) via NTLM Relay. ESC9 et ESC10 concernent les mappings de certificats (CT_FLAG_NO_SECURITY_EXTENSION et weak mappings). ESC11 exploite le relais vers l'interface RPC de la CA (ICPR). ESC12 abuse de la clé CA stockée dans un shell PKCS#12. ESC13 concerne les OID policies liées à des groupes (issuance policies). ESC14 exploite les weak explicit mappings via altSecurityIdentities. ESC15, la plus récente, cible les modèles avec un schema version 1 et l'application policy editable. La remédiation globale nécessite un audit exhaustif de chaque composant AD CS, détaillé dans notre bilan complet ESC1-ESC15. L'outil Certipy automatise la détection de ces vulnérabilités avec la commande find -vulnerable.

FGPP (Fine-Grained Password Policy)

Les Fine-Grained Password Policies (FGPP), introduites avec Windows Server 2008, permettent d'appliquer des politiques de mots de passe différentes à des groupes d'utilisateurs spécifiques au sein d'un même domaine. Avant les FGPP, la Default Domain Policy imposait une politique de mots de passe unique pour tout le domaine. Les FGPP sont implémentées via des objets Password Settings Objects (PSO) stockés dans CN=Password Settings Container,CN=System,DC=domain,DC=com. Chaque PSO définit les paramètres suivants : longueur minimale du mot de passe, complexité requise, historique de mots de passe, durée de vie minimale et maximale, seuil et durée de verrouillage de compte, et réversibilité du chiffrement. Les PSO sont liés directement à des groupes de sécurité globaux ou à des utilisateurs individuels. Lorsque plusieurs PSO s'appliquent à un même utilisateur, celui avec la valeur de précédence (msDS-PasswordSettingsPrecedence) la plus basse est prioritaire. Du point de vue sécurité, les FGPP sont essentielles pour appliquer le principe de défense en profondeur : les comptes de service peuvent avoir des mots de passe de 25+ caractères, les comptes administrateurs de 16+ caractères avec rotation fréquente, tandis que les comptes utilisateurs standard peuvent avoir des exigences plus souples. L'absence de FGPP pour les comptes privilégiés est un finding fréquent lors des audits de sécurité AD. Les attaquants vérifient les PSO existantes car elles révèlent les politiques de mots de passe par groupe, ce qui aide à calibrer les attaques de password spraying. L'outil PowerShell Get-ADFineGrainedPasswordPolicy et les requêtes LDAP ciblant la classe msDS-PasswordSettings permettent d'énumérer les PSO. La mise en oeuvre de FGPP doit faire partie intégrante du durcissement AD.

Forest (Forêt Active Directory)

Une forêt Active Directory est le conteneur de sécurité de plus haut niveau dans l'architecture AD, englobant un ou plusieurs domaines partageant un schéma commun, une partition de configuration commune, et un catalogue global. La forêt constitue la frontière de sécurité ultime d'Active Directory : les administrateurs d'un domaine au sein d'une forêt peuvent potentiellement compromettre l'ensemble de la forêt, car il n'existe pas d'isolation de sécurité absolue entre les domaines d'une même forêt. Le premier domaine créé dans une forêt est appelé Forest Root Domain et héberge les groupes Enterprise Admins et Schema Admins. La forêt maintient un schéma unique (définissant toutes les classes d'objets et attributs) et une partition de configuration partagée (contenant la topologie de réplication, les sites, les définitions de trusts). Le catalogue global, accessible via le port 3268/3269, agrège un sous-ensemble d'attributs de tous les objets de tous les domaines de la forêt. Du point de vue sécurité, la compromission d'un domaine enfant peut mener à la compromission de la forêt entière via l'exploitation du trust parent-child (qui est transitif et bidirectionnel). Les techniques incluent la forge de tickets inter-domaines avec le SID de Enterprise Admins (injection SID dans le PAC), l'exploitation de la clé de trust entre domaines parent et enfant, et l'abus de la réplication entre domaines de la même forêt. C'est pourquoi Microsoft recommande de traiter chaque forêt — et non chaque domaine — comme la frontière de sécurité. Les organisations nécessitant une isolation réelle doivent utiliser des forêts distinctes avec des trusts inter-forêts correctement configurés.

Forest Trust (Approbation de Forêt)

Un Forest Trust est une relation de confiance spécifique établie entre les domaines racines de deux forêts Active Directory distinctes. Introduit avec Windows Server 2003, le Forest Trust est par défaut transitive au sein de chaque forêt mais non transitive entre forêts : si la forêt A fait confiance à la forêt B et la forêt B à la forêt C, la forêt A ne fait pas automatiquement confiance à la forêt C. Le Forest Trust utilise le SID Filtering par défaut, une protection qui empêche les utilisateurs d'une forêt d'utiliser des SID de l'autre forêt dans leurs tickets Kerberos. Ce mécanisme bloque les attaques d'injection de SID History inter-forêts. Cependant, le Forest Trust peut être configuré en mode Selective Authentication, où seuls les utilisateurs explicitement autorisés dans la forêt cible peuvent accéder aux ressources. Les Forest Trusts supportent également le Name Suffix Routing, qui contrôle quels suffixes de noms (DNS, UPN) sont routés via le trust. Du point de vue attaque, même avec le SID Filtering activé, des techniques d'exploitation existent : l'abus de comptes avec des permissions dans les deux forêts, l'exploitation de la délégation Kerberos inter-forêts, et l'attaque via AD CS si les autorités de certification sont partagées. La clé de confiance du Forest Trust peut être extraite via DCSync et utilisée pour forger des tickets de référence. Un attaquant dans la forêt source peut ainsi créer un ticket avec un PAC valide pour accéder aux ressources de la forêt cible. La sécurisation recommande l'activation de Selective Authentication, l'audit régulier des permissions accordées aux Foreign Security Principals, la surveillance des authentifications inter-forêts, et la révision du Name Suffix Routing pour détecter les conflits. Consultez notre article sur le Forest Trust Abuse.

GMSA (Group Managed Service Account)

Un Group Managed Service Account (gMSA) est un type de compte de service Active Directory dont le mot de passe est automatiquement géré par les contrôleurs de domaine. Introduit avec Windows Server 2012, le gMSA résout le problème historique de la gestion des mots de passe des comptes de service en automatisant leur rotation. Le mot de passe d'un gMSA est de 240 caractères aléatoires, renouvelé automatiquement tous les 30 jours par défaut, et distribué de manière sécurisée aux serveurs autorisés via l'attribut msDS-GroupMSAMembership. Les serveurs listés dans cet attribut peuvent récupérer le mot de passe actuel (et le précédent pour assurer la continuité) auprès du KDC. Du point de vue sécurité, les gMSA représentent une amélioration significative par rapport aux comptes de service classiques. Ils éliminent le risque de mots de passe faibles, obsolètes ou partagés. Cependant, les gMSA ne sont pas exempts de risques. Si un attaquant compromet un serveur autorisé à lire le mot de passe du gMSA, il peut calculer le hachage NTLM du gMSA et l'utiliser pour des attaques Pass-the-Hash ou Silver Ticket. L'outil gMSADumper automatise cette extraction. De plus, si les permissions msDS-GroupMSAMembership sont mal configurées (trop de serveurs autorisés), la surface d'attaque augmente. Les gMSA disposant de privilèges élevés (comme les comptes utilisés pour l'administration de bases de données ou la sauvegarde) doivent être traités avec la même rigueur que les comptes Domain Admin. La migration des comptes de service classiques vers des gMSA est une recommandation forte du durcissement AD, mais elle doit s'accompagner d'une revue des permissions d'accès et d'une limitation stricte des serveurs autorisés.

Golden Certificate

Un Golden Certificate est un certificat forgé à partir de la clé privée d'une autorité de certification (CA) Active Directory, permettant à un attaquant de générer des certificats valides pour n'importe quel utilisateur du domaine. Lorsqu'un attaquant compromet un serveur hébergeant AD CS et extrait la clé privée de la CA (stockée dans le certificat store local ou dans un fichier PFX), il obtient la capacité de signer des certificats arbitraires. Ces certificats peuvent ensuite être utilisés pour l'authentification Kerberos PKINIT, permettant d'obtenir un TGT pour n'importe quel utilisateur, y compris les Domain Admins et le compte KRBTGT. L'impact est comparable à celui du Golden Ticket, mais avec des caractéristiques distinctes. La durée de validité d'un Golden Certificate est celle de la CA elle-même (généralement 5 à 20 ans), offrant une persistance à très long terme. De plus, la révocation d'un certificat dans AD est complexe car le contrôle de révocation (CRL/OCSP) n'est pas systématiquement vérifié par tous les services. L'extraction de la clé privée de la CA peut se faire via Certipy avec la commande ca -backup, SharpDPAPI pour déchiffrer la clé protégée par DPAPI, ou simplement en exportant le certificat depuis la console MMC si l'attaquant a un accès administrateur au serveur CA. La remédiation après une compromission de la clé CA nécessite la reconstruction complète de l'infrastructure PKI : révocation de tous les certificats émis, génération d'une nouvelle paire de clés CA, et réémission de tous les certificats. Cette opération est si impactante qu'elle constitue un argument majeur pour la protection renforcée des serveurs CA, idéalement avec un HSM et au niveau Tier 0 dans le modèle de tiering.

Golden Ticket

Le Golden Ticket est une technique de persistance dans Active Directory qui consiste à forger un Ticket Granting Ticket (TGT) Kerberos en utilisant le hachage NTLM du compte KRBTGT. Ce TGT forgé est indistinguable d'un TGT légitime émis par le KDC et permet à l'attaquant de s'authentifier en tant que n'importe quel utilisateur du domaine, y compris des utilisateurs inexistants ou avec des appartenances à des groupes arbitraires. Le Golden Ticket est créé à l'aide d'outils comme Mimikatz (kerberos::golden) ou Impacket (ticketer.py), en fournissant le hachage NTLM du KRBTGT, le SID du domaine, et les informations de l'utilisateur cible. La durée de vie du ticket peut être définie arbitrairement, allant jusqu'à 10 ans. L'impact est dévastateur : tant que le mot de passe du KRBTGT n'est pas changé deux fois (car l'historique de mot de passe conserve une entrée), le Golden Ticket reste valide. La détection est difficile car le TGT est cryptographiquement valide. Les indicateurs incluent les tickets avec des durées de vie anormales, des tickets émis pour des utilisateurs inexistants, ou des PAC contenant des appartenances à des groupes incohérentes. Les événements 4769 avec un type de chiffrement RC4 (alors que le domaine utilise AES) peuvent signaler un Golden Ticket ancien. La défense primaire est le changement régulier du mot de passe du KRBTGT (au moins deux fois, avec un délai de 12-24 heures entre les deux changements pour permettre la réplication). Le déploiement de mécanismes comme PAC Validation (validation du PAC auprès du DC pour chaque demande de TGS) renforce la détection. Notre guide sur le Golden Ticket détaille les aspects techniques et les contre-mesures.

GPO (Group Policy Object)

Un Group Policy Object est un objet Active Directory qui contient un ensemble de paramètres de configuration applicables aux utilisateurs et ordinateurs d'un domaine. Les GPO constituent le mécanisme principal de gestion centralisée de la configuration dans les environnements Windows, permettant de contrôler les paramètres de sécurité, les installations logicielles, les scripts de démarrage/connexion, les restrictions d'interface, et des milliers d'autres paramètres. Chaque GPO est composé de deux parties : un objet dans l'annuaire AD (contenant les métadonnées, les liens, le versioning) et un répertoire dans le SYSVOL du contrôleur de domaine (contenant les fichiers de paramètres proprement dits). Les GPO sont liées aux sites AD, aux domaines ou aux unités organisationnelles (OU), et leur application suit un ordre de précédence : Local, Site, Domain, OU (LSDOU). Du point de vue sécurité, les GPO représentent à la fois un outil de durcissement puissant et un vecteur d'attaque potentiel. Le GPO Abuse consiste à modifier une GPO légitime ou à en créer une nouvelle pour déployer du code malveillant sur les machines ciblées. Un attaquant disposant du droit de modifier une GPO liée à des serveurs peut déployer un script de démarrage malveillant, créer une tâche planifiée, modifier les groupes locaux, ou installer un service backdoor. Les permissions à surveiller incluent GPC-Machine-Extension-Names, GPC-User-Extension-Names, et les droits d'écriture sur les fichiers SYSVOL. Les outils comme BloodHound cartographient les liens GPO et les permissions d'écriture. Notre article sur le GPO Abuse et le guide de sécurisation par GPO couvrent ces aspects en profondeur.

Group Policy (Stratégie de Groupe)

La Group Policy, ou stratégie de groupe, est le framework de gestion de configuration centralisée d'Active Directory qui permet aux administrateurs de définir et d'appliquer des paramètres à l'échelle du domaine. Ce framework s'appuie sur les GPO mais englobe un écosystème plus large incluant les Administrative Templates (ADMX/ADML), les Preferences de stratégie de groupe, les extensions côté client (CSE), et le mécanisme de traitement des stratégies. Les stratégies de groupe se déclinent en deux catégories principales : les paramètres de configuration ordinateur (Computer Configuration), appliqués au démarrage de la machine et rafraîchis toutes les 90 minutes (+/- 30 minutes d'offset aléatoire), et les paramètres de configuration utilisateur (User Configuration), appliqués à la connexion de l'utilisateur et rafraîchis selon le même intervalle. Les stratégies de sécurité (Security Settings) incluent les politiques de comptes, les politiques locales (audit, droits utilisateurs, options de sécurité), les pare-feu Windows, les politiques de restriction logicielle (AppLocker/SRP), et les politiques de réseau sans fil. Du point de vue sécurité, les stratégies de groupe sont l'outil principal de durcissement AD. Les paramètres critiques incluent la restriction des sessions interactives sur les DC, la configuration des groupes restreints pour contrôler l'appartenance aux groupes locaux, la désactivation de NTLM (via les politiques de sécurité réseau), l'activation de l'audit avancé, la configuration de LSASS en PPL, et le déploiement de Windows Defender Credential Guard. Les Preferences de stratégie de groupe ont historiquement posé un risque de sécurité majeur avec le stockage de mots de passe chiffrés en GPP (Group Policy Preferences), dont la clé AES était publiquement connue — un finding classique dans les pentests AD.

Honey Account (Compte Leurre)

Un Honey Account est un compte Active Directory délibérément configuré comme leurre pour détecter les activités de reconnaissance et d'attaque dans l'environnement AD. Cette technique de deception (leurrage) repose sur le principe que certaines actions des attaquants — comme l'énumération de comptes privilégiés, le Kerberoasting, ou les tentatives de connexion avec des credentials volés — peuvent être détectées en surveillant l'activité sur des comptes spécialement conçus. Les types de honey accounts incluent les HoneyUsers (comptes utilisateurs avec des noms attractifs comme « svc_backup_admin » ou « sa_sql_prod »), les HoneyTokens (comptes dont toute activité d'authentification est suspecte), et les HoneyHash (hachages NTLM déposés délibérément en mémoire sur des machines stratégiques). Un honey account efficace doit paraître légitime : un nom de compte réaliste, un historique de modification cohérent, une appartenance à des groupes plausible, et un SPN si l'objectif est de détecter le Kerberoasting. L'attribut logonCount à 0 et un lastLogon absent sont des indicateurs que les attaquants sophistiqués peuvent utiliser pour identifier les leurres. Pour éviter cette détection, il convient de peupler artificiellement ces attributs. La surveillance se concentre sur les événements 4625 (échec de connexion), 4768/4769 (demandes Kerberos), et 4662 (accès aux propriétés de l'objet). Certaines solutions dédiées comme Microsoft ATA/ATA Advanced Threat Analytics, ou des produits tiers de deception, intègrent nativement la gestion des honey accounts. L'implémentation de comptes leurres fait partie des recommandations avancées du durcissement AD et constitue une couche de détection complémentaire aux solutions SIEM et EDR traditionnelles.

Kerberoasting

Le Kerberoasting est une technique d'attaque qui exploite le mécanisme de tickets de service Kerberos pour extraire les hachages de mots de passe des comptes de service Active Directory. Le principe est simple : tout utilisateur authentifié du domaine peut demander un ticket de service (TGS) pour n'importe quel service enregistré via un SPN (Service Principal Name). La partie chiffrée du TGS est chiffrée avec le hachage NTLM du compte de service, permettant une attaque par force brute hors ligne. L'attaquant n'a besoin que d'un compte de domaine valide — aucun privilège particulier n'est requis. Les outils principaux incluent Rubeus avec la commande kerberoast, GetUserSPNs.py d'Impacket, et le module PowerView Invoke-Kerberoast. Les hachages récupérés sont soumis à hashcat (mode 13100 pour RC4, 19700 pour AES) ou John the Ripper. La variante « targeted Kerberoasting » consiste à ajouter un SPN à un compte sans SPN existant (si l'attaquant dispose de permissions d'écriture) pour le rendre kerberoastable. La furtivité est un avantage majeur du Kerberoasting : les demandes de TGS sont des opérations légitimes qui génèrent des volumes importants de logs. La défense multi-couches comprend l'utilisation de gMSA avec des mots de passe de 240 caractères, l'imposition de mots de passe longs (25+ caractères) pour les comptes de service classiques, la surveillance des demandes TGS massives ou avec chiffrement RC4 (événement 4769), la préférence pour le chiffrement AES (qui est plus résistant au cracking), et la réduction du nombre de comptes avec des SPN. Notre guide complet du Kerberoasting détaille toutes les variantes et contre-mesures.

Kerberos

Kerberos est le protocole d'authentification principal d'Active Directory, basé sur un système de tickets et de clés symétriques. Conçu au MIT et nommé d'après le chien à trois têtes de la mythologie grecque, Kerberos v5 (RFC 4120) fonctionne avec un tiers de confiance central : le Key Distribution Center (KDC), hébergé sur chaque contrôleur de domaine. Le flux d'authentification Kerberos se déroule en plusieurs étapes : l'Authentication Service Exchange (AS-REQ/AS-REP) où l'utilisateur obtient un TGT en s'authentifiant auprès du KDC, puis le Ticket-Granting Service Exchange (TGS-REQ/TGS-REP) où le TGT est présenté pour obtenir un ticket de service spécifique, et enfin l'Application Exchange où le ticket de service est présenté au serveur cible. Kerberos utilise des clés dérivées des mots de passe des utilisateurs et des services, avec le support de plusieurs algorithmes de chiffrement : DES (obsolète), RC4-HMAC (basé sur le hachage NTLM), AES128-CTS-HMAC-SHA1, et AES256-CTS-HMAC-SHA1. Le Privilege Attribute Certificate (PAC) est une extension Microsoft ajoutée aux tickets Kerberos contenant les informations d'autorisation de l'utilisateur (SID, appartenances aux groupes). Du point de vue sécurité, Kerberos est au coeur de nombreuses attaques AD : le Golden Ticket forge un TGT, le Silver Ticket forge un TGS, le Kerberoasting casse les tickets de service, l'Overpass-the-Hash convertit un hachage en ticket, et les attaques de délégation exploitent les extensions S4U. La sécurisation passe par la désactivation de RC4, le déploiement des AES, la validation du PAC, et la surveillance des anomalies Kerberos.

KDC (Key Distribution Center)

Le Key Distribution Center est le composant central du protocole Kerberos, responsable de l'émission des tickets d'authentification et de service dans Active Directory. Chaque contrôleur de domaine exécute un service KDC qui comprend deux sous-services : l'Authentication Service (AS), qui vérifie l'identité des utilisateurs et émet les Ticket Granting Tickets (TGT), et le Ticket Granting Service (TGS), qui émet les tickets de service à partir d'un TGT valide. Le KDC utilise la base de données Active Directory (NTDS.dit) pour stocker les clés de chiffrement de tous les comptes du domaine. Lorsqu'un utilisateur s'authentifie, le KDC vérifie ses credentials contre la base, crée un TGT chiffré avec la clé du compte KRBTGT, et le renvoie au client. Pour les demandes de service, le KDC déchiffre le TGT avec la clé KRBTGT, vérifie sa validité, puis émet un ticket de service chiffré avec la clé du compte de service cible. Du point de vue sécurité, le KDC est l'une des cibles les plus critiques car il détient toutes les clés du domaine. La compromission du KDC (via la compromission d'un DC) donne accès à l'intégralité des secrets d'authentification. Les attaques ciblant le KDC incluent le Golden Ticket (forge de TGT via la clé KRBTGT), les attaques de relais vers le KDC, et l'exploitation des extensions S4U pour la délégation. Le KDC maintient également le cache des tickets et gère les mécanismes de pré-authentification, de renouvellement, et de validation. La protection du KDC passe par la sécurisation des contrôleurs de domaine, la rotation régulière de la clé KRBTGT, la surveillance des événements d'authentification (4768, 4769, 4771), et le déploiement de mécanismes de détection d'anomalies comme les tickets avec des durées de vie ou des types de chiffrement inhabituels.

KRBTGT

KRBTGT est le compte de service spécial d'Active Directory utilisé par le Key Distribution Center pour chiffrer et signer tous les Ticket Granting Tickets (TGT) du domaine. Ce compte est créé automatiquement lors de l'installation du domaine et est désactivé par défaut pour les connexions interactives — il n'est utilisé que par le service KDC interne. Le hachage NTLM du mot de passe KRBTGT constitue la « clé maîtresse » de l'authentification Kerberos dans le domaine. Toute personne connaissant cette clé peut forger des TGT arbitraires, c'est-à-dire créer des Golden Tickets. Le mot de passe du KRBTGT n'est jamais changé automatiquement — il conserve le mot de passe défini lors de la création du domaine à moins d'être manuellement réinitialisé. L'historique de mot de passe du KRBTGT conserve une entrée (le mot de passe actuel et le précédent), ce qui signifie qu'un changement unique du mot de passe ne suffit pas à invalider les Golden Tickets forgés avec l'ancien hachage. Il faut deux changements successifs pour éliminer complètement un Golden Ticket. Cependant, un double changement immédiat peut causer des perturbations car les TGT légitimes en circulation deviendraient invalides. La recommandation est d'effectuer un premier changement, d'attendre au moins la durée de vie maximale d'un TGT (10 heures par défaut) plus le temps de réplication, puis d'effectuer le second changement. Microsoft fournit le script New-KrbtgtKeys.ps1 pour automatiser cette opération. Dans les environnements hybrides, un KRBTGT distinct existe pour les Read-Only Domain Controllers (RODC), nommé krbtgt_XXXXX. La surveillance des accès au compte KRBTGT (via les requêtes de réplication DCSync ciblant ce compte) et de la modification de son mot de passe fait partie des contrôles critiques.

LAPS (Local Administrator Password Solution)

LAPS est une solution Microsoft qui automatise la gestion des mots de passe du compte administrateur local sur les machines jointes au domaine. LAPS génère un mot de passe unique, aléatoire et complexe pour chaque machine, le stocke de manière sécurisée dans un attribut d'Active Directory, et le renouvelle automatiquement selon un calendrier configurable. La version originale de LAPS (Legacy LAPS) stockait le mot de passe en clair dans l'attribut ms-Mcs-AdmPwd de l'objet ordinateur AD, avec un contrôle d'accès via les ACL pour limiter qui pouvait le lire. Windows LAPS (la version moderne intégrée à Windows 11 et Server 2022+) améliore considérablement la sécurité en ajoutant le chiffrement du mot de passe (stocké dans msLAPS-EncryptedPassword), le support des comptes nommés (pas uniquement le RID 500), l'historique des mots de passe, et le backup vers Entra ID. Du point de vue sécurité, LAPS est une mesure défensive fondamentale contre le mouvement latéral. Sans LAPS, les mots de passe administrateur local sont souvent identiques sur toutes les machines (déployés par image ou GPO), permettant un Pass-the-Hash systématique après la compromission d'une seule machine. Cependant, LAPS présente aussi des risques : les comptes ayant le droit de lire l'attribut LAPS peuvent récupérer les mots de passe de toutes les machines ciblées. Les outils comme LAPSDumper, CrackMapExec (--laps), et NetExec automatisent cette extraction. La permission de lecture LAPS doit donc être strictement contrôlée et limitée aux équipes d'administration Tier 1. Notre guide complet LAPS couvre le déploiement et la sécurisation.

LDAP (Lightweight Directory Access Protocol)

LDAP est le protocole standard utilisé pour interroger et modifier les données stockées dans l'annuaire Active Directory. Basé sur le modèle X.500, LDAP fonctionne sur le port 389 (LDAP) et 636 (LDAPS avec TLS). Active Directory implémente LDAP v3 (RFC 4511) comme interface principale d'accès à l'annuaire, permettant aux applications, scripts et outils d'administration de rechercher, créer, modifier et supprimer des objets. Les opérations LDAP incluent Bind (authentification), Search (recherche avec filtres), Add, Delete, Modify, et ModDN (renommer/déplacer). Les requêtes LDAP utilisent une syntaxe de filtre spécifique : par exemple, (&(objectCategory=user)(adminCount=1)) retourne tous les utilisateurs protégés par AdminSDHolder. Du point de vue sécurité, LDAP est à la fois un outil d'administration essentiel et un vecteur de reconnaissance pour les attaquants. Les requêtes LDAP permettent d'énumérer l'intégralité de l'annuaire : utilisateurs, groupes, GPO, trusts, ACL, SPN, délégations, et plus encore. Les outils de collecte BloodHound (SharpHound) et les frameworks offensifs (PowerView, ADExplorer, ldapdomaindump) s'appuient massivement sur LDAP. La sécurisation de LDAP comprend l'activation du LDAP Signing (qui empêche les attaques man-in-the-middle sur les connexions LDAP), l'activation du LDAP Channel Binding (qui lie la session TLS à la session LDAP pour prévenir le relais), la restriction des connexions LDAP non chiffrées, et la surveillance des requêtes LDAP massives ou inhabituelles. Depuis 2020, Microsoft renforce progressivement les exigences de signature LDAP, et les organisations doivent s'assurer que leurs applications supportent LDAPS ou le LDAP Signing.

LDAP Signing

Le LDAP Signing est un mécanisme de sécurité qui assure l'intégrité des communications LDAP en ajoutant une signature cryptographique à chaque message échangé entre le client et le serveur LDAP. Cette signature permet de détecter toute modification ou injection de données dans le flux LDAP, protégeant contre les attaques man-in-the-middle et le LDAP Relay. Le LDAP Signing peut être configuré via trois niveaux : None (pas de signature requise), Negotiate (signature si le client la supporte), et Required (signature obligatoire). La configuration côté serveur se fait via la GPO « Domain controller: LDAP server signing requirements » et côté client via « Network security: LDAP client signing requirements ». Du point de vue sécurité, l'absence de LDAP Signing est exploitée dans les attaques de relais LDAP (LDAP Relay) où un attaquant intercepte une authentification NTLM et la redirige vers un serveur LDAP pour effectuer des modifications dans l'annuaire. Cette technique est souvent combinée avec la coercion d'authentification pour relayer l'authentification d'un contrôleur de domaine vers le service LDAP d'un autre DC, permettant des modifications critiques comme l'ajout de délégation RBCD ou la modification d'ACL. Le LDAP Channel Binding (EPA — Extended Protection for Authentication) renforce la protection en liant la session d'authentification au canal TLS sous-jacent, empêchant le relais même si la signature est présente. Microsoft a annoncé le renforcement progressif des exigences de LDAP Signing et Channel Binding, avec une obligation prévue pour les contrôleurs de domaine. Les organisations doivent auditer la compatibilité de leurs applications et services avant d'activer le LDAP Signing en mode Required, en utilisant les événements d'audit 2887 (nombre de binds non signés) et 2889 (détails des binds non signés) sur les DC.

Linked GPO (GPO Liée)

Une Linked GPO fait référence à une stratégie de groupe qui a été associée à un conteneur Active Directory spécifique — un site, un domaine ou une unité organisationnelle (OU) — pour que ses paramètres s'appliquent aux objets contenus dans ce conteneur. La distinction entre la GPO elle-même et son lien est importante : une même GPO peut être liée à plusieurs conteneurs, et un conteneur peut avoir plusieurs GPO liées. L'ordre de traitement suit la hiérarchie LSDOU (Local, Site, Domain, OU), avec les GPO des OU enfants prenant précédence sur les OU parentes. Les liens GPO peuvent être configurés avec deux options de sécurité : Enforced (qui empêche les GPO de niveau inférieur de surcharger les paramètres) et Block Inheritance (qui empêche les GPO de niveau supérieur de s'appliquer, sauf celles marquées Enforced). Du point de vue sécurité, les liens GPO sont un vecteur d'attaque car la modification d'un lien peut changer les paramètres appliqués à des centaines de machines ou d'utilisateurs. Un attaquant disposant du droit gpLink sur une OU peut lier une GPO malveillante contenant un script de démarrage, une tâche planifiée, ou une modification des groupes locaux. L'attaque est d'autant plus impactante si la GPO est liée à une OU contenant des serveurs critiques ou des contrôleurs de domaine. La surveillance des modifications de liens GPO (attribut gPLink sur les conteneurs AD, événement 5136) est essentielle. Les outils comme BloodHound cartographient les relations entre GPO, liens et OUs pour identifier les chemins d'attaque via les stratégies de groupe. La revue régulière des liens GPO et de leurs permissions fait partie des contrôles recommandés dans le guide de sécurisation par GPO.

LLMNR (Link-Local Multicast Name Resolution)

LLMNR est un protocole de résolution de noms réseau utilisé par Windows lorsque le DNS ne parvient pas à résoudre un nom d'hôte. Défini dans la RFC 4795, LLMNR fonctionne par diffusion multicast sur le réseau local (adresse multicast 224.0.0.252 en IPv4, FF02::1:3 en IPv6, port UDP 5355), permettant à n'importe quelle machine du réseau de répondre aux requêtes de résolution de noms. Ce mécanisme constitue l'un des vecteurs d'attaque réseau les plus exploités dans les environnements Active Directory. L'attaque consiste à écouter les requêtes LLMNR sur le réseau local et à y répondre avec l'adresse IP de la machine de l'attaquant. L'outil Responder est le framework de référence pour cette attaque : il écoute les requêtes LLMNR (et NBT-NS, mDNS), répond en se faisant passer pour le serveur demandé, et capture les authentifications NTLM des clients qui tentent de se connecter. Les hachages NTLMv2 capturés peuvent être crackés hors ligne avec hashcat ou john, ou relayés en temps réel vers d'autres services (NTLM Relay). Ce scénario est particulièrement efficace dans les réseaux d'entreprise où les requêtes de résolution de noms échouées sont fréquentes (partages mal configurés, serveurs décommissionnés, erreurs de frappe). La remédiation est claire : désactiver LLMNR via GPO dans « Computer Configuration > Administrative Templates > Network > DNS Client > Turn off Multicast Name Resolution ». Cette désactivation doit être couplée avec la désactivation de NBT-NS et la mise en place d'un DNS robuste. La surveillance des requêtes LLMNR sur le réseau peut détecter les tentatives d'empoisonnement avant la désactivation complète du protocole.

LSA Secrets

Les LSA Secrets sont des données sensibles stockées de manière chiffrée dans le registre Windows par le Local Security Authority (LSA), dans la ruche HKLM\SECURITY\Policy\Secrets. Ces secrets incluent les mots de passe des comptes de service configurés pour s'exécuter sous un compte de domaine, le mot de passe du compte machine (utilisé pour le canal sécurisé avec le DC), les mots de passe de connexion automatique, les clés de la Domain Controller Account Password, les mots de passe des tâches planifiées exécutées sous des comptes spécifiques, et la clé de sauvegarde DPAPI du domaine sur les DC. Du point de vue sécurité offensive, l'extraction des LSA Secrets est une étape cruciale du credential dumping. Un administrateur local (ou SYSTEM) peut extraire ces secrets en accédant aux ruches de registre SAM, SYSTEM et SECURITY. Les outils comme secretsdump.py d'Impacket, Mimikatz (lsadump::secrets), et CrackMapExec (--lsa) automatisent cette extraction. Sur un contrôleur de domaine, les LSA Secrets contiennent des informations particulièrement sensibles, notamment la clé de sauvegarde DPAPI ($MACHINE.ACC) qui permet de déchiffrer les Master Keys DPAPI de tous les utilisateurs du domaine. Les mots de passe de comptes de service récupérés depuis les LSA Secrets peuvent être utilisés pour le mouvement latéral, l'escalade de privilèges, ou l'accès à des applications métier. La protection des LSA Secrets passe par la restriction des droits d'administration locale (pour empêcher l'extraction), le déploiement de Credential Guard (qui isole certains secrets dans un environnement virtualisé), la migration vers des gMSA (qui éliminent les mots de passe statiques dans les LSA Secrets), et la surveillance des accès aux ruches de registre sensibles.

Machine Account Quota

Le Machine Account Quota, contrôlé par l'attribut ms-DS-MachineAccountQuota sur l'objet domaine, définit le nombre de comptes d'ordinateurs qu'un utilisateur authentifié peut créer dans le domaine. Par défaut, cette valeur est fixée à 10, signifiant que tout utilisateur du domaine peut joindre jusqu'à 10 machines au domaine sans avoir de privilèges administratifs. Du point de vue sécurité, cette valeur par défaut est considérée comme dangereuse car elle permet aux attaquants de créer des comptes machines qu'ils contrôlent entièrement. Ces comptes machines peuvent ensuite être utilisés dans plusieurs scénarios d'attaque. La RBCD (Resource-Based Constrained Delegation) nécessite un compte machine contrôlé par l'attaquant : en modifiant l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity d'un service cible pour y ajouter le SID du compte machine créé, l'attaquant peut ensuite utiliser S4U2Self et S4U2Proxy pour usurper l'identité d'un administrateur. Les comptes machines créés disposent d'un SPN par défaut, ce qui peut être utile pour certaines attaques Kerberos. De plus, le créateur d'un compte machine peut modifier ses attributs, y compris le SPN et le mot de passe. Les relais NTLM vers LDAP pour la création de comptes machines utilisent également ce quota. La recommandation de sécurité est sans équivoque : positionner ms-DS-MachineAccountQuota à 0 et déléguer la jonction de machines au domaine à des groupes d'administration spécifiques via les permissions sur les OUs dédiées. Cette modification se fait via Set-ADDomain -Identity "domain.com" -Replace @{"ms-DS-MachineAccountQuota"=0} ou via ADSI Edit. C'est l'une des premières mesures de durcissement AD à implémenter.

MAPI (Messaging Application Programming Interface)

MAPI est l'interface de programmation propriétaire de Microsoft utilisée principalement par Microsoft Exchange pour la communication entre les clients Outlook et le serveur de messagerie. Dans le contexte Active Directory, MAPI est pertinent car Exchange est profondément intégré à AD, avec des extensions de schéma spécifiques et des permissions souvent excessives. Historiquement, l'installation d'Exchange ajoutait des permissions très larges dans l'annuaire, notamment via le groupe « Exchange Windows Permissions » qui disposait de WriteDACL sur l'objet domaine — un problème connu sous le nom d'Exchange Privilege Escalation ou PrivExchange. Du point de vue sécurité, les interfaces MAPI/RPC d'Exchange représentent une surface d'attaque significative. L'attaque PrivExchange, découverte en 2019, exploitait l'API MAPI pour déclencher une authentification depuis le serveur Exchange vers une machine contrôlée par l'attaquant, puis relayer cette authentification vers un DC pour obtenir des droits DCSync. La méthode EWS (Exchange Web Services) et les interfaces MAPI over HTTP ont remplacé progressivement le MAPI/RPC classique, mais les risques de sécurité persistent. Les serveurs Exchange doivent être considérés comme des actifs de haute valeur car leur compromission peut donner accès à l'ensemble de la messagerie de l'organisation et, potentiellement, à des droits d'escalade vers le domaine AD. Les mesures de protection incluent la suppression des permissions Exchange excessives dans l'annuaire, la mise à jour régulière des serveurs Exchange, la segmentation réseau des serveurs de messagerie, et la surveillance des authentifications et des accès MAPI inhabituels. La migration vers Exchange Online réduit la surface d'attaque on-premises mais introduit de nouvelles considérations de sécurité cloud.

mDNS (Multicast DNS)

Le Multicast DNS (mDNS) est un protocole de résolution de noms qui fonctionne sans serveur DNS central, utilisant des requêtes multicast sur le réseau local (adresse 224.0.0.251, port UDP 5353). Défini dans la RFC 6762, mDNS est principalement utilisé par les systèmes Apple (Bonjour) et Linux (Avahi) mais est également supporté par Windows 10 et versions ultérieures. Dans un environnement Active Directory, mDNS représente un vecteur d'attaque similaire à LLMNR car il peut être exploité pour intercepter les résolutions de noms et capturer des authentifications. L'outil Responder est capable de répondre aux requêtes mDNS, capturant les hachages NTLMv2 des clients qui tentent de résoudre des noms via ce protocole. L'exploitation est identique à LLMNR : l'attaquant écoute les requêtes multicast, répond en se faisant passer pour le serveur demandé, et capture ou relaye les credentials. Bien que moins fréquent que LLMNR dans les environnements Windows purs, mDNS peut être présent dans les réseaux hétérogènes incluant des appareils Apple, des machines Linux, ou des appareils IoT. Les imprimantes réseau et les périphériques multimédias utilisent souvent mDNS pour la découverte de services. La désactivation de mDNS est recommandée sur toutes les machines Windows du domaine via les paramètres de registre ou les GPO. Sur Windows, le service « mDNS » peut être désactivé, et le pare-feu peut bloquer le trafic sur le port UDP 5353. La stratégie de défense globale contre les protocoles de résolution de noms non sécurisés doit couvrir LLMNR, NBT-NS et mDNS simultanément pour éliminer complètement cette catégorie de risque. La surveillance réseau des requêtes multicast anormales permet de détecter les tentatives d'empoisonnement.

NBT-NS (NetBIOS Name Service)

NBT-NS (NetBIOS over TCP/IP Name Service) est un protocole de résolution de noms hérité qui fonctionne par diffusion broadcast sur le réseau local (port UDP 137). Dans la hiérarchie de résolution de noms Windows, NBT-NS intervient après l'échec du DNS et de LLMNR, ce qui en fait le dernier recours pour résoudre un nom d'hôte. Ce protocole est l'un des vecteurs d'empoisonnement de noms les plus anciens et les plus fiables dans les environnements Active Directory. L'attaque est similaire à celle de LLMNR : l'outil Responder écoute les requêtes de broadcast NBT-NS et répond en se faisant passer pour le serveur demandé, capturant les hachages NTLM des clients. NBT-NS est particulièrement dangereux car il utilise le broadcast réseau (ce qui signifie que toutes les machines du sous-réseau reçoivent la requête), il ne dispose d'aucun mécanisme d'authentification ou de vérification, et il est activé par défaut sur toutes les versions de Windows. De plus, NBT-NS est utilisé par le service de navigation réseau (Computer Browser) pour la découverte des partages et des imprimantes, générant un flux constant de requêtes exploitables. La désactivation de NBT-NS se fait interface par interface via les propriétés TCP/IP avancées (onglet WINS > Désactiver NetBIOS sur TCP/IP) ou via la configuration DHCP (option 001 = 0x2). Pour un déploiement à grande échelle via GPO, un script de démarrage PowerShell peut automatiser la désactivation sur toutes les interfaces. Il est important de tester la désactivation car certaines applications legacy dépendent encore de NetBIOS pour la résolution de noms ou la navigation réseau. La combinaison de la désactivation de NBT-NS, LLMNR et mDNS élimine complètement les risques d'empoisonnement de noms broadcast dans l'environnement.

NTDS.dit

NTDS.dit (NT Directory Services Directory Information Tree) est le fichier de base de données principale d'Active Directory, stocké sur chaque contrôleur de domaine dans %SystemRoot%\NTDS\ntds.dit. Ce fichier contient l'intégralité des objets et attributs de l'annuaire, y compris les hachages NTLM et les clés Kerberos de tous les comptes utilisateurs et machines du domaine. La base utilise le moteur ESE (Extensible Storage Engine), le même que celui de Microsoft Exchange. Le fichier est verrouillé en permanence par le service NTDS et ne peut pas être copié directement pendant le fonctionnement du DC. Du point de vue sécurité, NTDS.dit est le « Saint Graal » de la compromission Active Directory. L'extraction et le déchiffrement de ce fichier donnent accès à tous les hachages de mots de passe du domaine, permettant des attaques Pass-the-Hash à grande échelle, la création de Golden Tickets, et la compromission totale. Les techniques d'extraction incluent Volume Shadow Copy (vssadmin create shadow), ntdsutil "activate instance ntds" "ifm" "create full", l'outil wbadmin pour les sauvegardes, et l'accès à des sauvegardes existantes mal protégées. L'extraction distante via DCSync est souvent préférée car elle ne nécessite pas d'accès au système de fichiers du DC. Une fois le fichier obtenu, les outils comme secretsdump.py d'Impacket ou DSInternals extraient les hachages en combinant NTDS.dit avec la clé de la ruche SYSTEM. La protection passe par la sécurisation physique des DC, le chiffrement BitLocker des volumes, la surveillance des opérations VSS et ntdsutil, la protection des sauvegardes, et la restriction des privilèges. Notre article dédié au NTDS.dit approfondit ces aspects.

NTLM (NT LAN Manager)

NTLM est un protocole d'authentification challenge-response hérité de Microsoft, toujours largement présent dans les environnements Active Directory malgré la recommandation d'utiliser Kerberos. Le protocole NTLM fonctionne en trois étapes : le client envoie une demande de négociation (Type 1), le serveur répond avec un challenge aléatoire (Type 2), et le client répond avec une réponse calculée à partir du hachage NTLM de son mot de passe et du challenge (Type 3). Il existe deux versions principales : NTLMv1 (considéré comme cassé, le challenge peut être converti en hachage NTLM pur) et NTLMv2 (plus robuste, incluant un timestamp et un challenge client). NTLM est utilisé comme fallback lorsque Kerberos n'est pas disponible : accès par adresse IP, services non enregistrés dans le DNS du domaine, ou authentification cross-forest dans certains cas. Du point de vue sécurité, NTLM présente des faiblesses structurelles majeures. Le hachage NTLM est un simple MD4 du mot de passe Unicode, sans sel, ce qui le rend vulnérable aux attaques par tables arc-en-ciel et au cracking rapide. De plus, NTLM est vulnérable au relais NTLM (forwarding de l'authentification vers un autre service), au Pass-the-Hash (utilisation du hachage sans connaître le mot de passe), et à la capture réseau (via Responder/LLMNR/NBT-NS). La stratégie de réduction de NTLM passe par l'audit des dépendances NTLM (politique « Restrict NTLM: Audit NTLM authentication in this domain »), la désactivation progressive (« Restrict NTLM: NTLM authentication in this domain »), l'activation de la signature SMB, et le déploiement de EPA sur les services web. Microsoft a annoncé la dépréciation future de NTLM au profit de Kerberos et de la négociation IAKerb.

NTLM Relay (Relais NTLM)

Le NTLM Relay est une technique d'attaque qui consiste à intercepter une authentification NTLM en cours et à la transférer vers un autre service cible, permettant à l'attaquant de s'authentifier auprès de ce service avec les credentials de la victime. Contrairement au Pass-the-Hash qui réutilise un hachage statique, le NTLM Relay agit en temps réel sur un flux d'authentification actif. L'attaquant se positionne comme man-in-the-middle entre le client et le serveur, recevant le challenge du serveur cible, le transmettant au client victime, et renvoyant la réponse du client au serveur cible. Les outils de référence sont ntlmrelayx.py d'Impacket et MultiRelay de Responder. Les cibles de relais les plus dangereuses incluent le service LDAP d'un DC (pour modifier l'annuaire : ajouter un membre à un groupe, configurer une RBCD, modifier des ACL), le service HTTP d'AD CS (ESC8 — pour obtenir un certificat), le service SMB d'un serveur (pour exécuter du code), et le service MSSQL (pour exécuter des requêtes). La combinaison la plus dévastatrice est coercion + NTLM Relay : forcer un contrôleur de domaine à s'authentifier (via PetitPotam, PrinterBug, etc.) puis relayer cette authentification vers AD CS pour obtenir un certificat du DC, donnant ensuite accès DCSync. Les protections incluent l'activation de la signature SMB (qui empêche le relais SMB), le LDAP Signing et Channel Binding (pour le relais LDAP), l'EPA sur IIS/AD CS (pour le relais HTTP), et la désactivation de NTLM quand possible. Notre article sur les techniques et défenses NTLM Relay 2026 couvre les dernières évolutions.

OU (Organizational Unit)

Une Organizational Unit, ou unité organisationnelle, est un conteneur Active Directory utilisé pour organiser les objets (utilisateurs, groupes, ordinateurs, autres OUs) dans une hiérarchie logique et pour appliquer des stratégies de groupe et des délégations d'administration. Les OUs constituent la structure administrative du domaine et permettent une gestion décentralisée : un administrateur peut recevoir des droits de gestion sur une OU spécifique sans avoir accès à l'ensemble du domaine. Les GPO sont liées aux OUs, et leur application suit l'héritage hiérarchique (les GPO de l'OU parente s'appliquent aux OUs enfants, sauf blocage d'héritage). Du point de vue sécurité, les OUs sont essentielles dans l'implémentation du modèle de tiering. La structure d'OUs doit refléter les niveaux de sécurité : les OUs Tier 0 (contrôleurs de domaine, comptes administrateurs du domaine), Tier 1 (serveurs d'application, comptes d'administration serveurs), et Tier 2 (postes de travail, comptes utilisateurs). Les délégations d'administration sur les OUs doivent respecter cette segmentation. Les risques de sécurité liés aux OUs incluent les délégations excessives (un helpdesk ayant GenericAll sur une OU contenant des comptes privilégiés), l'absence de protection contre la suppression accidentelle (attribut ProtectedFromAccidentalDeletion), et les liens GPO malveillants. L'attribut gPLink de l'OU détermine quelles GPO s'appliquent et dans quel ordre. La modification non autorisée de cet attribut ou des ACL de l'OU constitue un vecteur d'escalade. L'audit des délégations sur les OUs avec Get-ADOrganizationalUnit et la revue des permissions avec dsacls ou ADACLScanner font partie des contrôles de sécurité réguliers.

Overpass-the-Hash

L'Overpass-the-Hash, également connu sous le nom de Pass-the-Key, est une technique d'attaque qui convertit un hachage NTLM ou une clé Kerberos AES en un Ticket Granting Ticket (TGT) Kerberos valide. Contrairement au Pass-the-Hash classique qui utilise le hachage NTLM pour s'authentifier via NTLM, l'Overpass-the-Hash utilise ce même hachage pour effectuer une pré-authentification Kerberos et obtenir un TGT légitime. Ce TGT peut ensuite être utilisé pour demander des tickets de service standard, rendant l'activité de l'attaquant plus difficile à distinguer du trafic Kerberos normal. La technique fonctionne car la clé utilisée pour la pré-authentification Kerberos est dérivée du mot de passe de l'utilisateur — et le hachage NTLM est lui-même une clé Kerberos valide (RC4-HMAC). L'outil Rubeus avec la commande asktgt /rc4:HASH ou /aes256:KEY effectue cette opération, tout comme Mimikatz via sekurlsa::pth. L'avantage principal de l'Overpass-the-Hash par rapport au Pass-the-Hash est qu'il fonctionne dans des environnements où NTLM est restreint ou désactivé, tant que Kerberos RC4 est encore supporté. De plus, les tickets Kerberos obtenus permettent l'accès aux services qui nécessitent une authentification Kerberos. La détection repose sur la surveillance des demandes AS-REQ utilisant le chiffrement RC4-HMAC (type 23) dans un environnement où AES est la norme, les événements 4768 avec le code de chiffrement 0x17, et la corrélation entre les connexions réseau et les tickets demandés. La mitigation consiste à désactiver le chiffrement RC4 dans la politique Kerberos du domaine, à déployer Credential Guard pour protéger les hachages en mémoire, et à surveiller les anomalies d'authentification Kerberos.

PAM Trust (Privileged Access Management Trust)

Le PAM Trust est un type spécial de relation d'approbation Active Directory introduit avec Windows Server 2016 dans le cadre de la fonctionnalité Privileged Access Management (PAM). Ce trust est établi entre une forêt de production et une forêt d'administration dédiée (souvent appelée « bastion forest » ou « red forest ») pour permettre une gestion sécurisée des accès privilégiés. Le concept repose sur l'idée qu'une forêt compromise ne peut pas être sécurisée à nouveau de manière fiable — il est donc préférable de gérer les accès privilégiés depuis une forêt séparée, réputée saine. Le PAM Trust diffère d'un Forest Trust classique par plusieurs caractéristiques : il est marqué avec l'attribut trustAttributes contenant le flag TRUST_ATTRIBUTE_PIM_TRUST (0x00000400), et il active le SID Filtering en mode forêt avec des règles spécifiques permettant le Shadow Principal. Les Shadow Principals sont des objets dans la forêt bastion qui « reflètent » des groupes privilégiés de la forêt de production. Un administrateur peut être ajouté temporairement à un Shadow Principal avec une durée de vie limitée (Time-to-Live), utilisant l'attribut msDS-ShadowPrincipalSid pour mapper le SID du groupe cible. Cette fonctionnalité permet des accès JIT (Just-In-Time) : l'administrateur obtient des privilèges élevés uniquement pour la durée nécessaire. Microsoft Identity Manager (MIM) peut automatiser le workflow d'approbation et de provisionnement. Du point de vue sécurité, le PAM Trust augmente considérablement la complexité de l'infrastructure mais offre une isolation forte des credentials privilégiés. Le modèle ESAE (Enhanced Security Admin Environment) de Microsoft recommandait cette architecture, bien que Microsoft ait récemment pivoté vers des solutions cloud-first avec Entra ID PIM.

PAW (Privileged Access Workstation)

Une Privileged Access Workstation est un poste de travail spécialement configuré et durci pour l'exécution des tâches d'administration privilégiées dans un environnement Active Directory. Le concept PAW est un pilier du modèle de sécurité Microsoft pour la protection des credentials Tier 0 et Tier 1. Le principe fondamental est la séparation physique ou logique : les administrateurs ne doivent jamais utiliser leurs credentials privilégiés sur un poste de travail standard, car ces postes sont exposés aux menaces internet (email, navigation web, malware) et constituent le vecteur principal de credential theft. Une PAW de niveau Tier 0 (pour l'administration des contrôleurs de domaine) doit être un poste physique dédié, sans accès internet, avec un système d'exploitation durci, un disque chiffré BitLocker, Credential Guard activé, et une authentification forte (carte à puce ou Windows Hello for Business). Les logiciels installés sont limités au strict nécessaire : RSAT, PowerShell avec contraintes de langage, et les outils d'administration spécifiques. La PAW ne doit jamais être utilisée pour la navigation web, la messagerie, ou toute activité non administrative. L'architecture recommandée utilise un Clean Source Principle : chaque couche de l'infrastructure ne doit être administrée que depuis un environnement de sécurité égal ou supérieur. L'administration via des solutions de type jump server ou bastion host peut être une alternative, mais avec des contrôles de sécurité stricts (pas de copier-coller, session enregistrée, MFA). Le modèle de tiering définit que les PAW Tier 0 ne peuvent administrer que des assets Tier 0, et ainsi de suite. Le déploiement de PAW est une recommandation majeure du guide de durcissement AD.

Pass-the-Certificate

Le Pass-the-Certificate est une technique d'attaque qui utilise un certificat X.509 valide pour s'authentifier auprès d'Active Directory via le mécanisme Kerberos PKINIT (Public Key Cryptography for Initial Authentication). Au lieu de s'authentifier avec un mot de passe ou un hachage NTLM, l'attaquant utilise un certificat et sa clé privée correspondante pour obtenir un TGT Kerberos. Cette technique exploite les vulnérabilités AD CS : un certificat obtenu via ESC1 (SAN spoofing), un Golden Certificate (forgé avec la clé CA), ou un certificat volé depuis un poste compromis peut être utilisé pour s'authentifier en tant que l'utilisateur spécifié dans le certificat. L'outil Certipy avec la commande auth -pfx certificate.pfx ou Rubeus avec asktgt /certificate:cert.pfx effectuent l'authentification PKINIT et retournent un TGT. Un avantage majeur du Pass-the-Certificate par rapport au Pass-the-Hash est que le certificat peut avoir une durée de validité de plusieurs années, offrant une persistance à long terme même si le mot de passe de l'utilisateur est changé. De plus, le mécanisme d'authentification par certificat peut être utilisé pour demander le hachage NTLM de l'utilisateur via l'extension U2U (User-to-User), une technique connue sous le nom de UnPAC-the-Hash. La détection repose sur la surveillance des événements 4768 avec un type de pré-authentification indiquant PKINIT (type 16/17), la corrélation avec les événements d'émission de certificats (4887), et l'identification des certificats avec des SAN suspects. La remédiation des vulnérabilités AD CS et la surveillance de l'infrastructure PKI sont les mesures préventives principales.

Pass-the-Hash (PtH)

Le Pass-the-Hash est une technique d'attaque fondamentale dans les environnements Windows qui permet à un attaquant de s'authentifier auprès d'un service en utilisant le hachage NTLM du mot de passe d'un utilisateur, sans avoir besoin de connaître le mot de passe en clair. Cette technique exploite une caractéristique du protocole NTLM : la réponse au challenge du serveur est calculée à partir du hachage NTLM (MD4 du mot de passe Unicode), et non du mot de passe lui-même. Un attaquant qui extrait un hachage NTLM depuis la mémoire LSASS, la base SAM, le fichier NTDS.dit, ou via DCSync peut donc l'utiliser directement pour s'authentifier. Les outils comme Mimikatz (sekurlsa::pth), pth-winexe, CrackMapExec, NetExec, et psexec.py d'Impacket implémentent le PtH. La technique est utilisée massivement pour le mouvement latéral : un attaquant compromettant un poste de travail extrait les hachages des administrateurs locaux et les utilise pour se connecter aux autres machines du réseau. C'est pourquoi le déploiement de LAPS (mots de passe administrateur local uniques) est une mesure défensive essentielle. Les protections contre le PtH incluent Credential Guard (qui empêche l'extraction des hachages depuis LSASS), la désactivation du compte administrateur local RID 500, la restriction des connexions réseau avec des comptes locaux via les politiques « Deny access to this computer from the network » et le filtre UAC remote, et la réduction des sessions privilégiées sur les postes de travail. Notre article détaillé sur le PtH couvre les variantes et les défenses en profondeur.

Pass-the-Ticket (PtT)

Le Pass-the-Ticket est une technique d'attaque qui consiste à voler un ticket Kerberos (TGT ou TGS) depuis la mémoire d'un système compromis et à l'injecter dans une autre session ou sur une autre machine pour usurper l'identité de l'utilisateur. Contrairement au Pass-the-Hash qui exploite le protocole NTLM, le PtT opère entièrement dans l'écosystème Kerberos. L'extraction des tickets se fait via Mimikatz (sekurlsa::tickets /export) ou Rubeus (dump), et l'injection dans une nouvelle session via Mimikatz (kerberos::ptt) ou Rubeus (ptt /ticket:base64). Le vol d'un TGT est plus intéressant qu'un TGS car il permet de demander des tickets de service pour n'importe quel service, tandis qu'un TGS ne donne accès qu'au service spécifique. Les tickets Kerberos ont une durée de vie limitée (10 heures par défaut pour un TGT, avec un renouvellement possible pendant 7 jours), ce qui limite la fenêtre d'exploitation par rapport à un hachage NTLM qui est valide indéfiniment. Cependant, les Golden Tickets et Silver Tickets sont des cas spéciaux du PtT où les tickets sont forgés plutôt que volés. Les défenses contre le PtT incluent l'ajout des comptes sensibles au groupe Protected Users (qui empêche la mise en cache du TGT sur les postes de travail), le déploiement de Credential Guard (qui isole les tickets dans un environnement virtualisé), la réduction de la durée de vie des TGT, et la surveillance des anomalies d'utilisation de tickets. La détection repose sur la corrélation entre l'émission d'un ticket (événement 4768) et son utilisation (événement 4769) depuis des machines différentes. Notre guide sur le Pass-the-Ticket détaille les scénarios et les contre-mesures.

PetitPotam

PetitPotam est une technique de coercion d'authentification découverte par le chercheur français Gilles Lionel (topotam) en 2021, qui exploite l'interface MS-EFSRPC (Encrypting File System Remote Protocol) pour forcer un serveur Windows à s'authentifier auprès d'une machine contrôlée par l'attaquant. L'attaque utilise les fonctions RPC EfsRpcOpenFileRaw et d'autres fonctions de l'API EFS pour déclencher une connexion sortante depuis le serveur cible, envoyant son authentification NTLM (ou Kerberos dans certaines conditions) vers l'attaquant. La variante la plus dévastatrice cible les contrôleurs de domaine : en forçant un DC à s'authentifier et en relayant cette authentification vers l'interface d'inscription web d'AD CS (ESC8), l'attaquant obtient un certificat pour le compte machine du DC, permettant ensuite une authentification PKINIT et un DCSync complet. L'impact initial a été considérable car l'attaque fonctionnait sans authentification (anonyme) sur de nombreuses configurations. Microsoft a publié des correctifs partiels qui nécessitent l'authentification pour les appels EFS-RPC, mais des variantes utilisant d'autres fonctions EFS ou des protocoles similaires continuent d'être découvertes. Les mesures de protection incluent l'activation de l'EPA (Extended Protection for Authentication) sur le service d'inscription web AD CS, la désactivation de l'inscription web HTTP si non nécessaire, le blocage du trafic SMB sortant des contrôleurs de domaine via le pare-feu, la désactivation de NTLM sur les DC quand possible, et la surveillance des connexions SMB sortantes anormales depuis les DC. PetitPotam a catalysé un intérêt renouvelé pour les techniques de coercion, menant à la découverte de DFSCoerce, ShadowCoerce, et d'autres techniques similaires. Notre article sur le NTLM Relay 2026 couvre les dernières techniques.

PIM (Privileged Identity Management)

Privileged Identity Management est une fonctionnalité d'Entra ID (Azure AD) qui permet de gérer, contrôler et surveiller l'accès aux rôles privilégiés selon le principe du Just-In-Time (JIT) et du Just-Enough-Access (JEA). PIM transforme les attributions de rôles permanentes en attributions éligibles : un administrateur n'est pas en permanence Global Admin ou Exchange Admin, mais il est « éligible » à ce rôle et doit l'activer explicitement pour une durée limitée, avec potentiellement une approbation requise et un justificatif obligatoire. Le processus d'activation peut exiger une authentification MFA, une justification textuelle, un numéro de ticket, et l'approbation d'un responsable. PIM couvre les rôles Entra ID (Global Admin, Security Admin, etc.), les rôles Azure RBAC (Owner, Contributor sur les souscriptions et ressources), et les groupes (PIM for Groups). Les fonctionnalités clés incluent les access reviews (revues d'accès périodiques), les alertes de sécurité (détection de rôles permanents excessifs, activations suspectes), et l'audit complet de toutes les activations de rôles. Du point de vue sécurité, PIM réduit considérablement la fenêtre d'exposition des comptes privilégiés : un attaquant qui compromet un compte éligible doit encore réussir l'activation (MFA, approbation) dans une fenêtre de temps limitée. Cependant, PIM peut être contourné si l'attaquant compromet le processus d'approbation, dispose d'un accès à un authenticator MFA, ou si des attributions permanentes existent à côté des attributions éligibles. La configuration de PIM doit s'intégrer dans une stratégie globale de gestion des accès privilégiés, en complément du modèle de tiering on-premises et du Conditional Access.

PKI (Public Key Infrastructure)

La Public Key Infrastructure dans le contexte Active Directory désigne l'ensemble de l'infrastructure de gestion des certificats numériques, principalement implémentée via AD CS (Active Directory Certificate Services). La PKI AD comprend les autorités de certification (CA) racines et subordonnées, les modèles de certificats, les points de distribution de listes de révocation (CRL Distribution Points), les répondeurs OCSP, et les politiques d'inscription. L'intégration de la PKI avec Active Directory est profonde : les certificats CA racines sont publiés dans l'objet NTAuthCertificates de l'annuaire, les modèles de certificats sont des objets AD, et l'auto-inscription (autoenrollment) utilise les GPO et l'authentification Kerberos. Cette intégration offre une gestion centralisée mais crée également une surface d'attaque significative. Les vulnérabilités ESC1 à ESC15 démontrent que des erreurs de configuration dans la PKI AD peuvent mener à la compromission totale du domaine. Les risques spécifiques à la PKI incluent la compromission de la clé privée de la CA (permettant la forge de Golden Certificates), les modèles de certificats mal configurés (permettant l'usurpation d'identité), les permissions excessives sur les objets PKI (permettant la modification des configurations), et l'inscription web non protégée (permettant le relais NTLM). La sécurisation de la PKI AD nécessite le déploiement de la CA racine en mode offline (hors ligne), le stockage des clés CA dans un HSM, l'audit de chaque modèle de certificat, la restriction des permissions d'inscription, l'activation de l'approbation par un gestionnaire pour les modèles sensibles, et la surveillance des émissions de certificats. Nos articles sur AD CS et le bilan ESC1-ESC15 fournissent une couverture exhaustive.

Pre-Authentication (Pré-Authentification Kerberos)

La pré-authentification Kerberos est un mécanisme de sécurité qui vérifie l'identité du client avant l'émission d'un TGT par le KDC. Lors de la phase AS-REQ, le client doit inclure un timestamp chiffré avec son hachage de mot de passe (PA-ENC-TIMESTAMP), prouvant ainsi qu'il connaît le secret partagé. Le KDC déchiffre ce timestamp, vérifie qu'il est dans la tolérance horaire (5 minutes par défaut), et émet le TGT seulement si la vérification réussit. La pré-authentification a été introduite pour empêcher les attaques hors ligne : sans elle, n'importe qui pourrait demander un TGT pour n'importe quel utilisateur et tenter de déchiffrer la réponse AS-REP, ce qui constitue précisément l'attaque AS-REP Roasting. L'option « Do not require Kerberos preauthentication » (flag UAC DONT_REQUIRE_PREAUTH, valeur 0x400000) peut être activée sur des comptes individuels pour des raisons de compatibilité avec des clients Kerberos anciens. Les comptes avec cette option sont vulnérables à l'AS-REP Roasting. Dans les versions récentes de Kerberos et avec les extensions Microsoft, d'autres mécanismes de pré-authentification existent : PA-PK-AS-REQ (PKINIT, authentification par certificat), PA-ETYPE-INFO2 (négociation des types de chiffrement), et les nouvelles extensions FAST (Flexible Authentication via Secure Tunneling) qui encapsulent la pré-authentification dans un tunnel protégé. La vérification de la pré-authentification échouée génère l'événement 4771 (Kerberos pre-authentication failed), tandis que les succès génèrent l'événement 4768. L'audit de tous les comptes sans pré-authentification et leur correction font partie des contrôles de sécurité AD de base.

Printerbug (SpoolService Bug)

Le Printerbug, également connu sous le nom de SpoolService Bug ou Printer Bug, est une technique de coercion d'authentification qui exploite le service Windows Print Spooler (Spouleur d'impression) via l'interface RPC MS-RPRN. Découverte par Lee Christensen de SpecterOps, cette technique utilise la fonction RpcRemoteFindFirstPrinterChangeNotification pour demander à un serveur de s'authentifier auprès d'un host arbitraire. Tout utilisateur authentifié du domaine peut déclencher cette coercion, ce qui en fait une attaque à faible barrière d'entrée. L'outil SpoolSample (C#) ou le script Python printerbug.py automatisent cette attaque. Le scénario d'exploitation le plus courant combine le Printerbug avec la délégation non contrainte (Unconstrained Delegation). Si un attaquant compromet un serveur configuré avec la délégation non contrainte, il peut utiliser le Printerbug pour forcer un contrôleur de domaine à s'authentifier auprès de ce serveur, capturant le TGT du DC dans la mémoire LSASS. Ce TGT peut ensuite être utilisé pour un DCSync. Un autre scénario combine le Printerbug avec le relais NTLM vers AD CS. La vulnérabilité est liée au service Print Spooler qui est activé par défaut sur toutes les versions de Windows, y compris les contrôleurs de domaine, bien qu'il ne soit presque jamais nécessaire sur un DC. La remédiation est simple et efficace : désactiver le service Print Spooler sur tous les contrôleurs de domaine et tous les serveurs qui n'ont pas besoin de gérer des imprimantes, via GPO ou manuellement avec Stop-Service Spooler; Set-Service Spooler -StartupType Disabled. La surveillance des appels RPC MS-RPRN et des connexions réseau sortantes anormales depuis les DC complète la défense.

PrintNightmare

PrintNightmare est le nom donné à une série de vulnérabilités critiques dans le service Windows Print Spooler, identifiées principalement par CVE-2021-34527 (Remote Code Execution) et CVE-2021-1675 (Local Privilege Escalation). La variante RCE permet à un utilisateur authentifié d'exécuter du code arbitraire avec les privilèges SYSTEM sur un serveur distant en exploitant la fonction RpcAddPrinterDriverEx pour charger un pilote d'impression malveillant. La variante LPE permet une escalade de privilèges locale par un mécanisme similaire. L'impact dans un environnement Active Directory est particulièrement grave : si le Print Spooler est actif sur les contrôleurs de domaine (ce qui est le cas par défaut), un utilisateur standard du domaine peut obtenir une exécution de code SYSTEM sur le DC, équivalant à une compromission totale du domaine. Les exploits publics incluent des implémentations en Python, PowerShell et C# qui automatisent l'exploitation. Plusieurs variantes et contournements des correctifs ont été découverts après la publication initiale, rendant la correction complexe. Les mesures de mitigation incluent la désactivation du service Print Spooler sur tous les contrôleurs de domaine et serveurs sensibles, l'application des correctifs Microsoft, la restriction de l'installation des pilotes d'impression via la GPO « Point and Print Restrictions » avec l'option « Only use Package Point and print », et la surveillance de la création de fichiers DLL dans les répertoires de pilotes d'impression (C:\Windows\System32\spool\drivers). PrintNightmare a renforcé la recommandation historique de désactiver le Print Spooler sur les DC, déjà motivée par le Printerbug. L'événement a catalysé une attention accrue sur la surface d'attaque du Print Spooler, avec des recherches supplémentaires révélant d'autres vulnérabilités dans ce composant.

Protected Users (Utilisateurs Protégés)

Protected Users est un groupe de sécurité Active Directory introduit avec Windows Server 2012 R2 qui applique automatiquement un ensemble de restrictions de sécurité renforcées à ses membres. Ces restrictions sont conçues pour protéger les comptes à haut privilège contre les techniques courantes de vol de credentials. Les protections appliquées aux membres du groupe incluent : l'impossibilité d'utiliser NTLM, Digest ou CredSSP pour l'authentification (seul Kerberos est autorisé), la désactivation de la pré-authentification DES et RC4 (seul AES est autorisé pour Kerberos), l'impossibilité de mise en cache des credentials (pas de stockage du hash NTLM ou du TGT en mémoire après déconnexion), l'impossibilité d'utiliser la délégation Kerberos (ni contrainte ni non contrainte), et une durée de vie du TGT réduite à 4 heures (non renouvelable). Ces restrictions rendent les membres du groupe résistants au Pass-the-Hash (NTLM désactivé), au Kerberoasting avec RC4 (seul AES autorisé, beaucoup plus long à cracker), au vol de TGT (pas de mise en cache et durée réduite), et à la délégation abusive. Cependant, Protected Users a des limitations : le groupe n'est efficace que si les DC fonctionnent en Windows Server 2012 R2 minimum, les restrictions peuvent casser des applications legacy qui dépendent de NTLM, et certaines techniques restent possibles (Kerberoasting AES, Overpass-the-Hash avec clé AES). Il est recommandé d'ajouter tous les comptes Domain Admin, Enterprise Admin et les comptes de service critiques à ce groupe, après avoir vérifié la compatibilité. Les comptes de service qui utilisent la délégation ne peuvent pas être membres de Protected Users sans casser la fonctionnalité. Le déploiement de Protected Users fait partie des mesures prioritaires du durcissement AD.

RBCD (Resource-Based Constrained Delegation)

La Resource-Based Constrained Delegation est un mécanisme de délégation Kerberos introduit avec Windows Server 2012 qui permet au service cible (et non au service source comme dans la délégation contrainte classique) de contrôler quels comptes peuvent lui présenter des tickets délégués. La configuration se fait via l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity sur le compte du service cible, qui contient un Security Descriptor listant les comptes autorisés à déléguer. Cette approche « basée sur les ressources » élimine le besoin d'un administrateur de domaine pour configurer la délégation, car le propriétaire du service cible peut modifier cet attribut lui-même. Du point de vue attaque, la RBCD est devenue l'un des vecteurs d'escalade de privilèges les plus courants. Le scénario d'exploitation typique nécessite deux conditions : un compte machine contrôlé par l'attaquant (créé via le MachineAccountQuota ou compromis) et le droit de modifier l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity du service cible (via GenericAll, GenericWrite, ou WriteDACL). L'attaquant configure la RBCD pour que son compte machine puisse déléguer vers le service cible, puis utilise S4U2Self et S4U2Proxy pour obtenir un ticket de service au nom d'un administrateur. L'outil Rubeus avec les commandes s4u et rbcd.py ou getST.py d'Impacket automatisent l'exploitation. La RBCD est souvent le résultat d'un relais NTLM vers LDAP qui modifie l'attribut de délégation. La défense consiste à réduire le MachineAccountQuota à 0, à auditer les modifications de l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity, et à surveiller les événements 5136 correspondants. Notre article sur la RBCD détaille les techniques et contre-mesures.

Replication (Réplication Active Directory)

La réplication Active Directory est le processus par lequel les modifications apportées à la base de données de l'annuaire sur un contrôleur de domaine sont propagées à tous les autres DC du domaine ou de la forêt. Active Directory utilise une réplication multi-maîtres : chaque DC est inscriptible et peut recevoir des modifications, qui sont ensuite répliquées vers les autres DC via le protocole DRS (Directory Replication Service Remote, MS-DRSR). La réplication utilise un mécanisme de convergence basé sur les USN (Update Sequence Numbers), les timestamps de modification, et un algorithme de résolution de conflits. La topologie de réplication est gérée par le KCC (Knowledge Consistency Checker) qui crée automatiquement des objets de connexion entre les DC. Du point de vue sécurité, le protocole de réplication est au coeur de certaines des attaques AD les plus critiques. L'attaque DCSync simule une demande de réplication légitime via l'opération GetNCChanges pour extraire les hachages de mots de passe. L'attaque DCShadow enregistre un faux DC et injecte des modifications via la réplication. Les droits nécessaires pour répliquer (DS-Replication-Get-Changes et DS-Replication-Get-Changes-All) doivent être strictement audités et limités aux comptes de DC légitimes. La surveillance de la réplication inclut le monitoring des événements 4662 avec les GUID de propriétés de réplication, la détection des sources de réplication non autorisées (événement 4929), et la vérification de la santé de la réplication avec repadmin /replsummary et dcdiag /test:replications. Les anomalies de réplication peuvent indiquer une attaque en cours ou des problèmes de configuration exploitables.

Responder

Responder est un outil de sécurité offensive développé par Laurent Gaffié qui exploite les protocoles de résolution de noms réseau (LLMNR, NBT-NS, mDNS) pour capturer les authentifications NTLM sur un réseau local. Lorsqu'une machine Windows ne parvient pas à résoudre un nom d'hôte via DNS, elle diffuse la requête via LLMNR et NBT-NS. Responder répond à ces requêtes en se faisant passer pour le serveur recherché, capturant le hachage NTLMv1 ou NTLMv2 du client qui tente de s'authentifier. L'outil inclut également des serveurs factices pour de nombreux protocoles : SMB, HTTP, HTTPS, FTP, LDAP, SQL, et WPAD. Le serveur WPAD est particulièrement efficace : en répondant aux requêtes de configuration proxy automatique, Responder peut intercepter le trafic HTTP de toutes les machines du réseau qui cherchent un proxy WPAD. Les hachages NTLMv2 capturés peuvent être crackés hors ligne avec hashcat (mode 5600) ou john, ou relayés en temps réel vers d'autres services avec le module MultiRelay ou ntlmrelayx.py. Responder est l'un des premiers outils exécutés lors d'un pentest Active Directory car il opère passivement sur le réseau et fournit rapidement des credentials exploitables. La défense multi-couches contre Responder comprend la désactivation de LLMNR et NBT-NS via GPO, la désactivation du proxy WPAD ou la publication d'un enregistrement DNS wpad pointant vers un serveur légitime, l'activation de la signature SMB (pour empêcher le relais SMB), la segmentation réseau (pour limiter la portée des broadcasts), et la surveillance réseau des réponses LLMNR/NBT-NS provenant de machines non légitimes. Le déploiement de capteurs réseau type IDS/IPS capables de détecter les réponses Responder complète le dispositif.

Rubeus

Rubeus est un outil de sécurité offensive développé en C# par Will Schroeder (GhostPack/SpecterOps) qui implémente de nombreuses attaques et interactions Kerberos dans les environnements Active Directory. Cet outil est devenu la référence pour la manipulation de tickets Kerberos sur les systèmes Windows, offrant des fonctionnalités complètes pour l'extraction, la forge, le renouvellement et l'injection de tickets. Les modules principaux de Rubeus incluent asktgt (demande de TGT avec mot de passe, hachage ou certificat — Overpass-the-Hash), asktgs (demande de TGS), kerberoast (extraction de tickets de service pour le cracking — Kerberoasting), asreproast (AS-REP Roasting), s4u (exploitation de S4U2Self et S4U2Proxy pour la délégation contrainte et RBCD), golden et silver (forge de Golden et Silver Tickets), ptt (injection de tickets en mémoire — Pass-the-Ticket), dump (extraction de tickets depuis la mémoire LSASS), tgtdeleg (extraction du TGT via un trick de délégation sans élévation), et harvest (monitoring continu des TGT). Rubeus est compilé en C# et peut être chargé en mémoire via des techniques d'exécution réflective (Assembly.Load), évitant l'écriture sur disque et la détection par les antivirus basés sur les signatures de fichiers. Les versions récentes incluent le support de la cryptographie AES et des améliorations de furtivité. La détection de Rubeus repose sur la surveillance des comportements plutôt que des signatures : demandes Kerberos inhabituelles (volume, type de chiffrement RC4, service cibles multiples), chargement de modules .NET en mémoire, et accès au processus LSASS. Les solutions EDR modernes détectent les patterns d'exécution de Rubeus, mais les variantes obfusquées continuent d'être efficaces.

SAM (Security Accounts Manager)

Le Security Accounts Manager est la base de données locale de Windows qui stocke les comptes utilisateurs et groupes locaux d'une machine, ainsi que les hachages de leurs mots de passe. Stockée dans le fichier C:\Windows\System32\config\SAM et verrouillée par le système pendant le fonctionnement, la base SAM utilise un chiffrement basé sur la clé BootKey (ou SysKey) stockée dans la ruche SYSTEM. Sur les stations de travail et serveurs membres, la SAM contient les comptes locaux comme l'administrateur local (RID 500), les comptes de service locaux, et les comptes créés localement. Sur les contrôleurs de domaine, la SAM contient le compte DSRM et quelques comptes système, car les comptes de domaine sont stockés dans NTDS.dit. Du point de vue sécurité offensive, l'extraction de la base SAM est une étape courante du credential dumping. Les techniques incluent la copie des ruches SAM et SYSTEM via les Volume Shadow Copies ou reg save (reg save HKLM\SAM sam.bak, reg save HKLM\SYSTEM system.bak), l'utilisation de secretsdump.py à distance, ou l'extraction en mémoire via Mimikatz (lsadump::sam). Les hachages extraits sont au format NT (MD4 du mot de passe Unicode) et peuvent être crackés ou utilisés en Pass-the-Hash. Le risque principal dans un contexte AD est le hachage de l'administrateur local : si ce mot de passe est identique sur toutes les machines (pas de LAPS), la compromission d'une seule SAM permet le mouvement latéral vers toutes les machines. La protection de la SAM inclut Credential Guard, le chiffrement BitLocker, la restriction des droits d'administration locale, et l'utilisation de LAPS pour des mots de passe uniques par machine.

Schema (Schéma Active Directory)

Le schéma Active Directory est la définition formelle de toutes les classes d'objets et de tous les attributs qui peuvent exister dans l'annuaire. Stocké dans la partition de schéma (CN=Schema,CN=Configuration,DC=forest-root,DC=com), le schéma est unique par forêt et répliqué sur tous les contrôleurs de domaine. Il définit les classes d'objets (user, computer, group, organizationalUnit, etc.) avec leurs attributs obligatoires et optionnels, les types de données, les syntaxes, et les règles d'héritage entre classes. Le schéma est extensible : des applications comme Exchange, Lync/Skype, SCCM et AD CS ajoutent de nouvelles classes et attributs lors de leur installation. Ces extensions sont irréversibles — une fois ajouté, un attribut ou une classe de schéma ne peut pas être supprimé, seulement désactivé. La modification du schéma nécessite l'appartenance au groupe Schema Admins et l'accès au DC détenant le rôle FSMO Schema Master. Du point de vue sécurité, le schéma est critique car il définit les attributs utilisés pour l'authentification, l'autorisation et le stockage des secrets. Les attributs comme unicodePwd (hachage du mot de passe), msDS-AllowedToDelegateTo (délégation), msDS-AllowedToActOnBehalfOfOtherIdentity (RBCD), msDS-KeyCredentialLink (Shadow Credentials), et adminCount (protection AdminSDHolder) sont définis dans le schéma. Les extensions de schéma malveillantes pourraient ajouter des attributs confidentiels ou modifier les attributs existants pour créer des backdoors. La surveillance des modifications du schéma (événement 5136 sur la partition de schéma) et la restriction du groupe Schema Admins (qui devrait être vide en temps normal) sont des mesures de sécurité essentielles.

SID (Security Identifier)

Un Security Identifier est un identifiant unique et immuable attribué à chaque principal de sécurité (utilisateur, groupe, ordinateur, domaine) dans un environnement Windows et Active Directory. Le SID est une structure binaire composée d'un numéro de révision, d'une autorité d'identification, et d'une série de sous-autorités. Le format textuel suit le schéma S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-YYYY où les valeurs X identifient le domaine et YYYY est le Relative Identifier (RID) spécifique à l'objet. Certains SID sont prédéfinis et identiques dans toutes les installations : S-1-5-18 (SYSTEM), S-1-5-32-544 (Administrators), S-1-5-21-domain-500 (Administrateur du domaine), S-1-5-21-domain-512 (Domain Admins), S-1-5-21-domain-519 (Enterprise Admins). Le SID est utilisé dans les ACL pour identifier les principaux de sécurité, dans les tickets Kerberos via le PAC (Privilege Attribute Certificate) pour transporter les appartenances aux groupes, et dans les jetons d'accès Windows pour les décisions d'autorisation. Du point de vue sécurité, la manipulation des SID est au coeur de plusieurs attaques : le Golden Ticket inclut des SID de groupes privilégiés dans le PAC forgé, l'injection de SID History ajoute des SID supplémentaires dans l'attribut sIDHistory d'un compte, et les attaques inter-domaines exploitent la résolution de SID entre domaines de confiance. Le SID Filtering est un mécanisme de sécurité qui vérifie que les SID dans les tickets inter-forêts correspondent au domaine d'origine, empêchant l'injection de SID étrangers. La compréhension des SID est fondamentale pour l'analyse de sécurité AD.

SID History

SID History est un attribut multi-valué (sIDHistory) des objets utilisateurs et groupes Active Directory qui stocke les anciens Security Identifiers (SID) d'un compte. Ce mécanisme a été conçu pour faciliter les migrations de domaine : lorsqu'un utilisateur est migré d'un ancien domaine vers un nouveau, son ancien SID est préservé dans l'attribut sIDHistory, lui permettant de continuer à accéder aux ressources de l'ancien domaine sans reconfigurer toutes les ACL. Lors de l'authentification, les SID de l'attribut sIDHistory sont ajoutés au token d'accès de l'utilisateur, exactement comme ses appartenances aux groupes. Du point de vue sécurité, SID History est un vecteur d'attaque redoutable pour la persistance et l'escalade de privilèges. Un attaquant disposant de privilèges suffisants (Domain Admin ou contrôle d'un DC) peut injecter le SID d'un groupe privilégié (par exemple, le SID du groupe Domain Admins ou Enterprise Admins) dans l'attribut sIDHistory d'un compte apparemment non privilégié. Ce compte bénéficiera alors de tous les droits du groupe dont le SID a été injecté, sans apparaître comme membre du groupe dans les outils de gestion standard. L'injection de sIDHistory peut se faire via Mimikatz (sid::add), via DCShadow (injection via la réplication), ou via des API de migration (DsAddSidHistory). La détection repose sur la surveillance de l'attribut sIDHistory de tous les comptes, en particulier la recherche de SID appartenant au domaine actuel (ce qui est anormal — normalement seuls des SID de domaines migrés devraient être présents). L'événement 4765 (SID History added) et l'audit des modifications de l'attribut sIDHistory (événement 5136) sont les indicateurs clés. Notre article sur l'injection SID History approfondit ces techniques.

Silver Ticket

Le Silver Ticket est une technique d'attaque qui consiste à forger un ticket de service (TGS) Kerberos en utilisant le hachage NTLM ou la clé AES du compte de service cible. Contrairement au Golden Ticket qui forge un TGT et nécessite le hachage du KRBTGT, le Silver Ticket cible un service spécifique et utilise le hachage du compte exécutant ce service. L'avantage principal est que le Silver Ticket ne nécessite aucune communication avec le KDC : le ticket est forgé localement et présenté directement au service, ce qui le rend plus furtif car il ne génère pas d'événement 4769 (TGS request) sur le DC. Les cibles courantes incluent les comptes machines des DC (pour accéder à CIFS, LDAP, ou RPC du DC), les comptes de service MSSQL, les comptes de service web (HTTP), et les comptes machines des serveurs de fichiers. La forge se fait avec Mimikatz (kerberos::golden /service:cifs /target:server) ou Impacket (ticketer.py -spn cifs/server), en fournissant le hachage du service, le SID du domaine, et les informations d'utilisateur à usurper (incluant les appartenances aux groupes dans le PAC). La durée de vie du Silver Ticket est définie par l'attaquant et peut être très longue. Les limitations incluent le fait que l'accès est restreint au service spécifique (pas d'accès universel comme le Golden Ticket), et que le PAC Validation (si activé) peut détecter les tickets avec un PAC invalide en vérifiant la signature KDC. Les défenses comprennent la rotation régulière des mots de passe des comptes de service (via gMSA), l'activation de la validation PAC, et la surveillance des accès de service sans demande TGS préalable. Notre article sur le Silver Ticket détaille l'analyse technique.

Skeleton Key

Le Skeleton Key est une technique de persistance qui consiste à injecter un « passe-partout » dans la mémoire du processus LSASS d'un contrôleur de domaine, permettant à l'attaquant de s'authentifier avec n'importe quel compte du domaine en utilisant un mot de passe unique prédéfini. L'implémentation la plus connue est le module misc::skeleton de Mimikatz, qui patche en mémoire les routines de vérification de mot de passe du DC pour accepter le mot de passe « mimikatz » (ou tout autre mot de passe configurable) en plus du vrai mot de passe de chaque utilisateur. Les vrais mots de passe continuent de fonctionner normalement, rendant l'attaque transparente pour les utilisateurs légitimes. L'attaque nécessite un accès administrateur ou SYSTEM sur le contrôleur de domaine et doit être réexécutée après chaque redémarrage du DC car les modifications sont en mémoire uniquement. Les mots de passe réels des utilisateurs ne sont pas modifiés et les hachages dans NTDS.dit restent intacts. Du point de vue détection, le Skeleton Key modifie le processus LSASS d'une manière détectable par plusieurs approches : l'analyse de la mémoire du processus LSASS (recherche de patterns de patch), la surveillance des DLL chargées par LSASS (recherche de DLL injectées), les événements de chargement de pilote ou de module suspectes (Sysmon Event ID 7), et les solutions EDR qui surveillent l'intégrité du processus LSASS. Le déploiement de LSASS en mode Protected Process Light (RunAsPPL) empêche l'injection de code dans LSASS et constitue la contre-mesure principale. Credential Guard, qui isole les opérations cryptographiques dans un environnement virtualisé, offre une protection supplémentaire. La surveillance des événements d'authentification anormaux (mêmes credentials utilisés pour des comptes différents) peut aider à la détection comportementale. Notre article sur Skeleton Key explore cette technique en profondeur.

SPN (Service Principal Name)

Un Service Principal Name est un identifiant unique enregistré dans Active Directory qui associe une instance de service à un compte d'ouverture de session. Les SPN suivent le format serviceclass/host:port/servicename, par exemple MSSQLSvc/sqlserver.domain.com:1433 ou HTTP/webserver.domain.com. Ils sont stockés dans l'attribut servicePrincipalName de l'objet utilisateur ou ordinateur qui exécute le service. Les SPN sont essentiels au fonctionnement de l'authentification Kerberos car ils permettent au client de localiser le service et au KDC d'identifier le compte avec lequel chiffrer le ticket de service. Sans SPN correctement configuré, l'authentification Kerberos échoue et le système retombe sur NTLM. Du point de vue sécurité, les SPN sont au coeur de l'attaque Kerberoasting : tout compte utilisateur disposant d'un SPN est un candidat potentiel au Kerberoasting, car n'importe quel utilisateur authentifié peut demander un TGS chiffré avec le hachage du compte de service. Les SPN enregistrés sur des comptes machines sont moins risqués car les mots de passe machines sont longs (240 caractères) et aléatoires. Les SPN sur des comptes utilisateurs sont les plus vulnérables, surtout si les mots de passe sont faibles. L'attaque « targeted Kerberoasting » consiste à ajouter un SPN à un compte (si l'attaquant a le droit de modifier l'attribut servicePrincipalName) pour le rendre kerberoastable. La vérification des duplications de SPN (setspn -X), l'audit des comptes avec SPN (Get-ADUser -Filter {ServicePrincipalName -ne "$null"}), et la migration vers des gMSA font partie des mesures de sécurité. La surveillance des modifications de l'attribut SPN (événement 5136) permet de détecter les tentatives de targeted Kerberoasting.

SYSVOL

SYSVOL (System Volume) est un partage réseau spécial présent sur chaque contrôleur de domaine qui stocke les fichiers de stratégies de groupe (GPO), les scripts de connexion/déconnexion/démarrage/arrêt, et d'autres fichiers de politique de domaine. Le chemin par défaut est C:\Windows\SYSVOL\sysvol et le partage est accessible via \\domain.com\SYSVOL. Le contenu du SYSVOL est répliqué entre tous les DC du domaine via DFS-R (ou FRS pour les domaines plus anciens). Tout utilisateur authentifié du domaine peut lire le SYSVOL, ce qui est nécessaire pour le téléchargement des GPO. Du point de vue sécurité, le SYSVOL est une source fréquente de credentials exposés. L'une des vulnérabilités historiques les plus connues (MS14-025, « Group Policy Preferences password ») impliquait des mots de passe stockés dans les fichiers de préférences GPP du SYSVOL, chiffrés avec une clé AES publiquement connue. Bien que Microsoft ait corrigé cette vulnérabilité en supprimant la possibilité de stocker de nouveaux mots de passe, les anciens fichiers Groups.xml, Services.xml, ScheduledTasks.xml, et DataSources.xml contenant des mots de passe chiffrés peuvent encore exister dans le SYSVOL. Les scripts de connexion stockés dans le SYSVOL peuvent également contenir des credentials en clair, des chaînes de connexion, ou des informations sensibles. L'outil findstr ou des scripts PowerShell peuvent scanner le SYSVOL à la recherche de mots de passe. La sécurisation du SYSVOL comprend le nettoyage des anciens fichiers GPP avec mots de passe, l'audit régulier des scripts de connexion, la surveillance de l'intégrité des fichiers GPO (modification non autorisée), et la restriction des modifications du SYSVOL aux seuls administrateurs autorisés. La signature SMB doit être activée pour protéger l'accès au SYSVOL.

Tier Model (Modèle de Tiering)

Le Tier Model, ou modèle de tiering, est une architecture de sécurité recommandée par Microsoft pour protéger les environnements Active Directory en segmentant les actifs et les credentials en trois niveaux de sécurité distincts. Le Tier 0 comprend les actifs de contrôle du domaine : contrôleurs de domaine, comptes Domain Admin et Enterprise Admin, serveurs AD CS, serveurs ADFS, et comptes de service critiques. Le Tier 1 englobe les serveurs d'application : serveurs de bases de données, serveurs de messagerie, serveurs de fichiers, et les comptes d'administration de ces serveurs. Le Tier 2 regroupe les postes de travail des utilisateurs finaux, les périphériques, et les comptes utilisateurs standard. Le principe fondamental est l'isolation des credentials : un compte de Tier 0 ne doit jamais s'authentifier sur un actif de Tier 1 ou Tier 2, et vice versa. Si un administrateur de domaine se connecte à un poste de travail compromis, son hachage NTLM ou son TGT peut être extrait de la mémoire, compromettant le Tier 0. Le modèle impose des PAW (Privileged Access Workstations) dédiées pour chaque tier, des comptes d'administration séparés par tier, et des restrictions de connexion via GPO (Allow log on locally, Deny log on through Remote Desktop Services). L'implémentation du tiering est considérée comme la mesure de sécurité AD la plus impactante mais aussi la plus difficile à déployer, nécessitant une refonte des processus opérationnels. Nos articles sur le Tiering Model et le Tiering Model face aux menaces 2026 détaillent l'implémentation pratique et les adaptations nécessaires face aux nouvelles techniques d'attaque.

TGS (Ticket Granting Service)

Le Ticket Granting Service est à la fois un sous-service du KDC Kerberos et le ticket de service émis par ce sous-service. Le TGS (en tant que service) reçoit les demandes des clients qui présentent un TGT valide et émet des tickets de service (TGS tickets ou Service Tickets) permettant l'accès à des services spécifiques. Le flux TGS-REQ/TGS-REP constitue la deuxième phase de l'authentification Kerberos : le client envoie son TGT au KDC en spécifiant le SPN du service souhaité, le KDC vérifie le TGT, et renvoie un ticket de service chiffré avec la clé du compte de service cible. Le ticket de service contient le PAC (Privilege Attribute Certificate) de l'utilisateur, les informations de session, et une clé de session partagée entre le client et le service. Du point de vue sécurité, les tickets de service sont au coeur de plusieurs attaques. Le Kerberoasting exploite le fait que le TGS est chiffré avec le hachage du compte de service : en demandant un TGS pour un service avec un compte utilisateur (et non un compte machine), l'attaquant peut tenter de casser le hachage hors ligne. Le Silver Ticket forge un TGS complet sans passer par le KDC, en utilisant directement le hachage du service. La durée de vie par défaut du TGS est de 10 heures (configurée dans la Default Domain Policy sous « Maximum lifetime for service ticket »). Les événements 4769 enregistrent les demandes de TGS et sont essentiels pour la détection du Kerberoasting (volume anormal de demandes, chiffrement RC4). La défense inclut la migration vers AES (plus résistant au cracking), l'utilisation de gMSA, et la surveillance des anomalies dans les patterns de demandes TGS.

TGT (Ticket Granting Ticket)

Le Ticket Granting Ticket est le ticket Kerberos initial obtenu par un utilisateur lors de son authentification auprès du KDC. Le TGT agit comme un « passeport » qui prouve l'identité de l'utilisateur et lui permet de demander des tickets de service (TGS) pour accéder aux différentes ressources du domaine sans avoir à se ré-authentifier. Le flux d'obtention du TGT est le AS-REQ/AS-REP : le client envoie une demande d'authentification au KDC (avec un timestamp chiffré comme pré-authentification), et le KDC répond avec un TGT chiffré avec la clé du compte KRBTGT. Le client ne peut pas déchiffrer le TGT lui-même — il le stocke dans son cache de tickets et le présente au TGS pour les demandes de service ultérieures. Le TGT contient le PAC de l'utilisateur (SID, appartenances aux groupes, privilèges), les informations de session, le timestamp d'émission, et la durée de validité. Par défaut, un TGT a une durée de vie de 10 heures et peut être renouvelé pendant 7 jours. Du point de vue sécurité, le TGT est la cible principale de plusieurs attaques. Le Golden Ticket forge un TGT en utilisant le hachage KRBTGT, le Pass-the-Ticket vole un TGT légitime depuis la mémoire, et l'Overpass-the-Hash convertit un hachage en TGT. Le vol d'un TGT sur un serveur avec délégation non contrainte est un scénario critique. Les protections incluent l'ajout au groupe Protected Users (TGT de 4 heures, non renouvelable), Credential Guard (isolation du TGT en mémoire), la rotation du KRBTGT, et la surveillance des événements 4768 (TGT requests) pour détecter les anomalies de pré-authentification et de chiffrement.

Token (Jeton d'Accès Windows)

Un Token, ou jeton d'accès Windows, est une structure de données créée par le système d'exploitation lors de l'authentification d'un utilisateur, contenant l'ensemble de ses informations de sécurité : son SID, les SID de tous ses groupes, les privilèges assignés (SeDebugPrivilege, SeImpersonatePrivilege, etc.), et le niveau d'intégrité. Chaque processus et chaque thread exécutés par l'utilisateur héritent de ce token, qui est utilisé par le système pour toutes les décisions d'autorisation. Il existe deux types de tokens : le token primaire (assigné au processus) et le token d'impersonation (utilisé par un thread pour agir au nom d'un autre utilisateur). Du point de vue sécurité, la manipulation de tokens est une technique d'escalade de privilèges et de mouvement latéral. L'impersonation de token permet à un processus disposant du privilège SeImpersonatePrivilege (attribué par défaut aux comptes de service, IIS, MSSQL) d'usurper l'identité d'un utilisateur se connectant au service. Les attaques « Potato » (Hot Potato, Juicy Potato, Sweet Potato, Rogue Potato, God Potato) exploitent ce mécanisme pour escalader de comptes de service vers SYSTEM. L'outil Mimikatz via token::elevate et token::impersonate permet de lister et d'utiliser les tokens disponibles sur un système. Les tokens de connexion réseau (logon type 3) ne stockent pas de credentials en mémoire, contrairement aux connexions interactives (logon type 2) et RDP (logon type 10). La protection passe par la restriction des privilèges SeImpersonatePrivilege et SeAssignPrimaryTokenPrivilege aux seuls comptes qui en ont besoin, la surveillance des événements de manipulation de tokens (4672 pour les privilèges spéciaux), et la réduction des sessions interactives sur les serveurs.

Trust (Relation de Confiance)

Un Trust, ou relation de confiance, est un lien logique établi entre deux domaines ou forêts Active Directory qui permet l'accès aux ressources entre les environnements. Les trusts définissent les frontières d'authentification et d'autorisation dans les architectures multi-domaines. Dans Active Directory, les trusts sont matérialisés par des Trusted Domain Objects (TDO) qui contiennent les informations de confiance, y compris la clé de confiance partagée (trust password/key) utilisée pour le chiffrement inter-domaines. Les trusts se caractérisent par leur direction (unidirectionnel ou bidirectionnel), leur transitivité (transitif ou non transitif), et leur type (parent-child, tree-root, forest, external, realm, PAM). Les trusts intra-forêt (parent-child et tree-root) sont automatiques, bidirectionnels et transitifs, formant un réseau de confiance complet au sein de la forêt. Les trusts inter-forêts (forest trusts) sont manuels et offrent des protections supplémentaires comme le SID Filtering. Du point de vue sécurité, les trusts étendent intrinsèquement la surface d'attaque en créant des ponts entre environnements. La compromission d'un domaine peut mener à la compromission des domaines de confiance via l'extraction des trust keys (par DCSync du TDO), la forge de tickets de référence inter-domaines, l'exploitation de comptes partagés entre domaines, ou l'abus de permissions accordées aux Foreign Security Principals. Les attaques inter-forêts sont limitées par le SID Filtering mais pas complètement éliminées. La sécurisation des trusts implique l'activation de Selective Authentication, la réduction du nombre de trusts au strict nécessaire, l'audit des permissions inter-domaines, la rotation des trust passwords, et la surveillance des authentifications inter-domaines. Notre article sur le Forest Trust Abuse explore ces risques en détail.

Unconstrained Delegation (Délégation Non Contrainte)

L'Unconstrained Delegation, ou délégation Kerberos non contrainte, est le mécanisme de délégation le plus ancien et le plus dangereux d'Active Directory. Lorsqu'un serveur est configuré avec le flag TRUSTED_FOR_DELEGATION dans son attribut userAccountControl, tout utilisateur qui s'authentifie auprès de ce serveur via Kerberos voit son TGT complet transmis et stocké dans la mémoire LSASS du serveur. Le serveur peut alors utiliser ce TGT pour accéder à n'importe quel service du domaine au nom de l'utilisateur, sans aucune restriction sur les services cibles. Ce mécanisme a été conçu pour les scénarios multi-tiers (par exemple, un serveur web qui doit accéder à une base de données avec les credentials de l'utilisateur), mais il représente un risque de sécurité majeur. Le scénario d'attaque principal combine la délégation non contrainte avec la coercion d'authentification. L'attaquant compromet un serveur avec délégation non contrainte, puis utilise le Printerbug, PetitPotam ou une autre technique de coercion pour forcer un contrôleur de domaine à s'authentifier auprès de ce serveur. Le TGT du compte machine du DC est alors capturé en mémoire et peut être utilisé pour un DCSync, compromettant le domaine entier. L'outil Rubeus avec monitor /interval:1 automatise la capture des TGT sur un serveur avec délégation non contrainte. Les défenses incluent l'identification et la suppression de la délégation non contrainte partout où possible (migration vers la délégation contrainte ou RBCD), l'ajout des comptes sensibles au groupe Protected Users (qui empêche la mise en cache du TGT), la surveillance des événements 4624 avec logon type 3 sur les serveurs avec délégation non contrainte, et la restriction de la coercion en désactivant les services non nécessaires (Print Spooler) sur les DC.

WBAD (Windows Backup Active Directory)

WBAD fait référence aux mécanismes et outils de sauvegarde d'Active Directory, principalement via Windows Server Backup (wbadmin) et les API VSS (Volume Shadow Copy Service). La sauvegarde AD est une opération critique qui capture l'état complet de l'annuaire, y compris la base de données NTDS.dit, les ruches de registre SYSTEM et SECURITY, le SYSVOL, et les certificats. Dans le contexte de la sécurité, les sauvegardes AD représentent à la fois une mesure défensive essentielle et un risque potentiel si elles ne sont pas correctement protégées. Du point de vue offensif, les sauvegardes AD sont une cible de choix car elles contiennent une copie intégrale de NTDS.dit avec tous les hachages de mots de passe du domaine. L'utilitaire wbadmin peut être utilisé par un attaquant disposant de droits Backup Operator pour créer une sauvegarde du System State, extraire NTDS.dit et les ruches de registre, puis déchiffrer tous les hachages hors ligne avec secretsdump.py. La commande ntdsutil "activate instance ntds" "ifm" "create full C:\temp" crée une copie IFM (Install From Media) contenant NTDS.dit et les ruches, offrant un autre vecteur d'extraction. Les sauvegardes existantes mal protégées (stockées sur des partages réseau sans contrôle d'accès, sur des bandes non chiffrées, ou sur des serveurs de sauvegarde faiblement sécurisés) représentent un risque comparable à une compromission directe du DC. La sécurisation des sauvegardes AD inclut le chiffrement de toutes les sauvegardes (BitLocker, chiffrement natif de wbadmin), la restriction de l'accès aux fichiers de sauvegarde, la surveillance des opérations wbadmin et ntdsutil (événements 1917 et 2170), la rotation régulière et la destruction sécurisée des anciennes sauvegardes, et le traitement des serveurs de sauvegarde comme des actifs Tier 0.

WPAD (Web Proxy Auto-Discovery)

WPAD est un protocole qui permet aux navigateurs web et aux applications de découvrir automatiquement la configuration du proxy à utiliser pour accéder à Internet. Le mécanisme fonctionne en recherchant un fichier de configuration wpad.dat (ou proxy.pac) via plusieurs méthodes : d'abord une requête DNS pour wpad.domain.com, puis via DHCP (option 252), et enfin via les protocoles de résolution locale (LLMNR, NBT-NS). Du point de vue sécurité, WPAD est un vecteur d'attaque classique dans les environnements Active Directory. Si aucun enregistrement DNS wpad n'est configuré dans le domaine, les requêtes de résolution tombent dans les protocoles broadcast (LLMNR/NBT-NS) et peuvent être interceptées par un outil comme Responder. L'attaquant répond à la requête WPAD, fournit un fichier PAC malveillant qui configure son propre serveur comme proxy, et peut alors intercepter tout le trafic HTTP des machines victimes. Cela inclut potentiellement les authentifications NTLM vers des services web internes, les cookies de session, et les données sensibles transitant en HTTP. L'attaque WPAD est particulièrement efficace car de nombreux systèmes Windows activent par défaut la détection automatique du proxy. La mitigation comprend la création d'un enregistrement DNS wpad pointant vers un serveur légitime (ou un serveur retournant une configuration « DIRECT » sans proxy), la désactivation de WPAD via GPO (« Disable Automatic Discovery » dans les paramètres Internet Explorer/Edge), la désactivation de LLMNR et NBT-NS (qui élimine également ce vecteur), et la surveillance des requêtes de résolution pour le nom wpad. Dans les environnements nécessitant un proxy, la configuration explicite via GPO est préférable à la découverte automatique WPAD.

WriteDACL

WriteDACL est un droit de contrôle d'accès Active Directory qui permet à un principal de sécurité de modifier la DACL (Discretionary Access Control List) d'un objet. Ce droit est l'un des plus dangereux dans l'écosystème AD car il confère essentiellement un contrôle total : un attaquant disposant de WriteDACL peut s'octroyer n'importe quel autre droit sur l'objet, puis exploiter ces droits pour atteindre son objectif. Les scénarios d'abus typiques incluent l'ajout du droit DS-Replication-Get-Changes-All sur l'objet domaine (pour effectuer un DCSync), l'ajout de GenericAll sur un compte administrateur (pour réinitialiser son mot de passe), l'ajout de droits d'écriture sur l'attribut msDS-AllowedToActOnBehalfOfOtherIdentity (pour configurer une RBCD), ou l'ajout de droits d'inscription sur un modèle de certificat AD CS. L'exploitation de WriteDACL se fait via des outils comme PowerView (Add-DomainObjectAcl), dacledit.py d'Impacket, ou directement via les commandes .NET DirectoryEntry.ObjectSecurity. Les attaquants ciblent WriteDACL car c'est un droit qui peut être attribué de manière légitime dans le cadre de la délégation d'administration, et qui est souvent accordé excessivement. Par exemple, les équipes helpdesk peuvent avoir WriteDACL sur les OUs utilisateurs pour gérer les permissions, créant involontairement un chemin d'escalade de privilèges. BloodHound identifie et cartographie les relations WriteDACL pour révéler ces chemins. La détection repose sur la surveillance des événements 5136 (modification d'objet AD) ciblant les attributs de sécurité, et la mitigation consiste à auditer toutes les délégations WriteDACL avec ADACLScanner et à les remplacer par des permissions plus spécifiques quand possible.

WriteOwner

WriteOwner est un droit de contrôle d'accès Active Directory qui permet à un principal de sécurité de modifier le propriétaire d'un objet. Ce droit est particulièrement dangereux car le propriétaire d'un objet AD dispose implicitement du droit de modifier les permissions (WriteDACL) de cet objet. Ainsi, un attaquant disposant de WriteOwner peut s'établir comme propriétaire de l'objet, puis modifier les ACL pour s'octroyer des droits supplémentaires (GenericAll, WriteDACL, etc.), et enfin exploiter ces droits pour atteindre son objectif. La chaîne d'exploitation est donc WriteOwner -> prise de propriété -> WriteDACL -> ajout de permissions -> exploitation. L'exploitation se fait via PowerView (Set-DomainObjectOwner) ou les API .NET (DirectoryEntry.ObjectSecurity.SetOwner). Les scénarios d'abus incluent la prise de propriété d'un groupe privilégié (pour pouvoir s'y ajouter), d'un compte de service (pour réinitialiser son mot de passe), d'un modèle de certificat (pour le modifier et le rendre vulnérable), ou de la racine du domaine (pour s'octroyer des droits DCSync). WriteOwner est souvent accordé de manière indirecte : les membres du groupe Account Operators, par exemple, possèdent par défaut des permissions étendues qui peuvent inclure WriteOwner sur certains objets. BloodHound identifie les relations WriteOwner et les intègre dans l'analyse des chemins d'attaque. La détection des abus WriteOwner repose sur la surveillance des changements de propriétaire d'objets sensibles (événement 5136 ciblant l'attribut nTSecurityDescriptor), et la prévention passe par l'audit régulier de toutes les ACE accordant WriteOwner, en privilégiant des délégations de permissions plus spécifiques. Le remplacement de WriteOwner par des droits ciblés (comme ResetPassword ou WriteProperty sur des attributs spécifiques) réduit considérablement la surface d'attaque.

ZeroLogon (CVE-2020-1472)

ZeroLogon, identifié sous CVE-2020-1472, est une vulnérabilité critique dans le protocole Netlogon Remote Protocol (MS-NRPC) de Microsoft, découverte par Tom Tervoort de Secura. Cette vulnérabilité permet à un attaquant non authentifié d'établir un canal sécurisé Netlogon avec un contrôleur de domaine en fixant le mot de passe du canal à une valeur nulle (composée uniquement de zéros). Le score CVSS est de 10.0/10.0, reflétant la gravité maximale. Le bug réside dans l'implémentation du chiffrement AES-CFB8 dans le protocole Netlogon : en utilisant un IV (Initialization Vector) composé de zéros et un texte en clair composé de zéros, il y a 1 chance sur 256 que le texte chiffré soit également composé de zéros. En réessayant l'authentification environ 256 fois (ce qui prend quelques secondes), l'attaquant réussit statistiquement à s'authentifier sans connaître le mot de passe du compte machine. L'exploitation la plus courante cible le compte machine du contrôleur de domaine lui-même : l'attaquant réinitialise le mot de passe du compte machine du DC à une chaîne vide, puis utilise ce mot de passe pour se connecter et exécuter un DCSync, extrayant tous les hachages du domaine. L'impact est dévastateur : une compromission complète du domaine depuis le réseau local, sans aucune authentification préalable. Les exploits publics incluent des implémentations en Python (utilisant Impacket), C et C#. La remédiation nécessite l'application immédiate du correctif Microsoft (août 2020) et l'activation du mode « enforcement » qui rejette les connexions Netlogon vulnérables. La surveillance des événements 5829 (connexion Netlogon non sécurisée autorisée) et 5827/5828 (connexion refusée) permet de détecter les tentatives d'exploitation et les systèmes non mis à jour.