Sécurité - Active Directory Et L'attaque ASREPRoast

29/03/2024 16:37 Sécurité : Active Directory et l'attaque ASREPRoast
Sécurité de l’Active Directory : comprendre et se protéger

de l’attaque ASREPRoast
26/03/2024 Mickael Dorigny 92 Views Aucun commentaire Active Directory, Cybersécurité 31 min read
Sommaire [-]
I. Présentation
II. Qu'est-ce que l'attaque ASREPRoast ?
A. Dans les grandes lignes
B. Dans le détail
C. Pourquoi cet attribut ?
III. Configuration d'un Lab vulnérable
IV. Point de vue de l'attaquant
A. Trouver une liste de noms
B. Exploiter ASREPRoast depuis Linux
C. Exploiter ASREPRoast depuis Windows
V. Point de vue du défenseur
A. Lister les comptes utilisateurs avec preauth-notreq
B. Corriger les comptes vulnérables
C. Détecter une attaque ASREPRoast
VI. Conclusion
I. Présentation
Dans cet article, nous allons comprendre, exploiter et corriger une vulnérabilité fréquente sur les
environnements Active Directory : ASREPRoast.
Ce nom ne vous dit peut-être rien, mais il s'agit d'un défaut de configuration fréquent dans l'Active Directory.
L'attaque ASREPRoast permet à un attaquant situé sur un réseau d'entreprise possédant un domaine de compromettre
rapidement un compte utilisateur, et ainsi de passer d'un mode opératoire boite noire (attaque sans identifiants
valides, juste une connexion au réseau) à un mode boite grise (attaque depuis un compte valide sur le domaine). Le
passage d'un mode boite noire à boite grise change en général la donne de façon très importante lors d'une
cyberattaque, car l'accès authentifié au domaine permet d'en extraire beaucoup d'informations.
L'objectif de cet article est de vous expliquer en détail cette vulnérabilité. Nous allons notamment voir comment elle
peut être introduite sur un Active Directory, comment un attaquant peut l'exploiter et comment un défenseur peut
l'identifier et la corriger.
https://www.it-connect.fr/securite-active-directory-comprendre-et-se-proteger-attaque-asreproast/ 1/23
C'est parti !
II. Qu'est-ce que l'attaque ASREPRoast ?

A. Dans les grandes lignes
Commençons par essayer de comprendre le nom de l'attaque. "ASREP" fait référence au message "KRB-AS-REP"
du service Kerberos lors d'une authentification (réponse à un message KRB-AS-REQ, une requête d'authentification
Kerberos). "Roast" renvoi simplement au mot "rôtir" ou "cuisiner" car l'on devra ensuite travailler un peu sur la
donnée obtenue pour pouvoir l'utiliser.
Au sein d'un domaine, l'authentification Kerberos est assurée par le composant Key Distribution
Center (KDC) des contrôleurs de domaine. Lorsqu'un utilisateur souhaite accéder à un service ou à une ressource
réseau, il doit d'abord obtenir un Ticket Granting Ticket (TGT) auprès du KDC. Pour cela, l'utilisateur envoie une
requête de type "KRB-AS-REQ" (Kerberos Authentication Service Request) au KDC, elle contient notamment des
informations d'identification de l'utilisateur et une clé liée à son mot de passe.
Le KDC vérifie alors les informations d'identification fournies par l'utilisateur. Si celles-ci sont correctes et que
l'utilisateur existe dans le domaine, le KDC lui délivre un TGT. Ce TGT est ensuite utilisé par l'utilisateur pour obtenir
des tickets de session (TGS) auprès des services du domaine, lui permettant d'accéder à ceux-ci sans avoir à fournir à
nouveau ses informations d'identification. Ce processus s'appelle pre-authentification.
Schéma d'une authentification Kerberos et de l'émission d'un TGT.
Cependant, il existe une configuration spécifique représentée par un attribut sur les comptes utilisateurs appelé "Do
not require Kerberos preauthentication". Cet attribut autorise l'envoi d'un TGT pour un compte sans que le
demandeur n'ait prouvé son identité au préalable.
Schéma de l'émission d'un TGT pour un utilisteur ayant l'attribut "Do not require Kerberos preauthentication".
En conséquence, n'importe qui sur le réseau peut obtenir un TGT représentant ce compte utilisateur et tenter
d'usurper son identité. Il est important de noter que le TGT obtenu ne peut être utilisé que si la personne qui le détient
connaît le mot de passe du compte associé. Cependant, en cas d'utilisation d'un mot de passe faible, le contenu du
TGT peut être utilisé pour retrouver le mot de passe du compte utilisateur.
Le TGT ne contient pas directement le mot de passe de l'utilisateur. Mais, il contient des informations
chiffrées grâce au secret de l'utilisateur, qui sont utilisés pour prouver l'identité de l'utilisateur lorsqu'il
demande des tickets de session ultérieurs. Ainsi, des "traces" du mot de passe s'y trouve, ce qui permet
de tenter de casser le TGT pour retrouver le mot de passe en clair.
Cette attaque est très connue des attaquants, si bien qu'elle dispose de son propre TTP (Tactics, Technics and
Procedures) dans le framework MITRE ATT&CK : T1558.004- Steal or Forge Kerberos Tickets: AS-REP Roasting.
B. Dans le détail
Regardons à présent dans le détail ce qu'il se passe lors d'une authentification via Kerberos. Pour cela, j'ai effectué une
capture réseau des échanges dans différents cas de figures.
AS-REQ pour un login inexistant
Lorsqu'un utilisateur souhaite s'authentifier auprès du service Kerberos, le client envoi dans un premier temps un
message de demande d'authentification ("KRB-AS-REQ"), voici à quoi il ressemble sur une capture réseau (cliquez
sur l'image pour zoomer) :
"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".
Dans le cas d'une demande d'authentification avec un login incorrect, c'est-à-dire qui n'existe pas dans l'Active
Directory, le service Kerberos renvoi un message de type "KRB-ERROR : C-PRINCIPAL-UNKNOWN" en
réponse à l'AS-REQ" du client. Le message est clair : l'utilisateur "MMARTIN1" n'existe pas dans l'Active Directory.
AS-REQ pour un login existant avec pré-authentification
Si le login est correct, le service renvoi une réponse de type "KRB-ERROR : PREAUTH REQUIRED". Cette
réponse du service Kerberos indique que pour obtenir un TGT pour cet utilisateur, il faut au préalable s'authentifier, ce
qui est plutôt une bonne nouvelle d'un point de vue sécurité. Rappelons que les TGT sont des tickets qui permettent de
demander des TGS (Ticket Granting Service) pour accéder à un service au nom de l'utilisateur présenté dans le
ticket. Il est donc préférable de prouver son identité (s'authentifier) au préalable.
À noter que cette différence de comportement dans la réponse du service

("PRINCIPAL_UNKNOWN "ou "PREAUTH REQUIRED") permet une énumération des
utilisateurs basée sur un dictionnaire. Sans même connaitre le mot de passe associé à un compte, on
peut savoir s'il existe dans l'annuaire, car le service Kerberos nous indiquera clairement cette
information dans sa réponse.
Voici à quoi rassemble une réponse "PREAUTH_REQUIRED". Suite à cette réponse, notre client s'authentifie
envoyant un message "AS-REQ", encore ? (cliquez sur l'image pour zoomer) :
Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.
Ce second message "AS-REQ" contient cependant un nouvel item, il s'agit d'une donnée chiffrée à l'aide d'une clé liée
au mot de passe utilisateur. Si le service Kerberos parvient à déchiffrer ce message avec le mot de passe de l'utilisateur
(qu'il possède de son côté grâce à l'annuaire et sa base NTDS.DIT) alors, il aura la preuve qu'il s'agit du bon mot de
passe, et donc du vrai utilisateur. Tout cela sans que le mot de passe n'ait transité en clair sur le réseau. Pour plus de
détails, sachez que la donnée chiffrée est un timestamp : c'est-à-dire la date et l'heure actuelle dans un format précis
(notez le "pA-ENC-TIMESTAMP" dans la seconde AS-REQ).
Enfin, si les identifiants sont corrects, le service envoi un message de réponse "AS-REP" contenant notamment un
TGT, qui permet de demander ensuite des TGS (cliquez sur l'image pour zoomer) à différents services :
Transmission d'un TGT par le service Keberos suite à une authentification réussie.
Voilà à quoi ressemble une authentification "classique" via Kerberos en vue d'obtenir un TGT.
AS-REQ pour un login existant sans pré-authentification
Cependant, Microsoft a ajouté un attribut aux objets utilisateur qui permet d'autoriser le service Kerberos à fournir un
TGT à quiconque le demande, sans authentification : l'attribut "Do not require Kerberos preauthentication". Dans ce
cas, un attaquant peut demander un TGT pour un tel compte sans avoir besoin de fournir de preuve d'identité valide.
Voilà alors ce qu'il se passe (cliquez sur l'image pour zoomer) :
Obtention d'un TGT sans authentification préalable pour un utilisateur ayant l'attribut "No preauthentication required".
Une "AS-REQ", demandant un TGT pour l'utilisateur "RDUBOIS", puis une "AS-REP" du KDC délivrant TGT, le
tout sans preuve d'identité (authentification). N'importe qui peut donc usurper l'identité de l'utilisateur "RDUBOIS" en
demandant un TGT à son nom, puis utiliser ce TGT pour demander des TGS aux services du domaine et y accéder.
Pour être plus précis, rappelons que le TGT obtenu dans les messages "AS-REP" est chiffré et ne peut être utilisé
sans connaître le mot de passe du compte utilisateur. Cependant, étant donné qu'il est chiffré avec un dérivé du mot
de passe utilisateur, l'attaquant pourra tenter de casser ce mot de passe en Offline (localement, sans interactions
supplémentaires avec le KDC ou le domaine), pour retrouver le mot de passe de l'utilisateur.
En résumé, quand cet attribut est présent sur un compte utilisateur, n'importe qui peut obtenir une donnée (le TGT) qui
utilise un dérivé du mot de passe du compte utilisateur, et donc tenter de retrouver le mot de passe en clair. Même en
étant confiant sur l'algorithme de chiffrement et la robustesse du mot de passe utilisé, reconnaissons qu'il est plutôt
périlleux de fournir ce genre d'informations à un simple visiteur non authentifié sur notre système d'information.
J'espère que cette vue en détail des échanges Kerberos vous aura permis de mieux comprendre le fonctionnement de
l'attaque ASREPRoast.
C. Pourquoi cet attribut ?

Certaines applications ne prennent pas en charge la pré-authentification Kerberos, il est ainsi courant de trouver
des utilisateurs avec la pré-authentification Kerberos désactivée, permettant ainsi aux attaquants de demander des TGT
pour ces utilisateurs. C'est la raison principale de l'existence de ce paramètre d'après la documentation Microsoft. La
pré-authentification Kerberos peut également être désactivée pour d'autres raisons liées à des besoins spécifiques de
sécurité ou de compatibilité avec d'autres systèmes.
Dans la réalité, il n'est pas rare de trouver de tels comptes, notamment sur des systèmes d'information qui ont un
certain historique...
III. Configuration d'un Lab vulnérable

Attention, dans ce chapitre, nous allons configurer de manière volontaire un Lab vulnérable pour vous exposer le but
et le fonctionnement de l'attaque.
NE PAS REPRODUIRE SUR UN ENVIRONNEMENT DE PRODUCTION.
Dans mon Lab de démonstration, j'ouvre la console "Utilisateurs et ordinateurs Active Directory", puis je
sélectionne un de mes utilisateurs, ici l'utilisateur "RDUBOIS". Il faut ensuite faire un clic droit "Propriétés" sur cet
objet et se rendre dans "Compte" :
Configuration de l'attribut "Do not require Kerberos preauthentication" sur un compte utilisateur.
Dans les "Options de compte", il faut trouver et cocher "La pré-authentification Kerberos n'est pas nécessaire"
comme sur l'image ci-dessus.
Si vous vous souvenez des explications précédentes, l'attaque ASREPROAST est d'autant plus dangereuse si le mot de
passe utilisé est faible, pour avoir un cas d'école, nous allons paramétrer le mot de passe de l'utilisateur "RDUBOIS" à
"#1p@ssword" (ce n'est pas un mot de passe faible ? Vous allez voir que si 🙂 ). Il faut à nouveau faire un clic droit
sur l'objet puis "Réinitialiser le mot de passe" :
Paramétrage d'un mot de passe faible sur le compte utilisateur.
Voilà, notre Lab d'entrainement est prêt !
IV. Point de vue de l'attaquant

Soyez vigilant à n'exploiter ou même tenter de découvrir cette vulnérabilité que si vous y êtes autorisé. Pour
rappel : Code pénal : Chapitre III : Des atteintes aux systèmes de traitement automatisé de données
A. Trouver une liste de noms

Vous l'aurez compris, pour effectuer une attaque ASREPRoast, il faut un login utilisateur à tester, voire plusieurs.
Dans un premier temps, l'attaquant doit donc se constituer une liste de login (dictionnaire) qu'il soumettra ensuite au
service Kerberos.
Dans le cas où l'attaquant n'est pas authentifié sur le domaine (boite noire) :
Si l'attaquant n'a pas de compte sur l'Active Directory, il peut utiliser différentes méthodes pour récupérer des logins
valides. L'OSINT (Open Source Intelligence) est une méthode assez commune puisqu'avec quelques requêtes Google
ou recherches Linkedin, on peut assez facilement retrouver une liste de personnes travaillant dans une entreprise. La
recherche dans des fuites de données, basée sur le nom de l'entreprise ou l'adresse mail, est aussi fréquente.
Depuis l'intérieur du réseau (toujours sans compte valide sur le domaine), il existe un grand nombre de techniques
également. Les imprimantes sont mon moyen favori, souvent mal protégées avec des interfaces d'administration
exposées et verbeuses, elles stockent des carnets d'adresses qui exposent souvent des logins utilisateur. Les
applications web internes, services SNMP, SMB et RPC mal configurés (authentification anonyme) ou même
l'interception réseau sont également très efficaces.
Également, il est possible pour l'attaquant d'utiliser des dictionnaires pré-conçus utilisant des couples prénom-noms
communs, voir des noms de comptes techniques comme "svc-ldap", "backup", "formation", "accueil", etc. Les
dictionnaires que j'utilise souvent sont publics et fonctionnent en général très bien, bien qu'utilisant majoritairement
des noms anglophones : https://github.com/insidetrust/statistically-likely-usernames.
Avec toutes ces méthodes, il est souvent très facile de se constituer une liste bien fournie de logins utilisateur
potentiels. Il faut enfin savoir les formater grâce à la nomenclature actuelle de l'Active Directory ciblé : est-
ce "marc.martin", marc_martin, "m.martin", "mmartin" ? etc.
Dans le cas où l'attaquant est authentifié sur le domaine (boite grise) :
Si l'attaquant possède déjà un compte sur le domaine, rien de plus facile. Une simple requête LDAP permettra de
récupérer la totalité des logins utilisateur de l'annuaire, il aura alors une liste exhaustive des comptes à cibler,
augmentant ses chances d'en trouver un avec l'attribut "Do not require Kerberos preauthentication".
Depuis Linux, une requête "ldapsearch" fera l'affaire :
ldapsearch -v -x -D "mmartin@it-connect.tech" -W -b "DC=it-connect,DC=tech" -H

"ldap://ad01.it-connect.tech" "(&(objectClass=user))" sAMAccountName |grep "sAMAccountName:"
|cut -d " " -f 2 > /tmp/userlist
J'utilise ici la commande "ldapsearch" pour récupérer les attributs "sAMAccountName" des utilisateurs du domaine,
puis la commande "grep" pour isoler les lignes qui m'intéressent et enfin "cut" pour isoler uniquement le login de
l'utilisateur. Si vous peinez à comprendre cette commande, n'hésitez pas à la décomposer dans votre environnement et
à exécuter les commandes une à une. Le tout est enregistré dans le fichier "/tmp/userlist". Voici un exemple du
résultat attendu :
Extraction des utilisateurs de l'Active Directory avec un compte valide sur le domaine via "ldapsearch".
Je me retrouve donc avec une liste de 1000 logins utilisateur valides dans le fichier "/tmp/userlist".
L'outil BloodHound va également récupérer la liste des utilisateurs pour les stocker dans un fichier JSON, qui pourra
facilement être parcouru pour en extraire les logins. Je vous oriente sur mon cours sur BloodHound si vous souhaitez
en savoir plus : Identifiez les faiblesses de votre Active Directory avec Bloodhound
Une fois cette liste, hypothétique, partielle ou complète à disposition, l'attaquant va pouvoir interroger sur le service
Kerberos du domaine afin de voir si :
L'utilisateur existe dans l'annuaire;

Il dispose de l'attribut "Do not require Kerberos preauthentication".
B. Exploiter ASREPRoast depuis Linux

Depuis Linux, une multitude d'outils offensifs existent pour effectuer cette attaque. Je vais ici vous présenter les outils
les plus classiques : "impacket" et "netexec".
Impacket est une bibliothèque Python utilisée pour interagir avec des protocoles de réseau tels que SMB,
LDAP et Kerberos. Elle offre des outils pour la manipulation de paquets réseau, la création de serveurs
et de clients pour ces protocoles, ainsi que des fonctionnalités avancées pour l'analyse et l'exploitation de
vulnérabilités. Impacket est très largement utilisé pour les opérations offensives et de nombreux outils
utilisent cette librairie.
En plus d'être une librairie très puissante, les créateurs d'Impacket fournissent des scripts qui l'utilisent afin
d'automatiser certaines opérations et attaques, comme ASREPRoast. Je ne peux pas détailler ici la procédure
d'installation de "Impacket" et de ses "examples scripts", je vous renvoie pour cela à la documentation officielle
: Github - Impacket.
ASREPRoast en boite noire
Nous allons notamment utiliser le script "impacket-GetNPUsers" ("NP" pour "NoPreauth"). Dans le cas où nous
sommes en boite noire, nous avons au préalable construit notre dictionnaire à partir de différentes sources. Nous
pouvons utiliser ce dictionnaire pour réaliser une attaque ASREPRoast. Ici,"192.168.56.102" est l'adresse IP de mon
contrôleur de domaine, qui héberge le service Kerberos (KDC)) :
impacket-GetNPUsers -usersfile /tmp/userlist -request -format hashcat -outputfile

/tmp/IMPACKET_asreproast_blackbox.txt -dc-ip 192.168.56.102 'it-connect.tech/'
L'outil netexec (NXC), également très présent dans les opérations offensives, peut aussi être utilisé :
netexec ldap 192.168.56.102 -u /tmp/userlist -p '' -d it-connect.tech --asreproast /tmp/NXC-

asreproast_blackbox.out
ASREPRoast en boite grise
Si l'on dispose d'un accès authentifié au domaine, encore mieux, "impacket-GetNPUsers" peut automatiser à la fois la
récupération des utilisateurs dans la base LDAP, et l'envoi d'un "AS-REQ" en leur nom pour voir s'ils sont vulnérables
à l'ASREPRoast :
impacket-GetNPUsers -request -format hashcat -outputfile ASREProastables.txt -dc-ip

192.168.56.102 'it-connect.tech/mmartin:MyPassword1!' -outputfile
/tmp/IMPACKET_asreproast_greybox.txt
Même principe pour "netexec", il suffira de spécifier l'utilisateur ("-u") et son mot de passe de ("-p") pour
s'authentifier auprès du service LDAP afin de récupérer la liste des utilisateurs :
netexec ldap 192.168.56.102 -u mmartin -p 'MyPassword1!' --asreproast /tmp/NXC-

asreproast_greybox.txt
Voici le résultat attendu pour "impacket-GetNPUsers" et "netexec" :
Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast authentifiée.
On voit donc que plusieurs logins sont tentés sur le service Kerberos et que, pour certains, un hash au format
"$krb5asrep$23$" est obtenu. Il s'agit d'une donnée extraite du TGT obtenu pour chaque utilisateur vulnérable,
spécialement formaté pour être interprété par des outils de cassage de mot de passe.
Maintenant que nous avons ces hashs, nous pouvons tenter de les casser, par exemple, à l'aide de "JohnTheRipper"
ou "hashcat" et de listes de mots de passe communs comme le dictionnaire de mot de passe "rockyou.txt" :
hashcat -m 18200 -a 0 ASREProastables.txt rockyou.txt

john --wordlist=rockyou.txt ASREProastables.txt
Ce cassage s'effectue totalement en local, sans interactions avec l'Active Directory ou le service Kerberos. Ainsi,
aucune détection n'est possible. Également, l'utilisateur a ici tout son temps et la rapidité de l'opération dépendra de la
robustesse du mot de passe et des ressources de calcul qu'il a à disposition. Si des mots de passe faibles ont été utilisés
par les comptes utilisateurs vulnérables, ils seront retrouvés par ces outils :
Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.
Si les mots de passe sont très robustes, alors il faudra déployer des moyens considérables pour les casser. Ici, le mot de
passe semble plutôt correct avec 3 alphabets et une longueur de 10 caractères, mais il se trouve dans le dictionnaire
public et très connu "rockyou.txt". Nous venons de retrouver le mot de passe d'un utilisateur de l'Active Directory par
l'intermédiaire d'un TGT signé grâce à un dérivé de son mot de passe par le service Kerberos.
C. Exploiter ASREPRoast depuis Windows

Sous Windows, l'outil le plus classique pour effectuer cette attaque est "Rubeus.exe", écrit en C#. Le plus simple est
de l'exécuter sur une machine intégrée au domaine ou via un "runas.exe" :
.\Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast
Voici le résultat attendu :
Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.
Comme pour les outils Linux, le fichier "hashes.asreproast" contiendra les hashs contenus dans les TGT récupérés et
pourra être passé à "hashcat" ou "JohnTheRipper" pour cassage.
V. Point de vue du défenseur

A. Lister les comptes utilisateurs avec preauth-notreq
Nous allons maintenant adopter le point de vue du défenseur ou blue team qui souhaite savoir si des utilisateurs
vulnérables à ASREPROAST sont présents sur son domaine.
Lorsque nous sommes sur notre propre domaine et contrôleur de domaine, le plus simple est d'utiliser le module
PowerShell "ActiveDirectory" qui permet de communiquer avec ADSI (Active Directory Services Interface). Nous
pouvons notamment cibler l'attribut "useraccountcontrol" pour extraire les utilisateurs disposant de l'attribut "Do not
require Kerberos preauthentication", exemple :
Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol | Format-

Table name, DistinguisedName, Enabled
Voici le résultat attendu :
Nous avons la même liste utilisateur qu'obtenue via notre requête "ldapsearch" bien entendu, avec un filtre sur ceux
qui ont déjà l'attribut "Do not require Kerberos authentication", mais nous utilisons ici des outils légitimes et plus
accessibles pour les administrateurs système. J'ai notamment ajouté le "DN" et l'attribut "Enabled" en sortie de la
commande (via le "Format-Table" ou "ft").
B. Corriger les comptes vulnérables

Une fois cette liste à disposition, il convient tout d'abord de déterminer :
Pourquoi ils sont/ont été utilisés, pour quels besoins, services et systèmes ?
Est-ce ce qu'ils sont toujours utilisés aujourd'hui ? (date de dernière authentification, dernier changement de mot de passe,
journaux d'évènements)
Est-ce que l'attribut "Do not require Kerberos authentication" est vraiment utile et répond à un besoin fonctionnel ?
Une fois que ces questions ont toutes une réponse claire pour chaque compte, la décision de désactiver cet attribut peut
être prise.
Corriger ASREPRoast via l'interface graphique
Depuis la console "Utilisateurs et ordinateurs Active Directory", effectuez un clic droit sur le compte utilisateur
concerné, puis "Propriétés. Il faut ensuite se rendre dans "Compte" et localiser l'option suivante :
Désactivation de l'attribut "Do not require Kerberos preauthentication" sur l'Active Directory.
Une fois décochée, nous pouvons appliquer nos changements. La modification prend effet immédiatement.
Corriger ASPREPRoast via Powershell
Il est aussi possible de modifier la valeur de cet attribut en PowerShell via ADSI. Le cmdlet "Set-
ADAccountControl" est fournie par le module PowerShell "ActiveDirectory" :
PS C:\> Set-ADAccountControl -Identity rdubois -DoesNotRequirePreAuth $false
À nouveau, la modification est prise en compte immédiatement.
Mesure complémentaire en cas de besoin fonctionnel
Si l'attribut "Do not require Kerberos preauthentication" est nécessaire et répond à un besoin identifié et justifié,
alors il convient de mettre un mot de passe très, très robuste à ce compte. L'idée est que même si un TGT est
récupéré, l'attaquant ne puisse pas casser le hash qu'il contient en vue de récupérer le mot de passe en clair de
l'utilisateur. Optez donc pour un mot de passe à plus de 30 caractères.
Dans l'idéal, il est également nécessaire de prévoir un renouvellement périodique de ces mots de passe afin de
réduire leur exposition dans le temps. Si l'attaquant dispose de tout le temps disponible devant lui pour casser le
hash contenu dans le TGT, alors il finira peut-être par y arriver (peut-être au bout de plusieurs années). Mais si le mot
de passe du compte est changé tous les six mois, il n'aura potentiellement pas le temps de l'exploiter une fois qu'il
l'aura cassé. Il s'agit d'une mesure de sécurité supplémentaire.
Limiter la propagation suite à une compromission

Il convient également de s'assurer que le compte qui dispose légitimement de l'attribut "Dot not require Kerberos
preauthentication" possède des droits limités sur le domaine et le système d'information. La revue des ACL,
appartenances aux groupes et l'application du principe de moindre privilège (configuration fine et minimaliste des
droits pour répondre uniquement aux fonctions métiers) permettra de limiter au maximum les actions possibles de
l'attaquant en cas de compromission du compte.
Changement de mot de passe
Enfin, il est à noter que si le compte a eu jusque-là cet attribut, n'importe quel utilisateur de votre domaine a peut être
déjà récupéré un TGT et obtenu son mot de passe, ou est en train de tenter de le casser. Ces mesures de correction
doivent donc s'accompagner d'un changement de mot de passe afin qu'un attaquant exploitant ou ayant exploité
cette faiblesse ne puisse pas réutiliser le mot de passe compromis pour ce compte, ce qui sera possible même si
l'attribut en question a été décoché.
C. Détecter une attaque ASREPRoast

Du point de vue du défenseur, nous allons également nous intéresser aux possibilités de détection d'une attaque
ASREPRoast passée ou en cours sur le système d'information.
Détection via les journaux d'évènements
L'exploitation de l'ASREPRoast génère, comme toute interaction avec l'Active Directory, des évènements. Cependant,
il n'est pas aisé de les distinguer clairement des activités légitimes et quotidiennes des utilisateurs du domaine. Il
faut savoir que lorsqu'un "AS-REQ" est effectué sur un compte non vulnérable à l'ASREPRoast (et donc, échoue),
aucun évènement de sécurité n'est généré. Seule l'émission d'un ticket Kerberos génère un évènement avec
l'eventID 4768.
L'event ID 4768 est enregistré sur le contrôleur de domaine chaque fois qu'un TGT est émis. Il indique
que le KDC a reçu une demande de TGT (AS-REQ) et qu'il a émis un TGT en réponse. L'évènement
journalisé contient alors quelques détails intéressants sur la demande.
https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/event-4768
Cet évènement apparait donc si :
La requête est émise avec une authentification valide, auquel cas un TGT est émis en réponse à l'"AS-REQ".
La requête porte sur un utilisateur ayant l'attribut "Do not require Kerberos authentication", auquel cas pas besoin
d'authentification, le TGT est tout de même émis en réponse à l'"AS-REQ".
Voici l'évènement tel qu'il apparaitra dans l'observateur d'évènement lors d'une demande de TGT classique, avec
authentification (utilisation ici de "impacket-getTGT") :
EventID 4768 suite à une demande et émission de TGT classique, avec authentification.
On voit clairement qu'un TGT a été demandé et émis pour l'utilisateur "IT-CONNECT\mmartin" par le client
"192.168.56.104". Nous allons également garder dans un coin de notre mémoire les informations relatives au "Type
de pré-authentification" et "Type de chiffrement du ticket". Je réalise maintenant la même opération à destination
du compte "IT-CONNECT\rdubois" et avec un outil offensif qui va directement demander un TGT sans
authentification préalable (utilisation de "netexec") :
EventID 4768 suite à une demande et émission de TGT à la suite d'une attaque ASREPROast via "netexec".
Les informations journalisées sont globalement les mêmes lors d'une demande et émission d'un TGT sur un compte ne
nécessitant pas la pré-authentification. Cependant, on peut noter deux exceptions (à noter que le résultat est le même
lors d'une exploitation avec "impacket-getNPUsers") :
Le "Type de chiffrement du ticket" est passé à "0x17" au lieu de "0x12".

Le "Type de pré-authentification" est passé à "0" au lieu de "2".
L'utilisation d'un chiffrement à "0x17" (RC4-HMAC) est un comportement typique des outils
d'attaque qui downgrade (abaissent) le niveau de chiffrement utilisé pour le chiffrement du TGT afin de rendre le
cassage de son contenu plus aisé. Par défaut, le niveau de chiffrement "0x12" entraine l'utilisation du AES256-CTS-
HMAC-SHA1-96 (Source : 4768(S, F): A Kerberos authentication ticket (TGT) was requested). Voilà un premier
élément caractéristique d'une attaque ASREPRoast avec des méthodes et outils classiques.
Egalement, la documentation Microsoft est limpide concernant les valeurs du "Type de pré-authentification" :
La demande de TGT avec une valeur "0" à "Type de pré-authentification" est donc également un signal intéressant à
surveiller. Pour finir sur cette détection, je vous propose une requête KQL (pour ELK) qui permet d'identifier les
événements de demande/émission d'un TGT avec un chiffrement faible (RC4) ou sans pré-authentification :
event.code:4768 AND (winlog.event_data.TicketEncryptionType: 0x17 OR

winlog.event_data.PreAuthType: 0)
Pour détailler un peu la requête. Il s'agit d'un filtre sur les évènements Windows ayant un évènement ID 4768 et qui
ont, soit un "TicketEncryptionType" à "0x17" (RC4), soit un "PreAuthType" à "0". Voici le résultat sur l'ELK de
mon lab (avec moins d'activité qu'un vrai SI, bien sûr) :
Visualisation dans ELK des évèenemtn caractértistique d'une attaque ASREPRoast
Pas de doute, il y a eu une activité suspecte sur mon SI entre 17h45 et 18h15, des TGT sans pre-authentification et
avec un algorithme de chiffrement faible ont été demandés.
Surveiller les modifications des attributs utilisateurs
Pour aller plus loin, vous pouvez également chercher et surveiller les event ID 4738 (A user account was changed)
et 5136 (A directory service object was modified) qui apparaissent lorsqu'un attribut utilisateur est modifié :
Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.
Plutôt que la compromission, vous visualiserez alors tous les évènements d'activation/désactivation de l'attribut
concerné sur des comptes utilisateurs, ce qui permettra de retrouver le moment où la vulnérabilité a été introduite sur
le compte concerné. Là aussi, il faudra aller plus loin pour réellement identifier le nom de l'attribut modifié et s'assurer
de n'obtenir que les alertes relatives à l'attribut "Do not require Kerberos preauthentication". Egalement, voici un
exemple de requête filtre KQL pour cet évènement :
event.code:4738 AND winlog.event_data.UserAccountControl:*2096*
Voici l'aperçu d'un tel évènement dans la console ElasticSearch :
Visualisation de l'eventID 4738 relatif à l'ajout de l'attribut "Do not requiere kebreroas pre-authentication" dans ElasticSearch.
Utilisation d'un honey account
Si vous maitrisez correctement la sécurité de votre système d'information, notamment avec un SIEM et un SOC
(Security Operation Center) efficaces, alors vous pouvez envisager la mise en place d'un honey account, ou "compte
pot de miel". L'idée est de créer un compte utilisateur volontairement vulnérable à ASREPRoast afin que sa
compromission génère un évènement de sécurité activement surveillé par la blue team.
Pour cela, il faut notamment être sûr que ce compte ne sera jamais utilisé de façon légitime par un utilisateur ou un
service du SI. Ainsi, si une demande de TGT pour ce compte spécifique apparait dans les journaux d'évènement, ce
sera forcément dû à une attaque ASREPRoast en cours.
Attention : La création et la gestion d'un compte pot de miel nécessitent une attention particulière. Il faut
s'assurer que les politiques de sécurité et les procédures de surveillance sont bien établies pour garantir
que le compte reste contrôlé et qu'il ne devienne pas une vulnérabilité supplémentaire. Il faut notamment
s'assurer que l'honey account ait un mot de passe très robuste afin que le hash contenu dans son TGT ne
soit jamais cassé, ce qui permettrait à l'attaquant d'obtenir un compte valide sur le domaine.
VI. Conclusion
J'espère que cet article vous a plu et que vous avez maintenant une meilleure idée des risques liés à cette attaque et de
la façon de s'en protéger. J'ai essayé de faire en sorte qu'il soit complet en abordant le point de vue des attaquants
comme des défenseurs.
N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !

Sécurité - Active Directory Et L'attaque ASREPRoast

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sécurité - Active Directory Et L'attaque ASREPRoast

Transféré par

Droits d'auteur :

Formats disponibles

29/03/2024 16:37 Sécurité : Active Directory et l'attaque ASREPRoast

Sécurité de l’Active Directory : comprendre et se protéger

II. Qu'est-ce que l'attaque ASREPRoast ?

Schéma d'une authentification Kerberos et de l'émission d'un TGT.

AS-REQ pour un login inexistant

"AS-REQ" suivi d'une erreur "ERR_C_PRINCIPAL_UNKNOWN".

AS-REQ pour un login existant avec pré-authentification

À noter que cette différence de comportement dans la réponse du service

Réponse "ERR_PREAUTH_REQUIRED" indiquant que le compte utilisateur existe dans l'annuaire.

AS-REQ pour un login existant sans pré-authentification

C. Pourquoi cet attribut ?

III. Configuration d'un Lab vulnérable

NE PAS REPRODUIRE SUR UN ENVIRONNEMENT DE PRODUCTION.

Voilà, notre Lab d'entrainement est prêt !

IV. Point de vue de l'attaquant

A. Trouver une liste de noms

Dans le cas où l'attaquant est authentifié sur le domaine (boite grise) :

Depuis Linux, une requête "ldapsearch" fera l'affaire :

ldapsearch -v -x -D "mmartin@it-connect.tech" -W -b "DC=it-connect,DC=tech" -H

L'utilisateur existe dans l'annuaire;

B. Exploiter ASREPRoast depuis Linux

ASREPRoast en boite noire

impacket-GetNPUsers -usersfile /tmp/userlist -request -format hashcat -outputfile

netexec ldap 192.168.56.102 -u /tmp/userlist -p '' -d it-connect.tech --asreproast /tmp/NXC-

ASREPRoast en boite grise

impacket-GetNPUsers -request -format hashcat -outputfile ASREProastables.txt -dc-ip

netexec ldap 192.168.56.102 -u mmartin -p 'MyPassword1!' --asreproast /tmp/NXC-

Voici le résultat attendu pour "impacket-GetNPUsers" et "netexec" :

Utilisation de "impacket-gtNPUsers" et "netexec" pour la réalisation d'une attaque ASREPRoast authentifiée.

hashcat -m 18200 -a 0 ASREProastables.txt rockyou.txt

Cassage du hash "krb5asrep" extrait du TGT de l'utilisateur obtenu via ASREPRoast.

C. Exploiter ASREPRoast depuis Windows

.\Rubeus.exe asreproast /format:hashcat /outfile:hashes.asreproast

Voici le résultat attendu :

Utilisation de "Rubeus.exe" pour la réalisation d'une attaque ASREPRoast.

V. Point de vue du défenseur

Get-ADUser -Filter 'useraccountcontrol -band 4194304' -Properties useraccountcontrol | Format-

Voici le résultat attendu :

B. Corriger les comptes vulnérables

Corriger ASREPRoast via l'interface graphique

Corriger ASPREPRoast via Powershell

PS C:\> Set-ADAccountControl -Identity rdubois -DoesNotRequirePreAuth $false

À nouveau, la modification est prise en compte immédiatement.

Mesure complémentaire en cas de besoin fonctionnel

Limiter la propagation suite à une compromission

Changement de mot de passe

C. Détecter une attaque ASREPRoast

Détection via les journaux d'évènements

Cet évènement apparait donc si :

Le "Type de chiffrement du ticket" est passé à "0x17" au lieu de "0x12".

event.code:4768 AND (winlog.event_data.TicketEncryptionType: 0x17 OR

Visualisation dans ELK des évèenemtn caractértistique d'une attaque ASREPRoast

Surveiller les modifications des attributs utilisateurs

Journalisation de la modification d'un attribut utilisateur via l'eventID 4738.

event.code:4738 AND winlog.event_data.UserAccountControl:*2096*

Voici l'aperçu d'un tel évènement dans la console ElasticSearch :

Utilisation d'un honey account

Vous aimerez peut-être aussi

event.code:4738 AND winlog.event_data.UserAccountControl:2096