Description :

ExecuteAssembly est une alternative de CS execute-assembly, construit avec C/C++ et peut être utilisé pour charger/injecter des assemblies .NET en ; réutilisant les modules CLR/AppDomainManager chargés par le processus hôte (spawnto), en écrasant les en-têtes DOS PE du loader/de l'assembly .NET, en déliant les modules liés à .NET, en contournant ETW+AMSI, en évitant les hooks EDR via des appels système statiques NT (x64) et en masquant les importations en résolvant dynamiquement les API via l'algorithme de hachage superfasthash.

TLDR (Fonctionnalités) :

Déliaison des modules liés à CLR des structures de données PEB. (utilisez l'utilitaire MS "ListDLLs" au lieu de PH pour confirmation)
Écrasement des en-têtes de l'assembly .NET et de la DLL réflexive (octets MZ, e_lfanew, en-tête DOS, Rich Text, en-tête PE).
Utilisation d'appels système statiques codés en dur pour contourner les hooks EDR. (support x64 uniquement pour l'instant, de WinXP à Win10 19042)
Énumération et réutilisation de CLR "AppDomain/AppDomainManager" (ICLRMetaHost->EnumerateLoadedRuntimes), définissez simplement le processus spawnto/hôte sur un processus .NET Windows connu.
Résolution dynamique des API WIN32 (PEB) en utilisant le hachage correspondant aux API (SuperFastHash)
Correction (patching) d'AMSI et ETW avant de charger les assemblies .NET.
Analyse et scan des octets de l'assembly .NET pour la version CLR à charger/utiliser.
Pas d'utilisation de GetProcAddress/LoadLibrary/GetModuleHandle pour le contournement ETW.
Hébergement CLR utilisant l'API COM v4 et l'injection de DLL réflexive

Utilisation :

x64(syscalls): cette version dépend principalement de l'utilisation d'appels système statiques pour contourner les hooks EDR, vous pouvez utiliser cette version pour construire la version x64 de la DLL uniquement (support x64 uniquement pour l'instant).
x86|x64(PEB): récupère les adresses API requises dynamiquement à l'exécution en parcourant les tables EAP des modules PEB et en résolvant les API via le hachage superfasthash. Cependant, ne tient pas compte des hooks EDR placés sur kernel32.dll ou ntdll.dll. Vous pouvez utiliser cette version pour construire les DLL x86 et x64, ou seulement la DLL x86 et utiliser la version x64(syscalls) pour construire la DLL x64 afin de tenir compte des hooks EDR courants.
Construisez les DLL requises en utilisant VS2017 et/ou Windows SDK 10.0.17134.0 (ou des versions SDK compatibles).
Assurez-vous que gzip est installé et que les artefacts suivants sont placés dans le même dossier, puis chargez simplement le script aggressor "ExecuteAssembly.cna" :
- ExecuteAssembly.cna
- ExecuteAssembly-x64.dll
- ExecuteAssembly-x86.dll
- Options CLI :
  
  --dotnetassembly: Assembly .NET à charger/injecter.
  
  --assemblyargs: Arguments de l'assembly .NET.
  
  --unlink-modules: Délier les modules liés à .NET tels que les DLL CLR/MsCoree des structures de données PEB.
  
  --stomp-headers: Écraser les en-têtes DOS PE de l'assembly .NET et de la DLL réflexive.
  
  --etw: Contourner le suivi d'événements sur Windows (ETW).
  
  --amsi: Contourner AMSI.
  
  --spawnto: Choisir le processus spawnto, liste des binaires .NET chargeant le CLR par défaut lorsqu'ils sont exécutés :
  - PresentationHost.exe
  - stordiag.exe
Consultez spawnto-list.txt pour des binaires MS supplémentaires chargeant le CLR par défaut et qui sont de bons candidats à définir comme spawnto. (éviterait les LOLBins connus sauf s'il s'agit d'une machine de développement peut-être)

Exemples :

ExecuteAssembly --dotnetassembly /tmp/Seatbelt.exe --assemblyargs LogonSessions --unlink-modules --stomp-headers --amsi --etw --spawnto PresentationHost.exe
ExecuteAssembly --amsi --etw --unlink-modules --stomp-headers --dotnetassembly /tmp/ghostpack/SharPersist.exe --assemblyargs -t reg -c "C:\Windows\SysWow64\mshta.exe C:\Users\admin\Downloads\Test2.hta" -k logonscript -m add --spawnto FileHistory.exe
ExecuteAssembly --unlink-modules --stomp-headers --dotnetassembly /tmp/ghostpack/SharPersist.exe --assemblyargs -t reg -k "logonscript" -v "C:\Windows\SysWow64\mshta.exe C:\Users\admin\Downloads\Test.hta" -m remove --spawnto FileHistory.exe
ExecuteAssembly --unlink-modules --amsi --dotnetassembly /tmp/ghostpack/SharpWMI.exe --assemblyargs action=query computername=localhost query="select * from win32_service" --spawnto FileHistory.exe
ExecuteAssembly --amsi --etw --dotnetassembly /tmp/ghostpack/SharpWMI.exe --assemblyargs action=query query="select * from win32_process" --spawnto PresentationHost.exe

Support C2 :

A été créé et testé principalement sur cobalt strike, mais peut également être utilisé avec d'autres frameworks C2 (MSF, etc.), gardez simplement à l'esprit que le DLLMAIN de la DLL réflexive attend le payload one-liner comme paramètre (lpReserved) dans le format suivant (sans ".");

AMSI_FLAG|ETW_FLAG|STOMPHEADERS_FLAG|UNLINKMODULES_FLAG|LL_FLAG.LENGTH_FLAG.B64_ENCODED_COMPRESSED_PAYLOAD [SPACE SEPARATED ARGUMENTS]
- AMSI_FLAG: 0|1 (soit 0 ou 1)
- ETW_FLAG: 0|1
- STOMPHEADERS_FLAG: 0|1
- UNLINKMODULES_FLAG: 0|1
- LENGTH_FLAG: Taille de l'assembly .NET en octets
- LL_FLAG: length_of(LENGTH_FLAG) (supportez-moi ici ou faites comme si vous n'aviez pas lu ça)
- B64_ENCODED_COMPRESSED_PAYLOAD: Assembly .NET compressé Gzip et encodé en base64.
- [SPACE SEPARATED ARGUMENTS]: Arguments de l'assembly .NET

Notes de test :

Testé avec cobalt strike 4.x sans utiliser de profils malléables.
Testé avec cobalt strike 4.x en utilisant le profil malléable suivant (plusieurs options d'évasion mémoire définies (userwx, startrwx, etc.));
- https://github.com/threatexpress/malleable-c2/blob/master/jquery-c2.4.0.profile

À faire :

Une alternative à RFLL, BOF + Tubes nommés peut-être (pas sûr pour les tâches de longue durée)
Support x86 pour les appels système statiques.
Correction de bugs et nettoyage des pointeurs pendants ou fuites de mémoire que j'aurais oubliées :p

Problèmes connus :

Support pour SharpHound v2 et v3 (v2 fonctionnait très bien, besoin de comprendre ce qui a changé).
Limitation de taille de l'assembly .NET (< 1 Mo)

Populaires

À propos

ExecuteAssembly