optiv/scarecrowScareCrow - Framework de création de payloads conçu autour du contournement d'EDR.
Pour consulter la dernière version de ScareCrow ou soumettre un problème, référez-vous à https://github.com/Tylous/ScareCrow.
Si vous souhaitez en savoir plus sur les techniques utilisées dans ce framework, veuillez consulter Partie 1 et Partie 2
ScareCrow est un framework de création de payloads pour le chargement latéral (pas d'injection) dans un processus Windows légitime (contournant les contrôles de liste blanche d'applications). Une fois le chargeur DLL chargé en mémoire, il utilise une technique pour éliminer le hook d'un EDR des DLL système s'exécutant dans la mémoire du processus. Cela fonctionne car nous savons que les hooks des EDR sont placés lorsqu'un processus est créé.
ScareCrow peut cibler ces DLL et les manipuler en mémoire en utilisant la fonction API VirtualProtect, qui modifie les permissions d'une section de la mémoire d'un processus vers une valeur différente, notamment de Exécuter-Lire à Lire-Écrire-Exécuter.
ScareCrow utilise l'une des 2 méthodes pour retirer les hooks
Lorsqu'il est exécuté, ScareCrow copie les octets des DLL système stockées sur le disque dans C:\Windows\System32\. Ces DLL sont stockées sur le disque « propres », sans hooks des EDR, car elles sont utilisées par le système pour charger une copie non altérée dans un nouveau processus lorsqu'il est créé. Comme les EDR ne hookent ces processus qu'en mémoire, elles restent inchangées. ScareCrow ne copie pas l'intégralité du fichier DLL, mais se concentre uniquement sur la section .text des DLL. Cette section d'une DLL contient l'assembly exécutable, et ce faisant, ScareCrow réduit la probabilité de détection, car la relecture de fichiers entiers peut amener un EDR à détecter une modification d'une ressource système. Les données sont ensuite copiées dans la bonne région mémoire en utilisant le décalage (offset) de chaque fonction. Chaque fonction possède un décalage qui indique le nombre exact d'octets à partir de l'adresse de base où elle réside, fournissant ainsi l'emplacement de la fonction sur la pile.
Pour ce faire, ScareCrow modifie les permissions de la région mémoire .text à l'aide de VirtualProtect. Même s'il s'agit d'une DLL système, comme elle a été chargée dans notre processus (que nous contrôlons), nous pouvons modifier les permissions mémoire sans nécessiter de privilèges élevés.
ScareCrow charge le shellcode en mémoire en déchiffrant d'abord le shellcode, qui est chiffré par l'une des trois méthodes de chiffrement (décrites ci-dessous). Une fois déchiffré et chargé, le shellcode est ensuite exécuté. Selon les options du chargeur spécifiées, ScareCrow mettra en place différentes fonctions d'export pour la DLL. La DLL chargée ne contient pas non plus la fonction DLLMain standard que toutes les DLL doivent normalement posséder pour fonctionner. La DLL s'exécutera néanmoins sans problème car le processus dans lequel nous chargeons recherchera ces fonctions d'export et ne se souciera pas de la présence de DLLMain.
Après
KnownDLLs est une liste de DLL chargées par Windows lors du démarrage du système. Comme ces DLL sont considérées comme essentielles au fonctionnement du système d'exploitation, elles sont mises en cache pour réduire les temps de chargement et améliorer les performances au démarrage des applications. KnownDLLs inclut des DLL telles que kernel32.dll, kernelbase.dll et ntdll.dll.
En utilisant ces KnownDLLs, ScareCrow mappe une copie de la DLL depuis \KnownDlls\<nomdll> en utilisant une combinaison de NtOpenSection et NtMapViewOfSection pour la charger dans la mémoire du processus. ScareCrow ne charge pas l'intégralité de la DLL, mais seulement la section .text de celle-ci (car elle contient tous les appels système). Ensuite, ScareCrow utilise des appels système indirects pour appeler NtProtectVirtualMemory et modifier les permissions de la section mémoire .text de la DLL, permettant ainsi à ScareCrow d'écraser les hooks de l'EDR avant de restaurer les permissions.
Pour plus d'informations, vous pouvez lire l'article détaillé de modexp ici
Une fois ces hooks supprimés, ScareCrow utilise alors des appels système personnalisés pour charger et exécuter le shellcode en mémoire. ScareCrow fait cela même après la suppression des hooks de l'EDR pour éviter la détection par des outils de collecte de télémétrie non basés sur l'espace utilisateur, tels que le suivi d'événements pour Windows (ETW) ou d'autres mécanismes de journalisation d'événements. Ces appels système personnalisés sont également utilisés pour effectuer l'appel VirtualProtect afin de supprimer les hooks placés par les EDR, comme décrit ci-dessus, et ainsi éviter la détection par les contrôles anti-altération des EDR. Cela se fait en appelant une version personnalisée de l'appel système VirtualProtect, NtProtectVirtualMemory. ScareCrow utilise Golang pour générer ces chargeurs, puis l'assembleur pour ces fonctions d'appel système personnalisées.
Lors du processus de création du chargeur, ScareCrow utilise une bibliothèque pour se fondre dans l'arrière-plan après qu'un beacon ait contacté le serveur. Cette bibliothèque fait deux choses :
Les fichiers signés avec des certificats de signature de code sont souvent moins scrutés, ce qui facilite leur exécution sans être contestés, car les fichiers signés par un nom de confiance sont généralement moins suspects que d'autres. La plupart des produits antimalware n'ont pas le temps de valider et vérifier ces certificats (certains le font maintenant, mais généralement les noms de fournisseurs courants sont inclus dans une liste blanche). ScareCrow crée ces certificats en utilisant une version en package Go de l'outil limelighter pour créer un fichier pfx12. Ce package prend un nom de domaine saisi par l'utilisateur pour créer un certificat de signature de code pour ce domaine. Si nécessaire, vous pouvez également utiliser votre propre certificat de signature de code si vous en possédez un, en utilisant l'option de ligne de commande valid.
clone, ainsi que le chemin vers le fichier dont vous souhaitez copier le certificat. Lors de la signature du chargeur avec microsoft.com, leur utilisation contre les produits WINDOWS DEFENDER ATP peut ne pas être aussi efficace, car ils peuvent valider le certificat comme leur appartenant. Si vous utilisez un chargeur contre un produit Windows, utilisez éventuellement un domaine différent.