PowerShell für Verteidiger: vom Angriffswerkzeug zur Erkennungsquelle

PowerShell für Verteidiger hat zwei Seiten, und beide sind wichtig. Der Beitrag zum PowerShell-Angriff zeigt, warum Angreifer PowerShell so gern nutzen: Es ist auf jedem Windows vorhanden, mächtig, und läuft im Speicher, ohne eine Datei zu hinterlassen. Dieser Beitrag dreht die Perspektive um: Wie macht man PowerShell von einer Angriffsfläche zu einer Erkennungsquelle, und wie nutzt das Blue Team PowerShell selbst als Werkzeug? Die gute Nachricht ist, dass PowerShell besser protokollierbar ist als fast jedes andere Werkzeug, wenn man die richtige Protokollierung aktiviert. Dieser Beitrag behandelt die drei Protokollierungsarten, die zwei wichtigsten Härtungen und die defensive Nutzung von PowerShell durch das Blue Team.

Die drei Protokollierungsarten

PowerShell bringt eine Protokollierung mit, die tiefer reicht als bei fast jedem anderen Werkzeug, aber sie ist standardmäßig größtenteils aus und muss per Gruppenrichtlinie aktiviert werden. Drei Arten gehören eingeschaltet.

• Script Block Logging (Event 4104). Die wichtigste und wertvollste Protokollierung: Sie zeichnet den tatsächlich ausgeführten Code auf, und zwar nach dem Entschlüsseln und Entschleiern. Ein Angreifer, der seinen Code base64-kodiert oder verschleiert, um der Erkennung zu entgehen, wird hier trotzdem im Klartext sichtbar, weil PowerShell den Code protokolliert, wie er wirklich ausgeführt wird. Das macht 4104 zum stärksten Signal gegen die Verschleierung aus dem Angriffsbeitrag.
• Module Logging (Event 4103). Protokolliert die aufgerufenen Befehle und ihre Argumente auf einer höheren Ebene. Es ergänzt das Script Block Logging um den Kontext, welche Befehle in welcher Reihenfolge liefen, ist aber gesprächiger und wird oft gezielter eingesetzt.
• Transcription. Schreibt ganze PowerShell-Sitzungen mit, Eingaben und Ausgaben, in eine Textdatei. Das ist besonders für die Forensik wertvoll, weil es nachvollziehbar macht, was in einer Sitzung tatsächlich geschah, inklusive der Ausgaben, die das Script Block Logging nicht erfasst.

Diese Ereignisse gehören wie alle anderen zentral gesammelt, per Windows Event Forwarding und ins SIEM, damit sie im Vorfall verfügbar sind und nicht lokal auf dem kompromittierten System liegen. Das Script Block Logging (4104) gehört dabei in jedes WEF-Abonnement, weil es eines der aussagekräftigsten Windows-Ereignisse überhaupt ist.

Die zwei wichtigsten Härtungen

• Constrained Language Mode. PowerShell kann in einem eingeschränkten Sprachmodus laufen, der die gefährlichen Funktionen sperrt, mit denen Angreifer aus PowerShell heraus beliebigen Code ausführen oder Systemschnittstellen direkt ansprechen. Im Zusammenspiel mit einer Anwendungssteuerung (etwa AppLocker oder WDAC) wird der Modus automatisch erzwungen, sobald ein nicht vertrauenswürdiges Skript läuft. Das nimmt vielen PowerShell-Angriffen ihre Mächtigkeit, ohne die legitime Nutzung zu behindern.
• AMSI (Antimalware Scan Interface). Eine Schnittstelle, über die PowerShell den Code, den es ausführen soll, zur Laufzeit an die Sicherheitssoftware zur Prüfung übergibt, und zwar nach dem Entschleiern. AMSI macht verschleierte bösartige Skripte sichtbar, die einer reinen Dateiprüfung entgehen würden. Angreifer versuchen gezielt, AMSI zu umgehen, und genau dieser Umgehungsversuch ist selbst ein starkes Erkennungssignal.

Ein wichtiger Zusatz: Alte PowerShell-Versionen (insbesondere Version 2) haben diese Schutzfunktionen nicht und werden von Angreifern gezielt aufgerufen, um sie zu umgehen. Die Version 2 gehört deshalb deaktiviert, und der Aufruf einer alten Version ist ein Alarm wert. Sichtbar wird er in Event 400 an der Engine-Version.

Was man in den Logs sucht

Mit aktivierter Protokollierung wird PowerShell zur ergiebigen Erkennungsquelle. Die typischen verdächtigen Muster im Script Block Logging:

• Kodierte Befehle. Der Parameter zur Ausführung base64-kodierter Befehle ist bei legitimer Nutzung selten und bei Angriffen häufig.
• Download und Ausführung aus dem Speicher. Befehle, die Code aus dem Internet laden und direkt im Speicher ausführen, ohne ihn als Datei abzulegen, sind ein klassisches Angriffsmuster.
• Verschleierung. Ungewöhnliche Zeichenketten, exzessive Ersetzungen und Verkettungen, die den wahren Code verstecken sollen, sind im entschleierten 4104-Log sichtbar.
• Verdächtige übergeordnete Prozesse. PowerShell, das aus einer Office-Anwendung oder einem Mail-Programm startet, ist der Moment nach dem Klick, wie im Threat-Hunting-Beitrag beschrieben.
• AMSI-Umgehungsversuche. Bekannte Muster, mit denen Angreifer AMSI abschalten, sind ein starkes Signal, weil sie fast nie einen legitimen Grund haben.

Diese Muster lassen sich in Sigma-Regeln gießen, die gegen das Script Block Logging laufen, und mit Atomic Red Team testen.

PowerShell als Werkzeug des Verteidigers

Die andere Seite: PowerShell ist nicht nur ein Angriffswerkzeug, sondern auch eines der besten Werkzeuge des Verteidigers. Dieselbe Mächtigkeit, die es für Angreifer attraktiv macht, macht es für das Blue Team wertvoll. Typische defensive Einsatzzwecke: das Abfragen vieler Systeme auf einmal (welche Rechner haben eine bestimmte Datei, einen bestimmten Registry-Wert, eine bestimmte Verbindung?), das Sammeln forensischer Daten im Vorfall (laufende Prozesse, Netzwerkverbindungen, Autostart-Einträge über viele Systeme hinweg), das Automatisieren wiederkehrender Prüfungen und das gezielte Eingreifen bei einer Reaktion. Das verbindet PowerShell direkt mit dem SOAR-Gedanken: Viele Reaktionsschritte lassen sich mit PowerShell skripten. Wichtig dabei ist, dass das defensive Skripten dieselbe Disziplin verdient wie das Detection Engineering: die Skripte versionieren, testen und dokumentieren, damit sie nachvollziehbar und wiederholbar bleiben. Und weil ein Angreifer, der ein Admin-Konto übernimmt, dieselben PowerShell-Werkzeuge nutzen kann, gilt auch hier die Trennung der privilegierten Konten aus der Active-Directory-Härtung.

Fazit

PowerShell ist das beste Beispiel dafür, dass ein Angriffswerkzeug mit der richtigen Konfiguration zur Erkennungsquelle wird. Wer das Script Block Logging (4104), das Module Logging und die Transcription aktiviert, zentral sammelt und mit dem Constrained Language Mode und AMSI härtet, verwandelt PowerShell von einer Angriffsfläche in eines der aussagekräftigsten Signale überhaupt, weil selbst verschleierter Code im Klartext sichtbar wird. Und PowerShell bleibt zugleich ein mächtiges Werkzeug des Verteidigers für Abfrage, Forensik und Automatisierung. Für ein Blue Team lohnt sich die Mühe der Protokollierung deshalb doppelt: Sie schließt eine der wichtigsten Angriffsflächen und eröffnet zugleich eine der besten Erkennungsquellen, und sie macht aus dem Lieblingswerkzeug der Angreifer ein Werkzeug, das gegen sie arbeitet.