Beschreibung:

ExecuteAssembly ist eine Alternative zu CS execute-assembly, entwickelt in C/C++, und kann verwendet werden, um .NET-Assemblies zu laden/injizieren, indem es die geladenen CLR-Module/AppDomainManager des Host-Prozesses (spawnto) wiederverwendet, die PE-DOS-Header von Loader/.NET-Assembly überschreibt, .NET-bezogene Module aus dem PEB entfernt, ETW+AMSI umgeht, EDR-Hooks über statische NT-Syscalls (x64) vermeidet und Importe durch dynamisches Auflösen von APIs mittels Superfasthash-Hashing-Algorithmus verbirgt.

TLDR (Funktionen):

Entfernung von CLR-bezogenen Modulen aus PEB-Datenstrukturen. (zur Bestätigung das MS-Tool "ListDLLs" anstelle von PH verwenden)
Überschreiben der .NET-Assembly- und Reflective-DLL-Header (MZ-Bytes, e_lfanew, DOS-Header, Rich Text, PE-Header).
Verwendung von statischen, hartkodierten Syscalls zur Umgehung von EDR-Hooks. (derzeit nur x64-Unterstützung, von WinXP bis Win10 19042)
Enumeration und Wiederverwendung von CLR "AppDomain/AppDomainManager" (ICLRMetaHost->EnumerateLoadedRuntimes); dazu einfach den spawnto/Host-Prozess auf einen bekannten Windows-.NET-Prozess setzen.
Dynamisches Auflösen von WIN32-APIs (PEB) mittels entsprechender Hash-Werte (SuperFastHash).
Patchen von AMSI und ETW vor dem Laden von .NET-Assemblies.
Parsen und Scannen von .NET-Assembly-Bytes nach der zu ladenden/verwendenden CLR-Version.
Keine Verwendung von GetProcAddress/LoadLibrary/GetModuleHandle für die ETW-Umgehung.
CLR-Hosting mittels v4 COM-API & Reflective-DLL-Injection

Verwendung:

x64(syscalls): Diese Version basiert hauptsächlich auf der Verwendung von statischen Syscalls zur Umgehung von EDR-Hooks. Mit dieser Version kann nur die x64-Version der DLL erstellt werden (derzeit nur x64-Unterstützung).
x86|x64(PEB): Ruft benötigte API-Adressen zur Laufzeit dynamisch ab, indem es die EAP-Tabellen der PEB-Module durchläuft und APIs mittels Superfasthash-Hash auflöst. Berücksichtigt jedoch keine EDR-Hooks, die entweder in kernel32.dll oder ntdll.dll platziert wurden. Mit dieser Version können sowohl die x86- als auch die x64-DLLs erstellt werden, oder nur die x86-DLL und die x64(syscalls)-Version für die Erstellung der x64-DLL, um gängige EDR-Hooks zu umgehen.
Erstellen Sie die benötigten DLLs mit VS2017 und/oder Windows SDK 10.0.17134.0 (oder kompatiblen SDK-Versionen).
Stellen Sie sicher, dass gzip installiert ist und die folgenden Artefakte im selben Ordner liegen. Laden Sie dann das Aggressor-Skript "ExecuteAssembly.cna":
- ExecuteAssembly.cna
- ExecuteAssembly-x64.dll
- ExecuteAssembly-x86.dll
- CLI-Optionen:
  
  --dotnetassembly: .NET Assembly to load/inject.
  
  --assemblyargs: .NET assembly arguments.
  
  --unlink-modules: Unlink .NET related modules such as CLR/MsCoree related DLLs from PEB data structures.
  
  --stomp-headers: Stomp .NET assembly and reflective DLL PE DOS headers.
  
  --etw: Bypass event tracing on windows (ETW).
  
  --amsi: Bypass AMSI.
  
  --spawnto: Choose spawnto process, list of .NET binaries loading the CLR by default when executed:
  - PresentationHost.exe
  - stordiag.exe
Überprüfen Sie spawnto-list.txt auf zusätzliche MS-Binärdateien, die standardmäßig die CLR laden und gute Kandidaten als Spawnto sind. (Vermeiden Sie die bekannten LOLBins, es sei denn, es handelt sich um einen Entwickler-Rechner.)

Beispiele:

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

C2-Unterstützung:

Wurde hauptsächlich für Cobalt Strike entwickelt und getestet, kann aber auch mit anderen C2-Frameworks (MSF usw.) verwendet werden. Beachten Sie, dass der DLLMAIN der Reflective DLL den One-Liner-Payload als Parameter (lpReserved) im folgenden Format erwartet (ohne ".");

AMSI_FLAG|ETW_FLAG|STOMPHEADERS_FLAG|UNLINKMODULES_FLAG|LL_FLAG.LENGTH_FLAG.B64_ENCODED_COMPRESSED_PAYLOAD [LEERZEICHENGETRENNTE ARGUMENTE]
- AMSI_FLAG: 0|1 (entweder 0 oder 1)
- ETW_FLAG: 0|1
- STOMPHEADERS_FLAG: 0|1
- UNLINKMODULES_FLAG: 0|1
- LENGTH_FLAG: .NET-Assembly-Größe in Bytes
- LL_FLAG: length_of(LENGTH_FLAG) (Ertragen Sie es einfach oder tun Sie so, als hätten Sie das nicht gelesen)
- B64_ENCODED_COMPRESSED_PAYLOAD: Gzip-komprimierte und Base64-kodierte .NET-Assembly.
- [LEERZEICHENGETRENNTE ARGUMENTE]: .NET-Assembly-Argumente

Testhinweise:

Getestet mit Cobalt Strike 4.x ohne malleable Profile.
Getestet mit Cobalt Strike 4.x mit folgendem malleable Profile (mehrere Memory-Evasion-Optionen gesetzt (userwx, startrwx usw.));
- https://github.com/threatexpress/malleable-c2/blob/master/jquery-c2.4.0.profile

TODO:

Eine Alternative zu RFLL, BOF + Named Pipes könnte sein (nicht sicher bei langlebigen Tasks)
x86-Unterstützung für statische Syscalls.
Fehlerbehebung und Bereinigung von hängenden Zeigern oder Speicherlecks, die ich übersehen habe :p

Bekannte Probleme:

Unterstützung für SharpHound v2 und v3 (v2 funktionierte einwandfrei, muss herausfinden, was sich geändert hat).
.NET-Assembly-Größenbeschränkung (< 1 MB)

Beliebteste

Über

ExecuteAssembly