Cybreach Consulting Prendre RDV
Retour aux articles
Vulnérabilités

Active Directory : les 5 chemins vers Domain Admin les plus fréquents

Active Directory est présent dans la quasi-totalité des réseaux d'entreprise. Et dans la quasi-totalité des pentests d'infrastructure que je mène, au moins un de ces cinq chemins mène au compte Domain Admin en quelques heures. Pas parce que les équipes sont négligentes, mais parce que ces vulnérabilités sont structurelles, souvent héritées de configurations d'il y a dix ans, et que les outils de détection habituels ne les remontent pas.

1. Kerberoasting

Kerberos permet à n'importe quel utilisateur authentifié de demander un ticket de service (TGS) pour n'importe quel compte ayant un Service Principal Name (SPN) enregistré. Ce ticket est chiffré avec le hash du mot de passe du compte de service. Un attaquant peut demander ce ticket, l'exporter, et le casser hors ligne avec hashcat.

Le problème : les comptes de service ont souvent des mots de passe faibles, jamais changés depuis des années, et des droits étendus dans le domaine. Un compte de service SQL kerberoastable avec un mot de passe de 2015 et des droits GenericAll sur une OU, c'est la norme, pas l'exception.

Détection difficile : la demande de TGS est un comportement Kerberos légitime. Corriger : gérer les comptes de service avec des mots de passe complexes de 30+ caractères, ou migrer vers des gMSA (Group Managed Service Accounts) dont le mot de passe est géré automatiquement par le domaine.

2. AS-REP Roasting

Certains comptes ont l'option « Ne pas exiger de pré-authentification Kerberos » activée. Pour ces comptes, n'importe qui peut demander un AS-REP (Authentication Service Response) sans s'authentifier préalablement. Ce AS-REP contient des données chiffrées avec le hash du mot de passe du compte, directement crackable hors ligne.

L'attaque ne nécessite même pas un compte valide dans le domaine pour énumérer les comptes vulnérables. Et l'option est parfois activée par mégarde lors de migrations ou de configurations de compatibilité, et oubliée.

3. Abus d'ACL (Access Control Lists)

Active Directory est un graphe de permissions. Chaque objet (utilisateur, groupe, OU, GPO…) a une ACL qui définit qui peut faire quoi dessus. Des droits apparemment inoffensifs peuvent créer des chemins d'escalade directs vers Domain Admin.

  • GenericAll sur un utilisateur : l'attaquant peut changer son mot de passe sans connaître l'ancien.
  • WriteDACL sur un groupe : l'attaquant peut s'ajouter lui-même au groupe, y compris Domain Admins.
  • ForceChangePassword : réinitialiser le mot de passe d'un compte cible sans interaction de l'utilisateur.
  • WriteOwner sur un objet : prendre la propriété et modifier ses permissions arbitrairement.

Ces chemins d'attaque sont cartographiables avec BloodHound. En pratique, on retrouve régulièrement des délégations de droits accumulées sur plusieurs années, jamais auditées, qui créent des chemins d'escalade en 3 ou 4 sauts depuis un compte utilisateur standard.

4. ADCS mal configuré (Active Directory Certificate Services)

AD CS est le service de PKI intégré à Active Directory. Il est présent dans la grande majorité des domaines Windows, souvent installé par défaut, rarement audité. Les mauvaises configurations permettent à un utilisateur non privilégié de demander un certificat au nom d'un autre compte, y compris un Domain Admin.

Les templates de certificats vulnérables sont nombreux : ESC1 (un utilisateur peut spécifier le SAN du certificat), ESC2 (template avec Any Purpose EKU), ESC4 (droits d'écriture sur un template), ESC8 (NTLM relay vers l'enrollment web). Avec un certificat valide au nom d'un Domain Admin, on peut obtenir son hash NTLM et s'authentifier comme lui.

ADCS est l'une des surfaces d'attaque AD les plus sous-estimées. La grande majorité des organisations qui l'ont déployé ne savent pas qu'il est là, et encore moins dans quel état il est configuré.

5. Délégation Kerberos non contrainte (Unconstrained Delegation)

La délégation Kerberos permet à un service de s'authentifier auprès d'autres services au nom d'un utilisateur. La délégation non contrainte (unconstrained) est la forme la plus ancienne et la plus dangereuse : un serveur configuré avec ce droit reçoit et stocke le TGT (Ticket Granting Ticket) de n'importe quel utilisateur qui s'y connecte.

Si un attaquant compromet un serveur avec la délégation non contrainte, il peut forcer un Domain Controller à s'y authentifier (via une imprimante ou SpoolSample, par exemple), récupérer le TGT du compte machine du DC, et l'utiliser pour effectuer une DCSync, dump complet du domaine.

Corriger : migrer vers la délégation contrainte (constrained delegation) ou la délégation contrainte basée sur les ressources (RBCD). Identifier tous les comptes et serveurs avec la délégation non contrainte via Get-ADComputer -Filter {TrustedForDelegation -eq $true}.

Ce qu'un pentest Active Directory couvre

Un pentest AD ne se limite pas à lancer BloodHound et à lire le graphe. Il implique une analyse manuelle des configurations spécifiques de votre domaine, la construction de chaînes d'attaque réalistes depuis un point de départ défini (compte utilisateur standard, accès réseau uniquement), et la démonstration d'impact concrète, pas juste un rapport de vulnérabilités théoriques.

Les cinq chemins décrits ici ne sont pas une liste exhaustive, c'est une liste des plus fréquents. DCSync, Pass-the-Hash, Pass-the-Ticket, Shadow Credentials, Golden/Silver Ticket… chaque environnement AD a sa propre combinaison de faiblesses, façonnée par dix ou quinze ans de décisions techniques accumulées. C'est ce qu'un audit est censé révéler.

Une question après la lecture ?

Vous avez un Active Directory et vous voulez savoir ce qu'un attaquant pourrait en faire ? Envoyez un message. Pas de pitch, pas de devis automatique.

Ou réservez directement un cadrage de 30 minutes

Réserver un appel