Deep Scriptblock Logging: PowerShell-Kommandos im Eventlog aufzeichnen

    Scriptblock-Logs in der EreignisanzeigeAls mächtiges Werk­zeug ist Power­Shell nicht nur für Admins, son­dern auch für Hacker interes­sant. Um ver­dächtige Aktivi­täten zu ent­decken, ist es hilf­reich, alle ausge­führten Befehle mitzu­schneiden. Neben dem Auf­zeichnen in einer Text­datei unter­stützt PowerShell seit der Version 5 auch die Proto­kollierung im Eventlog.

    PowerShell v5 brachte gleich mehrere Fortschritte beim Logging. So erweiterte es das ältere Ver­fahren, die so genannte "Over-the-shoulder-Transcription", auf alle PS-Hosts inklusive ISE und beschränkte sich nicht mehr auf die Kommando­zeile. Außerdem lässt sich dieses Feature seitdem auch über Gruppen­richtlinien aktivieren.

    Logging der tatsächlichen Befehle

    Zur Aufzeichnung aller Kommandos in einer Textdatei kam das so genannte Deep Scriptblock Logging hinzu. Es nutzt nicht nur das Windows Eventlog anstelle einer Textdatei, sondern löst vorher alle Befehle in die Form auf, in der sie von PowerShell ausgeführt werden. Auf diese Weise bleiben böswillige Aktivitäten nicht so leicht unbemerkt.

    Das betrifft zum Beispiel den Einsatz von dynamischer Code-Generierung, wo Kommandos in einer Variablen gespeichert und dann mit Hilfe von Invoke-Expression ausgeführt werden. Das Feature deckt auch Versuche auf, Befehlsfolgen zu verschleiern, indem sie mittels Base64 kodiert werden.

    Aktivierung nur über GPO

    Während sich Transcriptions auch explizit über die Cmdlets Start-Transcript und Stop-Transcript ein- und ausschalten lassen, kann man das Scriptblock Logging nur über GPOs oder das direkte Setzen des entsprechenden Registry-Schlüssels (de-)aktivieren. Daher bleibt weiterhin Bedarf für das ältere Verfahren, etwa für das Mitschneiden der Ausgabe in eigenen Scripts.

    Gruppenrichtlinien zur Aktivierung des Deep Scriptblock Logging

    Die zuständige GPO-Einstellung heißt Protokollierung von PowerShell-Skriptblöcken aktivieren und findet sich unter Richtlinien => Administrative Vorlagen => Windows-Komponenten => Windows PowerShell. Konfiguriert man sie unter Computer- und Benutzer­konfiguration, dann setzt sich Erstere durch.

    Hakt man die Option für Start-/Stoppereignisse an, dann muss man mit erheblich höherem Daten­aufkommen rechnen, weil dann Marker für den Beginn und das Ende von allen Ereignissen mitgeschrieben werden.

    Eventlog vorbereiten

    Während man die Mitschnitte in Textdateien durch Anlegen eines Verzeichnisses auf einem Fileshare und die Vergabe der erforderlichen Zugriffs­rechte vorbereitet, stehen beim neueren Logging andere Vorarbeiten an.

    So sollte man die maximale Größe des Eventlogs von den voreingestellten 20 MB auf einen deutlich höheren Wert ändern. Zum einen fallen je nach Konfiguration des Logging-Features relativ viele Daten an, zum anderen sollen Angreifer nicht in der Lage sein, ihre Spuren einfach zu verwischen, indem sie das Log relativ schnell mit unverdächtigen Einträgen füllen.

    Die Protokollierung erfolgt unter PowerShell/Operational

    Da man die Auswertung der Logs entweder dafür entwickelten Scripts oder SIEM-Tools überlassen wird, benötigt man die aufgezeichneten Ereignisse an zentraler Stelle. Zu diesem Zweck bietet es sich an, die von PowerShell geschriebenen Einträge an einen Rechner im Netz weiterzuleiten. PowerShell 7 soll dafür ein eigenes Log-Forwarding bekommen.

    Ereignis-IDs

    Das Logging erfolgt im Anwendungs­protokoll unter Microsoft => Windows => PowerShell => Operational, die Kommandos werden unter der Ereignis-ID 4104 aufgezeichnet. Wenn man zusätzlich Start- und Stopp­ereignisse mitschneidet, dann scheinen diese unter den IDs 4105 und 4106 auf.

    Benutzerdefinierter Filter in der Ereignisanzeige für aufgezeichnete Skriptblöcke

    Möchte man in der Ereignisanzeige einen benutzerdefinierten Filter für die mitgeschnittenen Befehle einrichten, dann aktiviert man als Quelle

    • PowerShell (Microsoft-Windows-PowerShell),
    • PowerShell (PowerShell)
    • PowerShellCore

    Zusätzlich wählt man als Ereignistyp Warnung aus gibt als ID 4104 ein.

    Befehlssequenzen zusammenfügen

    Während Transcripts ihre Daten praktisch unbegrenzt in eine Textdatei schreiben können, limitiert im Eventlog das Feld für Scriptblocks die Länge der Aufzeichnung. Daher werden längere Scripts gestückelt und über mehrere Einträge verteilt.

    Auf Microsoft Docs gibt es eine Vorlage für ein PowerShell-Script, mit dessen Hilfe man die Log-Fragmente wieder zusammenfügen kann. Möchte man etwa alle Mitschnitte für einen Prozess mit der ID 6524 aneinanderreihen, dann könnte man so vorgehen:

    Scriptblock-Logging für PowerShell Core

    Wie schon bei den Transcripts aktiviert die Gruppen­richtlinie das Logging von Skriptblöcken nur für Windows PowerShell. Auf PowerShell Core 6.x und den Nachfolger PowerShell 7 hat sie keine Auswirkung.

    Will man die Befehle für diese Versionen im Eventlog mitschneiden, dann muss man den Registry-Schlüssel selbst setzen. Dazu erstellt man unter

    HKLM\SOFTWARE\Policies\Microsoft\PowerShellCore

    den Schlüssel ScriptBlockLogging und weist an EnableScriptBlockLogging den Wert 1 zu. Die folgenden Anweisungen in einer .reg-Datei erledigen diese Aufgabe:

    Für die Aktivierung der Skriptblock-Aufzeichnung auf einer größeren Zahl an Rechnern empfiehlt sich der Einsatz der Group Policy Preferences, um die Registry anzupassen.

    Log-Einträge für PowerShell Core in der Ereignisanzeige

    Schließlich sei noch darauf verweisen, dass sich die Log-Einträge für PowerShell Core direkt unter den Anwendungs- und Dienstprotokollen befindet. Die Ereignis-IDs für die Aufzeichnung sind gleich wie bei Windows PowerShell.

    Keine Kommentare