Du simple compte au Golden Ticket : attaque d'un Active Directory en homelab
Pour voir ce que mes corrections de production empêchent vraiment, j'ai attaqué dans mon homelab un Active Directory volontairement vulnérable, d'un simple compte utilisateur jusqu'au contrôle complet du domaine.
En bref
J'avais durci un annuaire de production sans jamais voir à l'œuvre les attaques que chaque correction devait contrer.
J'ai monté un domaine vulnérable dans mon homelab et mené huit étapes, de la reconnaissance au Golden Ticket, en notant pour chacune sa trace et sa parade.
Contrôle complet du domaine à partir d'un simple compte. Defender a bloqué le Pass-the-Hash par psexec, et le Golden Ticket n'est passé qu'après trois refus du contrôleur.
Contexte
En production, j'ai audité et durci l'Active Directory d'une PME, sans avoir jamais vu les attaques que ces corrections bloquent. Ce projet comble ce manque, côté attaquant.
Tout se passe dans mon homelab, un cluster Proxmox de trois nœuds : rien ne touche l'entreprise, et ces techniques n'ont servi que sur ce labo, qui m'appartient. Le scénario part d'un accès minimal, le mot de passe d'un simple utilisateur, comme après un hameçonnage réussi. Pour chaque étape, trois questions : ce que l'attaque exploite, la trace qu'elle laisse, la mesure qui l'aurait arrêtée.
Ce que j'ai fait
- Construire un labo reproductibleUn contrôleur Windows Server 2022 et une station Kali, en adressage fixe. Un script PowerShell injecte les faiblesses courantes en entreprise : mots de passe faibles, comptes de service avec SPN, administrateur au mot de passe devinable, politique assouplie. Instantané du contrôleur avant la première attaque.
- Cartographier avec un simple compteNmap repère le contrôleur aux ports qu'il expose forcément (DNS, Kerberos, LDAP, SMB). BloodHound lit ensuite tout l'annuaire et montre les chemins vers les Admins du domaine, sans aucun privilège.
- Casser un compte de service hors ligneTout utilisateur peut demander le ticket d'un compte de service et chercher son mot de passe hors ligne : c'est le Kerberoasting. Deux comptes résistent au dictionnaire rockyou sans règles, ce qui ne les rend pas robustes ; un troisième, ajouté avec un mot de passe courant, cède en moins d'une seconde.
- Obtenir un administrateur du domaineAttaque par dictionnaire sur le seul compte désigné par BloodHound, et non du password spraying, qui essaie un mot de passe sur beaucoup de comptes. Le bon mot de passe fait 11 caractères et respecte la complexité Windows : il faut aussi refuser les mots de passe courants.
- Prendre le domaineAvec ce compte, DCSync réplique les empreintes de tous les comptes, dont
krbtgt. Defender bloque le Pass-the-Hash tenté avec psexec ; un Golden Ticket forgé avec la clé AES256 dekrbtgt, comme les tickets légitimes, ouvre tous les partages du contrôleur sans mot de passe.
Voir les détails techniques
Le labo. Deux VM sur un réseau interne sans DHCP : le contrôleur DC-LAB (4 vCPU, 4 Go de RAM), nouvelle forêt LAB.AD.local, DNS pointé sur lui-même ; la station Kali (2 vCPU, 4 Go), DNS pointé sur le contrôleur, car Kerberos exige une résolution de noms correcte. Pare-feu Windows du contrôleur désactivé, Microsoft Defender actif.
| Faiblesse introduite | Ce qu'elle permet |
|---|---|
| Utilisateurs à mot de passe courant | Le compte de départ de l'attaquant |
| Deux comptes de service avec SPN | Kerberoasting |
| Délégation non contrainte sur un compte de service | Usurper l'identité de quiconque s'y authentifie |
| Un compte membre des Admins du domaine, au mot de passe devinable | Prendre le contrôle du domaine |
| Politique : 4 caractères, sans complexité ni expiration | Rendre tout ce qui précède possible |
Cartographie. Le collecteur BloodHound relève 9 utilisateurs et 52 groupes, avec leurs droits et délégations. La Community Edition refusait de démarrer correctement sur Kali ; la version 4, une seule base graphe, a suffi : le besoin était la carte, pas la dernière interface. PingCastle, lancé en parallèle, classe bien les failles introduites en risque élevé.
Voies abandonnées et constats. L'AS-REP roasting exige un compte sans pré-authentification Kerberos : elle était active sur le compte visé, voie abandonnée. Dans les empreintes répliquées par DCSync, les empreintes LM sont vides : l'ancien algorithme n'est pas stocké.
Une alerte que personne ne voit. Le blocage Defender reste local au contrôleur. Sur un serveur sans session ouverte, l'alerte passe inaperçue : c'est le rôle d'une collecte centralisée comme mon SOC Wazuh.
Un fichier de tickets vide, sans erreur. L'option d'écriture de l'outil d'extraction produisait un fichier vide alors que les tickets s'affichaient à l'écran. J'ai contrôlé le contenu réel du fichier, puis filtré la sortie standard moi-même : plus simple à vérifier.
| Attaque | Trace et détection | Contre-mesure |
|---|---|---|
| Reconnaissance (Nmap, BloodHound) | Volume inhabituel de requêtes LDAP depuis un poste, visible seulement si les journaux sont centralisés | On ne peut pas interdire la lecture de l'annuaire à un compte authentifié : on détecte |
| Kerberoasting | Rafale de demandes de tickets de service en RC4 (événement 4769 sur le contrôleur) | Mots de passe de service de 25 caractères aléatoires ou plus, ou comptes de service gérés (gMSA) |
| Dictionnaire sur un compte | Échecs d'authentification répétés sur le même compte | Seuil de verrouillage, mot de passe long et non courant pour tout compte d'administration, MFA sur les comptes sensibles |
| DCSync | Demande de réplication venue d'une machine qui n'est pas un contrôleur (événement 4662) | Limiter les comptes qui ont les droits de réplication |
| Pass-the-Hash | Alerte Defender, observée ici, mais locale au serveur | Groupe Protected Users pour les comptes sensibles, antivirus ou EDR à jour, collecte centralisée |
| Golden Ticket | Pas de fichier ni de service, mais des anomalies Kerberos repérables si les journaux du contrôleur sont collectés | Protéger les comptes qui ont les droits de réplication (la clé vient de DCSync) ; double rotation de krbtgt pour invalider les tickets déjà forgés ; un Windows Server à jour rejette déjà les comptes inexistants |
L'incident
Le Golden Ticket refusé trois fois
Le contrôleur rejette le ticket forgé, alors que la clé de krbtgt est correcte.
Trois causes levées une à une : plusieurs heures d'écart d'horloge, quand Kerberos en tolère cinq minutes ; un ticket forgé avant la correction de l'heure ; un compte inventé, qu'un Windows Server 2022 à jour rejette. Reforgé pour le compte réel « Administrateur », le ticket est accepté.
Résultats
Le ticket donne accès à tous les partages du contrôleur, disque système compris, et reste valable plusieurs années. Changer tous les mots de passe ne l'invalide pas ; seule une double rotation de krbtgt le fait.
C'est précisément ce que j'avais appliqué sur l'annuaire de production : double rotation de krbtgt, LM et NTLMv1 refusés, 11 comptes d'administration marqués « sensibles, ne peuvent pas être délégués », ce qui les protège d'une délégation non contrainte, et groupe Protected Users testé. Ce labo m'a montré concrètement ce que chacune de ces mesures neutralise, et ses limites : la double rotation invalide les tickets déjà forgés, elle n'empêche pas d'en forger un nouveau si la clé fuit à nouveau. Les correctifs récents réduisent aussi la marge de l'attaquant : la même attaque, qui passait autrefois avec un compte fictif, exige aujourd'hui un compte existant.
Ce que j'améliorerais
- Exploiter la délégation non contrainte configurée sur le compte de service : une étape réaliste de plus, et l'effet de l'option « compte sensible » de production rendu visible.
- Relever les traces côté Windows (événements 4769 et 4662, après activation de l'audit) et les faire remonter dans le SIEM, pour vérifier que chaque étape déclenche une alerte.
- Isoler le labo dans un VLAN dédié, sans route vers le reste du homelab : le premier scan voyait cinq hôtes pour deux machines de labo.
Compétences
Pour aller plus loin
- Golden Ticket refusé trois fois : Un Golden Ticket forgé avec la bonne clé krbtgt, refusé trois fois par le contrôleur, et ce que chaque refus montre des vérifications de Kerberos.