Kerberoasting : Cracker les Mots de Passe des Comptes de Service

Qu'est-ce que le Kerberoasting ?

Le Kerberoasting est une technique d'attaque Active Directory qui permet à n'importe quel utilisateur authentifié du domaine d'extraire des hashes de mots de passe crackables depuis des comptes de service, sans aucun privilège particulier.

L'attaque cible les comptes avec un Service Principal Name (SPN) configuré. Dans Kerberos, tout utilisateur du domaine peut demander un ticket de service (TGS) pour n'importe quel SPN. Ce ticket est chiffré avec le hash NTLM du compte de service. Un attaquant peut demander le ticket, l'exporter et cracker le hash hors ligne.

Aucun droit élevé requis. Aucune interaction avec le compte cible. Aucune alerte sur le système cible. Juste une requête Kerberos légitime.

⚠️ Pourquoi c'est grave : Les comptes de service ont souvent des mots de passe qui n'expirent jamais, configurés il y a des années, sans exigences de complexité strictes.

Comment ca fonctionne

Quand un utilisateur veut accéder à un service, Kerberos émet un ticket TGS chiffré avec le hash NTLM du compte exécutant ce service. Le KDC ne vérifie pas si l'utilisateur a réellement besoin d'accéder au service : il émet simplement le ticket.

Ce fonctionnement intentionnel permet au service de valider le ticket localement, mais cela signifie aussi que n'importe quel utilisateur du domaine peut collecter autant de tickets de service qu'il le souhaite, sans aucun contrôle d'autorisation.

La Chaine d'Attaque

Etape 1 - Enumérer les SPNs

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet, PasswordNeverExpires |
    Select-Object SamAccountName, ServicePrincipalName, PasswordLastSet, PasswordNeverExpires

impacket-GetUserSPNs -dc-ip 10.10.0.1 corp.local/user:password

Cibles intéressantes : comptes avec PasswordNeverExpires = True, dates PasswordLastSet anciennes, noms lisibles comme svc_sql, svc_backup.

Etape 2 - Demander les Tickets de Service

.\Rubeus.exe kerberoast /outfile:hashes.txt

impacket-GetUserSPNs -dc-ip 10.10.0.1 corp.local/user:password -request -outputfile hashes.txt

Etape 3 - Cracker Hors Ligne

# Mode 13100 pour RC4 — des centaines de millions de tentatives/seconde
hashcat -m 13100 hashes.txt /usr/share/wordlists/rockyou.txt --rules-file best64.rule

# Mode 19700 pour AES-256
hashcat -m 19700 hashes.txt /usr/share/wordlists/rockyou.txt

Etape 4 - Mouvement Latéral et Escalade

Un mot de passe de compte de service cracké ouvre l'accès à tout ce à quoi ce compte a accès. Si le compte est sur-privilégié, cela peut signifier un chemin direct vers Domain Admin.

Détection

Event IDs Windows

Anomalies Comportementales

• Demandes TGS en masse depuis un seul compte en quelques secondes
• Chiffrement RC4 alors que le domaine impose AES uniquement
• Demandes en dehors des heures ouvrées depuis des comptes développeurs
• IPs source inconnues n'ayant jamais fait de telles demandes

Requete SIEM (Elastic KQL)

event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")

💡 Conseil : Imposez AES uniquement sur le domaine. Toute demande RC4 devient alors une alerte de haute confiance.

Remédiation

💡 Action Rapide : Auditez les comptes avec PasswordNeverExpires = True et changez tout mot de passe de plus d'un an immédiatement.

1. Mots de passe longs et forts - minimum 25 caractères générés aléatoirement, rendant le cracking hors ligne infaisable même avec RC4.

2. Group Managed Service Accounts (gMSA) - mots de passe de 240 caractères gérés automatiquement par AD.

New-ADServiceAccount -Name gMSA_SQL -DNSHostName sql.corp.local -PrincipalsAllowedToRetrieveManagedPassword "SQL_Servers"
Install-ADServiceAccount -Identity gMSA_SQL

3. Imposer AES sur les comptes de service.

Set-ADUser -Identity svc_sql -Replace @{msDS-SupportedEncryptionTypes=24}

4. Principe du moindre privilège - les comptes de service ne doivent avoir que les permissions nécessaires.

Auditer l'Exposition

Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties PasswordLastSet, PasswordNeverExpires |
    Where-Object {$_.PasswordNeverExpires -eq $true -or $_.PasswordLastSet -lt (Get-Date).AddYears(-1)} |
    Select-Object SamAccountName, PasswordLastSet, PasswordNeverExpires

Comment EtcSec Détecte Cela

EtcSec identifie les conditions qui rendent le Kerberoasting possible avant qu'un attaquant ne les exploite.

La détection KERBEROASTING_RISK signale tous les comptes avec un SPN configuré vulnérables en raison d'une posture de mot de passe faible : mots de passe anciens, non expirables, ou RC4 activé.

Contrôles associés :

• PASSWORD_NEVER_EXPIRES - mots de passe non expirables restent crackables indéfiniment
• PASSWORD_POLICY_WEAK - politique faible rend le cracking plus probable
• KERBEROS_RC4_FALLBACK - RC4 encore autorisé accélère le cracking et complique la détection

ℹ️ Note : EtcSec vérifie automatiquement ces vulnérabilités lors de chaque audit AD. Lancez un audit gratuit pour voir quels comptes de service sont exposés.

Priorites de Revue

Kerberoasting : Cracker les Mots de Passe des Comptes de Service doit etre traite comme une exposition reelle dans votre environnement Active Directory, pas comme un simple parametre isole. La premiere etape consiste a definir le vrai perimetre de revue : quels groupes privilegies, comptes de service, ACL, liens GPO, trusts, delegations, templates de certificats et postes d'administration sont concernes, quelles dependances metier existent, quels privileges sont exposes et quelles exceptions d'urgence ont ete ajoutees avec le temps. Ce cadrage evite une remediation superficielle, car le symptome technique est souvent plus petit que le rayon d'impact operationnel. En documentant le chemin complet entre configuration, privilege et usage reel, l'equipe peut prioriser des changements qui reduisent le risque sans bloquer l'activite.

Controles Adjacents a Revoir

Quand un attaquant arrive dans votre environnement Active Directory, il ne s'arrete presque jamais au premier point faible. Autour de Kerberoasting : Cracker les Mots de Passe des Comptes de Service, il cherche en general a enchainer avec comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees. Cela signifie que la defense doit revoir non seulement la faiblesse principale, mais aussi toutes les dependances qui transforment un acces initial en persistance ou en escalation. Verifiez quelles identites, quels roles, quelles permissions et quelles hypotheses de confiance peuvent etre reutilises. Si le correctif ferme un seul objet mais laisse intactes les voies adjacentes, le risque reel change peu. Une revue des chaines d'abus est donc indispensable pour obtenir un resultat durable.

Preuves et telemetry a collecter

Une bonne reponse a Kerberoasting : Cracker les Mots de Passe des Comptes de Service repose sur des preuves que l'ingenierie et la detection peuvent relire ensemble. Collectez Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, comparez les changements recents avec les fenetres de maintenance attendues et isolez les comptes ou objets qui ont change de comportement sans justification claire. Ces elements doivent permettre de repondre a trois questions simples : quand l'exposition est apparue, qui peut encore l'utiliser, et si des variantes similaires existent ailleurs dans votre environnement Active Directory. La collecte de preuves aide aussi a distinguer une dette technique ancienne d'un usage actif. Cette distinction est essentielle pour choisir le bon niveau d'urgence et la bonne sequence de remediation.

Faiblesses voisines a revoir

Tres peu d'environnements contiennent Kerberoasting : Cracker les Mots de Passe des Comptes de Service seul. Dans la pratique, la meme zone du tenant ou de l'annuaire contient souvent aussi comptes privilegies obsoletes, imbrication dangereuse de groupes, delegations excessives, politiques de mot de passe faibles et abus d'ACL heritees, et ce sont ces faiblesses voisines qui determinent si l'exposition reste limitee ou devient critique. Revoyez les owners communs, les permissions heritees, les exceptions dupliquees et les raccourcis administratifs qui n'ont jamais ete retires. Verifiez si la meme logique de contournement a ete approuvee a plusieurs endroits, car cela revele souvent une faille de processus plus qu'un bug unique. Cette revue elargie donne une meilleure chance d'eliminer le chemin d'attaque complet.

Ordre de remediation recommande

Pour Kerberoasting : Cracker les Mots de Passe des Comptes de Service, l'ordre de remediation doit privilegier la reduction de risque avant la perfection. Commencez par fermer les chemins qui augmentent le plus vite le privilege, puis verrouillez les objets ou identites a plus forte valeur, et ensuite seulement traitez les ecarts de hygiene secondaires. Utilisez tiering, nettoyage des delegations, revue ACL, hygiene des comptes de service, revue des permissions GPO et durcissement ADCS comme ensemble de controles cible. Chaque changement doit avoir un owner, une note de rollback et une etape de validation. Cette discipline evite que les programmes de correction s'arretent apres le premier gain technique. Si une refonte complete n'est pas possible tout de suite, formalisez des controles intermediaires et planifiez le travail structurel dans le prochain revue hebdomadaire des privileges et validation mensuelle des controles.

Validation apres chaque changement

Apres toute modification liee a Kerberoasting : Cracker les Mots de Passe des Comptes de Service, validez le resultat sous deux angles : administration legitime et chemin d'attaque. Confirmez que les utilisateurs et systemes attendus continuent de fonctionner, puis prouvez que la voie dangereuse ne donne plus le meme levier. Rejouez la collecte sur Event IDs 4624, 4662, 4670, 4688, 4728, 4732, 4768, 4769, 5136, changements SYSVOL et activite des certificats, relisez les approbations et verifiez qu'aucun objet voisin ne conserve une voie de contournement. La validation doit aussi inclure une definition ecrite du succes, afin que tout le monde sache ce qui constitue une fermeture acceptable. Dans les equipes matures, un correctif n'est accepte que lorsque le chemin risque est ferme et que l'etat final correspond vraiment a l'objectif de durcissement.

Lectures Connexes

Pour traiter ce sujet correctement, reliez-le a AS-REP Roasting : Collecter des Hashes Sans Credentials, Mots de Passe AD : Erreurs de Configuration Critiques, Comptes Obsolètes et Sur-Privilégiés dans AD, Délégation Kerberos : Non Contrainte à RBCD et Imbrication Dangereuse de Groupes AD : Chemins vers Domain Admin. Cet ensemble montre comment les memes erreurs d'identite, de privileges et de configuration se combinent dans une revue reelle au lieu d'apparaitre comme des constats isoles.

• AS-REP Roasting : Collecter des Hashes Sans Credentials
• Mots de Passe AD : Erreurs de Configuration Critiques
• Comptes Obsolètes et Sur-Privilégiés dans AD
• Délégation Kerberos : Non Contrainte à RBCD
• Imbrication Dangereuse de Groupes AD : Chemins vers Domain Admin

Ces liens internes gardent la remediaton centree sur le chemin d'attaque complet et pas seulement sur un controle pris separement.

Questions a Trancher Avant la Validation Finale

Avant qu'une equipe considere un sujet identite comme vraiment traite, elle devrait pouvoir repondre a quelques questions simples avec des preuves concretes. Quel compte, quel groupe ou quel systeme reste aujourd'hui le chemin d'exception le plus sensible ? Quelle dependance operationnelle a empeche une remediation plus complete, et qui a accepte ce risque de facon explicite ? Quel controle compensatoire, quelle regle de supervision ou quelle frequence de revue couvre desormais l'exposition residuelle en production ? Ces questions comptent parce qu'une faiblesse d'identite revient souvent lorsque la note de remediaton est plus forte que la realite d'exploitation. Si l'organisation ne peut pas expliquer clairement le proprietaire, la dependance metier et la prochaine date de revue, le controle n'est generalement pas aussi stable qu'il en a l'air.

Preuves a Conserver pour la Revue Suivante

Les equipes les plus solides conservent juste assez de preuves pour rendre la revue suivante plus rapide et plus fiable. Cela inclut en general le proprietaire actuel de l'actif concerne, le changement de configuration exact qui a reduit le risque, la liste des exceptions encore acceptees et la preuve technique montrant que le nouvel etat est bien applique en production. Cette discipline est utile parce que les problemes d'identite et de privilege ne sont presque jamais des decouvertes uniques. Ils reviennent plutot via le turnover administrateur, la derive applicative ou des dependances historiques mal comprises au premier passage. En documentant a la fois la correction et la raison pour laquelle elle a ete acceptee, les equipes reduisent le risque de refaire la meme analyse a chaque cycle ou de reintroduire la meme faiblesse en corrigeant un autre sujet operationnel.

Ce Qu'il Faut Reverifier au Prochain Changement Majeur

Les programmes de securite les plus solides reverifient le meme controle apres la prochaine fenetre de changement importante, et pas seulement juste apres la correction initiale. Nouvelles applications, mouvements d'OU, delegations d'administration et exceptions d'urgence recreent souvent le risque via le fonctionnement normal. Une revue courte centree sur les changements recents, les proprietaires et les exceptions suffit souvent a detecter cette derive avant qu'elle ne devienne la nouvelle norme.

Kerberoasting : validation avant clôture

Une revue solide de Kerberoasting doit se terminer par des preuves de production, pas par l'hypothèse que le chemin risqué a disparu. Avant de clôturer le constat, revalidez les options de compte, les paramètres de protocole ou l'état des SPN et de la délégation, le chemin d'authentification encore atteignable du point de vue attaquant et les logs, tickets ou preuves de configuration montrant le changement. Confirmez que l'état plus sûr s'applique bien au périmètre qui compte réellement : l'OU de production, l'attribution de rôle effective, le chemin applicatif ou le chemin de délégation et de confiance qu'un attaquant pourrait réellement exploiter. Documentez le propriétaire technique, la dépendance métier et la condition de retour arrière afin que le prochain cycle sache si l'état plus sûr a été maintenu.

Utilisez une checklist de clôture courte :

• vérifier que l'état risqué a disparu du point de vue attaquant, pas seulement dans une capture d'écran admin
• conserver un export avant/après ou un échantillon de log prouvant que la portée concernée a changé
• documenter le propriétaire et la décision d'exception si le contrôle ne peut pas être appliqué complètement

Pour les expositions adjacentes, recoupez le résultat avec Audit de sécurité Active Directory : checklist pratique, Délégation Kerberos : Non Contrainte à RBCD, AS-REP Roasting : Collecter des Hashes Sans Credentials, et Golden Ticket : Les Clés de Votre Domaine. Le même défaut de contrôle réapparaît souvent dans des chemins d'identité voisins, des manques de journalisation ou des délégations trop larges, d'où l'importance de cette validation finale.

Kerberoasting : preuves à conserver pour le prochain cycle

Le prochain relecteur ne devrait pas avoir à reconstruire le dossier de mémoire. Conservez la preuve qui justifiait le constat initial, la preuve que le changement a été appliqué, et la note qui explique pourquoi l'état final est acceptable. Pour ce sujet, les preuves les plus utiles combinent généralement l'inventaire des comptes ou services lié au chemin risqué, la preuve de protocole, de stratégie ou d'hôte montrant que la mitigation fonctionne et le propriétaire et les dépendances applicatives affectées par le changement. Ce paquet compact accélère fortement les revues trimestrielles ou après changement et permet d'expliquer si le problème a été supprimé, réduit ou accepté formellement.

Si un changement d'admin, de politique ou d'application rouvre plus tard le chemin, cet historique permet aussi de démontrer précisément ce qui a dérivé. C'est ce qui transforme Kerberoasting en processus d'assurance répétable plutôt qu'en contrôle ponctuel.