gmh5225/cs-dropspawn_bof# CobaltStrike BOF zum Starten von Beacons mittels DLL Application Directory Hijacking
DropSpawn ist ein CobaltStrike-BOF, das verwendet wird, um zusätzliche Beacons über eine relativ unbekannte Methode des DLL-Hijackings zu starten. Funktioniert x86-x86, x64-x64 und x86-x64/umgekehrt. Verwenden Sie es als Alternative zur Prozessinjektion.
Windows-Executables folgen der DLL-Suchreihenfolge, wenn sie versuchen, DLLs zu laden, deren absolute Pfade nicht angegeben wurden:
DLL-Hijacking erfordert typischerweise, dass entweder:
A. Ein Benutzer Schreibrechte in einem Ordner hat, der eine höhere Suchreihenfolge-Präzedenz hat als der, in dem sich die echte DLL befindet
oder
B. Dass die betreffende DLL nirgendwo auf dem System existiert, in welchem Fall sie in einem benutzerbeschreibbaren Ordner in der %PATH%-Variable des Benutzers abgelegt werden kann (wie %USERPROFILE%\appdata\local\microsoft\windowsapps).
Diese Anforderungen schließen DLL-Hijacking für Executables aus, die sich in C:\Windows\System32 befinden, da fast alle DLLs, die diese Executables laden, sich ebenfalls in System32 befinden. Das Kopieren eines System32-Executables an einen benutzerbeschreibbaren Ort und dessen Ausführung dort ist eine Option, aber nicht sehr OPSEC-sicher, da System32-Binaries, die von alternativen Orten ausgeführt werden, leicht zu identifizieren sind.
DropSpawn ermöglicht DLL-Hijacking mit System32-Executables (und anderen, die in zusätzlichen nicht-benutzerbeschreibbaren Ordnern gefunden werden), indem es "Das Verzeichnis, aus dem die Anwendung geladen wird" auf ein beliebiges, vom Benutzer angegebenes Verzeichnis spoofed.
Die öffentliche Version von DropSpawn unterscheidet sich geringfügig von der nicht-öffentlichen. Die nicht-öffentliche Version nutzt einen proprietären Payload-Generator, was die Erfahrung für den Operator wesentlich nahtloser macht. Die öffentliche Version wurde leicht verändert, um zu berücksichtigen, dass Benutzer ihre eigenen Wege haben, DLL-Hijack-kompatible Payloads zu generieren. Ein Python3-Skript sowie der Quellcode für eine Demonstrations-DLL wurden beigefügt, um Benutzern bei der Integration und Waffenisierung von DropSpawn zu helfen.
Identifizieren Sie einige Ziel-Executables, die versuchen, DLLs zu laden, ohne deren absolute Pfade anzugeben. Sie können dies tun, indem Sie die EXE in ein benutzerbeschreibbares Verzeichnis kopieren und sie ausführen, während Sie sie mit Procmon überwachen. In diesem Beispiel verwenden wir WerFault.exe, das normalerweise unter C:\Windows\System32\WerFault.exe liegt.
Im obigen Beispiel sind cryptsp.dll, wer.dll, dbghelp.dll und bcrypt.dll alle geeignete Kandidaten, da ihre absoluten Pfade nicht innerhalb von WerFault angegeben wurden; als Ergebnis wird WerFault versuchen, sie zuerst aus seinem Anwendungsverzeichnis zu laden, bevor es auf den Rest der DLL-Suchreihenfolge zurückgreift. Beachten Sie, dass dies normalerweise kein Problem darstellt, da das Anwendungsverzeichnis von WerFault System32 IST.
Laden Sie eine der hijackbaren DLLs vom Zielsystem herunter.
Dies ist notwendig, damit wir deren Exporte extrahieren und in unsere Payload-DLL aufnehmen können. Es ist wichtig, die hijackbare DLL von derselben Maschine zu holen, auf der Sie DropSpawn verwenden möchten, da sich DLLs zwischen Windows-Versionen ändern. Wenn Sie außerdem ein x86-Beacon ausführen und ein x64-Beacon mit DropSpawn starten möchten, stellen Sie sicher, dass Sie die x64-Version der echten DLL herunterladen, indem Sie 'C:\windows\sysnative...' anstelle von 'C:\windows\system32...' angeben.
Führen Sie generate_dll.py aus und übergeben Sie die heruntergeladene DLL und die gewünschte Payload-Architektur. Generate_dll.py ist eine modifizierte Version von diesem Skript. Es parst die bereitgestellte DLL, erstellt eine .def-Datei mit den Exporten der DLL und ruft MingW auf, um unsere Demonstrations-Payload-DLL zu kompilieren. Wenn der gestartete Prozess versucht, eine echte Funktion innerhalb der gespooften DLL aufzurufen, leitet unsere Payload-DLL den Aufruf an die echte DLL in System32 weiter, damit der Host-Prozess nicht abstürzt.
Rufen Sie DropSpawn mit der generierten Payload-DLL auf.
dropspawn <payload DLL> <x86|x64> <zu startendes Programm> [beschreibbarer Zielordner] [parent]
payload DLL - der vollständige Pfad zur generierten DLL-Payload.
Architektur - die Architektur des Prozesses, den Sie starten möchten
zu startendes Programm - der Name/Pfad des Prozesses, den Sie starten möchten. Wenn sich dieser Prozess in System32 (oder syswow64) befindet, können Sie einfach den Namen angeben. Andernfalls geben Sie den vollständigen Pfad an. Sie können dem Prozess auch Befehlszeilenargumente mitgeben. Wenn Leerzeichen im Pfad sind/wenn Sie Argumente verwenden, setzen Sie das Ganze in Anführungszeichen.
beschreibbarer Zielordner - Optional. Wenn leer gelassen, versucht DropSpawn, das aktuelle Verzeichnis des Beacons zu verwenden. Verwenden Sie Anführungszeichen, wenn Leerzeichen im Pfad sind.
parent - Optional. Der Name des Prozesses, der für PPID-Spoofing mit dem neu gestarteten Prozess verwendet werden soll. Wenn ein Prozess angegeben wird, der mehrere laufende Instanzen mit unterschiedlichen Berechtigungsstufen hat (z. B. svchost.exe), versucht DropSpawn, eine zu identifizieren, die für PPID-Spoofing verwendet werden kann.
Beispiel: dropspawn /root/dbgcore.dll x64 "WerFault.exe -u -p 4352 -s 160" C:\users\user\appdata\local\temp explorer.exe
Dies legt die Payload-DLL 'dbgcore.dll' unter 'c:\users\user\appdata\local\temp\dbgcore.dll' auf der Festplatte ab und startet einen x64-WerFault.exe-Prozess mit den Befehlszeilenargumenten '-u -p 4352 -s 160' und explorer.exe als Elternprozess.
Die Bereinigung ist einfach. Durch die Einbeziehung der Self-Deletion-Funktion in die Payload-DLL, die auf der Festplatte abgelegt wird, wird diese gelöscht, sobald unser neuer Prozess startet und sie lädt. Dies ist ein Game-Changer, da die DLL normalerweise so lange auf der Festplatte gesperrt wäre, wie unser Prozess, der sie geladen hat, weiterläuft. Wenn die Self-Deletion-Technik aus irgendeinem Grund fehlschlägt (oder der Prozess nicht startet), versucht DropSpawn, die Payload-DLL von der Festplatte zu löschen und informiert den Benutzer in jedem Fall über das Ergebnis der Operation.
Prozessinjektion folgt typischerweise der Kette "Remote-Prozess öffnen -> Remote-Speicher zuweisen -> Remote-Speicher schreiben -> Remote-Speicher ausführen", mit der Option, am Anfang einen neuen Prozess zu starten, anstatt einen vorhandenen zu verwenden. DropSpawn erstellt nur einen neuen Prozess; der neu gestartete Prozess ist für das Zuweisen, Schreiben und Ausführen von Shellcode verantwortlich, sodass wir viele der typischerweise mit Remote-Prozessinjektion verbundenen IOC vermeiden können.
Diese Technik ist natürlich davon abhängig, wie gut Ihre DLL-Payloads sind. Aber wir können uns ansehen, was Windows sieht (dieser nächste Abschnitt verwendet die private Version von DropSpawn und startet Beacons).
Was die Ereignisanzeige betrifft, sieht alles normal aus:
In MDE gibt es nur sehr wenig zu sehen.
Ausführen von DropSpawn:
MDE-Protokolle:
Mit PPID-Spoofing:
Ohne PPID-Spoofing:
In beiden Fällen sehen wir unseren ursprünglichen Beacon-Prozess (auch ein WerFault), der dbgcore.dll auf der Festplatte ablegt, einen neuen WerFault.exe-Prozess erstellt, der neu gestartete Prozess dbgcore.dll lädt und diese dann umbenennt (löscht). Entscheidend ist, dass es keine zusätzliche Prüfung von dbgcore.dll gibt, die oft mit DLL-Hijacks einhergeht, da wir sie nicht an einen häufig gehijackten Ort schreiben und WerFault.exe (oder welcher Prozess auch immer gewählt wird) nicht wirklich mit DLL-Hijacks in Verbindung gebracht wird, wie es bei Dingen wie WmiPrvSE.exe der Fall ist.
Interessanterweise ist es fast sichtbarer, dies mit PPID-Spoofing zu tun als ohne. Dies kann jedoch je nach Sicherheitsprodukt variieren.
Wie erwähnt, ist es wichtig, dass Benutzer die echten DLLs von der Zielmaschine herunterladen, auf der sie DropSpawn verwenden möchten. Die Verwendung der falschen Version einer DLL kann dazu führen, dass der gestartete Prozess abstürzt, wenn er versucht, eine Funktion aufzurufen, die nicht existiert.
DropSpawn kann mit Executables außerhalb von System32 verwendet werden; seien Sie jedoch gewarnt, dass Probleme auftreten können, wenn der Prozess versucht, zusätzliche DLLs aus dem tatsächlichen Anwendungsverzeichnis des Prozesses zu laden. Da wir das Anwendungsverzeichnis woandershin gespooft haben, wird der Prozess abstürzen/fehlschlagen, wenn das echte Anwendungsverzeichnis nicht auch anderweitig über die DLL-Suchreihenfolge erreichbar ist, da er essentielle DLLs nicht finden kann. Testen Sie potenzielle Hijacks immer auf Entwicklungsmaschinen, bevor Sie sie in der Produktion verwenden!
Diese Forschung entstand, als ich untersuchte, wie Prozesse ihre endgültige DLL-Suchreihenfolge zusammenstellen (da diese zur Laufzeit bestimmt werden muss, weil Executables in verschiedenen Verzeichnissen liegen, das aktuelle Verzeichnis Teil des Suchpfads ist usw.). Meine Forschung führte mich zu diesem Forenbeitrag, der als Ursprung der beiden kritischen undokumentierten APIs diente, die für diese Technik zentral sind.
Sie wurden bereits früher verlinkt, aber dieser Beitrag zur Vermeidung von Loader-Locks, dieses Skript zur Generierung einer .def-Datei für DLL-Proxying und diese Forschung zur Ermöglichung der Selbstlöschung laufender Executables sind wesentlich für die Erstellung effektiver, waffenisierter DLL-Payloads, die für DropSpawn geeignet sind.
Als ich diese Technik erstmals auf Twitter veröffentlichte, schlossen sich mehrere andere der Konversation an und erstellten POCs. SecurityAndStuff erstellte dieses, während Snovvcrash seines hier hat
