Durcissement de Kerberos : RC4, roasting et golden tickets

Kerberos est la colonne vertébrale de l'authentification AD, et ses formats de tickets cassables hors ligne en font une cible de choix : le Kerberoasting et l'AS-REP roasting transforment n'importe quel attaquant disposant d'un accès au domaine en casseur de mots de passe travaillant sur les propres réponses de vos DC, tandis que les golden et silver tickets permettent à un attaquant ayant déjà compromis krbtgt ou un compte de service de forger des authentifications indéfiniment. Rien de tout cela ne nécessite de vulnérabilité : ces attaques exploitent Kerberos exactement tel qu'il a été conçu lorsque les types de chiffrement et les paramètres de comptes restent à leurs valeurs héritées par défaut.

Ce guide couvre le durcissement du chiffrement, la pré-authentification et l'hygiène des SPN, la procédure de double réinitialisation du krbtgt, le blindage Kerberos et la surveillance des abus de falsification de tickets.

Imposer AES, désactiver RC4

Chaque compte (utilisateur, ordinateur et service) possède un attribut msDS-SupportedEncryptionTypes qui détermine les types de chiffrement Kerberos qu'il accepte. Les valeurs héritées par défaut autorisent souvent encore RC4-HMAC, bien plus facile à casser hors ligne qu'AES-256.

Vérifier l'état actuel à l'échelle du domaine

# Comptes autorisant encore RC4, ou sans valeur (le KDC applique alors sa valeur par défaut, qui inclut encore RC4)
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 -or -not $_."msDS-SupportedEncryptionTypes" } |
    Select-Object Name, msDS-SupportedEncryptionTypes

Valeurs des bits de type de chiffrement : 1 = DES-CBC-CRC, 2 = DES-CBC-MD5, 4 = RC4-HMAC, 8 = AES128, 16 = AES256. Une valeur de 24 signifie AES128+AES256 uniquement (ni RC4 ni DES) : c'est l'état cible.

Imposer par GPO

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos (types de chiffrement autorisés pour Kerberos)

Cochez uniquement AES128_HMAC_SHA1 et AES256_HMAC_SHA1 (et Future encryption types si proposé). Laissez DES et RC4_HMAC_MD5 décochés.

Configurer compte par compte en PowerShell

# Définir AES uniquement (valeur 24) sur un compte de service donné
Set-ADUser -Identity "svc-sqlreporting" -Replace @{"msDS-SupportedEncryptionTypes" = 24}

# Corriger en masse tous les comptes utilisateurs autorisant encore RC4
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 } |
    ForEach-Object { Set-ADUser -Identity $_ -Replace @{"msDS-SupportedEncryptionTypes" = 24} }

Vérifier

# Confirmer qu'aucun compte n'annonce encore RC4
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -band 4 }
# Ne doit rien renvoyer

# Auditer le chiffrement réellement utilisé pour les tickets via le journal Security des DC
# Événement 4768 (demande de TGT) / 4769 (demande de ticket de service) — champ « Ticket Encryption Type »
# 0x12 = AES256, 0x17 = RC4
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4769} -MaxEvents 200 |
    ForEach-Object { [xml]$_.ToXml() } |
    ForEach-Object { $_.Event.EventData.Data | Where-Object Name -eq 'TicketEncryptionType' } |
    Group-Object '#text'

Toute entrée 0x17 (RC4) après la mise en application indique un client ou un service qui négocie encore à la baisse : enquêtez avant de considérer RC4 comme totalement éliminé.

Pré-authentification et AS-REP roasting

La pré-authentification Kerberos exige qu'un client chiffre un horodatage avec la clé dérivée de son mot de passe avant que le KDC ne délivre un TGT — une preuve de connaissance du mot de passe avant toute remise de matériel de ticket. L'indicateur de compte DONT_REQ_PREAUTH la désactive : n'importe qui peut alors demander un AS-REP pour ce compte sans aucun identifiant, puis casser hors ligne le ticket renvoyé pour retrouver le mot de passe. Voir AS-REP roasting pour le principe de l'attaque.

# Trouver les comptes dont la pré-authentification est désactivée
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol |
    Select-Object Name, SamAccountName

# Corriger : effacer l'indicateur DONT_REQ_PREAUTH
Set-ADAccountControl -Identity "jsmith" -DoesNotRequirePreAuth $false

Il existe rarement une raison légitime à cet indicateur, hormis certains cas précis d'interopérabilité héritée : traitez chaque occurrence comme une non-conformité.

Le risque de Kerberoasting lié aux SPN sur les comptes utilisateurs

Le Kerberoasting ne nécessite aucun indicateur de mauvaise configuration : tout utilisateur authentifié peut demander un ticket de service pour n'importe quel compte doté d'un Service Principal Name (SPN), puis tenter de casser ce ticket hors ligne. Le risque se concentre sur les comptes utilisateurs employés comme comptes de service, car leurs mots de passe sont généralement choisis par des humains (plus faibles, réutilisés), contrairement aux comptes d'ordinateurs, dont les mots de passe longs et aléatoires sont renouvelés automatiquement. Voir Kerberoasting.

# Trouver les comptes utilisateurs (et non ordinateurs) dotés d'un SPN
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties ServicePrincipalName, PasswordLastSet |
    Select-Object Name, ServicePrincipalName, PasswordLastSet

Contre-mesures, par ordre d'efficacité :

1. Migrer les comptes de service vers des Group Managed Service Accounts (gMSA) : mots de passe aléatoires de 240 octets (120 caractères) renouvelés automatiquement, hors de portée d'un cassage hors ligne réaliste.
2. Là où les gMSA ne sont pas pris en charge, utiliser des mots de passe longs (25 caractères ou plus), générés aléatoirement et stockés dans un coffre-fort de mots de passe, jamais mémorisés par un humain.
3. S'assurer que msDS-SupportedEncryptionTypes est en AES uniquement pour chaque compte porteur de SPN : les tickets AES-256 sont considérablement plus coûteux à casser que les tickets RC4.
4. Ajouter les comptes à SPN de forte valeur à Protected Users lorsque c'est compatible (voir Tier 0 et accès à privilèges).

La procédure de double réinitialisation du krbtgt

Le mot de passe du compte krbtgt sert à dériver la clé qui signe chaque TGT Kerberos du domaine. S'il est compromis — directement ou par une extraction de type DCSync —, un attaquant peut forger des TGT (golden tickets) pour n'importe quel utilisateur, y compris des utilisateurs inexistants dans AD, valides jusqu'au renouvellement de la clé. Voir DCSync.

Pourquoi deux réinitialisations espacées : AD considère comme valides à la fois le hachage actuel et le hachage précédent du mot de passe krbtgt ; une seule réinitialisation n'invalide donc pas immédiatement les tickets forgés avec l'ancien hachage — le DC les accepte encore via le repli sur le « mot de passe précédent ». Il faut réinitialiser deux fois, avec un intervalle d'au moins la durée de vie maximale d'un ticket Kerberos (MaxTicketAge = 10 heures par défaut ; vérifiez la stratégie MaxTicketAge/MaxRenewAge réelle de votre domaine, qui peut être étendue à plusieurs jours), afin que le premier nouveau mot de passe sorte complètement des deux emplacements avant l'application de la seconde réinitialisation.

# Vérifier d'abord la stratégie de durée de vie des tickets — elle détermine l'intervalle entre les réinitialisations
# La stratégie Kerberos n'est pas un attribut AD ; elle se trouve dans la GPO Default Domain Policy :
# Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Kerberos Policy
[xml]$r = Get-GPOReport -Name "Default Domain Policy" -ReportType Xml
$r.GPO.Computer.ExtensionData.Extension.Account | Where-Object Type -eq 'Kerberos' | Select-Object Name, SettingNumber

# Réinitialisation 1
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<generate-random>" -Force)

# --- attendre au moins MaxTicketAge (souvent 10 heures ; confirmez la valeur de votre domaine) ---

# Réinitialisation 2
Set-ADAccountPassword -Identity "krbtgt" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "<generate-random-2>" -Force)

Dans les environnements à plusieurs DC, utilisez le script New-KrbtgtKeys.ps1 publié par Microsoft (ou un outil équivalent éprouvé) plutôt que des réinitialisations improvisées : il vérifie la convergence de la réplication entre les deux réinitialisations, afin de ne pas procéder au renouvellement avant que tous les DC aient reçu la première modification. Dans une forêt multidomaine, répétez l'opération pour le compte krbtgt de chaque domaine, pas seulement pour la racine de la forêt.

Effectuez ce renouvellement selon un calendrier régulier (de nombreuses organisations le font chaque trimestre ou après toute suspicion de compromission d'identifiants), et pas uniquement en réponse à incident.

Blindage Kerberos / FAST

FAST (Flexible Authentication Secure Tunneling), activé via le Kerberos Armoring, encapsule l'échange AS-REQ initial dans un canal chiffré et authentifié à l'aide des propres identifiants de l'ordinateur demandeur, ce qui protège les données de pré-authentification et réduit l'exposition aux attaques hors ligne contre les mots de passe utilisateurs faibles.

Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring (nommé Support Dynamic Access Control and Kerberos armoring sous Windows Server 2012) : réglez-le d'abord sur Supported sur les DC, puis sur Fail unarmored authentication requests uniquement lorsque tous les DC et clients le prennent en charge. Sur les clients : Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring.

Nécessite un niveau fonctionnel du domaine 2012 ou supérieur et la mise à jour de tous les DC avant la mise en application.

Golden et silver tickets : comment ces mesures se combinent

Un golden ticket forge un TGT à l'aide d'un hachage krbtgt volé ; un silver ticket forge un ticket de service à l'aide du hachage volé d'un compte de service, sans jamais solliciter le KDC. Ni l'un ni l'autre n'est une vulnérabilité à « corriger » : il s'agit d'un abus de la confiance légitime de Kerberos une fois une clé dérobée. La défense est étagée :

• AES uniquement + Protected Users sur les comptes Tier 0 et de service rend les hachages eux-mêmes plus difficiles à obtenir et à casser s'ils sont exfiltrés.
• Le renouvellement du krbtgt (ci-dessus) invalide tous les golden tickets forgés auparavant et limite la valeur future d'un hachage volé.
• La surveillance des anomalies : TGT à durée de vie inhabituellement longue, tickets pour des comptes inexistants, ou schémas d'événements 4624/4768 incohérents avec les sources d'ouverture de session habituelles.

# Un golden ticket forgé ne produit jamais de 4768 ; les 4769 d'un compte sans 4768 correspondant
# sur aucun DC sont donc l'anomalie à rechercher. Exécutez ceci sur chaque DC (ou interrogez votre SIEM)
# sur une fenêtre plus longue que la durée de vie du TGT (10 h par défaut) : un seul DC donne des faux positifs.
$since  = (Get-Date).AddHours(-12)
$events = Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769; StartTime=$since} |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        [pscustomobject]@{
            Id      = $_.Id
            # 4769 journalise user@REALM, 4768 le nom seul : normaliser avant de comparer
            Account = (($x.Event.EventData.Data | Where-Object Name -eq 'TargetUserName').'#text' -split '@')[0]
        }
    }
$withTgt = $events | Where-Object Id -eq 4768 | Select-Object -ExpandProperty Account -Unique
$events | Where-Object { $_.Id -eq 4769 -and $_.Account -notin $withTgt } |
    Group-Object Account | Sort-Object Count -Descending | Select-Object Name, Count

Ce que cela casse

• Les applications et équipements réseau hérités (anciens NAS, certains logiciels de sauvegarde, anciens clients Kerberos Linux/Java, certains systèmes SCADA/industriels) qui ne prennent en charge que RC4 échoueront à s'authentifier une fois RC4 désactivé à l'échelle du domaine. Auditez le champ TicketEncryptionType de l'événement 4769 pendant 90 jours avant la mise en application pour les repérer.
• Les partages de fichiers tiers ou basés sur d'anciennes versions de Samba peuvent ne pas prendre en charge AES256 nativement : vérifiez avant la bascule.
• La double réinitialisation du krbtgt, correctement espacée, a peu d'impact visible, car le DC accepte encore les TGT signés avec la clé précédente. Réinitialiser deux fois coup sur coup (le cas de la réponse à incident), ou effectuer la seconde réinitialisation avant que la première ne soit répliquée, invalide tous les TGT en circulation dans ce domaine et oblige utilisateurs et services à se réauthentifier : planifiez une fenêtre à faible impact et attendez-vous à une vague de reconnexions.
• L'application du blindage Kerberos exige que chaque DC et chaque OS client prenne en charge FAST ; dans des environnements mixtes comportant des DC hérités, l'authentification cassera si l'on active prématurément « Fail unarmored authentication requests ».

Pour aller plus loin : Tier 0 et accès à privilèges pour les protections au niveau des comptes, Délégation pour la combinaison des tickets forgés avec les abus de délégation, et NTLM et protocoles hérités pour la couche d'authentification que Kerberos est censé remplacer.