DCOM-Fernausführung erkennen: seitliche Bewegung über COM-Objekte

Nach RDP, SMB und WinRM folgt der unauffälligste der Remote Services: DCOM, das Distributed Component Object Model. Windows erlaubt es, COM-Objekte nicht nur lokal, sondern über das Netz auf einem anderen Host zu instanziieren. Einige dieser Objekte bieten Methoden, die letztlich einen Prozess starten - und genau das nutzen Angreifer, um aus der Ferne Code auszuführen, ohne einen Dienst anzulegen oder ein eigenes Programm auf dem Ziel zu hinterlassen. Der Beitrag bleibt auf der Verteidigerseite und bleibt konzeptionell.

Was der Angreifer tut

Seitliche Bewegung über DCOM läuft auf der Ebene des Prinzips, nicht als Anleitung, in wenigen Schritten ab:

• Ein COM-Objekt aus der Ferne instanziieren. Mit gültigen Zugangsdaten erzeugt der Angreifer auf dem Ziel ein DCOM-Objekt, etwa MMC20.Application oder eine Office-Anwendung.
• Eine ausführende Methode aufrufen. Das Objekt bietet eine Methode, die im Ergebnis einen Prozess startet - die Management-Konsole oder die Office-Anwendung wird so zum Starter des eigentlichen Befehls.
• Als Kind des COM-Wirts laufen. Der gestartete Befehl erscheint als Kindprozess von mmc.exe, excel.exe oder dllhost.exe - nicht als frischer Dienst.
• Unauffällig bleiben. Weil kein neuer Dienst und oft keine neue Datei entsteht, ist DCOM leiser als die anderen Remote Services.

Für die Erkennung ist das entscheidend: So leise die Aktivierung ist, die Eltern-Kind-Beziehung auf dem Ziel bleibt sichtbar - ein COM-Wirt, der eine Shell öffnet, ist das zuverlässige Signal.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie. Event 4688 und Sysmon Event 1 zeigen die verräterische Eltern-Kind-Beziehung: mmc.exe, eine Office-Anwendung oder dllhost.exe als Elternteil einer cmd.exe oder PowerShell.
• Der Aktivierungs-Hinweis. Dieselben Quellen zeigen den COM-Wirt oft mit dem Schalter -Embedding gestartet, ein Zeichen für die Aktivierung über COM statt durch einen Nutzer.
• LOLBins als Kind. Startet der COM-Wirt mshta oder rundll32, lohnt der Blick auf die LOLBins-Erkennung, weil diese Bordmittel den eigentlichen Code nachladen.
• Netzwerk-Telemetrie. Die DCOM-Aktivierung läuft über RPC; ungewöhnliche Host-zu-Host-Verbindungen auf dem RPC-Endpunkt ergänzen das Bild - siehe auch Sysmon einrichten für die Endpunkt-Seite.

Das Muster im Log

Der verlässlichste Befund ist die abnorme Elternschaft. Die Management-Konsole mmc.exe, die eine cmd.exe öffnet, hat im Alltag praktisch keinen Grund und ist das klarste Signal. Eine Office-Anwendung, die eine Shell startet, ist ebenso verdächtig - dasselbe Muster entsteht bei Makro-Missbrauch, was den Befund nicht schwächt, sondern in beiden Fällen eine Prüfung wert macht. dllhost.exe als Starter einer Shell ist seltener, aber aussagekräftig, weil der COM-Surrogatprozess normalerweise keine Kommandozeilen öffnet. Der Schalter -Embedding am COM-Wirt verdichtet den Verdacht, weil er die Aktivierung über COM verrät.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und über alle Backends sauber übersetzbar. Jede zielt auf einen der gängigen COM-Wirte als Elternprozess einer Shell. Die erste ist die spezifischste, weil mmc.exe fast nie eine Kommandozeile öffnet.

1. MMC20.Application startet eine Shell (T1021.003). mmc.exe als Elternteil einer Kommandozeile. Die Regel steht auf level: high.

title: MMC20.Application startet eine Shell (DCOM)
id: 5b1e7c84-3a26-4d9f-b0c7-2e8a4d1b63f5
status: experimental
description: |
  Erkennt mmc.exe als Elternprozess einer Kommandozeile oder eines Skript-Hosts. Ueber
  das DCOM-Objekt MMC20.Application laesst sich aus der Ferne Code ausfuehren, der dann
  als Kind von mmc.exe startet. Dass die Management-Konsole eine Shell oeffnet, hat im
  Normalbetrieb praktisch keinen Grund.
references:
  - https://attack.mitre.org/techniques/T1021/003/
author: blue-team.net
tags:
  - attack.lateral-movement
  - attack.t1021.003
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith: '\mmc.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: selection
falsepositives:
  - Sehr selten; einzelne Verwaltungs-Snapins, die Skripte starten; bekannte Faelle ausnehmen
level: high

2. Office-COM-Server startet eine Shell (T1021.003). Eine Office-Anwendung als Elternteil einer Shell, eines Skript-Hosts oder von mshta/rundll32. Ebenfalls level: high.

title: Office-COM-Server startet eine Shell (DCOM)
id: 8d4a2f16-6c73-4e50-9b21-7a3e1c9d54b8
status: experimental
description: |
  Erkennt eine Office-Anwendung als Elternprozess einer Kommandozeile, eines Skript-Hosts
  oder von mshta/rundll32. Ueber DCOM-Objekte wie Excel.Application oder Outlook laesst
  sich aus der Ferne Code ausfuehren, der als Kind der Office-Anwendung startet. Dasselbe
  Muster entsteht bei Makro-Missbrauch - in beiden Faellen ist es verdaechtig.
references:
  - https://attack.mitre.org/techniques/T1021/003/
author: blue-team.net
tags:
  - attack.lateral-movement
  - attack.t1021.003
logsource:
  product: windows
  category: process_creation
detection:
  selection_parent:
    ParentImage|endswith:
      - '\excel.exe'
      - '\winword.exe'
      - '\outlook.exe'
      - '\powerpnt.exe'
      - '\mspub.exe'
      - '\visio.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitime Office-Add-ins oder Automatisierung; bekannte Faelle nach Host und Konto ausnehmen
level: high

3. COM-Surrogat dllhost.exe startet eine Shell (T1021.003). dllhost.exe als Elternteil einer Shell. level: medium, weil einzelne COM-Komponenten legitim Hilfsprozesse starten.

title: COM-Surrogat dllhost.exe startet eine Shell
id: 2c9e6b40-7f18-4a35-8d02-6b1a4c7e93d5
status: experimental
description: |
  Erkennt dllhost.exe als Elternprozess einer Kommandozeile oder eines Skript-Hosts.
  dllhost.exe ist der COM-Surrogatprozess, in dem out-of-process aktivierte COM-Objekte
  laufen - auch solche, die per DCOM aus der Ferne instanziiert werden. Startet daraus
  eine Shell, deutet das auf Fernausfuehrung ueber ein COM-Objekt hin.
references:
  - https://attack.mitre.org/techniques/T1021/003/
author: blue-team.net
tags:
  - attack.lateral-movement
  - attack.t1021.003
logsource:
  product: windows
  category: process_creation
detection:
  selection:
    ParentImage|endswith: '\dllhost.exe'
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
  condition: selection
falsepositives:
  - Einzelne legitime COM-Komponenten, die Hilfsprozesse starten; bekannte CLSIDs und Hosts ausnehmen
level: medium

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

• DCOM-Rechte einschränken. Die Launch- und Aktivierungsrechte für COM-Objekte auf das Nötige begrenzen, damit nicht jedes Konto aus der Ferne Objekte instanziieren kann.
• RPC zwischen Arbeitsplätzen sperren. Per Firewall verhindern, dass Arbeitsplätze sich gegenseitig über die RPC-Endpunkte erreichen - das nimmt der DCOM-Aktivierung die Fläche.
• Office-Kindprozesse unterbinden. Mit Angriffsflächenreduzierung verhindern, dass Office-Anwendungen Kindprozesse starten - das deckt DCOM wie Makro-Missbrauch ab.
• Verhaltensregeln scharf schalten. Die Eltern-Kind-Regeln aktiv überwachen, damit ein COM-Wirt, der eine Shell öffnet, sofort auffällt.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf isolierten Systemen mit aktivem Sysmon:

• Für Regel 1 im Lab über das MMC20.Application-Objekt einen harmlosen Befehl auf einem anderen Host starten. Die Eltern-Kind-Beziehung mmc.exe zu cmd.exe muss erscheinen.
• Für Regel 2 über ein Office-COM-Objekt einen Testbefehl ausführen lassen. Die Office-Anwendung muss als Elternteil der Shell auftauchen.
• Für Regel 3 ein out-of-process aktiviertes COM-Objekt einen Hilfsprozess starten lassen. dllhost.exe muss als Elternteil erscheinen. Breiter wird der Test mit den DCOM-Fällen aus Atomic Red Team.

Fehlalarme und Tuning

• Office-Automatisierung. Add-ins und legitime Automatisierung lassen Office gelegentlich Hilfsprozesse starten. Für Regel 2 die bekannten Fälle nach Host und Konto ausnehmen.
• Verwaltungs-Snapins. Sehr selten startet ein MMC-Snapin ein Skript. Prüfe solche Treffer einmalig und nimm bekannte Fälle auf.
• COM-Komponenten. Einzelne Anwendungen nutzen dllhost.exe legitim. Für Regel 3 die bekannten CLSIDs und Hosts als Baseline ausnehmen.
• -Embedding als Verstärker. Wer den Schalter -Embedding am Elternprozess zusätzlich prüft, trennt COM-Aktivierung von normaler Nutzung und senkt die Fehlalarme deutlich.

Fazit

DCOM ist seitliche Bewegung ohne neuen Dienst und ohne eigenes Werkzeug auf dem Ziel - und deshalb besonders leise. Der verlässliche Anker ist die abnorme Elternschaft: mmc.exe, eine Office-Anwendung oder dllhost.exe, die eine Shell öffnen. Die wirksamste Härtung schränkt die DCOM-Aktivierungsrechte ein, sperrt RPC zwischen Arbeitsplätzen und unterbindet Office-Kindprozesse. Als Nächstes folgt eine andere Spielart der seitlichen Bewegung: das Übernehmen einer bestehenden Sitzung. Verwandt sind WinRM, die Admin-Shares und die Impacket-Werkzeuge, deren dcomexec genau diesen Weg nutzt. Weitere Techniken dieser Taktik sammelt das Lexikon nach Taktik unter Lateral Movement.