COM-Hijacking

COM-Hijacking ist in der Regel eine Technik, die erst nach einem erfolgreichen Zugriff auf ein System eingesetzt wird. Es handelt sich also um eine Methode, die nach der eigentlichen Kompromittierung verwendet wird (Post-Exploitation). COM-Hijacking eignet sich sehr gut, um einen persistenten Zugang zu einem kompromittierten System einzurichten. Je nach Anwendung kann Schadcode bei jedem Anmeldevorgang zur Ausführung gebracht werden.

In bestimmten Fällen kann COM-Hijacking aber auch für laterale Bewegungen innerhalb eines Netzwerks genutzt werden, zum Beispiel wenn ein Angreifer Zugriff auf die Remote-Registry eines anderen Systems hat. Ein Beispiel dafür ist die erst kürzlich veröffentliche Bitlockmove-Technik, welche ebenfalls auf Techniken basiert, die wir in diesem Artikel vorstellen.

Wir gehen auf verschiedene grundlegende COM-Hijacking Angriffe praktisch ein und stellen abschließend vor, wie diese Techniken erkannt werden können.

Was ist COM?

Die Component Object Model (COM)-Technologie ist ein grundlegender Bestandteil des Windows-Betriebssystems, der bereits in den 1990er Jahren eingeführt wurde. COM ermöglicht es Softwarekomponenten, miteinander zu kommunizieren, unabhängig davon, in welcher Programmiersprache sie geschrieben wurden oder ob sie sich in derselben Anwendung oder in getrennten Prozessen befinden. Dabei greifen Anwendungen über definierte Schnittstellen auf sogenannte COM-Objekte zu, die meist über die Windows-Registry verwaltet und identifiziert werden.

COM wird von unzähligen Windows-Funktionen genutzt, beispielsweise von der Office-Automatisierung über die Shell-Erweiterungen bis hin zur Systemverwaltung via WMI. Auch viele Drittanbieter-Programme bauen auf COM-Komponenten auf, um Funktionalitäten bereitzustellen oder zu erweitern. So verwendet beispielsweise auch 7ZIP COM, um neue Optionen dem Rechtsklickmenü hinzuzufügen.

Gerade weil COM tief im Windows System verankert und weit verbreitet ist, stellt es auch eine attraktive Angriffsfläche dar, insbesondere über Mechanismen wie das sogenannte COM Hijacking, welches Angreifer nutzen, um Schadcode persistent zur Ausführung zu bringen. Doch bevor wir uns dieser Angriffstechnik widmen, lohnt sich ein kurzer Blick auf die Funktionsweise von COM selbst.

Die folgende Grafik zeigt, wie ein COM-Objekt unter Windows mithilfe von CoCreateInstance(CLSID) erstellt und verwendet wird.

Clientprogramm (Bspw. 7z.exe) ruft CoCreateInstance(CLSID) auf. Eine CLSID steht für ClassIdentifier und referenziert eine COM-Klasse. CoCreateInstance erstellt und initialisiert standardmäßig ein einzelnes Objekt der Klasse, die der angegebenen CLSID zugeordnet ist.

1. Windows sucht die CLSID in der Windows-Registry, insbesondere den Pfad:
„HKEY_CLASSES_ROOT\CLSID\{…}“ um die zugehörige DLL oder EXE zu dieser CLSID zu finden. HKEY_CLASSES_ROOT ist kein eigenständiger Registry-Zweig, sondern ein virtueller Schlüssel, der von Windows zur Laufzeit aus „HKCU\Software\Classes“ und „HKLM\Software\Classes“ zusammengesetzt wird. Hierbei hat HKCU immer Vorrang.

• Zuerst wird „HKCU\Software\Classes\“ geprüft (Spezifisch für den aktuellen Benutzer).
• Nachfolgend „HKLM\Software\Classes\“ (systemweit).

2. CLSID wird auf DLL-Pfad aufgelöst:
Aus der Registry liest Windows die Pfadreferenz unter „HKCU\Software\Classes\CLSID\{CLSID}\InprocServer32“ zur COM-Server-DLL-Datei aus, die die gewünschte COM-Klasse implementiert.

• z. B.: InprocServer32 → Pfad zur DLL (für In-Process COM-Server)
• z. B.: LocalServer32 → Pfad zur EXE (für Out-of-Process COM-Server)

Kann dieser Pfad nicht gefunden werden, wird anschließend auf „HKLM\Software\Classes\CLSID\{CLSID}\InprocServer32“ zurückgegriffen. Wenn der Registry-Eintrag unter „HKEY_CLASSES_ROOT\CLSID\{…}\InprocServer32“ auf eine COM-Server DLL verweist, dann lädt Windows diese direkt in den Speicherraum (Address Space) des aufrufenden Prozesses, also des COM-Clientprogramms (hier 7z.exe).

3. DllMain() und DllGetClassObject() werden aufgerufen, um eine Referenz zum implementierten COM-Interface zu erhalten. Hierbei wird bereits aktiv Code in der DLL ausgeführt.

4. Die COM-Server DLL gibt eine Interface-Referenz (Pointer) auf das gewünschte COM-Objekt zurück.

5. Windows gibt Interface- Pointer an den Client zurück, über den er das Objekt verwenden kann.

6. Client führt Funktionsaufrufe über das Interface aus.

7. Rückgabewerte werden an den Client übermittelt.

Warum ist COM interessant für Angreifer?

Angreifer hinterlassen gerne Schadcode auf Systemen um einen dauerhaften Zugriff auf diese zu sicher. Gängige Methoden sind hierfür DLL-Hijacking / DLL-Sideloading-Angriffe bei denen schadhafte Dlls durch legitime Software geladen werden.

Programme werden jedoch meist in Ordnern wie „C:\Program Files“ installiert, in denen nur administrative Benutzer Dateien ablegen können. Für Angriffe wie DLL-Hijacking muss ein verwundbares Programm versuchen eine DLL durch einen LoadLibrary-Aufruf zu laden, welche nicht durch die Windows DLL-Suchreihenfolge gefunden werden kann. Kann in einen der durchsuchten Pfade geschrieben werden, wird eine bösartige DLL in diesem Pfad abgelegt. Die DLL-Suchreihenfolge findet nun die bösartige DLL und lädt diese. Schadcode wird anschließend bei Programmstart der verwundbaren DLL ausgeführt. Jedoch muss zunächst ein schreibbarer Pfad identifiziert werden, von dem versucht wird eine DLL zu laden.

Während bei DLL-Hijacking-Angriffen eine Datei also strategisch in einem Ordner platziert werden muss, welcher durch eine verwundbare Anwendung anschließend durchsucht wird, muss bei COM-Hijacking lediglich der Referenzpfad der DLLs in der Windows Registry geändert werden. Hierfür werden standardmäßig auch keine administrativen Berechtigungen benötigt.

COM-Hijacking nutzt aus, wie Windows COM-Objekte sucht und lädt. Jede COM-Klasse hat eine eindeutige CLSID und einen Registrierungseintrag wie InProcServer32 (für DLLs) oder LocalServer32 (für EXE-Dateien), der Windows den Pfad zu der entsprechenden Datei mitteilt, welche anschließend geladen und ausgeführt wird.

Da Windows bei der Suche zuerst den HKEY_CURRENT_USER (HKCU)-Zweig überprüft, hat ein dort vorhandener Eintrag Vorrang vor dem in HKEY_LOCAL_MACHINE (HKLM). Benutzer dürfen standardmäßig ihren eigenen HKCU-Zweig bearbeiten. Wenn ein Angreifer dort einen gesuchten CLSID-Eintrag erstellen oder überschreiben kann und anschließend ein Programm versucht, denselben CLSID Registrierungseintrag zu verwenden, wird die in der Registry konfigurierte DLL in den Prozess geladen. Dies erfolgt mit den Berechtigungen des aktuellen Benutzers.

Je nachdem, wie ein Angriff durchgeführt wird, werden beim COM-Hijacking verschiedene Registrierungsunterschlüssel verwendet.

Diese sind:

1. InprocServer32
2. LocalServer32
3. TreatAs
4. ProgID
5. ScriptletURL

Die oben genannten Unterschlüssel können unter den folgenden Registrierungsstrukturen verwendet werden:

• HKEY_CURRENT_USER\Software\Classes\CLSID
• HKEY_LOCAL_MACHINE\Software\Classes\CLSID

Wie wird COM von Angreifern missbraucht?

1. Hijack an existing component (by CLSID: InprocServer32/LocalServer32):
   Beim COM-Hijacking werden fehlende oder manipulierte CLSID-Einträge im Benutzer-Registryzweig (HKCU) ausgenutzt, um ohne Adminrechte eine eigene DLL zu laden. Eine Proxy-DLL leitet alle Aufrufe an die Original-DLL weiter, um Abstürze zu verhindern. Im Beispiel wird die XBOX GameBar unter Windows 11 gehijackt, indem ein fehlender CLSID-Eintrag auf eine Proxy-DLL zeigt. So wird beim Start des Zielprogramms die eigene DLL in den Prozessspeicher geladen und ausgeführt.
2. Hijack an existing component (TreatAs):
   Beim TreatAs-Angriff wird eine nicht vorhandene CLSID im Registry-Zweig erstellt, die über den Schlüssel TreatAs auf eine andere CLSID verweist. Diese zweite CLSID enthält den Pfad zu einer bösartigen Proxy-DLL, die wie beim COM-Hijacking in den Zielprozess geladen wird. So lässt sich die Ausführung verschleiern, da der direkte Verweis auf die DLL verborgen bleibt. Das Ergebnis entspricht dem klassischen COM-Hijacking.
3. Hijack an existing component (using ProgID):
   ProgIDs sind lesbare Namen für COM-Komponenten, die im Registry auf die zugehörige CLSID verweisen und so deren Nutzung vereinfachen. Für COM-Hijacking können Angreifer im HKCU-Zweig eigene ProgID-Einträge anlegen, die auf eine bösartige CLSID und damit auf ihre DLL zeigen. Zusätzlich zu InProcServer32 werden ProgID und VersionIndependentProgID gesetzt, um sowohl versionsspezifische als auch allgemeine Aufrufe abzudecken. So kann z. B. über PowerShell die manipulierte ProgID instanziiert und Schadcode ausgeführt werden.
4. Hijack an orphaned COM reference:
   Unvollständige Software-Deinstallationen können COM-Objekte in der Registry zurücklassen, deren Dateireferenzen fehlen. Erstellt ein Angreifer die fehlende Datei (z. B. eine DLL) am referenzierten Pfad, lässt sich dies für COM-Hijacking ausnutzen.
5. Exzessive Berechtigungen:
   Wenn Angreifer COM-Objekte außerhalb ihres eigenen HKCU-Zweigs manipulieren können, etwa in HKLM, kann dies zu lokalen Berechtigungserweiterungen führen. Ein bekanntes Beispiel ist CVE-2023-51715 bei SONIX-Webcams, bei der Benutzer mit geringen Rechten die DLL-Pfade in der Registry überschreiben und somit SYSTEM-Rechten bösartigen Code ausführen konnten. Zur Absicherung sollten Berechtigungen auf HKLM-COM-Schlüssel und deren referenzierte Dateien geprüft werden.
6. Registrierung einer neuen bösartigen COM-Komponente:
   Angreifer können ohne Adminrechte eigene COM-Shell Extensions im Benutzerprofil anlegen, die zum Beispiel das Rechtsklickmenü um bösartige Funktionen erweitern. Wird eine solche Shell Extension installiert, kann Schadcode bei verschiedenen Rechtsklick automatisch ausgeführt werden. Die Möglichkeiten sind dabei nahezu unbegrenzt und nur durch die Kreativität des Angreifers begrenzt.
7. ScriptletURL – „Fileless“ COM Execution:
   Mit der Windows Script Components-Technologie können COM-Komponenten über Skriptsprachen wie VBScript oder JScript erstellt werden, ohne eine DLL-Datei zu speichern. Durch die Verwendung des „ScriptletURL“-Schlüssels lässt sich eine .sct-Datei von einem Remote-Webserver herunterladen und ausführen, um Code auszuführen, z. B. das Starten des Taschenrechners. Diese Technik nutzt die Skriptkomponenten-Laufzeitumgebung (scrobj.dll), um die Datei zu laden und die Skript-Engine zu starten. Moderne Sicherheitslösungen erkennen solche Angriffe jedoch häufig als bösartig.

Gehen wir nun etwas tiefer ins Detail. Nachfolgend werden die gängigsten COM-Angriffe einmal dargestellt:

1. Hijack an existing component (by CLSID: InprocServer32/LocalServer32):
Dieser Angriff zählt zu der am häufigsten verwendeten Techniken. Hierfür analysieren Angreifer zunächst ob Programme während der Ausführung auf nicht vorhandene CLSID Registrierungseinträge zugreifen, um weitere Funktionalität nachzuladen. Ein fehlender HKCU CLSID-Eintrag auf welchen jedoch versucht wird zuzugreifen, kann von einem Angreifer selbst mit einer Pfadreferenz zu einer bösartigen DLL erstellt werden. Da CLSID Registryeinträge in HKCU Vorrang zu HKLM haben, werden auch hier keine Administrationsberechtigungen benötigt. Startet ein Nutzer nun ein Programm, das auf den neuen CLSID-Eintrag zugreift, wird die DLL des angegebenen Pfades geladen und Schadcode kommt zur Ausführung. Alternativ können auch vorhandene Einträge in HKCU manipuliert werden, welche von Programmen aktiv verwendet werden.

Für diesen Angriff müssen die Aufrufe der bösartigen DLL an die original DLL weitergeleitet werden, um die Funktionalität der Anwendung weiterhin zu gewährleisten. Ansonsten stürzt das Programm bei Ausführung in der Regel ab. Hierfür können Projekte wie SharpDllProxy, oder COMProxy verwendet werden.

Beispiel:
Um den Angriff einmal zu demonstrieren, muss zunächst ein verwundbarer Prozess gefunden werden. Wir fokussieren uns hier auf COM-Hijacking Angriffe in Standard Windows Programmen unter Windows 11. Die XBOX GameBar ist häufig installiert und lässt sich durch die Tastenkombination „STRG+G“ starten..

Mittels des Tools ProcMon lässt sich einsehen, dass während des Startens auf viele nicht vorhandene COM-Referenzen zugegriffen wird.

In diesem Beispiel arbeiten wir mit dem folgenden willkürlichen Eintrag: „HKCU\Software\Classes\CLSID\{2155fee3-2419-4373-b102-6843707eb41f}\InprocServer32“. Im vorherigen Screenshot kann eingesehen werden, dass unsere CLSID nicht gefunden werden kann. Da auf diese im HKCU-Zweig zugegriffen wird, können wir den Eintrag selbst anlegen.

Es ist anzumerken, dass nicht nur der Prozess „GameBarFTServer.exe“ (XBOX GameBar) auf die angegebene CLSID zugreift, sondern auch der native Windows Explorer (explorer.exe), welcher auf die CLSID bei jeder Anmeldung und unregelmäßig bei der gewöhnlichen Verwendung zugreift.

Um die Verfügbarkeit des Systems nicht zu gefährden, muss eine DLL für den Angriff verwendet werden, welche den Prozess nicht stoppt. Ansonsten wird der Prozess stets abbrechen und neustarten, was die Verfügbarkeit des Systems erheblich einschränkt. Payloads die beispielsweise eine Messagebox erzeugen, können zum Abstürzen des Explorer Prozesses führen, welcher anschließend neustartet und erneut crashed. Änderungen an der Registry können im abgesicherten Modus rückgängig gemacht werden.

Um die Prozesse durch unseren Angriff nicht zu gefährden, werden sämtliche Aufrufe, die an unsere DLL gestellt werden, an die original DLL weitergeleitet. Hierfür können wir nachsehen, ob unsere Beispiel-CLSID im HKLM-Zweig verwendet wird. Die Referenz löst auf die Datei thumbcache.dll im System32 Ordner auf. Diese DLL muss zum Erstellen einer Proxy-DLL verwendet werden.

Der Prozess zum Erstellen einer ProxyDLL wird in diesem Blog nicht weiter erläutert, kann jedoch beispielsweise in diesem Blog näher eingesehen werden.

Zusätzlich zu diesem Blog veröffentlichen wir ein Github Repository mit Code zum Erstellen einer Proxy-Dll, welche lediglich eine Log-Datei unter „C:\Windows\Tasks\com-hijack.log“ erstellt. Die Proxy-Dll verweist auf die genannte thumbcache.dll.

Um den DLL-Sideload durchzuführen, muss nun lediglich der gesuchte CLSID-Eintrag samt dem Unterschlüssel „InprocServer32“ im HKCU-Zweig erstellt werden. „InprocServer32“ wird anschließend mit dem Pfad zu unserer Proxy-DLL konfiguriert.

Wird nun die Tastenkombination STRG+G gedrückt, wird unsere DLL in den Speicher des Prozesses GameBarFTServer.exe geladen und kommt dort zur Ausführung.

Entsprechend wird die Datei „C:\Windows\Tasks\com-hijack.log“ erstellt.

Ähnliche Angriffe können ebenfalls mit .exe Dateien unter dem Schlüssel „LocalServer32“ statt „InprocServer32“ durchgeführt werden.

2. Hijack an existing component (TreatAs):
Der TreatAs-Schlüssel gibt die CLSID einer Klasse an, die die aktuelle Klasse emulieren kann. Kurzgesagt kann über einen TreatAs-Schlüssel eine andere CLSID referenziert werden. Dies kann von Angreifern genutzt werden, um die Ausführung etwas zu verschleiern.

Greift unser Programm nun auf eine nicht vorhandene CLSID zu, können Angreifer diese erstellen. Statt des Schlüssels „InprocServer32“ wird ein TreatAs-Schlüssel gesetzt, welcher auf eine weitere CLSID verweist. In diesem Fall wurde die CLSID „{DEADBEEF-DEAD-BEEF-DEAD-DEADBEAFDEAD}“ neu angelegt.

Wird „{2155fee3-2419-4373-b102-6843707eb41f}“ aufgerufen, verweist diese auf „{DEADBEEF-DEAD-BEEF-DEAD-DEADBEAFDEAD}“ welche wiederum die Konfiguration zu unserer Proxy-Dll beinhaltet.

Das Ergebnis gleicht dem vorherigen Beispiel.

3. Hijack an existing component (using ProgID):
COM ProgIDs (Programmatic Identifiers) sind lesbare Bezeichner, die auf COM-Komponenten verweisen und eine Alternative zu schwer lesbaren CLSIDs (GUIDs) bieten. ProgIDs sind im Windows-Registry unter dem Pfad HKEY_CLASSES_ROOT gespeichert und verknüpfen sich dort mit der entsprechenden CLSID. Anwendungen können über den ProgID die zugehörige COM-Komponente instanziieren, ohne die CLSID direkt kennen zu müssen. Damit erleichtern ProgIDs die Nutzung und Wartung von COM-Komponenten erheblich, vor allem bei Automatisierungsszenarien. Auch ProgIDs können für COM-Hijacking Angriffe verwendet werden indem unter HKCU eigene ProgID-Einträge hinzugefügt werden, welche anschließend auf eine bösartige CLSID auflösen.
Die folgenden Registrierungsschlüssel lösen ProgIDs zu CLSIDs auf.

• HKCU\Software\Classes
• HKLM\Software\Classes

Das bedeutet, dass das Betriebssystem, die zugehörige „ProgID“ auflöst, wenn eine Anwendung (Client) ein COM-Objekt (Klasse) aktiviert, indem es zunächst den folgenden Registrierungspfad ausliest:

• HKCU\Software\Classes\ProgID

Beispiel:
Zunächst legt ein Angreifer unter „HKCU\Software\Classes\“ einen neuen Eintrag an. Hierfür wird in der Regel eine vorhandene ProgID aus „HKLM\Software\Classes\“ übernommen. In diesem Beispiel verwenden wir die ProgID „Microsoft.DirectMusicScript“ welche in der letzten Abbildung dargestellt wurde. Anschließend wird der Unterschlüssel „CLSID“ erstellt, welcher auf unsere bereits verwendete CLSID verweist.

Für einen erfolgreichen Angriff müssen neben „InProcServer32“ zwei zusätzliche Unterschlüssel erstellt werden, welche beide die Ziel-ProgID beinhalten: Hier „Microsoft.DirectMusicScript“

• ProgID
• VersionIndependentProgID

Der Schlüssel „VersionIndependentProgID“ stellt einen unabhängigen Namen für die ProgID bereit, sodass Programme diese unter ihrem „allgemeinen“ Namen („Microsoft.DirectMusicScript“) nutzen können und nicht unter einem versionsspezifischen Namen (bspw. „Microsoft.DirectMusicScript.1.00“) aufrufen müssen.

Übersicht aller konfigurierten Unterschlüssel:

Anschließend kann die COM-Instanz über die ProgID innerhalb der Powershell erstellt werden. Die COM-DLL wird anschließend in die Powershell geladen und kommt dort zur Ausführung.

4. Hijack an orphaned COM reference:
COM-Referenzen können manchmal unrechtmäßig in der Registry verbleiben. Ein Beispiel ist hierbei eine unzureichende Deinstallation von Software, bei welcher COM-Objekte verbleiben, die Dateireferenz jedoch entfernt wurde. Ist ein Angreifer in der Lage die im COM-Objekt referenzierte Datei zu erstellen, so kann dies ebenfalls für COM-Hijacking missbraucht werden. Um fehlende DLL-Referenzen zu entdecken, kann die Funktion „Find-MissingLibraries“ des COMHijackToolkit verwendet werden.

5. Exzessive Berechtigungen:
Systeme mit einer SONIX Technology-Webcam, die die Treiber-DLL „SonixDeviceMFT.dll“ in der Standardkonfiguration verwendeten, waren anfällig für COM-Hijacking-Angriffe. Der Registrierungsschlüssel „HKLM\SOFTWARE\Classes\CLSID\{5A50829A-86DD-4D18-8685-891EEE643C24}\InprocServer32“ enthält einen Pfad zu der genannten .DLL-Datei und konnte von Benutzern mit geringen Berechtigungen überschrieben werden. Dies ermöglicht es Angreifern potenziell, eine bösartige DLL zu laden und damit ihre Berechtigungen zu erweitern. Die vom Registrierungsschlüssel referenzierte DLL wurde mit NT-AUTHORITY\SYSTEM-Rechten geladen, wenn die Webcam des Geräts aktiviert wurde.

Um solche Schwachstellen zu identifizieren, müssen zwei Berechtigungen überprüft werden:

• Die Berechtigung konfigurierte COM-Objekte unter HKLM zu manipulieren
• Die Berechtigung die im COM-Objekt referenzierte Datei zu manipulieren

Um diese zu identifizieren haben wir ein simples PowerShell-Script erstellt, welches sowohl die Berechtigungen der HKLM-CLSID Schlüssel sowie deren referenzierten Dateien analysiert:

Zusätzlich kann dies mittels des Tools PrivescCheck geprüft werden. Dieses Tool wird jedoch von Antivirenlösungen selbst als bösartig erkannt.

6. Registrierung einer neuen bösartigen COM-Komponente:
Hier erstellt ein Angreifer eine eigene neue COM-Shell Extension, die beispielsweise das Rechtsklickmenü um bösartige Funktionalität erweitert (Alternativen sind fast nur durch die Fantasie des Malwareautors begrenzt). Da diese auch nur für den eigenen Nutzer registriert werden kann, werden hierfür keine Administrationsberechtigungen benötigt. Wird ein Nutzer einmalig dazu gebracht Schadcode auszuführen, welcher die Shell Extension installiert, kann bösartiger Code beispielsweise bei jedem Rechtsklick zur Ausführung gebracht werden.

7. ScriptletURL – „Fileless“ COM Execution:
Anstatt ein benutzerdefiniertes COM-Objekt (DLL) auf die Festplatte zu schreiben, kann die Ausführung über Windows Scripting Components (Scriptlets) erfolgen. Durch den Schlüssel „ScriptletURL-Konfiguration“ wird die Registrierung eines Remote-Speicherorts ermöglicht, an dem sich eine .sct-Datei befindet, die anschließend heruntergeladen und ausgeführt wird.

Windows Script Components werden als einfache Möglichkeit bereitgestellt, Component Object Model (COM)-Komponenten mithilfe von Skriptsprachen wie VBScript, JScript und JavaScript zu erstellen. Die Skriptkomponenten-Technologie besteht ausfolgenden Teilen:

• der Skriptkomponenten-Laufzeitumgebung (Scrobj.dll)
  scrobj.dll (Script Component Runtime) ist ein Microsoft COM-Objekt, das anhand von Registry-Informationen erkennt, welche Skript-Engine (VBScript, JScript usw.) und welche Initialisierungsparameter für eine Scriptausführung verwendet werden sollen.
• den Schnittstellen-Handlern
• sowie der Skriptkomponenten-Datei (einer .sct-Datei), in der der zu verwendende Schnittstellen-Handler angegeben wird.

Für diesen Abschnitt verwenden wir das öffentliche Beispiel unter https://github.com/api0cradle/LOLBAS/tree/master/OSScripts/Payload.
In diesem wird das bereits beschriebene ProgID-Hijacking angewendet um eine Skriptkomponenten-Datei (.sct-Datei) oder auch „Scriptlet“ von einem Webserver herunterzuladen um den darin enthaltenen Code (VBScript, JScript usw.) auszuführen. Dieser startet anschließend den Taschenrechner. Es ist anzumerken, dass moderne AV/EDR-Systeme dies als bösartig erkennen.

Drei Hauptanforderungen müssen zur Nutzung der ScriptletURL-Konfiguration erfüllt werden:

1. Die Skriptkomponenten-Laufzeitumgebung (Scrobj.dll) muss als COM-Server (InProcServer32) verwendet werden.

2. Eine entsprechend aufgebaute Skriptkomponenten-Datei wird erstellt.
„<registration>“ definiert hierbei die COM-Registrierungsdetails für das Objekt. Innerhalb des Script-Abschnittes wird Code definiert, welcher mittels JScript zur Ausführung gebracht werden soll. Innerhalb des Script-Abschnittes wird Code definiert, welcher mittels JScript zur Ausführung gebracht werden soll.

3. Parallel zu InProcServer32, wird unter dem Schlüssel „ScriptletURL“ anschließend die Webserver-URL der erstellten Skriptkomponenten-Datei aus Schritt zwei konfiguriert, von der die Datei heruntergeladen werden soll.

Das Ergebnis ist ein registriertes COM-Objekt, bei dem die Windows Script Component-Laufzeitumgebung (scrobj.dll) als Server (InprocServer32) eingetragen ist und ein URL-Pfad im ScriptletURL-Schlüssel hinterlegt wurde, über den das Scriptlet von einem externen Webserver abgerufen wird. Wenn ein Programm oder Skript diese CLSID lädt, sucht Windows zuerst in HKCU\Software\Classes. Dort findet es den manipulierten Eintrag und lädt scrobj.dll als In-Process COM Server. Scrobj.dll erkennt anhand des Eintrags ScriptletURL, dass es ein Scriptlet von einer bestimmten URL laden soll. Anschließend erfolgt das Abrufen der Scriplet -Datei von der angegebenen URL.

Scrobj.dll ruft anschließend die zuständige Skript-Engine (VBScript / JScript) auf. Diese führt daraufhin den angegebenen Code aus, welcher den Taschenrechner startet.

Wie können COM-Hijacking erkannt werden?

COM-Hijacking-Angriffe zählen zu den eher schwer erkennbaren Techniken. Das liegt vor allem daran, dass dabei legitime Funktionen des Betriebssystems genutzt werden. Bereits erfolgte COM-Hijacking Angriffe können meist nur mittels manueller Analyse der Registry aufgedeckt werden. Anpassungen an COM-Hijacking relevanten Pfaden können jedoch bereits im Vorhinein, leicht überwacht werden. Bei der Verwendung von COM-Objekten prüft Windows standardmäßig zuerst benutzerspezifische Pfade in der Registry. Dadurch können Angreifer eigene Einträge unter HKCU platzieren. Solche Änderungen wirken auf den ersten Blick unauffällig, da sie keine direkten Exploits oder verdächtigen Prozesse auslösen.

Registry-Einträge für COM-Einträge ändern sich jedoch sehr selten. Ebenfalls werden nur selten neue Einträge hinzugefügt beispielsweise bei der Installation von Software oder deren Updates. Genau deshalb erfordert die Erkennung von COM-Hijacking ein gezieltes Monitoring auf Registry-Ebene sowie eine gute Korrelation mit weiteren Ereignissen im System.

Hierfür kann Sysmon verwendet werden:

Sysmon (System Monitor) ist ein Windows-Systemdienst der Microsoft Sysinternals Suite. Es erfasst detaillierte Informationen über sicherheitsrelevante Ereignisse im System und geht damit deutlich über die Standardfunktionen von Windows-Eventlogs hinaus.

Folgende Events können interessant sein, um COM-Hijacking Angriffe zu identifizieren:

• Event ID 12 – Neuer Registry-Schlüssel wurde erstellt
• Event ID 13 – Ein Registry-Wert wurde geändert
• Event ID 14 – Ein Registry-Schlüssel wurde umbenannt
• Event ID 15 – Ein Registry-Schlüssel wurde gelöscht

Das ist besonders relevant für COM-Hijacking, da Angreifer üblicherweise Werte unter folgenden Pfaden ändern oder erstellen:

• HKCU\Software\Classes\CLSID\{…}\InprocServer32
• HKCU\Software\Classes\CLSID\{…}\LocalServer32

Hierfür kann Sysmon verwendet werden:

Sysmon (System Monitor) ist ein Windows-Systemdienst der Microsoft Sysinternals Suite. Es erfasst detaillierte Informationen über sicherheitsrelevante Ereignisse im System und geht damit deutlich über die Standardfunktionen von Windows-Eventlogs hinaus.

Folgende Events können interessant sein, um COM-Hijacking Angriffe zu identifizieren:

• Event ID 12 – Neuer Registry-Schlüssel wurde erstellt
• Event ID 13 – Ein Registry-Wert wurde geändert
• Event ID 14 – Ein Registry-Schlüssel wurde umbenannt
• Event ID 15 – Ein Registry-Schlüssel wurde gelöscht

Das ist besonders relevant für COM-Hijacking, da Angreifer üblicherweise Werte unter folgenden Pfaden ändern oder erstellen:

• HKCU\Software\Classes\CLSID\{…}\InprocServer32
• HKCU\Software\Classes\CLSID\{…}\LocalServer32

Beispiel:

Für diesen Artikel erstellen wir eine einfache Sysmonregel. In den Referenzen ist ebenfalls eine komplexere Sysmonkonfiguration angegeben.
Zunächst muss Sysmon heruntergeladen werden.

Nun wird eine neue Sysmonregel erstellt, welche Änderungen am Pfad „HKCU\Software\Classes\CLSID\“ mittels entsprechender Events meldet. Anhand der folgenden Konfiguration werden Events für sämtliche Änderungen an COM-Objekten für sämtliche Benutzer in der Windows-Ereignisanzeige aufgelistet.

Anschließend wird Sysmon mittels des folgenden Befehls installiert und die Konfiguration geladen:

“Sysmon64.exe -accepteula -i sysmon-config.xml”

• -accepteula: Akzeptiert die Lizenzbedingungen
• -i: Installiert den Sysmon-Treiber und lädt die Konfiguration

Wird nun eine Änderung an einem der konfigurierten Pfade durchgeführt, wird dies in der Windows-Ereignisanzeige (eventvwr.msc) sichtbar.
Um dies zu demonstrieren, kann mittels des folgenden Scripts ein neuer COM-Eintrag angelegt werden:

$clsid = ‚{DEADBEEF-DEAD-BEEF-DEAD-DEADBEAFDEAD‘

$key = „HKCU:\Software\Classes\CLSID\$clsid\InprocServer32“

New-Item -Path $key -Force | Out-Null

Set-ItemProperty -Path $key -Name „(Default)“ -Value „C:\Windows\Tasks\thumbcache.dll“

Folgende Events wurden durch die Konfiguration eines neuen COM-Eintrags erstellt.

• Event ID 12 – Neuer Registry-Schlüssel wurde erstellt
• Event ID 13 – Ein Registry-Wert wurde geändert

Weiterhin kann die SIGMA Regel in den Referenzen verwendet werden, um Manipulationen an vorhandenen Registryeinträgen zu identifizieren. Hierfür müssen jedoch sämtliche in der Umgebung eingesetzten CLSIDs analysiert und in die Regel aufgenommen werden, was auf lange Sicht eher unpraktisch ist.

Eine weitere Möglichkeit ist ebenfalls zu überprüfen, ob DLL oder EXE Dateien von untypischen Dateipfaden wie „C:\Windows\Temp“ oder „C:\Users\Public\“ geladen oder ausgeführt werden. Auch dies ist für jede Umgebung individuell zu erfassen.

Weiterhin kann die SIGMA Regel in den Referenzen verwendet werden, um Manipulationen an vorhandenen Registryeinträgen zu identifizieren. Hierfür müssen jedoch sämtliche in der Umgebung eingesetzten CLSIDs analysiert und in die Regel aufgenommen werden, was auf lange Sicht eher unpraktisch ist.

Fazit

Um mögliche COM-Hijacking Angriffsflächen zu reduzieren, sollte man zuerst nach verwundbaren COM-Objekten und Pfaden suchen. Dabei geht es vor allem darum, die Berechtigungen in der Registry sowie deren referenzierte Dateien zu überprüfen und gegebenenfalls anzupassen. Viele COM-Objekte sind durch falsche oder zu weit gefasste Berechtigungen angreifbar. Besonders im Pfad „HKCU\Software\Classes\CLSID“ sollte man sicherstellen, dass nur vertrauenswürdige Nutzer Zugang haben.

Ein wirksamer Schutz kann darin bestehen, nur administrativen Nutzern das Erstellen oder Verändern von Schlüsseln in diesen Registry-Bereichen zu erlauben. Je restriktiver die Rechte hier gesetzt sind, desto besser lässt sich ein möglicher Missbrauch verhindern. Hierfür sollte jedoch zunächst geprüft werden, ob dies die aktuelle Umgebung negativ beeinflusst.

Zusätzlich hilft es, verdächtige Änderungen in der Registry durch Logging zu überwachen. Moderne EDR-Lösungen können dabei unterstützen, Manipulationen frühzeitig zu erkennen. Auch Maßnahmen wie Application Whitelisting können helfen, dass keine unerwünschten oder manipulierten Komponenten ausgeführt werden können.

Referenzen:

• https://github.com/Flangvik/SharpDllProxy
• https://github.com/leoloobeek/COMProxy/
• https://github.com/SigmaHQ/sigma/blob/master/rules/windows/registry/registry_set/registry_set_persistence_com_hijacking_builtin.yml
• https://attack.mitre.org/techniques/T1546/015/
• https://github.com/SwiftOnSecurity/sysmon-config/tree/master
• https://github.com/nccgroup/acCOMplice/tree/master
• https://github.com/itm4n/PrivescCheck/tree/master
• https://github.com/ptf-maximilianbarz/COM-Hijacking-Blog