Active Directory : la révision 2026 du guide CISA

Le 15 septembre 2026, une révision du guide Detecting and mitigating Active Directory compromises est mise en ligne. Le document est rédigé par l’Australian Signals Directorate, ASD (1), via son Australian Cyber Security Centre, et cosigné par la Cybersecurity and Infrastructure Security Agency, CISA (2), la National Security Agency, le Centre canadien pour la cybersécurité, le National Cyber Security Centre britannique et son homologue néo-zélandais. La première version datait du 26 septembre 2024. Le guide couvre soixante-quatorze pages et est publié sous licence Creative Commons Attribution 4.0.

Le périmètre est celui des trois services d’annuaire de Microsoft : Active Directory Domain Services, AD DS (3), Active Directory Certificate Services, AD CS (4), et Active Directory Federation Services, AD FS (5). Les techniques sont présentées dans l’ordre où elles sont habituellement exécutées, en partant de l’élévation de privilèges et du déplacement latéral pour finir par la persistance. Chaque technique est traitée selon trois volets : le mécanisme, les contrôles d’atténuation, les événements de détection.

La révision de 2026 apporte deux changements de fond. Le premier est l’ajout de la technique Shadow Credentials, qui exploite l’attribut msDS-KeyCredentialLink. Le second est la refonte de la détection du DCSync, qui repose désormais sur l’audit des appels de procédure distante plutôt que sur l’audit d’accès aux objets d’annuaire.

Avant d’entrer dans les techniques, le guide pose un préalable : la sécurisation des accès à privilèges selon le modèle en tiers de Microsoft, l’Enterprise Access Model, qui remplace l’ancien Active Directory Administrative Tier Model et prend en compte les environnements hybrides.

Le tier 0 rassemble les objets utilisateur disposant d’un accès significatif au domaine : membres des groupes Domain Admins et Enterprise Admins, objet KRBTGT (6), compte de service AD FS, administrateurs de sauvegarde, objets utilisateur de Microsoft Entra Connect. Côté machines, il rassemble les contrôleurs de domaine, le serveur AD FS, l’autorité de certification racine, les serveurs de sauvegarde et le serveur Microsoft Entra Connect.

• Les objets utilisateur de tier 0 n’exposent jamais leurs identifiants à des systèmes de tier inférieur.
• Les objets ordinateur de tier 0 ne sont administrés que par des objets utilisateur de tier 0.
• Les tiers inférieurs consomment les services des tiers supérieurs, jamais l’inverse.
• Les chemins d’accès à privilèges sont réduits en nombre, protégés et surveillés.

Les objets de tier 0 appellent des protections supplémentaires : authentification multifacteur, MFA (7), résistante au phishing, postes d’administration dédiés, Kerberos armoring et application de politiques de confiance zéro. Le guide est explicite sur l’effet attendu : ce modèle rend plusieurs des techniques décrites impossibles, et contraint les acteurs malveillants à des méthodes plus complexes, donc plus détectables.

Huit techniques servent à gagner des privilèges ou à se déplacer dans le domaine. Elles ont un point commun opérationnel : elles reposent sur des fonctionnalités légitimes d’Active Directory et produisent les mêmes événements que l’activité normale. La détection tient donc rarement à la présence d’un événement, presque toujours à son volume, à ses champs ou à son contexte.

Kerberoasting

Tout objet utilisateur porteur d’un service principal name, SPN (8), voit son ticket de service, TGS (9), délivrable à n’importe quel autre objet utilisateur du domaine, y compris non privilégié. Ce ticket est chiffré avec le hash du mot de passe de l’objet, qui peut être cassé hors ligne pour en révéler le mot de passe en clair.

La détection porte sur l’événement 4769, généré à chaque demande de TGS. Deux champs sont discriminants. Le type de chiffrement du ticket à 0x17 signale le RC4 (10), que les acteurs malveillants privilégient parce qu’il se casse plus vite ; ce type étant peu fréquent, son volume résiduel est exploitable comme signal. Le champ Ticket Options aux valeurs 0x40800000 ou 0x40810000 correspond aux réglages par défaut des outils offensifs. Les événements 4738 et 5136 complètent le dispositif : ils tracent la modification d’un objet utilisateur, technique par laquelle un SPN est ajouté le temps de récupérer le ticket, puis retiré.

Les contrôles d’atténuation sont au nombre de quatre : réduire le nombre d’objets utilisateur porteurs d’un SPN ; les créer en group Managed Service Accounts, gMSA (11), qui imposent un mot de passe de 120 caractères en rotation automatique, ou à défaut un mot de passe de 30 caractères minimum, unique et géré ; leur attribuer les privilèges strictement nécessaires et les tenir hors des groupes à hauts privilèges ; activer le chiffrement AES (12), Active Directory utilisant RC4 par défaut pour les tickets de service.

AS-REP Roasting

La variante s’applique aux objets utilisateur configurés pour ne pas exiger la pré-authentification Kerberos. Le ticket d’attribution de tickets, TGT (13), est alors renvoyé dans la réponse du serveur d’authentification, chiffré avec le hash du mot de passe, et se casse de la même manière. Cette configuration n’existe que pour les systèmes antérieurs à Kerberos version 5.

La détection porte sur l’événement 4768, généré à la demande de TGT, avec la même logique de volume sur une fenêtre courte. L’événement 4625 s’y ajoute : l’AS-REP Roasting peut être exécuté avant toute authentification, sans objet utilisateur valide, ce qui produit un échec de connexion alors que le ticket est tout de même délivré. La corrélation de 4625 et de 4768 permet de déterminer si la technique a été exécutée dans le contexte d’un objet utilisateur valide. Les événements 4738 et 5136 tracent les modifications de la configuration de pré-authentification.

Le contrôle d’atténuation est unique : exiger la pré-authentification Kerberos sur tous les objets utilisateur. Pour les rares cas où elle doit être levée, le guide demande des privilèges minimaux, l’exclusion des groupes à hauts privilèges, et un mot de passe de 30 caractères minimum pour les comptes de service, de 15 caractères minimum pour les utilisateurs.

Password spraying

Le password spray consiste à tester un mot de passe unique, ou un petit nombre de mots de passe, sur une large liste d’objets utilisateur, en restant sous le seuil de verrouillage. Le guide signale un point souvent ignoré : le compte Administrator intégré au domaine n’est pas soumis au seuil de verrouillage. Même signalé comme verrouillé, il reste authentifiable si le bon mot de passe est fourni, ce qui remet le compteur d’échecs à zéro. Il doit donc être traité en compte de bris de glace, avec un mot de passe de 30 caractères minimum, marqué comme sensible et non délégable, et sous surveillance.

Second point : le MFA est largement inopérant contre cette technique une fois l’accès initial obtenu, parce que l’authentification peut se faire directement auprès d’un contrôleur de domaine via NTLM (14), qui ne le supporte pas. Le guide recommande de désactiver NTLM et, lorsque ce n’est pas possible, d’activer le channel binding LDAP (15), l’extended protection for authentication et la signature SMB (16).

L’attribut badPasswordTime complète ces événements : si plusieurs objets utilisateur portent la même date et heure de dernier échec, ou des valeurs très proches, le password spray est probable. Côté atténuation, le guide demande des mots de passe de 30 caractères minimum pour les comptes d’administration locale, de service et de bris de glace, gérés par Local Administrator Password Solution, LAPS (17), où c’est possible ; quatre mots aléatoires et 15 caractères minimum pour l’authentification à facteur unique ; un verrouillage après cinq échecs au maximum, sauf pour les comptes de bris de glace ; des mots de passe générés aléatoirement à la création et à la réinitialisation ; un balayage mensuel du réseau à la recherche d’identifiants stockés en clair.

Compromission de MachineAccountQuota

L’attribut ms-DS-MachineAccountQuota autorise par défaut tout objet utilisateur à créer jusqu’à dix objets ordinateur dans le domaine. Ces objets rejoignent automatiquement le groupe Domain Computers et en héritent les privilèges. Si ce groupe est trop privilégié, l’acteur malveillant crée son propre objet ordinateur, s’authentifie sous son identité et remonte d’un cran. La technique sert aussi d’amorce au KrbRelayUp lorsque la signature LDAP n’est pas imposée, avec pour résultat une élévation au rang d’administrateur local.

Trois événements suffisent : 4741 à la création de l’objet ordinateur, à analyser au regard de l’objet créateur ; 4724, tentative de réinitialisation de mot de passe, généré au même moment ou presque puisque l’objet doit recevoir un mot de passe pour être utilisable ; 4624, à corréler pour établir que l’objet créé s’est bien authentifié.

L’atténuation tient en quatre points : porter MS-DS-MachineAccountQuota à zéro, le besoin réel étant limité aux administrateurs ; vérifier que Domain Computers n’est membre d’aucun groupe privilégié ; vérifier qu’il ne dispose d’aucun droit d’écriture sur un objet d’Active Directory ; activer la signature LDAP sur les contrôleurs de domaine, ce qui traite également KrbRelayUp.

Délégation non contrainte

Lorsqu’un objet ordinateur est configuré pour la délégation non contrainte, une copie du TGT de chaque objet utilisateur qui s’y authentifie est conservée dans le processus Local Security Authority Subsystem Service, LSASS (18), de cette machine. Un acteur malveillant qui obtient les droits d’administration locale y extrait les tickets. Plusieurs techniques permettent de forcer un objet à s’authentifier sur la machine visée : le guide cite le service de spouleur d’impression d’un contrôleur de domaine, dont l’abus permet de récupérer le TGT du compte ordinateur du contrôleur lui-même.

La détection combine cinq événements, dont quatre collectés sur les machines configurées pour la délégation non contrainte et non sur les contrôleurs de domaine : 4103 et 4104 pour l’activité PowerShell, dont se servent les outils courants ; 4624 pour les authentifications inhabituelles, et côté contrôleur de domaine pour les connexions dont l’adresse source correspond à une machine en délégation non contrainte ; 4688 pour la création de processus, avec les commandes d’extraction de LSASS que le guide cite explicitement, procdump.exe -accepteula -ma lsass.exe lsass.dmp, rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump <PID> C:\lsass.dmp full et sekurlsa::minidump ; 4770 pour le renouvellement d’un TGT, la durée de vie maximale étant de sept jours par défaut.

L’atténuation la plus efficace est de supprimer la délégation non contrainte au profit de la délégation contrainte basée sur les ressources. S’y ajoutent trois contrôles : marquer les objets utilisateur privilégiés comme sensibles et non délégables ; les placer dans le groupe Protected Users, dont les membres ne peuvent pas être délégués ; désactiver le spouleur d’impression sur les contrôleurs de domaine.

Mot de passe dans les préférences de stratégie de groupe

La CVE-2014-1812 a permis de déchiffrer les mots de passe distribués par les préférences de stratégie de groupe, GPP (19). Ces valeurs, appelées cpasswords, résident dans le répertoire SYSVOL (20) présent sur chaque contrôleur de domaine et lisible par tous les utilisateurs du domaine. La clé privée de chiffrement a été publiée vers 2012. Le correctif Microsoft 2962486, publié en 2014 sous le bulletin MS14-025, a retiré la fonctionnalité de création, mais n’a pas supprimé les cpasswords existants, dont l’effacement reste une opération manuelle jamais menée dans beaucoup d’environnements.

Le guide est catégorique sur la détection : il n’existe pas de méthode efficace. Les voies d’accès à SYSVOL sont trop nombreuses et le répertoire est lu en permanence dans le cadre normal de l’application des stratégies de groupe. La seule approche proposée consiste à déposer un mot de passe GPP canari appartenant à un objet utilisateur qui ne doit jamais être utilisé, et à surveiller toute authentification de cet objet.

L’atténuation est simple et sans coût d’exploitation : supprimer tous les mots de passe GPP et appliquer le correctif 2962486.

Compromission d’AD CS

AD CS met en oeuvre l’infrastructure à clés publiques de Microsoft. Un modèle de certificat mal configuré ouvre une voie d’élévation directe. La configuration dite ESC1 réunit quatre conditions : des droits d’inscription ouverts aux objets utilisateur, un usage étendu de clé, EKU (21), autorisant l’authentification client, la possibilité pour le demandeur de fournir son propre subject alternative name, SAN (22), et l’absence d’approbation par le gestionnaire de certificats. Un objet utilisateur quelconque demande alors un certificat au nom d’un objet privilégié et s’authentifie sous son identité.

Le certificat obtenu reste valide même si l’objet usurpé change son mot de passe. Il n’est invalidé que par son expiration ou sa révocation, laquelle n’est pas systématiquement prononcée pendant une réponse à incident. Douze autres configurations vulnérables, ESC2 à ESC13, existent et ne sont pas détaillées dans le guide, qui renvoie aux travaux de SpecterOps, de Mandiant et de Microsoft.

L’audit d’AD CS n’est pas activé par défaut. Il faut activer l’audit d’accès aux objets pour les services de certificats dans la configuration avancée de la stratégie d’audit, puis cocher l’ensemble des options de l’onglet Audit dans les propriétés de l’autorité de certification. Une fois la collecte en place, neuf événements sont exploitables.

Le guide ajoute un contrôle manuel utile : auditer les certificats émis pour l’authentification client et relever les écarts entre le demandeur et le nom du sujet. Un écart signale une demande faite au nom d’un autre. Les contrôles d’atténuation portent sur la configuration des modèles, retrait du drapeau Enrollee Supplies Subject, restriction des permissions des objets utilisateur standard, retrait du drapeau EDITF_ATTRIBUTESUBJECTALTNAME2 sur l’autorité, exigence d’approbation par le gestionnaire de certificats, retrait des EKU d’authentification, et sur la protection des serveurs eux-mêmes, classés en tier 0.

Shadow Credentials

C’est la technique ajoutée à cette révision. L’attribut msDS-KeyCredentialLink, introduit avec le niveau fonctionnel de domaine Windows Server 2016 pour prendre en charge l’authentification sans mot de passe dont Windows Hello Entreprise, accepte des informations d’identification par clé. Un acteur malveillant disposant des permissions suffisantes sur un objet y ajoute sa propre clé, s’authentifie par certificat et obtient un TGT au nom de cet objet.

Deux propriétés en font une technique de persistance autant que d’élévation. La clé reste valide après un changement de mot de passe de l’objet visé. Plusieurs informations d’identification peuvent coexister sur un même objet, donc une clé légitime et une clé malveillante cohabitent sans conflit. Par défaut, les membres de Domain Admins peuvent modifier cet attribut sur tous les objets utilisateur et ordinateur du domaine, et ceux de Key Admins et Enterprise Key Admins sur tous les objets ordinateur.

La détection repose sur un seul événement, le 5136, généré lorsqu’un attribut d’objet d’annuaire est modifié. Elle exige d’activer l’audit des modifications de service d’annuaire dans la configuration avancée de la stratégie d’audit, puis de configurer les listes de contrôle d’accès système sur les objets concernés. Le filtre est double : l’Attribute LDAP Display Name doit valoir msDS-KeyCredentialLink, et le champ Subject Name ne doit pas correspondre à un service d’enrôlement autorisé. Le guide insiste sur ce second point : il faut tenir une liste des services d’authentification sans mot de passe habilités, un acteur malveillant pouvant déployer un service au nom vraisemblable pour passer un contrôle fondé sur la seule reconnaissance du nom de compte.

Une revue périodique complète la détection événementielle. L’attribut stocke, pour chaque clé, un identifiant unique, une date de création, le matériel de clé publique et l’objet associé. Il ne contient ni le système ni l’utilisateur d’origine, et ne permet donc pas à lui seul de conclure. Il permet en revanche d’identifier trois anomalies : plusieurs clés sur un objet qui ne le justifie pas, une clé sur un objet qui n’utilise pas l’authentification sans mot de passe, une clé récente hors de toute campagne d’enrôlement connue. Dans un environnement qui n’utilise pas l’authentification sans mot de passe, toute valeur de cet attribut est suspecte.

Dix techniques relèvent de la compromission complète du domaine ou du maintien d’accès. Leur point commun est qu’elles résistent aux mesures d’éviction habituelles : plusieurs d’entre elles survivent à une réinitialisation générale des mots de passe, et deux imposent la reconstruction du domaine.

Golden Certificate

Un accès administrateur à une autorité de certification permet d’extraire son certificat et sa clé privée, avec les outils natifs de sauvegarde ou avec Mimikatz, Seatbelt et SharpDPAPI. Des certificats d’authentification client sont ensuite forgés pour n’importe quel objet du domaine. Ils restent valides jusqu’à révocation.

La détection est difficile car elle suppose d’attraper la sauvegarde et l’exfiltration. Le journal CAPI2 de l’autorité, à activer dans l’observateur d’événements, produit l’événement 70 à l’acquisition d’une clé privée de certificat : c’est le signal le plus direct, à filtrer sur un champ subjectName correspondant à une autorité. L’événement 4876, déclenché au démarrage d’une sauvegarde de la base de l’autorité, n’est pas fiable pour ce cas : il n’est généré que si l’option de sauvegarde de la base et de son journal est retenue, pas si seules la clé privée et le certificat sont exportés. S’y ajoutent 1102, 4103 et 4104.

Le contrôle d’atténuation décisif est le module matériel de sécurité, HSM (23) : la clé privée de l’autorité ne peut alors plus être sauvegardée ni exfiltrée. Autour, le guide demande le MFA pour les utilisateurs privilégiés, le contrôle applicatif sur les serveurs d’autorité pour bloquer l’exécution d’outils comme Mimikatz, et le traitement de ces serveurs au même niveau que les contrôleurs de domaine.

DCSync

Le DCSync consiste à demander une réplication d’annuaire pour en obtenir les hash de mots de passe. Il suppose les permissions Replicating Directory Changes, Replicating Directory Changes All ou Replicating Directory Changes in Filtered Set, ou bien GenericAll ou AllExtendedRights sur l’objet racine du domaine. Par défaut, ces droits appartiennent aux groupes Enterprise Admins, Domain Admins et Administrators sur les contrôleurs de domaine. La cible privilégiée est l’objet KRBTGT, préalable au Golden Ticket. Les hash obtenus sont soit cassés, soit rejoués directement en Pass-the-Hash, NTLM acceptant le hash comme jeton d’authentification valide.

Le guide signale une variante préparatoire : activer le stockage des mots de passe avec chiffrement réversible sur les objets visés, attendre leur prochain changement de mot de passe, puis exécuter le DCSync pour récupérer les mots de passe en clair. Cette manoeuvre annule l’effet des exigences de complexité et supprime l’étape de cassage.

La détection a été refondue. La méthode désormais préférée repose sur l’audit des appels de procédure distante, RPC (24), associés au protocole de réplication d’annuaire de Microsoft. Elle produit moins de volume et un meilleur rapport signal sur bruit que l’ancienne, mais impose deux prérequis : des contrôleurs de domaine sous Windows Server 2019 ou ultérieur, et le correctif cumulatif Microsoft d’octobre 2025 ou postérieur.

• Activer l’audit des événements RPC en succès, par stratégie de groupe de préférence, ou par auditpol /set /subcategory:"RPC Events" /success:enable.
• Configurer le filtre de pare-feu RPC sur chaque contrôleur de domaine, avec une action en permit : une action en deny bloquerait la réplication et désynchroniserait l’annuaire.
• Filtrer sur l’identifiant d’interface globale unique, GUID (25), e3514235-4b06-11d1-ab04-00c04fc2dcd2 et sur l’OpNum 3, faute de quoi l’événement est généré pour toute activité RPC auditée.
• Alerter sur l’événement 5712 dont le compte initiateur ou l’adresse source n’est pas habilité à la réplication.
• Si la réplication passe par SMB, configuration non native, l’adresse source est absente de l’événement 5712 : corréler alors le champ SubjectLogonId de l’événement 5712 avec le champ TargetLogonID de l’événement 4624.

La méthode d’accès au service d’annuaire reste disponible et moins recommandée, son volume étant supérieur puisque l’événement 4662 couvre un périmètre bien plus large que la seule réplication. Trois identifiants globaux uniques la qualifient : 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 pour DS-Replication-Get-Changes-All, 89e95b76-444d-4c62-991a-0facbeda640c pour DS-Replication-Get-Changes-In-Filtered-Set, et 19195a5b-6da0-11d0-afd3-00c04fd930c9 qui signale une modification des permissions sur l’objet de domaine en vue d’ouvrir l’accès à la réplication.

Le DCSync ne peut pas être éliminé, les permissions qu’il exploite étant nécessaires au fonctionnement d’Active Directory. Le guide demande donc d’en réduire l’exposition : minimiser le nombre d’objets utilisateur disposant des permissions ; vérifier qu’aucun objet porteur d’un SPN n’en dispose, pour couper la chaîne qui va du Kerberoasting au DCSync ; interdire à ces objets de se connecter sur des environnements non privilégiés ; revoir ces permissions tous les six mois ; désactiver NTLMv1 ; éliminer les hash LAN Manager, ce qu’assure un mot de passe de 15 caractères minimum.

Extraction de ntds.dit

Le fichier ntds.dit est la base d’AD DS, présente sur chaque contrôleur de domaine sauf en lecture seule, et contient les hash de tous les objets utilisateur et ordinateur. Le fichier étant verrouillé, sa copie passe par le service de cliché instantané de volume ou par Ntdsutil. Le déchiffrement complet exige en outre la ruche SYSTEM du registre du même contrôleur de domaine. Le guide signale une voie plus discrète : les sauvegardes de contrôleurs de domaine, parfois déposées sur des partages de fichiers et rarement protégées au même niveau que les serveurs eux-mêmes.

La perte du fichier emporte plus que les hash. Elle emporte le hash de KRBTGT, celui de l’objet de domaine approuvé et la clé de sauvegarde de l’interface de protection des données, DPAPI (26). Cette dernière est immuable : elle ne peut pas être réinitialisée, et la seule option de rétablissement recommandée par Microsoft est la création d’un nouveau domaine et la migration de tous les objets utilisateur.

La détection s’appuie sur six événements collectés sur les contrôleurs de domaine : 1102 pour la purge du journal de sécurité ; 4103 et 4104 pour l’activité PowerShell liée au fichier ; 4656 pour la demande d’un handle sur l’objet, à filtrer sur un champ Object Name correspondant à ntds.dit ; 4663 pour l’accès effectif, qui suppose une liste de contrôle d’accès système, SACL (27), posée sur le fichier ; 4688 pour la création de processus, qui donne les commandes et leurs paramètres ; 8222 pour la création d’un cliché instantané, méthode courante de contournement du verrou.

L’atténuation porte sur le durcissement des contrôleurs de domaine : accès limité aux seuls utilisateurs privilégiés qui en ont besoin, chemins d’accès restreints aux passerelles d’administration et aux postes d’administration sécurisés, sauvegardes chiffrées et réservées aux administrateurs de sauvegarde, aucun service ni application sans lien avec la sécurité, journalisation centralisée, spouleur d’impression désactivé, SMB version 1 désactivé.

Golden Ticket

Le hash de l’objet KRBTGT permet de forger des TGT arbitraires. Il n’a pas besoin d’être cassé, puisque c’est le hash lui-même qui chiffre les tickets. Ce hash s’obtient par DCSync ou par extraction de ntds.dit. L’objet KRBTGT étant la racine de confiance du domaine, sa compromission impose la réinitialisation coordonnée de tous les mots de passe d’objets utilisateur et ordinateur, et peut conduire à reconstruire le domaine.

La détection la plus robuste est une détection par absence. Une authentification Kerberos normale produit un événement 4768 à la demande de TGT, puis un 4769 à la demande de TGS, et les deux se correspondent. Un TGT forgé hors ligne n’a jamais été demandé au centre de distribution de clés : l’événement 4769 existe, le 4768 correspondant manque. Les incohérences relevables sur le 4769 complètent la recherche : objet utilisateur inexistant dans le domaine, appartenance de groupe déclarée sans correspondance réelle, algorithme plus faible que celui du domaine, durée de vie du ticket éloignée de la valeur par défaut de dix heures, Mimikatz retenant dix ans.

Le guide est explicite sur la limite de cette approche : un acteur malveillant soigneux forge un ticket aussi proche que possible d’un ticket légitime, et la détection sur les anomalies de contenu ne garantit rien. D’où le contrôle d’atténuation retenu, changer le mot de passe de KRBTGT tous les six mois, ou dès qu’une compromission est constatée ou suspectée, et le changer deux fois, les contrôleurs de domaine conservant l’ancien et le nouveau mot de passe pour ne pas interrompre l’authentification. Le délai entre les deux réinitialisations doit être suffisant pour que la première ait été répliquée sur l’ensemble des contrôleurs de domaine.

Silver Ticket

Le Silver Ticket forge un ticket de service à partir du hash de l’objet utilisateur qui exécute un service, ou du hash de l’objet ordinateur. Il ne passe pas par le contrôleur de domaine, ce qui en fait avant tout une technique d’évasion : l’échange se limite à l’acteur malveillant et à la machine visée, et les organisations journalisent rarement les authentifications ailleurs que sur les contrôleurs de domaine. Les services visés sont le partage de fichiers, LDAP, le service de base de données et le service HOST, qui donne accès aux tâches planifiées et à PowerShell Remoting.

La technique ouvre aussi une persistance durable. Active Directory change les mots de passe des objets ordinateur tous les trente jours, mais ce changement est initié par la machine et non par le contrôleur de domaine. Un objet ordinateur dont le mot de passe n’a pas changé depuis des années reste autorisé à s’authentifier. Un acteur malveillant qui détient le hash peut altérer le processus de renouvellement et conserver son accès indéfiniment.

La détection se déplace vers la machine visée. Deux événements y sont nécessaires : 4624 pour la connexion, et surtout 4627, généré conjointement, qui donne les appartenances de groupe du compte connecté. Le ticket étant forgé, il peut porter un SID et des appartenances qui ne correspondent pas à l’objet, et c’est cette discordance qui constitue le signal.

L’atténuation combine des gMSA pour les objets porteurs d’un SPN, le changement effectif des mots de passe de tous les objets ordinateur, contrôleurs de domaine compris, tous les trente jours, l’exclusion des objets ordinateur des groupes privilégiés, et l’absence de droit d’écriture ou de modification du groupe Domain Computers sur les objets d’Active Directory.

Golden SAML

AD FS signe les réponses Security Assertion Markup Language, SAML (28), avec une clé privée. Un acteur malveillant qui obtient cette clé forge des réponses et accède aux services pour lesquels AD FS est fournisseur d’identité. La technique exige trois éléments : le certificat de signature de jetons et sa clé privée, la clé maîtresse du Distributed Key Manager, DKM (29), stockée dans AD DS et nécessaire au déchiffrement du certificat, et la liste des services concernés.

L’effet dépasse le périmètre interne. Si la partie de confiance, Microsoft Entra ID par exemple, fait confiance aux revendications MFA du fournisseur d’identité, la réponse forgée contourne le MFA et survit au changement de mot de passe de l’objet usurpé. La technique a été employée dans la compromission de chaîne d’approvisionnement impliquant SolarWinds en 2019, et l’est restée depuis. Le guide note qu’une partie de confiance peut être configurée pour exiger le MFA même en présence d’une revendication du fournisseur d’identité, ce qui referme cette porte.

L’accès au conteneur DKM mérite une attention particulière : cet attribut ne doit être lu que périodiquement, par le seul compte de service AD FS. Chaque occurrence appelle une vérification. La configuration de l’audit d’accès au service d’annuaire avec l’option de lecture de toutes les propriétés sur les conteneurs parent et enfant d’AD FS est un prérequis.

Côté atténuation, le compte de service AD FS doit être un gMSA, ce qui lui confère un mot de passe de 120 caractères en rotation tous les trente jours et le met hors de portée du Kerberoasting comme du cassage, et il ne doit servir à rien d’autre. Les certificats de signature et de chiffrement de jetons doivent être renouvelés tous les douze mois, ou plus tôt en cas de compromission, deux fois de suite pour révoquer les jetons existants.

Compromission de Microsoft Entra Connect

Microsoft Entra Connect synchronise Active Directory avec Microsoft Entra ID. La configuration par défaut, la synchronisation de hash de mots de passe, PHS (30), crée deux objets : un objet utilisateur dans Active Directory, préfixé MSOL, et un objet dans Entra ID, préfixé Sync. L’objet MSOL dispose des permissions de réplication, c’est à dire exactement celles qu’exige un DCSync. L’objet Sync porte le rôle Directory Synchronisation Accounts, qui lui permet de créer, modifier et supprimer des objets utilisateur et de définir des mots de passe.

Un accès administrateur au serveur Microsoft Entra Connect permet d’extraire les mots de passe en clair de ces deux objets, avec AADInternals notamment. Le premier donne les hash de tout l’annuaire, le second permet de définir le mot de passe d’un objet portant le rôle Global Administrator, donc le contrôle complet des ressources infonuagiques. L’autre configuration courante, l’authentification directe, PTA (31), est compromise différemment : le processus d’authentification entre Entra ID et Active Directory est détourné, ce qui permet de s’authentifier comme n’importe quel objet sans en connaître le mot de passe, et de conserver une copie en clair des mots de passe présentés.

La détection combine sept événements collectés sur les serveurs Microsoft Entra Connect : 611 pour l’échec de la synchronisation de hash, 650 et 651 pour le début et la fin de récupération des mots de passe mis à jour, 656 pour la détection d’un changement et la tentative de synchronisation, 657 pour la synchronisation réussie, 1102 pour la purge du journal de sécurité, 4103 et 4104 pour l’activité PowerShell dont se sert AADInternals. S’y ajoute une détection par corrélation : un événement d’authentification directe sans événement d’authentification correspondant sur un contrôleur de domaine signale un détournement du processus.

Deux contrôles d’atténuation sont propres à ce périmètre et souvent négligés : désactiver la reprise par correspondance forte, qui empêche la source d’autorité d’un objet Entra ID de basculer vers Active Directory, et désactiver la correspondance approximative une fois la synchronisation initiale terminée, faute de quoi un nouvel objet Entra ID peut être approvisionné à la demande. S’y ajoutent l’interdiction de synchroniser les objets privilégiés entre les deux annuaires, avec des comptes d’administration distincts de part et d’autre, et le MFA pour tous les utilisateurs privilégiés d’Entra ID.

Contournement d’une relation d’approbation unidirectionnelle

L’établissement d’une relation d’approbation entre deux domaines crée un objet de domaine approuvé, TDO (32), dont le mot de passe est partagé entre les deux domaines et stocké dans l’annuaire. Un acteur malveillant disposant des droits d’administration sur un contrôleur de domaine du domaine approbateur récupère le hash de ce mot de passe dans le conteneur System, demande un TGT au domaine approuvé en le présentant, et accède aux ressources du domaine approuvé. Le sens de la relation ne protège donc pas.

Le guide en tire une conclusion nette : les domaines Active Directory ne constituent pas des frontières de sécurité. La frontière est la forêt, et encore, le guide décrit par ailleurs le saut de domaine par combinaison d’un Golden Ticket et de l’historique de SID, qui permet d’atteindre les autres forêts lorsque des relations inter-forêts existent.

La détection tient à la surveillance de l’usage du TDO, qui ne doit servir qu’à communiquer avec le domaine pour lequel il a été créé. L’événement 4768, collecté dans le domaine approuvé, avec un champ User ID correspondant au nom du TDO, est le signal principal. Il s’accompagne de 1102, 4103 et 4104 sur les contrôleurs de domaine. Toute autre activité associée au TDO, requêtes LDAP ou événements d’authentification inhabituels, appelle une vérification.

Une conséquence opérationnelle mérite d’être retenue pour la réponse à incident : le périmètre d’un incident touchant un domaine doit inclure tous les domaines avec lesquels une relation d’approbation existe. Et la réinitialisation du mot de passe du TDO se fait d’abord dans le domaine approbateur, puis avec la même valeur dans le domaine approuvé.

Compromission de l’historique de SID

Chaque objet d’AD DS porte un identifiant de sécurité, SID (33), unique et immuable, et un attribut sIDHistory destiné à conserver les identifiants antérieurs lors d’une migration entre domaines. Avec les droits d’administration sur un contrôleur de domaine, un acteur malveillant ajoute le SID d’un objet ou d’un groupe privilégié à l’historique d’un objet qu’il contrôle. Cet objet hérite alors des privilèges correspondants sans apparaître dans la composition du groupe. C’est une technique de persistance et de dissimulation : l’objet passe pour un utilisateur ordinaire dans toutes les revues d’appartenance.

La détection repose sur quatre événements : 4738, qui trace la modification de l’attribut sIDHistory sur un objet utilisateur et constitue le signal direct ; 4675, généré lorsque des SID sont filtrés, qui peut révéler une tentative de saut de domaine ; 4103 et 4104 pour l’activité PowerShell ; 1102 pour la purge du journal. L’attribut ne devant servir qu’aux migrations, sa modification est un événement rare dans la plupart des organisations, ce qui en fait un signal à faible bruit.

Trois contrôles d’atténuation : ne pas utiliser l’attribut, et le vider une fois la migration terminée et les accès reconfigurés ; le vérifier chaque semaine ; activer le filtrage de SID sur les relations d’approbation de domaine et de forêt. Le guide précise la limite de ce dernier contrôle : il empêche l’usage des SID des groupes intégrés comme Domain Admins et Enterprise Admins entre domaines, mais laisse passer ceux dont l’identifiant relatif est supérieur à 1000.

Skeleton Key

Skeleton Key est un code malveillant qui détourne les processus d’authentification NTLM et Kerberos dans la mémoire du processus LSASS d’un contrôleur de domaine, et y injecte un mot de passe universel. Les authentifications légitimes continuent de fonctionner ; celles de l’acteur malveillant réussissent avec ce mot de passe. Les deux sont ensuite indiscernables.

La technique a trois caractéristiques exploitables en détection. Elle force le RC4, même lorsqu’un algorithme plus robuste est disponible, ce qui fait échouer l’authentification des comptes protégés ou configurés sans RC4 sur le contrôleur de domaine infecté ; une variante sans ce forçage existe mais provoque des problèmes de performance ou de mémoire visibles. Elle réside uniquement en mémoire et disparaît au redémarrage, donc elle doit être réinjectée. Elle doit être déployée sur tous les contrôleurs de domaine pour que toutes les authentifications malveillantes aboutissent, faute de quoi certaines échouent selon le contrôleur sollicité.

La détection exige deux préparations : activer le mode audit pour le processus LSASS, qui produit un événement par pilote refusé au chargement lorsque la protection LSASS est active, et activer l’audit des objets noyau sur les contrôleurs de domaine à partir de Windows Server 2016, une liste de contrôle d’accès système étant posée par défaut sur le processus LSASS depuis cette version.

Sur l’événement 4663, le guide demande d’établir au préalable la liste des solutions de sécurité présentes sur l’hôte, certaines accédant légitimement au processus LSASS. Les contrôles d’atténuation ajoutent au durcissement habituel des contrôleurs de domaine trois mesures propres à cette technique : exécuter LSASS en mode protégé, appliquer la liste de blocage des pilotes vulnérables de Microsoft, et restreindre l’exécution des pilotes à un ensemble approuvé, par exemple avec Windows Defender Application Control. Le guide précise que la protection de LSASS se contourne par un pilote vulnérable en mode noyau, ce qui explique que les deux derniers contrôles accompagnent nécessairement le premier.

L’annexe B consolide les événements par source. C’est la partie du guide directement transposable en plan de collecte. Elle appelle une lecture attentive sur un point : les contrôleurs de domaine n’en sont qu’une source sur six.

Deux prérequis de configuration conditionnent l’ensemble. Les événements 4103 et 4104 supposent la journalisation des modules et des blocs de script PowerShell. Les événements 4656 et 4663 supposent des listes de contrôle d’accès système posées sur les objets à surveiller, à commencer par le fichier ntds.dit. À quoi s’ajoutent les activations spécifiques déjà citées : audit des événements RPC et filtre de pare-feu RPC pour le DCSync, audit des modifications de service d’annuaire pour Shadow Credentials, audit d’accès aux objets et onglet Audit pour AD CS, journal CAPI2 sur les autorités de certification, audit des objets noyau pour Skeleton Key, audit d’accès au service d’annuaire en succès et en échec pour les canaris et pour le conteneur DKM.

Une lecture transverse du tableau fait ressortir les événements qui servent plusieurs détections et méritent donc d’être traités en priorité. L’événement 1102 couvre quatre techniques, 4103 et 4104 en couvrent quatre chacun sur les contrôleurs de domaine, 4624 trois, 4768 quatre, 4738 trois, 5136 trois. Ce sont les signaux au meilleur rendement pour une collecte qui démarre.

Le guide consacre une section à une technique de détection qui ne repose pas sur la corrélation d’événements. Le constat qui la motive est franc : la complexité de la détection des compromissions d’Active Directory est l’une des principales causes de leur succès. Les techniques exploitent des fonctionnalités légitimes, produisent les mêmes événements que l’activité normale, et plusieurs se détectent par l’absence d’un événement plutôt que par sa présence.

Le mécanisme est simple. Des objets canaris sont créés dans l’annuaire, avec un refus de lecture pour le groupe Everyone. La politique d’audit d’accès au service d’annuaire est configurée en succès et en échec. Toute tentative de lecture des propriétés d’un objet canari produit alors un événement 4662 en échec d’audit, que le système de gestion des informations et des événements de sécurité, SIEM (34), alerte sur la base de l’identifiant globalement unique de l’objet.

L’intérêt tient à ce que la technique détecte la compromission elle-même, et non l’outil qui la porte. Elle s’applique à toute compromission qui énumère les objets du domaine, ce qui est le point de départ de la plupart d’entre elles, par exemple avec SharpHound. Le guide cite nommément le Kerberoasting, l’AS-REP Roasting et le DCSync comme détectables par cette voie, et mentionne les canaris développés par Airbus parmi les outils disponibles.

La limite est explicite : un acteur malveillant qui ne vise qu’un objet utilisateur ou un petit nombre d’entre eux ne lit pas les canaris et n’est pas détecté. La technique ne remplace donc pas la collecte, elle lui donne un filet de sécurité à faible bruit.

Le document est primaire et signé par six agences nationales. Les valeurs citées ici ont été relevées sur le fichier d’origine et recoupées avec les tableaux de l’annexe B, non sur une conversion en texte.

D’abord la collecte, ensuite les règles

Écrire des règles de détection sur des événements qui ne sont pas collectés est l’échec le plus courant sur ce sujet. L’ordre est donc contraint.

• Activer les journalisations manquantes sur les contrôleurs de domaine : modules et blocs de script PowerShell, audit des objets noyau, audit des modifications de service d’annuaire, audit des événements RPC en succès avec le filtre de pare-feu correspondant, audit d’accès au service d’annuaire en succès et en échec.
• Poser les listes de contrôle d’accès système sur les objets à surveiller, à commencer par ntds.dit et par les objets pour lesquels msDS-KeyCredentialLink doit être audité.
• Étendre la collecte aux cinq sources qui ne sont pas des contrôleurs de domaine : autorités de certification, avec le journal CAPI2 activé, serveurs AD FS, serveurs Microsoft Entra Connect, objets ordinateur en délégation non contrainte, serveurs sensibles susceptibles d’être visés par un Silver Ticket.
• Vérifier les prérequis de la détection du DCSync par RPC : version de système d’exploitation des contrôleurs de domaine et correctif cumulatif d’octobre 2025. À défaut, la détection reste sur l’événement 4662, avec le volume correspondant.

Les détections par absence

Trois détections décrites dans le guide ne reposent pas sur la présence d’un événement mais sur son absence. Elles demandent une construction spécifique dans le SIEM et sont souvent omises.

• Un événement 4769 sans événement 4768 correspondant, indicateur d’un TGT forgé hors ligne, donc d’un Golden Ticket.
• Une authentification constatée chez un fournisseur de service sans événement 1200 et 1202 correspondant côté AD FS, indicateur d’une réponse SAML forgée.
• Un événement d’authentification directe sur un serveur Microsoft Entra Connect sans authentification correspondante sur un contrôleur de domaine, indicateur d’un détournement du processus.

Les dettes à coût nul

Une partie des contrôles d’atténuation ne coûte qu’une décision et une vérification. Ils ferment des voies d’élévation directes et se traitent avant les chantiers longs.

• Porter ms-DS-MachineAccountQuota à zéro et vérifier que Domain Computers n’est ni membre d’un groupe privilégié ni titulaire d’un droit d’écriture.
• Supprimer les cpasswords résiduels de SYSVOL et confirmer l’application du correctif 2962486.
• Recenser et supprimer les objets ordinateur en délégation non contrainte, et désactiver le spouleur d’impression sur les contrôleurs de domaine.
• Recenser les objets utilisateur sans pré-authentification Kerberos et rétablir l’exigence.
• Vider l’attribut sIDHistory hors migration en cours, et en instaurer la vérification hebdomadaire.
• Marquer le compte Administrator intégré comme sensible et non délégable, lui attribuer un mot de passe de 30 caractères et le surveiller.
• Activer la signature LDAP sur les contrôleurs de domaine, désactiver SMB version 1 et NTLMv1.
• Poser des objets canaris et les câbler dans le SIEM sur leur identifiant globalement unique.

Les chantiers longs

Restent les travaux qui se planifient sur plusieurs exercices : la mise en oeuvre du modèle en tiers, le passage des comptes de service en gMSA, la rotation du mot de passe de KRBTGT tous les six mois et des certificats AD FS tous les douze mois, le renouvellement effectif des mots de passe d’objets ordinateur tous les trente jours, le passage des autorités de certification sur module matériel de sécurité, le contrôle applicatif et la restriction des pilotes sur les contrôleurs de domaine.

Une remarque pour finir sur l’usage du document. Le guide décrit des techniques largement connues et publiquement documentées depuis des années. Sa valeur pour une équipe de détection ne tient pas à cette description mais à trois éléments plus rares : la liste précise des champs à filtrer, l’annexe qui consolide les événements par source, et l’inventaire des configurations d’audit à activer au préalable. C’est cette dernière liste qui détermine si les deux premières servent à quelque chose.

1. ASD (1) : Australian Signals Directorate, agence australienne du renseignement d’origine électromagnétique, dont dépend l’Australian Cyber Security Centre.
2. CISA (2) : Cybersecurity and Infrastructure Security Agency, agence américaine de cybersécurité et de sécurité des infrastructures.
3. AD DS (3) : Active Directory Domain Services, service d’annuaire et d’authentification de Microsoft.
4. AD CS (4) : Active Directory Certificate Services, service d’infrastructure à clés publiques de Microsoft.
5. AD FS (5) : Active Directory Federation Services, service de fédération d’identité de Microsoft.
6. KRBTGT (6) : Kerberos Ticket Granting Ticket, objet utilisateur créé avec le domaine, dont le hash chiffre les tickets d’attribution de tickets. Racine de confiance du domaine.
7. MFA (7) : Multi-Factor Authentication, authentification exigeant plusieurs facteurs distincts.
8. SPN (8) : Service Principal Name, identifiant qui associe un service à un objet de l’annuaire.
9. TGS (9) : Ticket Granting Service, ticket Kerberos donnant accès à un service déterminé.
10. RC4 (10) : Rivest Cipher 4, algorithme de chiffrement par flot, utilisé par défaut par Active Directory pour les tickets de service et vulnérable au cassage de mot de passe.
11. gMSA (11) : group Managed Service Account, type de compte de service dont Active Directory gère le mot de passe, de 120 caractères et renouvelé automatiquement.
12. AES (12) : Advanced Encryption Standard, algorithme de chiffrement par blocs, à substituer au RC4 pour les tickets Kerberos.
13. TGT (13) : Ticket Granting Ticket, ticket Kerberos initial, présenté pour obtenir des tickets de service.
14. LDAP (14) : Lightweight Directory Access Protocol, protocole d’interrogation et de modification de l’annuaire.
15. NTLM (15) : New Technology LAN Manager, famille de protocoles d’authentification Microsoft antérieurs à Kerberos, qui ne prend pas en charge le MFA.
16. SMB (16) : Server Message Block, protocole de partage de fichiers et d’impression de Microsoft.
17. LAPS (17) : Local Administrator Password Solution, solution Microsoft de gestion des mots de passe des comptes d’administration locale.
18. LSASS (18) : Local Security Authority Subsystem Service, processus Windows qui valide les authentifications et conserve en mémoire les secrets associés.
19. GPP (19) : Group Policy Preferences, extension des stratégies de groupe ayant permis de distribuer des mots de passe chiffrés avec une clé publiquement connue.
20. SYSVOL (20) : System Volume, répertoire partagé présent sur chaque contrôleur de domaine et lisible par tous les utilisateurs du domaine.
21. EKU (21) : Extended Key Usage, champ d’un certificat qui définit les usages autorisés, dont l’authentification client.
22. SAN (22) : Subject Alternative Name, champ d’un certificat désignant les identités auxquelles il s’applique.
23. HSM (23) : Hardware Security Module, module matériel qui conserve les clés privées et interdit leur extraction.
24. RPC (24) : Remote Procedure Call, mécanisme d’appel de procédure entre systèmes, support du protocole de réplication d’annuaire.
25. GUID (25) : Globally Unique Identifier, identifiant unique attribué aux objets, interfaces et attributs.
26. DPAPI (26) : Data Protection Application Programming Interface, interface Windows de protection des données, dont la clé de sauvegarde d’annuaire est immuable.
27. SACL (27) : System Access Control List, liste qui définit les accès à auditer sur un objet.
28. SAML (28) : Security Assertion Markup Language, standard d’échange d’assertions d’authentification entre fournisseur d’identité et fournisseur de service.
29. DKM (29) : Distributed Key Manager, composant dont la clé maîtresse, stockée dans l’annuaire, déchiffre le certificat de signature d’AD FS.
30. PHS (30) : Password Hash Synchronisation, mode de synchronisation qui recopie les hash de mots de passe d’Active Directory vers Microsoft Entra ID.
31. PTA (31) : Pass-Through Authentication, mode où Microsoft Entra ID renvoie les demandes d’authentification vers Active Directory pour validation.
32. TDO (32) : Trusted Domain Object, objet créé lors de l’établissement d’une relation d’approbation, porteur d’un mot de passe partagé entre les deux domaines.
33. SID (33) : Security Identifier, identifiant unique et immuable d’un objet d’annuaire, qui détermine ses droits d’accès.
34. SIEM (34) : Security Information and Event Management, système de collecte, de corrélation et d’alerte sur les événements de sécurité.

1. ASD ACSC, CISA, NSA, CCCS, NCSC-UK et NCSC-NZ, Detecting and mitigating Active Directory compromises, révision de septembre 2026, 74 pages. cyber.gov.au
2. CISA, page de ressource Detecting and Mitigating Active Directory Compromises, date de révision du 15 septembre 2026, consultée le 16 septembre 2026. cisa.gov
3. CISA, alerte de publication initiale du guide, 26 septembre 2024. cisa.gov
4. NSA, communiqué de publication conjointe du guide, septembre 2024. nsa.gov
5. Microsoft, spécification MS-DRSR, Directory Replication Service Remote Protocol, référencée en note du guide pour l’identifiant d’interface de réplication. learn.microsoft.com
6. Microsoft Learn, 5712(S) A Remote Procedure Call (RPC) was attempted, référencée en note du guide pour la description de l’événement.