RedPeanut è un piccolo RAT sviluppato in .Net Core 2 e il suo agente in .Net 3.5 / 4.0.
__________________________________________________________________________
ooooooo________________oo_ooooooo___________________________________oo____
oo____oo___ooooo___oooooo_oo____oo__ooooo___ooooo__oo_ooo__oo____o__oo____
oo____oo__oo____o_oo___oo_oo____oo_oo____o_oo___oo_ooo___o_oo____o_oooo___
ooooooo___ooooooo_oo___oo_oooooo___ooooooo_oo___oo_oo____o_oo____o__oo____
oo____oo__oo______oo___oo_oo_______oo______oo___oo_oo____o_ooo___o__oo__o_
oo_____oo__ooooo___oooooo_oo________ooooo___oooo_o_oo____o_oo_ooo____ooo__
__________________________________________________________________________
________________________________________________RedPeanut_v0.3.0___@b4rtik
__________________________________________________________________________
Attualmente in fase di test.
Problemi noti dei moduli:
process -> spawnasagent
process -> spawnasshellcode
RedPeanut è un piccolo RAT sviluppato in .Net Core 2 e il suo agente in .Net 3.5 / 4.0. L'esecuzione del codice di RedPeanut si basa su shellcode generato con DonutCS. È quindi un ibrido; sebbene sviluppato in .Net, non si basa esclusivamente su Assembly.Load. Ciò aumenta la superficie di rilevamento, ma ci consente di esercitarci e sperimentare varie tecniche di evasione relative all'ambiente dotnet, alla gestione dei processi e all'iniezione. Questo comportamento può essere modificato a runtime con i comandi "managed" e "unmanaged". Se sei interessato a un framework C2 .Net che sia consistente e possa essere utilizzato in un impegno, suggerisco Covenant.
RedPeanut è armato con:
L'agente RedPeanut può essere compilato in .Net 3.5 e 4.0 e ha capacità di pivoting tramite NamedPipe. L'agente, quando eseguito in modalità non gestita, esegue le proprie operazioni critiche in un processo separato per impedire che la risposta dell'AV al rilevamento o un errore durante l'esecuzione ti faccia perdere l'intero agente.
Il flusso di esecuzione è il seguente:
L'agente attualmente supporta solo il canale https.
Il protocollo di checkin dell'agente è molto semplice:
In alternativa, è possibile attivare la funzionalità del canale coperto (al momento è solo un PoC). L'idea è imitare il traffico web effettuato da un utente reale. Di solito una pagina web è composta dalla pagina html e da tutti gli oggetti necessari per la sua visualizzazione come css, immagini, ecc. Alla richiesta di un nuovo compito, la risposta del server non sarà direttamente il compito crittografato, ma una pagina html da cui estrarre il link all'immagine che avrà incorporato il compito crittografato. La richiesta http per l'immagine conterrà l'header Referer.
La consegna dei contenuti è organizzata in 4 canali:
La capacità di RedPeanut di personalizzare l'impronta di rete sia lato server che lato client. Le proprietà che possono essere impostate sono:
Domain Fronting
Per abilitare il supporto al domain fronting è necessario valorizzare l'header "Host" nella sezione client, sia post che get (esemplificato nel profilo predefinito 2)
Il modulo PowerShellExecuter consente di eseguire comandi oneliner o file in un runspace con bypass di AMSI, bypass del logging e PowerView già caricato.
A partire dalla versione 0.3.0 RedPeanutAgent supporta il comando blockdlls. Con questa opzione abilitata, i processi figlio creati per eseguire attività in modalità non gestita vengono creati con l'attributo PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON. Questo attributo impedisce al processo di caricare dll non firmate da Microsoft, il che potrebbe proteggere le nostre attività dalle tecniche di hooking di AV e EDR.
RedPeanutAgent utilizza il caricamento dinamico delle DLL per evitare l'uso di importazioni DLL sospette. I crediti per il caricamento dinamico delle DLL vanno a @TheRealWover, @cobbr_io e @FuzzySec per il loro lavoro in SharpSploit.
Alcuni fornitori di AV e EDR utilizzano tecniche di hooking per tenere traccia delle attività. Per evitare l'uso di syscall hookate, RedPeanutAgent utilizza syscall dirette, auto-iniettando il codice necessario. I crediti per le syscall dirette vanno a @Cneelis
Per eseguire RedPeanut è necessario avere dotnet installato. Per installare dotnet su Kali:
wget -qO- https://packages.microsoft.com/keys/microsoft.asc | gpg --dearmor > microsoft.asc.gpg
mv microsoft.asc.gpg /etc/apt/trusted.gpg.d/
wget -q https://packages.microsoft.com/config/debian/9/prod.list
mv prod.list /etc/apt/sources.list.d/microsoft-prod.list
chown root:root /etc/apt/trusted.gpg.d/microsoft.asc.gpg
chown root:root /etc/apt/sources.list.d/microsoft-prod.list
apt-get install apt-transport-https
apt-get update
apt-get install dotnet-sdk-2.1
git clone --recursive https://github.com/b4rtik/RedPeanut.git
Per la funzionalità del canale coperto è necessario installare la libreria libgdiplus, quindi:
Per linux:
apt-get install -y libgdiplus
Per OSx
brew install mono-libgdiplus
Generazione della chiave di firma dell'assembly
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>sn.exe -k 4096 key.snk
Quindi copiare key.snk in Workspace/KeyFile
root@kali:~# cd RedPanut
root@kali:~/RedPeanut# dotnet run
Using launch settings from /root/Projects/RedPeanut/Properties/launchSettings.json...
Enter password to encrypt serverkey:
__________________________________________________________________________
ooooooo________________oo_ooooooo___________________________________oo____
oo____oo___ooooo___oooooo_oo____oo__ooooo___ooooo__oo_ooo__oo____o__oo____
oo____oo__oo____o_oo___oo_oo____oo_oo____o_oo___oo_ooo___o_oo____o_oooo___
ooooooo___ooooooo_oo___oo_oooooo___ooooooo_oo___oo_oo____o_oo____o__oo____
oo____oo__oo______oo___oo_oo_______oo______oo___oo_oo____o_ooo___o__oo__o_
oo_____oo__ooooo___oooooo_oo________ooooo___oooo_o_oo____o_oo_ooo____ooo__
__________________________________________________________________________
________________________________________________RedPeanut_v0.3.0___@b4rtik
__________________________________________________________________________
[*] No profile available, creating new one...
[RP] >
DonutCS è uno strumento di generazione di shellcode che crea payload shellcode indipendenti dalla posizione da assembly .NET. Questo shellcode può essere utilizzato per iniettare l'assembly in processi Windows arbitrari. Dato un assembly .NET arbitrario, parametri e un punto di ingresso (come Program.Main), produce shellcode indipendente dalla posizione che lo carica dalla memoria. L'assembly .NET può essere sia staged da un URL, sia stageless essendo incorporato direttamente nello shellcode.
La tecnica di persistenza CLR è stata presentata per la prima volta in questo post da @Am0nsec. La tecnica consiste nell'eseguire l'hooking del gestore del dominio applicativo. Come descritto nel post, è necessario l'assembly per eseguire l'hooking, che è disponibile nel GAC. Un assembly da utilizzare dal GAC deve avere un nome sicuro (strong-named) e quindi essere firmato con una chiave. Il modulo di persistenza CLR necessita di una chiave per poter firmare gli assembly, che può essere generata con lo strumento sn.exe come segue:
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.9.3
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>sn.exe -k 4096 key.snk
Copiare il file key.snk nella cartella Workspace/KeyFile. Questo file sarà utilizzato per firmare l'assembly per la persistenza.
Alcuni degli strumenti ben noti presenti in RedPeanut, come gli strumenti GhostPack, sono completamente wrappati ed eseguiti sul lato client. Per aggiornare gli strumenti, ad esempio SeatBelt, senza aggiornare l'intero repository è necessario: Clonare il repository Seatbelt, rinominare il metodo "Main" in "Execute", inserire il modificatore public e ricompilare come dll. La dll deve essere compressa e codificata in Base64 con lo script ps di RastaMouse Get-CompressedShellcode.ps1