(Enfin ?) Comprendre les vecteurs d’attaques Active Directory, un guide des vulnérabilités et configurations dangereuses : Partie II

Cet article est la suite de la première partie, vous pouvez la lire ici : Partie I

Nous reprenons donc notre exploration des vulnérabilités et configurations dangereuses liées aux infrastructure Active Directory, avec cette fois-ci un petit focus sur le protocole Kerberos !

Vecteur IV : Pre2K

En des temps immémoriaux (l’an 2000), la première version d’Active Directory voyait le jour, et un des grands défis de cette nouvelle solution était notamment de réussir à intégrer les ordinateurs tournant sur des versions antérieures à Windows 2000 au sein des différents services.

Ces systèmes, que l’on qualifie de Pre-Windows 2000 (Pre2K), possèdaient évidemment des standards d’authentification différents de ce qui a pu se faire par la suite. Pour garantir cette rétro-compabilité et s’assurer que les comptes machines qui allait être associés à ces ordinateurs Pre2K puissent facilement s’authentifier sur le réseau, une option a été proposée à chaque création de nouveau compte machine

Cocher cette case permet ainsi d’assurer la compatibilité pour des systèmes antérieurs à Windows 2000, mais au prix d’un paramètre de sécurité aujourd’hui essentiel : la sécurité des mots de passe. En effet, un compte machine assigné à un système Pre2K se verra donné au moment de sa création un mot de passe basé sur son nom d’ordinateur (qui sera automatiquement changé au moment de la première authentification sur le réseau).

Cela signifie qu’un compte machine Pre2K jamais utilisé possède un mot de passe égal à son nom, ce qui présente évidemment un immense risque pour sa sécurité (un attaquant ayant décelé la nomenclature générale des machines dans un domaine cherchera à deviner des noms de comptes machines en espérant tomber sur desPre2Kjamais utilisés et en prendre le contrôle ou en changer les mots de passe). Compromettre un compte machine peut ensuite permettre d’exécuter d’autres attaques exploitant les fonctionnalités AD réservés aux ordinateurs et compromettre le domaine si d’autres configurations dangereuses le permettent.

De nombreux outils et scripts permettent d’énumérer les comptes machines Pre2K, mais ce one-liner powershell donne une première vision du nombre de ces comptes présents dans le domaine :

Get-ADComputer -Filter {UserAccountControl -band 4128} -Properties UserAccountControl

Le filtre se fait au niveau de l’attribut UserAccountControl qui est égal à 4128 pour les comptes Pre2K, ce qui représente la somme des flags PASSWD_NOTREQD (32) et WORKSTATION_TRUST_ACCOUNT (4096)

Si les noms de ces comptes ne vous disent rien par rapport à votre infra, il faut ensuite vérifier la date de dernière modification de mot de passe pour s’assurer que ces comptes aient bien été un jour associés à des ordinateurs utilisés dans le domaine (et qu’ils ne disposent plus du mot de passe par défaut).

Vecteur V : AS_REP Roasting

Voici un deuxième vecteur d’attaque facilement détectable permettant la plupart du temps de prendre rapidement le contrôle d’un compte utilisateur :

Lors d’une authentification Kerberos (un des 2 protocoles d’authentification utilisé par Active Directory), un compte voulant accéder à un service va effectuer un échange d’informations en tout genre avec le contrôleur de domaine puis avec le compte portant le dit service, dans le but d’obtenir des tickets d’authentification selon la séquence suivante :

Source : https://narekkay.fr/posts/kerberos-protocol-explained-animated/

On remarquera l’étape KRB_AS_REQ qui consiste en l’envoi d’une demande de pré-authentification (qui contient le nom du compte requêteur, ainsi que l’heure de la demande, chiffrés avec le condensat de mot de passe du compte requêteur).

Un condensat de mot de passe, également appelé hash, est un résultat d’un algorithme non réversible qui transforme un mot de passe en une chaîne de caractères unique et fixe. L’utilisation de hash permet d’éviter le stockage ou la transmission de mot de passe en clair.

Le contrôleur de domaine connaissant le nom ainsi que le hash du compte requêteur, il peut ainsi déchiffrer le timestamp et valider la pré-authentification. Le contrôleur peut ainsi répondre en envoyant un premier ticket (appelé TGT pour Ticket-Granting-Ticket) accompagné d’une clé de session Kerberos, elle aussi chiffrée avec le hash du compte requêteur (c’est le KRB_AS_REP)

Cette étape de pré-authentification est donc essentielle pour garantir la sécurité des comptes lors d’une authentification Kerberos.

L’AS_REP Roasting consiste en une demande de TGT pour un compte ne nécessitant pas de pré-authentification. N’ayant pas besoin de déchiffrer de demande de ticket préalable pour valider une authentification, le contrôleur de domaine va ainsi répondre avec un TGT à n’importe quelle requête pour le compte sans pré-authentification, peu importe qui est à l’origine de la requête.

Le message de réponse KRB_AS_REP contenant des informations chiffrées avec le hash du compte pour lequel le ticket est demandé , il est possible d’en craquer le mot de passe s’il est suffisament faible. Un compte sans pré-authentification représente donc un danger.

L’attribut spécifiant la désactivation de la pré-authentification Kerberos se situe directement dans les propriétés de chaque utilisateur :

Il est également possible de détecter rapidement les comptes ne nécessitant pas de pré-authentification en Powershell :

Get-Aduser -filter * -pr DoesNotRequirePreAuth | Where-Object {($_.DoesNotRequirePreAuth -eq $true) -and ($_.Enabled -eq $true)} | Select-Object samaccountname

Vecteur VI : Kerberoasting

Cousin du vecteur précédent, le Kerberoasting repose sur la suite du fonctionnement de Kerberos :

Source : https://narekkay.fr/posts/kerberos-protocol-explained-animated/

Une fois son TGTrécupéré, le compte requêteur peut ensuite demander un ST (pour Service Ticket, ou Ticket de Service en français) afin de pouvoir accéder au service qu’il désire. Pour demander ce ST, il va envoyer :

– son TGT précédement récupéré
– L’identifiant du service auquel il veut accéder (ou SPN pour Service Principal Name, composé du nom spécifique du service ainsi que de l’hôte qui le porte)
– Un authenticator (composé du nom du compte requêteur + l’heure de la demande, chiffrés à l’aide de la clé de session Kerberos générée lors de la création du TGT).

Le contrôleur de domaine ayant lui-même généré la clé de session Kerberos, il peut déchiffrer l'authenticator pour voir si son contenu correspond à celui duTGT (qui contenait aussi le nom du compte requêteur et l’heure de la demande). Si les 2 coïncident, alors le contrôleur de domaine répond avec un Service Ticket.

Ce ticket de service est chiffré avec le hash du compte qui fait tourner le service en question. Et c’est là que le Kerberoasting intervient. En effet, un attaquant en possession d’un compte valable dans le domaine peut effectuer une demande de TGT, puis de ST dans le but de craquer ce dernier et d’en récupérer le mot de passe du compte qui porte le service. Comme pour l’AS_REP Roasting, si le mot de passe du compte est suffisamment faible, ce dernier tombera et le compte qui porte le service s’en retrouve compromis.

Ce vecteur d’attaque ne repose pas sur le fait que des comptes portent des services (l’intérêt principal de l’AD étant de pouvoir justement fédérer des services et de les rendre accessibles facilement), car il faut bien qu’un compte soit utilisé pour démarrer un service spécifique. En revanche, 2 questions permettent de déterminer si un compte utilisé pour un service présente un risque de sécurité :

– S’agit-il d’un compte utilisateur ? Si oui, alors son mot de passe est géré par un humain qui peut commettre l’erreur de lui donner un mot de passe trop faible. La meilleure pratique reste d’utiliser des comptes de service dont les mots de passe sont créés automatiquement par l’AD avec rotation automatique, comme les comptes sMSA ou gMSA. Et non, il ne suffit pas de créer un compte utilisateur et de lui donner un nom qui commence par svc pour en faire un compte de service adéquat 😄

– Quelles sont ses permissions et ses appartenances de groupe ? Dans le cadre d’une cyberattaque, un attaquant peut être amené à compromettre des comptes portant des services, ce qui ne garantit pas la compromission systématique du domaine. Si le service tourne en revanche avec des permissions élevées, alors le Kerberoasting peut être fatal.

Le one-liner powershell suivant permet de détecter tous les comptes utilisateurs disposant d’un Service Principal Name :

Get-ADUser -filter * -pr ServicePrincipalNames | Where-Object {($_.ServicePrincipalNames -like "*") -and ($_.samaccountname -notlike "krbtgt")}

Exemple de mauvaise pratique, le compte Administrateur de domaine built-in fait tourner un service. Un attaquant pourrait requêter un ST pour ce service et tenter de casser le mot de passe du compte Administrateur