Von JEA, CLM, WinRM bis hin zur AMSI-Integration und Execution Policy: Wir erklären Ihnen, wie Sie PowerShell professionell “härten” und damit sicherer machen können.
Was versteht man unter “PowerShell-Härtung”?
Eine offizielle, allgemein verbindliche Definition von “PowerShell Hardening” gibt es nicht. Der Begriff bedeutet einerseits, dass man IT-Systeme mithilfe von PowerShell härtet – also einer Systemhärtung bzw. einem System Hardening unterzieht. Dies kann über selbst entwickelte PowerShell-Skripte oder mit Hardening-Tools wie dem Enforce Administrator erfolgen, das auf PowerShell DSC basiert.
Zum anderen bezeichnet man als PowerShell Hardening die Härtung von PowerShell selbst. In vielen Publikationen wird der Begriff in diesem Sinne verwendet.
📅 Enforce Administrator: Live-Demo buchen
Wie geht man beim PowerShell Hardening vor?
Wenn wir die letztgenannte Definition verwenden, bedeutet das: PowerShell Hardening bezeichnet eine Maßnahme, mit der man die Angriffsflächen von PowerShell deutlich reduziert. Das erfolgt über die sichere Konfiguration (Secure Configuration) der Anwendung.
Warum ist das wichtig? PowerShell wird seit rund 20 Jahren von IT-Administratoren eingesetzt. Sie nutzen es unter anderem, um das Betriebssystem zu konfigurieren und Aufgaben zu automatisieren. Daher versuchen Angreifer häufig, PowerShell zu “kapern”, um die Systeme übernehmen zu können. PowerShell kann somit ein mögliches Eintrittstor bei Cyber-Attacken sein.
PowerShell Hardening bedeutet jedoch nicht, das Framework zu verbieten oder zu deaktivieren! Vielmehr geht es darum, den Einsatz kontrollierbar, nachvollziehbar und sicher zu gestalten.
Das PowerShell Hardening folgt somit den klassischen Prinzipien der Systemhärtung:
✅ Reduzierung der Angriffsfläche
✅ Einschränkung von Missbrauchsmöglichkeiten
✅ Schaffung von Transparenz durch Logging
✅ Legitime Administration wird ermöglicht
PowerShell Hardening: Was sollten Sie NICHT machen?
Ja, PowerShell kann für Angriffsvektoren ausgenutzt werden. Es ist allerdings nicht sinnvoll, PowerShell vollständig zu deinstallieren. Die NSA und andere Sicherheitsbehörden raten sogar ausdrücklich davon ab, das Windows-Tool zu deaktivieren oder zu entfernen. Denn ohne PowerShell lassen sich essentielle, administrative Aufgaben nicht mehr ausführen.
Auch aggressive Einschränkungen, die die Produktivität stark beeinträchtigen, machen keinen Sinn. Das PowerShell Hardening darf nämlich nicht dazu führen, dass wichtige Skripte oder Administrationswerkzeuge unbenutzbar werden!
Bedenken Sie also stets: Eine 100-prozentige Systemhärtung kann und darf nie Ihr Ziel sein – ansonsten werden Ihre Systeme unbrauchbar!
Wie setzt man eine PowerShell-Härtung um?
Sie möchten nun im Detail wissen, wie man ein sinnvolles und nachhaltiges PowerShell Hardening durchführt? Dann sollten Sie diese Maßnahmen umsetzen:
Erweitertes Logging
➡ PowerShell bietet umfangreiche Logging‑Funktionen wie Script Block Logging, Module Logging und Transcription, um ausgeführte Befehle nachvollziehbar zu machen. Diese Transparenz ist aus Security- und Forensik-Sicht äußerst wertvoll, da PowerShell häufig “Living off the Land“ verwendet wird.
➡ Logging ist kein triviales Thema! Selbst etablierte Standards wie die CIS-Benchmarks bewerten einzelne Logging-Optionen, insbesondere Transcription, nicht eindeutig. Sie setzen diese nicht klar auf “enabled” oder “disabled”, sondern variieren je nach Sicherheitsprofil und Einsatzszenario.
➡ Enthalten Skripte beispielsweise Klartext-Passwörter oder Tokens, können diese bei aktivem Logging ungewollt protokolliert werden. Ein PowerShell Hardening erfordert hier ein bewusstes Logging-Design, sichere Skript-Standards und klare organisatorische Vorgaben. Und eben nicht nur das pauschale Aktivieren aller Log-Optionen.
Legacy‑Komponenten deaktivieren
➡ Ein grundlegender Hardening-Schritt ist die Deaktivierung veralteter PowerShell-Versionen, insbesondere PowerShell 2.0. Da die veraltete Fassung keine modernen Sicherheitsfunktionen wie AMSI oder erweitertes Logging unterstützt, wird sie von Angreifern als Downgrade-Pfad missbraucht.
➡ PowerShell v2 sollte daher konsequent deaktiviert bzw. entfernt werden. Das reduziert die Angriffsfläche deutlich, ohne den regulären Admin-Betrieb zu beeinträchtigen.
Application Control und Code Signing
➡ Eine der wirksamsten Maßnahmen im PowerShell Hardening ist die Kontrolle darüber, welcher Code überhaupt zugelassen wird. Technologien wie AppLocker oder Windows Defender Application Control (WDAC) ermöglichen es, die Ausführung von Skripten und Binärdateien gezielt auf vertrauenswürdige Quellen zu beschränken.
➡ Während AppLocker auf regelbasierten Freigaben (beispielsweise Pfad, Hash oder Publisher) basiert, verfolgt WDAC einen deutlich strengeren, Kernel-basierten Ansatz. Das heißt: Hier ist nur explizit zugelassener Code erlaubt!
➡ In diesem Zusammenhang spielt auch Code Signing eine zentrale Rolle. Durch die kryptografische Signierung von Skripten lässt sich sicherstellen, dass nur geprüfter und freigegebener Code ausgeführt wird. Dies schafft nicht nur Integrität, sondern auch klare Vertrauensketten im Betrieb.
➡ Ein entscheidender Vorteil: Erst durch den Einsatz von Application Control entfalten andere Sicherheitsmechanismen ihre volle Wirkung. So kann etwa der Constrained Language Mode in Kombination mit WDAC zuverlässig für nicht vertrauenswürdigen Code erzwungen werden, während signierte und freigegebene Skripte weiterhin im Full Language Mode ausführen.
AMSI: Anti Malware Scan Interface
➡ Das Anti Malware Scan Interface (AMSI) ermöglicht es, Security-Lösungen mit PowerShell-Code zur Laufzeit zu analysieren. Unabhängig davon, ob der Code aus einer Datei stammt, interaktiv eingegeben oder dynamisch generiert wird.
➡ Gut zu wissen: AMSI ist kein Schutzmechanismus, der PowerShell absichert. Sondern eine Schnittstelle, die Transparenz für Endpoint-Security-Produkte herstellt. Die Wirksamkeit hängt daher maßgeblich von der angebundenen Applikation und der Konfiguration ab.
➡ Im Hardening-Kontext stellt AMSI ein zentraler Baustein dar, um PowerShell-Missbrauch frühzeitig zu erkennen. Es ersetzt jedoch weder saubere Konfigurationen, noch eingeschränkte Berechtigungen. Warum? AMSI lässt sich unter bestimmten Bedingungen umgehen.
JEA: Just Enough Administration
➡ Mit der JEA-Technologie lassen sich administrative Aufgaben so bereitstellen, dass Benutzer nur die genau benötigten Aktionen ausführen dürfen. Alles ohne generellen Admin-Zugriff. Das reduziert Risiken erheblich, selbst wenn Anmeldeinformationen kompromittiert werden. Es setzt somit das Least-Privilege-Prinzip konsequent um.
➡ JEA basiert auf speziell definierten Session-Konfigurationen und Rollen (Role Capabilities). Über diese legt man exakt fest, welche Befehle und Aktionen ausgeführt werden dürfen.
CLM: Constrained Language Mode
➡ Der Constrained Language Mode (CLM) schränkt gezielt mächtige PowerShell-Funktionen ein, die häufig für einen Missbrauch genutzt werden. Dazu gehören zum Beispiel der Zugriff auf .NET-Typen, COM-Objekte oder das dynamische Erzeugen von Code. PowerShell bleibt beim Einsatz des CLM weiterhin nutzbar, die Angriffsfläche wird jedoch deutlich reduziert.
➡ Das bedeutet: Während CLM die technischen Möglichkeiten von PowerShell einschränkt, kontrolliert JEA, was ein Benutzer tun darf. CLM schützt somit primär vor gefährlichem Code auf gehärteten Systemen, JEA vor übermäßigen Rechten in administrativen Sessions. Beide Ansätze ergänzen sich, ersetzen sich jedoch nicht.
➡ Der Constrained Language Mode ist nicht als eigenständige Sicherheitsmaßnahme gedacht. Erst in Kombination mit systemweiten Application-Control-Mechanismen wie AppLocker oder Windows Defender Application Control greift der Schutz zuverlässig.
➡ In solchen Szenarien – abhängig von der konfigurierten Richtlinie – erzwingt Windows automatisch den Constrained Language Mode für nicht-vertrauenswürdigen Code, während genehmigte oder signierte Skripte weiterhin im Full Language Mode laufen dürfen.
➡ Der Sicherheitsgewinn ergibt sich somit aus dem Zusammenspiel von Einschränkung und gezieltem Vertrauen. Dies erfordert jedoch saubere Richtlinien sowie eine kontrollierte Freigabe von Skripten.
WinRM: Secure Remote Management
➡ PowerShell wird häufig für die Remote-Administration eingesetzt. Dementsprechend ist auch WinRM ein zentraler Bestandteil im Hardening-Prozess. Die Sicherheit hängt maßgeblich vom jeweiligen Einsatzszenario sowie vom verwendeten Authentifizierungsmechanismus ab.
➡ Grundsätzlich gilt: WinRM verschlüsselt die Kommunikation immer, unabhängig davon, ob HTTP oder HTTPS zum Einsatz kommt. Wie Microsoft beschreibt, wird nach erfolgreicher Authentifizierung der gesamte PowerShell-Remoting-Datenverkehr verschlüsselt übertragen.
______________
Ein zentraler Unterschied für die Bewertung der Sicherheit liegt im Betriebsmodell:
🔻 In AD-integrierten Umgebungen erfolgt die Authentifizierung standardmäßig über Kerberos. Dadurch werden sowohl die Identität des Benutzers als auch des Zielsystems sichergestellt, ohne dass man wiederverwendbare Zugangsdaten überträgt. In diesen Szenarien besteht in der Regel kein zusätzlicher Bedarf für den Einsatz von Zertifikaten im Kontext von WinRM.
🔻 In sogenannten Standalone-Umgebungen, also außerhalb einer Domäne, kommt hingegen NTLM zum Einsatz. Hier stellen Zertifikate primär die Funktion, die Identität von Client und Server sicher. Sie sind jedoch nicht für die eigentliche Verschlüsselung der Kommunikation verantwortlich.
🔻 Diese Unterscheidung ist wichtig: Während in AD-Umgebungen Kerberos bereits eine starke Authentifizierung und gegenseitige Identitätsprüfung bietet, erfordern Standalone-Szenarien eine bewusst geplante Konfiguration, um vergleichbare Sicherheitsniveaus zu erreichen.
🔻 Unabhängig vom Szenario bleibt die Zugriffskontrolle ein zentraler Faktor. Nur autorisierte Systeme und Benutzer sollten WinRM nutzen dürfen, kombiniert mit Netzwerkbeschränkungen und einem sauberen Berechtigungsmodell.
🔻 Da WinRM häufig für laterale Bewegungen innerhalb eines Netzwerks genutzt wird, spielt zudem das Least-Privilege-Prinzip eine zentrale Rolle. Technologien wie JEA können dabei helfen, administrative Zugriffe gezielt einzuschränken und die Auswirkungen kompromittierter Zugangsdaten zu begrenzen.
🔻 Ziel des Hardening ist es somit, eine kontrollierte, nachvollziehbare und sichere Remote-Administration zu ermöglichen – unter Berücksichtigung der jeweiligen Einsatzszenarien.
______________
Umgang mit Zugangsdaten
➡ Die PowerShell-Härtung umfasst auch den sicheren Umgang mit Credentials. Warum? Unsauber gestaltete Skripte können dazu führen, dass Passwörter oder Tokens im Klartext übergeben oder sogar mitgeloggt werden – insbesondere bei aktivem Transcription-Logging.
➡ Conclusio: Sichere Credential-Mechanismen und bewusst geplante Logging-Strategien sollten zu Ihrem PowerShell Hardening unbedingt dazugehören!
➡ Daher sollten sichere Mechanismen zur Credential-Verwaltung eingesetzt werden, beispielsweise Secret-Management-Lösungen oder dedizierte Vault-Systeme. Gleichzeitig sind klare Vorgaben für Skript-Entwicklung und Logging unerlässlich.
Execution Policy als Schutzmechanismus
➡ Die Execution Policy ist ebenfalls kein Sicherheitsmechanismus, sondern ein Schutz gegen unbeabsichtigte Skriptausführung. Etwa durch versehentlich gestartete Dateien oder unsignierte Skripte aus E‑Mails.
➡ Ein Angreifer mit ausreichenden Rechten kann die Execution Policy umgehen oder gezielt anpassen. Deshalb wird sie bei der Systemhärtung nicht als Schutzbarriere zu verstehen, sondern als hygienische Baseline-Einstellung. Eine, die Benutzer für den bewussten Umgang mit Skripten sensibilisiert.
➡ PowerShell Hardening bedeutet hier vor allem: Keine falsche Sicherheit vermitteln, sondern die Execution Policy korrekt einordnen und mit echten Sicherheitsmaßnahmen kombinieren!
Fazit
PowerShell Hardening ist keine einzelne Maßnahme, sondern ein ganzheitlicher Ansatz, um PowerShell als potentiellen Angriffsweg zu “unattraktiver” zu machen – ohne dabei die Funktionalität für berechtigte Nutzer einzuschränken. Erst die Kombination verschiedener Strategien und Maßnahmen (zum Beispiel die Kontrolle der Code-Ausführung und das saubere Betriebsmodell) schafft eine belastbare Sicherheitsstrategie.
Haben Sie weitere Fragen zum Thema? Oder benötigen Sie Unterstützung? Wenden Sie sich gerne an uns. Das System-Hardening-Team der FB Pro steht Ihnen gerne zur Seite.
Bilder: Freepik/Magnific AI