L'ADCS est un élément au centre d'énormément d'attaques, car il permet, lorsqu'un de ses éléments est mal configuré, d'augmenter ses privilèges, et d'obtenir les privilèges d'administrateurs du domaine. Maintenant que nous avons accès aux logs, nous pouvons tester différentes attaques pour étudier les logs associés. Ces différentes attaques sont appelées ESCXX où le X correspond à un nombre, permettant de les différencier. Cette nomenclature a été proposée par l’entreprise Specter Ops dans son article Certified Pre-Owned et le Whitepaper associé, puis reprise par la communauté lors de la découverte de nouveaux vecteurs d’attaque.

‍

ESC1

Création du modèle vulnérable pour les tests

‍

Nous allons créer un modèle de certificat vulnérable. Pour cela, sur le serveur ADCS, dans l'applicatif "certsrv", effectuer un clic droit sur le dossier "Modèle de certificats" ouvrira un menu, où il faudra sélectionner "Gérer" :

‍

‍

‍

Cette action va ouvrir le menu de gestion des modèles de certificat. Pour gagner du temps, on va dupliquer le modèle "Utilisateur" en effectuant un clic droit sur ce dernier, puis en sélectionnant "Dupliquer le modèle".

‍

‍

‍

Dans l'onglet Général, nous allons appeler le modèle de certificat "TEST-ESC1", et dans le "Nom du sujet", il faudra remplacer "Construire à partir de ces informations Active Directory" par "Fournir dans la demande", puis valider.

‍

‍

‍

Lorsque l'option "Fournir dans la demande" est cochée, il est possible de préciser, lors de la demande de certificat basée sur ce modèle, des informations qui ne sont pas forcément conformes avec celles de l'Active Directory, ou du moins qui ne correspondent pas à notre utilisateur courant. Par exemple, on peut arbitrairement indiquer un nom d'utilisateur (UPN), pour usurper l'identité de quelqu'un d'autre. C’est le cœur de l’attaque ESC1.

Pour ajouter le nouveau modèle à l'autorité de certification, il faut effectuer un clic droit dans le menu "Modèles de certificats", et choisir successivement "Nouveau", puis "Modèle de certificat à délivrer" :

‍

Et on va ajouter le modèle que nous venons de créer :

‍

‍

Il devrait désormais apparaître dans la liste des modèles

‍

‍

Exploitation

On va utiliser l'outil de Lyak appelé Certipy : https://github.com/ly4k/Certipy

‍

‍

‍

Pour commencer, le modèle nous est bien présenté comme vulnérable à l'ESC1 car:

• Le modèle est disponible (Enabled = True)

• Il est possible de s'authentifier avec un certificat de ce type (Client authentication = True)

• Il est possible de préciser des informations sur le certificat que l'on veut obtenir (Enrolee Supplies Object = True)

• Un groupe non privilégié peut demander un certificat (Ici, Utilisateurs du domaine)

‍

Ainsi, on peut voir que l'on peut demander un certificat en précisant un User Principal Name / UPN, ici avec le compte Administrateur :

‍

‍

‍

On a bien reçu les deux certificats au format pfx, pour le compte misty qui a fait la requête, mais aussi et surtout pour le compte Administrateur. Il est alors possible de s'authentifier avec ces derniers, pour compromettre les comptes associés :

‍

‍

Si le modèle n'est pas vulnérable à l'ESC1, le certificat généré ne prendra pas en compte l’UPN fourni :

‍

Détection

L'événement 4887 du journal Security correspond à l'émission validée d'un certificat. L'événement 4888 quant à lui correspond au refus de la demande d'un certificat. On peut voir qu'il y a dans le log le champ UPN que l'on a précisé (upn=Administrateur), le template associé (CertificateTemplate:User), et le compte qui a effectué la demande (misty) :

‍

‍

Ici, le champ UPN que l'on a précisé (upn=Administrateur), le template associé (CertificateTemplate:TEST-ESC1), et le compte qui a effectué la demande (misty) :

‍

‍

On pourra donc détecter les tentatives d'ESC1 en utilisant les filtres suivants :

• Event ID [4887 ou 4888]

• UPN != Demandeur (ici Administrateur != misty)

Enfin, pour ne pas laisser notre environnement vulnérable, on peut supprimer le modèle de certificat :

‍

‍

‍

ESC3

Création du modèle vulnérable pour les tests

De la même façon, on va aller plus vite en dupliquant le modèle utilisateur :

‍

‍

En nouveau nom, on va choisir "TEST-ESC3" :

‍

‍

Dans l'onglet "Extensions", il faudra modifier la "Stratégies d'application" pour ajouter l'option "Agent de demande de certificat" :

‍

C’est ce paramètre qui rendra ce modèle de certificat vulnérable à l’attaque ESC3.

Ensuite, pour l'ajouter à l'autorité de certification, il faut effectuer un clic droit dans le menu "Modèles de certificats", et choisir successivement "Nouveau", puis "Modèle de certificat à délivrer" :

‍

‍

Et on va ajouter le modèle que nous venons de créer :

‍

‍

Exploitation

En relançant l'énumération des informations des certificats

Nous obtenons les résultats suivants :

‍

‍

Pour commencer, le modèle nous est bien présenté comme vulnérable à l'ESC3 car:

• Le modèle est disponible (Enabled = True)

• Il est possible de préciser d'utiliser le certificat pour en demander un autre (Extended Key Usage contient Certificate Request Agent)

• Il faut que l'on puisse demander un certificat sans avoir besoin qu'il soit validé par la console de l'ADCS (Requires Manager Approval = False)

• Un groupe non privilégié peut demander un certificat (Ici, Utilisateurs du domaine)

‍

Ainsi, on va demander deux certificats. Le premier en demandant un certificat basé sur le modèle vulnérable à l'ESC3 :

Ensuite, on va demander un nouveau certificat permettant l'authentification cliente (par exemple, le modèle par défaut User) en précisant le compte que l'on veut usurper avec l'argument « on-behalf-of » en utilisant le certificat que l'on vient d'obtenir :

‍

Encore une fois, il est possible de s'authentifier avec le certificat que l'on vient d'obtenir pour le compte Administrateur et donc de compromettre le compte.

‍

Si lors de la demande du certificat, l'erreur "CERTSRV_E_SUBJECT_EMAIL_REQUIRED" apparaît, cela signifie que l'adresse e-mail du compte n'est pas disponible. Il faudra alors soit l'ajouter dans les propriétés du compte, dans l'applicatif "Utilisateurs et Ordinateurs Active Directory" sur un des contrôleurs du domaine :

‍

‍

Soit, dans l'onglet "Nom du sujet", il est possible de décocher les deux options indiquant qu'il faut inclure le compte de messagerie dans le certificat :

‍

‍

Détection

Cette fois-ci, on peut voir que le champs "Sujet", contenant le Disinguished Name du compte « Administrateur », ne correspond pas au champs "Demandeur", ici « KANTO\misty ».

‍

Dans le cas de l'Event ID 4888 (refus de la demande), il ne contient malheureusement pas assez d'informations pour vérifier si l'exploitation a été tentée.

‍

‍

‍

On pourra donc détecter les tentatives d'ESC3 en utilisant les filtres suivants :

• Event ID [4887]

• Sujet != Demandeur (ici Administrateur != misty)

‍

Nous verrons d'autres typologie d'attaques dans un prochain article.

‍