Henoc
Henoc
03 Introduction
04 Active Directory
05 Technique d'attaque 1 :
Utilisation de méthodes d'authentification alternatives (T1550)
16 Technique d'attaque 2 :
Kerberoasting
23 Technique d'attaque 3 :
Attaque Golden Ticket
28 Technique d'attaque 4 :
Attaque DCShadow
32 Technique d'attaque 5 :
AS-REP Roasting
37 Technique d'attaque 6 :
Attaque par injection LDAP
42 Technique d'attaque 7 :
Attaque par relais NTLM PetitPotam sur les services de certificats
Active Directory (AD CS)
47 Conclusion
48 Références
Active Directory (AD), introduit avec Windows 2000 [1], est devenu partie intégrante des organisations modernes, servant
de pilier à l'infrastructure d'identité de 90 % des entreprises du classement Fortune 1000 [2]. Active Directory est largement
utilisé par les organisations pour sa simplicité et son approche de gestion centralisée. Il s'agit d'une solution attrayante pour
les entreprises, car elle facilite l'accès des employés aux ressources et aux applications à l'aide d'un seul ensemble
d'identifiants, ce qui augmente la productivité et l'efficacité [3]. De plus, sa structure de gestion centralisée offre un point de
contrôle unique aux administrateurs informatiques, leur permettant de gérer les utilisateurs, les ordinateurs et l'accès aux
ressources en un seul endroit [4].
Cependant, en raison de son utilisation généralisée et de ses limites architecturales, Active Directory devient un
handicap en cas de faille de sécurité et une cible prioritaire pour les adversaires qui cherchent à élever leurs privilèges,
infecter plusieurs systèmes et lancer des attaques dévastatrices telles que l'exfiltration de données, la compromission
totale du système et les ransomwares.
Les principaux défis à relever pour se remettre d'une violation d'AD consistent à identifier la source, à déterminer
l'étendue des dommages et à créer un nouvel environnement sécurisé. Selon le rapport 2022 de Verizon sur les enquêtes
relatives aux violations de données [5], 80 % des violations proviennent d'agents externes. Comme le souligne le rapport
2021 d'IBM sur le coût des violations de données, une fois qu'un administrateur de domaine est piraté, les attaquants
peuvent se cacher dans votre réseau pendant 277 jours avant d'être détectés, ce qui représente une menace importante
[6].
L'utilisation généralisée et la facilité d'accès aux ressources pour les employés rendent difficile pour les organisations de
retirer l'Active Directory (AD) obsolète et d'adopter des alternatives plus sécurisées comme Microsoft Azure Active
Directory (AAD). La transition vers AAD remédie à certaines des limites de l'AD en automatisant les tâches administratives
telles que la gestion des utilisateurs et l'attribution des appartenances à des groupes pour une efficacité accrue [7].
Cependant, les mêmes risques de sécurité s'appliquent toujours, car une compromission de l'infrastructure d'identité peut
avoir des conséquences dévastatrices. Les adversaires peuvent également exploiter Microsoft Endpoint Manager pour se
déplacer latéralement d'un locataire Azure vers un domaine AD sur site, créant ainsi des voies d'attaque entre des
environnements de gestion des identités distincts [8].
On ne saurait trop insister sur l'importance de la sécurité d'Active Directory. Les organisations doivent se préparer en mettant
en place des plans de reprise après sinistre et une surveillance vigilante afin de bloquer les attaques avant que le système
ne soit corrompu ou devienne irréparable. Le choix entre AD et AAD dépendra en grande partie des besoins et des
ressources de l'organisation, mais le risque de compromission demeure quel que soit le choix. L'utilisation sécurisée et
efficace d'Active Directory nécessite une compréhension claire des risques potentiels et un engagement envers les pratiques
et protocoles de sécurité.
Active Directory (AD) est un service d'annuaire essentiel pour la gestion des ressources réseau dans les réseaux
Windows. Il permet de centraliser la gestion de diverses ressources réseau, notamment les comptes
utilisateurs et ordinateurs, les ressources et les politiques de sécurité. AD facilite ainsi la gestion efficace et
sécurisée des réseaux dans une structure hiérarchique.
AD fonctionne selon une structure hiérarchique composée de domaines au niveau supérieur et de divers objets
imbriqués, tels que des utilisateurs, des ordinateurs et des groupes. La structure est conçue pour fournir un moyen
organisé et efficace de gérer les ressources réseau, et elle garantit l'application cohérente des politiques de sécurité
sur l'ensemble du réseau.
AD utilise le protocole LDAP (Lightweight Directory Access Protocol) pour la communication entre les domaines et les
contrôleurs de domaine. LDAP est un protocole de service d'annuaire qui permet la gestion de services d'annuaire
distribués sur un réseau IP. De plus, AD utilise Kerberos, un protocole d'authentification sécurisé pour l'authentification
sur un réseau. Cela garantit que seuls les utilisateurs et les ordinateurs autorisés peuvent accéder aux ressources du
réseau, renforçant ainsi la sécurité du réseau.
Pour gérer efficacement les ressources réseau, Active Directory utilise des objets de stratégie de groupe (GPO). Les
GPO servent à contrôler et à appliquer les stratégies de sécurité, le déploiement de logiciels et d'autres tâches
administratives sur l'ensemble du réseau. AD prend également en charge les appels de procédure à distance (RPC),
ce qui permet la gestion à distance des ressources réseau. Les administrateurs réseau peuvent ainsi gérer
efficacement les ressources réseau à partir d'un emplacement centralisé, quel que soit l'emplacement des
ressources elles-mêmes.
Cependant, Active Directory n'est pas à l'abri des attaques, et celles-ci peuvent avoir des conséquences
désastreuses pour le réseau. Les attaques réussies contre Active Directory se déroulent en trois étapes principales :
la découverte, l'escalade des privilèges par le vol d'identifiants de compte valides et l'accès à d'autres ordinateurs
du réseau/domaine. Une fois que les attaquants ont pris pied dans le réseau cible, ils s'efforcent immédiatement
d'obtenir un accès privilégié à d'autres systèmes qui les aideront à atteindre leur objectif final, tel que le
chiffrement et l'exfiltration des données de l'organisation.
En résumé, Active Directory est un composant essentiel pour la gestion et la sécurisation des ressources réseau
dans les réseaux Windows. Sa structure hiérarchique et ses diverses fonctionnalités, telles que LDAP et Kerberos,
les GPO et les RPC, permettent une gestion efficace et sécurisée des ressources réseau. Pour garantir la sécurité de
votre réseau, il est essentiel de protéger Active Directory contre les attaques en mettant en œuvre des mesures de
sécurité robustes et en maintenant à jour les protocoles de sécurité afin d'empêcher tout accès non autorisé aux
ressources réseau.
Les attaques adversaires sur un système peuvent souvent contourner les contrôles d'accès normaux en utilisant des
moyens d'authentification alternatifs tels que les hachages de mots de passe, les tickets Kerberos et les jetons d'accès aux
applications. Cette technique, connue sous le nom de T1550 dans le cadre MITRE ATTsCK, permet aux attaquants de se
déplacer latéralement dans un environnement et d'obtenir un accès non autorisé.
Cette section fournit une description détaillée de deux sous-techniques de la technique « Utilisation de méthodes d'authentification
alternatives (T1150) » : Pass-the-Hash (T1550.002) et Pass-the-Ticket (T1550.003).
Pass-the-Hash (T1550.002)
Le Pass-the-Hash (PtH) est une attaque basée sur l'identité qui est exploitée par les pirates pour accéder à d'autres
systèmes et privilèges au sein d'un réseau une fois qu'ils ont déjà compromis le système.
Un hachage est une sortie unique digérée d'une fonction mathématique à sens unique qui prend en entrée des
données de différentes tailles (qui peuvent être aussi longues qu'un roman classique ou aussi courtes qu'un
mot de passe à 8 chiffres) et renvoie une chaîne de caractères de taille fixe. Comme ces fonctions sont
conçues pour être unidirectionnelles, ce qui signifie qu'une fois le résultat obtenu, il devrait être impossible pour
un adversaire de le renverser, c'est-à-dire d'obtenir le texte en clair, le hachage des mots de passe reste une
pratique de sécurité courante contre les attaques visant à compromettre les données.
NTLM est une méthode d'authentification unique qui utilise un système de défi-réponse pour vérifier l'identité de
l'utilisateur sans avoir besoin de son mot de passe. Par conséquent, cette technique d'attaque ne nécessite pas que les
adversaires utilisent des outils de piratage tiers, car la version en clair du mot de passe n'est pas nécessaire ; elle
élimine donc le besoin d'effectuer des opérations de piratage fastidieuses.
Si un attaquant obtient le hachage NTLM du mot de passe d'un utilisateur par des moyens tels que l'extraction de la mémoire
[Link] ou du fichier %systemroot%\system32\config\SAM, la capture pendant les transmissions réseau ou le vidage à
partir d'une sauvegarde ou d'une image d'un système, il peut utiliser le mot de passe haché en transmettant le hachage à un
système distant qui reconnaît le compte compromis de l'utilisateur. En fonction des privilèges et du niveau d'accès de
l'utilisateur compromis, les adversaires peuvent obtenir un accès complet au système et mener à bien des attaques de
déplacement latéral.
Il est important de noter qu'il ne s'agit pas d'une vulnérabilité, mais plutôt d'un choix de conception délibéré
visant à réduire les frictions et à améliorer l'expérience utilisateur globale.
Les attaques Pass-the-Hash (PtH) peuvent être exécutées à l'aide de divers outils disponibles publiquement, tels que
Mimikatz [9] et evil-winrm [10], ainsi que des cmdlets PowerShell intégrés. Les attaquants utilisent souvent ces outils ou
commandes pour extraire le hachage de la mémoire d'un système compromis, puis l'utilisent pour accéder à d'autres
systèmes du réseau.
Outil 1 : Mimikatz
L'utilisation de Mimikatz pour l'attaque Pass-the-Hash comprend trois étapes principales.
Pour extraire la liste des utilisateurs récemment connectés et leurs identifiants OS, les pirates utilisent souvent le
module sekurlsa de Mimikatz, qui exploite différentes techniques pour extraire les informations d'authentification de la
mémoire LSASS, notamment l'analyse des structures mémoire et l'utilisation des API Windows. La fonction « logonpasswords
» de ce module extrait spécifiquement les données de session de connexion telles que les hachages de mots de passe
enregistrés et les identifiants mis en cache. Cela peut inclure les informations de connexion de l'utilisateur actuel, ainsi que
les informations relatives aux autres utilisateurs qui se sont connectés au même ordinateur.
Notez qu'avant d'utiliser la commande sekurlsa::logonpasswords, les attaquants doivent exécuter la commande
privilege::debug afin que Mimikatz puisse fonctionner correctement.
Par défaut, LSASS s'exécute avec un niveau d'intégrité élevé et est protégé contre le débogage par des processus
non autorisés. Cependant, en activant le privilège du débogueur, l'attaquant peut contourner cette protection et
accéder à la mémoire LSASS pour extraire les données de session de connexion.
Une fois ce hachage NTLM obtenu, les adversaires peuvent passer à la deuxième étape.
Il est important de noter que Mimikatz n'est pas le seul moyen de récupérer les hachages NTLM. Les adversaires utilisent
souvent d'autres applications en ligne de commande intégrées ou des outils tiers, tels que ProcDump [11] et Gsecdump
[12], pour récupérer les identifiants.
Il s'agit de l'étape principale au cours de laquelle l'adversaire transmet le hachage pour usurper l'identité de l'utilisateur et
accéder au système distant.
La commande « sekurlsa::pth » de Mimikatz est une fonctionnalité qui facilite les attaques « Pass-the-Hash ». Cette
technique permet à un attaquant de s'authentifier sur un système distant en utilisant un hachage NTLM capturé du
mot de passe d'un utilisateur, sans avoir besoin du mot de passe réel. Pour exécuter cette commande, l'attaquant doit
uniquement fournir les paramètres suivants :
Notez que les mots de passe Windows ne se limitent pas au protocole NTLM, mais peuvent également utiliser des
algorithmes de chiffrement par blocs courants tels que AES-128 et AES-256 pour le stockage des mots de passe.
Dans ce cas, les adversaires devront utiliser les paramètres /aes128: ou /aes256: au lieu de /ntlm:.
Remarquez avec quelle facilité nous avons pu accéder à un système distant sans connaître que le nom d'utilisateur et le
hachage NTLM du mot de passe de la victime.
Dans la troisième étape, l'attaquant utilise le compte utilisateur nouvellement obtenu pour étendre son accès au réseau. Par
exemple, l'adversaire peut utiliser un utilitaire en ligne de commande appelé PsExec pour exécuter du code à distance sur un
autre hôte.
Par exemple, l'attaquant peut exécuter la commande suivante pour lancer le processus « [Link] » sur la machine distante
dont l'adresse IP interne est « [Link] » :
Mimikatz n'est pas le seul moyen d'effectuer une attaque Pass-the-Hash. Les adversaires utilisent souvent PowerShell également.
Il est courant que les adversaires utilisent la cmdlet Invoke-WMIExec, qui permet d'exécuter des commandes arbitraires sur
une machine Windows distante à l'aide de WMI (Windows Management Instrumentation), pour mener une attaque PtH.
Notez que Invoke-WMIExec est une cmdlet PowerShell intégrée présente dans de nombreux systèmes Windows
récents. Cette fonctionnalité permet l'exécution de commandes arbitraires sur une machine Windows distante via
Windows Management Instrumentation (WMI). Vous pouvez exécuter Invoke-WMIExec directement à partir d'une
invite PowerShell ou l'intégrer dans un script PowerShell.
Le fait qu'il s'agisse d'une cmdlet intégrée rend l'attaque utilisant Invoke-WMIExec plus discrète, car elle ne
nécessite aucun téléchargement ou installation supplémentaire.
Par exemple, en disposant du hachage du mot de passe de l'utilisatrice Alice de notre scénario précédent, un
adversaire peut exécuter la commande suivante.
Dans la commande ci-dessus, un adversaire utilise le script Invoke-WmiExec pour exécuter la commande « hostname » sur la machine
distante dont l'adresse IP interne est [Link].
Outil 3 : evil-winrm
L'outil « evil-winrm » est un gem Ruby qui permet d'exécuter des commandes à distance sur une machine Windows à
l'aide du protocole Windows Remote Management (WinRM). Comme evil-winrm n'est pas un outil intégré, les adversaires
doivent l'installer avant de l'utiliser. Diverses options d'installation sont disponibles dans le dépôt GitHub correspondant
[10].
Dans une attaque Pass-the-Hash utilisant evil-winrm, l'attaquant spécifie le nom d'utilisateur, le hachage NTLM et l'adresse
IP du système cible comme paramètres dans la commande evil-winrm [14].
Par exemple, la commande suivante peut être utilisée pour effectuer une attaque PtH sur une machine Windows avec
l'adresse IP [Link], en utilisant le nom d'utilisateur « Alice » et le hachage NTLM «
a0c8746a6efc7782c7c19c55185145be » :
Grâce à ces informations, evil-winrm établit une connexion à distance avec le système cible et s'authentifie en tant
qu'utilisateur spécifié (Alice), permettant ainsi à l'attaquant d'exécuter des commandes arbitraires sur la machine
distante.
Ci-dessous, des ID d'événement connus sont ajoutés pour détecter une éventuelle attaque Pass-the-Hash [15], [16], [17],
[18] :
● Champs de description clés : Étiquette requise, Domaine du compte, Nom du processus source, Nom du nouveau
processus, Type d'escalade de jeton, ID du nouveau processus, ID du processus source
Pour atténuer le risque d'attaques par hachage, les organisations peuvent mettre en œuvre plusieurs mesures
techniques. L'une d'entre elles consiste à activer Windows Defender Credential Guard, une fonctionnalité introduite dans
Windows 10 et Windows Server 2016. Cet outil exploite la virtualisation pour sécuriser le stockage des informations
d'identification et restreindre l'accès aux seuls processus fiables.
La randomisation et le stockage des mots de passe administrateur local à l'aide d'une solution telle que Local
Administrator Password Solution (LAPS) de Microsoft ajoutent également un niveau de sécurité supplémentaire, car ils
réduisent la capacité d'un pirate à se déplacer latéralement avec des comptes locaux partageant le même mot de
passe. Il est également recommandé d'empêcher les comptes locaux de s'authentifier sur le réseau, ce qui peut être
réalisé grâce à l'utilisation de SID connus dans les stratégies de groupe.
Pass-the-Ticket (T1550.003)
Pass the Ticket (PtT) est une technique qui permet à un pirate d'utiliser un ticket d'accès Kerberos (TGT) acquis
précédemment. Le TGT est un élément essentiel du protocole Kerberos, car il permet à un utilisateur de s'authentifier sur
plusieurs systèmes sans avoir à saisir son mot de passe à chaque fois.
Le Ticket Granting Ticket (TGT) est un type de ticket émis par le contrôleur de domaine (DC) à un utilisateur
après authentification réussie sur le domaine. Il contient des informations cruciales telles que la clé de session
de l'utilisateur, son appartenance à un groupe et ses privilèges, qui sont utilisées pour demander des tickets de
service pour des services spécifiques sur les systèmes cibles. Kerberos chiffre le TGT à l'aide du hachage du mot
de passe de l'utilisateur et utilise des algorithmes de chiffrement symétrique (tels que DES ou AES) en fonction de la
configuration de l'environnement Kerberos. Après le chiffrement, le TGT est envoyé à l'ordinateur de l'utilisateur
et stocké en mémoire.
Lorsque l'utilisateur souhaite accéder à une ressource sur un autre système, il utilise le TGT pour demander un ticket de
service au contrôleur de domaine. Le ticket de service est également chiffré à l'aide de la clé de session de
l'utilisateur et contient une clé de session chiffrée qui peut être utilisée pour s'authentifier auprès du système
cible. Le ticket de service est ensuite envoyé à l'ordinateur de l'utilisateur, où il est utilisé pour s'authentifier
auprès du système cible.
En disposant d'une clé TGT volée, un adversaire peut demander un ticket de service au contrôleur de domaine pour un
service spécifique sur un système cible afin d'accéder à ses ressources.
Les attaques de type « pass-the-ticket » (PtH) peuvent être exécutées à l'aide de divers outils disponibles publiquement,
tels que Mimikatz, Kekeo [19], Rubeus [20], Creddump7 [21], etc. Les pirates utilisent souvent ces outils pour extraire les
TGT Kerberos de la mémoire d'un système compromis, puis les utilisent pour accéder à d'autres systèmes du réseau.
Un attaquant peut utiliser la commande sekurlsa::tickets Mimikatz avec le paramètre /export pour extraire tous les tickets
Kerberos de la mémoire et les enregistrer sous forme de fichiers .kirbi dans le même dossier que le fichier exécutable
Mimikatz.
En examinant les noms des fichiers .kirbi, il est possible de déterminer s'il existe des tickets Kerberos pour
un administrateur de domaine, tel que DOMAIN\Alice :
» | findstr « krbtgt »
...
[0;1e4c7df]-2-0-40e10000-Alice@[Link]
...
La deuxième commande, dir | findet « Alice » | findstr « krbtgt », répertorie tous les fichiers du répertoire actuel et
redirige la sortie vers la commande findstr afin de rechercher le texte « krbtgt ». Cette commande a pour but de
trouver le ou les fichiers de tickets Kerberos associés à l'utilisateur « Alice », dont le nom peut contenir la chaîne «
krbtgt ».
Notez que Mimikatz n'est pas le seul outil permettant d'obtenir des tickets Kerberos. Les adversaires peuvent
utiliser l'outil Rubeus [20] pour générer du trafic AS-REQ brut afin de demander un TGT avec un nom
d'utilisateur et un mot de passe fournis. L'avantage de cette attaque est que le mot de passe fourni à Rubeus
peut être crypté à l'aide des algorithmes RC4, DES et AES, et que l'attaque fonctionnerait toujours [22].
Au cours de cette étape, l'attaquant utilise la commande Mimikatz kerberos::ptt pour insérer le TGT obtenu dans sa
propre session, ce qui permet à sa session d'adopter l'identité et les autorisations du TGT volé pour accéder à l'avenir
aux ressources sans connaître les informations d'identification en clair. Cela permet à l'adversaire d'accéder à des
ressources qui seraient autrement protégées par l'authentification Kerberos [23].
* Fichier :
« C:\KerberosTickets\[0;1e4c7df]-2-0-40e10000-joed@[Link] » : OK
Notez que la commande ci-dessus sert à insérer le ticket d'accès Kerberos (TGT) stocké dans le fichier .kirbi
correspondant dans la session en cours.
Pour s'assurer que le bon ticket a été injecté, un adversaire peut utiliser la commande Mimikatz « kerberos::list ».
Il est important de mentionner que le TGT a une durée de vie limitée et qu'il expirera après un certain temps.
L'utilisateur devra se réauthentifier auprès du domaine pour obtenir un nouveau TGT.
Une fois qu'un ticket obtenu est prêt à être réutilisé, l'attaquant doit identifier ses capacités, c'est-à-dire où il peut être
utilisé. Un TGS ne peut fournir l'accès qu'à la ressource spécifique pour laquelle il a été émis, et l'attaquant peut trouver
cette information en examinant le TGS.
Pour utiliser un TGT, l'attaquant peut être amené à effectuer une phase de découverte interne afin de déterminer l'accès qu'il
accorde. Cela peut être aussi simple que de vérifier l'appartenance de l'utilisateur à un groupe et de rechercher des signes
évidents.
De nombreux outils peuvent être utilisés pour recueillir des informations sur Active Directory.
Cependant, un pirate peut également utiliser des commandes intégrées telles que « net » pour
recueillir ces informations sans alerter les contrôles de sécurité.
Enfin, l'attaquant peut utiliser les utilitaires intégrés au système d'exploitation pour se déplacer latéralement de manière
furtive afin d'essayer d'accéder à d'autres ressources et d'atteindre ses objectifs. Par exemple, l'adversaire peut utiliser
l'utilitaire de ligne de commande PsExec pour exécuter le fichier [Link] sur un poste de travail distant.
Ci-dessous, des ID d'événement connus sont ajoutés pour détecter une éventuelle attaque « Pass the Ticket » [15], [16] :
● Champs de description clés : nom du compte, nom du service (toujours « krbtgt »), ID du service, adresse du
client
Les mesures efficaces pour contrer les attaques de type « pass-the-hash » consistent principalement à rendre les tickets
plus difficiles à voler et à limiter l'impact potentiel d'un ticket volé. L'une de ces mesures consiste à utiliser Windows
Defender Credential Guard de Microsoft. Cette technologie, introduite dans Windows 10 et Windows Server 2016,
exploite la virtualisation pour sécuriser le stockage des informations d'identification et n'autoriser l'accès qu'aux
processus fiables.
Une autre mesure importante consiste à limiter le nombre de terminaux sur lesquels les utilisateurs disposent de
privilèges administratifs. Cela réduit considérablement le risque qu'un pirate utilise un ticket volé pour se déplacer
latéralement. Il est également important d'éviter d'accorder des privilèges administratifs au-delà des limites de
sécurité, car cela réduit considérablement le risque qu'un pirate utilise un ticket volé pour étendre ses privilèges.
Kerberoasting
Le kerberoasting est une technique utilisée pour obtenir les hachages de mots de passe des comptes d'utilisateurs Active
Directory (AD) qui ont des valeurs servicePrincipalName (SPN).
Dans les environnements AD, les SPN sont enregistrés sur des comptes utilisateur ou ordinateur, appelés « comptes de
service ». Ces comptes sont utilisés pour exécuter des services et des applications, et ils se voient généralement attribuer les
privilèges minimaux nécessaires à l'exécution de leur fonction. Lorsqu'un client demande un service à un serveur, il
utilise le SPN pour localiser le compte de service associé au service. Le client s'authentifie ensuite auprès du service à
l'aide des informations d'identification du compte de service, qui sont stockées sous forme de hachage de mot de passe
dans AD.
Dans le cas du Kerberoasting, un attaquant peut exploiter la valeur SPN d'un compte de service pour demander un ticket de
service (TGS). Le ticket TGS peut être chiffré (via RC4) avec le hachage du mot de passe du compte de service attribué au
SPN demandé comme clé. Cela signifie qu'un attaquant qui capture des tickets TGS dans le trafic réseau ou les extrait de la
mémoire peut extraire le hachage du mot de passe du compte de service et effectuer une attaque par force brute hors ligne
pour récupérer le mot de passe en clair.
Le kerberoasting est une méthode qui consiste à obtenir les identifiants d'un compte de service en demandant
des tickets de service à un contrôleur de domaine et en les craquant hors ligne. Elle permet à l'attaquant
d'accéder aux ressources réseau en utilisant le hachage du mot de passe du compte de service. Le Pass-the-
Ticket, quant à lui, est une technique par laquelle un attaquant vole un ticket d'accès Kerberos (TGT) à partir de
la session d'un utilisateur et l'utilise pour usurper l'identité de cet utilisateur afin d'accéder aux ressources
réseau.
Les attaques par kerberoasting peuvent être exécutées à l'aide de divers outils et utilitaires disponibles publiquement, tels
que les scripts Impacket.
Pour cette attaque, on n'utilise pas un seul outil, mais plutôt une combinaison de plusieurs outils, tels que Mimikatz, Rubeus,
Impacket, John the Ripper et Hashcat.
Outil 1 : Impacket
L'attaque Kerberoasting utilisant le script Impacket comprend trois parties principales.
La première étape des attaques Kerberoasting consiste à énumérer (ou identifier) les noms de service principaux (SPN) et
à demander des tickets de service (TGS).
Le script Impacket GetUserSPNs (Python) peut effectuer toutes les étapes nécessaires pour demander un ST pour un
service donné, à condition de disposer de son SPN et d'informations d'identification de domaine valides [24] :
# avec un hachage NT
[Link] -outputfile [Link] -hashes 'LMhash:NThash' -dc-ip
$KeyDistributionCenter 'DOMAINE/UTILISATEUR'
La commande ci-dessus utilise le script [Link] et spécifie un fichier de sortie, « [Link] », dans lequel les
hachages de mot de passe obtenus seront stockés.
Le drapeau -dc-ip permet de spécifier l'adresse IP du contrôleur de domaine et le drapeau -outputfile permet de spécifier
l'emplacement où les hachages de mot de passe obtenus seront enregistrés. Il utilise également l'argument «
DOMAINE/UTILISATEUR:Mot de passe » ou « DOMAINE/UTILISATEUR » pour fournir le domaine, le nom d'utilisateur et
le mot de passe/hachage NT d'un utilisateur de domaine valide afin de demander le ST.
La commande ci-dessus utilise le drapeau --kerberoasting pour spécifier un fichier de sortie dans lequel
enregistrer les hachages de mots de passe obtenus et le drapeau --kdcHost pour spécifier l'adresse IP du
domaine.
Après avoir volé les mots de passe contenus dans le fichier [Link], l'adversaire peut lancer une attaque par
force brute hors ligne afin d'obtenir le mot de passe en clair à l'aide d'outils tiers, tels que John the Ripper et Hashcat.
La commande ci-dessus utilise l'indicateur --format=krb5tgs pour spécifier que les hachages dans le fichier « [Link]
» sont au format Kerberos 5 TGS (Ticket Granting Service) et
--wordlist pour spécifier l'emplacement du fichier de liste de mots à utiliser dans le processus de craquage. Une fois la
commande exécutée, John essaiera de trouver une correspondance entre les hachages de mot de passe et les mots du
fichier de liste de mots.
Une fois le mot de passe piraté, l'attaquant peut utiliser les identifiants du compte de service pour accéder aux ressources
réseau et poursuivre ses objectifs. Cela peut inclure l'exfiltration de données, le déplacement latéral au sein du réseau
ou l'escalade de ses privilèges.
Outil 2 : Rubeus
L'attaque Kerberoasting qui exploite Rubeus comprend quatre étapes principales.
La première étape d'une attaque Kerberoasting consiste à identifier et à énumérer les noms principaux de service (SPN)
des comptes de service ciblés disposant des privilèges souhaités.
Pour cette raison, les adversaires peuvent développer des filtres LDAP personnalisés pour rechercher les utilisateurs dont les
valeurs SPN sont enregistrées pour le domaine actuel [25].
$result_entry | Select-Object @{
Nom = « Nom d'utilisateur » ; Expression = { $_.sAMAccountName }
}, @{
Nom = « SPN » ; Expression = { $_.servicePrincipalName | Select-Object
-First 1 }
}
}
$Résultats
● la classe de service et
● le nom d'hôte.
La classe de service est le nom du service, tel que « HTTP » ou « ldap », et le nom d'hôte est le nom d'hôte DNS ou
l'adresse IP de la machine sur laquelle le service est exécuté. Par exemple, un SPN pour un serveur Web peut être «
HTTP/[Link] », où « HTTP » est la classe de service et « [Link] » est le nom
d'hôte.
Nom SPN
d'utilisateur ---
--------
ServiceAccount1 http/webserver1
ServiceAccount2 cifs/appserver2
Un pirate peut cibler des comptes de service spécifiques en identifiant et en énumérant leurs noms principaux de service
(SPN), puis demander des tickets TGS (Ticket Granting Service) pour ces comptes de service. Des outils tels que Rubeus
peuvent être utilisés pour automatiser ce processus en extrayant les hachages de mots de passe de la mémoire [26].
.\[Link]
$krb5tgs$23$*ServiceAccount1$[Link]$http/webserver1*$45FAD4676AECDDE4C1397BF CED441F79$DEB. . .
L'étape suivante de l'attaque consiste à obtenir les mots de passe en clair des comptes de service. Ce processus est
réalisé à l'aide d'une attaque par force brute hors ligne, ce qui signifie que l'attaquant n'a pas besoin de communiquer
avec l'Active Directory, ce qui le rend indétectable.
Pour effectuer cette tâche, l'attaquant peut utiliser différents outils tels que John the Ripper et Hashcat, qui sont
spécialement conçus pour le craquage de mots de passe à l'aide de dictionnaires de mots de passe courants :
● -m 13100 : cet indicateur est utilisé pour spécifier le type de hachage, dans ce cas Kerberos 5 TGS (Ticket
Granting Service)
● -o [Link] : cet indicateur est utilisé pour spécifier le fichier de sortie dans lequel les mots de
passe piratés seront enregistrés
● -a 0 : cet indicateur est utilisé pour spécifier le mode d'attaque. Dans ce cas, 0 correspond au mode
d'attaque « Straight ».
La commande spécifie également les chemins d'accès aux fichiers [Link] et [Link]. Une fois la
commande exécutée, Hashcat tentera de trouver une correspondance entre les hachages de mots de passe dans le
fichier [Link] et les mots dans le fichier [Link].
Une fois le mot de passe cracké, l'attaquant peut utiliser les identifiants du compte de service pour accéder aux ressources
réseau et atteindre ses objectifs.
Par exemple, en disposant des identifiants du compte, l'adversaire peut utiliser l'outil runas avec le paramètre
Il est possible d'identifier divers signes de Kerberoasting en observant le journal des événements Windows à la
recherche de demandes inhabituelles de service d'octroi de tickets (TGS) [27], [28].
Pour protéger les mots de passe des comptes de service contre les attaques Kerberoasting, plusieurs mesures peuvent
être prises, telles que [29] :
Technique d'atténuation 1 : rejeter les demandes d'authentification qui n'utilisent pas le protocole
FAST (Flexible Authentication Secure Tunneling) de Kerberos
Cette technique est également connue sous le nom de « Kerberos Armoring ». Cette extension de pré-authentification crée un canal
sécurisé entre le client et le contrôleur de domaine, dans le but de renforcer la protection des tickets Kerberos contre les
tentatives de piratage de mot de passe hors ligne. Si la technique FAST permet d'éradiquer la menace posée par le
Kerberoasting, sa mise en œuvre rapide et efficace au sein d'une organisation peut s'avérer difficile.
Bien que la désactivation complète de RC4 soit une tâche importante, il est possible de configurer des comptes de service
individuels pour qu'ils n'acceptent pas le protocole RC4. En définissant l'attribut
msDS-SupportedEncryptionTypes sur 0x18 (décimal 24), seuls AES128 et AES256 seront activés. Cette modification
améliore non seulement la sécurité, mais facilite également la détection des activités malveillantes, car l'utilisation de RC4
dans une requête TGS est un indicateur plus fort.
Technique d'atténuation 3 : adopter des pratiques rigoureuses en matière de mots de passe pour les
comptes de service
Les mots de passe des comptes de service doivent être générés de manière aléatoire, comporter au moins 30 caractères
et être changés fréquemment.
L'attaque Golden Ticket consiste à falsifier un ticket Kerberos afin d'obtenir un accès non autorisé à un système
informatique en tant qu'utilisateur privilégié. Pour mener à bien cette attaque, le pirate doit obtenir le NTHash du
compte krbtgt, le compte chargé de crypter et de signer tous les tickets au sein d'un domaine, ainsi que l'identifiant de
sécurité (SID) du domaine. Grâce à ces informations, l'attaquant peut créer un Golden Ticket frauduleux qui imite un
ticket légitime émis par le serveur d'authentification du domaine. Ce Golden Ticket permet à l'attaquant d'accéder à des
informations et ressources sensibles sur le système ciblé.
Les adversaires peuvent utiliser plusieurs outils tiers tels que Mimikatz et Impacket pour mener une attaque Golden Ticket.
Outil 1 : Impacket
Dans ce scénario, nous supposerons qu'après avoir mené une attaque Kerberoasting, un pirate a vidé un fichier de
hachages et les a crackés afin d'obtenir un accès administrateur au contrôleur de domaine. En d'autres termes, nous
disposons du mot de passe en clair d'un utilisateur administrateur pouvant accéder au contrôleur de domaine. De plus, pour
des raisons d'efficacité, notre nom de domaine sera [Link].
Une attaque Golden Ticket typique avec Impacket comprend deux parties principales.
Pour créer un ticket doré valide, certaines informations sont nécessaires, telles que le NTHash du compte krbtgt du
contrôleur de domaine et le SID du domaine. Ces informations peuvent être obtenues à l'aide du script [Link]
d'Impacket, à condition que l'attaquant dispose d'un accès administrateur au contrôleur de domaine. Vous trouverez ci-
dessous la syntaxe appropriée pour vider le NTHash du compte krbtgt [30].
Ensuite, l'attaquant doit connaître le SID du domaine. Pour cela, il peut utiliser l'outil [Link] d'Impacket. Notez
que même si l'attaquant choisit le contrôleur de domaine comme cible, cette attaque fonctionne avec n'importe
quel contrôleur de domaine.
[Link] [Link]/Administrator:"Password"@<DC_IP_Address>
Enfin, l'attaquant utilise l'outil [Link] d'Impacket pour falsifier un ticket d'or pour un utilisateur du domaine. L'un
des avantages de [Link] est que le ticket falsifié est écrit dans un fichier .ccache plutôt que dans un fichier .kirbi ;
en d'autres termes, l'attaquant n'a pas besoin de le convertir.
Notez que la commande ci-dessus est un exemple d'un attaquant falsifiant un ticket d'or pour une administratrice
de domaine inexistante, Alice.
Pour configurer le ticket doré, la variable d'environnement KRB5CCNAME doit être définie sur le chemin d'accès du fichier
.ccache, qui peut être un chemin d'accès absolu ou relatif. La variable d'environnement KRB5CCNAME est utilisée pour
indiquer aux outils Impacket qui prennent en charge les tickets Kerberos où trouver le ticket. Cela permet à l'attaquant
d'utiliser le ticket doré pour accéder au système en tant qu'utilisateur privilégié [30].
Ensuite, l'adversaire peut utiliser les outils d'exécution de commandes d'Impacket, tels que [Link], [Link] ou
[Link], pour charger et s'authentifier avec le ticket, ce qui lui permet finalement d'exécuter une commande. Pour
que l'authentification Kerberos fonctionne, l'adversaire doit fournir l'adresse IP de la cible, l'adresse IP du contrôleur de
domaine et le nom de domaine.
Notez que tandis que l'option -no-pass indique au script d'ignorer l'authentification par mot de passe, l'option -k
spécifie que le ticket Kerberos doit être récupéré à partir de la variable d'environnement KRB5CCNAME. L'objectif de
ce script est d'exécuter à distance des commandes sur l'ordinateur cible à l'aide de l'authentification Kerberos sans
avoir à saisir de mot de passe.
Outil 2 : Mimikatz
Une attaque Golden Ticket typique avec Impacket comprend trois parties principales.
Comme dans le scénario Impacket, pour qu'une attaque Golden Ticket fonctionne, un adversaire doit disposer d'un accès
administrateur à un contrôleur de domaine. Nous partirons donc de cette hypothèse.
Pour exfiltrer le hachage du mot de passe de l'utilisateur krbtgt, l'attaquant peut utiliser la commande «
lsadump::dcsync ».
Identifiants :
Hachage NTLM : 1b8cee51fd49e55e8c9c9004a4acc159 # Hachage NTLM
. . .
aes256_hmac (4096) : ffa8bd983a5a03618bdf577c2d79a467265f140ba339b89cc0a9c1bfdb4747f5
. .
Notez que « lsadump::dcsync /user:DOMAIN\KRBTGT » est un argument de ligne de commande pour Mimikatz qui lui
indique d'effectuer une opération « DCSync » à l'aide du compte utilisateur « DOMAIN\KRBTGT », qui est le compte par
défaut utilisé par le service d'authentification Kerberos dans les environnements Windows Active Directory [31].
Une fois qu'ils ont obtenu l'accès au hachage du mot de passe KRBTGT, ils peuvent utiliser Mimikatz pour falsifier des tickets
Kerberos. Cela peut impliquer la création d'un faux ticket d'accès (TGT) pour un compte utilisateur inexistant.
Utilisateur : AdministrateurInexistant
Domaine : [Link] (DOMAINE)
SID : S-1-5-21-5840559-2756745051-1363507867
ID utilisateur : 500 ID du
groupe : *513 2668
Clé de service : ffa8bd983a5a03618bdf577c2d79a467265f140ba339b89cc0a9c1bfdb4747f5 - aes256_hmac
-> Ticket : ** Transmettre le ticket **
. . .
Ticket doré pour « NonExistentUser@[Link] » soumis avec succès pour la session en cours
Notez qu'avec l'indicateur /id, l'adversaire a indiqué l'identifiant utilisateur pour lequel il souhaite créer le ticket. Dans ce cas,
l'attaquant transmet la valeur 500 à l'indicateur /id pour créer un compte Administrateur. Le nom du compte utilisateur peut être
n'importe quel nom, comme indiqué dans l'exemple.
L'attaquant peut utiliser le ticket falsifié pour accéder aux ressources intégrées à Kerberos. Le TGT est signé et chiffré
avec le hachage du mot de passe KRBTGT réel, ce qui en fait une preuve d'identité valide aux yeux de tout contrôleur de
domaine. Le contrôleur de domaine émettra alors des tickets TGS (Ticket-Granting Service) basés sur le TGT.
À mesure que l'attaquant obtient davantage d'informations sur l'environnement, il peut utiliser les tickets falsifiés pour
accéder aux applications, bases de données ou autres ressources qui utilisent Active Directory pour l'authentification et
l'autorisation. L'attaquant peut cibler des groupes spécifiques en incluant leur RID dans le processus de falsification des
tickets. Par exemple, il peut découvrir le groupe « MSSQL Administrators » avec le RID correspondant pendant une phase de
découverte, ce qui peut lui donner accès à des bases de données précieuses [31].
Pour se prémunir contre les attaques par Kerberoasting, il est recommandé de prendre des mesures visant à limiter
l'accès des adversaires et à leur compliquer la tâche pour obtenir le hachage du mot de passe de l'utilisateur KRBTGT. Cela peut
être réalisé grâce aux actions suivantes [31], [32] :
Technique d'atténuation 1 : restreindre les privilèges administratifs au-delà des limites de sécurité
Les organisations ne doivent pas autoriser les utilisateurs à disposer de privilèges administratifs au-delà des limites de
sécurité. Par exemple, un pirate qui accède à un poste de travail ne doit pas pouvoir étendre ses privilèges pour cibler le
contrôleur de domaine.
Les comptes de service disposant de privilèges élevés, tels que les administrateurs de domaine, ne doivent être accordés
qu'en cas de nécessité. En limitant le nombre de ces comptes, les organisations peuvent réduire le nombre de cibles pour un
pirate informatique à la recherche du hachage KRBTGT.
Il est important de changer régulièrement le mot de passe de l'utilisateur KRBTGT et immédiatement après tout changement
de personnel responsable de l'administration d'Active Directory. Le mot de passe doit être changé deux fois, avec un
intervalle de 12 à 24 heures entre les deux changements, afin d'éviter toute interruption de service.
Attaque DCShadow
Une attaque DC Shadow consiste à compromettre l'environnement Active Directory en introduisant un contrôleur de
domaine (DC) malveillant dans le réseau, puis en répliquant les modifications apportées par les contrôleurs de domaine
légitimes vers le contrôleur malveillant. L'attaque se déroule en six étapes.
Une attaque DC Shadow est un type d'attaque sur un environnement Active Directory dans lequel un pirate introduit un
contrôleur de domaine (DC) malveillant dans le réseau et y réplique les modifications apportées par les contrôleurs de
domaine légitimes. L'attaquant commence par apporter des modifications à l'environnement, par exemple en ajoutant de
nouveaux objets ou en modifiant ceux qui existent déjà, puis attend que ces modifications soient répliquées sur les
contrôleurs de domaine légitimes. Il enregistre ensuite les noms principaux de service (SPN) du contrôleur de domaine
malveillant et l'enregistre dans l'espace de noms de configuration, ce qui lui permet de s'authentifier et de communiquer
avec d'autres contrôleurs de domaine. L'attaquant déclenche la réplication des modifications qu'il a apportées au
contrôleur de domaine malveillant, qui les réplique, permettant ainsi aux modifications de persister dans l'environnement.
Enfin, l'attaquant supprime les SPN et le contrôleur de domaine malveillant, effaçant ainsi ses traces et laissant
l'environnement dans un état compromis. Ce type d'attaque permet à l'attaquant de persister et de contrôler le réseau en
apportant des modifications qui sont répliquées sur d'autres contrôleurs de domaine.
Les adversaires utilisent souvent Mimikatz comme outil pour mener une attaque DCShadow.
Outil 1 : Mimikatz
Avant d'aller plus loin, nous devons partir du principe que l'attaquant a déjà compromis les identifiants d'un compte Active
Directory disposant de droits d'administration. Supposons que cet utilisateur s'appelle Bob. Cette hypothèse repose sur le
fait qu'un compte administrateur permet à l'adversaire d'apporter des modifications à l'environnement, par exemple en
ajoutant un contrôleur de domaine malveillant et en y répliquant les modifications apportées aux contrôleurs de domaine
légitimes. Sans accès administratif, l'attaquant ne serait pas en mesure de mener à bien son attaque.
La première étape consiste à démarrer le service mimidrv, qui fournit les privilèges nécessaires pour jouer le rôle d'un faux
contrôleur de domaine [33]. Ces commandes initiales (« !+ » et « !ProcessToken ») enregistrent et démarrent un service
appelé « mimidrv » et élèvent les privilèges au niveau SYSTEM.
mimikatz # lsadump::dcshadow
/object:"CN=Alice,OU=Employees,DC=sub,DC=domain,DC=com" /attribute:SidHistory
/value:S-5-1-5-21-2049251289-867822404-1193079966
. . .
** Démarrage du serveur **
Cette commande permet de spécifier le faux serveur pour une attaque DCShadow.
Dans le contexte d'une attaque DCShadow, cette commande est utilisée pour spécifier le faux serveur et cibler l'objet
utilisateur afin de modifier son attribut SidHistory avec la nouvelle valeur spécifiée. L'attribut modifié peut être utilisé
pour accorder à l'attaquant un accès non autorisé au système cible et à des informations sensibles.
Dans un deuxième temps, l'adversaire doit relancer Mimikatz sous le compte « Bob », qu'il a compromis au préalable.
L'adversaire exécute la commande suivante :
La commande lsadump::dcshadow /push est censée effectuer une attaque DCShadow en enregistrant un faux contrôleur
de domaine (shadowDC) et en y transférant les données de réplication. L'objectif de cette attaque est de modifier le
contenu de la base de données Active Directory à l'aide du contrôleur de domaine malveillant. Une fois les données de
réplication validées, le faux contrôleur de domaine est désenregistré à des fins de nettoyage.
Une fois toutes ces opérations effectuées, l'attaquant se déconnecte du compte compromis Bob et se reconnecte pour
obtenir le jeton d'accès mis à jour avec l'historique SID modifié.
La seule façon définitive d'identifier une attaque DCShadow consiste à surveiller le réseau à la recherche de requêtes
RPC (Remote Procedure Call) DRSUAPI pour l'opération DRSUAPI_REPLICA_ADD provenant de systèmes qui ne sont pas
connus pour être des contrôleurs de domaine. Une autre méthode de détection de DCShadow consiste à analyser les
journaux d'événements Windows, mais cette approche ne fournit que des indices de l'attaque et non les modifications
exactes apportées par l'attaquant.
Afin d'imiter un contrôleur de domaine, DCShadow doit apporter des modifications à Active Directory, telles que l'ajout d'un
nouvel objet NTDSDSA et d'un servicePrincipalName de catalogue global (GC/<host>) à un objet ordinateur qui n'est pas
un contrôleur de domaine connu. Une fois l'attaque terminée, ces deux éléments seront supprimés.
En examinant les événements 5136 et 5141 dans la sous-catégorie Audit Directory Service Changes (Audit des
modifications du service d'annuaire) du journal des événements Windows ([35], [36]), vous pouvez rechercher des
preuves de la création et de la suppression d'objets serveur au sein des sites.
L'attaque DCShadow est un type de menace persistante avancée (APT) qui exploite les fonctionnalités et les privilèges
d'Active Directory (AD) pour modifier des données de manière malveillante. Comme il n'est pas possible d'éliminer
complètement le risque lié à cette attaque, il est important d'adopter une approche de sécurité multicouche pour l'atténuer.
Voici quelques suggestions qui peuvent vous aider à réduire le risque d'une attaque DCShadow réussie :
Utilisez des pare-feu basés sur l'hôte pour limiter les mouvements latéraux. Assurez-vous que les protocoles de gestion à
distance tels que RDP ne sont accessibles qu'à partir d'un petit ensemble de systèmes approuvés et surveillés.
Il est essentiel de limiter le nombre d'utilisateurs disposant de privilèges administratifs au-delà des limites de sécurité.
Cela permet de minimiser la possibilité pour un attaquant d'étendre ses privilèges.
Limitez le nombre d'utilisateurs autorisés à ajouter des objets informatiques à Active Directory. Cela permet d'éviter
toute modification non autorisée de l'infrastructure AD.
Gérez de manière adéquate les groupes privilégiés intégrés et les autorisations administratives déléguées afin de
réduire le risque d'abus.
La suppression régulière des sites et des objets informatiques inutilisés permet de maintenir une bonne hygiène Active Directory
et de réduire la surface d'attaque.
En suivant ces stratégies d'atténuation, les organisations peuvent mieux se protéger contre les attaques DCShadow et d'autres types
de menaces persistantes avancées.
AS-REP Roasting
La technique AS-REP Roasting permet aux pirates d'obtenir les hachages de mots de passe des comptes utilisateurs qui ont
désactivé la pré-authentification Kerberos. Cette méthode consiste à transmettre un message AS-REQ (Authentication
Server Request) au contrôleur de domaine (DC). Si la pré-authentification est désactivée, le DC renvoie un message AS-
REP contenant des données cryptées, y compris un segment crypté avec le hachage du mot de passe de l'utilisateur.
L'attaquant peut ensuite utiliser ces informations pour tenter de cracker le mot de passe de l'utilisateur hors ligne.
Dans des circonstances normales, lorsque la pré-authentification est activée, l'utilisateur lance la procédure
d'authentification Kerberos en envoyant un message AS-REQ au contrôleur de domaine. Ce message est crypté avec un
horodatage, qui est ensuite crypté avec le hachage du mot de passe de l'utilisateur. Si le DC parvient à décrypter
l'horodatage à l'aide de son enregistrement stocké du hachage du mot de passe de l'utilisateur, il répondra par un
message AS-REP comprenant un Ticket Granting Ticket (TGT), émis par le Key Distribution Center (KDC). L'utilisateur utilise
ensuite ce TGT pour ses futures demandes d'accès.
Les adversaires peuvent utiliser divers outils tiers pour mener une attaque AS-REP Roasting, tels que Rubeus et Empire,
Kerbrute et Impacket.
Outil : Rubeus
Afin de trouver tous les comptes qui ne nécessitent pas d'authentification préalable et d'extraire leurs hachages AS-REP
pour les cracker hors ligne, un adversaire exécute la commande suivante.
[Link] asreproast
Pour faire avancer l'attaque de quelques étapes, l'attaquant peut exploiter certains paramètres afin d'extraire les données
dans un format pouvant être craqué hors ligne, par exemple avec Hashcat :
Notez que les informations d'identification de hachage sont écrites dans le fichier [Link] du répertoire Temp.
Ensuite, l'adversaire utilise Hashcat, en spécifiant le code de mode de hachage pour les hachages AS-REP (18200),
un fichier de hachage et un dictionnaire à utiliser pour effectuer la recherche par force brute du mot de passe.
Pour mieux comprendre l'attaque AS-REP Roasting et comment elle est réalisée à l'aide d'autres outils, vous pouvez
consulter cette page [37].
La détection des attaques AS-REP Roasting est cruciale pour atténuer le risque de vol de mot de passe. Une façon
de détecter ces attaques consiste à surveiller les modifications apportées au paramètre qui contrôle l'activation de la
préauthentification Kerberos.
Par exemple, au cours d'une telle attaque, l'événement ID 4738 est généré. Cet événement signale une demande de ticket
de service d'authentification Kerberos et comprend des paramètres tels que le type de chiffrement du ticket (0x17), les
options du ticket (0x40800010) et le nom du service (krbtgt). La présence de ces paramètres dans les journaux d'événements
peut indiquer une attaque AS-REP Roasting en cours, car cet événement est produit lorsque l'attaquant manipule des objets
de domaine [38].
● Champs de description clés : ID de sécurité, nom du compte, domaine du compte, ID de connexion, DN, GUID,
classe, nom d'affichage LDAP
Une autre option consiste à surveiller l'ID d'événement 5136, qui fournit des informations sur les modifications apportées
aux comptes d'utilisateurs dans un environnement Windows. En analysant les journaux de cet événement, il est possible
d'identifier tous les comptes d'utilisateurs qui ont eu le paramètre Kerberos
Pré-authentification modifiée.
Le moyen le plus efficace de prévenir les attaques AS-REP Roasting consiste à localiser tous les comptes utilisateurs
configurés sans exiger de pré-authentification Kerberos et à activer ce paramètre. Pour ce faire, vous pouvez utiliser
le script suivant [39] :
Le script utilise la cmdlet Get-ADUser avec un filtre pour rechercher tous les comptes d'utilisateurs, et il spécifie la propriété
« DoesNotRequirePreAuth » dans le paramètre « Properties » pour récupérer les
informations de pré-authentification pour chaque compte.
La sortie de la cmdlet Get-ADUser est ensuite transmise à la cmdlet Where-Object, qui filtre les résultats afin de n'inclure
que les comptes pour lesquels « DoesNotRequirePreAuth » est égal à $True et « Enabled » est égal à $True. Les résultats
filtrés sont ensuite transmis à la cmdlet Select-Object, qui sélectionne les propriétés « SamAccountName » et «
DoesNotRequirePreAuth » pour chaque compte. Enfin, les résultats sélectionnés sont transmis à la cmdlet Sort-Object, qui
trie les résultats en fonction de la propriété « SamAccountName ».
En activant la pré-authentification Kerberos pour ces comptes utilisateurs, cela garantit que le contrôleur de domaine peut
déchiffrer l'horodatage chiffré avec le hachage du mot de passe de l'utilisateur. Il est ainsi beaucoup plus difficile pour
un pirate d'accéder au hachage du mot de passe de l'utilisateur et de mener une attaque de craquage hors ligne.
Pour se prémunir contre les attaques AS-REP Roasting, il est conseillé de mettre en œuvre des politiques de mots de passe
forts, en particulier pour les comptes privilégiés, qui imposent l'utilisation de mots de passe longs et complexes. Il devient
alors difficile pour un pirate de cracker les mots de passe, même s'il parvient à les voler. La mise en œuvre de politiques de
mots de passe fines est une première étape efficace pour garantir la sécurité des mots de passe.
Il est important d'identifier les personnes autorisées à modifier le paramètre de préauthentification, car elles pourraient
le désactiver temporairement afin de voler le hachage AS-REP, puis le réactiver. La requête suivante affiche toutes
les personnes disposant de droits d'accès aux comptes sans préauthentification [40] :
Le code récupère la liste de contrôle d'accès (ACL) du descripteur de sécurité associé à un objet utilisateur spécifique
dans Active Directory (AD).
Il filtre d'abord tous les comptes d'utilisateurs dans AD où la valeur « useraccountcontrol » a le bit décimal 4194304
défini (ce qui correspond au drapeau UF_DONT_REQUIRE_PREAUTH dans l'attribut userAccountControl) et récupère leur
nom distinctif. Il récupère ensuite la liste ACL du descripteur de sécurité du premier compte utilisateur dans le jeu de
résultats à l'aide du nom distinctif et le stocke dans une variable. La dernière ligne de code récupère la propriété
d'accès de la liste ACL et l'affiche. Celle-ci représente les droits d'accès accordés ou refusés aux entités de sécurité
spécifiées dans la liste ACL pour l'objet utilisateur cible.
LDAP, abréviation de Lightweight Directory Access Control Protocol, est un protocole d'application open source utilisé pour
l'authentification des services d'annuaire. En d'autres termes, LDAP se comporte comme une plateforme multiplateforme
qui maintient un langage de communication pour les applications qui communiquent avec d'autres services d'annuaire, qui
stockent des informations sur des objets et partagent ces informations avec d'autres entités du réseau. Il convient de
noter que LDAP et Active Directory ne sont pas identiques ; en fait, LDAP est le langage compris par Microsoft Active
Directory (AD). Ainsi, si vous avez besoin d'accéder à des données stockées sur AD ou de vous authentifier auprès de
celles-ci, vous utilisez LDAP pour communiquer avec le serveur cible.
Une requête LDAP, quant à elle, est la commande qui demande à un service d'annuaire particulier les informations que vous
avez demandées.
Par défaut, en tant que compte valide non privilégié dans AD, vous pouvez utiliser des requêtes LDAP pour obtenir
diverses informations critiques. Par exemple, si vous souhaitez répertorier tous les utilisateurs pour lesquels l'option
« Mot de passe n'expire jamais » est activée, vous devez exécuter la requête LDAP suivante :
(objectcategory=user)(userAccountControl:1.2.840.113556.1.4.803:=65536)
Les attaques par injection LDAP peuvent prendre plusieurs formes, dont certaines sont abordées dans ce texte. Si vous
souhaitez approfondir le sujet et découvrir d'autres types d'attaques par injection LDAP qui ne sont pas mentionnés ici,
veuillez suivre ce lien [41].
Le problème de l'élévation des privilèges fait référence à la situation dans laquelle des utilisateurs disposant d'un faible
niveau de sécurité peuvent accéder à des informations hautement sécurisées. Cela est possible grâce à l'utilisation d'une
injection sous la forme d'un filtre traité par le serveur LDAP.
Par exemple, l'attaquant peut cibler un répertoire contenant des documents à faible niveau de sécurité, tels que «
Informations/Rapports » et « Informations/Projets à venir ».
« Information)(security_level=*))(&(directory=documents"
(&(répertoire=Informations)(niveau_de_sécurité=*))(&(répertoire=Informations) (niveau_de_sécurité=faible))
Comme le serveur LDAP ne traite que le premier filtre, le second filtre est ignoré et la requête exécutée est «
(&(directory=Information)security level=*) ». Cela permet à l'attaquant d'accéder à une liste de documents qui,
autrement, ne serait accessible qu'aux utilisateurs disposant d'un niveau de sécurité élevé, même si l'attaquant ne dispose
pas des privilèges appropriés.
Toutes les pages de connexion contiennent deux champs destinés à la saisie par l'utilisateur, l'un pour le nom d'utilisateur
et l'autre pour le mot de passe. Les champs sont intitulés USER (nom d'utilisateur) et PASSWORD (mot de passe). Le
client fournit un nom d'utilisateur et un mot de passe, et LDAP confirme l'existence de cette paire en créant des filtres de
recherche et en les envoyant au serveur LDAP.
Le filtre est écrit comme suit : (&(USER=Alice)(PASSWORD=PaSsW0rd!+). Cependant, un pirate peut manipuler cela en
entrant un nom d'utilisateur valide et en injectant une séquence après celui-ci, contournant ainsi efficacement la
vérification du mot de passe. En connaissant le nom d'utilisateur, l'attaquant peut entrer n'importe quelle chaîne comme
valeur de mot de passe, ce qui entraîne l'envoi de la requête suivante au serveur :
(&(USER=Alice)(PASSWORD=PaSsW0rd!+)
Le serveur LDAP ne traite que le premier filtre, ignorant le second, ce qui permet à l'attaquant d'entrer dans le système
sans mot de passe valide, car la requête (&(USER=Alice)(&))
e
st toujours correcte.
Un explorateur de ressources permet à un utilisateur de voir quelles ressources sont disponibles sur le système, comme un site
web qui vend des vêtements. Par exemple, un utilisateur peut rechercher un article spécifique, comme des cahiers ou
des autocollants, pour voir s'ils sont disponibles à la vente. Cela se fait à l'aide d'une requête LDAP, telle que :
(|(type=Notebooks)(type=Stickers)).
Cependant, un pirate informatique peut exploiter cette faille en injectant la chaîne « uid=* » dans la requête, ce qui
donne la requête suivante : (|(type=Notebooks)(uid=*))(type=Stickers)).
Cette requête sera traitée par le serveur LDAP, affichant non seulement tous les jeans disponibles, mais également tous les
objets utilisateur du système.
Il existe plusieurs techniques d'atténuation pour prévenir une éventuelle attaque par injection LDAP [42].
Technique d'atténuation 1 : échapper toutes les variables à l'aide du bon encodage LDAP
L'échappement de toutes les variables à l'aide du bon encodage LDAP est l'une des principales techniques d'atténuation contre
les attaques par injection LDAP. Cette technique consiste à encoder toutes les entrées fournies par l'utilisateur de manière à
rendre difficile pour les attaquants l'injection de charges utiles malveillantes dans les requêtes LDAP.
Le protocole LDAP utilise le nom distinctif (DN) pour stocker et identifier les noms dans sa base de données. Un DN agit
comme un identifiant unique, similaire à un nom d'utilisateur, et peut être utilisé pour accéder à des ressources.
Un DN est composé de plusieurs parties, séparées par des virgules. Par exemple, un DN pourrait ressembler à ceci [42] :
Certains caractères d'un DN sont considérés comme des caractères spéciaux et doivent être correctement échappés
ou traités afin d'éviter tout problème avec le DN. La liste exhaustive des caractères spéciaux d'un DN comprend \ # + < >
, ; " = et les espaces en début ou en fin.
Cependant, certains caractères « spéciaux » sont autorisés dans les noms distinctifs et ne nécessitent pas d'échappement. Il
s'agit notamment des caractères * ( ) . & - _ [ ] ` ~ | @ $ % ^ ? : { } ! '.
Il est important de traiter correctement les caractères spéciaux dans un DN afin de garantir que celui-ci fonctionne comme
prévu et d'éviter tout problème ou conséquence imprévue lors de son utilisation.
Dans la base de données LDAP, chaque DN, ou nom distinctif, pointe de manière unique vers une seule entrée, qui peut
être considérée comme une ligne dans un système de gestion de base de données relationnelle (SGBDR). Chaque entrée
contient un ou plusieurs attributs, similaires aux colonnes d'un SGBDR. Les filtres de recherche peuvent être utilisés pour
effectuer des recherches dans la base de données LDAP et trouver des entrées avec des attributs spécifiques.
Les filtres de recherche utilisent la notation polonaise, également appelée notation préfixée, pour spécifier les conditions de
la recherche. Par exemple, le filtre de recherche suivant renverrait toutes les entrées de l'unité organisationnelle Physique
dont le responsable est Freeman Dyson ou Albert Einstein [42].
Lors de la création de requêtes LDAP dans le code d'une application, il est essentiel d'échapper toutes les données non
fiables ajoutées à la requête afin d'éviter tout problème de sécurité. Il existe deux formes d'échappement LDAP : l'encodage
pour la recherche LDAP et l'encodage pour le DN LDAP. La forme d'échappement appropriée dépend de l'utilisation des
données dans un filtre de recherche ou en tant que DN comme identifiant pour accéder à une ressource.
Les caractères spéciaux tels que « ( », « ) » et « » doivent être correctement échappés lorsqu'ils sont utilisés dans
un filtre de recherche afin de garantir que la requête est exécutée comme prévu. Pour en savoir plus sur l'échappement
des filtres de recherche, consultez le document RFC4515 [43].
Défenses supplémentaires
Pour renforcer la protection contre les attaques par injection LDAP, les entreprises peuvent mettre en œuvre les mesures de défense
suivantes :
Privilège minimal : limiter les privilèges attribués au compte de liaison LDAP, qui est le compte utilisé pour accéder au
répertoire LDAP, afin de minimiser les dommages potentiels en cas d'attaque réussie.
Activer l'authentification de liaison : configurez le protocole LDAP pour qu'il exige une authentification de liaison, qui
vérifie et autorise les informations d'identification valides transmises par l'utilisateur [44]. Cependant, les attaquants
peuvent toujours contourner l'authentification de liaison grâce à la liaison anonyme [45] et à la liaison non authentifiée
[46]. Par conséquent, ces options de liaison doivent également être désactivées.
Validation des entrées par liste blanche : mettez en œuvre des techniques de validation des entrées afin de détecter et
d'empêcher les entrées non autorisées d'être transmises à la requête LDAP. Cela permet de garantir que seules les
valeurs approuvées sont utilisées dans la construction des requêtes LDAP, réduisant ainsi le risque d'une attaque par
injection LDAP réussie. Ces techniques de validation peuvent inclure l'utilisation d'expressions régulières, de restrictions
de type de données et de longueur, ainsi que des vérifications croisées par rapport à des listes ou des bases de données
externes [47].
L'attaque par relais NTLM PetitPotam est un type de cyberattaque qui exploite le protocole hérité Windows NTLM et le
protocole MS-EFSRPC. Cette attaque tire parti de la configuration par défaut non sécurisée des services de certificats
Active Directory (AD-CS), qui n'appliquent pas la protection étendue pour l'authentification (EPA).
Dans cette attaque, un pirate peut déclencher une authentification du contrôleur de domaine en exploitant la
vulnérabilité PetitPotam et en la relayant au serveur AD-CS pour demander un certificat pour le compte du contrôleur
de domaine. À l'aide de ce certificat, le pirate peut alors récupérer un TGT (Ticket Granting Ticket) pour le compte du
contrôleur de domaine relayé et effectuer d'autres opérations en utilisant ses privilèges élevés. Cela peut conduire à une
compromission totale du domaine en quelques étapes et permettre potentiellement au pirate de récupérer les hachages
des administrateurs du domaine.
Il est important de noter que cette vulnérabilité a été partiellement corrigée par une mise à jour de sécurité publiée par
Microsoft lors du Patch Tuesday du 10 mai 2022, mais une attaque reste possible si un pirate dispose des identifiants
d'un compte Active Directory.
Technique d'attaque n° 7 : attaque par relais NTLM PetitPotam sur les services de certificats Active Directory (AD CS)
42
Techniques permettant d'effectuer une attaque par relais NTLM PetitPotam
sur les services de certificats Active Directory (AC DC)
Dans le scénario suivant, nous allons montrer comment un adversaire peut exploiter la vulnérabilité PetitPotam pour
obtenir tous les privilèges d'administrateur de domaine sans avoir besoin d'une authentification préalable.
Une attaque par relais NTLM PetitPotam classique comprend cinq étapes [48].
Dans un premier temps, l'attaquant doit s'assurer que [Link] d'Impacket est configuré pour relayer vers la page
d'inscription Web AD DC.
Notez que l'indicateur « --target » spécifie l'URL cible à attaquer. Dans ce cas, la cible est un point de terminaison de
serveur de certificats. Les indicateurs « --adcs » et « --template KerberosAuthentication » indiquent que la cible est un
serveur Active Directory Certificate Services (ADCS) et que l'outil utilisera un modèle d'authentification spécifique. Les
indicateurs « -debug » et « -smb2support » servent respectivement au débogage et à la prise en charge de la version
2 du protocole SMB.
Pour exploiter la vulnérabilité PetitPotam, nous devons tous deux spécifier le DC et l'adresse IP de l'attaquant. [Link] peut
être téléchargé depuis son dépôt GitHub officiel [49].
Notez que si l'adresse IP listener correspond à l'adresse IP relais de l'attaquant, l'adresse IP target correspond à
l'adresse IP du contrôleur de domaine ciblé par l'attaquant. Une fois que l'adversaire a exploité la vulnérabilité
PetitPotam, les informations d'identification sont relayées vers le contrôleur de domaine AD, où le certificat sera
enregistré.
Technique d'attaque n° 7 : attaque par relais NTLM PetitPotam sur les services de certificats Active Directory (AD CS)
43
... #Voir la première étape.
[*] Serveurs démarrés, en attente de connexions
...
[*] CERTIFICAT OBTENU !
Maintenant qu'il est enregistré, l'attaquant peut utiliser ce certificat pour obtenir un Ticket Granting Ticket (TGT). Pour
cette étape, l'attaquant peut utiliser l'outil kekeo ou Rubeus [50] :
Au cours de cette étape, l'attaquant peut utiliser Mimikatz pour lancer une attaque DCSync sur l'utilisateur krbtgt.
Notez qu'avec cette commande, l'attaquant spécifie le domaine à cibler (« [Link] ») et l'utilisateur à usurper («
krbtgt »), qui est un compte privilégié dans Active Directory utilisé pour effectuer diverses tâches administratives,
notamment l'émission de tickets Kerberos.
La fonction « lsadump::dcsync », quant à elle, est utilisée pour mener une attaque « DCSync », qui permet à un pirate de
simuler le comportement d'un contrôleur de domaine et de récupérer des hachages de mots de passe, des tickets
Kerberos et d'autres informations sensibles à partir de la base de données Active Directory. Ainsi, en exécutant cette
commande, l'adversaire obtient le hachage du mot de passe de l'utilisateur krbtgt :
186c026974e59a14040dbc63aa8fb8c4.
Technique d'attaque n° 7 : attaque par relais NTLM PetitPotam sur les services de certificats Active Directory (AD CS)
44
Étape 5 : transmission du hachage
Au cours de cette étape, l'adversaire peut utiliser l'outil [Link] d'Impacket pour transmettre le hachage obtenu à la
cinquième étape afin d'obtenir un shell interactif sur le contrôleur de domaine.
En termes plus simples, ces deux bogues fonctionnent ensemble pour permettre à une personne disposant d'un
accès limité de prendre rapidement le contrôle total d'un réseau ou d'un système. Même si le réseau ou le système
est entièrement mis à jour avec les derniers correctifs de sécurité, ces bogues peuvent toujours être utilisés pour
causer de graves dommages en quelques minutes seulement.
Techniques d'atténuation pour une attaque par relais NTLM PetitPotam sur les
services de certificats Active Directory (AD CS)
Pour sécuriser les réseaux contre les attaques par relais NTLM, les administrateurs de domaine doivent prendre des mesures
pour protéger les services compatibles avec l'authentification NTLM. La menace PetitPotam exploite les serveurs qui ne
disposent pas de protections contre les attaques par relais NTLM dans les services de certificats Active Directory (AD
CS).
Ce guide de mitigation fournit aux clients AD CS des mesures à prendre pour protéger leurs serveurs contre ce type
d'attaque.
Si vous utilisez AD CS avec les services suivants, votre réseau peut être vulnérable :
Microsoft suggère les mesures suivantes pour atténuer les attaques potentielles sur les serveurs AD CS [51] :
Étape 1 : Activez la protection étendue pour l'authentification (EPA) pour l'inscription Web auprès de l'autorité de
certification et le service Web d'inscription de certificats. Cela peut être fait via le Gestionnaire des services Internet (IIS),
l'option « Requis » étant l'option recommandée et la plus sécurisée.
Étape 2 : mettez à jour le fichier [Link] créé par le rôle Service Web d'inscription de certificats, situé dans
<%windir%>\systemdata\CES<CA Name>_CES_Kerberos\[Link], afin de refléter le paramètre EPA sélectionné.
Étape 3 : Pour ce faire, ajoutez <extendedProtectionPolicy> avec une valeur « WhenSupported » ou « Always »,
selon le paramètre EPA dans l'interface utilisateur IIS. Le paramètre « Always » doit être utilisé lorsque le paramètre
EPA est défini sur « Required ».
Étape 4 : Activez les connexions SSL uniquement en activant l'option « Require SSL » dans le Gestionnaire IIS.
Technique d'attaque n° 7 : attaque par relais NTLM PetitPotam sur les services de certificats Active Directory (AD CS)
45
Figure 2. Activation des connexions SSL uniquement dans le Gestionnaire IIS [51] :
Étape 5 : Une fois ces étapes terminées, il est important de redémarrer IIS pour charger les modifications. Pour ce
faire, ouvrez une fenêtre d'invite de commande élevée et tapez la commande suivante :
iisreset /restart
Notez que cette commande arrête tous les services IIS, puis les redémarre.
Pour plus d'informations sur les options disponibles pour <extendedProtectionPolicy>, reportez-vous à la section
<binding name="TransportWithHeaderClientAuth">
<security mode="Transport">
<transport clientCredentialType="Windows">
<extendedProtectionPolicy policyEnforcement="Always" />
</transport>
<message clientCredentialType="None" establishSecurityContext="false"
negotiateServiceCredential="false" />
</security>
<readerQuotas maxStringContentLength="131072" />
</binding>
Technique d'attaque n° 7 : attaque par relais NTLM PetitPotam sur les services de certificats Active Directory (AD CS)
46
Conclusion
En conclusion, la fréquence et la sophistication croissantes des attaques visant Active Directory sont évidentes. Les
attaques courantes abordées dans ce rapport, telles que Pass the Hash, Pass the Ticket, Kerberoasting, Golden
Ticket, DC Shadow, AS-REP Roasting, LDAP Injection et PetitPotam NTLM Relay Attack, illustrent les innombrables
façons dont les adversaires peuvent exploiter les vulnérabilités de l'infrastructure Active Directory d'une
organisation.
Compte tenu du rôle crucial que joue Active Directory dans la régulation de l'accès aux données et ressources
sensibles d'une organisation, il est impératif que les organisations adoptent des mesures proactives pour se
défendre contre ce type d'attaques. Cela nécessite un
une approche multicouche, intégrant des audits de sécurité réguliers, des évaluations de vulnérabilité et une
surveillance continue afin de détecter et de traiter les menaces en temps réel.
Il est essentiel de reconnaître que les attaquants adaptent constamment leurs tactiques, ce qui oblige les
organisations à rester vigilantes et à mettre à jour régulièrement leurs mesures de sécurité afin de garder une
longueur d'avance sur les menaces émergentes. En investissant dans des mesures de sécurité complètes et en
surveillant de près l'évolution du paysage des menaces, les organisations peuvent réduire le risque d'être victimes
d'une attaque Active Directory.
[2] « Active Directory : qu'est-ce que c'est ? Pourquoi est-ce important ? », Intermedia | Intermedia, 10 mars 2022. [En
ligne]. Disponible sur :
[Link] [Consulté le 10 février 2023]
[3] E. B. Abid, « Avantages d'Active Directory (pour et contre) », Cloud Infrastructure Services, 22 août 2021. [En ligne].
Disponible sur :
[Link] [Consulté le 10 février 2023]
[4] « Avantages de Microsoft 365 et Azure Active Directory pour la gestion des identités », Montra Technologies, 22 juin
2022. [En ligne]. Disponible sur :
[Link] agement/. [Consulté le 10 février 2023]
[5] « Rapport DBIR 2022 - Guide du maître », Verizon Business. [En ligne]. Disponible sur :
[Link] [Consulté le 10 février
2023]
[6] « Rapport sur le coût des violations de données 2022 ». [En ligne]. Disponible sur :
[Link] [Consulté le 10 février 2023]
[7] « Comparaison entre Active Directory et Azure Active Directory ». [En ligne]. Disponible sur :
[Link]
[Consulté le 10 février 2023]
[8] A. Robbins, « Comment les pirates passent d'Azure Active Directory à AD sur site », The New Stack, 26 mai 2022. [En
ligne]. Disponible à l'adresse :
[Link]
/. [Consulté le 10 février 2023]
[16] « Détection des mouvements latéraux grâce au suivi des journaux d'événements. » [En ligne]. Disponible :
[Link] [Consulté le : 9 février 2023]
[17]J. Warren, « Comment détecter les attaques Pass-the-Hash » [En ligne]. Disponible sur :
[Link] [Consulté le : 09 février 2023]
[18] « Atténuer les attaques par hachage (PtH) et autres techniques de vol d'identifiants
» [En ligne]. Disponible sur : [Link]
%20Pass-the-Hash%20(PtH)%20Attacks%20and%20Other%20Credential%20Theft%20T echniques_English.pdf. [Consulté le 9
février 2023]
[19] « GitHub - gentilkiwi/kekeo : une petite boîte à outils pour jouer avec Microsoft Kerberos en C », GitHub. [En
ligne]. Disponible sur : [Link] [Consulté le 7 février 2023]
[20] « GitHub - GhostPack/Rubeus : Essayer d'apprivoiser le chien à trois têtes », GitHub. [En ligne]. Disponible :
[Link] [Consulté le : 07 février 2023]
[22] R. Chandel, « A Detailed Guide on Rubeus », Hacking Articles, 11 mai 2022. [En ligne]. Disponible sur :
[Link] [Consulté le 7 février 2023]
[23] JasonGerend, « Kerberos Authentication Overview » (Présentation de l'authentification Kerberos). [En ligne].
Disponible sur : [Link] ation-
overview. [Consulté le 7 février 2023]
[26] « Attack Tutorial: How the Kerberoasting Attack Works », Netwrix. [En ligne]. Disponible sur :
[Link] [Consulté le 13 janvier 2023]
[27] « Astuce Active Directory pour une persistance sournoise ie 18 : Suppression des SPN sur les comptes administrateur
pour un Kerberoasting ultérieur ». [En ligne]. Disponible sur : [Link] [Consulté le 9 février 2023]
[28] S. Metcalf, « Detecting Kerberoasting Activity », Active Directory Security, 5 février 2017. [En ligne]. Disponible sur :
[Link] [Consulté le 9 février 2023]
[30] K. Mistele, « Impacket Deep Dives Vol. 2 : Attacking Kerberos - Kyle Mistele », Medium, 5 juin 2021. [En ligne].
Disponible sur :
[Link] dd472a. [Consulté le 8
février 2023]
[32] « Golden ticket attacks: How they work — and how to defend against them
», Quest. [En ligne]. Disponible à l'adresse :
[Link] st-them/. [Consulté le 9 février
2023]
[34] « DCShadow Attack using Mimikatz », Netwrix. [En ligne]. Disponible sur :
[Link] [Consulté le 8 février 2023]
[35] « 5136(S) : un objet du service d'annuaire a été modifié », Microsoft. [En ligne]. Disponible :
[Link]
6. [Consulté le 10 février 2023]
[36] « Détection des mouvements latéraux grâce au suivi des journaux d'événements
». [En ligne]. Disponible sur : [Link] [Consulté le 10 février 2023]
[38] A. Berlin, « How To Detect AS-REP Roasting With », Blumira, 7 décembre 2021. [En ligne]. Disponible sur :
[Link] [Consulté le 8 février 2023]
[40] J. Dibley, « Cracking Active Directory Passwords with AS-REP Roasting » [En ligne]. Disponible sur :
[Link] [Consulté le 8 février 2023]
[41]A. Dizdar, « Complete Guide to LDAP Injection: Types, Examples, and Prevention », Bright Security, 2 juin 2021. [En
ligne]. Disponible sur : [Link] [Consulté le 9 février 2023]
[42] « Prévention des injections LDAP - Série de fiches pratiques OWASP ». [En ligne]. Disponible à l'adresse :
[Link]
.html. [Consulté le 9 février 2023]
[44] « The LDAP Bind Operation », [Link], 27 avril 2018. [En ligne]. Disponible sur :
[Link] [Consulté le 9 février 2023]
[45] « 3.4 - La liaison anonyme sur le serveur LDAP doit être désactivée. » [En ligne]. Disponible :
[Link]
udit:8bc4cb19c1fe0abfc3edcf804e7603f0. [Consulté le 9 février 2023]
[46] M.-A. Moreau, « Pourquoi les liaisons non authentifiées LDAP Active Directory doivent être désactivées, et comment
procéder », blog Devolutions. [En ligne]. Disponible sur : [Link]
ldap-unauthenticated-binds-s hould-be-disabled-and-how-to-do-it/. [Consulté le 09 février 2023]
[47] « Validation des entrées - Série de fiches pratiques OWASP ». [En ligne]. Disponible sur :
[Link] [Consulté le 9 février 2023]
[48] « De l'inconnu à l'administrateur de domaine // Utilisation de PetitPotam pour relayer NTLM vers l'administrateur de domaine »,
Truesec. [En ligne]. Disponible sur :
[Link] [Consulté le 09
février 2023]
[49] « GitHub - topotam/PetitPotam : outil PoC permettant de contraindre les hôtes Windows à s'authentifier auprès
d'autres machines via MS-EFSRPC EfsRpcOpenFileRaw ou d'autres fonctions », GitHub. [En ligne]. Disponible sur :
[Link] [Consulté le 9 février 2023]
[50] PetitPotam | Attaques par relais NTLM | AD CS | Mimikatz | Rubeus | Prise de contrôle de domaine. (29 juillet 2021)
[En ligne]. Disponible sur : [Link]
[Consulté le 9 février 2023]
[51] « KB5005413 : Atténuation des attaques par relais NTLM sur les services de certificats Active Directory (AD CS) ». [En
ligne]. Disponible :
[Link]
services-ad-cs-3612b773-4043-4aa9-b23d-b87910cd3429. [Consulté le : 09 février 2023]
En tant que pionniers de la simulation de violations et d'attaques (BAS), notre plateforme complète
de validation des contrôles de sécurité est utilisée par les équipes de sécurité du monde entier
pour identifier de manière proactive les failles de sécurité et obtenir des informations
exploitables pour y remédier.
[Link]
picussecurity