pwn1sher/frostbyteCombina l'iniezione di AppDomain Manager con l'embedding di shellcode in binari firmati per eludere il rilevamento EDR/AV per i payload di red team.
Negli ultimi giorni ho sperimentato con la tecnica di iniezione del gestore AppDomain e ho ottenuto un discreto successo nei miei precedenti impegni Red Team contro alcuni EDR. Sebbene sia molto valida come vettore di accesso iniziale, volevo rilasciare un POC che possa aiutare a nascondere il proprio shellcode altrove. Niente più file DLL con shellcode incorporato!
Sebbene sia una tecnica eccellente se usata indipendentemente, quando abbinata a una tecnica di consegna come l'invio di un C# ClickOnce all'interno di un file ISO/ZIP/VHD/VHDX, il vero problema è che 1 volta su 10 la DLL per l'appdomain veniva rilevata dalle euristiche AI/ML dell'AV/EDR. Questo perché il file DLL deve essere rilasciato su disco prima di inizializzare l'appdomain. Tralasciando per ora i caricamenti remoti di DLL (percorsi UNC in .config), la DLL per l'appdomain conterrebbe lo shellcode e ho fortemente ritenuto che questa fosse la ragione di una probabile rilevazione statica, poiché il resto del codice, costituito da chiamate WINAPI, può essere risolto dinamicamente e abbastanza ben offuscato.
Volevo migliorare questa tecnica riducendo al minimo ciò che la DLL dovrebbe inizialmente contenere. Ho iniziato rilasciando shellcode crittografato in un file separato su disco insieme alla DLL injector, ma poi mi sono imbattuto in questo fantastico blog di Checkpoint sulla campagna di Zloader
Versione TLDR: Possiamo incorporare dati arbitrari in alcuni campi all'interno del PE in modo da non rompere la firma del file. Quindi i nostri dati verranno incorporati e l'exe rimarrà comunque firmato digitalmente.
Maggiori informazioni su questo - https://www.blackhat.com/docs/us-16/materials/us-16-Nipravsky-Certificate-Bypass-Hiding-And-Executing-Malware-From-A-Digitally-Signed-Executable-wp.pdf
Quindi l'idea è di incorporare uno stub di shellcode crittografato in un eseguibile firmato noto e riuscire comunque a mantenerlo firmato, come ha fatto il malware Zloader. In questo modo, la DLL del gestore AppDomain non conterrà più lo shellcode al suo interno, ma avrà solo la logica per analizzare lo shellcode dal binario PE che lo carica, decrittografarlo ed eseguirlo come thread separato. In questo modo si potrebbe ridurre il tasso di rilevamento statico per la DLL, mentre il tuo shellcode è ben posizionato all'interno di un binario firmato.
Stavo cercando di ottenere questo manipolando manualmente i campioni di ZLoader presi da VirusTotal, ma poi ho scoperto un progetto che aveva già implementato tutte queste tecniche molto bene - Sigflip. In questo POC ho sfruttato il codice loader di Sigflip per costruire la DLL AppDomain e l'injector SigFlip per incorporare lo shellcode crittografato nel nostro exe C#.
Grandi blob di shellcode come lo shellcode Stageless di Cobalt Strike non risiederanno più su una DLL non firmata sul disco, indipendentemente dalle tecniche di offuscamento/codifica utilizzate. La DLL è più pulita, più piccola e più furtiva con un codice minimo, riducendo così le possibilità di rilevamento.
SigFlip.exe -i "Z:\ZLoader\CasPol.exe" "Z:\ZLoader\x64-stageless.bin" "Z:\ZLoader\update.exe" "S3cretK3y"update.exe che sarà un PE firmato digitalmente con shellcode crittografato incorporato.csc /target:library /out:test.dll test.csQuesto POC è solo un'idea che avevo in mente per unire due tecniche di evasione difensiva completamente diverse, che potrebbero aiutare me e altri Red Teamer a costruire migliori payload di esecuzione iniziale per le loro operazioni. Questo progetto utilizza l'iniezione del gestore AppDomain come esempio, ma questa idea è applicabile anche ad altre tecniche di iniezione come - DLL SideLoading, DLL Hijacking ecc.
Tutti i crediti a med0x2e, questo POC è basato sul suo progetto SigFlip