Bösartige PowerShell mit Skriptblockprotokollierung erkennen

Der Leitfaden zur PowerShell-Sicherheit schaltet die Protokollierung ein. In diesem Leitfaden geht es darum, was Sie damit anfangen: wo die Beweise landen, wie man lange Skripte aus Fragmenten zusammensetzt, welche Muster einen Angreifer von einem Administrator unterscheiden und wie man Erkennungen so abstimmt, dass Ihre Analysten sie auch nächsten Monat noch lesen.

Die verfügbare Telemetrie

PowerShell 7 schreibt in sein eigenes Protokoll PowerShellCore/Operational, sobald sein Ereignismanifest registriert ist, und verwendet eigene Richtlinieneinstellungen. Ist PowerShell 7 installiert, sammeln Sie beide Protokolle ein, sonst haben Sie einen blinden Fleck mit anderem Programmnamen (pwsh.exe).

All das ist nur außerhalb des Hosts nützlich. Leiten Sie es mit Windows Event Forwarding oder Ihrem Agent weiter und vergrößern Sie das Operational-Protokoll, damit es auf einem ausgelasteten Server nicht vor der Erfassung überschrieben wird.

Schritt 1: aufgeteilte Skriptblöcke zusammensetzen

Große Skripte werden auf mehrere 4104-Ereignisse verteilt. Jedes Fragment trägt dieselbe ScriptBlock ID und einen Zähler „Teil n von m“. Analysten, die einzelne Ereignisse lesen, sehen zerstückelten Code, und Erkennungsregeln verpassen Muster, die über eine Grenze reichen. Setzen Sie sie zuerst wieder zusammen:

$events = Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-PowerShell/Operational'; Id = 4104
} -MaxEvents 5000

$events | Group-Object { $_.Properties[3].Value } | ForEach-Object {
  $parts = $_.Group | Sort-Object { [int]$_.Properties[0].Value }
  [pscustomobject]@{
    ScriptBlockId = $_.Name
    Time          = ($parts | Select-Object -First 1).TimeCreated
    Path          = $parts[0].Properties[4].Value
    Text          = ($parts | ForEach-Object { $_.Properties[2].Value }) -join ''
  }
}

Machen Sie im SIEM dasselbe mit einer Gruppierung nach Skriptblock-ID vor dem Abgleich. Ein leerer Path bedeutet, dass der Code von einer interaktiven Eingabeaufforderung, aus -Command, -EncodedCommand oder dem Speicher stammt statt aus einer Datei auf dem Datenträger. Schon das ist ein nützlicher Ansatzpunkt.

Schritt 2: mit dem beginnen, was PowerShell bereits markiert

Auch ohne Richtlinie protokolliert PowerShell 5.1 Skriptblöcke mit bekannten verdächtigen Begriffen als 4104-Ereignisse der Stufe Warnung. Bei aktivierter Skriptblockprotokollierung sind diese zwischen den ausführlichen Ereignissen weiterhin als Warnungen markiert. Sie ergeben einen rauscharmen ersten Alarm:

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-PowerShell/Operational'; Id = 4104; Level = 3
} -MaxEvents 200 | Select-Object TimeCreated, MachineName, @{n='Snippet';e={ $_.Properties[2].Value.Substring(0, [Math]::Min(200, $_.Properties[2].Value.Length)) }}

Prüfen Sie einige Wochen lang jedes Ereignis der Stufe Warnung. Sie lernen dabei, welche Admin-Skripte sie auslösen, und können diese per Pfad ausnehmen.

Schritt 3: nach den Mustern suchen, die Angreifer brauchen

Angriffswerkzeuge müssen eine kleine Zahl von Dingen tun, und jedes hinterlässt Wörter im Skripttext. Gruppieren Sie Indikatoren nach dem, was der Angreifer erreichen will:

Zwei Dinge machen diese Regeln praxistauglich:

1. Indikatoren kombinieren. -NoProfile allein ist überall. -NoProfile plus verstecktes Fenster plus Download-Cradle ist es nicht.
2. Zuerst normalisieren. Wandeln Sie den Text vor dem Abgleich in Kleinbuchstaben um, entfernen Sie Backticks und gleichen Sie Befehlszeilenschalter per Präfix ab. powershell.exe akzeptiert / ebenso wie - sowie abgekürzte Parameternamen.

Das offene Regel-Repository Sigma enthält gut gepflegte PowerShell-Regeln, die Sie in Ihr SIEM übertragen können, statt jede selbst zu schreiben.

Schritt 4: die Engine beobachten, nicht nur die Skripte

Einige der besten Signale stecken im klassischen Protokoll Windows PowerShell und in der Prozesstelemetrie statt im Skripttext:

• Downgrade-Versuche. Ereignis 400 mit EngineVersion=2.0 bedeutet, dass jemand die PowerShell-2.0-Engine gestartet hat, die weder Skriptblockprotokollierung noch AMSI kennt. Alarmieren Sie bei jedem Auftreten und entfernen Sie die Engine wie im Härtungsleitfaden beschrieben.
• Ungewöhnliche Hosts. Die Ereignisse 400 und 600 enthalten HostApplication. PowerShell, das in etwas anderem als powershell.exe, pwsh.exe oder der ISE läuft, ist verdächtig.
• Unmanaged PowerShell. Werkzeuge können die PowerShell-Engine in jeden .NET-Prozess laden. Sysmon-Ereignis 7 für System.Management.Automation.dll (oder das native Abbild), geladen von einem unerwarteten Prozess, erkennt das. Nehmen Sie in Ihrer Sysmon-Konfiguration genau diese DLL auf, statt jeden Image-Ladevorgang zu protokollieren.
• Verdächtige Elternprozesse. 4688 oder Sysmon 1, bei denen powershell.exe ein Kindprozess von winword.exe, excel.exe, outlook.exe, mshta.exe, wmiprvse.exe, w3wp.exe oder sqlservr.exe ist. Von Office gestartete PowerShell wird außerdem von den ASR-Regeln direkt blockiert.

Schritt 5: AMSI-Erkennungen als hochpräzise Alarme nutzen

Das Antimalware Scan Interface übergibt Skriptinhalte zur Laufzeit an Defender, nach der Entschleierung. Blockiert Defender ein Skript, sieht der Benutzer die Meldung „This script contains malicious content and has been blocked by your antivirus software“, und Defender protokolliert 1116 (erkannt) und 1117 (Aktion ausgeführt). Die Ressource der Erkennung verweist auf AMSI und den Hostprozess statt auf eine Datei auf dem Datenträger.

Behandeln Sie jede AMSI-Erkennung auf einem Server als Vorfall, nicht als lästige Virenschutzmeldung. Aktivieren Sie die ASR-Regel Block execution of potentially obfuscated scripts zunächst im Überwachungsmodus, um zu sehen, was sie erfassen würde.

Schritt 6: Versuche erkennen, das Licht auszuschalten

Angreifer, die von der Protokollierung wissen, versuchen sie abzuschalten:

• Registrierungsänderungen unter HKLM\SOFTWARE\Policies\Microsoft\Windows\PowerShell (Sysmon 13 oder eine SACL mit 4657).
• Löschen von Protokollen: 1102 (Sicherheit) und 104 (System, für jedes andere Protokoll). Die übrigen Manipulationssignale finden Sie in der Referenz der Sicherheitsereignis-IDs.
• Ein Host, dessen 4104-Volumen auf null fällt, während er weiterhin andere Ereignisse meldet. Bauen Sie eine Prüfung auf „stumme Hosts“ pro Protokoll, nicht nur pro Rechner.
• Defender-Änderungen: 5001 (Echtzeitschutz deaktiviert) und 5007 (Konfiguration geändert, einschließlich neuer Ausschlüsse).

Schritt 7: einen Treffer triagieren

Wenn eine Regel auslöst, beantworten Sie vier Fragen, bevor Sie ihn als harmlos einstufen:

1. Wer und wo? Konto, Host und Anmeldesitzung. Gehen Sie von der Sitzung aus zum 4624-Ereignis: Ein interaktiver Admin an einer Konsole ist etwas anderes als eine Netzwerkanmeldung von einem Arbeitsplatz.
2. Was hat es gestartet? Verfolgen Sie die Elternkette in 4688 oder Sysmon 1. Eine geplante Aufgabe, ein Dienst, ein Office-Dokument und eine WinRM-Remotesitzung (wsmprovhost.exe) weisen jeweils auf unterschiedliche Einstiegspunkte hin.
3. Was geschah danach? Sehen Sie sich das zusammengesetzte Skript an, dann Netzwerkverbindungen (Sysmon 3 und 22), Dateischreibvorgänge (Sysmon 11) und Kindprozesse in den folgenden Minuten.
4. Ist es bekannt? Suchen Sie den Hash des Skriptblocks oder markante Strings in der gesamten Flotte. Dasselbe Skript auf Hunderten Rechnern ist meist ein Agent; dasselbe Skript nachts auf drei Servern ist meist ein Einbruch.

Halten Sie die Antwort in den Tuning-Notizen der Regel fest, damit der nächste Analyst nicht bei null anfängt.

Was kaputtgeht

Detection Engineering für PowerShell strapaziert vor allem die Geduld Ihrer Analysten:

• Management-Agents sehen aus wie Malware. Configuration Manager, die Intune Management Extension, Überwachungsagents und EDR-Reaktionswerkzeuge führen PowerShell routinemäßig mit -ExecutionPolicy Bypass, -NoProfile und codierten Befehlen aus. Nehmen Sie sie anhand von vollständigem Elternpfad und Signierer aus, niemals nur anhand des Prozessnamens.
• Volumen. Vollständige Skriptblockprotokollierung auf einem ausgelasteten Managementserver erzeugt viele 4104-Ereignisse, ebenso jeder DSC- oder Überwachungslauf. Dimensionieren Sie das Protokoll entsprechend und filtern Sie im SIEM, nicht durch Abschalten der Protokollierung.
• Geheimnisse in Protokollen. Der Skripttext enthält alles, was Admins eintippen, auch Kennwörter. Beschränken Sie den Lesezugriff auf die PowerShell-Protokolle in Ihrem SIEM oder verwenden Sie Protected Event Logging.

Überprüfen

Testen Sie jede Schicht auf einem Laborrechner, bevor Sie ihr in der Produktion vertrauen:

# 1. Skriptblockprotokollierung: eine harmlose, leicht auffindbare Markierung
powershell.exe -NoProfile -Command "Write-Output 'sbl-canary-2026'"

# 2. AMSI: Microsofts dokumentierter Teststring, wird erkannt, ist aber harmlos
'AMSI Test Sample: 7e72c3ce-861b-4339-8740-0ac1484c1386'

# 3. Erkennung des Engine-Downgrades, sofern die v2-Engine im Labor noch vorhanden ist
powershell.exe -Version 2 -Command "exit"

Bestätigen Sie dann, dass jedes Ereignis das SIEM erreicht und die erwartete Regel ausgelöst hat: 4104 mit dem Canary-String, 1116 von Defender, 400 mit EngineVersion=2.0. Fehlt eines davon, reparieren Sie die Pipeline, bevor Sie weitere Regeln schreiben. Der Constrained Language Mode schränkt ein, was Angreifer tun können; die Erkennung verrät Ihnen, dass sie es versucht haben. Mehr zu beidem auf der Themenseite PowerShell-Sicherheit.

Checkliste

• 4103, 4104, 400/403/600 und PowerShellCore/Operational nahezu in Echtzeit weitergeleitet
• Skriptblöcke vor dem Regelabgleich per ScriptBlock ID zusammengesetzt
• Alarm bei 4104-Ereignissen der Stufe Warnung, per Skriptpfad abgestimmt
• Regeln mit kombinierten Indikatoren für Download, Verschleierung, Ausführung im Speicher und Umgehung der Abwehr
• Alarm bei Ereignis 400 mit EngineVersion 2.0
• Sysmon-Regel für System.Management.Automation.dll, geladen von unerwarteten Prozessen
• Alarme bei Office, Webservern und WMI als Elternprozessen von PowerShell
• AMSI-Erkennungen (1116/1117) auf Servern als Vorfälle behandelt
• Erkennungen für stumme Hosts und Protokollmanipulation eingerichtet
• Management-Agents nur anhand von vollständigem Pfad und Signierer ausgenommen