PowerShell als Hacking-Tool: Missbrauch von Scripts verhindern

    Abgesichertes PowerShellPowerShell ist ein mäch­tiges Tool für die System­verwaltung und als solches auch ein per­fektes Instru­ment für Angreifer. Auf­grund der tiefen Veran­kerung im System sorgt ein generelles Blockieren nur für schein­bare Sicherheit. Den besten Schutz versprechen letztlich die Schutz­mechanismen von PowerShell selbst.

    PowerShell bietet fast unbegrenzten Zugriff auf die Ressourcen eines Windows-Rechners und dient auch dazu, zahlreiche Anwendungen wie etwa Exchange zu automatisieren. Nutzer sind zudem nicht auf die vielen Module und Cmdlets beschränkt, sondern können auch .NET-Klassen, Windows-APIs und COM-Objekte integrieren. Gerade die letzt­genannten Fähigkeiten sind in den Händen von Angreifern besonders gefährlich.

    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.

    Windows Defender verhindert den Download von PowerSploit

    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.

    powershell.exe mit den Richtlinien für die Software-Einschränkung blockieren

    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.

    PowerShell 2.0 ist ab Windows 8 und Server 2012 ein optionales Feature und standardmäßig aktiviert.

    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.

    Auswahl der zulässigen Parameter eines Cmdlets

    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.

    Die Ereignisanzeige präsentiert nur die verschlüsselten Einträge, dekodieren kann es sie nicht.

    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.

     Event LoggingTrans­criptionDynamic Evaluation LoggingEncrypted LoggingApp White­listing
    Bash Nein** Nein* Nein Nein Ja
    CMD / BAT Nein Nein Nein Nein Ja
    JScript Nein Nein Nein Nein Ja
    LUA Nein Nein Nein Nein Nein
    Perl Nein Nein Nein Nein Nein
    PHP Nein Nein Nein Nein Nein
    PowerShell Ja Ja Ja Ja Ja
    Python Nein Nein Nein Nein Nein
    Ruby Nein Nein Nein Nein Nein
    sh Nein** Nein* Nein Nein Nein
    T-SQL Ja Ja Ja Nein Nein
    VBScript Nein Nein Nein Nein Ja
    zsh Nein** Nein* Nein Nein Nein

       

     Antimalware IntegrationLocal SandboxingRemote SandboxingUntrusted Input Tracking
    Bash Nein Nein* Ja Nein
    CMD / BAT Nein Nein Nein Nein
    JScript Ja Nein Nein Nein
    LUA Nein Nein* Ja Ja
    Perl Nein Nein* Ja Ja
    PHP Nein Nein* Ja Ja
    PowerShell Ja Ja Ja Nein**
    Python Nein Nein Nein Nein**
    Ruby Nein Nein** Nein** Ja
    sh Nein Nein* Ja Nein
    T-SQL Nein Nein** Nein** Nein
    VBScript Ja Nein Nein Nein
    zsh Nein Nein* Ja Nein

    *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.

    2 Kommentare

    Ralph sagt:
    9. Januar 2020 - 21:31

    Hallo Herr Sommergut,

    wenn (Zitat von Ihnen:) „ von Angreifer könnten PowerShell somit aus beliebigen eigenen Programmen ...“ möglich ist, dann haben Sie leider Applocker / Safer nicht richtig eingerichtet. Benutzer sollten lediglich die vom Admin installierten Programme ausführen dürfen. Zudem sollte das Ausführen von Programmen aus schreibberechtigten Verzeichnissen verboten sein. Und zu guter Letzt gehört analysiert, welche Verzeichnisse und Programme von Microsoft für Benutzer zur Ausführung gesperrt werden sollten (z.B. aus meiner Sicht (Auszug) : cmd, net, regedit, wscript, cscript, ... und auch powershell). Aber ansonsten finde ich Ihren Beitrag recht interessant.

    Bild von Wolfgang Sommergut
    10. Januar 2020 - 12:01

    Sie haben natürlich recht, dass SAFER oder AppLocker die Ausführung solcher unerwünschten Shells aus dem Benutzerprofil unterbinden können. Allerdings ist nach meiner Erfahrung Application Whitelisting nicht besonders populär, weil es einigen Wartungsaufwand verursacht und unter Umständen legitime Programme und OS-Funktionen blockieren kann.