[English]Ich greife mal, aus gegebenem Anlass, ein Thema auf, was mir Anfang Mai 2025 unter die Augen gekommen ist. Administratoren haben festgestellt, dass das PowerShell Script Enforcement im AppLocker/WDAC über Monate kaputt war. Sollte inzwischen aber mit der PowerShell 7.6 zwar behoben sein, zeigt aber, dass man im Fall der Fälle nicht oft genug hinschauen kann.
Anzeige
AppLocker und WDAC
AppLocker ist eine Anwendungskontrollfunktion in Windows, die verwendet wird, um zu steuern, welche Anwendungen und Dateien Benutzer ausführen können. Es ermöglicht die Erstellung von Regeln, um die Ausführung von Apps basierend auf verschiedenen Faktoren, wie z.B. der Dateigröße, dem Hash-Wert oder dem Zertifikat, zu erlauben oder zu verweigern.
Windows Defender Application Control (WDAC) soll dazu beitragen, viele denkbare Sicherheitsbedrohungen zu minimieren. Dies erfolgt durch Einschränken von Anwendungen, die Benutzer ausführen dürfen, und den Code, der im Systemkern (Kernel) ausgeführt wird. Anwendungssteuerungsrichtlinien können auch nicht signierte Skripts und MSI-Dateien blockieren und Windows PowerShell auf die Ausführung im ConstrainedLanguage-Modus beschränken.
PowerShell Script Enforcement mit App-Control
Bei App Control Script Enforcement durch AppLocker/WDAC handelt es sich um eine Sicherheitsebene, bei der die Script-Ausführung zwischen dem Script-Host (PowerShell) und App Control per Handshake ausgehandelt wird. Script-Host steuert dann, ob gesetzte Regeln zur Ausführung oder Blockierung des Scripts anzuwenden sind. Einige Script Hosts, wie der Microsoft HTML Application Host (mshta.exe), blockieren die gesamte Codeausführung, wenn eine App Control UMCI-Richtlinie aktiv ist. Die meisten Script Hosts fragen zunächst App Control, ob die Ausführung eines Skripts auf der Grundlage der derzeit aktiven App Control Richtlinien erlaubt werden soll. Der Skript-Host blockiert oder erlaubt dann die Ausführung des Skripts oder ändert sie, um den Benutzer und das Gerät bestmöglich zu schützen. Wurde von Microsoft hier beschrieben.
Es gab ein Problem in Windows 11 24H2
Das Ganze ging etwas an mir vorbei, aber bereits Anfang April 2025 gibt es in der Spice-Works-Community den Beitrag Application Control blocking WDAC policy deployment, wo jemand darauf hin wies, dass es Probleme bei der Durchsetzung von WDAC-Richtlinien in Windows 11 24H2 gebe.
Anzeige
Auf reddit.com gibt es den Thread Heads up!! Windows 11 24H2: AppLocker script enforcement broken!!, der davor warnt, dass es bei der Migration auf Windows 11 24H2 Probleme mit dem AppLocker Script Enforcement gebe. Der Beitrag verweist auf den zum 27. April 2025 bei Patch my PC erschienenen Artikel Windows 11 24H2: AppLocker script enforcement broken.
Bei der Migration auf Windows 11 24H2 gebe es ein kritisches Sicherheitsproblem, heißt es dort. Unter Windows 11 24H2 werde der eingeschränkte Sprachmodus (Constrained Language Mode) bei der Verwendung von AppLocker-Skriptregeln nicht mehr korrekt durchgesetzt.
PowerShell-Skripte, die stark eingeschränkt sein sollten, würden jetzt im vollständigen Sprachmodus völlig uneingeschränkt ausgeführt. Dadurch entstehe eine große Lücke in der Sicherheitsdurchsetzung, die Administratoren vor dem Upgrade auf Windows 24H2 verstehen und beseitigen müssen.
Mir ist das Thema dann erstmals Anfang Mai 2025 im neowin.net-Beitrag Admins find Windows 11 24H2 PowerShell AppLocker/WDAC script enforcement broken for months untergekommen. Im Kontext dieses Kommentars hier im Blog habe ich das Thema mal herausgezogen. Inzwischen hat Microsoft das Verhalten mit PowerShell 7.6 wohl korrigiert (siehe Fallback to AppLocker after WldpCanExecuteFile (#24912). Aber das ist der Blog-Leserschaft vermutlich bekannt.
Ähnliche Artikel:
Windows: WDAC und Driver Blocklist scheitern; MS will Video von Will Dormann
Windows Defender Application Control (WDAC) wird Application Control for Business
Windows 10: Ungewollte Neustarts wegen Microsoft Defender Application Control (WDAC)
Anzeige
Der Constrained Language Mode ist so eine Sache… Am einfachsten lässt er sich ja einschalten, in dem man $ExecutionContext.SessionState.LanguageMode = "ConstrainedLanguage" setzt, aber das lässt sich genauso einfach wieder ausschalten. Man kann außerdem eine Umgebungsvariable setzen, das geht z.B. auch per GPO, __PSLockDownPolicy=4, aber dies ist ein eher undokumentierter Hack, für den Microsoft keine Garantie gibt, dass er weiter unterstützt wird, eine offiziell unterstützte Möglichkeit, dem CLM einzuschalten gibt es nicht direkt, nur indirekt über Applocker/SRP, mit dem man aber eigentlich was anderes erreicht (nämlich dass PS1-Scripte nur aus erlaubten Pfaden ausführen kann). Außerdem wirkt der CLM auf wirklich alle User, auch auf Serviceaccounts und Admins, was so manche Deployment- oder Inventarisierungs-Software usw. aus dem Tritt bringt. Ich empfehle das hier nochmal nachzulesen:
https://www.windowspro.de/wolfgang-sommergut/constrained-language-mode-powershell-risiken-entschaerfen
Sicherer ist wohl, die Ausführung von PS1 Scripten auf (remote-) signed fest zu legen, das bedeutet allerdings bei Script-Erstellung/Testing etwas Mehraufwand, der sich aber auch wieder vereinfachen lässt:
https://4sysops.com/archives/set-powershell-execution-policy-with-group-policy/
https://www.windowspro.de/wolfgang-sommergut/powershell-scripts-signieren-zertifikaten-einer-ad-zertifizierungsstelle
https://www.der-windows-papst.de/2025/03/19/powershell-script-signer/
Danke für die Ergänzung – die Admins müssen es halt wissen (wovon ich ausgehe) und das auch beherzigen (was ich nicht beurteilen kann).
Wenn Microsoft in den letzten Jahren nicht signifikante Änderungen an der Sicherheitsarchitektur von PowerShell vorgenommen hat, bringt die Signierung eher wenig, außer vor versehentlicher Ausführung zu schützen.
Auf die Schnelle gefunden:
https://www.netspi.com/blog/technical-blog/network-pentesting/15-ways-to-bypass-the-powershell-execution-policy/
Spätestens Variante 3 zeigt, mit welchem Unfug hier Microsoft Sicherheit versucht zu verkaufen. Genau das gleiche wie bei UAC:
Der Laie soll aufgeschreckt werden, mehr nicht.
Alle andern werden genervt.
Echte Bugs und Probleme an den Basics können aus Kompatibilitäts-Zwängen nicht gefixt werden.
Windows ist Broken by Design.
Schon immer: Es wird lediglich seit Jahrzehnten durch immer mehr neue Sicherheitsschichten in jeder neuen Windows-Version versucht zu kaschieren.
Das Problem bei den von dir vorgeschlagenen Einstellungen, dass die Funktionalität nicht von Admin und normalem User unterscheiden kann, heißt wenn Admins weiterhin Powershell im vollem Umfang nutzen können sollen, führt ein Weg über Applocker nicht daran vorbei.
Aber das ist der Blog-Leserschaft vermutlich bekannt.
Leider nein… Danke!
Powershell sollte für Clients deaktiviert und Administratoren-Hosts vorbehalten sein, alles andere ist fahrlässig. Ist die dunkle Seite der Macht bereits dazu im Stande, PS-Scripte auf der Administrativen Maschine auszuführen, kann der Verantwortliche sich eh gleich mit seiner Berufshaftpflicht in Verbindung setzen.
Danke für den Artikel. Ich war tatsächlich gestern mit dem Problem konfrontiert und habe mir erst mal einen Wolf gesucht.
Finde es schade, dass MS keine GPO etc. zur Verfügung stellt, um den Constrained Language Mode zu aktivieren.
Wie das geht, steht im Sommergut-Artikel, der oben verlinkt ist: Applocker aktivieren.