AS-REP Roasting : casser les comptes qui ont sauté la préauth Kerberos

La plupart des attaques Kerberos partent du principe que vous avez déjà un pied dans la place. L'AS-REP roasting, non, et c'est précisément ce qui en fait la première chose à vérifier sur une mission interne.

Toute l'attaque repose sur un seul drapeau de compte : DONT_REQ_PREAUTH. Quand un compte a l'option "Ne pas demander la préauthentification Kerberos" activée, le contrôleur de domaine remet une AS-REP à quiconque en fait la demande au nom de ce compte. Une partie de cette réponse est chiffrée avec une clé dérivée du mot de passe du compte. Aucune vérification de mot de passe n'a lieu au préalable. Vous demandez, le DC répond, et vous voilà avec une cible de cassage hors ligne pour un compte dont vous n'avez jamais possédé les identifiants.

Pourquoi ce drapeau existe

La préauthentification, c'est exactement ce qui bloque normalement ce scénario. Avec la préauth activée, le client doit prouver qu'il connaît le mot de passe (en chiffrant un horodatage) avant que le DC ne renvoie quoi que ce soit de sensible. Désactivez-la et cette étape de preuve disparaît.

On la désactive pour des raisons d'héritage. Vieux clients Kerberos Unix, certains appliances, une intégration Java mise en place en 2014 qui ne marchait plus avec la préauth. Alors quelqu'un a basculé le drapeau pour faire passer le flux de tickets, l'intégration a été démantelée trois ans plus tard, et le drapeau est resté. Aujourd'hui ce n'est plus qu'un compte roastable qui traîne dans l'annuaire.

Récupérer l'AS-REP

Sur une machine d'attaque Linux, le GetNPUsers.py d'Impacket est l'outil de référence. Si vous avez un compte de domaine valide, laissez-le énumérer les comptes vulnérables à votre place :

GetNPUsers.py -dc-ip 10.0.0.10 contoso.local/lowprivuser:Password1 -request -format hashcat -outputfile asrep.txt

Ça interroge LDAP pour trouver les comptes avec le drapeau "préauth non requise", demande une AS-REP pour chacun, et les écrit au format hashcat.

Si vous n'avez aucun identifiant mais que vous disposez d'une liste de noms d'utilisateurs (OSINT, un dump de fuite, ou une énumération antérieure), vous pouvez le lancer sans authentification :

GetNPUsers.py contoso.local/ -no-pass -usersfile users.txt -format hashcat -outputfile asrep.txt

Chaque nom du fichier dont la préauth est désactivée revient avec un hash. Les autres échouent proprement. C'est cette version qui surprend, parce qu'elle ne demande rien d'autre qu'un accès réseau au DC et un nom d'utilisateur deviné.

Depuis Windows, Rubeus fait la même chose avec Rubeus.exe asreproast, et il sait cibler un seul utilisateur ou ratisser tout ce qu'il peut voir.

Le format et comment le casser

Ce qui atterrit dans votre fichier est un hash krb5asrep. En RC4, il ressemble à ceci :

$krb5asrep$23$user@CONTOSO.LOCAL:f4c8...

Le 23 est le type de chiffrement, RC4, et c'est lui qui décide si ça vaut votre temps. Les hashs AS-REP en RC4 partent vers le mode hashcat 18200 :

hashcat -m 18200 -a 0 asrep.txt rockyou.txt -r /usr/share/hashcat/rules/best64.rule

Ça casse vite. Le débit RC4 sur un seul GPU se compte en milliards d'essais par seconde, donc tout compte avec un mot de passe du genre dictionnaire-plus-règles tombe rapidement. John the Ripper gère les mêmes hashs avec le format krb5asrep si vous préférez l'autodétection. Les arbitrages habituels entre hashcat et John s'appliquent, et si le format vous résiste, le guide pour trouver le mode hashcat couvre l'AS-REP et le reste de la famille Kerberos.

Parfois vous récupérez de l'etype 17 ou 18 à la place. C'est de l'AES, et l'économie du cassage change complètement : la dérivation lente de la clé à partir de la chaîne fait chuter votre débit de plusieurs ordres de grandeur. Un mot de passe faible tombe quand même, mais un mot de passe correct est en pratique hors de portée. La plupart des comptes sans préauth que vous croisez sur le terrain sont pourtant encore en RC4, parce que le genre de montage hérité qui exigeait la préauth désactivée précède en général aussi l'imposition de l'AES.

Sa place à côté du Kerberoasting

Les deux attaques sont cousines et on les confond. La distinction nette, c'est le prérequis d'entrée. Le Kerberoasting exige un compte de domaine valide parce qu'il faut demander des tickets de service pour les comptes munis d'un SPN. L'AS-REP roasting tourne avec zéro identifiant contre les comptes qui ont désactivé la préauth, et le blob cassable vient de l'AS-REP, pas d'un TGS.

En pratique, vous faites les deux. AS-REP roasting d'abord, parce que ça peut marcher avant même d'avoir le moindre identifiant. Kerberoasting une fois que vous en avez un. Les mots de passe cassés se recoupent souvent de toute façon, parce que le même admin qui a désactivé la préauth sur un compte de service lui a sans doute donné un mot de passe facile à retenir et enregistré un SPN dessus aussi.

Côté défenseur

Vous ne pouvez pas détecter la requête AS-REP comme vous attraperiez une connexion échouée, parce que pour le DC ça ressemble à un échange Kerberos normal. Mais il y a deux vrais leviers.

D'abord, tuez le drapeau. Sortez chaque compte avec DONT_REQ_PREAUTH activé et justifiez-en chacun. Le PowerShell tient en une ligne contre userAccountControl, et sur la plupart des domaines la réponse honnête est qu'aucun n'en a plus besoin. Réactivez la préauth et le compte cesse complètement d'être roastable.

Ensuite, surveillez l'événement 4768, la requête de ticket d'authentification Kerberos. Un 4768 avec un type de préauthentification 0 signifie qu'une AS-REP a été émise sans préauth. Une rafale de ces événements, surtout sur de nombreux comptes depuis une même source, c'est le roasting en cours. Alertez dessus. La plupart des environnements ne produisent jamais légitimement d'événements de type préauth 0, donc le taux de faux positifs est faible.

Et la même chose qui vous sauve partout ailleurs : la longueur du mot de passe. Un compte de service sans préauth avec un mot de passe aléatoire de 20 caractères survit très bien à un roasting RC4. Summer2024!, non, et il ne survivra jamais.