Compromission d’un Active Directory à partir de modèles de certificats vulnérables

J’ai souvent noté que les audits portant sur la sécurité de l’Active Directory faisaient l’impasse sur le service de certificats.

Or il suffit d’un seul modèle de certificat mal configuré pour pouvoir usurper l’identité de n’importe compte du domaine et potentiellement compromettre l’Active Directory !

En réalité rien de nouveau depuis la Blackhat de 2021 « Certified Pre-Owned: Abusing Active Directory Certificate Services » (https://specterops.io/wp-content/uploads/sites/3/2022/06/Certified_Pre-Owned.pdf) mais malheureusement force est de constater que le message n’est pas bien passé.

Alors pour les gens pressés, comment faire pour compromettre l’AD avec des certificats ?

Il faut d’abord lister les modèles de certificat vulnérables, prenez par exemple l’outil Certify (https://github.com/GhostPack/Certify) qui va vous lister tous vos modèles de certificat vulnérables :

Certify.exe find /vulnerable [/ca:SERVER\ca-name | /domain:domain.local | /path:CN=Configuration,DC=domain,DC=local] [/quiet]

Ensuite il vous faut repérer les templates vulnérables, c’est à dire ceux réunissant les 3 conditions suivantes :

pkiextendedkeyusage             : Client Authentication
msPKI-Certificates-Name-Flag    : ENROLLEE_SUPPLIES_SUBJECT
Enrollment Rights               : NT AUTHORITY\Authenticated Users

En somme il faut rechercher les templates accessibles à tout utilisateur permettant de réaliser de l’authentification client et autorisant la fourniture d’un SAN (sujet alternatif, un autre compte que vous-même).

Une fois les templates repérés il n’y a plus qu’à demander un certificat pour le compte d’une tierce personne, au hasard un domain admin :=)

Certify.exe request /ca:dc.theshire.local\theshire-DC-CA /template:VulnTemplate /altname:localadmin

Une fois la clé privée et le certificat obtenu, convertissez les en PFX (PKCS12) avec openssl :

openssl pkcs12 -in cert.pem -inkey key.pem -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx

Muni de votre certificat cert.pfx l’étape suivante consiste à demander un ticket Kerberos TGT pour l’utilisateur victime (c’est le nom du compte dans le SAN du certificat) et d’injecter ce TGT dans votre propre processus LSASS :

Rubeus.exe asktgt /user:victim /certificate:C:\Temp\cert.pfx /password:password

Vous pouvez vérifier la présence de ce ticket TGT avec la commande klist

Et voila, vous pouvez maintenant utiliser vos nouveaux droits sur le domaine, simple non ?

Alors j’ai passé sous silence quelques points comme le bypass des outils de sécurité locaux, antivirus , d’EDR, etc mais là n’était pas le sujet.

Je trouve cette technique incroyablement simple et efficace, pas la peine de se fatiguer à casser des mots de passe sur du Kerberoasting par exemple, l’authentification par certificat rend le pentest AD tellement plus facile.