InlineExecute-Assembly

InlineExecute-Assembly é uma prova de conceito de Beacon Object File (BOF) que permite que profissionais de segurança realizem execução de assemblies .NET in-process como alternativa ao módulo tradicional fork and run execute-assembly do Cobalt Strike. O InlineExecute-Assembly executará qualquer assembly com o ponto de entrada Main(string[] args) ou Main(). Isso deve permitir executar a maioria das ferramentas publicadas sem necessidade de modificação prévia.

O BOF determinará automaticamente qual Common Language Runtime (CLR) precisa ser carregado no processo para seu assembly (v2.0.50727 ou v4.0.30319) antes da execução e, na maioria dos casos, deve terminar graciosamente se houver algum problema. O BOF também suporta várias flags que permitem ao operador ditar comportamentos antes da execução .NET, incluindo: desabilitar o AMSI via patching in-memory, desabilitar e restaurar o ETW via patching in-memory, personalizar o nome do App Domain CLR a ser criado, determinar se deve criar e direcionar a saída do console do seu assembly para um named pipe ou mailslot, e permite ao operador alterar o ponto de entrada padrão de Main(string[] args) para Main(). Mais detalhes sobre uso, casos de uso e possíveis detecções podem ser encontrados abaixo e em https://securityintelligence.com/posts/net-execution-inlineexecute-assembly/.

Por fim, a vantagem de executar nossos assemblies .NET no mesmo processo que nosso beacon implant é que evitamos o comportamento padrão do módulo execute-assembly do Cobalt Strike, que cria um novo processo para então carregar/injetar o CLR/assembly .NET. No entanto, outras considerações de OPSEC ainda existem, por exemplo: o processo em que estamos executando normalmente carrega o CLR? O assembly .NET que estamos executando tem assinaturas conhecidas? Portanto, a desvantagem é que, se algo for detectado e eliminado, por exemplo pelo AMSI, seu beacon também será eliminado.

Referências do Assunto

Esta ferramenta não existiria sem o apoio de pesquisas, ferramentas e códigos excelentes já publicados por membros da comunidade de segurança. Muito obrigado. Por fim, se você achar que alguém foi deixado de fora abaixo, por favor me avise e garantirei que seja adicionado.

• HostingCLR - aqui - Lógica de execução de assembly/CLR
• Dotnet-Loader-Shellcode - (por @modexpblog) - aqui - Ótima pesquisa em geral, incluindo sobre interfaces COM para executar .NET em C -> Real MVP
• Donut - (por @TheRealWover e @modexpblog) - aqui - Cabeçalho de interfaces COM
• Memory Patching AMSI Bypass - (por @_RastaMouse) - aqui - Pesquisa sobre patching de memória para AMSI
• Metasploit-Execute-Assembly - (por @b4rtik) - aqui - Patching AMSI modificado e uso da função find .NET version
• ExecuteAssembly - (por @med0x2e) - aqui - Script aggressor modificado
• Hiding Your .NET ETW - (por @xpn) - aqui - Ótima pesquisa sobre ETW
• ETW BOF - (por @ajpc500) - aqui - Patching ETW modificado
• ExecuteAssembly_Mailslot - (por @N4k3dTurtl3) - aqui - Uso modificado de mailslots para redirecionamento de console
• @freefirex2 - Gentilmente compartilhou alguns bons detalhes sobre funcionamento interno do BOF e pegadinhas.

Primeiros Passos

1. Copie a pasta inlineExecute-Assembly com todo seu conteúdo para um sistema ao qual você planeja se conectar via aplicativo GUI do Cobalt Strike.
2. Carregue o script Aggressor inlineExecute-Assembly.cna
3. Execute inlineExecute-Assembly --dotnetassembly /caminho/para/assembly.exe para execução mais básica (veja os casos de uso abaixo para exemplos específicos de flags)

Compile o Seu Próprio

Execute o comando abaixo dentro do diretório src via Prompt de Comando de Ferramentas Nativas x64 para VS 2019

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx64.o

Execute o comando abaixo dentro do diretório src via Prompt de Comando de Ferramentas Nativas x86 para VS 2019

cl.exe /c inlineExecute-Assembly.c /GS- /FoinlineExecute-Assemblyx86.o

Flags

--dotnetassembly        Caminho do diretório para seu assembly **obrigatório**
--assemblyargs          Argumentos do assembly a serem passados
--appdomain             Altera o nome padrão do AppDomain enviado (valor padrão é totesLegit e é definido via script aggressor incluído) *Domínio sempre descarregado*
--amsi                  Tenta desabilitar o AMSI via patching in-memory (Se bem-sucedido, AMSI será desabilitado por toda a vida do processo)
--etw                   Tenta desabilitar o ETW via patching in-memory (Se bem-sucedido, ETW será desabilitado por toda a vida do processo, a menos que revertido)
--revertetw             Tenta desabilitar o ETW via patching in-memory e depois o repatcha de volta ao estado original
--pipe                  Altera o nome padrão do named pipe (valor padrão é totesLegit e é definido via script aggressor incluído)
--mailslot              Alterna para uso de mailslots para redirecionar a saída do console. Altera o nome padrão do mailslot (Se deixado em branco, valor padrão é totesLegit e é definido via script aggressor incluído)
--main                  Altera o ponto de entrada para Main() (valor padrão é Main(string[] args))

Caso de Uso

Executar assembly .NET

Sintaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe

Caso de Uso

Executar assembly .NET com argumentos

Sintaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker

Caso de Uso

Executar assembly .NET com argumentos e desabilitar AMSI

Sintaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi

Caso de Uso

Executar assembly .NET com argumentos e desabilitar ETW

Sintaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --etw

Caso de Uso

Executar assembly .NET com argumentos e redirecionar saída via mailslots em vez do named pipe padrão

Sintaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --mailslot

Caso de Uso

Executar assembly .NET com argumentos e alterar o nome do named pipe padrão definido no script aggressor

Sintaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --pipe forRealLegit

Caso de Uso

Executar assembly .NET e alterar o app domain padrão definido no script aggressor

Sintaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --appdomain forRealLegit

Caso de Uso

Executar assembly .NET com ponto de entrada Main() em vez do padrão Main(string[] args)

Sintaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/simpleMain.exe --main

Caso de Uso

Ir com tudo (Go HAM)

Sintaxe

beacon> inlineExecute-Assembly --dotnetassembly /root/Desktop/Seatbelt.exe --assemblyargs AntiVirus AppLocker --amsi --etw --appdomain forRealLegit --mailslot forRealLegit

Advertências

1. Embora eu tenha tentado tornar isso o mais estável possível, não há garantias de que nada travará ou que beacons não morrerão. Não temos o luxo adicional do fork and run onde, se algo der errado, nosso beacon sobrevive. Este é o trade-off com BOFs. Dito isso, não posso enfatizar o suficiente a importância de testar seus assemblies com antecedência para garantir que funcionarão corretamente com a ferramenta.
2. Como o BOF é executado in-process e assume o controle do beacon enquanto está em execução, isso deve ser levado em consideração antes de ser usado para assemblies de longa duração. Se você optar por executar algo que levará muito tempo para obter resultados, seu beacon não estará ativo para executar mais comandos até que os resultados retornem e seu assembly termine a execução. Isso também não segue o sleep set. Por exemplo, se seu sleep estiver configurado para 10 minutos e você executar o BOF, receberá os resultados assim que o BOF terminar a execução.
3. A menos que seja feita modificação em ferramentas que carregam PE’s na memória (por exemplo, SafetyKatz), estas provavelmente matarão seu beacon. Muitas dessas ferramentas funcionam bem com execute assembly porque conseguem enviar sua saída de console do processo sacrificial antes de sair. Quando elas saem via nosso BOF in-process, matam nosso processo, o que mata nosso beacon. Essas podem ser modificadas para funcionar, mas eu recomendo executar esses tipos de assemblies via execute assembly, já que outras coisas não amigáveis ao OPSEC podem ser carregadas em seu processo que não são removidas.
4. Se seu assembly usa Environment.Exit, isso precisará ser removido, pois matará o processo e o beacon.
5. Named pipes e mailslots precisam ser únicos. Se você não receber dados de volta e seu beacon ainda estiver ativo, o problema provavelmente é que você precisa selecionar um nome de named pipe ou mailslot diferente.

Detecção

Algumas estratégias de detecção e mitigação que poderiam ser usadas:

1. Usa PAGE_EXECUTE_READWRITE ao realizar patching de memória para AMSI e ETW. Isso foi feito intencionalmente e deve ser uma bandeira vermelha, pois muito poucos programas têm intervalos de memória com a proteção PAGE_EXECUTE_READWRITE.
2. O nome padrão do named pipe criado é totesLegit. Isso foi feito intencionalmente e detecções por assinatura podem ser usadas para sinalizar isso.
3. O nome padrão do mailslot criado é totesLegit. Isso foi feito intencionalmente e detecções por assinatura podem ser usadas para sinalizar isso.
4. O nome padrão do AppDomain carregado é totesLegit. Isso foi feito intencionalmente e detecções por assinatura podem ser usadas para sinalizar isso.
5. Boas dicas sobre detecção de uso malicioso de .NET (por @bohops) aqui, (por F-Secure) aqui, e aqui
6. Procurar por carregamento do CLR .NET em processos suspeitos, como processos não gerenciados que nunca deveriam ter o CLR carregado.
7. Rastreamento de Eventos aqui
8. Procurar por outros IOC’s conhecidos do Cobalt Strike Beacon ou IOC’s de egresso/comunicação C2.