InlineExecute-Assembly

InlineExecute-Assembly est une preuve de concept de Beacon Object File (BOF) permettant aux professionnels de la sécurité d'effectuer une exécution d'assembly .NET en processus, en alternative au module traditionnel fork-and-run execute-assembly de Cobalt Strike. InlineExecute-Assembly exécute tout assembly dont le point d'entrée est Main(string[] args) ou Main(). Cela devrait vous permettre d'exécuter la plupart des outils publiés sans aucune modification préalable.

Le BOF détermine automatiquement quel Common Language Runtime (CLR) doit être chargé dans le processus pour votre assembly (v2.0.50727 ou v4.0.30319) avant l'exécution et, dans la plupart des cas, se termine proprement en cas de problème. Le BOF prend également en charge plusieurs indicateurs qui permettent à l'opérateur de dicter certains comportements avant l'exécution .NET, notamment : désactiver AMSI via du patching mémoire, désactiver et restaurer ETW via du patching mémoire, personnaliser le nom du domaine d'application CLR à créer, choisir de créer et diriger la sortie console de votre assembly vers un named pipe ou un mailslot, et permettre à l'opérateur de passer du point d'entrée par défaut Main(string[] args) à Main(). Plus de détails sur l'utilisation, les cas d'usage et les détections possibles se trouvent ci-dessous et sur https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/.

Enfin, l'avantage d'exécuter nos assemblies .NET dans le même processus que notre beacon est d'éviter le comportement par défaut du module execute-assembly de Cobalt Strike, qui crée un nouveau processus pour charger/injecter le CLR/l'assembly .NET. Cependant, d'autres considérations OPSEC subsistent, par exemple : le processus dans lequel nous exécutons charge-t-il normalement le CLR ? L'assembly .NET que nous exécutons a-t-il des signatures connues ? Par conséquent, l'inconvénient est que si quelque chose est détecté et tué, par exemple par AMSI, votre beacon est également tué.

Références

Cet outil n'existerait pas sans pouvoir s'appuyer sur des recherches, des outils et du code déjà publiés par des membres de la communauté de sécurité. Merci donc. Enfin, si vous pensez que quelqu'un a été oublié ci-dessous, n'hésitez pas à me le faire savoir et je veillerai à l'ajouter.

• HostingCLR - ici - Logique CLR/exécution d'assembly
• Dotnet-Loader-Shellcode - (par @modexpblog) - ici - Excellente recherche globale, y compris sur les interfaces COM pour l'exécution de .NET en C -> Real MVP
• Donut - (par @TheRealWover et @modexpblog) - ici - En-tête des interfaces COM
• Memory Patching AMSI Bypass - (par @_RastaMouse) - ici - Recherche sur le patching mémoire AMSI
• Metasploit-Execute-Assembly - (par @b4rtik) - ici - Patching AMSI modifié et utilisation de la fonction find .NET version
• ExecuteAssembly - (par @med0x2e) - ici - Script aggressor modifié
• Hiding Your .NET ETW - (par @xpn) - ici - Excellente recherche sur ETW
• ETW BOF - (par @ajpc500) - ici - Patching ETW modifié
• ExecuteAssembly_Mailslot - (par @N4k3dTurtl3) - ici - Utilisation modifiée des mailslots pour la redirection de console
• @freefirex2 - A eu la gentillesse de partager quelques bonnes fonctionnalités internes et pièges des BOF.

Pour commencer

1. Copiez le dossier inlineExecute-Assembly avec tout son contenu vers un système auquel vous prévoyez de vous connecter via l'application Cobalt Strike GUI.
2. Chargez le script Aggressor inlineExecute-Assembly.cna
3. Exécutez inlineExecute-Assembly --dotnetassembly /chemin/vers/assembly.exe pour une exécution basique (voir les cas d'usage ci-dessous pour des exemples d'indicateurs spécifiques)

Compiler votre propre BOF

Exécutez la commande ci-dessous dans le répertoire src via l'invite de commande x64 Native Tools pour VS 2019

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx64.o

Exécutez la commande ci-dessous dans le répertoire src via l'invite de commande x86 Native Tools pour VS 2019

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx86.o

Indicateurs

--dotnetassembly        Chemin d'accès vers votre assembly **obligatoire**
--assemblyargs          Arguments de l'assembly à passer
--appdomain             Modifier le nom par défaut du AppDomain envoyé (la valeur par défaut est totesLegit et est définie via le script aggressor inclus) *Le domaine est toujours déchargé*
--amsi                  Tente de désactiver AMSI via du patching mémoire (si réussi, AMSI sera désactivé pour toute la durée de vie du processus)
--etw                   Tente de désactiver ETW via du patching mémoire (si réussi, ETW sera désactivé pour toute la durée de vie du processus sauf revert)
--revertetw             Tente de désactiver ETW via du patching mémoire puis le repatch à l'état d'origine
--pipe                  Modifier le nom par défaut du named pipe (la valeur par défaut est totesLegit et est définie via le script aggressor inclus)
--mailslot              Utilise les mailslots pour rediriger la sortie console. Modifie le nom par défaut du mailslot (si laissé vide, la valeur par défaut est totesLegit et est définie via le script aggressor inclus)
--main                  Change le point d'entrée vers Main() (la valeur par défaut est Main(string[] args))

Cas d'usage

Exécuter un assembly .NET

Syntaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe

Cas d'usage

Exécuter un assembly .NET avec des arguments

Syntaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker

Cas d'usage

Exécuter un assembly .NET avec des arguments et désactiver AMSI

Syntaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi

Cas d'usage

Exécuter un assembly .NET avec des arguments et désactiver ETW

Syntaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --etw

Cas d'usage

Exécuter un assembly .NET avec des arguments et rediriger la sortie via des mailslots au lieu du named pipe par défaut

Syntaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --mailslot

Cas d'usage

Exécuter un assembly .NET avec des arguments et changer le nom du named pipe par défaut défini dans le script aggressor

Syntaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --pipe forRealLegit

Cas d'usage

Exécuter un assembly .NET et changer le nom du domaine d'application par défaut défini dans le script aggressor

Syntaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --appdomain forRealLegit

Cas d'usage

Exécuter un assembly .NET avec le point d'entrée Main() au lieu du Main(string[] args) par défaut

Syntaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/simpleMain.exe --main

Cas d'usage

Faire le grand jeu

Syntaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi --etw --appdomain forRealLegit --mailslot forRealLegit

Mises en garde

1. Bien que j'aie essayé de rendre cet outil aussi stable que possible, rien ne garantit qu'il ne plantera jamais et que les beacons ne mourront pas. Nous n'avons pas le luxe supplémentaire de fork-and-run où, si quelque chose tourne mal, notre beacon survit. C'est le compromis avec les BOF. Cela dit, je ne saurais trop insister sur l'importance de tester vos assemblies au préalable pour vous assurer qu'ils fonctionneront correctement avec l'outil.
2. Étant donné que le BOF s'exécute dans le processus et prend le contrôle du beacon pendant qu'il tourne, cela doit être pris en compte avant de l'utiliser pour des assemblies de longue durée. Si vous choisissez d'exécuter quelque chose qui prendra beaucoup de temps pour obtenir des résultats, votre beacon ne sera pas actif pour exécuter d'autres commandes jusqu'à ce que les résultats reviennent et que votre assembly ait terminé. Cela ne respecte pas non plus le paramètre sleep. Par exemple, si votre sleep est réglé à 10 minutes et que vous exécutez le BOF, vous obtiendrez les résultats dès que le BOF aura terminé son exécution.
3. Sauf modification apportée aux outils qui chargent des PE en mémoire (par exemple, SafetyKatz), ceux-ci tueront très probablement votre beacon. Nombre de ces outils fonctionnent correctement avec execute assembly car ils peuvent envoyer leur sortie console depuis le processus sacrifié avant de se terminer. Lorsqu'ils se terminent via notre BOF en processus, ils tuent notre processus, ce qui tue notre beacon. Ils peuvent être modifiés pour fonctionner, mais je conseillerais d'exécuter ces types d'assemblies via execute assembly, car d'autres éléments non conformes à l'OPSEC pourraient être chargés dans votre processus sans être supprimés.
4. Si votre assembly utilise Environment.Exit, cela doit être supprimé car cela tuera le processus et le beacon.
5. Les named pipes et les mailslots doivent être uniques. Si vous ne recevez pas de données et que votre beacon est toujours vivant, le problème vient probablement du fait que vous devez choisir un nom de named pipe ou de mailslot différent.

Détection

Quelques stratégies de détection et d'atténuation pourraient être utilisées :

1. Utilise PAGE_EXECUTE_READWRITE lors du patching mémoire AMSI et ETW. Cela a été fait intentionnellement et devrait être un signal d'alarme, car très peu de programmes ont des plages mémoire avec la protection PAGE_EXECUTE_READWRITE.
2. Le nom par défaut du named pipe créé est totesLegit. Cela a été fait intentionnellement et des détections par signature pourraient être utilisées pour le signaler.
3. Le nom par défaut du mailslot créé est totesLegit. Cela a été fait intentionnellement et des détections par signature pourraient être utilisées pour le signaler.
4. Le nom par défaut du AppDomain chargé est totesLegit. Cela a été fait intentionnellement et des détections par signature pourraient être utilisées pour le signaler.
5. Bonnes astuces pour détecter l'utilisation malveillante de .NET (par @bohops) ici, (par F-Secure) ici, et ici
6. Rechercher le chargement du CLR .NET dans des processus suspects, tels que les processus non managés qui ne devraient jamais avoir le CLR chargé.
7. Event Tracing ici
8. Rechercher d'autres IOC connus de Cobalt Strike Beacon ou des IOC de communication C2.