PowerShell als Hacking-Tool: Missbrauch von Scripts verhindern

Bei Windows Server ist Microsoft schon lange dazu über­gegangen, auf einem frisch installierten Rechner keine Rollen und Features auszuführen, um die Angriffsfläche zu minimieren. Dort müssen Benutzer alle erforderlichen Funktionen erst explizit aktivieren.

Laxe Standardkonfiguration von PowerShell

Bei PowerShell hingegen steht von Anfang an auf jedem Windows-PC der volle Funktions­umfang zur Verfügung, wenn man vom "Schutz" durch eine restriktive Execution Policy absieht. Es empfiehlt sich jedoch nicht, diesen Zustand so zu belassen.

Gefahr droht nämlich nicht nur von böswilligen PowerShell-Experten, welche alle Möglichkeiten von Scripts ausreizen können. Vielmehr reichen bereits grundlegende Kenntnisse, um mit Hilfe verschiedener Hacking-Tools in Systeme einzudringen.

Hacking-Tools für PowerShell

Eine ganze Reihe davon lässt sich einfach als Open Source über Github beziehen. Dazu zählen etwa die umfangreichen Script- und Modul-Sammlungen PowerSploit, PowerShell Empire, Nishang oder PowerUp.

Nun könnte man sich darauf verlassen, dass die meisten Virenscanner diese Hacking-Tools erkennen und blockieren. Tatsächlich interveniert etwa Windows Defender bereits nach dem Download und stellt die Scripts unter Quarantäne.

Allerdings lassen sich Scripts im Unterschied zu binären Dateien recht einfach verändern, um die Erkennung über Signaturen zu behindern. Beispielsweise kann man Invoke-Mimikatz aus dem Browser-Fenster kopieren und in einen Editor wie die PowerShell_ISE einfügen, um mit dem Code zu experimentieren.

Dieser Blog-Beitrag von Carrie Roberts demonstriert, wie man die meisten Virenscanner durch Suchen und Ersetzen einiger markanter Stellen überlisten kann. Aktuell mögen die dort besprochenen Änderungen nicht mehr ausreichen, aber durch Ausprobieren lässt sich wahrscheinlich heraus­finden, woran Virenscanner dieses Script erkennen. Ansonsten helfen verschiedene AMSI-Bypasses.

Generelles Blockieren von PowerShell

Als Vorbeugung gegen solche Bedrohungen werden viele Unternehmen zu einer radikalen Maßnahme greifen und PowerShell ganz deaktivieren. In zentral verwalteten Umgebungen bietet sich dafür ein Blacklisting mit AppLocker oder den Software Restriction Policies an.

Entscheidet man sich für die Software-Einschränkung, dann erstellt man zwei neue Hashregeln und verbindet diese mit powershell.exe sowie powershell_ise.exe, als Sicherheitsstufe wählt man Nicht erlaubt. Blockiert man die Programme auf Benutzerebene, dann kann man Admins davon ausnehmen.

Dieses Vorgehen hat aber gleich zwei Nachteile. Zum einen kann es die System­verwaltung behindern, weil PowerShell mittlerweile zu einem unverzichtbaren Werkzeug für die meisten Admins geworden ist. Beispiels­weise laufen dann keine PowerShell-Logon-Scripts mehr, die im Sicherheits­kontext eines Users ausgeführt werden.

Umgehung durch alternative Shells

Schwerwiegender ist jedoch, dass PowerShell mehr ist als nur powershell.exe bzw. power­shell_ise.exe und sich daher nicht endgültig blockieren lässt, indem man den Zugang zu diesen beiden Dateien verbaut. Vielmehr handelt es sich dabei um eine System­komponente (System.Management.Automation), die man nicht entfernen kann und die sich von verschiedenen "Runspaces" nutzen lässt.

Angreifer könnten PowerShell somit aus beliebigen eigenen Programmen ansprechen. Es überrascht daher nicht, dass es dafür schon Shells gibt, die in den eigenen Code eingebunden werden können oder sich direkt ausführen lassen. Dazu gehören etwa p0wnedShell oder PowerOPS.

Darüber hinaus stehen zahlreiche Versionen von PowerShell 6 und 7 als Download im ZIP-Format zur Verfügung, die sich einfach in ein Verzeichnis entpacken und ausführen lassen. Ständig neue Previews würden Admins auf Trab halten, weil sie dafür stets neue Regeln anlegen müssen.

Und nicht zuletzt besteht eine weitere Umgehungs­möglichkeit darin, PowerShell-Scripts zu ausführbaren Dateien zu kompilieren. Auch sie sind nicht auf powershell.exe angewiesen.

PowerShell mit integrierten Mechanismen entschärfen

Anstatt PowerShell komplett zu verbannen, ohne dabei eine wirkliche Sicherheit zu erzielen, bietet sich an, deren Security-Features zu nutzen. Diese wurden mit der Version 5 weiter ausgebaut, so dass man PCs auf die neueste Variante aktualisieren sollte.

Unbedingt geboten ist zudem, PowerShell 2.0 zu entfernen, das weiterhin als optionales Feature vorinstalliert ist und ab Windows 8.1 und Server 2012 deinstalliert werden kann. Mit dieser alten Ausführung lassen sich alle wesentlichen Restriktionen für PowerShell unterlaufen.

Zu den wichtigsten Sicherheits­funktionen von Windows PowerShell gehört der Constrained Language Mode, der mehrere gefährliche Features deaktiviert. Besonders wirksam ist dieser Sprachmodus im Zusammenspiel mit Application Whitelisting. Das gilt auch für die Beschränkung auf signierte Scripts, die aus vertrauens­würdiger Quelle stammen.

Bei der Ausführung von PowerShell auf Remote-Rechnern können Session Configurations und Just Enough Administration den Spielraum für Benutzer effektiv einschränken.

Neben Mitteln, die den Missbrauch von PowerShell unterbinden, stehen auch solche zur Verfügung, um verdächtigen und unerwünschten Aktivitäten auf die Spur zu kommen. Dazu zählt das Mitschreiben aller ausgeführten Kommandos in Log-Dateien (Transcription) sowie das neuere Deep Scriptblock Logging.

Letzteres zeichnet alle PowerShell-Aktionen im Eventlog auf. Diese Einträge lassen sich mit Hilfe von Protected Event Logging verschlüsseln und so vor neugierigen Blicken schützen. Insgesamt verfügt PowerShell somit über eine Reihe von Mechanismen, die eine böswillige Nutzung deutlich erschweren.

Lee Holmes hat auf Microsofts PowerShell-Teamblog eine Tabelle zusammen­gestellt, welche die Sicherheits­funktionen verschiedener Programmier­sprachen und Shells vergleicht.

Dabei zeigt sich, dass PowerShell mehr Möglichkeiten bietet als die anderen, um eine unerwünschte Nutzung zu unterbinden. Eine letzte Sicherheit erreicht man damit natürlich auch nicht, weil findige Köpfe immer wieder Wege finden, um die Abwehr zu umgehen.

*Feature existiert, kann aber nicht über Richtlinien erzwungen werden
**experimentell

Um in den Genuss dieser Schutz­mechanismen zu kommen, müssen Admins allerdings mehr Aufwand investieren als für das bloße Blockieren von powershell.exe. Dafür steht PowerShell weiterhin als Werkzeug der System­verwaltung in vollem Umfang zur Verfügung und lässt sich sogar fein abgestuft so weit einschränken, dass Aufgaben an Standard­benutzer delegiert werden können.

Das neue Fachbuch PowerShell Security von WindowsPro geht auf alle oben genannten Sicherheits­funktionen von PowerShell ein. Es ist als Taschenbuch (147 Seiten, € 14,90) und als E-Book für Kindle (€ 9,95) verfügbar.