Nach der Installation des VEH wird die Ausführung des Hauptthreads auf den Payload-Entrypoint umgeleitet. Wenn der HWBP am Entrypoint ausgelöst wird, stoppt der VEH bei jeder ausgeführten Assembly-Anweisung, entschlüsselt die nächste Assembly-Anweisung und verschlüsselt die zuvor entschlüsselte Anweisung, die als globale Variable gespeichert ist.

Dadurch wird im Grunde immer nur eine einzelne Assembly-Anweisung entschlüsselt, während der Rest des Payloads verschlüsselt bleibt.

Einschränkungen:

HINWEIS: Diese Technik ist ideal, um mit einem einfachen Shellcode wie msfvenom oder benutzerdefinierten Reverse-Shells einen ersten Zugang zu erhalten. Sie kann auch als anfänglicher Stage-1-Payload verwendet werden, der den Rest des Payloads vom C2-Server herunterlädt.

HINWEIS: Diese Technik ist nicht mit allen Payloads kompatibel (z. B. mit Reflective Loadern). Nachfolgend finden Sie eine Liste der aktuellen Einschränkungen:

• 1.) Da der VEH für JEDE ASSEMBLY-ANWEISUNG ausgelöst wird, die im Shellcode ausgeführt wird, wird die Ausführungsgeschwindigkeit des Shellcodes drastisch verlangsamt. Für jede Assembly-Anweisung, die die CPU ausführt, führt der VEH mindestens 300 zusätzliche ASM-Anweisungen aus, um die Entschlüsselung, Verschlüsselung und Wiederherstellung der Ausführung des Hauptthreads durchzuführen. Wenn der jeweilige Shellcode eher auf geringe Größe als auf Leistung optimiert ist (wie msfvenom), ist die Payload-Ausführung langsamer. Es kann über 15 Sekunden dauern (je nach CPU), um einen MSFVENOM auszuführen. Dies liegt daran, dass der von msfvenom verwendete Shellcode Leistung zugunsten einer kleineren Payload-Größe opfert.
• 2.) Wenn der Shellcode NtCreateThread oder einen seiner Wrapper in Kernelbase.dll mit dem Entrypoint innerhalb des Shellcodes aufruft, wird der Payload nicht funktionieren, da der VEH für diese Thread-Ausführung nicht ausgelöst wird, da kein HWBP am Entrypoint des neu erstellten Threads installiert ist. (In Arbeit - wird in diesem Repo weiter umgesetzt)
• 3.) Wenn der Shellcode Werte/Variablen in sich selbst gespeichert hat (z. B. den Rohstring "powershell.exe", der über einen Offset in einem Aufruf der WinExec-WINAPI referenziert wird) oder eine Zahl an einem Offset gespeichert ist, und der Shellcode später versucht, diese irgendwo zu laden oder zu referenzieren, wird das Programm nicht funktionieren, da die betreffende Variable oder der String verschlüsselt wird und der VEH diese nicht entschlüsselt. Wenn der Shellcode solche Argumente über Assembly-Anweisungen auf den Stack legt (push 0x4141414141414141, um "AAAAAAAA" auf den Stack zu legen, um es in einem Funktionsaufruf zu verwenden), funktioniert diese Technik. (In Arbeit - wird in diesem Repo weiter umgesetzt)

Verwendung:

So reproduzieren Sie den POC:

• 1.) Erstellen Sie Ihren msfvenom-Payload:

• 2.) Verwenden Sie XorEncryptPayload.exe, um den Payload per XOR zu verschlüsseln

• 3.) Aktualisieren Sie die Variable, die den Shellcode in der main.cpp des Voidgate-Projekts enthält
• 4.) Stellen Sie sicher, dass der XOR-Schlüssel mit dem Verschlüsselungsprogramm und dem Voidgate-Projekt übereinstimmt
• 5.) Stellen Sie sicher, dass Ihr Listener auf dem Angriffsrechner wartet:

• 6.) Führen Sie Voidgate.exe aus

Demo:

Haftungsausschluss

Dieses Repository dient akademischen Zwecken. Die Verwendung dieser Software liegt in Ihrer eigenen Verantwortung.