PowerShell-Logging per GPO: Skripte nachvollziehbar machen

PowerShell ist auf jedem Windows-Rechner vorhanden, lässt sich mit einer Zeile Code fernsteuern und wird von Angreifern regelmäßig im Speicher ausgeführt. Wer nichts protokolliert, sieht davon nichts. Microsoft liefert die passenden Schalter mit — aktiv sind sie standardmäßig nicht.

Drei Protokolle, drei Blickwinkel

Die Skriptblockprotokollierung schreibt den Inhalt jedes verarbeiteten Skriptblocks als Ereignis-ID 4104 ins Ereignisprotokoll. Sie erfasst auch Blöcke, die aus Base64 dekodiert oder zur Laufzeit zusammengesetzt werden — der wichtigste Baustein für Forensik. Die Modulprotokollierung (Ereignis-ID 4103) zeichnet Pipelineaufrufe pro Modul auf und ist deutlich schlanker. Die Transkription schreibt komplette Sitzungen als Textdatei weg.

Windows PowerShell 5.1 loggt in den Kanal Windows PowerShell/Operational, PowerShell 7 in PowerShellCore/Operational. Beide Kanäle müssen getrennt aktiviert werden, sonst bleibt die Hälfte der Umgebung unsichtbar.

Aktivieren per Gruppenrichtlinie

Die Einstellungen liegen unter Computerkonfiguration → Richtlinien → Administrative Vorlagen → Windows-Komponenten → Windows PowerShell. Dort drei Werte auf „Aktiviert“ stellen: „Modulprotokollierung aktivieren“, „PowerShell-Skriptblockprotokollierung aktivieren“ und „PowerShell-Transkription aktivieren“.

Für PowerShell 7 existiert ein eigener Zweig „PowerShell Core“ mit denselben Optionen, alternativ steuert man das über die Datei powershell.config.json. Bei der Transkription ein Ausgabeverzeichnis angeben (etwa \\fileserver\logs$\powershell) und „Aufrufheader einschließen“ aktivieren, damit Zeitstempel und Benutzer in den Dateinamen landen.

Schnelltest ohne GPO

Auf einer Testmaschine lässt sich das vorab über die Registry prüfen. Wichtig: Der Richtlinienzweig unter Policies gewinnt gegen lokale Einstellungen, eine spätere GPO überschreibt den Test also wieder.

$p = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell'
New-Item "$p\ScriptBlockLogging" -Force | Out-Null
Set-ItemProperty "$p\ScriptBlockLogging" -Name EnableScriptBlockLogging -Value 1
New-Item "$p\ModuleLogging\ModuleNames" -Force | Out-Null
Set-ItemProperty "$p\ModuleLogging" -Name EnableModuleLogging -Value 1
Set-ItemProperty "$p\ModuleLogging\ModuleNames" -Name '*' -Value '*'
gpupdate /force

Danach in einer neuen Sitzung ein Testskript ausführen und prüfen, ob 4104 auftaucht: Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' -MaxEvents 20 | Where-Object Id -eq 4104.

Kommandozeilen mitprotokollieren

Ergänzend lohnt Ereignis-ID 4688 aus der Prozesserstellung. Dafür in der erweiterten Überwachungsrichtlinie unter „Detaillierte Überwachung“ die Option „Prozesserstellung überwachen“ auf Erfolg stellen. Zusätzlich unter Administrative Vorlagen → System → Überwachungsprozesserstellung die Einstellung „Befehlszeile in Prozesserstellungsereignisse einschließen“ aktivieren.

Erst damit steht im Sicherheitsprotokoll, mit welchen Parametern powershell.exe gestartet wurde — etwa -enc mit einem Base64-Block oder -w hidden. Vorsicht: Kommandozeilen können Kennwörter im Klartext enthalten, jeder mit Leserecht auf das Sicherheitsprotokoll sieht sie.

Auswerten und filtern

4104-Ereignisse sind zahlreich. Vor der Weiterleitung an ein SIEM lohnt ein Filter auf typische Angriffsmuster:

Get-WinEvent -LogName 'Microsoft-Windows-PowerShell/Operational' -MaxEvents 5000 |
  Where-Object Id -eq 4104 |
  Where-Object { $_.Message -match 'FromBase64String|DownloadString|Invoke-Expression|IEX' } |
  Select-Object TimeCreated, @{n='Block';e={ $_.Message.Substring(0, [Math]::Min(200, $_.Message.Length)) }}

Was in der Praxis schiefgeht

Auf Servern mit Exchange oder Configuration Manager kann die Skriptblockprotokollierung mehrere hundert Megabyte pro Tag erzeugen, weil dort permanent PowerShell läuft. Log-Größe, Aufbewahrung und zentrale Sammlung per Windows Event Forwarding oder SIEM müssen deshalb vor dem Rollout stehen — sonst rollt das lokale Log die Spuren weg.

Transkripte sind Klartext: Wer dort Kennwörter sieht, sieht sie auch in der Dateiablage. Das Zielverzeichnis gehört auf ein administrativ geschütztes Share mit restriktiven NTFS-Rechten. Für besonders sensible Umgebungen bietet Windows die geschützte Ereignisprotokollierung, die Log-Inhalte mit einem Zertifikat verschlüsselt.

Und: Die Protokollierung ersetzt keine Application-Whitelist. Sie macht sichtbar, was passiert ist; unterbinden müssen es AppLocker oder WDAC — die Execution Policy ist keine Sicherheitsgrenze.

Quellen

Microsoft Learn: about_Logging_Windows — PowerShell-Protokollierung (abgerufen am 10.11.2026)

Microsoft Learn: Überwachen von Befehlszeilenprozessen (Ereignis 4688) (abgerufen am 10.11.2026)

SOC Prime: How to Enable and Export PowerShell Script Block Logs (22.10.2026)

Hinweis: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz (KI) erstellt.