Após a instalação do VEH, a execução da thread principal será redirecionada para o ponto de entrada do payload. Quando a HWBP for acionada no ponto de entrada, o VEH parará em cada instrução de assembly executada, realizará a descriptografia da próxima instrução de assembly e criptografará a instrução anteriormente descriptografada, que é salva como uma variável global.

Com isso, basicamente uma única instrução de assembly é descriptografada por vez, com o restante do payload permanecendo criptografado.

Limitações:

NOTA: Esta técnica é ideal para obter um acesso inicial usando um shellcode básico, como msfvenom ou shells reversos personalizados. Ela também pode ser usada como um payload de estágio 1 inicial que baixa o restante do payload do servidor C2.

NOTA: Esta técnica não é compatível com todos os payloads (como reflective loaders). Abaixo está uma lista das limitações atuais:

• 1.) Como o VEH será acionado para CADA INSTRUÇÃO DE ASSEMBLY executada no shellcode, a velocidade de execução do shellcode será drasticamente reduzida. Para cada instrução de assembly que a CPU executa, o VEH executará pelo menos mais 300 instruções ASM para realizar a descriptografia, criptografia e restaurar a execução para a thread principal. Se o shellcode em questão for otimizado para tamanho menor em vez de desempenho (como o msfvenom), a execução do payload será mais lenta. Pode levar mais de 15 segundos (dependendo da CPU) para executar um MSFVENOM. Isso acontece porque o shellcode específico usado pelo msfvenom sacrifica desempenho para obter um tamanho menor de payload.
• 2.) Se o shellcode chamar NtCreateThread ou qualquer um de seus wrappers em Kernelbase.dll com o ponto de entrada dentro do shellcode, o payload não funcionará, pois o VEH não será acionado para a execução dessa thread, já que não há HWBP instalada no ponto de entrada da thread recém-criada. (Trabalho em andamento - será implementado mais adiante neste repositório)
• 3.) Se o shellcode tiver alguns valores/variáveis armazenados dentro dele (por exemplo, ter a string bruta "powershell.exe" que é referenciada via um offset em uma chamada para WinExec WINAPI) ou algum número salvo em um offset, e o shellcode depois tentar carregar ou referenciá-lo em algum lugar, o programa não funcionará, pois a variável ou string específica será criptografada e o VEH não a descriptografa. Se o shellcode empurrar tais argumentos para a pilha via instruções de assembly (push 0x4141414141414141 para colocar "AAAAAAAA" na pilha para ser usado em uma chamada a uma função), esta técnica funcionará. (Trabalho em andamento - será implementado mais adiante neste repositório)

Uso:

Como reproduzir o POC:

• 1.) Crie seu payload msfvenom:

• 2.) Use o XorEncryptPayload.exe para criptografar o payload com XOR

• 3.) Atualize a variável que contém o shellcode dentro do main.cpp do projeto Voidgate
• 4.) Garanta que a chave xor corresponda ao criptografador e ao projeto Voidgate
• 5.) Garanta que seu listener esteja aguardando na máquina de ataque:

• 6.) Execute o Voidgate.exe

Demonstração:

Aviso Legal

Este repositório é para fins acadêmicos, o uso deste software é de sua responsabilidade.