Se défendre contre le Kerberoasting et l'AS-REP roasting

Le Kerberoasting ne nécessite rien d'autre qu'un compte de domaine. L'attaquant liste les comptes dotés d'un Service Principal Name, demande un ticket de service pour chacun et casse les tickets hors ligne avec des outils comme Hashcat. Le DC journalise un événement 4769 banal, et rien d'autre ne se passe jusqu'à ce que le mot de passe d'un compte de service tombe. L'AS-REP roasting applique la même idée aux comptes qui n'exigent pas la pré-authentification Kerberos, et ne nécessite même pas de compte de domaine. Les deux attaques ciblent des mots de passe choisis par des humains, sur des comptes qui détiennent souvent bien plus de privilèges que leurs propriétaires ne l'imaginent.

Le guide Durcissement de Kerberos a présenté ces deux attaques. Celui-ci en est le plan opérationnel : mesurer votre surface exposée, supprimer ce dont vous n'avez pas besoin, rendre le reste incassable et détecter les tentatives que vous ne pouvez pas empêcher.

Mesurer : votre surface exposée au roasting

Les comptes d'ordinateurs ont eux aussi des SPN, mais leurs mots de passe sont aléatoires et renouvelés tous les 30 jours : ce ne sont pas des cibles réalistes. Le risque porte sur les comptes utilisateurs dotés de SPN. Excluez krbtgt, qui porte le SPN kadmin/changepw mais ne peut pas être « roasté » via une demande de ticket de service normale.

Get-ADUser -Filter 'ServicePrincipalName -like "*"' `
    -Properties ServicePrincipalName, PasswordLastSet, LastLogonDate, AdminCount,
                msDS-SupportedEncryptionTypes, MemberOf, Enabled |
    Where-Object { $_.SamAccountName -ne 'krbtgt' } |
    Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, AdminCount,
        @{n='EncTypes';e={$_.'msDS-SupportedEncryptionTypes'}},
        @{n='SPNs';e={$_.ServicePrincipalName -join '; '}} |
    Sort-Object PasswordLastSet

Classez les résultats selon trois questions :

1. Le compte est-il privilégié ? AdminCount = 1 ou l'appartenance à un groupe Tier 0 signifie qu'un mot de passe cassé équivaut à une compromission du domaine. Ces comptes passent en premier. Traitez-les comme du Tier 0 jusqu'à preuve du contraire.
2. Quel âge a le mot de passe ? Un PasswordLastSet datant de plusieurs années signifie presque toujours un mot de passe court choisi par un humain, et peut-être l'absence de clés AES.
3. Le compte autorise-t-il RC4 ? Un msDS-SupportedEncryptionTypes vide ou incluant RC4 signifie que le KDC peut émettre des tickets RC4 pour lui.

Pour l'AS-REP roasting, l'exposition correspond à l'indicateur DONT_REQ_PREAUTH (bit 0x400000 de userAccountControl) :

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' -Properties DoesNotRequirePreAuth, PasswordLastSet |
    Select-Object SamAccountName, Enabled, PasswordLastSet

N'oubliez pas qui peut créer une nouvelle exposition. Tout principal disposant d'un accès en écriture à servicePrincipalName sur un utilisateur peut ajouter un SPN et le « roaster » (le Kerberoasting ciblé), et quiconque peut modifier userAccountControl peut désactiver la pré-authentification. C'est un problème d'ACL ; auditez-le avec ACL et sécurité des objets.

Pourquoi le type de chiffrement compte

Un ticket de service RC4 est chiffré avec une clé qui n'est autre que le hachage NT du compte : chaque tentative de mot de passe coûte un calcul MD4. Un ticket AES utilise une clé dérivée avec PBKDF2 (4 096 itérations de HMAC-SHA1), salée avec le royaume et le nom du compte, ce qui rend chaque tentative des milliers de fois plus coûteuse sur le même matériel. Cet écart fait passer un mot de passe de huit caractères de « cassé pendant la pause déjeuner » à « ne vaut pas l'électricité », mais il ne sauve pas un mot de passe qui figure dans un dictionnaire. Considérez AES comme un multiplicateur de la robustesse du mot de passe, pas comme un substitut, et rappelez-vous que de nombreux outils de roasting demanderont RC4 tant que le compte l'autorise encore.

Auditer : décider compte par compte

Pour chaque compte utilisateur porteur de SPN, choisissez une issue :

Consultez LastLogonDate et les événements 4769 pour confirmer qu'un SPN est effectivement demandé avant de le supprimer :

# Supprimer un SPN obsolète d'un compte
Set-ADUser -Identity 'svc-oldreport' -ServicePrincipalNames @{ Remove = 'HTTP/oldreport.corp.example.com' }

# Trouver les SPN dupliqués dans le domaine (les doublons cassent aussi Kerberos)
setspn -X

Imposer : rendre les tickets restants incassables

Migrer vers les gMSA

Un gMSA possède un mot de passe aléatoire de 120 caractères géré par le domaine et renouvelé automatiquement. Ses tickets peuvent toujours être demandés, mais les casser n'est pas réaliste. SQL Server, les pools d'applications IIS, les tâches planifiées et la plupart des services Windows prennent en charge les gMSA. Les détails par application figurent dans migrer les comptes de service vers des gMSA.

# Après la migration : l'ancien compte ne doit plus porter aucun SPN
Get-ADUser 'svc-sql01' -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName
Get-ADServiceAccount 'gmsa-sql01' -Properties ServicePrincipalName | Select-Object -ExpandProperty ServicePrincipalName

Mots de passe longs et AES uniquement pour le reste

Pour les comptes qui doivent rester des comptes utilisateurs :

• Générez un mot de passe aléatoire d'au moins 25 caractères avec votre outil PAM ou votre gestionnaire de mots de passe, et renouvelez-le selon un calendrier que l'application peut supporter.
• Imposez cette longueur par une stratégie de mot de passe affinée (FGPP) appliquée à un groupe ServiceAccounts, afin que les réinitialisations manuelles ne puissent pas descendre en dessous.
• Réglez msDS-SupportedEncryptionTypes sur 24 (AES128 + AES256), puis réinitialisez le mot de passe s'il est antérieur à la prise en charge d'AES, pour que les clés AES existent.

New-ADFineGrainedPasswordPolicy -Name 'PSO-ServiceAccounts' -Precedence 10 `
    -MinPasswordLength 25 -ComplexityEnabled $true -PasswordHistoryCount 24 `
    -MaxPasswordAge '365.00:00:00' -LockoutThreshold 0
Add-ADFineGrainedPasswordPolicySubject -Identity 'PSO-ServiceAccounts' -Subjects 'ServiceAccounts'

Set-ADUser 'svc-app01' -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }

AES seul ne sauve pas un mot de passe faible ; il rend seulement chaque tentative plus coûteuse. Ce sont la longueur et le caractère aléatoire qui font le vrai travail. Le retrait de RC4 à l'échelle du domaine est traité dans désactiver RC4 dans Kerberos.

Traiter d'abord les comptes de service privilégiés

La pire découverte de presque tous les audits est un compte de service doté d'un SPN qui est aussi Domain Admin, souvent parce qu'un installateur l'a demandé il y a dix ans. Casser ce seul mot de passe met fin à l'exercice. Avant toute autre remédiation, retirez ces comptes des groupes privilégiés et n'accordez que les droits réellement utilisés par l'application, c'est-à-dire généralement l'administration locale de quelques serveurs ou une autorisation déléguée sur une UO.

Cela demande de négocier avec les responsables d'applications : rassemblez donc d'abord des éléments factuels — sur quels serveurs le compte ouvre une session (événements 4624 sur ces serveurs, ou LastLogonDate plus les noms d'hôtes des SPN), quelles tâches planifiées et quels services l'utilisent, et quelles autorisations AD il exerce. Là où l'application ne peut pas fonctionner sans droits au niveau du domaine, le compte et chaque serveur sur lequel il s'exécute relèvent du Tier 0 et doivent être gérés comme tels. Les deux issues valent mieux qu'un Domain Admin exposé au roasting.

Corriger les comptes exposés à l'AS-REP roasting

Effacez l'indicateur, puis réinitialisez le mot de passe de chaque compte qui le portait, car son AS-REP a peut-être déjà été collecté :

Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' |
    ForEach-Object { Set-ADAccountControl -Identity $_ -DoesNotRequirePreAuth $false }

Si une application héritée l'exige réellement, documentez l'exception, attribuez au compte un mot de passe aléatoire de 25 caractères ou plus, et surveillez-le.

Détecter ce qui subsiste

Stratégie d'audit

Sur les DC : Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon > Audit Kerberos Service Ticket Operations et Audit Kerberos Authentication Service, en succès et en échec. Transférez les 4768 et 4769 vers votre SIEM ou un collecteur central.

Logique de détection

• Tickets de service RC4 pour des comptes utilisateurs : 4769 avec TicketEncryptionType 0x17 lorsque le service est un compte utilisateur, dans un environnement où AES est par ailleurs la norme. De nombreux outils de roasting demandent explicitement RC4.
• Volume : un compte qui demande des tickets de service pour de nombreux SPN distincts dans un court laps de temps (par exemple plus de 10 en 5 minutes).
• AS-REP roasting : 4768 avec PreAuthType 0.

# Clients ayant demandé des tickets RC4 pour plus de 10 services distincts au cours de la dernière heure
$since = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4769; StartTime=$since } |
    ForEach-Object {
        $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        if ($d.TicketEncryptionType -eq '0x17' -and $d.ServiceName -notlike '*$') {
            [pscustomobject]@{ Client = $d.TargetUserName; Service = $d.ServiceName }
        }
    } | Group-Object Client | Where-Object { ($_.Group.Service | Sort-Object -Unique).Count -gt 10 }

Réglage fin

Attendez-vous à du bruit le premier jour. Les scanners de vulnérabilités, les outils de gouvernance des identités et certains produits de supervision énumèrent les SPN et demandent des tickets en masse, et d'anciens clients négocient légitimement RC4 avec les comptes qui l'autorisent encore. Constituez une liste d'autorisation des adresses sources des scanners et des identités de service connues, et révisez-la chaque trimestre. Le signal RC4 devient beaucoup plus net une fois les comptes de service passés en AES uniquement : dès lors, tout ticket RC4 pour un compte de service de type utilisateur provient soit d'un client hérité non corrigé, soit d'un outil de roasting qui demande délibérément le chiffrement le plus faible.

Honey SPN

Créez un honeytoken : un compte utilisateur au nom et au SPN réalistes, doté d'un long mot de passe aléatoire, sans activité d'ouverture de session et sans véritable service derrière. Tout 4769 le concernant déclenche une alerte. Les détails de conception figurent dans honeytokens et leurres.

New-ADUser -Name 'svc-sqlbackup-legacy' -SamAccountName 'svc-sqlbackup-legacy' `
    -Path 'OU=ServiceAccounts,DC=corp,DC=example,DC=com' -Enabled $true `
    -AccountPassword (Read-Host -AsSecureString 'Random 30+ char password') `
    -ServicePrincipalNames 'MSSQLSvc/sqlbackup01.corp.example.com:1433'

Vérifier

• La requête d'inventaire des SPN ne renvoie que des gMSA, des comptes d'ordinateurs et une liste courte et documentée de comptes utilisateurs, chacun avec un mot de passe plus récent que votre intervalle de renouvellement et msDS-SupportedEncryptionTypes réglé sur 24.
• La requête DoesNotRequirePreAuth ne renvoie rien, ou uniquement des exceptions documentées.
• Aucun compte utilisateur doté d'un SPN n'est membre d'un groupe privilégié.
• Une demande de ticket de test pour le honey SPN (klist get MSSQLSvc/sqlbackup01.corp.example.com:1433 depuis un poste d'administration, annoncée au SOC) déclenche une alerte.

Ce que cela casse

• Supprimer des SPN encore utilisés casse Kerberos vers ce service ; les clients se replient sur NTLM là où c'est autorisé, ou échouent. Consultez l'historique des 4769 avant toute suppression.
• Réinitialiser le mot de passe de comptes de service hérités casse tous les endroits où l'ancien mot de passe est codé en dur : services, tâches planifiées, fichiers de configuration d'applications, scripts sur d'autres serveurs.
• AES uniquement sur les comptes de service casse les clients et keytabs qui ne gèrent que RC4, notamment les anciennes intégrations Java et Linux.
• La migration vers les gMSA ne fonctionne pas pour les applications qui ont besoin du mot de passe en clair, ni pour les services hébergés hors du domaine.
• Effacer DONT_REQ_PREAUTH peut casser les rares intégrations Unix ou d'équipements hérités qui en dépendaient.

Pour aller plus loin : le domaine Kerberos et authentification, et le durcissement des comptes de service avec gMSA et LAPS pour le programme global des comptes de service.