Le Kerberoasting en une page

Le compte de service est ce collègue qui ne prend jamais de congés, ne change jamais de mot de passe et détient les clés de la maison : on le trouve fiable, et on n’est pas le seul.

L’essentiel

• Le risque tient en une phrase. Tout compte authentifié du domaine peut obtenir un ticket de service pour n’importe quel SPN ; ce ticket est chiffré avec une clé dérivée du mot de passe du compte de service, et un mot de passe faible se retrouve hors ligne, loin de tout journal.
• On ne ferme pas la porte, on vide la pièce. Délivrer des tickets est le métier du contrôleur de domaine. La défense consiste à rendre le ticket inexploitable, par la force du secret et la modestie des droits.
• gMSA d’abord. Le compte de service géré de groupe (depuis Windows Server 2012) porte un mot de passe aléatoire très long, que le domaine renouvelle seul (tous les 30 jours par défaut) et qu’aucun humain ne connaît. Il n’y a rien à deviner.
• Sinon, un vrai secret. Quand l’application refuse le gMSA : mot de passe aléatoire de 25 caractères ou plus, rangé dans un coffre, renouvelé par outillage plutôt que par la mémoire de quelqu’un.
• AES seul, RC4 refusé. L’attribut msDS-SupportedEncryptionTypes du compte à 0x18 (AES128 et AES256). La clé RC4 n’est autre que le condensat NT, sans sel ni itérations ; la clé AES est salée et dérivée par 4096 itérations (RFC 3962). Avant de couper RC4, on mesure qui le demande encore.
• Moindre privilège. Aucun SPN sur un compte d’administration, aucun compte de service dans un groupe privilégié : si le secret tombe un jour, c’est un service qui tombe, pas le domaine.
• L’événement 4769 se lit. Émis par les contrôleurs de domaine à chaque ticket de service délivré, il donne le compte demandeur, le SPN et le type de chiffrement (0x17 pour RC4, 0x12 pour AES256). Un ticket RC4 pour un compte censé être en AES, ou une rafale de SPN distincts depuis un même compte, méritent une alerte.

Idées reçues, et fausses

• « Il faut être administrateur pour obtenir ces tickets. » Faux. N’importe quel compte du domaine suffit, celui du stagiaire arrivé lundi compris. C’est même ce qui rend le risque si démocratique.
• « Un mot de passe de service qui n’expire jamais, c’est de la stabilité. » Faux. C’est une cible qui ne bouge pas. Le ticket se travaille hors ligne aussi longtemps qu’il faut, et « Printemps2019! » a eu le temps de voir passer beaucoup de printemps.
• « Passer en AES règle le problème. » Faux. AES ralentit beaucoup l’essai de mots de passe, il ne rend pas fort un mot de passe faible. Il le fait seulement tomber moins vite, ce qui est une consolation plutôt qu’une parade.
• « Le compte doit être administrateur du domaine, l’installateur l’a demandé. » Faux. Presque aucune application n’en a besoin ; l’installateur l’a demandé parce que c’était plus simple pour lui. Les droits se donnent sur ce que le service touche, et c’est rarement l’annuaire entier.
• « Nos journaux nous préviendront. » Faux. Le 4769 consigne une demande parfaitement normale, et le travail sur le ticket se fait ailleurs, hors de toute trace. Sans règle sur le chiffrement et le volume, et sans quelqu’un pour lire l’alerte, le journal se contente d’être exhaustif.

Pour aller plus loin : Kerberos et KDC dans Active Directory, attaques et durcissement · Active Directory délégations et chemins d’attaque · Authentifier les personnes et les services · Vault PAM et enregistrement des sessions admin · Calibrer les alertes d’un SIEM sans noyer le SOC · NTLM, fonctionnement et durcissement.

À lire aussi

• L'administration Active Directory en tiers en une pageTiers 0, 1 et 2 : pourquoi un admin du domaine connecté sur un poste de travail expose tout le domaine, et les cloisons qui l'en empêchent : un compte par tier, poste d'administration dédié, LAPS, Protected Users.
• Authentification défi-réponse, rejeu, relais et attaque hors ligneComment l'authentification par défi-réponse prouve la connaissance d'un secret sans le transmettre dans CHAP, NTLM, Kerberos et FIDO2, et pourquoi le rejeu, le relais et l'attaque hors ligne restent possibles.
• Registre Windows, GPO et services, fonctionnement et attaquesComment le registre Windows, les GPO et les services s'articulent, où se logent la persistance et l'élévation de privilèges, et ce qu'il faut verrouiller en premier.
• Attaque par relais NTLM et signature SMB obligatoireMonter un relais NTLM en laboratoire, s'authentifier à la place d'une victime sans casser son mot de passe, puis refermer la faille avec la signature SMB et la liaison de canal.

Pages voisines

Le Kerberoasting en une page

Elle cite

• Active Directory délégations et chemins d’attaque
• Authentifier les personnes et les services
• Comment calibrer les alertes d’un SIEM sans noyer le SOC
• Kerberos et KDC dans Active Directory, attaques et durcissement
• NTLM : protocole authentification LAN Manager New Technology Microsoft
• Vault PAM et enregistrement des sessions admin