Auteur/autrice : psiracusa

Microsoft offre nativement tout un tas de technologies autour de la protection du kernel car c’est par lui que passe nécessairement bon nombre d’attaques de type ransomware.

En effet afin de briser les défenses les attaquants ont besoin de désactiver (ou de rendre aveugle) les solutions de sécurité de type antivirus et EDR, et l’unique moyen d’y arriver est de se placer à un niveau d’exécution plus élevé, dans l’espace kernel.

Ci-joint un petit support de présentation que j’ai compilé (en anglais), il recense des technologies internes à Windows pour lutter contre ces attaques kernel de type BYOVD (Bring Your Own Vunerable Driver), on y retrouve bon nombre d’acronymes comme SMEP, HVCI, KASRL, KCFG, KCET, etc

A noter que certaines de ces fonctionnalités de protection kernel ne sont pas activées par défaut…

J’essaierai d’accompagner ces slides d’une vidéo commentée (voir de labs) car ce sujet est complexe et quasi inabordable pour ceux n’ayant jamais touché aux Windows Internals, aux drivers, à l’assembleur et aux techniques de bypass comme les ROP.

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 ?