TrollDump
- Injiziert eine verwaltete x64-DLL in einen verwalteten/nicht verwalteten x64-Prozess (der Prozess muss über eine GUI verfügen, da wir dessen Fensterhandle erhalten) mittels setwindowshook
- Hier als TROLL injizieren wir in das versteckte Fenster von taskmgr, um einen lsass-Dump unerkannt durchzuführen (siehe Abschnitt Testfall unten)
- Die injizierende DLL und die injizierte DLL sind dieselbe DLL, daher ist keine zusätzliche DLL erforderlich
- Die Integritätsstufe des Zielprozesses muss gleich oder niedriger sein als die des injizierenden Prozesses
Credits (Upgrade/Neuschreibung des Projekts)
Originalprojekt: https://github.com/enkomio/ManagedInjector
- Code portiert, um in 64-Bit-Binaries zu injizieren ---> das ursprüngliche Projekt erlaubt nur DLL-Injection in 32-Bit-Binaries
- IPC-Logik entfernt, da sie überladen war
- Boilerplate-Code erstellt, um deinen Payload direkt in der Funktion RunOnRemoteProcess() auszuführen, anstatt auf dem vorherigen verworrenen Weg
- Das Projekt verwendet weiterhin DLLExport, um eine .NET-DLL dazu zu bringen, Funktionen zu exportieren
- Beachte: Dies ist keine Abhängigkeit des Projekts, sondern eher eine Nachbearbeitung. DLLExport modifiziert deine finale .NET-DLL, um eine Funktion zu exportieren.
- Die Funktionsexportierung kann bei Bedarf auch manuell durchgeführt werden https://blog.xpnsec.com/rundll32-your-dotnet/
Kompilieren
- Projekt herunterladen & Projektmappe als X64, Release kompilieren
- Keine externen Abhängigkeiten erforderlich
Verwendung
> Requires High Integrity depending on use case
> [System.Reflection.Assembly]::LoadFrom("C:\Users\public\TrollDump.dll")
> [TrollDump.ForFun]::Main("C:\windows\system32\taskmgr.exe")
- In diesem POC führen wir einen lsass-Dump durch; du kannst jede beliebige "Logik der exportierten DLL-Funktion" ausführen, indem du die Funktion RunOnRemoteProcess() modifizierst und neu kompilierst.
- Wie bereits erwähnt, dient der Code als Boilerplate für die DLL-Injection; was du danach tun möchtest, lässt sich bequem in verwaltetem C#-Code schreiben.
Testfall
- Win 2019 Build 17763.737 mit den neuesten windefender-Patches
- sowohl DLL-Injection als auch lsass-Dump
- Andere AVs (ungenannt)
- DLL-Injection funktioniert einwandfrei
- ob der lsass-Dump funktioniert oder nicht, hängt offensichtlich davon ab, ob die AV taskmgr erlaubt, lsass zu dumpen
- Nicht auf EDRs getestet -> ich vermute, dass die DLL-Injection auf bestimmten EDRs weiterhin funktionieren sollte
OPSEC
- Die DLL muss auf der Festplatte liegen und sollte daher obfuskiert werden
- Die DLL sollte nur für die Injection verwendet werden; der eigentliche Payload sollte niemals in die DLL eingebettet werden und sollte reflektiv geladen werden
- Natürlich ist das Injizieren von CLR in einen nicht verwalteten Prozess verdächtig, aber hey!
- setwindowshook ist zwar eine klassische Technik, wird aber meist mit Keylogging in Verbindung gebracht, nicht mit unserem Anwendungsfall
- Man kann sehr kreativ sein, in welchen GUI-Prozess man injizieren möchte (wenn man als System läuft, kann man auch in dwm.exe injizieren)
Wunschliste - Das Projekt wurde über das Wochenende erstellt und ich habe weder Zeit noch Absicht, Folgendes weiterzuverfolgen:
- In Prozesse ohne GUI injizieren
- Derzeit verwendet es für setwindowshook WH_CALLWNDPROC; du kannst es so ändern, dass WH_GETMESSAGE verwendet wird, aber der Zielprozess muss eine Nachrichtenschleife (GetMessage()) ausführen
- Wenn du eine Binärdatei ohne GUI findest, die eine Nachrichtenschleife implementiert (was ich für unwahrscheinlich halte), kannst du auch in Binaries ohne GUI injizieren
- Es ist üblich, dass GUI-Prozesse GetMessage() ausführen
- Vollständig reflektiv und kein Ablegen auf der Festplatte erforderlich
- Basierend auf setwindowshook scheint es, als müsste die DLL auf der Festplatte liegen?
- Ich habe versucht, C#-Delegaten zu verwenden, um einen Funktionszeiger zur Ausführung zu übergeben, anstatt der exportierten DLL-Funktion, und das funktionierte nicht (das ist die klassische C#-Keylogger-Technik für lokale Prozesse, aber wir arbeiten mit einem entfernten Prozess)
- Du kannst das versuchen, indem du andere Techniken einbeziehst; ich denke, es ist machbar
- Taskmgr wird automatisch mit hoher Integrität (High Integrity) gestartet, selbst wenn unser aktueller Prozess Medium ist (technisch gesehen ist es also ein UAC-Bypass, wenn wir eine DLL hinein injizieren)
- Die Injection scheint laut den Rückgabewerten der Win-API einwandfrei zu funktionieren
- Allerdings schafft es taskmgr nicht, die exportierte Funktion aufzurufen
Haftungsausschluss
- Sollte nur für Bildungszwecke verwendet werden!