Folgen PowerShell-Skriptblockprotokolle befinden sich in Anwendungs- und Dienstprotokolle → Microsoft → Windows → PowerShell → Betriebsbereit, als Ereignis 4104. Sie sind nur vollständig, wenn die Skriptblockprotokollierung aktiviert ist. Um sie zu exportieren:
wevtutil epl „Microsoft-Windows-PowerShell/Operational“ C:logspowershell.evtx
PowerShell 7 ist ein separates Produkt mit einem separaten Kanal, PowerShellCore/Operational, und einer eigenen Richtlinieneinstellung.
Wenn ein Angreifer einen Windows-Rechner berührt hat, ist die Wahrscheinlichkeit groß, dass PowerShell beteiligt war. Die Skriptblockprotokollierung zeichnet den tatsächlich ausgeführten Code auf, oft nachdem die Verschleierungsschichten entfernt wurden. Prime Core verfügt über 663 Erkennungsregeln für PowerShell-Protokolle, zugeordnet zu 417 MITRE ATT&CK-Techniken. Sie decken bösartige PowerShell-Nutzung (T1059.001), Verschleierung (T1027) und Download-Cradles ab, die Werkzeuge herunterladen (T1105).
Bevor Sie beginnen
Ist die Skriptblockprotokollierung aktiviert?
reg query „HKLMSOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging“
EnableScriptBlockLogging auf 0x1 gesetzt bedeutet ja. Wenn der Schlüssel nicht existiert, ist es deaktiviert. Selbst dann protokolliert Windows PowerShell 5.1 weiterhin Skriptblöcke, die es als verdächtig betrachtet, als 4104-Ereignisse auf Warnstufe. Daher können Sie einige Ereignisse finden. Verwechseln Sie diese nur nicht mit dem vollständigen Bild.
Das Einschalten hilft ab jetzt, nicht für das, was bereits passiert ist. Verwenden Sie die Gruppenrichtlinieneinstellung Administrative Vorlagen → Windows-Komponenten → Windows PowerShell → PowerShell-Skriptblockprotokollierung aktivieren, oder setzen Sie den Registrierungseintrag direkt:
reg add „HKLMSOFTWAREPoliciesMicrosoftWindowsPowerShellScriptBlockLogging“ /v EnableScriptBlockLogging /t REG_DWORD /d 1 /f
PowerShell 7 liest seinen eigenen Richtlinienschlüssel unter HKLMSOFTWAREPoliciesMicrosoftPowerShellCore. Wenn es aus einem Zip anstelle des MSI installiert wurde, ist sein Ereigniskanal möglicherweise nicht registriert, bis Sie RegisterManifest.ps1 aus $PSHOME ausführen.
Erwarten Sie Volumen. Jedes Skript und Modul, das ausgeführt wird, wird im Protokoll aufgezeichnet. Erhöhen Sie die maximale Größe des Kanals, sonst bleiben nur wenige Stunden erhalten.
Erwarten Sie Geheimnisse. Administratorskripte enthalten manchmal Passwörter und API-Schlüssel im Klartext, und die Skriptblockprotokollierung zeichnet sie getreu auf. Bedenken Sie dies, bevor diese Datei irgendwohin gelangt, und lesen Sie den LogTotal-Abschnitt unten.
Exportieren Sie die Protokolle
In der Ereignisanzeige, Rechtsklick Betriebsbereit unter PowerShell und wählen Sie Alle Ereignisse speichern als… Von der Befehlszeile:
:: nur Skriptblöcke
wevtutil epl „Microsoft-Windows-PowerShell/Operational“ C:logsps_4104.evtx /q:“*[System[(EventID=4104)]]“
:: PowerShell 7
wevtutil epl „PowerShellCore/Operational“ C:logspwsh.evtx
:: das klassische „Windows PowerShell“-Protokoll: Engine-Startereignisse mit der Hostbefehlszeile
wevtutil epl „Windows PowerShell“ C:logswindows_powershell.evtx
Dieses letzte wird leicht vergessen, aber es lohnt sich, es zu erfassen. Ereignis 400 zeichnet jeden Motorstart auf, einschließlich der Motorausgabe. Eine EngineVersion von 2.0 auf einem modernen System bedeutet normalerweise, dass jemand absichtlich herabgestuft hat, um die Skriptblockprotokollierung zu umgehen.
Hochladen und in LogTotal überprüfen
LogTotal liest EVTX nativ. Eine Sache, die man zuerst wissen sollte: LogTotal bereinigt EVTX-Dateien noch nicht. [PROOF: confirm which formats the sanitize step covers today.] With PowerShell logs, that matters more than usual, because of the secrets mentioned above. Use EVTX uploads freely for test machines. For production hosts, get a yes from whoever owns data handling first.
- Hochladen. Öffnen logtotal.com und die Datei hereinziehen. [BEWEIS: Upload-Bildschirm, Größenlimit]
- Überprüfen. [PROOF: what the results screen shows for PowerShell data]
Wie dies bei echten Daten aussieht. Wir verwendeten [BEWEIS: Probequelle, z. B. eine Test-VM mit aktivierter Skriptblockprotokollierung, nach dem Ausführen eines codierten Download-Cradles und einer harmlosen AMSI-Manipulationstestzeichenfolge]. LogTotal markierte [BEWEIS: tatsächliche Ergebnisse]. [BEWEIS: Link zur Beispieldatei]
Wenn es schief geht
| Symptom | Wahrscheinliche Ursache | Fix |
|---|---|---|
| Überhaupt keine 4104-Ereignisse | Skriptblockprotokollierung ist aus und nichts sah verdächtig aus | Aktivieren Sie es für die Zukunft; überprüfen Sie das Windows PowerShell-Protokoll, um zu sehen, was noch zu holen ist |
| Nur eine Handvoll 4104-Ereignisse, alle Warnung | Protokollierung ist aus; Sie sehen automatische Protokollierung verdächtiger Blöcke | Gleiches wie oben |
| PowerShellCore/Operational nicht gefunden | PowerShell 7 ist nicht installiert oder sein Manifest ist nicht registriert | Führen Sie RegisterManifest.ps1 aus $PSHOME aus |
| 4104 Text ist unlesbarer Geheimtext | Geschützte Ereignisprotokollierung ist aktiviert | Sie benötigen das Entschlüsselungszertifikat |
| Protokoll deckt nur wenige Stunden ab | Standardgröße, hohes Volumen | Erhöhen Sie die maximale Größe des Kanals |
FAQ
Erfasst die Skriptblockprotokollierung verschleierten Code?
Größtenteils ja. Es zeichnet Skriptblöcke auf, wenn sie kompiliert werden. Wenn verschleierter Code die nächste Stufe erstellt und ausführt, wird diese Stufe als eigener Block protokolliert, oft in lesbarer Form.
Was ist der Unterschied zur Transkription?
Die Transkription schreibt Textdateien der Sitzungseingaben und -ausgaben in einen Ordner. Die Skriptblockprotokollierung zeichnet den Code selbst im Ereignisprotokoll auf. Sie ergänzen sich gegenseitig und beide sind lohnenswert zu haben.
