optiv/dentUn framework pour créer des contournements basés sur COM en exploitant des vulnérabilités dans les capteurs WDAPT de Microsoft.
Pour voir la dernière version de Dent ou soumettre un problème, consultez https://github.com/Tylous/Dent.
Dent
Si vous souhaitez en savoir plus sur les techniques utilisées dans ce framework, veuillez consulter cet article.
Ce framework génère du code pour exploiter des vulnérabilités dans les règles de réduction de la surface d'attaque (ASR) de Microsoft Defender Advanced Threat Protection afin d'exécuter du shellcode sans être détecté ou empêché. L'ASR a été conçu pour être la première ligne de défense, détectant les événements basés sur des actions qui violent un ensemble de règles. Ces règles se concentrent sur des indicateurs de comportement spécifiques sur le terminal, souvent associés aux tactiques, techniques ou procédures (TTP) d'un attaquant. Elles accordent une grande importance à la suite Microsoft Office, car il s'agit d'un vecteur d'attaque courant pour établir un pied-à-terre distant sur un terminal. Une grande partie des contrôles basés sur les règles se concentrent sur les indicateurs de comportement réseau ou processus qui se démarquent des opérations commerciales normales. Ces règles ciblent soit la compromission initiale d'un système, soit une technique pouvant gravement impacter une organisation (par exemple, divulgation d'identifiants ou ransomware). Elles couvrent une grande partie de la surface d'attaque courante et visent à entraver les techniques connues utilisées pour compromettre des actifs.
Dent tire parti de plusieurs vulnérabilités pour contourner ces contrôles restrictifs et exécuter des charges utiles sur un terminal sans être bloqué ou efficacement détecté par les capteurs de Microsoft Defender Advanced Threat Protection. L'article ci-dessus décrit ces vulnérabilités qui sont TOUJOURS présentes dans Microsoft Defender Advanced Threat Protection même après la divulgation.
La première étape, comme toujours, est de cloner le dépôt, puis de le construire
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
"Appelez quelqu'un un héros assez longtemps, et il le croira. Il le deviendra.
Ils n'ont pas le choix. Laissez-les vous appeler un monstre, et vous devenez un monstre."
Utilisation de ./Dent :
-C string
Nom de l'objet COM.
-N string
Nom de la charge utile XLL lorsqu'elle est écrite sur le disque.
-O string
Nom du fichier de sortie. (par défaut "output.txt")
-P string
Chemin de la DLL pour votre objet COM. (Utilisez \\ ou des guillemets autour du chemin)
-U string
URL où la charge utile XLL encodée en base64 est hébergée.
-show
Afficher le script dans le terminal.
Ce framework est destiné à exploiter les vulnérabilités et les déficiences de Microsoft Defender Advanced Threat Protection, donc il ne génère pas réellement de charges utiles/implants. Pour les générer, vous pouvez utiliser un grand nombre d'outils disponibles publiquement, cependant toutes les recherches, le développement et les tests ont été effectués avec ScareCrow. Microsoft Defender Advanced Threat Protection ne repose pas sur le hooking en espace utilisateur pour la télémétrie, mais utilise plutôt divers autres mécanismes tels que les callbacks du noyau. D'après les tests, ce framework fonctionne extrêmement bien pour contourner Microsoft Defender Advanced Threat Protection et exécuter du shellcode.
Au moment de la sortie, il existe actuellement deux techniques. J'ajouterai constamment différentes techniques qui exploitent ces vulnérabilités de différentes manières périodiquement, alors restez à l'écoute.
Les objets COM sont souvent créés lorsqu'une application est installée sur un système. Une fois créés, n'importe quelle application ou script peut les appeler, mais ce n'est pas la seule façon de les créer. En modifiant/créant des clés de registre dans la section HKEY_CLASSES_ROOT du registre Windows, nous pouvons créer un objet COM qui pointe vers notre shellcode sur le système. Cela signifie que toute application ou script capable d'utiliser COM peut l'appeler, exécutant ainsi le shellcode.
Cela fonctionne grâce au fonctionnement de l'API CoCreateInstance. CoCreateInstance est utilisée pour créer et initialiser des objets COM basés sur le CLSID (un identifiant global unique utilisé pour identifier une classe d'objet COM spécifique). Cette fonction extrait les informations nécessaires à l'exécution de l'appel en utilisant les valeurs stockées dans les clés de registre. Ces valeurs CLSID se trouvent dans le chemin HKEY_CLASSES_ROOT\CLSID\ du registre. Cependant, avant qu'un processus puisse appeler le CLSID, il doit connaître sa valeur. Cela se fait en effectuant d'abord une requête de registre pour rechercher l'objet COM dans HKEY_CLASSES_ROOT\<nom de l'objet COM>, et s'il existe, une deuxième requête de registre sera effectuée pour obtenir la valeur CLSID stockée dans le sous-dossier.
Une inspection plus approfondie des sous-dossiers du registre montre que les permissions pour les valeurs CLSID ne sont pas cohérentes. Une grande majorité des objets COM stockés ici n'autorisent que la permission "Contrôle total" au Trusted Installer. Le Trusted Installer est un compte de service qui possède des ressources pour les protéger, même des administrateurs. Cela vise à garantir que même si un attaquant obtient des privilèges administratifs, les ressources ne peuvent pas être manipulées malicieusement. Malheureusement, de nombreux objets COM permettent à quiconque dans le groupe Administrateurs la permission "Contrôle total". De plus, la clé racine CLSID accorde au groupe Administrateurs les permissions "Contrôle total" plutôt qu'à NT AUTHORITY\System ou Trusted Installer. De ce fait, sous un contexte élevé, nous pouvons créer ou même modifier les valeurs d'objets COM spécifiques.
Important
La création de ces clés de registre ne fonctionne que si vous les exécutez dans un contexte élevé. Double-cliquer dessus via une interface graphique n'exécutera pas le fichier .VBS dans un contexte élevé, même si vous êtes administrateur. Il est recommandé de l'exécuter depuis une invite de commandes administrative. Cependant, une fois les clés créées, n'importe quelle application peut appeler cet objet COM dans n'importe quel contexte.
Pour utiliser une charge utile ScareCrow avec ce type de contournement, vous pouvez exécuter la commande suivante :
./ScareCrow -I <chemin vers votre shellcode brut sans stade> -domain <nom de domaine> -Loader dll
Une fois que vous avez votre charge utile, utilisez le drapeau -N pour le nom de la charge utile lorsqu'elle est écrite sur le disque, le drapeau -C pour le nom de l'objet COM, le drapeau -I pour l'emplacement où l'écrire, et enfin le drapeau -O pour le fichier de sortie qui stockera le contenu.
Cette option génère un bloc de code pour contourner plusieurs règles ASR afin de télécharger, écrire sur le disque, charger et exécuter du shellcode, contournant ainsi les contrôles préventifs de l'ASR. Cela se fait en utilisant l'objet COM Excel.Application qui représente l'ensemble de l'application Excel, mais sous une forme automatisée, et permet une interaction programmatique avec celle-ci. Comme il s'agit toujours d'Excel, cela ne déclenche pas la règle ASR. En effet, lorsque nous appelons Excel.Application, nous pouvons constater qu'il se lance sous un processus Service Host (Svchost.exe) et non sous le processus WinWord.exe. Bien que Svchost.exe soit un processus système utilisé pour héberger plusieurs services Windows, le processus enfant créé (Excel.exe) n'a pas obtenu de privilèges système.
Parce que nous avons créé un objet COM qui était une application entière, le processus Excel a été créé sous Svchost.exe afin d'être géré correctement pour éviter toute instabilité au processus WinWord.exe. Bien que ce processus soit sous Svchost.exe, il y a un autre défi à relever : exécuter le shellcode. Comme l'exécution binaire ou l'utilisation de WinAPI dans une macro déclencherait d'autres règles ASR, cela limite ce que nous pouvons faire sans déclencher une règle ASR ou être détecté par le composant EDR de WDATP. C'est là que les DLL excellent. Si une charge utile basée sur DLL est compilée avec les bonnes fonctions d'exportation, elle peut être utilisée comme un plugin Office qui, une fois chargé, exécutera automatiquement le shellcode. Pour ce faire, nous pouvons utiliser la fonction RegisterXLL d'Excel. La fonction RegisterXLL charge un plugin XLL en mémoire, l'enregistre et l'exécute automatiquement. Les fichiers XLL sont essentiellement des DLL basées sur Excel.
Pour obtenir le contenu sur le système, nous pouvons utiliser un autre objet COM (Microsoft.XMLHTTP), ce qui permet d'exécuter une requête HTTP, dans ce cas une requête HTTP GET vers une URL. Le deuxième objet COM (ADODB.stream) offre la capacité de lire/écrire des octets d'un flux de données. En combinant les deux objets COM, un attaquant peut demander une ressource distante via une requête HTTP GET et écrire la réponse (dans ce cas, le fichier lui-même) sur le disque. Cela se fait en utilisant à nouveau l'objet COM (ADODB.stream) pour gérer la lecture/écriture des octets du flux de données. Le deuxième objet COM (Microsoft.XMLDOM) permet la lecture des données stockées dans un fichier. L'objet XMLDOM permet de définir le type de données (dans ce cas, base64) et une fois ouvert et stocké dans une chaîne avec le bon type de données, l'objet ADODB.stream peut écrire la chaîne de code sur le disque en utilisant un type de données différent (dans ce cas, BinaryStreamType), convertissant ainsi la chaîne base64 en forme binaire.
Pour utiliser une charge utile ScareCrow avec ce type de contournement, vous pouvez exécuter la commande suivante :
./ScareCrow -I <chemin vers votre shellcode brut sans stade> -domain <nom de domaine> -Loader excel -O <nom du fichier de sortie>
Une fois généré, copiez les lignes 13 et 14 du fichier de sortie, et fusionnez-les en supprimant :
var <nom de variable>; à la fin de chaque ligne
Une fois que vous avez votre charge utile encodée, utilisez le drapeau -N pour le nom de la charge utile lorsqu'elle est écrite sur le disque, le drapeau -U pour l'URL où la charge utile encodée sera hébergée (par exemple https:///), et le drapeau -F pour le nom du fichier hébergé par le site. Le code généré est conçu pour fonctionner dans un document macro.
Grâce à des investigations plus approfondies, il a été observé qu'il ne s'agit pas d'une lacune des capteurs de WDATP, mais plutôt que WDATP a bien une visibilité sur cette activité, mais qu'elle est ignorée. À travers la chronologie des événements du terminal WDATP à la recherche de toute référence à Appwiz.xll, nous avons observé que WDATP a enregistré un événement "fichier créé" lorsque Word a créé le fichier AppWiz.xll. Il est important de noter que les fichiers .XLL sont exécutables.
20/11/2020 - Développement de la recherche et rédaction de l'article.
14/03/2021 - Remise à Microsoft d'un document de divulgation préliminaire décrivant les problèmes identifiés.
31/03/2021 - Microsoft a reconnu et confirmé que les vulnérabilités liées à la création d'un processus enfant Office et à l'écriture de fichiers sur le disque étaient de véritables vulnérabilités et a commencé à travailler sur des correctifs. Cependant, les incohérences de permissions dans le registre ont été jugées non vulnérables en raison de l'exigence de privilèges élevés.
21/04/2021 - Microsoft a informé l'auteur que la version de signature 1.333.1055.0 publiée le 22/03/2021 et la version 1.335.1321.0 publiée le 21/04/2021 contenaient la détection des vulnérabilités basées sur les applications Office et a clôturé le dossier.
22/04/2021 - L'auteur a retesté les mêmes techniques, constatant que les vulnérabilités étaient toujours présentes.