octoberfest7/beatrevPOC para frustrar/derrotar analistas de malware
O trabalho a seguir é uma POC para permitir que malwares se "vinculem" a uma vítima específica, a fim de frustrar os esforços de analistas de malware.
Não assumo nenhuma responsabilidade pelo uso malicioso de qualquer ideia ou código contido neste projeto. Disponibilizo esta pesquisa para educar ainda mais profissionais de segurança da informação e fornecer treinamento adicional / alimento para reflexão para Analistas de Malware, Engenheiros Reversos e Equipes Azuis em geral.
Na primeira vez que o malware é executado em uma vítima, ele criptografa via AES a carga útil real (um RDLL) usando dados ambientais dessa vítima. Cada vez subsequente que o malware é executado, ele coleta as mesmas informações ambientais, descriptografa via AES a carga útil armazenada como um array de bytes dentro do malware e a executa. Se a descriptografia falhar / a carga útil não executar, o malware se autoexclui. Proteção contra engenheiros reversos e analistas de malware.
Não senti que este projeto estava finalizado, então voltei e fiz uma reescrita bastante substancial. A pesquisa original e o tradecraft podem ser encontrados Aqui.
As principais mudanças são as seguintes:
Existem várias coisas diferentes que podem ser tiradas do código-fonte deste projeto para uso em outros lugares. Espero que seja útil para alguém.
Havia algumas deficiências na versão original do BeatRev que decidi tentar resolver.
O Stage2 era anteriormente um executável independente armazenado como um fluxo de dados alternativo (ADS) do Stage1. Para alcançar a criptografia AES por vítima e a subsequente descriptografia e execução, cada vez que o Stage1 era executado, ele lia o ADS, descriptografava, escrevia de volta no ADS, chamava CreateProcess e, em seguida, recriptografava o Stage2 e o escrevia de volta no disco no ADS. Isso gerava muitas operações de I/O e a chamada CreateProcess, claro, não era ideal.
Me deparei com a pesquisa de Steven Fewer sobre DLLs Refletivas e pareceu uma boa adaptação. Stage2 agora é um RDLL; nosso malware / runner de shellcode / qualquer coisa que queiramos proteger pode ser portado para o formato RDLL e armazenado como um array de bytes dentro do Stage1, que é então descriptografado em tempo de execução e executado pelo Stage1. Isso remove todas as operações de I/O e a chamada CreateProcess da Versão 1 e é uma mudança bem-vinda.
O Stage1 não tinha nenhum tipo de medida real de evasão de AV programada; isso foi intencional, pois é trabalho extra e não era realmente o objetivo desta pesquisa. Durante a reescrita, encarei isso como um desafio adicional e adicionei hash de API para remover funções da Tabela de Endereços de Importação do Stage1. Isso ajudou na detecção e o Stage1 tem uma taxa de detecção de 4/66 no VirusTotal. Senti-me confortável em enviar o Stage1, dado que ele já está vinculado à máquina original onde foi executado e a assinatura do arquivo muda constantemente devido à criptografia AES que ocorre.
Recentemente, comecei a prestar atenção na entropia como meio de detectar malware; para tentar reduzir a entropia, que de outra forma seria muito alta devido a um blob binário gigante criptografado com AES, pesquisei a integração de shellcode armazenado como UUIDs. Como o binário é armazenado em representação de string, há menor entropia geral no executável. Usando essa técnica, a entropia do Stage0 agora é de aproximadamente 6,8 e do Stage1 de ~4,5 (em uma escala máxima de 8).
Finalmente, é uma tarefa enorme integrar e produzir um Stage0 completo devido a todas as peças que precisam ser manipuladas. Para facilitar isso, criei um aplicativo builder que ingere um arquivo de template Stage0.c, um stub Stage1, um stub Stage2 e um arquivo de shellcode bruto (isso foi construído em torno do Stage2 sendo um runner de shellcode contendo shellcode do CobaltStrike) e produz um payload Stage0 compilado para uso no alvo.
O código DLL Refletiva de Stephen Fewer contém algumas instruções específicas do compilador Visual Studio; tenho certeza de que é possível portar a técnica para o MingW, mas não tenho as habilidades para fazê-lo. O principal problema aqui é que o shellcode do CobaltStrike (sem estado é ~265K) precisa ir dentro do RDLL e ser compilado. Para contornar isso e integrá-lo bem com o resto do processo, escrevi meu RDLL Stage2 para conter um bloco de memória variável global do tamanho do shellcode CS; esse bloco de memória de ~265K tem um pequeno placeholder que pode ser localizado no binário compilado. O código em src/Stage2 já tem isso adicionado.
Uma vez compilado, este Stage2stub é transferido para o kali onde um patch binário pode ser realizado para colocar o shellcode CS real no local de memória que lhe pertence. Isso produz o Stage2 completo.
Para evitar o fiasco de I/O e CreateProcess descrito anteriormente, o Stage2 completo também deve ser patchado no Stage1 compilado pelo Stage0; isso é necessário para permitir que o Stage2 seja criptografado uma vez no alvo, além de evitar que o Stage2 seja armazenado separadamente no disco. O mesmo conceito descrito anteriormente para o Stage2 é conduzido pelo Stage0 no alvo para montar o payload final do Stage1. Deve-se notar que a função memmem é usada para localizar o placeholder dentro de cada stub; esta função não está disponível no Windows, então uma implementação personalizada foi usada. Agradecimentos ao Foxik384 por seu código.
Para realizar um patch binário, devemos alocar a memória necessária antecipadamente; isso tem um efeito composto, pois o Stage1 agora deve ser grande o suficiente para conter também o Stage2. Com a etapa adicional de converter o Stage2 em uma string UUID, o Stage2 aumenta de tamanho, assim como o Stage1 para armazená-lo. Um RDLL Stage2 com tamanho compilado de ~290K resulta em um payload Stage0 de ~1,38M e um payload Stage1 de ~700K.
O aplicativo builder suporta apenas a criação de EXEs x64. No entanto, com um pouco mais de trabalho, em teoria, você poderia fazer do Stage0 uma DLL, assim como do Stage1, e fazer todo o ciclo de vida existir como um sequestro de DLL em vez de um executável independente.
Estas instruções o guiarão no uso desta POC.
