PowerShell & Scripting

PowerShell-Protokollierung (Logging und Transkription)

Overview

PowerShell bietet mehrere Protokollierungsebenen. Start-Transcript schreibt alle Eingaben und Konsolenausgaben einer Sitzung in eine Textdatei. Script Block Logging zeichnet den Inhalt aller verarbeiteten Scriptblocks im Ereignisprotokoll auf, auch wenn der Code verschleiert oder dynamisch erzeugt wurde. Module Logging protokolliert Pipeline-Ereignisse für ausgewählte Module.

Für Sicherheitsteams ist Script Block Logging die wichtigste Quelle, weil Angreifer PowerShell häufig für Living-off-the-Land-Techniken nutzen. Die Ereignisse eignen sich zur Weiterleitung an ein SIEM wie Microsoft Sentinel.

Wichtig ist die Trennung der Versionen: Windows PowerShell 5.1 schreibt in das Protokoll Microsoft-Windows-PowerShell/Operational und wird über Administrative Vorlagen > Windows-Komponenten > Windows PowerShell gesteuert. PowerShell 7 schreibt in PowerShellCore/Operational und hat eigene Richtlinien unter Administrative Vorlagen > PowerShell Core.

How it works

Die Mechanismen im Einzelnen:

  1. Transkript: Start-Transcript -Path oder -OutputDirectory startet die Aufzeichnung, -IncludeInvocationHeader ergänzt Zeitstempel je Befehl, Stop-Transcript beendet sie. Ohne Pfad landet die Datei in Dokumente (Windows) bzw. $HOME.
  2. Script Block Logging: Die Richtlinie „Turn on PowerShell Script Block Logging“ aktiviert die Aufzeichnung. Die Ereignisse tragen die ID 4104. Unter PowerShell 7 muss unter Windows zuerst der Ereignisanbieter mit $PSHOME\RegisterManifest.ps1 registriert werden. Alternativ lässt sich die Option in powershell.config.json setzen.
  3. Module Logging: Es muss für die Sitzung und je Modul aktiviert sein, etwa über die Eigenschaft LogPipelineExecutionDetails.
  4. Protected Event Logging: Verschlüsselt die Protokolleinträge nach dem CMS-Standard mit einem Zertifikat mit der erweiterten Schlüsselverwendung Document Encryption. Die Richtlinie liegt unter Windows-Komponenten > Event Logging. Entschlüsselt wird auf einem gesicherten System mit Unprotect-CmsMessage, der private Schlüssel gehört nicht auf die protokollierenden Rechner.

Benefits

  • Nachvollziehbarkeit: Auch verschleierte oder zur Laufzeit erzeugte Befehle erscheinen im Klartext im Protokoll
  • Forensik: Nach einem Vorfall lässt sich rekonstruieren, welche Befehle mit welchem Konto liefen
  • Compliance: Protokolle belegen administrative Tätigkeiten, etwa für NIS2-Anforderungen an Protokollierung und Erkennung
  • Schutz sensibler Inhalte: Protected Event Logging verhindert, dass protokollierte Kennwörter im Klartext lesbar sind

Practical example

Ein Maschinenbauer mit 500 Mitarbeitenden fällt unter NIS2 und muss Angriffe auf seine Server erkennen können. Die IT aktiviert per Gruppenrichtlinie Script Block Logging für Windows PowerShell und PowerShell Core, registriert auf den Servern den Ereignisanbieter von PowerShell 7 und schaltet Protected Event Logging mit einem Zertifikat der internen CA ein. Die Ereignisse 4104 gehen per Agent an Microsoft Sentinel. Bei einem Testangriff des Pentesters wird der Download-Befehl im Protokoll sichtbar und löst eine Warnung aus.

Things to keep in mind

  • Script Block Logging für Windows PowerShell 5.1 und PowerShell 7 getrennt aktivieren, PowerShell 7 nutzt eigene Richtlinien und ein eigenes Ereignisprotokoll
  • Unter PowerShell 7 den Ereignisanbieter registrieren und vor einem Update mit -Unregister abmelden, sonst entstehen keine Einträge
  • Protected Event Logging einsetzen, sobald Protokolle über die reine Diagnose hinaus aufbewahrt werden, weil Skripte Kennwörter enthalten können
  • Größe der Ereignisprotokolle erhöhen und an ein SIEM weiterleiten, die Standardgröße reicht für 4104-Ereignisse nicht lange
  • Transkriptverzeichnisse auf Netzlaufwerken so berechtigen, dass Benutzer schreiben, aber nicht lesen oder löschen können

Licensing & availability

Alle Protokollierungsfunktionen sind in Windows PowerShell 5.1 und PowerShell 7 ohne Zusatzlizenz enthalten. Für die zentrale Auswertung fallen Kosten beim gewählten SIEM an, etwa Microsoft Sentinel nach Datenvolumen. Stand: Oktober 2026.

Conclusion

Script Block Logging gehört auf jeden Server und Admin-Arbeitsplatz, weil PowerShell ein bevorzugtes Angriffswerkzeug ist. Kombiniere es mit Protected Event Logging und einer zentralen Auswertung im SIEM.

Further reading

Related articles