Execution (MITRE ATT&CK, Taktik TA0002) umfasst alle Techniken, mit denen ein Angreifer eigenen Code auf einem Zielsystem ausführt. Der Dreh- und Angelpunkt sind Skript-Interpreter wie PowerShell, die Windows-Eingabeaufforderung und Unix-Shells, dazu geplante Tasks und WMI. Dieser Hub zeigt die wichtigsten Techniken mit publizierten Beispiel-Payloads und jeweils der passenden Erkennung. Gerade bei Execution ist die Verteidigung oft im Vorteil, weil Code-Ausführung reichlich Telemetrie erzeugt.
Was ist Execution?
Execution ist der Schritt, in dem aus einem Zugang eine Aktion wird. Ein Angreifer mag über Phishing oder eine Schwachstelle hereingekommen sein (Initial Access) - aber erst die Ausführung von Code macht daraus Handlungsfähigkeit. Fast jeder weitere Schritt, von Persistence bis Credential Access, beginnt mit einer Form von Execution.
Weil Code-Ausführung auf modernen Systemen umfangreiche Spuren hinterlässt (Prozesserstellung, Skript-Logging, Kommandozeilen), ist diese Taktik einer der dankbarsten Ansatzpunkte für die Erkennung. Die folgenden Techniken sind die praktisch wichtigsten.
| Technik | ATT&CK | Kurzbeschreibung |
|---|---|---|
| PowerShell | T1059.001 | Ausführung über den PowerShell-Interpreter, oft dateilos |
| Windows Command Shell | T1059.003 | Klassische cmd.exe-Ausführung |
| Unix Shell | T1059.004 | Bash und andere Shells auf Linux und macOS |
| Scheduled Task/Job | T1053 | Ausführung über geplante Aufgaben (zugleich Persistence) |
| Windows Management Instrumentation | T1047 | Ausführung über WMI, auch remote |
Operatives Ziel, Voraussetzungen und Alternativen
Execution ist kein Selbstzweck: Das operative Ziel ist, aus einem Zugang Handlungsfähigkeit zu machen. Weil Code-Ausführung viel Telemetrie erzeugt, entscheidet ein Red Teamer bewusst, womit er ausführt - nicht reflexhaft mit PowerShell.
| Frage | Überlegung |
|---|---|
| Wann? | Direkt nach dem Erstzugang und auf jedem neu erreichten System - fast jeder weitere Schritt beginnt mit einer Form von Execution. |
| Voraussetzungen | Ein Ausführungskontext (Shell, Makro, Dienst) und meist Benutzerrechte; dateilose Ausführung braucht einen Interpreter. |
| Alternativen | PowerShell, cmd, WMI oder ein in der Umgebung ohnehin genutztes Bordmittel - die leiseste Option fügt sich ins Normalverhalten ein. |
| Tradeoff | PowerShell ist mächtig, aber stark beobachtet; ein eigenes Binary umgeht das Skript-Logging, erzeugt aber eine verdächtige neue Datei. |
In der durchgehenden, autorisierten Übung bei der fiktiven Nordlicht Logistik GmbH folgt auf das Phishing eines Disponenten genau dieser Schritt: Eine PowerShell-Stage lädt den Beacon in den Speicher. Das Team wählt bewusst den Interpreter, der auf diesen Workstations ohnehin für Logistik-Skripte läuft - so geht die Ausführung im Normalverhalten unter, statt ein neues Binary zu riskieren.
PowerShell (T1059.001)
PowerShell ist einer der verbreitetsten und flexibelsten Ausführungswege unter Windows, weil es tief ins System integriert ist und Code direkt im Speicher ausführen kann, ohne eine Datei auf die Platte zu schreiben. Der Klassiker ist der Download Cradle, der ein Skript aus dem Netz lädt und direkt ausführt:
Script Block Logging (Event ID 4104) macht auch verschleierten PowerShell-Code sichtbar, Module Logging (4103) protokolliert aufgerufene Cmdlets. Verdächtig sind Parameter wie -enc, -nop oder -w hidden sowie Netzwerkverbindungen direkt aus powershell.exe. Die Sigma-Regeln dazu stehen auf blue-team.net.
Unix Shell und Reverse Shells (T1059.004)
Auf Linux und macOS ist die Shell der zentrale Ausführungsweg. In Kombination mit Initial Access entsteht daraus oft eine Reverse Shell, bei der das Ziel die Verbindung zum Angreifer aufbaut und so eingehende Firewall-Regeln umgeht:
Der verräterische Indikator ist ein Shell-Prozess mit einem Socket als Standard-Ein- und -Ausgabe. In der Telemetrie: eine Shell (bash, sh) als Kind eines ungewöhnlichen Prozesses und mit ausgehender Netzwerkverbindung. Auf Linux liefern auditd und eBPF-basierte Sensoren die nötige Sicht. Details auf blue-team.net.
Scheduled Task und WMI (T1053, T1047)
Geplante Tasks und WMI dienen der Ausführung, oft zugleich der Persistenz oder der Remote-Ausführung. Beide sind legitime Windows-Mechanismen, was ihre Erkennung anspruchsvoll macht: Der Missbrauch fällt nur im Kontext auf.
Erstellung geplanter Tasks (Event ID 4698), WMI-Aktivität (Event ID 5857-5861 bei aktiviertem WMI-Tracing) und schtasks.exe oder wmic.exe als Kind ungewöhnlicher Prozesse. Besonders auffällig: Tasks, die Skript-Interpreter mit verschleierten Argumenten starten. Erkennungslogik auf blue-team.net.
Einordnung und Grenze
Die hier gezeigten Payloads sind seit Jahren publiziert und in jedem Cheat Sheet zu finden. Was dieser Hub bewusst nicht liefert, sind Techniken zur Umgehung von Script Block Logging, AMSI oder Endpoint-Schutz - die AV- und EDR-Evasion bleibt außen vor. Der Fokus liegt auf dem Verständnis der Ausführungswege und ihrer Spuren.
Alle Commands gehören ausschließlich in autorisierte Tests mit wirksamer Erlaubnis des Berechtigten. Der Einsatz gegen fremde Systeme ohne Berechtigung kann abhängig vom Einzelfall strafrechtlich relevant sein. Dieser Beitrag dient der Information und der Absicherung legitimer Sicherheitsarbeit und ist keine Rechtsberatung.
Einordnung in die Angriffskette
Execution folgt meist direkt auf Initial Access und ist das Sprungbrett zu Persistence, Credential Access und der Kommunikation über Command & Control. Einen Überblick über alle Taktiken gibt die Payload-Sammlung.
Häufige Fragen
Warum ist PowerShell bei Angreifern so beliebt?
Weil es vorinstalliert, mächtig und tief ins System integriert ist und Code direkt im Speicher ausführen kann. Genau deshalb ist umfassendes PowerShell-Logging eine der wirksamsten Verteidigungsmaßnahmen.
Ist dateilose Ausführung unsichtbar?
Nein. Dateilos heißt nur, dass nichts auf die Platte geschrieben wird. Prozesserstellung, Kommandozeilen und Script Block Logging machen die Ausführung dennoch sichtbar, sofern die Telemetrie aktiviert ist.