DSCourier BOF

Dies ist eine BOF-Implementierung des Projekts DSCourier von Dylan Davis und Matthew Schramm. Es verwendet die COM-Schnittstelle von WinGet, um beliebigen PowerShell-Code in einem von Microsoft signierten und vertrauenswürdigen Prozess auszuführen. Der vollständige Forschungsblogbeitrag ist hier zu finden.

Im Gegensatz zu den meisten Projekten, die ich veröffentliche, ist dies KEIN einsatzbereites Werkzeug, sondern eher ein Proof of Concept. Ich habe mich entschieden, dies nicht weiterzuverfolgen, nachdem ich eine Reihe von Problemen entdeckt habe, die einer einfachen Bereitstellung als BOF im Wege stehen. Der Code wurde fast vollständig mit Claude erstellt. Mehrere Probleme sind ungelöst und werden unten diskutiert.

Verwendung

Fügen Sie Ihren beliebigen PowerShell-Code in die Datei dist/rev.yml ein. Standardmäßig enthält sie eine einfache PowerShell-Reverse-Shell aus dem ursprünglichen Repository. Wenn Sie diese verwenden möchten, ersetzen Sie die IP im vorhandenen Beispiel durch Ihre gewünschte IP.

Beispiel mit der PowerShell-Reverse-Shell:

Funktionsweise / Einschränkungen

In keiner bestimmten Reihenfolge sind hier einige Probleme/Einschränkungen dieses Tools aufgeführt.

1. Damit die COM-Aufrufe erfolgreich sind, muss die Datei Microsoft.Management.Configuration.winmd im selben Verzeichnis wie die ausführbare Datei vorhanden sein, die die COM-Aufrufe tätigt. Dies stellt ein unmittelbares Problem dar, wenn ein Beacon aus einem ausgehöhlten system32-Prozess ausgeführt wird, in dem normale Benutzer keine Schreibrechte haben. Um dies zu umgehen, wird die Datei stattdessen in %APPDATA%\temp abgelegt und die Funktion WinTypes!RoGetMetaDataFile, die den winmd-Dateipfad abruft, wird mit einem Inline-Hook versehen, damit wir den temporären Pfad angeben können. Dies ermöglicht das Lesen der winmd-Datei / das erfolgreiche Durchführen der COM-Aufrufe, bedeutet aber, dass VirtualProtect-Aufrufe getätigt werden und DLL-Speicher überschrieben wird, was IOCs erzeugt.
2. Nach Punkt 1 wird die winmd-Datei nach dem Ausführen des BOF auf der Festplatte gesperrt, bis der Beacon-Prozess beendet wird. Ich habe ein wenig damit herumprobiert, um dies zu lösen, einschließlich des Hinzufügens der mittlerweile bekannten Selbstlöschfunktion, aber die Datei blieb auf der Festplatte gesperrt. Möglicherweise kann man das umgehen/lösen, aber das überlasse ich jemand anderem.
3. Wie in der ursprünglichen Forschung erwähnt, wird durch die Verwendung der pwsh-Ressource in WinGet ein conhost.exe-Prozess unter ConfigurationRemotingServer.exe gestartet. Claude schlug vor, dass es möglich wäre, anstelle von pwsh ein benutzerdefiniertes Binärmodul als Ressource zu laden, was das conhost-Problem lösen sollte, aber dies erfordert das Ablegen zusätzlicher Dateien auf der Festplatte, und ich konnte es nicht zum Laufen bringen. Es könnte auch nicht möglich sein. Wenn doch, würde dies die Tür öffnen, eine generische .NET-DLL auf die Festplatte zu legen, die von geladen werden und übergebenen Shellcode/Parameter usw. ausführen könnte.

Kompilierung

Dieses Tool wurde ohne die Verwendung normaler BOF-API-Deklarationen (z. B. einer bofdefs.h-Datei) geschrieben. Wie in diesem Blogbeitrag von Matt Ehrnschwender beschrieben, ist es möglich, mit objcopy die richtigen Symbole im Format DLL$API nach der Kompilierung in den BOF zu patchen.

Ich habe ein Tool namens BOFPatcher geschrieben, das diesen Prozess automatisiert. Dies ermöglicht es Benutzern, BOFs als normales C zu schreiben, ohne sich um umständliche API-Deklarationen kümmern zu müssen:

Dieses Tool ist für diejenigen verfügbar, die meinen Kurs BOF Development and Tradecraft erwerben.

Obwohl das BOFPatcher-Tool nicht in diesem Repository enthalten ist, ruft das Makefile dieses Tools objcopy auf und übergibt eine Datei imports_dscourier64.txt, die die richtigen Symbolersetzungen enthält, wodurch der BOF nutzbar wird.

Danksagungen

1. Große Arbeit von Dylan und Matt. Ich hoffe, mehr von ihnen zu sehen!
2. Claude für das Erstellen des größten Teils dieses Codes.