Python-Ausführung erkennen: der stille Interpreter

Command and Scripting Interpreter ist eine der meistgenutzten Ausführungstaktiken, und Python ist einer ihrer Wege. Für den Angreifer hat es einen Reiz: Es ist ein legitimer, verbreiteter Interpreter, der beliebigen Code ausführt - und auf dem viele Erkennungen weniger scharf eingestellt sind als auf PowerShell. Auf Entwickler-Arbeitsplätzen gehört Python zum Alltag; auf einem normalen Büro-PC oder einem Server ist es dagegen die Ausnahme. Für den Verteidiger heißt das: Der Kontext entscheidet. Dieser Beitrag nimmt die Erkennung in den Blick und bleibt auf der Verteidigerseite.

Was der Angreifer tut

Der Missbrauch folgt - auf der Ebene des Prinzips, nicht als Anleitung - einigen wiederkehrenden Mustern, die am Endpunkt sichtbar sind:

• Inline-Code ausführen. Mit dem Schalter -c lässt sich Code direkt übergeben, ganz ohne Skriptdatei - praktisch, um unauffällig zu bleiben.
• Ein Skript nachladen. Eine Python-Datei landet in einem temporären oder Download-Pfad und wird von dort gestartet.
• Aus einem Dokument heraus starten. Ein Office-Dokument oder eine Phishing-Mail lädt Python nach und ruft es auf; der Interpreter erscheint als Kind eines ungewöhnlichen Prozesses.
• Unter dem Radar bleiben. Weil Python seltener überwacht wird als PowerShell, setzt der Angreifer darauf, dass die Ausführung untergeht.

Für die Erkennung ist entscheidend: Jeder dieser Wege hinterlässt einen Python-Prozess mit aussagekräftiger Befehlszeile oder Herkunft. Nicht Python an sich ist das Signal, sondern wie und woher es startet.

Welche Logquellen die Technik zeigt

• Prozess-Telemetrie zuerst. Event 4688 zeigt python.exe samt vollständiger Befehlszeile und übergeordnetem Prozess - die wichtigste Quelle für diese Technik.
• Befehlszeilen-Kontext. Der Schalter -c und Pfade wie Temp oder Downloads in der Befehlszeile heben die auffälligen Aufrufe heraus.
• Eltern-Kind-Beziehung. Entscheidend ist, wer Python startet; ein Aufruf aus einem Office-Programm oder einem Skript-Host ist ein starkes Signal.
• Werkzeug-Kontext. Python ist ein legitimer Interpreter; erst der Kontext macht den Unterschied. Grundlagen zum Missbrauch mitgebrachter oder installierter Interpreter unter Living off the Land.

Das Muster im Log

Drei Signale tragen. Das erste ist Python mit dem Schalter -c, also Inline-Code ohne Datei. Das zweite ist Python, dessen Befehlszeile auf Temp, Downloads, AppData oder das öffentliche Benutzerverzeichnis verweist. Das dritte ist Python als Kind eines Office-, Mail- oder Skript-Host-Prozesses. Die ersten beiden stehen auf mittlerer Stufe, weil Entwicklung und Automatisierung ähnlich aussehen können; die Eltern-Kind-Regel steht auf hoher Stufe, weil ein Office-Programm kaum je Python startet. Legitime Treffer stammen von Entwickler-Arbeitsplätzen, Installern und Automatisierung - solche bekannten Hosts und Skripte gehören als Baseline ausgenommen. Auffällig wird es, wenn Python auf einem System auftaucht, das es sonst nie nutzt, oder aus einem Dokument heraus startet. Der Blick auf Befehlszeile, Pfad, Eltern und Host trennt den Alltag vom Angriff.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und nehmen die drei Signale: Inline-Code, Ausführung aus einem auffälligen Pfad und den Start aus einem Office-, Mail- oder Skript-Host-Prozess. Alle drei werten die Prozess-Telemetrie aus.

1. Python führt Inline-Code aus (T1059.006). python mit dem Schalter -c. Die Regel steht auf level: medium.

title: Python fuehrt Inline-Code aus (-c)
id: 5b2a9e74-3c81-4d62-a1f7-8c3d6b5e2a94
status: experimental
description: |
  Erkennt den Start von Python mit dem Schalter -c, der inline uebergebenen Code direkt ausfuehrt. Angreifer
  nutzen diesen Weg, um Code ohne eine Skriptdatei laufen zu lassen (Command and Scripting Interpreter: Python).
  In vielen Umgebungen ist Python auf Endpunkten unueblich und die Inline-Ausfuehrung ein Signal.
references:
  - https://attack.mitre.org/techniques/T1059/006/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.006
logsource:
  product: windows
  category: process_creation
detection:
  sel:
    Image|endswith:
      - '\\python.exe'
      - '\\pythonw.exe'
      - '\\python3.exe'
    CommandLine|contains: ' -c '
  condition: sel
falsepositives:
  - Entwicklung und Automatisierung nutzen python -c legitim - bekannte Hosts, Konten und Skripte als Baseline ausnehmen
level: medium

2. Python führt eine Datei aus einem auffälligen Pfad aus (T1059.006). Ein Python-Aufruf mit Temp, Downloads, AppData oder dem öffentlichen Verzeichnis in der Befehlszeile. Ebenfalls level: medium.

title: Python fuehrt eine Datei aus einem auffaelligen Pfad aus
id: 7c3e8a24-6d91-4b53-a2f7-1d5c9b6e4a38
status: experimental
description: |
  Erkennt Python, dessen Befehlszeile auf einen auffaelligen Pfad verweist - Temp, Downloads, AppData oder das
  oeffentliche Benutzerverzeichnis. Nachgeladene Python-Skripte landen oft an solchen Orten und werden von dort
  ausgefuehrt (Command and Scripting Interpreter: Python).
references:
  - https://attack.mitre.org/techniques/T1059/006/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.006
logsource:
  product: windows
  category: process_creation
detection:
  sel_img:
    Image|endswith:
      - '\\python.exe'
      - '\\pythonw.exe'
      - '\\python3.exe'
  sel_path:
    CommandLine|contains:
      - '\\Temp\\'
      - '\\Downloads\\'
      - '\\AppData\\'
      - '\\Users\\Public\\'
  condition: sel_img and sel_path
falsepositives:
  - Entwicklungsumgebungen und Installer fuehren Python aus solchen Pfaden legitim aus - bekannte Faelle als Baseline ausnehmen
level: medium

3. Python aus einem Office-, Mail- oder Skript-Host-Prozess gestartet (T1059.006). Python als Kind von winword, excel, outlook, wscript und Co. Wegen der Seltenheit auf level: high.

title: Python aus einem Office-, Mail- oder Skript-Host-Prozess gestartet
id: 9a4c2e68-1d75-4b92-a6f3-7c5d8b2e4a16
status: experimental
description: |
  Erkennt Python als Kindprozess eines Office-Programms, von Outlook oder eines Skript-Hosts. Ein Dokument oder
  eine Phishing-Mail, die Python nachlaedt und startet, erzeugt genau diese Eltern-Kind-Kette (Command and
  Scripting Interpreter: Python). Solche Elternprozesse starten normalerweise kein Python.
references:
  - https://attack.mitre.org/techniques/T1059/006/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.006
logsource:
  product: windows
  category: process_creation
detection:
  sel:
    ParentImage|endswith:
      - '\\winword.exe'
      - '\\excel.exe'
      - '\\powerpnt.exe'
      - '\\outlook.exe'
      - '\\wscript.exe'
      - '\\cscript.exe'
      - '\\mshta.exe'
    Image|endswith:
      - '\\python.exe'
      - '\\pythonw.exe'
      - '\\python3.exe'
  condition: sel
falsepositives:
  - Sehr selten starten Office-Add-Ins oder Automatisierung legitim Python - bekannte Faelle als Baseline ausnehmen
level: high

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

• Python dort entfernen, wo es nicht gebraucht wird. Auf Büro-PCs und Servern ohne Entwicklungszweck gehört kein Interpreter; wo er fehlt, läuft dieser Weg ins Leere.
• Anwendungssteuerung. Mit AppLocker oder WDAC steuern, welche Interpreter überhaupt starten dürfen - und python.exe auf die Hosts begrenzen, die es wirklich brauchen.
• Befehlszeile protokollieren. Die Prozess-Befehlszeile (Event 4688 mit Command-Line-Auditing oder Sysmon) zuverlässig erfassen - ohne sie fehlt der entscheidende Kontext.
• Office-Kindprozesse einschränken. Regeln zur Angriffsflächenreduzierung, die Office das Starten von Kindprozessen verbieten, nehmen der Eltern-Kind-Kette die Grundlage.

Der Test

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

• Für Regel 1 python mit -c und einer harmlosen Ausgabe aufrufen und prüfen, dass Event 4688 die Befehlszeile zeigt.
• Für Regel 2 ein leeres Python-Skript in den Downloads-Ordner legen und von dort starten und kontrollieren, dass die Regel auf den Pfad anspringt.
• Für Regel 3 Python aus einem harmlosen Elternprozess starten, der wie ein Office-Programm heißt, und prüfen, dass die Eltern-Kind-Regel greift.
• Breiter wird der Test mit den Fällen zu T1059 aus Atomic Red Team.

Fehlalarme und Tuning

• Entwickler-Arbeitsplätze. Wo Python zum Alltag gehört, sind -c und Ausführungen aus AppData normal. Solche Hosts und Nutzer als Baseline aufnehmen, bevor die Regeln scharf geschaltet werden.
• Installer und Automatisierung. Setup-Programme und Build-Jobs führen Python aus temporären Pfaden aus; bekannte Fälle und Zeitfenster dokumentieren und ausnehmen.
• Host-Kontext entscheidet. Python auf einem Entwickler-PC ist Alltag; dasselbe auf einem Büro-PC oder Server ist es nicht - nach dem Host priorisieren.
• Kette schlägt Einzelzeile. Python aus einem Office-Prozess zusammen mit einem Nachladen oder weiterer Aktivität ist weit aussagekräftiger als ein Treffer allein - die Korrelation schärft die Bewertung.

Fazit

Python ist ein legitimer Interpreter, der genau deshalb als Ausführungsweg taugt: Er führt beliebigen Code aus und steht seltener unter Beobachtung als PowerShell. Die verlässlichen Signale sind Inline-Code per -c, die Ausführung aus einem auffälligen Pfad und der Start aus einem Office-, Mail- oder Skript-Host-Prozess. Weil Python auf Entwickler-Arbeitsplätzen Alltag, auf Büro-PCs und Servern aber die Ausnahme ist, liegt die Stärke im Kontext: Befehlszeile, Pfad, Elternprozess und Host entscheiden. Die wirksamste Härtung ist, Python dort zu entfernen oder per Anwendungssteuerung zu begrenzen, wo es nicht gebraucht wird. Weitere Techniken dieser Taktik führt das Lexikon nach Taktik unter Execution.