Shellcode Fluctuation PoC

Uma implementação de PoC para mais uma técnica de evasão em memória que criptografa e descriptografa ciclicamente o conteúdo do shellcode para então fazê-lo flutuar entre as proteções de memória RW (ou NoAccess) e RX. Quando nosso shellcode reside em páginas de memória RW ou NoAccess, scanners como Moneta ou pe-sieve não conseguirão rastreá-lo e despejá-lo para análises adicionais.

Introdução

Após lançar o ThreadStackSpoofer, recebi algumas perguntas sobre o seguinte ponto do README:

Altere a proteção das páginas de memória do seu Beacon para RW (de RX/RWX) e criptografe seu conteúdo antes de dormir (isso poderia evadir scanners como Moneta ou pe-sieve)

Antes, eu tinha quase certeza de que a comunidade já sabia como criptografar/descriptografar seus payloads e alterar suas proteções de memória para simplesmente evadir scanners de memória que procuram regiões executáveis anômalas. As perguntas provaram o contrário, então decidi lançar este PoC não armamentado para documentar mais uma estratégia de evasão e oferecer uma implementação de exemplo para a comunidade trabalhar.

Este PoC é uma demonstração de uma técnica bastante simples, já conhecida pela comunidade ofensiva (então não estou trazendo nada de novo aqui, na verdade), na esperança de revelar o segredo por trás da mágica mostrada por alguns frameworks comerciais que demonstram suas capacidades de evasão mirando ambos os scanners de memória mencionados.

Aqui está uma comparação ao flutuar para RW (outra opção é flutuar para PAGE_NOACCESS - descrito abaixo):

1. Beacon não criptografado
2. Beacon criptografado (flutuando)

Esta implementação, juntamente com meu ThreadStackSpoofer, traz à comunidade de Segurança Ofensiva implementações de exemplo para acompanhar o que é oferecido pelos produtos C2 comerciais, para que possamos não fazer pior em nossas ferramentas de Red Team. 💪

---

Como funciona?

Este programa realiza auto-injeção de shellcode (aproximadamente via clássico VirtualAlloc + memcpy + CreateThread). Quando o shellcode é executado (esta implementação visa especificamente implantes Cobalt Strike Beacon), uma função do Windows será hookada interceptando o momento em que o Beacon adormece, kernel32!Sleep. Sempre que a função hookada MySleep é invocada, ela localiza os limites de sua alocação de memória, altera a proteção para RW e aplica xor32 em todos os bytes armazenados ali. Após aguardar o tempo esperado, quando o shellcode retorna ao nosso handler MySleep, descriptografamos os dados do shellcode e revertemos a proteção para RX.

A flutuação para PAGE_READWRITE funciona da seguinte forma

1. Ler o conteúdo do shellcode do arquivo.
2. Hookar kernel32!Sleep apontando de volta para o nosso callback.
3. Injetar e executar o shellcode via VirtualAlloc + memcpy + CreateThread. Ao contrário do que tínhamos no ThreadStackSpoofer, aqui não estamos hookando nada na ntdll para executar nosso shellcode, mas sim saltando para ele a partir de nossa própria função. Isso tenta evitar deixar IOCs simples na memória apontando para memória modificada da ntdll.
4. Assim que o Beacon tenta dormir, nosso callback MySleep é invocado.
5. A alocação de memória do Beacon é criptografada e a proteção alterada para RW
6. Em seguida, removemos o hook do kernel32!Sleep original para evitar deixar um IOC simples na memória indicando que Sleep foi trampolinada (hookada in-line).
7. Uma chamada ao ::Sleep original é feita para deixar o Beacon dormir enquanto aguarda novas comunicações.
8. Após o Sleep terminar, descriptografamos os dados do shellcode, revertemos as proteções de memória para RX e então re-hookamos kernel32!Sleep para garantir a interceptação dos sleeps seguintes.

A flutuação para PAGE_NOACCESS funciona da seguinte forma

1. Ler o conteúdo do shellcode do arquivo.
2. Hookar kernel32!Sleep apontando de volta para o nosso callback.
3. Injetar e executar o shellcode via VirtualAlloc + memcpy + CreateThread ...
4. Inicializar um Vectored Exception Handler (VEH) para configurar nosso próprio handler que capturará exceções Access Violation.
5. Assim que o Beacon tenta dormir, nosso callback MySleep é invocado.
6. A alocação de memória do Beacon é criptografada e a proteção alterada para PAGE_NOACCESS
7. Em seguida, removemos o hook do kernel32!Sleep original para evitar deixar um IOC simples na memória indicando que Sleep foi trampolinada (hookada in-line).
8. Uma chamada ao ::Sleep original é feita para deixar o Beacon dormir enquanto aguarda novas comunicações.
9. Após o Sleep terminar, re-hookamos kernel32!Sleep para garantir a interceptação dos sleeps seguintes.
10. O shellcode então tenta retomar sua execução, o que resulta em uma Access Violation sendo lançada, já que suas páginas estão marcadas como NoAccess.
11. Nosso VEH Handler captura a exceção, descriptografa e reverte as proteções de memória para RX, e o shellcode é retomado.

---

Não é uma técnica nova

A técnica não é nova, nem algo que eu tenha criado. É apenas uma implementação mostrando o conceito e sua utilização prática para permitir que nossa comunidade de Segurança Ofensiva acompanhe o que é oferecido pelos frameworks C2 comerciais.

Na verdade, fui apresentado à ideia de alternar a proteção de memória do shellcode há alguns anos, através do trabalho de Josh Lospinoso em seu incrível Gargoyle.

Aqui está mais contexto:

• gargoyle, uma técnica de evasão de varredura de memória
• Contornando Scanners de Memória com Cobalt Strike e Gargoyle

Gargoyle leva o conceito de shellcode autoconsciente e autoflutuante um passo adiante, utilizando uma sequência de ROP que chama VirtualProtect. No entanto, por mais impressionante que seja a técnica, é igualmente difícil utilizá-la com o Beacon do Cobalt Strike sem ter que matar sua thread e ficar reinicializando o Beacon na memória.

Isso está longe de ser perfeito; no entanto, como já operamos a partir da base do nosso próprio processo loader de auto-injeção, podemos fazer o que quisermos com o ambiente no qual o shellcode opera e ocultá-lo como preferirmos. Esta técnica (e a anterior, o ThreadStackSpoofer) mostra as vantagens de executar nossos shellcodes dessa forma.

A implementação da flutuação para PAGE_NOACCESS é inspirada no trabalho de ORCA666 apresentado em seu injetor https://github.com/ORCA666/0x41. Ele mostrou que:

1. podemos inicializar um vectored exception handler (VEH),
2. alterar as páginas do shellcode para sem acesso (no-access)
3. e então capturar exceções de Access Violation que ocorrerão assim que o shellcode quiser retomar sua execução e descriptografar + reverter suas páginas de memória para Read+Execute.

Esta implementação contém essa ideia implementada, disponível com a opção 2 em <fluctuate>. Não deixe de conferir também os outros projetos dele.

---

Demonstração