Descrizione:

ExecuteAssembly è un'alternativa a CS execute-assembly, costruito in C/C++ e può essere utilizzato per caricare/iniettare assembly .NET tramite; riutilizzo dei moduli CLR/AppDomainManager caricati dal processo host (spawnto), stomping dei loader/assembly .NET degli header PE DOS, scollegamento dei moduli correlati a .NET, bypass di ETW+AMSI, evitamento degli hook EDR tramite syscall NT statici (x64) e nascondimento degli import risolvendo dinamicamente le API tramite l'algoritmo di hash superfasthash.

TLDR (Caratteristiche):

Scollegamento dei moduli correlati a CLR dalle strutture dati PEB. (usare l'utility MS "ListDLLs" invece di PH per conferma)
Stomping degli header dell'assembly .NET e della DLL riflessiva (byte MZ, e_lfanew, Header DOS, Rich Text, Header PE).
Uso di syscall statici hardcodati per bypassare gli hook EDR. (supporto solo x64 per ora, da WinXP a Win10 19042)
Enumerazione e riutilizzo di CLR "AppDomain/AppDomainManager" (ICLRMetaHost->EnumerateLoadedRuntimes), basta impostare il processo spawnto/host su un noto processo Windows .NET.
Risoluzione dinamica delle API WIN32 (PEB) utilizzando l'hash corrispondente delle API (SuperFastHash)
Patching di AMSI ed ETW prima di caricare gli assembly .NET.
Parsing dei byte dell'assembly .NET e scansione per la versione CLR da caricare/utilizzare.
Nessun uso di GetProcAddress/LoadLibrary/GetModuleHandle per il bypass di ETW.
Hosting CLR tramite API COM v4 e iniezione DLL riflessiva

Utilizzo:

x64(syscalls): questa versione dipende principalmente dall'uso di syscall statici per bypassare gli hook EDR; puoi usare questa versione per compilare solo la versione x64 della DLL (solo supporto x64 per ora).
x86|x64(PEB): recupera dinamicamente gli indirizzi API richiesti a runtime esaminando le tabelle EAP dei moduli PEB e risolvendo le API tramite hash superfasthash. tuttavia non tiene conto degli hook EDR posizionati su kernel32.dll o ntdll.dll; puoi usare questa versione per compilare sia le DLL x86 che x64, oppure solo la DLL x86 e usare la versione x64(syscalls) per compilare la DLL x64 per gestire gli hook EDR comuni.
Compila le DLL richieste usando VS2017 e/o Windows SDK 10.0.17134.0 (o versioni SDK compatibili).
Assicurati che gzip sia installato e che i seguenti artefatti siano inseriti nella stessa cartella, poi carica lo script aggressor "ExecuteAssembly.cna":
- ExecuteAssembly.cna
- ExecuteAssembly-x64.dll
- ExecuteAssembly-x86.dll
- Opzioni CLI:
  
  --dotnetassembly: Assembly .NET da caricare/iniettare.
  
  --assemblyargs: Argomenti dell'assembly .NET.
  
  --unlink-modules: Scollega i moduli correlati a .NET come le DLL relative a CLR/MsCoree dalle strutture dati PEB.
  
  --stomp-headers: Stompa gli header PE DOS dell'assembly .NET e della DLL riflessiva.
  
  --etw: Bypassa il tracciamento eventi su Windows (ETW).
  
  --amsi: Bypassa AMSI.
  
  --spawnto: Scegli il processo spawnto, elenco di binari .NET che caricano il CLR per impostazione predefinita quando eseguiti:
  - PresentationHost.exe
  - stordiag.exe
Controlla spawnto-list.txt per ulteriori binari MS che caricano il CLR per impostazione predefinita e sono buoni candidati da impostare come spawnto. (eviterei i noti LOLBins a meno che non si tratti di una macchina da sviluppo)

Esempi:

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

Supporto C2:

È stato creato e testato principalmente su Cobalt Strike, tuttavia può essere utilizzato anche con altri framework C2 (MSF ecc.), tieni presente che la DLL riflessiva DLLMAIN si aspetta il payload one-liner come parametro (lpReserved) nel seguente formato (senza ".");

AMSI_FLAG|ETW_FLAG|STOMPHEADERS_FLAG|UNLINKMODULES_FLAG|LL_FLAG.LENGTH_FLAG.B64_ENCODED_COMPRESSED_PAYLOAD [SPACE SEPARATED ARGUMENTS]
- AMSI_FLAG: 0|1 (0 o 1)
- ETW_FLAG: 0|1
- STOMPHEADERS_FLAG: 0|1
- UNLINKMODULES_FLAG: 0|1
- LENGTH_FLAG: dimensione dell'assembly .NET in byte
- LL_FLAG: length_of(LENGTH_FLAG) (sopportami o fai finta di non averlo letto)
- B64_ENCODED_COMPRESSED_PAYLOAD: Assembly .NET compresso con Gzip e codificato in base64.
- [SPACE SEPARATED ARGUMENTS]: Argomenti dell'assembly .NET

Note di test:

Testato con Cobalt Strike 4.x senza profili malleabili.
Testato con Cobalt Strike 4.x utilizzando il seguente profilo malleabile (diverse opzioni di evasione della memoria impostate (userwx, startrwx ..ecc.));
- https://github.com/threatexpress/malleable-c2/blob/master/jquery-c2.4.0.profile

DA FARE:

Un'alternativa a RFLL, BOF + Named Pipes potrebbe essere (non sono sicuro per attività di lunga durata)
Supporto x86 per syscall statici.
Correzioni di bug e pulizia di eventuali puntatori pendenti o memory leak che ho dimenticato :p

Problemi noti:

Supporto per SharpHound v2 e v3 (v2 funzionava perfettamente, bisogna capire cosa è cambiato).
Limitazione della dimensione dell'assembly .NET ( < 1MB)

Più Popolari

Informazioni

ExecuteAssembly