RedPeanut é um pequeno RAT desenvolvido em .Net Core 2 e seu agente em .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
__________________________________________________________________________
Atualmente em teste.
Problemas conhecidos dos módulos:
process -> spawnasagent
process -> spawnasshellcode
RedPeanut é um pequeno RAT desenvolvido em .Net Core 2 e seu agente em .Net 3.5 / 4.0. A execução de código do RedPeanut é baseada em shellcode gerado com DonutCS. É, portanto, um híbrido, embora desenvolvido em .Net, não depende exclusivamente do Assembly.Load. Isso aumenta a superfície de detecção, mas nos permite praticar e experimentar várias técnicas de evasão relacionadas ao ambiente dotnet, gerenciamento de processos e injeção. Esse comportamento pode ser alterado em tempo de execução com os comandos "managed" e "unmanaged". Se você está interessado em um Framework C2 .Net que seja consistente e possa ser usado em um engajamento, sugiro Covenant.
RedPeanut é equipado com:
O agente RedPeanut pode ser compilado em .Net 3.5 e 4.0 e possui capacidades de pivoting via NamedPipe. O agente, quando executado em modo não gerenciado (unmanaged), realiza suas próprias tarefas críticas em um processo separado para evitar que a resposta do AV à detecção ou erro durante a execução faça você perder o agente inteiro.
O fluxo de execução é o seguinte:
Atualmente, o agente suporta apenas o canal https.
O protocolo de check-in do agente é muito simples:
Alternativamente, o recurso de canal coberto pode ser ativado (no momento é apenas uma PoC). A ideia é imitar o tráfego web realizado por um usuário real. Geralmente, uma página web é composta pela página html e todos os objetos necessários para sua exibição, como css, imagens, etc. Na solicitação de uma nova tarefa, a resposta do servidor não será diretamente a tarefa criptografada, mas uma página html da qual extrair o link para a imagem que terá a tarefa criptografada embutida. A requisição http para a imagem conterá o cabeçalho Referer.
A entrega de conteúdo é organizada em 4 canais:
RedPeanut tem capacidade de personalização da pegada de rede tanto no lado do servidor quanto no lado do cliente. As propriedades que podem ser definidas são:
Geral
Http Get
Http Post
Domain Fronting
Para habilitar o suporte a domain fronting, é necessário valorizar o cabeçalho "Host" na seção client, tanto post quanto get (exemplificado no perfil padrão 2)
O módulo PowerShellExecuter permite executar comandos oneliner ou arquivos em um runspace com bypass de AMSI, bypass de Logging e PowerView já carregados.
A partir da versão 0.3.0, o RedPeanutAgent suporta o comando blockdlls. Com esta opção habilitada, os processos filhos que são criados para realizar tarefas no modo não gerenciado são criados com o atributo PROCESS_CREATION_MITIGATION_POLICY_BLOCK_NON_MICROSOFT_BINARIES_ALWAYS_ON. Este atributo impede que o processo carregue dlls que não são assinadas pela Microsoft, isso pode proteger nossas tarefas contra técnicas de hooking de AV e EDR.
O RedPeanutAgent usa carregamento dinâmico de DLL para evitar o uso de imports de DLL suspeitos. Os créditos pelo Dynamic Dll Loading vão para @TheRealWover, @cobbr_io e @FuzzySec pelo seu trabalho em SharpSploit.
Alguns fornecedores de AV e EDR usam a técnica de hooking para rastrear atividades. Para evitar o uso de syscall com hook, o RedPeanutAgent usa syscall direto, injetando automaticamente o código necessário. Os créditos pelo Direct Syscall vão para @Cneelis
Para executar o RedPeanut, você precisa ter o dotnet instalado. Para instalar o dotnet no 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
Para a funcionalidade de canal coberto, é necessário instalar a biblioteca libgdiplus, portanto:
Para usuários Linux:
apt-get install -y libgdiplus
Para macOS
brew install mono-libgdiplus
Geração de chave de assinatura de assembly
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community>sn.exe -k 4096 key.snk
Em seguida, copie key.snk para 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 é uma ferramenta de geração de shellcode que cria payloads de shellcode independentes de posição a partir de assemblies .NET. Este shellcode pode ser usado para injetar o Assembly em processos Windows arbitrários. Dado um assembly .NET arbitrário, parâmetros e um ponto de entrada (como Program.Main), ele produz shellcode independente de posição que o carrega a partir da memória. O assembly .NET pode ser staged a partir de uma URL ou sem stage, sendo incorporado diretamente no shellcode.
A técnica de persistência CLR foi apresentada pela primeira vez neste post por @Am0nsec. A técnica consiste em realizar o hooking do gerenciador de domínio de aplicação. Conforme descrito no post, o assembly para realizar o hooking é necessário e está disponível no GAC. Um assembly para ser usado a partir do GAC deve ter nome forte (strong-named) e ser assinado com uma chave. O módulo de persistência CLR precisa de uma chave para poder assinar os assemblies, que pode ser gerada com a ferramenta sn.exe da seguinte forma:
**********************************************************************
** 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
Copie o arquivo key.snk para a pasta Workspace/KeyFile. Este arquivo será usado para assinar o assembly para persistência.
Algumas das ferramentas conhecidas presentes no RedPeanut, como as ferramentas GhostPack, são totalmente encapsuladas e executadas no lado do cliente. Para atualizar as ferramentas, por exemplo SeatBelt, sem atualizar todo o repositório, é necessário: Clone o repositório do Seatbelt, renomeie o método "Main" para "Execute", insira o modificador public e recompile como dll. A dll deve ser compactada e codificada em Base64 com o script ps do RastaMouse Get-CompressedShellcode.ps1