COM-Hijacking erkennen: Code über gekaperte COM-Objekte

Nach dem Erstzugang sucht der Angreifer einen Weg zu mehr Rechten und zu dauerhaftem Zugriff. Während der UAC-Bypass die Benutzerkontensteuerung aushebelt und die Token-Manipulation eine fremde Identität borgt, nutzt das COM-Hijacking eine Konfigurationsschwäche: COM-Objekte werden über die Registry aufgelöst, und wer dort einen Eintrag umbiegt, kann seinen Code unterschieben. Das Tückische ist die Selbstverständlichkeit - COM wird ständig aufgerufen, und ein manipuliertes Objekt läuft im Kontext des aufrufenden Prozesses an, oft mit mehr Rechten als der Angreifer selbst hatte. Dieser Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Das Kapern eines COM-Objekts läuft - auf der Ebene des Prinzips, nicht als Anleitung - in wenigen Mustern ab:

• Ein passendes Objekt finden. Gesucht wird ein COM-Objekt, das von einem interessanten Prozess regelmäßig aufgerufen wird.
• Den Server umbiegen. Der InprocServer32- oder LocalServer32-Eintrag des CLSID wird in der Registry auf eine eigene DLL gesetzt, meist im Benutzerkontext (HKCU), der ohne Administratorrechte beschreibbar ist.
• Oder umleiten. Alternativ wird per TreatAs-Eintrag ein vertrauenswürdiges Objekt auf ein eigenes umgeleitet.
• Auf den Aufruf warten. Beim nächsten Aufruf des Objekts lädt der Prozess die untergeschobene DLL - der Code läuft im Kontext und mit den Rechten dieses Prozesses.

Für die Erkennung ist entscheidend: Der Eingriff findet in der Registry statt und läuft über wenige benannte Schlüssel. Genau daran setzen die Regeln an.

Welche Logquellen die Technik zeigt

• Registry-Telemetrie zuerst. Sysmon Event 13 zeigt die Änderung eines InprocServer32-, LocalServer32- oder TreatAs-Eintrags unter einem CLSID - besonders, wenn der Wert in einen Benutzerpfad zeigt. Die wichtigste Quelle.
• Prozess-Telemetrie. Event 4688 zeigt ein reg.exe, das einen solchen Schlüssel setzt, samt vollständiger Befehlszeile.
• DLL-Ladevorgänge. Sysmon Event 7 (ImageLoad) zeigt, wenn ein Prozess später eine DLL aus einem Benutzerpfad lädt - der eigentliche Treffer nach dem Kapern.
• Kontext. Ein COM-Eintrag im Benutzerkontext (HKCU), der einen systemweiten überlagert, ist besonders aussagekräftig, weil er ohne Administratorrechte gesetzt werden kann.

Das Muster im Log

Drei Signale tragen. Das erste ist ein COM-Server-Eintrag, der auf eine DLL in einem Benutzer- oder Temp-Pfad zeigt - ein legitimer COM-Server liegt dort selten. Das zweite ist eine neu gesetzte TreatAs-Umleitung unter einem CLSID, die einen Aufruf auf ein anderes Objekt umbiegt. Das dritte ist ein reg-Aufruf, der direkt einen InprocServer32-, LocalServer32- oder TreatAs-Schlüssel schreibt. Legitime Treffer stammen aus Software-Installationen, die COM-Server registrieren. Auffällig wird es, wenn der Eintrag im Benutzerkontext liegt, auf einen Benutzerpfad zeigt oder einen vorhandenen systemweiten Eintrag überlagert. Der Blick auf Schlüssel, Zielpfad und Hive trennt den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: den COM-Server im Benutzerpfad, die TreatAs-Umleitung und den reg-Aufruf auf einen CLSID. Die ersten beiden werten die Registry-Telemetrie aus, die dritte die Prozess-Telemetrie.

1. COM-Server-DLL auf Benutzerpfad umgebogen (T1546.015). Ein InprocServer32- oder LocalServer32-Eintrag unter einem CLSID, der auf einen Benutzer- oder Temp-Pfad zeigt. Die Regel steht auf level: high.

title: COM-Server-DLL auf Benutzerpfad umgebogen
id: 3b7d1c25-6a84-4e93-9f02-2c6d5b8e7a41
status: experimental
description: |
  Erkennt, dass der Pfad eines COM-Servers in der Registry auf ein benutzerschreibbares Verzeichnis
  zeigt - Users, AppData, Temp oder ProgramData. Beim COM-Hijacking biegt der Angreifer den
  InprocServer32- oder LocalServer32-Eintrag eines CLSID auf seine eigene DLL um; beim naechsten Aufruf
  des COM-Objekts laeuft sein Code, oft mit den Rechten des aufrufenden Prozesses. Ein COM-Server im
  Benutzerpfad ist ein starkes Signal.
references:
  - https://attack.mitre.org/techniques/T1546/015/
author: blue-team.net
tags:
  - attack.privilege-escalation
  - attack.t1546.015
logsource:
  product: windows
  category: registry_set
detection:
  sel_clsid:
    TargetObject|contains: '\CLSID\'
  sel_server:
    TargetObject|contains:
      - 'InprocServer32'
      - 'LocalServer32'
  sel_userpath:
    Details|contains:
      - '\Users\'
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
  condition: sel_clsid and sel_server and sel_userpath
falsepositives:
  - Einzelne Software registriert COM-Server in einem Datenpfad - bekannte CLSID und Herausgeber als Baseline ausnehmen
level: high

2. COM-TreatAs-Umleitung in der Registry gesetzt (T1546.015). Ein neu gesetzter TreatAs-Eintrag unter einem CLSID. Die Regel steht auf level: medium, weil auch Software TreatAs setzt.

title: COM-TreatAs-Umleitung in der Registry gesetzt
id: 6c2e9a14-8d47-4b63-a0f5-3d7c2b9e6a15
status: experimental
description: |
  Erkennt das Setzen eines TreatAs-Eintrags unter einem CLSID. Mit TreatAs wird ein COM-Objekt auf ein
  anderes umgeleitet; Angreifer nutzen das, um Aufrufe eines vertrauenswuerdigen COM-Objekts auf ihr
  eigenes umzubiegen (COM-Hijacking). Ein neu gesetzter TreatAs-Eintrag ist im Normalbetrieb selten.
references:
  - https://attack.mitre.org/techniques/T1546/015/
author: blue-team.net
tags:
  - attack.privilege-escalation
  - attack.t1546.015
logsource:
  product: windows
  category: registry_set
detection:
  sel_clsid:
    TargetObject|contains: '\CLSID\'
  sel_treatas:
    TargetObject|contains: '\TreatAs'
  condition: sel_clsid and sel_treatas
falsepositives:
  - Einzelne Software setzt TreatAs bei Updates - bekannte CLSID und Herausgeber als Baseline ausnehmen
level: medium

3. COM-CLSID-Schlüssel per reg.exe gesetzt (T1546.015). reg.exe mit add auf einen CLSID und InprocServer32, LocalServer32 oder TreatAs. Ebenfalls level: high.

title: COM-CLSID-Schluessel per reg.exe gesetzt
id: 8d1f3c26-5b79-4a84-9e03-6d4c7b2e8a19
status: experimental
description: |
  Erkennt, dass per reg.exe ein COM-Server- oder TreatAs-Eintrag unter einem CLSID geschrieben wird -
  InprocServer32, LocalServer32 oder TreatAs. Angreifer legen damit ihr COM-Hijacking auf der
  Kommandozeile an. Das direkte Setzen eines solchen Schluessels per reg add ist ein auffaelliges
  Muster.
references:
  - https://attack.mitre.org/techniques/T1546/015/
author: blue-team.net
tags:
  - attack.privilege-escalation
  - attack.t1546.015
logsource:
  product: windows
  category: process_creation
detection:
  sel_reg:
    Image|endswith: '\reg.exe'
  sel_add:
    CommandLine|contains: 'add'
  sel_clsid:
    CommandLine|contains: '\CLSID\'
  sel_key:
    CommandLine|contains:
      - 'InprocServer32'
      - 'LocalServer32'
      - 'TreatAs'
  condition: sel_reg and sel_add and sel_clsid and sel_key
falsepositives:
  - Installationsroutinen registrieren COM-Server per reg - bekannte Installer und CLSID als Baseline ausnehmen
level: high

Härtung: der Angriff, der ins Leere läuft

• Registry-Schlüssel überwachen. Änderungen an CLSID-Einträgen, vor allem im Benutzerkontext (HKCU\Software\Classes\CLSID), gezielt protokollieren und als Erkennung führen. Die wirksamste Maßnahme gegen diesen Weg.
• Anwendungssteuerung. Mit AppLocker oder WDAC verhindern, dass eine DLL aus einem Benutzerpfad geladen und ausgeführt wird - damit läuft eine umgebogene DLL ins Leere.
• Rechte begrenzen. Nutzer ohne Administratorrechte führen, sodass systemweite COM-Einträge (HKLM) nicht verändert werden können.
• Gezielt überwachen. COM-Server im Benutzerpfad, TreatAs-Umleitungen und reg-Aufrufe auf CLSID-Schlüssel als feste Erkennungen führen.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten System mit aktivem Sysmon - mit einem Test-CLSID und einer harmlosen DLL, danach wieder aufräumen:

• Für Regel 1 unter einem Test-CLSID einen InprocServer32-Eintrag auf eine harmlose DLL in einem Benutzerpfad setzen und prüfen, dass Sysmon Event 13 die Änderung meldet.
• Für Regel 2 unter einem Test-CLSID einen TreatAs-Eintrag setzen und den Treffer kontrollieren.
• Für Regel 3 denselben Schlüssel per reg add schreiben und prüfen, dass Event 4688 den reg-Aufruf samt Befehlszeile zeigt.
• Breiter wird der Test mit den Fällen zu T1546.015 aus Atomic Red Team.

Fehlalarme und Tuning

• Software-Installationen. Installer registrieren COM-Server regulär. Bekannte Installationsprozesse, CLSID und Herausgeber als Baseline ausnehmen, bevor die Regeln scharf geschaltet werden.
• Entwicklungswerkzeuge. Auf Entwicklerrechnern werden COM-Objekte häufig registriert und wieder entfernt. Diese Hosts gezielt behandeln.
• Hive und Pfad sind entscheidend. Ein COM-Eintrag im Benutzerkontext, der auf einen Benutzerpfad zeigt, wiegt weit schwerer als eine systemweite Registrierung durch einen Installer - danach priorisieren.
• Kette schlägt Einzelzeile. Der umgebogene COM-Eintrag zusammen mit einem späteren DLL-Ladevorgang aus dem Benutzerpfad ist weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.

Fazit

Das COM-Hijacking nutzt keine Schwachstelle im Code, sondern die Art, wie Windows COM-Objekte über die Registry auflöst. Wer dort einen Eintrag auf seine eigene DLL umbiegt, lässt seinen Code beim nächsten Aufruf im Kontext eines anderen, oft höher berechtigten Prozesses laufen. Die verlässlichen Signale sind ein COM-Server im Benutzerpfad, eine TreatAs-Umleitung und ein reg-Aufruf auf einen CLSID. Die wirksamste Härtung ist, CLSID-Änderungen im Benutzerkontext zu überwachen und DLLs aus Benutzerpfaden per Anwendungssteuerung zu blockieren. Die lautere Variante über einen echten Exploit zeigt die Ausnutzung einer Schwachstelle; das Aushebeln der Benutzerkontensteuerung der UAC-Bypass. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Privilege Escalation.