Pré-authentification Kerberos : de la découverte à l’exploitation offensive

Implémenté par Microsoft dans sa version 5 depuis Windows 2000, le protocole Kerberos devait idéalement remplacer les protocoles d’authentification réseau historiques basés sur Lan Manager souffrant de faiblesses de sécurité bien connues. L’authentification mutuelle est en effet un apport significatif par rapport aux protocoles Net-NTLM. La version 2 de Net-NTLM est cependant encore aujourd’hui activée par défaut sur les systèmes Microsoft pour des raisons de rétrocompatibilité. On ne cessera donc pas de rappeler que la signature des paquets SMB et du trafic LDAP doit être généralisée pour réduire le risque d’usurpation de droits par attaque NTLM Relaying et que les versions antérieures de ce protocole sont à bannir, car aisément cassables par cryptanalyse.

Le protocole Kerberos est lui aussi de plus en plus exploité à des fins offensives, comme détaillé dans l’article « Attaques sur le protocole Kerberos en environnement Active Directory » publié dans le hors-série n°20 du magazine MISC. On peut citer parmi les attaques spécifiques à ce protocole :

• Le Kerberoasting, consistant à collecter des tickets de service et à casser ceux-ci par attaque hors ligne afin d’obtenir les mots de passe des comptes de service utilisés pour chiffrer ces tickets ;
• L’abus de délégations d’authentification, pouvant conduire à une escalade de privilèges (attaque S4U via une resource-based constrained delegation) voire à une compromission des domaines Active Directory (exploitation du « Printer bug » via une unconstrained delegation) ;
• Le rejeu de tickets (pass-the-ticket) extraits depuis le processus LSASS d’une machine compromise, permettant d'obtenir des tickets d’accès à des services ;
• La génération de tickets (silver ticket et golden ticket) à partir de secrets compromis (comptes de service ou compte krbtgt), afin d’escalader les privilèges ou maintenir une persistance.

L’outil PowerShell PowerSpray [1] est utilisé dans cet article pour illustrer d’autres attaques exploitant le mécanisme de pré-authentification de Kerberos décrit dans la RFC 4120.

1. Rappel sur l’authentification Kerberos

En environnement Active Directory, l’authentification Kerberos est initiée par une demande de ticket d’authentification (TGT) pour un sujet donné. Les données de pré-authentification incluses dans cette requête (AS-REQ) comprennent un horodatage (timestamp) chiffré avec une clé cryptographique dérivée du mot de passe de ce sujet. À la réception du message AS-REQ, le service Kerberos du contrôleur de domaine (Key Distribution Center ou KDC) tente de déchiffrer le timestamp pour valider l’identité du sujet (et vérifier la bonne synchronisation des horloges par la même occasion).

Le contrôleur de domaine retourne un TGT si l’authentification s’avère valide (AS-REP), ou un code d’erreur dans le cas contraire.

Le sujet peut ensuite utiliser le TGT comme preuve d’identité, qu’il présente au KDC pour obtenir des tickets d’accès à des services.

2. Découverte de comptes et de faiblesse d’authentification

2.1 Énumération

Lors d’une phase de reconnaissance, la découverte d’utilisateurs Active Directory peut présenter un intérêt du point de vue d’un attaquant non-authentifié.

À la réception d’un message AS-REQ ne contenant aucune donnée de pré-authentification Kerberos, le KDC retourne normalement un code d’erreur révélant la validité ou non du nom d’utilisateur spécifié dans la requête :

Des noms d’utilisateurs valides peuvent ainsi être déduits des codes d’erreur Kerberos via une attaque par force brute, consistant à forger des requêtes AS-REQ à partir d’une liste d’identifiants potentiels :

Des implémentations de cette attaque existent pour divers outils, comme le script NSE krb5-enum-users intégré à NMAP [2]. La liste de noms d’utilisateurs potentiels peut être construite en employant des techniques de renseignement en source ouverte (OSINT). De telles informations peuvent par exemple être collectées à partir de fuites de données massives circulant sur l’Internet.

2.2 AS-REP roasting

Microsoft propose une option Do not require Kerberos preauthentication pour permettre à un compte utilisateur donné de solliciter l’obtention d’un TGT sans inclure de données de pré-authentification dans la requête AS-REQ. La réponse AS-REP retournée par le KDC inclut une clé de session chiffrée avec celle dérivée du mot de passe de l’utilisateur, en plus du TGT chiffré avec le compte krbtgt.

Ce bloc de données peut être cassé par attaque hors ligne afin d’obtenir le mot de passe de l’utilisateur. La suite cryptographique AES256-CTS-HMAC-SHA1-96 (Encryption Type 18) est utilisée par défaut à partir de Windows Server 2008, mais en forgeant le message AS-REQ il est possible de forcer une dégradation du chiffrement en spécifiant l’utilisation de ARCFOUR-HMAC-MD5 (Encryption Type 23) qui est bien plus rapide à casser [3].

À partir d’un accès à l’annuaire Active Directory, la recherche d’objets dont l’attribut LDAP userAccountControl comporte le drapeau DONT_REQ_PREAUTH permet de dresser une liste des comptes vulnérables à cette attaque connue sous le nom de AS-REP roasting. Les empreintes RC4-HMAC des mots de passe associés peuvent ensuite être obtenues en forgeant des requêtes AS-REQ sans aucune forme d’authentification préalable :

À l’instar de l’attaque Kerberoasting, une cryptanalyse peut enfin être menée sur ces empreintes de mots de passe en utilisant par exemple l’outil Hashcat avec le mode 18200 (Kerberos 5 AS-REP etype 23).

Une preuve de concept de l’attaque AS-REP roasting a initialement été publiée par Will Schroeder puis réimplémentée dans son excellent outil Rubeus [4].

3. Recherche de mots de passe faibles

3.1 Attaque sur l’authentification et furtivité

Divers mécanismes d’authentification peuvent être employés en environnement Active Directory pour vérifier la validité d’un mot de passe, tels que LDAP bind, MS-RPC bind (NETLOGON) via une connexion SMB ou RDP. Ces mécanismes sont bruyants en termes de trafic réseau et génèrent des événements d’échec 4625 « An account failed to log on » et 4776 « The computer attempted to validate the credentials for an account » dans les journaux de sécurité des contrôleurs de domaine lorsque l’authentification échoue.

La pré-authentification Kerberos induit quant à elle un trafic réseau réduit à deux datagrammes UDP pour chaque tentative et ne génère par défaut aucun événement dans les journaux en cas d’échec [5].

3.2 Contrainte relative à la stratégie de mot de passe

Une tentative d’authentification Kerberos avec un mot de passe invalide entraîne naturellement l’incrémentation de l’attribut LDAP badPwdCount du compte ciblé, excluant de ce fait l’emploi d’une attaque par force brute pour deviner le mot de passe d’un compte lorsqu’un seuil de blocage est spécifié dans la stratégie de mot de passe.

La stratégie de mot de passe appliquée par défaut au niveau du domaine Active Directory peut être identifiée à partir d’un accès à l’annuaire LDAP, en utilisant par exemple le module PowerShell « ActiveDirectory » intégré aux utilitaires RSAT :

En présence d’une telle stratégie de mot de passe, le password spraying est une alternative plus efficace qu’une attaque par force brute pour compromettre des comptes Active Directory. Cette attaque consiste à tenter une authentification sur l’ensemble des comptes du domaine avec un unique mot de passe choisi intelligemment.

3.3 Attaque password spraying optimisée

Un accès LDAP à l’annuaire Active Directory permet d’obtenir la liste de l’ensemble des comptes de domaine et de vérifier la valeur de leur attribut badPwdCount pour prévenir les blocages potentiels. En cas d’échec d’authentification, cet attribut est en effet incrémenté au niveau du contrôleur de domaine gérant la demande d’authentification, mais celui-ci n’est pas répliqué (il est néanmoins synchronisé sur le contrôleur principal portant le rôle FSMO PDCe).

La valeur de l’attribut badPwdCount révèle une autre information d’intérêt : lorsqu’une authentification basée sur Kerberos ou Net-NTLM est réalisée avec l’un des deux précédents mots de passe d’un utilisateur, l’authentification échoue, mais l’attribut badPwdCount n’est alors pas incrémenté. En comparant la valeur de cet attribut avant et après une tentative d’authentification infructueuse, il est donc possible d’identifier si le mot de passe testé correspond à l’un des précédents mots de passe de l’utilisateur. Ce principe peut éventuellement révéler un pattern de construction de mot de passe utilisé par l’utilisateur et potentiellement employé pour son mot de passe actuel. Celui-ci a initialement été exposé par Rindert Kramer et outillé sous la forme d’un module Metasploit badPwdCountSprayer pour réaliser du password spraying via le mécanisme LDAP bind [6].

Un password spraying mené via le mécanisme de pré-authentification Kerberos couplé à l’inspection de l’attribut badPwdCount constitue donc une attaque relativement furtive et efficace pour compromettre des comptes Active Directory.

À noter que le code d’erreur Kerberos KDC_ERR_KEY_EXPIRED parfois retourné par le KDC indique par ailleurs qu’un mot de passe est valide, mais que celui-ci est expiré. Il peut donc être renouvelé à partir du mot de passe utilisé lors de la tentative d’authentification.

3.4 Chemins de compromission

Du point de vue d’un attaquant authentifié, la compromission de comptes de domaine présente un intérêt réel lorsqu’une escalade de privilèges s’avère possible. Ces chemins d’attaque peuvent être cartographiés à partir d’un accès non-privilégié au domaine, par analyse de relations de contrôle entre objets Active Directory. Ces relations sont basées sur un ensemble de propriétés telles que les permissions, les paramètres de stratégie de groupe, l’appartenance aux groupes de sécurité ou la hiérarchie des objets (voir figure 3). BloodHound est un outil couramment utilisé pour réaliser ce type d’analyse à des fins offensives, en intégrant un nombre impressionnant de vecteurs d’escalade de privilèges [7].

Identifier l’existence d’un chemin de contrôle vers une cible d’intérêt à partir de comptes compromis par password spraying est particulièrement utile (voir figure 2).

4. Rejeu et réutilisation de secrets d’authentification

4.1 Rappel sur la technique Pass-the-key

Pour authentifier un sujet à l’origine d’une requête Kerberos AS-REQ, un timestamp est intégré aux données de pré-authentification et chiffré avec une clé secrète dérivée du mot de passe de l’utilisateur.

Plusieurs suites cryptographiques sont supportées dans l’implémentation Kerberos de Microsoft : DES_CBC_CRC, DES_CBC_MD5, RC4_HMAC_MD5, AES128_HMAC_SHA1 et AES256_HMAC_SHA1. La clé secrète basée sur l’algorithme RC4 n’est autre que le condensat NTLM (NT-HASH) du mot de passe de l’utilisateur, qui peut donc être rejoué via le mécanisme de pré-authentification Kerberos :

Initialement implémentée par Benjamin Delpy dans son fameux outil Mimikatz, cette technique connue sous le nom de overpass-the-hash (ou pass-the-key) est typiquement employée pour obtenir un TGT en ayant uniquement connaissance du NT-HASH d’un mot de passe (typiquement extrait depuis le processus lsass.exe d’une machine compromise) [8]. Peu bruyante et généralement moins surveillée que la classique attaque pass-the-hash, cette technique offre d’autres perspectives intéressantes pour identifier notamment la réutilisation de secrets d’authentification entre des domaines Active Directory distincts.

4.2 Credential stuffing

La technique pass-the-key peut être exploitée pour rejouer sur un domaine Active Directory ciblé l’ensemble des couples identifiant / NT-HASH extraits depuis un autre domaine compromis (par exemple via une attaque DCSync, comme illustré ci-après).

La réutilisation de secrets d’authentification représente en effet un chemin de compromission potentiel dans un environnement Active Directory multi-forêt où aucune relation d’approbation n’est exploitable :

Référencée sous la terminologie crendential stuffing dans la dernière version bêta du framework MITRE ATT&CK, cette technique tire parti de la tendance des utilisateurs à utiliser les mêmes mots de passe sur différents services.

5. Contre-mesures

5.1 Détection

Comme évoqué dans cet article, la pré-authentification Kerberos ne génère par défaut aucun événement en cas d’échec. Pour détecter les attaques exploitant ce mécanisme, la journalisation avancée doit tout d’abord être activée grâce au paramètre de stratégie de groupe Audit: Force audit policy subcategory settings to override audit policy category settings. Dans la catégorie Account Logon, la journalisation des opérations en échec de la sous-catégorie Audit Kerberos Authentication Service doit a minima être activée. Avec cette configuration, une authentification Kerberos en échec génère un événement 4771 « Kerberos pre-authentication failed ».

La suite cryptographique AES256-CTS-HMAC-SHA1-96 étant devenue la norme sur les systèmes Windows modernes, l’emploi de RC4 pour le chiffrement des tickets Kerberos constitue donc une exception qui doit éveiller les soupçons. Cette dégradation du chiffrement est en effet caractéristique d’attaques Pass-the-key, AS-REP roasting ou autre Kerberoasting. Il convient de surveiller les régressions cryptographiques dans les demandes de ticket en activant aussi la journalisation des opérations en succès de la sous-catégorie Audit Kerberos Authentication Service. Toute demande de TGT génère alors un événement 4768 « A Kerberos authentication ticket (TGT) was requested », avec un champ Ticket Encryption Type spécifiant un code hexadécimal relatif au type de chiffrement employé :

5.2 Remédiations

Une stratégie de mot de passe garantissant une complexité acceptable doit être généralisée à l’ensemble des comptes du domaine Active Directory. Des stratégies de mots de passe renforcées doivent par ailleurs être imposées pour :

• Les administrateurs : un minimum de 15 caractères permet par exemple de s’assurer que l’algorithme obsolète LM-HASH ne sera pas employé sur les systèmes les plus vieillissants ;
• Les comptes de service : privilégier lorsque c’est possible les comptes gérés (MSA ou gMSA) ou une longueur et une complexité accrues pour se prémunir contre le Kerberoasting.

L’ajout d’un facteur d’authentification supplémentaire n’est pleinement efficace que si l’authentification NTLM est désactivée, ce qui impose que les utilisateurs soient membres du groupe Protected Users. Les comptes les plus privilégiés devraient dans tous les cas être rattachés à ce groupe apparu depuis Windows 2012 R2, pour interdire notamment l’utilisation de l’algorithme RC4 avec Kerberos [9].

L’option Do not require Kerberos preauthentication est à bannir pour l’ensemble des comptes Active Directory pour se prémunir contre l’attaque AS-REP roasting.

Enfin, une fonctionnalité apportée par Windows Server 2012 R2, nommée blindage Kerberos (Kerberos armoring), peut être activée pour renforcer la sécurité des messages échangés entre le client et le KDC. En implémentant la technologie FAST (Flexible Authentication Secure Tunneling), cette fonctionnalité protège notamment les blocs de données qui dépendent directement du mot de passe de l’utilisateur [10].

Conclusion

Les attaques présentées dans cet article impliquent de devoir forger des requêtes AS-REP. La structure de données utilisée dans les échanges protocolaires est basée sur le standard commercial ASN.1.

Aucune fonction n’est fournie par le framework .NET pour manipuler ce type d’encodage. Des implémentations des mécanismes Kerberos sont disponibles en open source, les travaux de Benjamin Delpy et Will Schroeder représentent une excellente référence sur le sujet. L’outil PowerSpray abordé dans cet article s’appuie sur une implémentation C# du format ASN.1 intégrée à Rubeus. Celle-ci a été adaptée pour être chargée en tant que bibliothèque, permettant ainsi la construction des messages Kerberos en PowerShell. Les fonctions cryptographiques sont quant à elles importées depuis la bibliothèque Windows cryptdll.dll.

Bien que l’utilisation de PowerShell soit de plus en plus surveillée, cette technologie reste avantageuse de par son support natif et sa facilité d’emploi lors de tests d’intrusion en environnement Windows.

Remerciements

Je tiens à souligner à nouveau que les publications de Benjamin Delpy et Will Schroeder constituent une mine d’or sur Kerberos, sans oublier les articles d’Aurélien Bordes sur le sujet qui sont également d’une grande aide pour comprendre le fonctionnement (et les faiblesses !) du protocole.

Je salue enfin toute l’équipe de SYNETIS pour sa motivation et son intérêt pour de tels sujets et remercie notamment Yann et Joshua pour leur relecture attentive.

Références

[1] Timothée Ménochet, outil offensif pour la découverte de secrets d’authentification via Kerberos : https://github.com/tmenochet/PowerSpray

[2] NMAP, script NSE « krb5-enum-users » : https://nmap.org/nsedoc/scripts/krb5-enum-users.html

[3] Will Schroeder, « Roasting AS-REPs » : https://www.harmj0y.net/blog/activedirectory/roasting-as-reps

[4] Will Schroeder, « From Kekeo to Rubeus » : https://www.harmj0y.net/blog/redteaming/from-kekeo-to-rubeus

[5] Ronnie Flathers, « Fun with LDAP and Kerberos: Attacking AD from non-Windows machines » : https://www.troopers.de/troopers19/talks/zbw3mh

[6] Rindert Kramer, « Further abusing the badPwdCount attribute » : https://blog.fox-it.com/2017/11/28/further-abusing-the-badpwdcount-attribute

[7] Walter Legowski, « A Hacker's Guide to the BloodHound Galaxy » : https://www.ernw.de/download/ERNW_DogWhisperer3.pdf

[8] Benjamin Delpy, « Overpass-the-hash » : http://blog.gentilkiwi.com/securite/mimikatz/overpass-the-hash

[9] Aurélien Bordes, « Secrets d’authentification épisode II Kerberos contre-attaque » : https://www.ssi.gouv.fr/publication/secrets-dauthentification-episode-ii-kerberos-contre-attaque

[10] Aurélien Bordes, « L’administration en silo » : https://www.sstic.org/2017/presentation/administration_en_silo