thewover/donutGénère du shellcode indépendant de la position pour x86, x64 ou AMD64+x86 qui charge des assemblies .NET, des fichiers PE et d'autres charges utiles Windows depuis la mémoire et les exécute avec des paramètres.
Version actuelle : v1.1
Donut est un code indépendant de la position qui permet l'exécution en mémoire de fichiers VBScript, JScript, EXE, DLL et d'assemblies dotNET. Un module créé par Donut peut soit être chargé depuis un serveur HTTP, soit être intégré directement dans le chargeur lui-même. Le module est éventuellement chiffré à l'aide du chiffrement par blocs Chaskey et d'une clé générée aléatoirement de 128 bits. Une fois le fichier chargé et exécuté en mémoire, la référence originale est effacée pour dissuader les scanners mémoire. Le générateur et le chargeur prennent en charge les fonctionnalités suivantes :
Il existe des bibliothèques dynamiques et statiques pour Linux et Windows qui peuvent être intégrées dans vos propres projets. Il existe également un module Python que vous pouvez découvrir plus en détail dans la documentation sur la construction et l'utilisation de l'extension Python.
Donut contient des chargeurs individuels pour chaque type de fichier pris en charge. Pour les assemblies dotNET EXE/DLL, Donut utilise l'API Unmanaged CLR Hosting pour charger le Common Language Runtime. Une fois le CLR chargé dans le processus hôte, un nouveau domaine d'application est créé pour permettre l'exécution d'assemblies dans des AppDomains jetables. Lorsque l'AppDomain est prêt, l'assembly dotNET est chargé via la méthode AppDomain.Load_3. Enfin, le point d'entrée des EXE ou la méthode publique des DLL spécifiée par l'utilisateur est invoqué avec les paramètres supplémentaires. Référez-vous à MSDN pour la documentation sur l'API Unmanaged CLR Hosting. Pour un exemple autonome d'un hôte CLR, consultez le code ici.
Les fichiers VBScript et JScript sont exécutés à l'aide de l'interface IActiveScript. Il existe également un support minimal pour certaines des méthodes fournies par le Windows Script Host (wscript/cscript). Pour un exemple autonome, consultez le code ici. Pour une description plus détaillée, lisez : Exécution en mémoire de JavaScript, VBScript, JScript et XSL
Les fichiers EXE/DLL non managés ou natifs sont exécutés à l'aide d'un chargeur PE personnalisé avec prise en charge des importations différées, du TLS et de la correction de la ligne de commande. Seuls les fichiers avec des informations de relogement sont pris en charge. Lisez Exécution en mémoire de DLL pour plus d'informations.
Le chargeur peut désactiver AMSI et WLDP pour aider à échapper à la détection de fichiers malveillants exécutés en mémoire. Pour plus d'informations, lisez Comment les équipes rouges contournent AMSI et WLDP pour le code dynamique .NET. Il prend également en charge la décompression de fichiers en mémoire à l'aide d'aPLib ou de l'API RtlDecompressBuffer. Lisez Compression de données pour plus d'informations.
À partir de la v1.0, ETW est également contourné. Comme pour AMSI/WLDP, il s'agit d'un système modulaire qui vous permet de remplacer le contournement par défaut par le vôtre. Le contournement par défaut est dérivé des recherches de XPN. Lisez Cacher votre .NET - ETW pour plus d'informations.
Par défaut, le chargeur écrase les en-têtes PE des PE non managés (de l'adresse de base à `IMAGE_OPTIONAL_HEADER.SizeOfHeaders`). Si aucun module leurre n'est utilisé (surcharge de module), les en-têtes PE seront mis à zéro. Si un module leurre est utilisé, les en-têtes PE du module leurre seront utilisés pour écraser ceux du module de charge utile. Cela vise à dissuader la détection en comparant les en-têtes PE des modules en mémoire avec le fichier qui les supporte sur le disque. L'utilisateur peut demander que tous les en-têtes PE soient conservés dans leur état d'origine. Ceci est utile dans les scénarios où le module de charge utile doit accéder à ses en-têtes PE, par exemple lors de la recherche de ressources PE intégrées.
Pour une présentation détaillée de l'utilisation du générateur et de l'impact de Donut sur les méthodes opérationnelles, lisez Donut - Injecter des assemblies .NET en tant que shellcode. Pour plus d'informations sur le chargeur, lisez Chargement d'assemblies .NET depuis la mémoire.
Ceux qui souhaitent en savoir plus sur les aspects internes doivent consulter les notes de développement.
