Dopo l'installazione del VEH, l'esecuzione del thread principale verrà reindirizzata all'entrypoint del payload. Quando l'HWBP verrà innescato all'entrypoint, il VEH si fermerà su ogni istruzione assembly eseguita, decritterà la successiva istruzione assembly e crittograferà la precedente istruzione decrittata, salvata come variabile globale.

In questo modo, fondamentalmente una singola istruzione assembly viene decrittata alla volta, mentre il resto del payload rimane crittografato.

Limitazioni:

NOTA: Questa tecnica è ideale per ottenere un accesso iniziale utilizzando uno shellcode di base come msfvenom o reverse shell personalizzate. Può anche essere usata come payload iniziale di stage 1 che scarica il resto del payload dal server C2.

NOTA: Questa tecnica non è compatibile con tutti i payload (come i reflective loader). Di seguito è riportato un elenco delle limitazioni attuali:

• 1.) Poiché il VEH scatterà per OGNI ISTRUZIONE ASSEMBLY eseguita nello shellcode, la velocità di esecuzione dello shellcode verrà drasticamente ridotta. Per ogni istruzione assembly eseguita dalla CPU, il VEH eseguirà almeno altre 300 istruzioni ASM per effettuare la decrittazione, la crittografia e il ripristino dell'esecuzione del thread principale. Se lo shellcode è ottimizzato per una dimensione ridotta piuttosto che per le prestazioni (come msfvenom), l'esecuzione del payload sarà più lenta. Può richiedere oltre 15 secondi (a seconda della CPU) per eseguire un MSFVENOM. Questo accade perché lo specifico shellcode usato da msfvenom sacrifica le prestazioni per ottenere una dimensione del payload inferiore.
• 2.) Se lo shellcode chiama NtCreateThread o uno qualsiasi dei suoi wrapper in Kernelbase.dll con l'entrypoint all'interno dello shellcode, il payload non funzionerà poiché il VEH non scatterà per l'esecuzione di quel thread, non essendoci nessun HWBP installato all'entrypoint del thread appena creato. (Lavori in corso - verrà implementato ulteriormente in questo repo)
• 3.) Se lo shellcode contiene valori/variabili al suo interno (ad esempio, la stringa grezza "powershell.exe" referenziata tramite un offset in una chiamata a WinExec WINAPI) o alcuni numeri salvati a un offset, e lo shellcode tenterà successivamente di caricarli o referenziarli da qualche parte, il programma non funzionerà poiché quella specifica variabile o stringa verrà crittografata e il VEH non la decritta. Se lo shellcode inserisce tali argomenti nello stack tramite istruzioni assembly (push 0x4141414141414141 per inserire "AAAAAAAA" nello stack da usare in una chiamata a una funzione), questa tecnica funzionerà. (Lavori in corso - verrà implementato ulteriormente in questo repo)

Utilizzo:

Come riprodurre il POC:

• 1.) Crea il tuo payload msfvenom:

• 2.) Usa XorEncryptPayload.exe per crittografare il payload con XOR

• 3.) Aggiorna la variabile che contiene lo shellcode all'interno del main.cpp del progetto Voidgate
• 4.) Assicurati che la chiave xor corrisponda tra l'encryptor e il progetto Voidgate
• 5.) Assicurati che il tuo listener sia in ascolto sulla macchina dell'attaccante:

• 6.) Esegui Voidgate.exe

Demo:

Disclaimer

Questo repository è a scopo accademico, l'uso di questo software è di tua responsabilità.