Politique de mots de passe et Kerberoasting

Une politique de mot de passe robuste

Active Directory permet de définir une politique de mot de passe au niveau du domaine (longueur minimale, complexité, historique) via une Group Policy Object (GPO), et des politiques granulaires (Fine-Grained Password Policy) pour des groupes spécifiques ayant des exigences différentes.

Le Kerberoasting : une attaque ciblant les comptes de service

Kerberoasting exploite une faiblesse du protocole Kerberos : n'importe quel utilisateur authentifié du domaine peut demander un ticket de service pour un compte associé à un Service Principal Name (SPN), puis tenter de casser hors ligne le mot de passe de ce compte à partir du ticket obtenu, sans générer d'alerte immédiate.

flowchart TD
    A[Utilisateur authentifié] -->|Demande ticket pour SPN| B[Contrôleur de domaine]
    B -->|Ticket chiffré avec le hash\ndu mot de passe du compte service| A
    A -->|Cassage hors ligne| C{Mot de passe faible ?}
    C -- Oui --> D[Compromission du compte de service]
    C -- Non --> E[Attaque échoue]

Pourquoi les comptes de service sont vulnérables

Les comptes de service ont souvent des mots de passe anciens, jamais changés, et parfois simples car "personne ne les tape jamais manuellement". Un mot de passe de compte de service faible est directement cassable hors ligne une fois le ticket Kerberos obtenu.

Protéger les comptes de service

• Utiliser des Managed Service Accounts (MSA/gMSA) dont le mot de passe est généré automatiquement, très long et changé périodiquement, sans intervention humaine.
• À défaut, imposer un mot de passe très long (25+ caractères) et aléatoire pour tout compte de service classique disposant d'un SPN.
• Surveiller les demandes anormales de tickets de service (TGS) dans les journaux, un indicateur classique de tentative de Kerberoasting.

Cas concret

Un compte de service SQL Server, créé il y a 8 ans avec un mot de passe de 10 caractères jamais changé depuis, est associé à un SPN. Un attaquant ayant obtenu un accès utilisateur standard sur le domaine demande un ticket Kerberos pour ce compte, l'exporte, et le casse hors ligne en quelques heures avec un mot de passe de cette complexité, obtenant les privilèges du compte de service SQL, souvent très élevés sur la base de données.

Erreurs fréquentes

• Laisser des comptes de service avec des mots de passe courts et anciens, la cible privilégiée du Kerberoasting.
• Ne jamais migrer vers des comptes de service managés (gMSA) alors qu'ils éliminent structurellement ce risque sans effort de gestion continu.
• Ignorer les journaux d'événements liés aux demandes de tickets de service, qui révèlent souvent une attaque en cours avant l'exploitation effective.

À retenir

• Le Kerberoasting cible les comptes de service via leur SPN, exploitable par n'importe quel utilisateur authentifié du domaine.
• Un mot de passe de compte de service long et aléatoire (25+ caractères) rend le cassage hors ligne impraticable.
• Les comptes de service managés (gMSA) éliminent ce risque en gérant automatiquement un mot de passe fort et changé périodiquement.

Mini-exercice

Un compte de service dispose d'un mot de passe de 8 caractères, jamais changé depuis sa création. Quelle attaque ce compte est-il particulièrement exposé, et quelle est la protection la plus robuste ?

Réponse : le Kerberoasting, exploitable par tout utilisateur authentifié du domaine sans privilège particulier. La protection la plus robuste est la migration vers un compte de service managé (gMSA), dont le mot de passe long est généré et renouvelé automatiquement.