Pentest Active Directory : les attaques les plus courantes en 2024

Sommaire

Active Directory (AD) est le service d’annuaire de Microsoft utilisé par plus de 95% des entreprises du Fortune 500 et par la quasi-totalité des PME et ETI françaises. Il centralise l’authentification, l’autorisation et la gestion des ressources informatiques. Cette position centrale en fait la cible prioritaire de toute intrusion en environnement d’entreprise : compromettre l’Active Directory, c’est obtenir les clés du royaume.

Lors de nos tests d’intrusion internes, nous parvenons à compromettre le domaine Active Directory dans la grande majorité des cas, souvent en quelques heures. Voici les techniques d’attaque les plus courantes que nous utilisons et que les vrais attaquants exploitent quotidiennement.

Énumération avec BloodHound

Avant d’attaquer, il faut comprendre. BloodHound est l’outil de référence pour cartographier un environnement Active Directory. Développé par les chercheurs de SpecterOps, il analyse les relations entre les objets AD (utilisateurs, groupes, machines, GPO) pour identifier les chemins d’attaque vers les comptes à haut privilège.

Comment ça fonctionne

BloodHound utilise un collecteur (SharpHound ou BloodHound.py) pour interroger l’Active Directory et récupérer :

• Les membres de chaque groupe (et groupes imbriqués)
• Les sessions utilisateurs actives sur chaque machine
• Les droits d’administration locale
• Les ACL (Access Control Lists) sur les objets AD
• Les relations d’approbation entre domaines et forêts

Ces données sont importées dans une base de données Neo4j et visualisées sous forme de graphe. L’outil identifie automatiquement les chemins les plus courts vers les groupes Domain Admins, Enterprise Admins, et autres groupes à haut privilège.

Impact

Un utilisateur de domaine standard (sans aucun privilège particulier) peut exécuter BloodHound et obtenir une cartographie complète de l’AD. Cela révèle souvent des chemins d’attaque insoupçonnés, par exemple : un utilisateur lambda est administrateur local d’un serveur sur lequel un Domain Admin a une session active.

Comment se protéger

• Limitez les droits de lecture sur les objets AD sensibles
• Réduisez le nombre d’administrateurs locaux sur les postes et serveurs
• Nettoyez les sessions des comptes à privilèges (n’utilisez jamais un compte Domain Admin pour vous connecter à un poste utilisateur)
• Auditez régulièrement les ACL avec des outils comme PingCastle ou Purple Knight
• Exécutez vous-même BloodHound pour identifier vos chemins d’attaque avant qu’un attaquant ne le fasse

Kerberoasting

Le Kerberoasting est l’une des attaques les plus efficaces et les plus fréquentes contre Active Directory. Elle exploite le fonctionnement normal du protocole Kerberos pour extraire des hachages de mots de passe de comptes de service.

Comment ça fonctionne

1. L’attaquant, disposant d’un compte de domaine quelconque, demande un ticket de service (TGS) pour chaque compte ayant un Service Principal Name (SPN) configuré
2. Le contrôleur de domaine fournit le ticket, qui est chiffré avec le hachage NTLM du mot de passe du compte de service
3. L’attaquant extrait le ticket et le soumet à un outil de cracking offline comme Hashcat ou John the Ripper
4. Si le mot de passe du compte de service est faible (ce qui est très souvent le cas), il est cassé en quelques minutes ou heures

Cette attaque est particulièrement redoutable car :

• Elle ne génère aucune alerte dans les logs par défaut (demander un TGS est un comportement normal)
• Le cracking se fait offline, donc aucune tentative de connexion échouée n’est enregistrée
• De nombreux comptes de service utilisent des mots de passe faibles ou qui ne sont jamais changés
• Les comptes de service ont souvent des privilèges élevés (administrateur de base de données, compte de sauvegarde, etc.)

Outils utilisés

• Rubeus (C#) : Rubeus.exe kerberoast
• Impacket (Python) : GetUserSPNs.py domain/user:password -request
• PowerView : Invoke-Kerberoast

Comment se protéger

• Mots de passe de 25+ caractères pour tous les comptes de service avec SPN
• Comptes de service gérés (gMSA) : Azure AD/Windows gère automatiquement des mots de passe de 240 caractères
• Supprimez les SPN inutiles : si un compte n’a plus besoin de son SPN, supprimez-le
• Surveillez les demandes TGS anormales : un volume élevé de demandes TGS depuis un même compte est suspect
• Chiffrement AES : configurez les comptes de service pour utiliser uniquement AES256 (et non RC4)

AS-REP Roasting

L’AS-REP Roasting est similaire au Kerberoasting mais cible les comptes dont la pré-authentification Kerberos est désactivée (attribut DONT_REQUIRE_PREAUTH).

Comment ça fonctionne

Normalement, lors d’une demande de TGT (Ticket Granting Ticket), le client doit prouver son identité en chiffrant un timestamp avec son hachage de mot de passe (pré-authentification). Si cette pré-authentification est désactivée pour un compte, n’importe qui peut demander un TGT pour ce compte, et le contrôleur de domaine répondra avec des données chiffrées avec le hachage du mot de passe du compte.

L’attaquant peut alors cracker ce hachage offline, comme pour le Kerberoasting.

Outils utilisés

• Rubeus : Rubeus.exe asreproast
• Impacket : GetNPUsers.py domain/ -usersfile users.txt -no-pass

Comment se protéger

• Activez la pré-authentification Kerberos sur tous les comptes (c’est le paramètre par défaut — vérifiez qu’il n’a pas été modifié)
• Identifiez les comptes avec DONT_REQUIRE_PREAUTH : Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
• Mots de passe robustes sur les comptes concernés si la désactivation est nécessaire (certaines applications legacy l’exigent)

Relais NTLM (NTLM Relay)

Le relais NTLM exploite le protocole d’authentification NTLM pour relayer les identifiants d’un utilisateur vers un autre service, sans avoir besoin de connaître le mot de passe.

Comment ça fonctionne

1. L’attaquant se positionne en man-in-the-middle sur le réseau (via LLMNR/NBT-NS poisoning, ARP spoofing, ou un partage réseau piégé)
2. Lorsqu’un utilisateur tente de s’authentifier, sa requête NTLM est interceptée
3. L’attaquant relaye cette authentification vers un autre serveur (serveur de fichiers, Exchange, LDAP, MSSQL, etc.)
4. Le serveur cible accepte l’authentification car elle provient d’un utilisateur légitime

Les attaques de relais NTLM les plus puissantes en 2024 :

• PetitPotam : force un contrôleur de domaine à s’authentifier vers l’attaquant via MS-EFSRPC, puis relaye vers les services de certificats AD (ADCS) pour obtenir un certificat de DC
• Coerce + NTLM relay vers LDAP : si la signature LDAP n’est pas requise, l’attaquant peut modifier les ACL AD pour s’octroyer des privilèges
• Relais vers ADCS (ESC8) : si le service d’inscription web ADCS ne requiert pas l’EPA (Extended Protection for Authentication), l’attaquant peut obtenir un certificat au nom de la machine relayée

Comment se protéger

• Désactivez NTLM autant que possible et migrez vers Kerberos
• Activez la signature SMB (SMB signing) sur tous les serveurs et postes
• Activez la signature LDAP (LDAP signing) et le channel binding sur les contrôleurs de domaine
• Désactivez LLMNR et NBT-NS via GPO
• Activez l’Extended Protection for Authentication (EPA) sur ADCS et tous les services web IIS
• Appliquez les correctifs PetitPotam (KB5005413 et suivants)

Pass-the-Hash (PtH)

Le Pass-the-Hash est une technique qui permet de s’authentifier avec le hachage NTLM d’un mot de passe, sans connaître le mot de passe en clair.

Comment ça fonctionne

1. L’attaquant obtient le hachage NTLM d’un utilisateur (via extraction de la mémoire LSASS avec Mimikatz, dump de la base SAM, ou récupération dans les secrets du domaine)
2. Il utilise ce hachage pour s’authentifier auprès de services qui acceptent l’authentification NTLM (SMB, WMI, RPC, etc.)
3. Aucun cracking n’est nécessaire : le hachage lui-même sert de preuve d’authentification

Le Pass-the-Hash est souvent utilisé pour le mouvement latéral : l’attaquant compromet un premier poste, extrait les hachages des comptes qui s’y sont connectés, puis les utilise pour se connecter à d’autres machines.

Outils utilisés

• Mimikatz : sekurlsa::pth /user:admin /ntlm:hash /domain:corp.local
• Impacket : psexec.py domain/user@target -hashes :ntlm_hash
• CrackMapExec : cme smb targets.txt -u admin -H ntlm_hash

Comment se protéger

• Déployez Credential Guard (Windows 10/11 Enterprise) pour protéger les identifiants en mémoire
• Limitez les comptes à privilèges : appliquez le principe du moindre privilège
• Utilisez le tiering modèle (modèle en niveaux) : les comptes Tier 0 (Domain Admins) ne doivent jamais se connecter sur des machines Tier 1 ou Tier 2
• Activez Protected Users : les membres de ce groupe ne peuvent pas utiliser l’authentification NTLM
• Déployez LAPS (Local Administrator Password Solution) pour des mots de passe admin locaux uniques par machine
• Surveillance SIEM : alertez sur les connexions administratives anormales

DCSync

L’attaque DCSync permet à un attaquant de simuler un contrôleur de domaine et de demander la réplication de tous les hachages de mots de passe de l’annuaire, y compris celui du compte krbtgt.

Comment ça fonctionne

Active Directory utilise un protocole de réplication (MS-DRSR) pour synchroniser les données entre les contrôleurs de domaine. Un utilisateur disposant des droits Replicating Directory Changes et Replicating Directory Changes All (droits accordés par défaut aux Domain Controllers, Domain Admins, et Enterprise Admins) peut demander la réplication de n’importe quel objet, y compris les hachages de mots de passe.

L’attaquant n’a besoin que d’un accès réseau vers un contrôleur de domaine et d’un compte disposant de ces droits de réplication.

Outils utilisés

• Mimikatz : lsadump::dcsync /domain:corp.local /user:krbtgt
• Impacket : secretsdump.py domain/admin:password@dc01.corp.local

Comment se protéger

• Auditez les droits de réplication : identifiez tous les comptes disposant des droits DCSync
• Retirez les droits de réplication à tous les comptes qui n’en ont pas besoin (seuls les DC devraient les avoir)
• Surveillez les événements 4662 avec le GUID de la propriété de réplication DS-Replication-Get-Changes-All
• Segmentez le réseau : limitez les accès réseau vers les contrôleurs de domaine

Golden Ticket et Silver Ticket

Les Golden Tickets et Silver Tickets sont des tickets Kerberos forgés qui permettent un accès persistant et quasi indétectable à l’environnement AD.

Golden Ticket

Un Golden Ticket est un TGT forgé utilisant le hachage du compte krbtgt. Avec ce ticket, l’attaquant peut :

• S’authentifier en tant que n’importe quel utilisateur du domaine, y compris des utilisateurs inexistants
• Accéder à toutes les ressources du domaine sans restriction
• Persister même après un changement de mots de passe des utilisateurs (le Golden Ticket reste valide tant que le mot de passe du compte krbtgt n’est pas changé deux fois)

Silver Ticket

Un Silver Ticket est un TGS forgé utilisant le hachage du compte de la machine ou du service cible. Il est plus limité qu’un Golden Ticket (accès uniquement au service ciblé) mais aussi plus discret car il ne nécessite pas de communication avec le contrôleur de domaine.

Comment se protéger

• Changez le mot de passe du compte krbtgt deux fois consécutivement (avec un intervalle d’au moins 12 heures entre les deux changements)
• Surveillez les événements de tickets Kerberos anormaux (durée de vie excessive, chiffrement inhabituels)
• Déployez Microsoft Defender for Identity (ou un outil SIEM équivalent) pour détecter l’utilisation de Golden/Silver Tickets
• Réduisez la durée de vie des tickets Kerberos (10 heures par défaut pour les TGT)

Pourquoi le pentest AD est indispensable

Active Directory est un composant complexe dont la sécurité repose sur un grand nombre de paramètres de configuration, de droits d’accès et de politiques. Les erreurs de configuration sont extrêmement courantes car :

• Les environnements AD évoluent sur des années, accumulant une dette technique considérable
• Les droits sont ajoutés mais rarement retirés (privilege creep)
• Les comptes de service sont créés avec des mots de passe faibles et jamais changés
• Les configurations par défaut sont souvent insécurisées (NTLM activé, SMB signing désactivé, etc.)
• Les outils de gestion natifs (ADUC, GPO) ne permettent pas de visualiser les chemins d’attaque

Un test d’intrusion Active Directory permet de :

• Identifier les chemins d’attaque réels avant qu’un attaquant ne les exploite
• Valider l’efficacité des mesures de sécurité en place (tiering, LAPS, Credential Guard)
• Prioriser les remédiations en fonction de l’impact réel démontré
• Sensibiliser la direction avec des scénarios d’attaque concrets (« nous avons obtenu les droits Domain Admin en 3 heures depuis un poste utilisateur standard »)

Chez Expert Intrusion, nous réalisons des tests d’intrusion Active Directory en boîte grise, simulant un attaquant ayant obtenu un premier accès au réseau interne. Nous identifions et exploitons les chemins d’attaque vers la compromission du domaine, puis vous accompagnons dans la remédiation avec un plan d’action priorisé.