optiv/freeze.rsFreeze.rs é um kit de ferramentas de payload para contornar EDRs usando processos suspensos, syscalls diretos escritos em RUST
Para ver a versão mais recente do Freeze.rs ou enviar um problema, consulte https://github.com/Tylous/Freeze.rs.
Se você quiser saber mais sobre as técnicas utilizadas neste framework, dê uma olhada no SourceZero Blog e na ferramenta original.
Freeze.rs é uma ferramenta de criação de payload usada para contornar controles de segurança de EDR e executar shellcode de forma furtiva. Freeze.rs utiliza múltiplas técnicas não apenas para remover hooks de EDR no espaço do usuário, mas também para executar shellcode de modo a contornar outros controles de monitoramento de endpoint.
Quando um processo é criado, Ntdll.dll é a primeira DLL a ser carregada; isso acontece antes de qualquer DLL de EDR ser carregada. Isso significa que há um pequeno atraso antes que um EDR possa ser carregado e começar a hooking e modificar a montagem das DLLs do sistema. Observando as chamadas de sistema do Windows em Ntdll.dll, podemos ver que nada ainda foi hookado. Se criarmos um processo em estado suspenso (um que está congelado no tempo), podemos ver que nenhuma outra DLL é carregada, exceto Ntdll.dll. Você também pode ver que nenhuma DLL de EDR é carregada, o que significa que as syscalls localizadas em Ntdll.dll não estão modificadas.
Para usar esse processo suspenso limpo para remover hooks do carregador do Freeze.rs, precisamos de uma maneira de encontrar e ler programaticamente a memória do processo suspenso limpo. É aqui que entra a aleatoriedade do layout do espaço de endereço (ASLR). ASLR é um mecanismo de segurança para evitar vulnerabilidades baseadas em corrupção de memória da pilha. O ASLR randomiza o espaço de endereço dentro de um processo, para garantir que todos os objetos mapeados na memória, a pilha, o heap e o próprio programa executável sejam únicos. Agora, é aqui que fica interessante porque, embora o ASLR funcione, ele não funciona para código independente de posição, como DLLs. O que acontece com as DLLs (especificamente DLLs de sistema conhecidas) é que o espaço de endereço é randomizado uma vez na inicialização. Isso significa que não precisamos enumerar informações de um processo remoto para encontrar o endereço base de sua ntdll.dll, porque ele é o mesmo em todos os processos, incluindo aquele que controlamos. Como o endereço de cada DLL é o mesmo lugar por inicialização, podemos obter essas informações do nosso próprio processo e nunca precisar enumerar o processo suspenso para encontrar o endereço.
Com essas informações, podemos usar a API ReadProcessMemory para ler a memória de um processo. Essa chamada de API é comumente associada à leitura do LSASS como parte de qualquer ataque baseado em credenciais; no entanto, por si só, não é inerentemente maliciosa, especialmente se estamos apenas lendo uma seção arbitrária da memória. A única vez que ReadProcessMemory será sinalizada como parte de algo suspeito é se você estiver lendo algo que não deveria (como o conteúdo do LSASS). Os produtos de EDR nunca devem sinalizar o fato de que ReadProcessMemory foi chamado, pois existem usos operacionais legítimos para essa função e resultaria em muitos falsos positivos.
Podemos ir um passo além, lendo apenas uma seção da Ntdll.dll onde todas as syscalls estão armazenadas - sua seção .text, em vez de ler toda a DLL.
Combinando esses elementos, podemos obter programaticamente uma cópia da seção .text da Ntdll.dll para sobrescrever nossa seção .text existente que foi hookada antes de executar o shellcode.
O ETW utiliza syscalls internas para gerar essa telemetria. Como o ETW também é um recurso nativo do Windows, os produtos de segurança não precisam "hookar" as syscalls do ETW para acessar as informações. Como resultado, para prevenir o ETW, o Freeze.rs aplica patches em várias syscalls do ETW, limpando os registradores e retornando o fluxo de execução para a próxima instrução. O patch do ETW agora é padrão em todos os carregadores.
Como apenas Ntdll.dll é restaurada, todas as chamadas subsequentes para executar o shellcode precisam residir em Ntdll.dll. Usando o crate NTAPI do Rust (note que você pode fazer isso em outras linguagens, mas em Rust é bastante fácil de implementar), podemos definir e chamar as syscalls NT necessárias para alocar, escrever e proteger o shellcode, efetivamente pulando as chamadas padrão localizadas em Kernel32.dll e Kernelbase.dll, pois estas podem ainda estar hookadas.
Com o crate NTAPI do Rust, você pode ver que todas essas chamadas não aparecem sob ntdll.dll, no entanto elas ainda existem dentro do processo.
Como resultado:
Isso começou como um projeto divertido para aprender Rust e se transformou em seu próprio framework.
Freeze.rs foi desenvolvido em Rust.
Se Rust e Rustup não estiverem instalados, por favor instale-os. Se você estiver compilando a partir do OSX ou Linux, certifique-se de ter o alvo "x86_64-pc-windows-gnu" adicionado. Para fazer isso, execute o seguinte comando:
rustup target add x86_64-pc-windows-gnu
Depois de feito, você pode compilar o Freeze.rs, executar os seguintes comandos ou usar o binário compilado:
cargo build --release
A partir daí, a versão compilada será encontrada em target/release (note que se você não colocar --release o arquivo estará em target/debug/ )
___________
\_ _____/______ ____ ____ ________ ____ _______ ______
| __) \_ __ \_/ __ \_/ __ \\___ // __ \ \_ __ \/ ___/
| \ | | \/\ ___/\ ___/ / /\ ___/ | | \/\___ \
\___ / |__| \___ >\___ >_____ \\___ > /\ |__| /____ >
\/ \/ \/ \/ \/ \/ \/
(@Tyl0us)
Em breve eles aprenderão que a vingança é um prato... melhor servido FRIO & Enferrujado...
USO:
Freeze-rs [SINALIZADORES] [OPÇÕES]
SINALIZADORES:
-c, --console Apenas para Payloads Binários - Gera informações detalhadas no console quando o payload é executado. Isso desabilitará o recurso de janela oculta
-h, --help Exibe informações de ajuda
-n, --noetw Desabilita o patch do ETW que impede a geração de eventos ETW.
-s, --sandbox Ativa a evasão de sandbox verificando:
O Endpoint está associado a um domínio?
O Endpoint tem mais de 2 CPUs?
O Endpoint tem mais de 4 GB de RAM?
-V, --version Exibe informações da versão
OPÇÕES:
-E, --Encrypt <ENCRYPT> Criptografa o shellcode usando criptografia AES 256, ELZMA ou RC4
-I, --Input <INPUT> Caminho para o shellcode bruto de 64 bits.
-O, --Output <OUTPUT> Nome do arquivo de saída (ex.: loader.exe ou loader.dll). Dependendo da extensão do arquivo definida, determinará se o Freeze gera uma dll ou exe.
-p, --process <PROCESS> O nome do processo a ser criado. Este processo deve existir em C:\Windows\System32\. Exemplo 'notepad.exe'
-e, --export <export> Define um nome de função de exportação personalizada para qualquer DLL.
Freeze.rs pode gerar tanto um arquivo .exe quanto .dll. Para especificar isso, certifique-se de que a opção de linha de comando -O termine com .exe para binários ou .dll para DLLs. Nenhum outro tipo de arquivo é atualmente suportado. No caso de arquivos DLL, o Freeze.rs também pode adicionar funcionalidade de exportação adicional. Para fazer isso, use -export com o nome da função de exportação específica.
Criptografar shellcode é uma técnica importante usada para protegê-lo de ser detectado e analisado por EDRs e outros produtos de segurança. O Freeze.rs vem com múltiplos métodos para criptografar shellcode, incluindo AES, ELZMA e RC4.
AES (Advanced Encryption Standard) é um algoritmo de criptografia simétrica amplamente utilizado para criptografar dados. O Freeze.rs usa tamanho de 256 bits AES para criptografar o shellcode. A vantagem de usar AES para criptografar shellcode é que ele fornece criptografia forte e é amplamente suportado por bibliotecas criptográficas. No entanto, o uso de um tamanho de bloco fixo pode torná-lo vulnerável a certos ataques, como o ataque de padding oracle.
ELZMA é um algoritmo de compressão e criptografia frequentemente usado em malware para ofuscar o código. Para criptografar shellcode usando ELZMA, o shellcode é primeiro comprimido usando o algoritmo ELZMA. Os dados comprimidos são então criptografados usando uma chave aleatória. Os dados criptografados e a chave são então incorporados no código do exploit. A vantagem de usar ELZMA para criptografar shellcode é que ele fornece compressão e criptografia em um único algoritmo. Isso pode ajudar a reduzir o tamanho do código do exploit e torná-lo mais difícil de detectar.
RC4 é um algoritmo de criptografia simétrica frequentemente usado em malware para criptografar shellcode. É uma cifra de fluxo que pode usar chaves de tamanho variável e é conhecida por sua simplicidade e velocidade.
Freeze.rs utiliza uma técnica de primeiro criar o processo e depois movê-lo para segundo plano. Isso faz duas coisas - primeiro ajuda a manter o processo oculto e, segundo, evita ser detectado por qualquer produto EDR. Criar um processo imediatamente em segundo plano pode ser muito suspeito e um indicador de maliciosidade. O Freeze.rs faz isso chamando as funções do Windows ‘GetConsoleWindow’ e ‘ShowWindow’ após o processo ser criado e os hooks do EDR serem carregados, e então altera os atributos da janela para oculto.
Se a opção de linha de comando -console for selecionada, o Freeze.rs não ocultará o processo em segundo plano. Em vez disso, o Freeze.rs adicionará várias mensagens de depuração exibindo o que o carregador está fazendo.