Windows Command Shell erkennen: cmd.exe als Angriffswerkzeug

Nach PowerShell ist die klassische Eingabeaufforderung der zweite große Interpreter unter Windows. cmd.exe ist überall vorhanden, wird selten überwacht und fällt im Rauschen kaum auf - ideal, um die nächste Stufe eines Angriffs zu starten. Meist steht cmd nicht am Anfang, sondern als Bindeglied: Ein Office-Makro ruft es auf, es startet ein Batch-Skript oder fasst mehrere Schritte in einer Zeile zusammen. ATT&CK führt das als Windows Command Shell, eine Untertechnik von Command and Scripting Interpreter. Dieser Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Der Missbrauch der Eingabeaufforderung läuft - auf der Ebene des Prinzips, nicht als Anleitung - in wenigen Mustern ab:

• Als Bindeglied starten. Ein Makro, eine Verknüpfung oder ein anderer Erstzugang ruft cmd.exe auf, um den nächsten Schritt anzustoßen.
• Batch-Skripte nutzen. Die Schadsoftware legt ein .bat- oder .cmd-Skript in einem Temp- oder Benutzer-Verzeichnis ab und lässt es über die Eingabeaufforderung laufen.
• Einzeiler bauen. Mehrere Schritte werden mit Operatoren wie && in einer einzigen Befehlszeile verkettet - oft mit einem Nachlade-Werkzeug darin.
• Unauffällig bleiben. Weil cmd.exe überall vorkommt, geht der Aufruf im normalen Rauschen leicht unter - der Angreifer setzt genau darauf.

Für die Erkennung ist entscheidend: Nicht cmd.exe selbst ist das Signal, sondern der Kontext - der auslösende Prozess, der Pfad des Skripts und die verkettete Zeile. Genau daran setzen die Regeln an.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie zuerst. Event 4688 zeigt cmd.exe samt übergeordnetem Prozess und vollständiger Befehlszeile - also Herkunft, Skriptpfad und die ganze Zeile. Die wichtigste Quelle.
• Eltern-Kind-Beziehung. Entscheidend ist, wer cmd.exe aufruft; ein Office-Programm als Elternprozess ist ein starkes Signal und steht in der Prozess-Telemetrie.
• Datei-Telemetrie. Das vorherige Ablegen eines Batch-Skripts in Temp oder AppData zeigt sich im Datei-Log und ergänzt die Prozesszeile.
• Werkzeug-Kontext. cmd ruft oft weitere Bordmittel auf; Grundlagen zum Missbrauch solcher Programme unter Living off the Land.

Das Muster im Log

Drei Signale tragen. Das erste ist cmd.exe als Kindprozess eines Office-Programms - ein starker Hinweis auf ein Makro, das die Kommandozeile missbraucht. Das zweite ist cmd.exe, das eine Batch-Datei aus einem Temp- oder Benutzer-Verzeichnis startet. Das dritte ist eine verkettete Befehlszeile mit && und einem Nachlade-Werkzeug wie certutil oder bitsadmin. Legitime Treffer stammen aus Installern, Wartungs- und Build-Skripten, die Batch-Dateien und Werkzeuge bewusst nutzen. Auffällig wird es, wenn ein Office-Programm cmd aufruft, ein Skript aus einem Download-Ordner läuft oder ein Einzeiler Nachladen und Ausführen verbindet. Der Blick auf Elternprozess, Pfad und Befehlszeile trennt den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: cmd als Kind eines Office-Programms, die Batch-Datei aus einem temporären Verzeichnis und die verkettete Zeile mit Nachlade-Werkzeug. Alle drei werten die Prozess-Telemetrie aus.

1. cmd.exe als Kind eines Office-Programms gestartet (T1059.003). cmd.exe mit einem Office-Programm als Elternprozess. Die Regel steht auf level: high.

title: cmd.exe als Kind eines Office-Programms gestartet
id: 5d7a9c31-6b24-4e85-a3f1-8c2d7b4e9a63
status: experimental
description: |
  Erkennt den Start von cmd.exe als Kindprozess eines Office-Programms (Word, Excel, PowerPoint,
  Outlook und weitere). Ein Makro oder eine praeparierte Datei startet ueber die Kommandozeile weitere
  Befehle (Windows Command Shell). Dass ein Office-Programm cmd.exe aufruft, ist im Normalbetrieb sehr
  ungewoehnlich und ein starkes Signal.
references:
  - https://attack.mitre.org/techniques/T1059/003/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.003
logsource:
  product: windows
  category: process_creation
detection:
  sel_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\mspub.exe'
      - '\msaccess.exe'
  sel_child:
    Image|endswith: '\cmd.exe'
  condition: sel_parent and sel_child
falsepositives:
  - Einzelne Office-Add-ins oder Makro-Vorlagen starten cmd legitim - bekannte Faelle nach Vorlage und Host als Baseline ausnehmen
level: high

2. cmd.exe führt Batch-Datei aus temporärem Verzeichnis aus (T1059.003). Eine .bat oder .cmd aus Temp, AppData, Downloads, Public oder ProgramData. Die Regel steht auf level: medium.

title: cmd.exe fuehrt Batch-Datei aus temporaerem Verzeichnis aus
id: 8f2c6b43-7a95-4d61-b5e2-9c3d7a4f1e86
status: experimental
description: |
  Erkennt cmd.exe, das eine Batch-Datei (.bat oder .cmd) aus einem temporaeren oder Benutzer-Verzeichnis
  ausfuehrt (Temp, AppData, Downloads, Public, ProgramData). Schadsoftware legt Batch-Skripte an solchen
  Orten ab und startet sie ueber die Kommandozeile (Windows Command Shell). Eine Batch-Datei aus einem
  solchen Pfad ist im Normalbetrieb ungewoehnlich.
references:
  - https://attack.mitre.org/techniques/T1059/003/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.003
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\cmd.exe'
  sel_bat:
    CommandLine|contains:
      - '.bat'
      - '.cmd'
  sel_loc:
    CommandLine|contains:
      - '\Temp\'
      - '\AppData\'
      - '\Downloads\'
      - '\Public\'
      - '\ProgramData\'
  condition: sel_img and sel_bat and sel_loc
falsepositives:
  - Installer und Wartungsskripte legen Batch-Dateien in Temp ab - bekannte Faelle nach Pfad und Host als Baseline ausnehmen
level: medium

3. Verkettete cmd-Befehlszeile mit Nachlade-Werkzeug (T1059.003). Eine Zeile mit && und certutil, bitsadmin, curl, mshta oder powershell. Ebenfalls level: medium.

title: Verkettete cmd-Befehlszeile mit Nachlade-Werkzeug
id: 3a9e5c17-4d82-4b73-9f26-7c2d8e4a1b59
status: experimental
description: |
  Erkennt eine verkettete cmd-Befehlszeile (Operator &&), die ein bekanntes Nachlade- oder
  Ausfuehrungswerkzeug aufruft (certutil, bitsadmin, curl, mshta oder powershell). Angreifer fassen
  mehrere Schritte in einer Einzeiler-Befehlszeile zusammen und laden darueber Code nach oder fuehren ihn
  aus (Windows Command Shell). Diese Kombination ist im Normalbetrieb ungewoehnlich.
references:
  - https://attack.mitre.org/techniques/T1059/003/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.003
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith: '\cmd.exe'
  sel_chain:
    CommandLine|contains: '&&'
  sel_tool:
    CommandLine|contains:
      - 'certutil'
      - 'bitsadmin'
      - 'curl '
      - 'mshta'
      - 'powershell'
  condition: sel_img and sel_chain and sel_tool
falsepositives:
  - Einzelne Build- und Administrationsskripte verketten Befehle mit diesen Werkzeugen - bekannte Faelle als Baseline ausnehmen
level: medium

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

• Makros einschränken. Office-Makros aus dem Internet per Richtlinie blockieren - das nimmt dem häufigsten Weg, über den ein Office-Programm cmd.exe startet, die Grundlage.
• Ausführung steuern. Mit AppLocker oder WDAC das Starten von Skripten und Programmen aus Temp- und Benutzer-Verzeichnissen einschränken.
• Kommandozeile protokollieren. Die Prozess-Befehlszeile (Event 4688 mit Command-Line-Auditing oder Sysmon) zuverlässig erfassen - ohne sie bleibt der Kontext unsichtbar.
• Gezielt überwachen. cmd aus Office, Batch-Dateien aus Temp und verkettete Zeilen mit Nachlade-Werkzeugen als feste Erkennungen führen und mit dem Ingress Tool Transfer korrelieren.

Der Test

Die Erkennung lässt sich im Lab gefahrlos prüfen, auf einem isolierten System mit aktivem Sysmon und Command-Line-Auditing - mit harmlosen Testbefehlen:

• Für Regel 1 aus einem Office-Dokument heraus in einer Testumgebung cmd.exe mit einem harmlosen Befehl starten und prüfen, dass Event 4688 die Eltern-Kind-Beziehung zeigt.
• Für Regel 2 eine harmlose Test-Batch in den Temp-Ordner legen, per cmd starten und prüfen, dass die Regel greift.
• Für Regel 3 eine verkettete Zeile wie cmd /c echo test && certutil -? ausführen und kontrollieren, dass die Regel den Treffer meldet.
• Breiter wird der Test mit den Fällen zu T1059.003 aus Atomic Red Team.

Fehlalarme und Tuning

• Installer und Setups. Setup-Programme legen Batch-Dateien in Temp ab und rufen cmd auf. Bekannte Installer und Pfade als Baseline ausnehmen, bevor die Regeln scharf geschaltet werden.
• Build- und Wartungsskripte. Entwickler- und Administrationsskripte verketten Befehle und nutzen certutil oder curl legitim. Diese Hosts und Skripte gezielt behandeln.
• Elternprozess entscheidet. cmd allein ist Alltag; cmd mit einem Office-Programm als Elternprozess ist es nicht - nach dem Kontext priorisieren.
• Kette schlägt Einzelzeile. cmd aus Office zusammen mit anschließendem Nachladen und Ausführen ist weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.

Fazit

Die Windows Command Shell ist das unauffällige Bindeglied vieler Angriffe: cmd.exe startet die nächste Stufe, läuft als Batch aus dem Temp-Ordner oder fasst mehrere Schritte in einer Zeile zusammen. Die verlässlichen Signale sind cmd als Kind eines Office-Programms, eine Batch-Datei aus einem temporären Verzeichnis und eine verkettete Zeile mit einem Nachlade-Werkzeug. Die wirksamste Härtung ist das Einschränken von Makros und der Ausführung aus Temp-Pfaden, zusammen mit einem zuverlässigen Protokoll der Befehlszeile. Wie der Erstzugang über ein Office-Makro aussieht und weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Execution.