winterknife/pinkpantherHandgefertigter Windows-x64-Kernel-Mode-Shellcode zum Token-Diebstahl
Windows x64 handgefertigter Kernel-Mode-Shellcode, um das primäre Zugriffstoken des ausgeführten Prozesses durch das SYSTEM-Prozesstoken zu ersetzen, zur Elevation of Privilege(EoP).
Windows 7/Windows Server 2008 R2 Build 7601Windows 8/Windows Server 2012 Build 9200Windows 8.1/Windows Server 2012 R2 Build 9600Windows 10 1507/TS1 Build 10240Windows 10 1511/TS2 Build 10586Windows 10 1607/RS1/Windows Server 2016 Build 14393Windows 10 1703/RS2 Build 15063Windows 10 1709/RS3 Build 16299Windows 10 1803/RS4 Build 17134Windows 10 1809/RS5/Windows Server 2019 Build 17763Windows 10 1903/19H1 Build 18362Windows 10 1909/19H2 Build 18363Windows 10 2004/20H1 Build 19041Windows 10 2009/20H2 Build 19042Windows 10 2104/21H1 Build 19043Windows 10 2110/21H2 Build 19044Die Voraussetzungen für die Erstellung dieses Projekts sind:
Visual Studio 2019(any edition will do fine)Windows 10 SDK, version 2004Windows 10 WDK, version 2004Python3An dieser Stelle sei angemerkt, dass man auch nur mit einem Assembler auskommt (dieses Projekt verwendet MASM), denn technisch gesehen ist das alles, was man braucht.
Nach der Installation der oben genannten Komponenten ist es so einfach wie das Öffnen der Projektmappe mit Visual Studio und das Erstellen für das Ziel x64.
Nach einem erfolgreichen Build befinden sich die Binärdateien im Bin-Verzeichnis im entsprechenden Unterverzeichnis der Bitbreite.
Alternativ können Sie einsatzbereiten positionsunabhängigen Shellcode aus Releases herunterladen.
Bitte versuchen Sie NICHT, den Payload auf einem Rechner einzusetzen, auf den Sie für Ihre Arbeit angewiesen sind, wenn Sie sich nicht sicher sind, wie er funktioniert.
Weitere Informationen finden Sie in der Microsoft-Dokumentation.
Zu Testzwecken empfehle ich dringend, flare-kscldr zum Bereitstellen des Kernel-Mode-Shellcodes auf einer Test-VM zu verwenden sowie CodeMachine-Anleitung zur Systemeinrichtung für Kernel-Entwicklung und -Debugging, um eine Hyper-V-Gast-VM mit vollständiger Kernel-Debugging-Unterstützung einzurichten.
Optional können Sie den Prozess auch mit kdbg-driver-vagrant automatisieren, um schnell eine Test-VM mit vollständigem Kernel-Debugging mithilfe von Vagrant hochzufahren.
Wie mir Dmytro Oleksiuk(@d_olex) mitgeteilt hat, gibt es einige nicht gerade subtile Race Conditions im Code, die insbesondere mit Folgendem zusammenhängen:
nt!_EPROCESS-Strukturen, die über eine zirkuläre doppelt verkettete Liste miteinander verbunden sind, ohne eine Art Synchronisierungsprimitive/Sperrmechanismus zu verwendenSie verfügen derzeit über keinerlei Schutz gegen Änderungen, die an ihnen vorgenommen werden, während wir daran arbeiten.
Ist das ein Problem? Ja, Race Conditions sind immer problematisch und können alle möglichen unangenehmen Folgen wie undefiniertes Verhalten/Bugchecks verursachen.
Wird die Verwendung dieses Payloads die Stabilität meines Exploits beeinträchtigen? Möglicherweise.
Was ist also die Lösung? Die Lösung besteht aus zwei Schritten.
Teil 1 umfasst das Erlangen einer Wartesperre wie Pushlocks - nt!PspActiveProcessLock(Pushlock-Zeiger) für exklusiven Zugriff mithilfe von nt!ExAcquirePushLockExclusive, bevor die Prozessliste durchlaufen wird (die normale Kernel-APC-Zustellung muss zuvor deaktiviert werden) und nt!ExReleasePushLockExclusive, um die Sperre freizugeben, sobald wir die Liste nicht mehr verwenden. An diesem Punkt sollte die normale Kernel-APC-Zustellung wieder aktiviert werden.
Da diese globale Variable jedoch nicht vom nt-Kernel exportiert wird, wäre ein wesentlich besserer und sicherer Ansatz, die nt!ZwQuerySystemInformation-API mit SYSTEM_INFORMATION_CLASS == SystemProcessInformation zu verwenden, um die PID aus dem ImageName zu ermitteln, und nt!PsLookupProcessByProcessId, um die nt!_EPROCESS VA aus der PID zu erhalten.
Wenn Sie jedoch neugierig sind, wie der Kernel Ersteres macht, bitte ich Sie, sich nt!PsGetNextProcess in einem Disassembler anzusehen.
Teil 2 umfasst das sichere Referenzieren von Objekten mithilfe der nt!ObReferenceObject-Familie von APIs, um die Referenzanzahl des Prozessobjekts zu erhöhen, sodass es nicht gelöscht werden kann, bis wir sie am Ende explizit verringern, sobald wir damit fertig sind, mithilfe von nt!ObDereferenceObject.
Beachten Sie, dass das manuelle Erhöhen der Referenzanzahl überflüssig ist, da ein Aufruf von nt!PsLookupProcessByProcessId dies bei Erfolg automatisch für uns erledigt.
Die Implementierung dieser Korrekturen würde jedoch erfordern, die Basisadresse von ntoskrnl.exe zu finden und die darin enthaltenen Symbole aufzulösen, indem man das EAT durchläuft, um die Funktionszeiger mithilfe eines String-Hashing-Algorithmus zu finden, was alles die Payload-Größe drastisch erhöhen würde.
Ich werde mich vielleicht eines Tages dazu entschließen, das zu implementieren, oder einfach in C schreiben und die Compiler-Ausgabe zumüllen :)
Dank an Dmytro Oleksiuk(@d_olex) und Paul L.(@am0nsec) für das Aufzeigen der Fehler und auch für den Vorschlag der Lösung.