Event-ID 400: PowerShell-Engine gestartet

Event 400 („Engine state is changed from None to Available“) schreibt Windows in das klassische Log Windows PowerShell, jedes Mal wenn eine PowerShell-Engine startet. Das zugehörige Event 403 protokolliert das Ende der Sitzung. Beide Events sind unabhängig von Gruppenrichtlinien immer aktiv und liefern zwei Informationen, die sonst schwer zu bekommen sind: die verwendete PowerShell-Version und die vollständige Kommandozeile der Host-Anwendung.

Die wichtigsten Felder

Die Werte stehen als Schlüssel-Wert-Paare im Feld Data bzw. im Nachrichtentext:

• EngineVersion: die Version der gestarteten Engine, z. B. 5.1.19041.1 oder 2.0.
• HostVersion: die Version der Host-Anwendung.
• HostName: bei der normalen Konsole ConsoleHost, bei der ISE Windows PowerShell ISE Host, bei Remoting ServerRemoteHost.
• HostApplication: die vollständige Kommandozeile, z. B. powershell.exe -nop -w hidden -enc ....
• RunspaceId: verknüpft Start und Ende einer Sitzung.

Worauf du bei der Detection achtest

• Downgrade auf PowerShell 2.0: EngineVersion=2.0 auf einem System mit PowerShell 5. Angreifer starten gezielt powershell.exe -version 2, weil die alte Version weder Script Block Logging (4104) noch Module Logging (4103) noch AMSI kennt.
• Verdächtige Kommandozeilen: HostApplication mit -enc, -w hidden, -nop oder Download-Befehlen. Das ist eine Alternative, falls 4688 ohne Kommandozeile protokolliert wird.
• Unmanaged PowerShell: HostApplication zeigt einen Prozess, der nicht powershell.exe oder pwsh.exe ist, etwa rundll32.exe oder ein unbekanntes Programm. Frameworks wie Cobalt Strike (powerpick) laden die PowerShell-Engine direkt in fremde Prozesse.
• Remoting von ungewöhnlichen Quellen: HostName=ServerRemoteHost auf Systemen, die sonst nicht per PowerShell-Remoting verwaltet werden.

Typische False Positives

Jeder PowerShell-Start erzeugt ein Event 400, das Volumen hängt also stark von deinen Admin- und Management-Skripten ab. Echte Downgrades auf Version 2.0 sind in modernen Umgebungen dagegen selten und fast immer eine Prüfung wert. Einige sehr alte Fachanwendungen fordern PowerShell 2.0 noch ausdrücklich an. Diese solltest du kennen und dokumentieren.

Voraussetzung

Event 400 wird ohne weitere Konfiguration geschrieben. Du musst nur das Log Windows PowerShell an dein SIEM weiterleiten, das oft vergessen wird, weil es neben dem Operational-Log existiert. Die wirksamste Gegenmaßnahme gegen Downgrades ist, die Windows-Funktion „Windows PowerShell 2.0“ zu entfernen. Auf aktuellen Windows-Versionen ist sie standardmäßig nicht mehr vorhanden, auf älteren Systemen ist sie häufig noch installiert.

Sigma-Regel (Beispiel)

title: PowerShell-Downgrade auf Version 2.0
status: experimental
description: Erkennt den Start der PowerShell-Engine in Version 2.0 auf Systemen mit neuerer PowerShell. Angreifer nutzen das, um Script Block Logging und AMSI zu umgehen.
references:
  - https://attack.mitre.org/techniques/T1562/010/
author: blue-team.net
tags:
  - attack.defense-evasion
  - attack.t1562.010
logsource:
  product: windows
  category: ps_classic_start
detection:
  selection:
    Data|contains: 'EngineVersion=2.'
  filter_old_host:
    Data|contains: 'HostVersion=2.'
  condition: selection and not filter_old_host
falsepositives:
  - Sehr alte Anwendungen, die ausdruecklich PowerShell 2.0 anfordern
level: medium

Beispielregel als Ausgangspunkt. Vor dem produktiven Einsatz an die eigene Umgebung, Log-Quellen und Ausnahmen anpassen.

Verwandte Event-IDs

• 4104 PowerShell-Skriptblock protokolliert
• 4103 PowerShell-Modulprotokollierung
• 91 WinRM-Shell erstellt
• 4688 Neuer Prozess erstellt