optiv/freeze.rsFreeze.rs est une boîte à outils de payloads pour contourner les EDR en utilisant des processus suspendus et des appels système directs écrits en RUST.
Pour voir la dernière version de Freeze.rs ou soumettre un problème, référez-vous à https://github.com/Tylous/Freeze.rs.
Si vous souhaitez en savoir plus sur les techniques utilisées dans ce framework, veuillez consulter le Blog SourceZero et l'outil original.
Freeze.rs est un outil de création de payload utilisé pour contourner les contrôles de sécurité EDR afin d'exécuter du shellcode de manière furtive. Freeze.rs utilise plusieurs techniques non seulement pour supprimer les hooks EDR en espace utilisateur, mais aussi pour exécuter le shellcode d'une manière qui contourne d'autres contrôles de surveillance des endpoints.
Lorsqu'un processus est créé, Ntdll.dll est la première DLL chargée ; cela se produit avant que les DLL EDR ne soient chargées. Cela signifie qu'il y a un léger délai avant qu'un EDR puisse être chargé et commencer à hooker et modifier l'assembly des DLL système. En examinant les appels système Windows dans Ntdll.dll, nous pouvons voir que rien n'est encore hooké. Si nous créons un processus dans un état suspendu (gelé dans le temps), nous pouvons voir qu'aucune autre DLL n'est chargée, à l'exception de Ntdll.dll. Vous pouvez également voir qu'aucune DLL EDR n'est chargée, ce qui signifie que les appels système situés dans Ntdll.dll ne sont pas modifiés.
Pour utiliser ce processus suspendu propre afin de supprimer les hooks du loader Freeze.rs, nous avons besoin d'un moyen de trouver et lire programmatiquement la mémoire du processus suspendu propre. C'est là qu'intervient la randomisation de l'espace d'adressage (ASLR). ASLR est un mécanisme de sécurité visant à prévenir les vulnérabilités basées sur la corruption de la mémoire de la pile. ASLR randomise l'espace d'adressage à l'intérieur d'un processus, afin de garantir que tous les objets mappés en mémoire, la pile, le tas et le programme exécutable lui-même, sont uniques. Maintenant, c'est là que cela devient intéressant car bien que l'ASLR fonctionne, il ne fonctionne pas pour le code indépendant de la position tel que les DLL. Ce qui se passe avec les DLL (en particulier les DLL système connues), c'est que l'espace d'adressage est randomisé une fois au démarrage. Cela signifie que nous n'avons pas besoin d'énumérer les informations d'un processus distant pour trouver l'adresse de base de sa ntdll.dll car elle est la même dans tous les processus, y compris celui que nous contrôlons. Puisque l'adresse de chaque DLL est au même endroit par démarrage, nous pouvons extraire ces informations de notre propre processus sans jamais avoir à énumérer le processus suspendu pour trouver l'adresse.
Avec ces informations, nous pouvons utiliser l'API ReadProcessMemory pour lire la mémoire d'un processus. Cet appel API est couramment associé à la lecture de LSASS dans le cadre d'attaques basées sur les identifiants ; cependant, en soi, il n'est pas intrinsèquement malveillant, surtout si nous lisons simplement une section arbitraire de la mémoire. La seule fois où ReadProcessMemory sera signalé comme suspect, c'est si vous lisez quelque chose que vous ne devriez pas (comme le contenu de LSASS). Les produits EDR ne devraient jamais signaler le fait que ReadProcessMemory a été appelé, car il existe des utilisations opérationnelles légitimes pour cette fonction, ce qui entraînerait de nombreux faux positifs.
Nous pouvons aller plus loin en ne lisant qu'une section de Ntdll.dll où tous les appels système sont stockés - sa section .text, plutôt que de lire l'intégralité de la DLL.
En combinant ces éléments, nous pouvons obtenir programmatiquement une copie de la section .text de Ntdll.dll pour écraser notre section .text hookée existante avant d'exécuter le shellcode.
ETW utilise des appels système intégrés pour générer cette télémétrie. Comme ETW est également une fonctionnalité native intégrée à Windows, les produits de sécurité n'ont pas besoin de "hooker" les appels système ETW pour accéder aux informations. Par conséquent, pour empêcher ETW, Freeze.rs corrige de nombreux appels système ETW, vidant les registres et renvoyant le flux d'exécution à l'instruction suivante. La correction d'ETW est maintenant par défaut dans tous les chargeurs.
Puisque seule Ntdll.dll est restaurée, tous les appels ultérieurs pour exécuter le shellcode doivent résider dans Ntdll.dll. En utilisant la crate NTAPI de Rust (notez que vous pouvez le faire dans d'autres langages, mais en Rust, c'est assez simple à implémenter), nous pouvons définir et appeler les appels système NT nécessaires pour allouer, écrire et protéger le shellcode, contournant ainsi efficacement les appels standard situés dans Kernel32.dll et Kernelbase.dll, car ceux-ci peuvent encore être hookés.
Avec la crate NTAPI de Rust, vous pouvez voir que tous ces appels n'apparaissent pas sous ntdll.dll, mais ils existent toujours dans le processus.
En conséquence :
Ce projet a commencé comme un projet amusant pour apprendre Rust et a grandi pour devenir son propre framework.
Freeze.rs a été développé en Rust.
Si Rust et Rustup ne sont pas installés, veuillez les installer. Si vous compilez depuis OSX ou Linux, assurez-vous d'avoir ajouté la cible "x86_64-pc-windows-gnu". Pour cela, exécutez la commande suivante :
rustup target add x86_64-pc-windows-gnu
Une fois cela fait, vous pouvez compiler Freeze.rs, exécuter les commandes suivantes, ou utiliser le binaire compilé :
cargo build --release
Ensuite, la version compilée se trouvera dans target/release (notez que si vous ne mettez pas --release, le fichier sera dans target/debug/ )
___________
\_ _____/______ ____ ____ ________ ____ _______ ______
| __) \_ __ \_/ __ \_/ __ \\___ // __ \ \_ __ \/ ___/
| \ | | \/\ ___/\ ___/ / /\ ___/ | | \/\___ \
\___ / |__| \___ >\___ >_____ \\___ > /\ |__| /____ >
\/ \/ \/ \/ \/ \/ \/
(@Tyl0us)
Soon they will learn that revenge is a dish... best served COLD & Rusty...
USAGE:
Freeze-rs [FLAGS] [OPTIONS]
FLAGS:
-c, --console Uniquement pour les payloads binaires - Génère des informations console détaillées lors de l'exécution du payload. Cela désactivera la fonctionnalité de fenêtre cachée
-h, --help Affiche les informations d'aide
-n, --noetw Désactive la correction d'ETW qui empêche la génération d'événements ETW.
-s, --sandbox Active l'évasion de sandbox en vérifiant : L'Endpoint est-il joint à un domaine ? L'Endpoint a-t-il plus de 2 CPU ? L'Endpoint a-t-il plus de 4 Go de RAM ?
-V, --version Affiche les informations de version
OPTIONS:
-E, --Encrypt <ENCRYPT> Chiffre le shellcode en utilisant le chiffrement AES 256, ELZMA ou RC4
-I, --Input <INPUT> Chemin vers le shellcode brut 64 bits.
-O, --Output <OUTPUT> Nom du fichier de sortie (par exemple loader.exe ou loader.dll). Selon l'extension de fichier définie, Freeze déterminera s'il crée une dll ou un exe.
-p, --process <PROCESS> Le nom du processus à créer. Ce processus doit exister dans C:\Windows\System32\. Exemple 'notepad.exe'
-e, --export <export> Définit un nom de fonction d'exportation personnalisé pour toute DLL.
Freeze.rs peut générer soit un fichier .exe soit .dll. Pour le spécifier, assurez-vous que l'option de ligne de commande -O se termine par .exe pour les binaires ou .dll pour les dlls. Aucun autre type de fichier n'est actuellement pris en charge. Dans le cas des fichiers DLL, Freeze.rs peut également ajouter des fonctionnalités d'exportation supplémentaires. Pour ce faire, utilisez -export avec un nom de fonction d'exportation spécifique.
Le chiffrement du shellcode est une technique importante utilisée pour le protéger contre la détection et l'analyse par les EDR et autres produits de sécurité. Freeze.rs propose plusieurs méthodes pour chiffrer le shellcode, notamment AES, ELZMA et RC4.
AES (Advanced Encryption Standard) est un algorithme de chiffrement symétrique largement utilisé pour chiffrer des données. Freeze.rs utilise une taille de clé AES-256 bits pour chiffrer le shellcode. L'avantage d'utiliser AES pour chiffrer le shellcode est qu'il fournit un chiffrement fort et est largement pris en charge par les bibliothèques cryptographiques. Cependant, l'utilisation d'une taille de bloc fixe peut le rendre vulnérable à certaines attaques, comme l'attaque par oracle de padding.
ELZMA est un algorithme de compression et de chiffrement souvent utilisé dans les malwares pour obscurcir le code. Pour chiffrer le shellcode avec ELZMA, le shellcode est d'abord compressé à l'aide de l'algorithme ELZMA. Les données compressées sont ensuite chiffrées à l'aide d'une clé aléatoire. Les données chiffrées et la clé sont ensuite intégrées dans le code d'exploitation. L'avantage d'utiliser ELZMA pour chiffrer le shellcode est qu'il fournit à la fois compression et chiffrement dans un seul algorithme. Cela peut aider à réduire la taille du code d'exploitation et le rendre plus difficile à détecter.
RC4 est un algorithme de chiffrement symétrique souvent utilisé dans les malwares pour chiffrer le shellcode. C'est un chiffrement par flux qui peut utiliser des clés de longueur variable et est connu pour sa simplicité et sa rapidité.
Freeze.rs utilise une technique pour d'abord créer le processus puis le déplacer en arrière-plan. Cela fait deux choses : d'abord, cela aide à garder le processus caché, et ensuite, cela évite d'être détecté par tout produit EDR. Créer un processus directement en arrière-plan peut être très suspect et un indicateur de malveillance. Freeze.rs fait cela en appelant les fonctions Windows ‘GetConsoleWindow’ et ‘ShowWindow’ après la création du processus et le chargement des hooks de l'EDR, puis modifie les attributs de la fenêtre pour la masquer.
Si l'option de ligne de commande -console est sélectionnée, Freeze.rs ne cachera pas le processus en arrière-plan. Au lieu de cela, Freeze.rs ajoutera plusieurs messages de débogage affichant ce que le chargeur fait.