Kerberos FAST: lire un AS-REQ protégé par armoring

Un attaquant qui écoute le réseau entre un poste et un contrôleur de domaine peut-il casser hors ligne le mot de passe d’un utilisateur à partir de sa demande de TGT? Sans protection, oui: l’AS-REQ et l’AS-REP portent tous deux des données chiffrées avec une clé dérivée du mot de passe. Kerberos FAST (Flexible Authentication Secure Tunneling, RFC 6113), que Microsoft appelle « Kerberos armoring », place ce dialogue dans un tunnel chiffré par une clé qui ne dépend plus du mot de passe de l’utilisateur.

Dans cet article nous allons voir comment ce tunnel est construit, ce qui change dans un AS-REQ une fois FAST activé, et jusqu’où va réellement la protection.

Pourquoi blinder la pré-authentification?

Comme nous l’avions vu dans l’article Kerberos: lire un ticket de service avec klist et Wireshark, la première étape d’une ouverture de session est un échange KRB_AS_REQ / KRB_AS_REP avec le KDC. En pré-authentification classique, le client chiffre un horodatage (PA-ENC-TIMESTAMP, type 2) avec sa clé longue durée, calculée depuis son mot de passe. Le KDC déchiffre, vérifie que l’horodatage est récent et répond avec un AS-REP dont la partie enc-part est elle aussi chiffrée avec la clé de l’utilisateur.

Ces deux blocs ont la même faiblesse: ils sont chiffrés avec une clé dérivée d’un mot de passe choisi par un humain, et le contenu clair est en partie prévisible (un horodatage, une structure ASN.1 connue). Celui qui les capture peut donc tester des mots de passe hors ligne, sans aucune interaction avec le contrôleur de domaine, et donc sans laisser la moindre trace d’échec d’authentification. Nous sommes dans la technique MITRE ATT&CK T1110.002 (Password Cracking), alimentée par une écoute réseau (T1040) ou par une position d’homme du milieu (T1557). L’empoisonnement LLMNR / NBT-NS décrit dans cet ancien article est un moyen classique d’obtenir cette position.

Le cas extrême est celui des comptes pour lesquels la pré-authentification est désactivée (drapeau DONT_REQ_PREAUTH dans userAccountControl): n’importe qui peut alors demander un AS-REP pour ce compte et casser la partie chiffrée tranquillement. C’est l’AS-REP roasting, technique T1558.004.

FAST répond au premier problème en ajoutant une clé forte et aléatoire dans le calcul. Nous verrons plus loin que la réponse au second est plus nuancée.

Description détaillée du fonctionnement

Le principe de FAST tient en une idée: pour protéger la pré-authentification d’un utilisateur, nous utilisons un ticket déjà obtenu par ailleurs, le TGT d’armure. Sous Windows, c’est le TGT du compte machine. Le mot de passe d’un compte machine est long et aléatoire, ce qui rend son propre échange AS (forcément non blindé, puisqu’aucun TGT n’existe encore pour le protéger) peu intéressant à casser.

L’échange se déroule ainsi:

1. Au démarrage, le poste obtient le TGT de son compte machine (win11$) par un échange AS ordinaire.
2. Quand l’utilisateur ouvre sa session, le client construit un AP-REQ contenant ce TGT machine et un authentificateur porteur d’une sous-clé aléatoire. La clé d’armure est calculée par la fonction KRB-FX-CF2 à partir de cette sous-clé et de la clé de session du TGT machine. Ni l’une ni l’autre ne dérive du mot de passe de l’utilisateur.
3. Le client envoie un AS-REQ dont le padata contient un seul élément intéressant, PA-FX-FAST (type 136). Il porte une structure KrbFastArmoredReq: le champ armor (l’AP-REQ de l’étape précédente, armor-type 1, FX_FAST_ARMOR_AP_REQUEST), un req-checksum qui lie le tunnel au corps de la requête, et enc-fast-req, chiffré avec la clé d’armure. Ce dernier contient la vraie requête: les options FAST, le req-body intérieur et la pré-authentification.
4. Dans le tunnel, l’horodatage classique est remplacé par PA-ENCRYPTED-CHALLENGE (type 138). Le client y chiffre son horodatage avec une clé qui combine, toujours via KRB-FX-CF2, la clé d’armure et sa clé longue durée. Pour tester un mot de passe, il faudrait donc aussi connaître la clé d’armure.
5. Le KDC déchiffre le TGT machine avec la clé du compte krbtgt, retrouve la clé de session, recalcule la clé d’armure et traite la requête intérieure. Sa réponse revient elle aussi dans un PA-FX-FAST, et les erreurs passent dans un PA-FX-ERROR (137) protégé au lieu d’un KRB-ERROR en clair.

La RFC prévoit en plus un champ strengthen-key dans la réponse FAST: le KDC peut fournir une clé aléatoire qui est combinée à la clé de réponse, ce qui protège aussi l’enc-part de l’AS-REP contre une attaque hors ligne. Attention, la présence de ce champ ne se voit pas sans déchiffrer le tunnel, et je préfère ne pas affirmer ce que fait le KDC Windows sans l’avoir lu dans [MS-KILE].

FAST ne cherche pas à cacher l’identité: le req-body extérieur continue de porter le nom du compte et le SPN krbtgt/TEST.LOCAL, ce qui laisse lisible qui s’authentifie et auprès de quel domaine.

Activer FAST et le voir dans Wireshark

Notre maquette reste minimale:

Nom du domaine: test.local (TESTLOCAL), niveau fonctionnel 2016

Contrôleur de domaine: dc01.test.local (Windows Server 2022)

Client: win11.test.local (Windows 11), utilisateur alice@test.local

FAST se pilote par deux paramètres de stratégie de groupe, apparus avec Windows Server 2012 et Windows 8 en même temps que les revendications (claims) et l’authentification composée:

Côté KDC (GPO liée à l'OU Domain Controllers):
Configuration ordinateur \ Stratégies \ Modèles d'administration \ Système \ KDC
  « Prise en charge du contrôleur de domaine Kerberos pour les revendications,
    l'authentification composée et le blindage Kerberos »
  (KDC support for claims, compound authentication and Kerberos armoring)
  Options: Non pris en charge | Pris en charge | Toujours fournir des revendications
           | Échec des demandes d'authentification non blindées

Côté client (GPO liée aux postes):
Configuration ordinateur \ Stratégies \ Modèles d'administration \ Système \ Kerberos
  « Prise en charge des revendications, de l'authentification composée
    et du blindage Kerberos par le client Kerberos »
  (Kerberos client support for claims, compound authentication and Kerberos armoring)

Nous commençons par une capture de référence, les deux paramètres non configurés. Lançons Wireshark sur le poste avec le filtre « kerberos », puis ouvrons une session alice. L’AS-REQ qui suit l’erreur KDC_ERR_PREAUTH_REQUIRED a la forme bien connue:

Kerberos
    as-req
        pvno: 5
        msg-type: krb-as-req (10)
        padata: 2 items
            PA-DATA pA-ENC-TIMESTAMP
                padata-type: pA-ENC-TIMESTAMP (2)
                    padata-value
                        etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                        cipher: 6f1c0e…
            PA-DATA pA-PAC-REQUEST
        req-body
            cname: alice
            realm: TEST.LOCAL
            sname: krbtgt/TEST.LOCAL

-> Le champ cipher est l’horodatage chiffré avec la clé d’alice: c’est le bloc qu’un attaquant en écoute récupérerait.

Nous activons ensuite le paramètre KDC sur « Pris en charge » et le paramètre client sur « Activé », puis lançons un gpupdate /force sur dc01 et un redémarrage de win11, pour que le compte machine obtienne un nouveau TGT. Sur la maquette, la même ouverture de session donne cette fois:

Kerberos
    as-req
        msg-type: krb-as-req (10)
        padata: 1 item
            PA-DATA pA-FX-FAST
                padata-type: pA-FX-FAST (136)
                    padata-value: armored-data
                        armor
                            armor-type: 1
                            armor-value
                                ap-req
                                    ticket
                                        realm: TEST.LOCAL
                                        sname: krbtgt/TEST.LOCAL
                                        enc-part: etype 18, kvno 2, cipher …
                        req-checksum
                            cksumtype: cKSUMTYPE-HMAC-SHA1-96-AES256 (16)
                        enc-fast-req
                            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
                            cipher: a40b97…
        req-body
            cname: alice
            realm: TEST.LOCAL
            sname: krbtgt/TEST.LOCAL

-> pA-ENC-TIMESTAMP a disparu, il n’y a plus d’élément chiffré avec la seule clé d’alice dans la trame.

-> L’armor-value transporte le TGT de win11$, que l’on retrouve sur le poste dans le cache de la session SYSTEM.

Pour isoler ces trames dans une capture plus large, le filtre « kerberos.padata_type == 136 » suffit. Pour vérifier depuis le poste que le TGT de l’utilisateur a bien été obtenu par un échange blindé, klist affiche un drapeau de cache dédié:

C:\> klist -li 0x3e7
#0>  Client: win11$ @ TEST.LOCAL
     Server: krbtgt/TEST.LOCAL @ TEST.LOCAL
     ...

C:\> klist
#0>  Client: alice @ TEST.LOCAL
     Server: krbtgt/TEST.LOCAL @ TEST.LOCAL
     KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
     Cache Flags: 0x41 -> PRIMARY FAST
     Kdc Called: dc01.test.local

Côté contrôleur de domaine, l’événement 4768 (demande de TGT) du journal Sécurité indique le type de pré-authentification utilisé. La valeur 2 correspond à l’horodatage classique, 138 au challenge chiffré de FAST, 0 à une demande sans pré-authentification:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768} -MaxEvents 200 |
  ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
      Heure   = $_.TimeCreated
      Compte  = $d.TargetUserName
      Client  = $d.IpAddress
      PreAuth = $d.PreAuthType
    }
  } | Group-Object PreAuth, Client | Sort-Object Count -Descending

Cette requête est la base de l’inventaire avant d’aller plus loin: tous les clients qui remontent encore en type 2 sont ceux qui ne blindent pas.

Pour aller jusqu’au contenu de enc-fast-req, il faut reconstituer la clé d’armure, donc déchiffrer le TGT machine avec la clé du compte krbtgt. Attention: c’est une manipulation de maquette, un keytab contenant la clé krbtgt d’un domaine de production est l’équivalent d’un accès complet au domaine.

Ce que FAST change pour un attaquant

Reprenons le scénario de départ. Un attaquant obtient une position d’écoute, par empoisonnement LLMNR, par un équipement réseau compromis ou sur un segment Wi-Fi mal isolé, et capture les ouvertures de session du matin. Sans FAST, chaque AS-REQ est un candidat au cassage hors ligne, et un mot de passe faible tombe sans qu’aucun 4771 n’apparaisse sur un contrôleur de domaine. Le secret obtenu est le mot de passe lui-même, réutilisable en Kerberos comme en NTLM, sur le VPN, dans Entra ID si les hashs sont synchronisés, jusqu’à son prochain changement. Avec FAST, la même capture ne contient plus que des blocs chiffrés avec une clé d’armure aléatoire: l’écoute passive ne suffit plus.

La protection s’arrête là, et il faut connaître ses bords.

En mode « Pris en charge », le KDC accepte toujours les requêtes non blindées. Un outil offensif qui forge lui-même son AS-REQ ne blinde rien, et le KDC lui répond comme avant. Pour l’AS-REP roasting, cela veut dire que rien ne change: un compte avec DONT_REQ_PREAUTH reste exposé. Seul le mode « Échec des demandes d’authentification non blindées » oblige à présenter une armure, et il demande un niveau fonctionnel de domaine 2012 au minimum.

Même en mode strict, la barrière tient à la possession d’un TGT. Un attaquant qui a déjà compromis un poste du domaine, ou qui connaît le mot de passe de n’importe quel compte, peut obtenir un ticket et blinder ses propres requêtes. FAST élève le niveau requis (passer d’un accès au réseau à une identité dans le domaine), il ne remplace pas le ménage. La vraie parade contre l’AS-REP roasting reste de supprimer DONT_REQ_PREAUTH partout où c’est possible, ce que l’on peut suivre en continu:

Get-ADUser -LDAPFilter '(userAccountControl:1.2.840.113556.1.4.803:=4194304)' `
  -Properties userAccountControl, pwdLastSet |
  Select-Object SamAccountName, Enabled, pwdLastSet

Dans le journal, ces comptes se trahissent aussi par des 4768 avec un type de pré-authentification à 0, à surveiller de près quand ils viennent d’une adresse inhabituelle.

FAST ne protège que l’échange AS. Le Kerberoasting (T1558.003) cible le TGS-REP, chiffré avec la clé du compte de service, et n’est pas concerné: la parade reste des mots de passe longs ou des comptes gMSA et AES uniquement. NTLM ne l’est pas davantage, et un poste qui retombe en NTLM continue d’exposer ses réponses challenge/réponse, comme nous l’avions vu dans Pourquoi Kerberos retombe en NTLM.

Reste la compatibilité, qui décide en pratique du mode retenu. En mode strict, tout ce qui ne sait pas présenter un TGT d’armure échoue: postes antérieurs à Windows 8, machines non jointes au domaine (elles n’ont pas de TGT machine), clients Linux MIT ou Heimdal non configurés pour l’armure, appliances, scanners et vieux serveurs applicatifs qui font leur propre kinit. L’erreur arrive à l’ouverture de session et ressemble à un mauvais mot de passe pour l’utilisateur, ce qui rend le diagnostic pénible. L’ordre que je recommande: client activé partout, KDC en « Pris en charge », quelques semaines d’inventaire avec l’événement 4768, correction ou isolement des clients en type 2, puis seulement le mode strict.

Quand le mode strict est impossible à l’échelle du domaine, les stratégies d’authentification (authentication policies et silos, niveau fonctionnel 2012 R2) permettent d’exiger l’armure pour une population ciblée, comptes d’administration en tête, puisqu’elles reposent sur le même blindage pour appliquer leurs conditions. Pour ces comptes, l’association avec le groupe Protected Users et une ouverture de session restreinte aux postes d’administration donne un résultat bien plus solide que FAST seul.

Rémi Vernier

Responsable des opérations cybersécurité dans un grand groupe international. Identité, Active Directory, Entra ID, cloud hybride, et désormais SAP, IA et modèles en local.

Tous les articles → LinkedIn →