Event-ID 4104: PowerShell-Skriptblock protokolliert

Event 4104 („Creating Scriptblock text“) landet im Log Microsoft-Windows-PowerShell/Operational und enthält den PowerShell-Code, der tatsächlich ausgeführt wird. Das Besondere: Der Code wird nach der Entschlüsselung protokolliert. Egal ob ein Angreifer Base64, String-Verkettung oder mehrere Verschleierungsebenen nutzt, 4104 zeigt dir am Ende den Klartext. Auch Skripte, die nie als Datei auf der Platte lagen, sondern direkt aus dem Internet in den Speicher geladen wurden, tauchen hier auf.

Die wichtigsten Felder

• ScriptBlockText: der ausgeführte Code. Das zentrale Feld für jede Regel.
• ScriptBlockId: eindeutige ID. Große Skripte werden in mehrere Events aufgeteilt, die dieselbe ID tragen.
• MessageNumber und MessageTotal: Teil X von Y bei aufgeteilten Skripten.
• Path: der Pfad der Skriptdatei, leer bei interaktiven Befehlen oder In-Memory-Code.
• Level: Warning (3) bei Blöcken, die PowerShell selbst als verdächtig einstuft, sonst Verbose (5).

Worauf du bei der Detection achtest

• AMSI-Bypass: Begriffe wie AmsiUtils, amsiInitFailed oder Manipulationen an amsi.dll. Wer AMSI abschaltet, will unerkannt Schadcode ausführen.
• Download-Cradles: DownloadString, Invoke-WebRequest oder Net.WebClient in Kombination mit IEX bzw. Invoke-Expression.
• In-Memory-Ausführung: [Reflection.Assembly]::Load, VirtualAlloc oder CreateThread über P/Invoke.
• Bekannte Offensiv-Frameworks: Funktionsnamen aus PowerSploit, PowerView, Nishang oder Empire, z. B. Invoke-Mimikatz, Get-DomainUser oder Invoke-Kerberoast.
• Warnungen von PowerShell selbst: Events mit Level Warning sind ein guter Startpunkt für jede Regel.

Typische False Positives

Admin-Skripte, Konfigurationsmanagement (z. B. DSC, SCCM, Intune) und Security-Tools selbst erzeugen große Mengen an 4104-Events, teils mit Base64 oder Reflection. Filtere bekannte Skriptpfade und signierte Module. Das Volumen kann hoch werden, plane dafür eine größere Log-Größe für den Operational-Kanal ein.

Voraussetzung

Aktiviere die Gruppenrichtlinie PowerShell-Skriptblockprotokollierung aktivieren unter Administrative Vorlagen → Windows-Komponenten → Windows PowerShell. Ohne diese Einstellung protokolliert PowerShell 5 nur Blöcke, die es selbst als verdächtig einstuft. Angreifer umgehen die Protokollierung gern mit PowerShell 2.0, das kein Script Block Logging kennt. Deinstalliere die Windows-Funktion „Windows PowerShell 2.0“, wo sie noch vorhanden ist.

Sigma-Regel (Beispiel)

title: Verdaechtiger PowerShell-Skriptblock
status: experimental
description: Erkennt typische Muster von AMSI-Bypass, Download-Cradles und In-Memory-Ausfuehrung im protokollierten Skriptblock.
references:
  - https://attack.mitre.org/techniques/T1059/001/
author: blue-team.net
tags:
  - attack.execution
  - attack.t1059.001
logsource:
  product: windows
  category: ps_script
  definition: Script Block Logging muss aktiviert sein
detection:
  selection:
    ScriptBlockText|contains:
      - 'AmsiUtils'
      - 'amsiInitFailed'
      - 'System.Reflection.Assembly]::Load'
      - 'Invoke-Mimikatz'
      - 'Net.WebClient).DownloadString'
      - 'FromBase64String'
      - 'VirtualAlloc'
  condition: selection
falsepositives:
  - Legitime Admin-Skripte mit Base64-Dekodierung oder Reflection
level: medium

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

Verwandte Event-IDs

• 4103 PowerShell-Modulprotokollierung
• 400 PowerShell-Engine gestartet
• 1116 Microsoft Defender hat Malware erkannt
• 4688 Neuer Prozess erstellt
• 1 Prozess erstellt