optiv/ivyIvy est un framework de création de payloads pour l'exécution de code source VBA (macro) arbitraire directement en mémoire. Le loader d'Ivy y parvient en utilisant un accès programmatique dans l'environnement objet VBA pour charger, déchiffrer et exécuter du shellcode.
Pour voir la dernière version d'Ivy ou soumettre un problème, référez-vous à https://github.com/Tylous/Ivy.
Si vous souhaitez en savoir plus sur les techniques utilisées dans ce framework ainsi que sur les mesures défensives pour s'en protéger, veuillez consulter l'Article.
Ivy est un framework de création de payloads pour l'exécution de code source VBA (macro) arbitraire en mémoire. Le loader d'Ivy y parvient en abusant de l'accès programmatique dans l'environnement objet VBA pour charger, déchiffrer et exécuter du shellcode. Cette technique est aussi proche que possible d'être véritablement sans fichier, car la plupart des attaques sans fichier de nos jours nécessitent un certain type de fichiers déposés sur le disque, contournant ainsi les règles standard basées sur les signatures pour détecter le code VBA. Les payloads VBA typiques ont les caractéristiques suivantes :
En s'exécutant purement en mémoire, ces caractéristiques de comportement rendent plus difficile la détection par les EDR.
Les loaders d'Ivy sont chiffrés avec le chiffrement RC4 (le chiffrement AES provoque beaucoup de gonflement et prend des siècles à déchiffrer en VBA) puis divisés en chaînes séparées, empêchant tout sandbox de reconnaître ces chaînes comme des chaînes chiffrées qui devraient être inspectées. Cela empêche également tout mécanisme de décodage de reconnaître ces payloads comme autre chose que des caractères indésirables.
Le loader d'Ivy effectue d'abord une requête de registre pour activer « Trust access to the VBA project object mode ». Cette valeur de clé de registre est stockée en mode utilisateur, ce qui permet à l'utilisateur de modifier la valeur sans nécessiter de permissions élevées. La valeur du registre est mise de zéro à 1 ; si la clé de registre n'existe pas, Ivy la créera avec une valeur de « 1 ». Avec cette valeur activée, l'accès programmatique à l'environnement objet VBA est autorisé depuis un autre processus.
Une fois cela fait, le loader génère alors un processus Excel caché et charge les chaînes chiffrées dans une fonction VBA. Cela est fait en utilisant ActiveX pour simuler les actions GUI de la même tâche. Cela aide à contourner de nombreux contrôles traditionnels en place pour surveiller l'exécution. En conséquence, la fonction de déchiffrement et le shellcode sont déplacés d'un tampon mémoire à un autre, sans jamais toucher le disque. Enfin, le loader utilise des appels de commande GUI et exécute la fonction run, qui simule l'action de cliquer sur le bouton d'exécution de macro dans le panneau GUI de VBA, démarrant la fonction de déchiffrement, suivie de l'exécution réelle du shellcode.
IMPORTANT
Le point d'extrémité cible doit avoir Microsoft Office installé et activé pour fonctionner car Ivy dépend d'un abus de l'accès programmatique à l'environnement VBA de Microsoft Office.
Cela permet à Ivy d'utiliser des appels système de bas niveau pour construire sa propre version de la fonction Windows WriteProcessMemory en référençant l'adresse mémoire directe et les valeurs des registres indirectement. Ivy peut écraser des sections de mémoire qui ne sont pas inscriptibles sans appeler aucune des fonctions API de modification mémoire. Cela est dû à une caractéristique de WriteProcessMemory qui modifie temporairement les permissions de la région mémoire en écriture (si vous avez suffisamment de privilèges, ce qui est le cas puisque nous possédons le processus). Il écrit la valeur et restaure les permissions originales sans appeler la fonction VirtualProtect, mais en appelant automatiquement le syscall associé (NtProtectVirtualMemory).
Ivy n'utilise pas sa propre version de NtWriteVirtualMemory car ce processus de modification temporaire des permissions mémoire ne se produirait pas, ce qui signifie que la protection de l'adresse mémoire spécifique ne serait pas modifiée et l'exécution échouerait. C'est une « fonctionnalité » que Microsoft a publiée pour rendre les débogueurs plus stables. Étant donné que les débogueurs veulent modifier la mémoire à la volée, ils peuvent simplement modifier une section sans avoir à effectuer plusieurs tâches. (Voir devblogs.microsoft.com pour plus d'informations)
Examinons la série d'événements qu'un EDR verrait :
Une fois que tous les hooks de l'EDR ont été supprimés, le loader effectue alors son action normale pour établir une session distante.
Ivy adresse cela en désaccrochant les DLL système communes que l'EDR accroche, cela inclut :
Lors de l'utilisation de unhook avec un type de payload Inject, le loader d'Ivy désaccrochera d'abord le processus Office en retirant l'EDR de celui-ci, puis supprimera les hooks dans le processus injecté. Cela garantit que les deux processus sont libres de hooks, empêchant toute télémétrie du processus parent et enfant d'être envoyée à l'EDR.
En utilisant la même technique pour désaccrocher, Ivy peut corriger les fonctions ETW, empêchant tout événement d'être généré par le processus. ETW utilise des syscalls intégrés pour générer cette télémétrie. Comme ETW est une fonctionnalité native de Windows, les produits de sécurité n'ont pas besoin de « hooker » les syscalls ETW pour obtenir les informations. En conséquence, pour empêcher ETW, Ivy corrige de nombreux syscalls 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 loaders, si vous ne souhaitez pas corriger ETW, utilisez l'option de ligne de commande -noetw pour la désactiver dans votre loader.
Ivy a été développé avec Go.
La première étape comme toujours est de cloner le dépôt. Avant de compiler Ivy, vous devrez installer les dépendances. Pour les installer, exécutez les commandes suivantes :
go get github.com/fatih/color
go get github.com/KyleBanks/XOREncryption/Go
Ensuite, compilez-le
go build Ivy.go
$ ./Ivy -h