Depuis trois ans, nous auditons des infrastructures Active Directory pour des ETI françaises, belges et luxembourgeoises. Un constat revient systématiquement : les groupes ransomware n'exploitent pas des failles zero-day sophistiquées. Ils suivent des chemins d'attaque bien connus, documentés, et — dans la majorité des cas — corrigeables en quelques heures.

Le rapport ANSSI sur l'état de la menace informatique confirme cette réalité : plus de 70% des incidents de sécurité traités impliquaient une compromission d'Active Directory, et dans la grande majorité de ces cas, l'attaquant avait exploité des erreurs de configuration — pas des vulnérabilités logicielles.

Voici les cinq chemins d'attaque que nous retrouvons le plus fréquemment dans nos audits, avec pour chacun la méthode de détection, la remédiation concrète, et des retours d'expérience de nos missions terrain.

1. Kerberoasting : quand les comptes de service deviennent la porte d'entrée

Le Kerberoasting est probablement l'attaque la plus rentable du point de vue de l'attaquant. Le principe repose sur un mécanisme légitime de Kerberos : tout utilisateur authentifié dans le domaine peut demander un ticket de service (TGS — Ticket Granting Service) pour n'importe quel compte associé à un servicePrincipalName (SPN). Ce ticket est chiffré avec le hash NTLM du mot de passe du compte de service. L'attaquant exporte ce ticket puis le brute-force hors ligne avec des outils comme Hashcat ou John the Ripper — sans générer aucune alerte dans l'Active Directory.

Le problème structurel est double. D'abord, beaucoup d'entreprises ont des comptes de service avec des mots de passe faibles (souvent 8-12 caractères, parfois identiques depuis la création du domaine). Ensuite, ces comptes ont fréquemment des privilèges élevés : membre de Domain Admins, Enterprise Admins, ou disposant de droits DCSync (réplication de l'annuaire).

Ce que nous voyons en audit : sur nos derniers audits, 78% des infrastructures présentaient au moins un compte avec SPN et privilèges Domain Admin, avec un mot de passe inchangé depuis plus de 3 ans. Dans un cas, le compte de service SQL Server — membre Domain Admins — avait un mot de passe de 8 caractères qui tombait en moins de 4 heures avec Hashcat sur un GPU grand public.

Détection

PingCastle signale les comptes avec SPN et privilèges élevés dans la section « Privileged accounts with SPN ». Pour une détection manuelle plus fine :

# Comptes avec SPN et privilèges élevés
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
  -Properties ServicePrincipalName, MemberOf, PasswordLastSet |
Where-Object {
    $_.MemberOf -match "Domain Admins|Enterprise Admins|Schema Admins"
} | Select Name, PasswordLastSet,
    @{N='SPN';E={$_.ServicePrincipalName -join '; '}}

# Comptes avec SPN et mot de passe ancien (>1 an)
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
  -Properties PasswordLastSet |
Where-Object {$_.PasswordLastSet -lt (Get-Date).AddYears(-1)} |
Select Name, PasswordLastSet

Côté détection active, surveillez l'événement Windows 4769 (Kerberos Service Ticket Operation) avec un type de chiffrement 0x17 (RC4-HMAC). Un pic de demandes TGS pour des comptes de service différents depuis un même poste est un indicateur fort de Kerberoasting en cours.

Remédiation en 3 niveaux

Jour 1 — Actions immédiates : Identifier et supprimer tous les SPN inutiles. Beaucoup sont des résidus de décommissionnements incomplets. Nous trouvons régulièrement des SPN pointant vers des serveurs qui n'existent plus depuis des années.

Semaine 1 — Actions prioritaires : Pour les comptes qui doivent conserver un SPN, appliquer un mot de passe de 30 caractères minimum généré aléatoirement, activer le chiffrement AES 256, et désactiver RC4 via l'attribut msDS-SupportedEncryptionTypes. Retirer ces comptes des groupes à privilèges et leur accorder uniquement les permissions minimales nécessaires.

Mois 1 — Actions structurelles : Migrer vers des Group Managed Service Accounts (gMSA) pour tous les services compatibles. Les gMSA gèrent automatiquement la rotation du mot de passe (240 caractères, rotation tous les 30 jours par défaut) et éliminent le risque de Kerberoasting. Déployer LAPS (Local Administrator Password Solution) pour les comptes administrateurs locaux.

Salle serveur

2. Délégation non contrainte : le jackpot silencieux

La délégation non contrainte (TrustedForDelegation) est un mécanisme hérité de Windows Server 2000 qui permet à un serveur d'usurper l'identité de n'importe quel utilisateur qui s'y authentifie. Quand un utilisateur se connecte à un serveur configuré en délégation non contrainte, son TGT Kerberos complet est transmis et stocké en mémoire sur ce serveur.

L'implication est catastrophique : si un attaquant compromet un serveur avec délégation non contrainte, il peut extraire de la mémoire le TGT de tout utilisateur qui s'y est connecté — y compris les administrateurs du domaine. Avec l'outil Rubeus, l'extraction et la réutilisation du TGT prennent moins de 30 secondes.

L'attaque devient encore plus dangereuse combinée avec le Printer Bug (MS-RPRN) ou PetitPotam : l'attaquant force un contrôleur de domaine à s'authentifier auprès du serveur compromis, récupère le TGT du compte machine du DC, puis l'utilise pour une attaque DCSync et extraire l'intégralité des hash de l'annuaire.

Ce que nous voyons en audit : en moyenne 4 à 10 serveurs avec délégation non contrainte hors contrôleurs de domaine. Notre record : 23 serveurs, dont un serveur d'impression accessible à tous les utilisateurs du domaine.

Détection

# Serveurs avec délégation non contrainte (hors DCs)
Get-ADComputer -Filter {TrustedForDelegation -eq $true} `
  -Properties TrustedForDelegation, OperatingSystem |
Where-Object {
    $_.DistinguishedName -notmatch "Domain Controllers"
} | Select Name, OperatingSystem, DistinguishedName

# Comptes utilisateur avec délégation (encore plus dangereux)
Get-ADUser -Filter {TrustedForDelegation -eq $true}

Remédiation

Désactiver la délégation non contrainte sur tous les serveurs qui ne sont pas des contrôleurs de domaine. Pour les applications qui nécessitent réellement de la délégation, reconfigurer en délégation contrainte (ciblée vers un service spécifique) ou en délégation contrainte basée sur les ressources (RBCD), qui est plus sécurisée et ne nécessite pas de modifier l'objet du serveur source.

En parallèle, ajouter systématiquement les comptes sensibles au groupe Protected Users et les marquer comme Account is sensitive and cannot be delegated. Ces deux mesures empêchent la mise en cache de leur TGT sur les serveurs tiers.

3. ACL abusives sur AdminSDHolder : la backdoor qui se régénère

AdminSDHolder est un conteneur spécial d'Active Directory qui sert de modèle de sécurité pour tous les groupes protégés — Domain Admins, Enterprise Admins, Schema Admins, Account Operators, etc. Le processus SDProp (Security Descriptor Propagator) s'exécute toutes les 60 minutes et écrase les ACL de ces groupes protégés avec celles définies sur AdminSDHolder.

C'est un mécanisme de protection légitime, mais il devient une arme redoutable entre les mains d'un attaquant. Si l'attaquant ajoute une ACE (Access Control Entry) sur AdminSDHolder — par exemple, GenericAll pour un compte qu'il contrôle — cette ACE sera automatiquement répliquée sur tous les groupes protégés dans l'heure. Même si votre SOC nettoie les permissions sur Domain Admins, SDProp les écrasera dans les 60 minutes avec la version corrompue. La backdoor se régénère automatiquement.

Détection

Comparer les ACL actuelles d'AdminSDHolder avec un état de référence sain. PingCastle identifie les ACE suspectes dans la catégorie « AdminSDHolder ». Configurer une alerte SIEM sur l'événement 5136 (modification d'objet annuaire) ciblant le DN d'AdminSDHolder — toute modification doit déclencher une alerte critique immédiate.

Remédiation

Auditer et nettoyer les ACL d'AdminSDHolder pour ne conserver que les entrées par défaut de Microsoft. Documenter l'état de référence sain et le vérifier mensuellement. Tout écart doit être traité comme un incident de sécurité.

Circuits numériques

4. GPO comme vecteur de déploiement de charge malveillante

Les Group Policy Objects sont le mécanisme de distribution le plus puissant d'Active Directory. Un attaquant qui obtient le droit de modifier une GPO liée à un OU contenant des postes ou des serveurs peut déployer un script de démarrage, une tâche planifiée, ou une installation MSI malveillante sur l'ensemble du périmètre en quelques minutes.

Le scénario classique : un compte de service (compromis via Kerberoasting) dispose du droit GPC-Modify sur une GPO de déploiement. L'attaquant insère un Immediate Scheduled Task qui exécute un beacon Cobalt Strike au prochain rafraîchissement de GPO (90 minutes par défaut). Un autre vecteur fréquent : les scripts de connexion stockés dans SYSVOL. Si les permissions SYSVOL sont trop ouvertes, un attaquant remplace un script légitime par un script malveillant exécuté par tous les utilisateurs.

Remédiation

Lister tous les comptes qui ont un droit d'écriture sur les GPO et restreindre au strict minimum (Tier 0 uniquement). Implémenter le modèle de tiering Microsoft : les comptes Tier 0 (AD) ne touchent jamais les postes Tier 2. Activer l'audit des modifications GPO (événements 5136, 5137) et les router vers votre SIEM.

5. NTLM Relay et absence de signature

Malgré les recommandations de Microsoft depuis plus de quinze ans, la majorité des infrastructures auditées n'imposent pas la signature LDAP ni la signature SMB. Cette lacune ouvre la porte aux attaques par relais NTLM.

La combinaison PetitPotam + NTLM Relay vers AD CS (Active Directory Certificate Services) est devenue l'attaque la plus dévastatrice de ces dernières années. L'attaquant force un DC à s'authentifier via NTLM, relaie vers le service d'enrôlement de certificats (ESC8), obtient un certificat au nom du DC, puis réalise un DCSync complet. L'ensemble prend moins de 5 minutes et compromet l'intégralité du domaine.

Remédiation

Activer et imposer la signature LDAP serveur (LDAPServerIntegrity = 2) et le channel binding. Imposer la signature SMB via GPO. Désactiver SMBv1. Pour AD CS, auditer les vulnérabilités ESC1 à ESC13 avec Certify ou Certipy, corriger en priorité ESC8 (Web Enrollment HTTP) et ESC1 (templates avec SAN autorisé).

Conclusion : la dette technique se paie comptant

Aucun de ces cinq chemins d'attaque n'est nouveau. Ce sont des erreurs de configuration accumulées au fil des années, souvent parce que l'AD est perçu comme un service « qui fonctionne tout seul » — jusqu'au jour où il ne fonctionne plus.

Les groupes ransomware ont industrialisé l'exploitation de ces faiblesses. Leurs playbooks intègrent systématiquement une phase de reconnaissance AD avec BloodHound, suivie d'une escalade via les chemins décrits ici. Le temps moyen entre la compromission initiale et le déploiement du ransomware est passé sous la barre des 24 heures pour les groupes les plus efficaces.

Un audit AD ciblé permet d'identifier et de corriger ces vulnérabilités avant qu'elles ne soient exploitées. C'est exactement ce que nous faisons chez Gétul Consulting : PingCastle comme première couche de détection automatisée, complété par une analyse manuelle qui vérifie les chemins d'attaque complexes, les ACL héritées, et les configurations subtiles que l'outil seul ne peut pas interpréter.