DDE-Angriff erkennen: Ausführung im Office-Dokument ohne Makro

Office-Dokumente sind ein beliebter Träger für Code, und das Makro ist nur einer von mehreren Wegen. Die schädliche Datei mit Office-Makro nutzt VBA, der Windows Script Host führt VBScript und JScript aus - Dynamic Data Exchange geht einen dritten Weg: Es missbraucht eine alte Office-Funktion, mit der ein Dokument Daten aus einer anderen Anwendung nachlädt. Statt Daten lädt der Angreifer einen Befehl, und beim Öffnen fragt Office nur noch, ob es ihn ausführen darf. Das Tückische: Dafür muss kein Makro aktiv sein. Für die Erkennung ist das zweitrangig, weil der Weg dieselbe Spur hinterlässt wie ein Makro. Dieser Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Die Ausführung über DDE läuft - auf der Ebene des Prinzips, nicht als Anleitung - in wenigen Mustern ab:

• Ein Feld präparieren. In ein Dokument wird ein DDE-Feld eingebettet, das statt einer Datenquelle einen Befehl an eine Anwendung wie cmd oder PowerShell enthält.
• Die Bestätigung erschleichen. Beim Öffnen fragt Office, ob verknüpfte Inhalte aktualisiert werden dürfen; eine glaubwürdige Mail soll das Opfer zum Zustimmen bewegen.
• Den Befehl ausführen. Nach der Bestätigung startet das Office-Programm den hinterlegten Prozess - ganz ohne Makro.
• Weiterarbeiten. Der gestartete Prozess lädt nach, verankert sich oder beginnt mit der Erkundung - die Ausführung ist geschafft.

Für die Erkennung ist entscheidend: Egal ob Makro, Skript oder DDE - am Ende startet ein Office-Programm einen fremden Prozess. Genau diese Eltern-Kind-Beziehung ist der Punkt, an dem die Regeln ansetzen.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie zuerst. Event 4688 und Sysmon Event 1 zeigen die Eltern-Kind-Beziehung: Word oder Excel als Elternprozess eines Interpreters oder LOLBins. Die wichtigste Quelle.
• Office-Telemetrie. Moderne Office-Versionen protokollieren das Aktualisieren verknüpfter Felder; in gehärteten Umgebungen ist DDE per Richtlinie ganz abgeschaltet.
• Kommandozeile. Die Befehlszeile des Kindprozesses zeigt oft den nachgeladenen Befehl im Klartext und macht so den Zweck sichtbar.
• Werkzeug-Kontext. Die missbrauchten Helfer wie rundll32 und certutil sind mitgelieferte Windows-Programme; Grundlagen dazu unter Living off the Land.

Das Muster im Log

Drei Signale tragen. Das erste ist ein Office-Programm, das einen Skript- oder Shell-Interpreter startet - Word als Elternprozess von PowerShell oder cmd gibt es im Alltag praktisch nicht. Das zweite ist ein Office-Programm, das einen signierten Helfer wie rundll32 oder certutil aufruft, um Code zu laden oder auszuführen. Das dritte ist ein Office-Programm, das einen Prozess aus einem Benutzer- oder Temp-Pfad startet. Legitime Treffer sind selten, kommen aber vor - etwa durch einzelne Add-ins. Auffällig wird es, wenn der gestartete Prozess ein Interpreter ist, der Zielpfad im Benutzerbereich liegt oder die Kommandozeile einen nachgeladenen Befehl zeigt. Der Blick auf Eltern, Kind und Zielpfad trennt den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: das Office-Programm, das einen Interpreter startet, das einen signierten LOLBin aufruft und das einen Prozess aus einem Benutzerpfad startet. Alle drei werten die Prozess-Telemetrie aus und setzen am Office-Programm als Elternprozess an.

1. Office-Programm startet Skript- oder Shell-Interpreter (T1559.002). Word, Excel oder ein anderes Office-Programm als Elternprozess von cmd, PowerShell, wscript oder mshta. Die Regel steht auf level: high.

title: Office-Programm startet Skript- oder Shell-Interpreter
id: 3d7b2f14-6a85-4c93-9e21-4f8a1c6d3b02
status: experimental
description: |
  Erkennt, dass ein Office-Programm einen Skript- oder Shell-Interpreter startet - cmd.exe,
  powershell.exe, wscript.exe, cscript.exe oder mshta.exe. Beim Dynamic Data Exchange fuehrt ein
  praepariertes Dokument Code ueber ein Feld aus, ganz ohne Makro, und startet dabei einen solchen
  Kindprozess. Ein Office-Programm als Elternprozess eines Interpreters ist sehr ungewoehnlich.
references:
  - https://attack.mitre.org/techniques/T1559/002/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1559.002
logsource:
  product: windows
  category: process_creation
detection:
  sel_office:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\mspub.exe'
      - '\visio.exe'
  sel_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
  condition: sel_office and sel_child
falsepositives:
  - Einzelne Office-Add-ins starten Hilfsprozesse - bekannte Faelle nach Kommandozeile als Baseline ausnehmen
level: high

2. Office-Programm startet signierten LOLBin (T1559.002). Ein Office-Programm als Elternprozess von rundll32, regsvr32, certutil oder bitsadmin. Ebenfalls level: high.

title: Office-Programm startet signierten LOLBin
id: 6f1c9a23-8d47-4e62-b0a5-3c7d2b9e5f41
status: experimental
description: |
  Erkennt, dass ein Office-Programm einen signierten, oft missbrauchten Windows-Helfer startet -
  rundll32.exe, regsvr32.exe, certutil.exe oder bitsadmin.exe. Beim Dynamic Data Exchange laedt oder
  startet das Dokument darueber seine Nutzlast, um vertrauenswuerdig zu erscheinen. Ein solcher LOLBin
  mit einem Office-Programm als Elternprozess ist ein starkes Signal.
references:
  - https://attack.mitre.org/techniques/T1559/002/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1559.002
logsource:
  product: windows
  category: process_creation
detection:
  sel_office:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\mspub.exe'
      - '\visio.exe'
  sel_lolbin:
    Image|endswith:
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
  condition: sel_office and sel_lolbin
falsepositives:
  - Einzelne Office-Integrationen rufen rundll32 auf - bekannte Faelle nach Kommandozeile als Baseline ausnehmen
level: high

3. Office-Programm startet Prozess aus Benutzer- oder Temp-Pfad (T1559.002). Ein Office-Programm startet einen Prozess aus Users, AppData, Temp oder ProgramData. Die Regel steht auf level: medium, weil einzelne Add-ins dort liegen können.

title: Office-Programm startet Prozess aus Benutzer- oder Temp-Pfad
id: 9a2d5c38-1e76-4b84-8f03-6d4c7b2e8a15
status: experimental
description: |
  Erkennt, dass ein Office-Programm einen Prozess aus einem benutzerschreibbaren Verzeichnis startet -
  Users, AppData, Temp oder ProgramData. Beim Dynamic Data Exchange legt das Dokument eine Nutzlast in
  einem solchen Pfad ab und fuehrt sie aus. Ein von einem Office-Programm gestarteter Prozess aus einem
  Benutzerpfad ist auffaellig, weil regulaere Programme aus geschuetzten Systempfaden laufen.
references:
  - https://attack.mitre.org/techniques/T1559/002/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1559.002
logsource:
  product: windows
  category: process_creation
detection:
  sel_office:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\mspub.exe'
      - '\visio.exe'
  sel_path:
    Image|contains:
      - '\Users\'
      - '\AppData\'
      - '\Temp\'
      - '\ProgramData\'
  condition: sel_office and sel_path
falsepositives:
  - Einzelne Office-Erweiterungen starten Hilfsprogramme aus einem Benutzerpfad - bekannte Pfade und Herausgeber als Baseline ausnehmen
level: medium

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

• DDE per Richtlinie abschalten. Das automatische Aktualisieren verknüpfter Felder in Office zentral deaktivieren; dann läuft ein DDE-Dokument gar nicht erst an. Die wirksamste Maßnahme gegen diesen Weg.
• Office-Kindprozesse blockieren. Mit Angriffsflächenregeln (ASR) verhindern, dass Office-Programme ausführbare Prozesse starten - das trifft DDE, Makro und Exploit gleichermaßen.
• Anwendungssteuerung. Mit AppLocker oder WDAC verhindern, dass ein aus Office gestarteter Interpreter oder eine Datei aus dem Benutzerpfad ausgeführt wird.
• Gezielt überwachen. Office-Programme als Elternprozess von Interpretern, LOLBins und Prozessen aus Benutzerpfaden als feste Erkennungen führen.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten System mit aktivem Sysmon - ohne echtes DDE-Dokument, allein durch Nachstellen der Prozesskette:

• Für Regel 1 aus einem umbenannten oder testweise als winword.exe gestarteten Prozess einen Interpreter aufrufen und prüfen, dass Event 4688 die Eltern-Kind-Beziehung zeigt.
• Für Regel 2 denselben Aufbau mit rundll32 oder certutil als Kindprozess nachstellen und den Treffer in der Prozess-Telemetrie kontrollieren.
• Für Regel 3 aus einem Office-ähnlichen Prozess eine harmlose EXE aus einem Temp-Pfad starten und prüfen, dass der Treffer erscheint.
• Breiter wird der Test mit den Fällen zu T1559.002 aus Atomic Red Team.

Fehlalarme und Tuning

• Add-ins und Integrationen. Einzelne Office-Add-ins starten Hilfsprozesse. Bekannte Fälle nach Kommandozeile und Add-in als Baseline ausnehmen, bevor die Regeln scharf geschaltet werden.
• Automatisierung. Manche Fachanwendungen steuern Office per Skript und lösen dabei Kindprozesse aus. Diese bekannten Quellen nach Prozess und Pfad ausnehmen.
• Kind und Pfad sind entscheidend. Ein gestarteter Interpreter wiegt weit schwerer als ein bekanntes Hilfsprogramm aus einem Herstellerpfad - danach priorisieren.
• Kette schlägt Einzelzeile. Das Office-Programm, das einen Interpreter startet, der kurz darauf nachlädt, ist weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.

Fazit

Dynamic Data Exchange zeigt, dass ein Office-Dokument auch ohne Makro Code ausführen kann: Der Befehl steckt in einem Feld, und eine Bestätigung genügt. Für den Verteidiger ist der genaue Mechanismus zweitrangig, denn der Weg endet immer gleich - ein Office-Programm startet einen fremden Prozess, einen Interpreter, einen LOLBin oder eine Datei aus dem Benutzerpfad. Die wirksamste Härtung ist, DDE per Richtlinie abzuschalten und Office-Kindprozesse mit ASR-Regeln zu blockieren. Der Makro-Weg ist die schädliche Datei mit Office-Makro; die Skript-Variante der Windows Script Host. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Execution.