optiv/dentEin Framework zur Erstellung COM-basierter Umgehungen unter Ausnutzung von Schwachstellen in den WDAPT-Sensoren von Microsoft.
Um die neueste Version von Dent anzusehen oder ein Problem zu melden, siehe https://github.com/Tylous/Dent.
Dent
Wenn Sie mehr über die in diesem Framework verwendeten Techniken erfahren möchten, werfen Sie einen Blick auf diesen Artikel.
Dieses Framework generiert Code, um Schwachstellen in den Attack Surface Reduction (ASR)-Regeln von Microsoft Defender Advanced Threat Protection auszunutzen, um Shellcode auszuführen, ohne erkannt oder verhindert zu werden. ASR wurde als erste Verteidigungslinie entwickelt, die Ereignisse auf der Grundlage von Aktionen erkennt, die gegen eine Reihe von Regeln verstoßen. Diese Regeln konzentrieren sich auf spezifische Verhaltensindikatoren auf dem Endpunkt, die oft mit den Taktiken, Techniken oder Verfahren (TTPs) eines Angreifers verbunden sind. Ein Schwerpunkt liegt auf der Microsoft Office-Suite, da dies ein häufiger Angriffsvektor für die Etablierung eines entfernten Fußes auf einem Endpunkt ist. Viele der regelbasierten Kontrollen konzentrieren sich auf netzwerk- oder prozessbasierte Verhaltensindikatoren, die sich vom normalen Geschäftsbetrieb abheben. Diese Regeln zielen entweder auf die erste Kompromittierung eines Systems oder auf eine Technik ab, die eine Organisation schwerwiegend beeinträchtigen kann (z. B. Preisgabe von Anmeldedaten oder Ransomware). Sie decken einen großen Teil der gemeinsamen Angriffsfläche ab und konzentrieren sich darauf, bekannte Techniken zur Kompromittierung von Vermögenswerten zu behindern.
Dent nutzt mehrere Schwachstellen aus, um diese restriktiven Kontrollen zu umgehen und Payloads auf einem Endpunkt auszuführen, ohne von den Sensoren von Microsoft Defender Advanced Threat Protection blockiert oder wirksam erkannt zu werden. Der obige Artikel beschreibt diese Schwachstellen, die auch nach der Offenlegung noch in Microsoft Defender Advanced Threat Protection vorhanden sind.
Der erste Schritt ist wie immer das Klonen des Repositoriums, dann das Erstellen.
go build Dent.go
./Dent -h
________ __
\______ \ ____ _____/ |_
| | \_/ __ \ / \ __\
| | \ ___/| | \ |
/_______ /\___ >___| /__|
\/ \/ \/
(@Tyl0us)
"Call someone a hero long enough, and they'll believe it. They'll become it.
They have no choice. Let them call you a monster, and you become a monster."
Usage of ./Dent:
-C string
Name of the COM object.
-N string
Name of the XLL playload when it's writen to disk.
-O string
Name of the output file. (default "output.txt")
-P string
Path of the DLL for your COM object. (Either use \\ or '' around the path)
-U string
URL where the base64 encoded XLL payload is hosted.
-show
Display the script in the terminal.
Dieses Framework ist dazu gedacht, Schwachstellen und Defizite in Microsoft Defender Advanced Threat Protection auszunutzen, daher generiert es keine Payloads/Implantate. Um diese zu generieren, kann man eine Vielzahl öffentlich verfügbarer Tools verwenden, jedoch wurden alle Forschung, Entwicklung und Tests mit ScareCrow durchgeführt. Microsoft Defender Advanced Threat Protection verlässt sich für die Telemetrie nicht auf Userland-Hooking, sondern nutzt verschiedene andere Mechanismen wie Kernel-Callbacks. Tests zufolge funktioniert dieses Framework hervorragend, um Microsoft Defender Advanced Threat Protection zu umgehen und Shellcode auszuführen.
Zum Zeitpunkt der Veröffentlichung gibt es derzeit zwei Techniken. Ich werde regelmäßig verschiedene hinzufügen, die diese Schwachstellen auf unterschiedliche Weise ausnutzen. Bleiben Sie also gespannt auf weitere.
COM-Objekte werden oft erstellt, wenn eine Anwendung auf einem System installiert wird. Einmal erstellt, kann jede Anwendung oder jedes Skript sie aufrufen, aber das ist nicht der einzige Weg, sie zu erstellen. Durch Ändern/Erstellen von Registrierungsschlüsseln im Abschnitt HKEY_CLASSES_ROOT der Windows-Registrierung können wir ein COM-Objekt erstellen, das auf unseren Shellcode auf dem System verweist. Das bedeutet, dass jede Anwendung oder jedes Skript, das COM nutzen kann, es aufrufen und den Shellcode ausführen kann.
Dies funktioniert aufgrund der Funktionsweise der CoCreateInstance-API. CoCreateInstance wird verwendet, um COM-Objekte basierend auf der CLSID (einer global eindeutigen Kennung zur Identifizierung einer bestimmten COM-Klasse) zu erstellen und zu initialisieren. Diese Funktion ruft die Informationen zum Ausführen des Aufrufs aus den in Registrierungsschlüsseln gespeicherten Werten ab. Diese CLSID-Werte finden sich im Pfad HKEY_CLASSES_ROOT\CLSID\ der Registrierung. Bevor ein Prozess jedoch die CLSID aufrufen kann, muss er deren Wert kennen. Dazu wird zunächst eine Registrierungsabfrage durchgeführt, um das COM-Objekt in HKEY_CLASSES_ROOT\<COM-Objektname> zu suchen. Wenn es existiert, wird eine zweite Registrierungsabfrage durchgeführt, um den im Unterordner gespeicherten CLSID-Wert zu erhalten.
Eine weitere Untersuchung der Unterordner der Registrierung zeigt, dass die Berechtigungen für die CLSID-Werte nicht konsistent sind. Eine große Mehrheit der hier gespeicherten COM-Objekte gewährt nur dem Trusted Installer die Berechtigung „Vollzugriff“. Der Trusted Installer ist ein Dienstkonto, das Ressourcen besitzt, um sie zu schützen, sogar vor Administratoren. Dies soll sicherstellen, dass selbst wenn ein Angreifer administrative Privilegien erlangt, die Ressourcen nicht böswillig manipuliert werden können. Leider erlauben viele COM-Objekte jedem in der Gruppe „Administratoren“ die Berechtigung „Vollzugriff“. Darüber hinaus gewährt der Stammschlüssel CLSID der Gruppe „Administratoren“ die Berechtigung „Vollzugriff“ anstelle von NT-AUTORITÄT\System oder Trusted Installer. Aus diesem Grund können wir in einem erhöhten Kontext bestimmte COM-Objektwerte erstellen oder sogar ändern.
Wichtig Das Erstellen dieser Registrierungsschlüssel funktioniert nur, wenn Sie es in einem erhöhten Kontext ausführen. Ein Doppelklick darauf über eine GUI führt die .VBS-Datei nicht in einem erhöhten Kontext aus, selbst wenn Sie Administrator sind. Es wird empfohlen, sie von einer administrativen Shell oder Eingabeaufforderung aus auszuführen. Sobald die Schlüssel jedoch erstellt sind, kann jede Anwendung dieses COM-Objekt in jedem Kontext aufrufen.
Um einen ScareCrow-Payload mit dieser Art von Umgehung zu nutzen, können Sie den folgenden Befehl ausführen:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader dll
Sobald Sie Ihren Payload haben, verwenden Sie das Flag -N für den Namen des Payloads, wenn er auf die Festplatte geschrieben wird, das Flag -C für den Namen des COM-Objekts, das Flag -I für den Speicherort, an den er geschrieben werden soll, und schließlich das Flag -O für die Ausgabedatei, um den Inhalt zu speichern.
Diese Option generiert einen Codeblock, um mehrere ASR-Regeln zu umgehen, um Shellcode herunterzuladen, auf die Festplatte zu schreiben, zu laden und auszuführen, wobei die vorbeugenden ASR-Kontrollen umgangen werden. Dies geschieht mithilfe des COM-Objekts Excel.Application, das die gesamte Excel-Anwendung darstellt, jedoch in automatisierter Form, und die programmatische Interaktion damit ermöglicht. Da es sich immer noch um Excel handelt, wird die ASR-Regel nicht ausgelöst. Das liegt daran, dass beim Aufruf von Excel.Application zu sehen ist, dass es unter einem Service Host-Prozess (Svchost.exe) und nicht unter dem WinWord.exe-Prozess erzeugt wird. Während Svchost.exe ein systemnaher Prozess ist, der mehrere Windows-basierte Dienste hostet, erhielt der erzeugte untergeordnete Prozess (Excel.exe) keine systemweiten Privilegien.
Da wir ein COM-Objekt erstellt haben, das eine gesamte Anwendung war, wurde der Excel-Prozess unter Svchost.exe erstellt, damit er ordnungsgemäß behandelt werden kann, um Instabilitäten im WinWord.exe-Prozess zu vermeiden. Obwohl dieser Prozess unter Svchost.exe läuft, gibt es eine weitere Herausforderung: die Ausführung von Shellcode. Da die binäre Ausführung oder die Verwendung von WinAPI innerhalb eines Makros andere ASR-Regeln auslösen würde, schränkt dies ein, was wir tun können, ohne eine ASR-Regel auszulösen oder von der EDR-Komponente von WDAPT erwischt zu werden. Hier kommen DLLs ins Spiel. Wenn ein DLL-basierter Payload mit den richtigen Exportfunktionen kompiliert wird, kann er als Office-Plugin verwendet werden, das beim Laden automatisch Shellcode ausführt. Dazu können wir die RegisterXLL-Funktion von Excel nutzen. Die RegisterXLL-Funktion lädt ein XLL-Plugin in den Speicher, registriert und führt es automatisch aus. XLL-Dateien sind im Wesentlichen Excel-basierte DLLs.
Um den Inhalt auf das System zu bringen, können wir ein weiteres COM-Objekt (Microsoft.XMLHTTP) verwenden, das die Fähigkeit erhält, eine HTTP-Anfrage auszuführen, in diesem Fall eine HTTP-GET-Anfrage an eine URL. Das zweite COM-Objekt (ADODB.stream) bietet die Möglichkeit, Bytes eines Datenstroms zu lesen/schreiben. Durch die Kombination der beiden COM-Objekte kann ein Angreifer eine entfernte Ressource über eine HTTP-GET-Anfrage anfordern und die Antwort (in diesem Fall die Datei selbst) auf die Festplatte schreiben. Dies geschieht erneut mit dem COM-Objekt (ADODB.stream) zur Handhabung von Lese-/Schreibbytes des Datenstroms. Das zweite COM-Objekt (Microsoft.XMLDOM) ermöglicht das Lesen von in einer Datei gespeicherten Daten. Das XMLDOM-Objekt erlaubt es, den Datentyp festzulegen (in diesem Fall base64). Sobald es geöffnet und mit dem richtigen Datentyp in einem String gespeichert wurde, kann das ADODB.stream-Objekt den Code-String mit einem anderen Datentyp (in diesem Fall BinaryStreamType) auf die Festplatte schreiben, wobei der base64-String wieder in eine binäre Form umgewandelt wird.
Um einen ScareCrow-Payload mit dieser Art von Umgehung zu nutzen, können Sie den folgenden Befehl ausführen:
./ScareCrow -I <path to your raw stageless shellcode> -domain <domain name> -Loader excel -O <Output filename>
Sobald generiert, kopieren Sie Zeile 13 und 14 aus der ausgegebenen Datei und führen Sie sie zusammen, wobei Sie sicherstellen, dass Sie Folgendes entfernen:
var <variable name>; am Ende jeder Zeile
Sobald Sie Ihren codierten Payload haben, verwenden Sie das Flag -N für den Namen des Payloads, wenn er auf die Festplatte geschrieben wird, das Flag -U für die URL, auf der der codierte Payload gehostet wird (z. B. https:///), und das Flag -F für den Namen der Datei, die von der Site gehostet wird. Der ausgegebene Code ist für die Verwendung in einem Makrodokument ausgelegt.
Durch weitere Untersuchungen wurde festgestellt, dass es sich nicht um eine Lücke in den WDATP-Sensoren handelt, sondern dass WDATP zwar Sicht auf diese Aktivität hat, diese aber ignoriert wird. Durch die WDATP-Endpunkt-Ereigniszeitlinie, die nach Verweisen auf Appwiz.xll suchte, wurde beobachtet, dass WDATP ein „Datei erstellt“-Ereignis aufzeichnete, als Word die Datei AppWiz.xll erstellte. Es ist wichtig zu beachten, dass .XLL-Dateien ausführbar sind.
20.11.2020 - Forschung, Entwicklung und Artikel geschrieben.
14.03.2021 - Microsoft ein vorläufiges Offenlegungsdokument mit den identifizierten Problemen vorgelegt.
31.03.2021 - Microsoft erkannte und bestätigte, dass die Schwachstellen im Zusammenhang mit dem Erzeugen eines Office-Unterprozesses und dem Schreiben von Dateien auf die Festplatte echte Schwachstellen waren, und begann mit der Behebung. Die Inkonsistenzen der Berechtigungen in der Registrierung wurden jedoch nicht als Schwachstelle angesehen, da erhöhte Privilegien erforderlich sind.
21.04.2021 - Microsoft informierte den Autor, dass Signaturbuild 1.333.1055.0, veröffentlicht am 22.03.2021, und 1.335.1321.0, veröffentlicht am 21.04.2021, die Erkennung für die Office-Anwendungsschwachstellen enthielten und schloss den Fall.
22.04.2021 - Der Autor testete dieselben Techniken erneut und stellte fest, dass die Schwachstellen immer noch vorhanden waren.