Freigeben über

Skripterzwingung mit Windows Defender Application Control (WDAC)

Hinweis

Einige Funktionen von Windows Defender Anwendungssteuerung sind nur in bestimmten Windows-Versionen verfügbar. Erfahren Sie mehr über die Verfügbarkeit des Anwendungssteuerungsfeatures.

Wichtig

Option 11 Deaktiviert: Die Skripterzwingung wird auf Windows Server 2016 oder auf Windows 10 1607 LTSB nicht unterstützt und sollte auf diesen Plattformen nicht verwendet werden. Dies führt zu unerwarteten Skripterzwingungsverhalten.

Übersicht über die Skripterzwingung

Standardmäßig ist die Skripterzwingung für alle WDAC-Richtlinien aktiviert, es sei denn, die Option 11 Deaktiviert:Skripterzwingung ist in der Richtlinie festgelegt. Die WDAC-Skripterzwingung umfasst einen Handshake zwischen einem optimierten Skripthost wie PowerShell und WDAC. Der Skripthost verarbeitet jedoch das tatsächliche Erzwingungsverhalten. Einige Skripthosts, z. B. der Microsoft HTML-Anwendungshost (mshta.exe), blockieren die gesamte Codeausführung, wenn eine WDAC-UMCI-Richtlinie aktiv ist. Die meisten Skripthosts fragen zuerst WDAC, ob ein Skript basierend auf den derzeit aktiven WDAC-Richtlinien ausgeführt werden soll. Der Skripthost blockiert, lässt oder ändert dann die Ausführung des Skripts, um den Benutzer und das Gerät bestmöglich zu schützen.

Die Überprüfung für signierte Skripts erfolgt mithilfe der WinVerifyTrust-API. Um die Überprüfung zu bestehen, muss der Signaturstamm im vertrauenswürdigen Stammspeicher auf dem Gerät vorhanden sein, und Ihre WDAC-Richtlinie muss dies zulassen. Dieses Verhalten unterscheidet sich von der WDAC-Überprüfung für ausführbare Dateien, für die keine Installation des Stammzertifikats erforderlich ist.

WDAC gibt das Ereignisprotokoll AppLocker – MSI und Script für alle Skripterzwingungsereignisse frei. Wenn ein Skripthost WDAC fragt, ob ein Skript zulässig sein soll, wird ein Ereignis mit der Antwort-WDAC protokolliert, die an den Skripthost zurückgegeben wird. Weitere Informationen zu WDAC-Skripterzwingungsereignissen finden Sie unter Grundlegendes zu Anwendungssteuerungsereignissen.

Hinweis

Wenn ein Skript ausgeführt wird, das von der Richtlinie nicht zulässig ist, löst WDAC ein Ereignis aus, das angibt, dass das Skript "blockiert" wurde. Das tatsächliche Skripterzwingungsverhalten wird jedoch vom Skripthost verarbeitet und kann die Ausführung der Datei möglicherweise nicht vollständig blockieren.

Beachten Sie auch, dass einige Skripthosts ihr Verhalten ändern können, auch wenn sich eine WDAC-Richtlinie nur im Überwachungsmodus befindet. Sie sollten die spezifischen Informationen des Skripthosts in diesem Artikel überprüfen und gründlich in Ihrer Umgebung testen, um sicherzustellen, dass die Skripts, die Sie ausführen müssen, ordnungsgemäß funktionieren.

Optimierte Skripthosts, die Teil von Windows sind

PowerShell

Ihre WDAC-Richtlinien müssen zulassen, dass alle PowerShell-Skripts (.ps1), Module (.psm1) und Manifeste (.psd1) mit Vollsprachrechten ausgeführt werden können.

Ihre WDAC-Richtlinien müssen auch alle abhängigen Module zulassen, die von einem zulässigen Modul geladen werden, und Modulfunktionen müssen explizit anhand des Namens exportiert werden, wenn WDAC erzwungen wird. Module, die keine exportierten Funktionen angeben (keine Exportnamenliste), werden weiterhin geladen, aber es sind keine Modulfunktionen zugänglich. Module, die Platzhalter (*) im Namen verwenden, können nicht geladen werden.

Alle PowerShell-Skripts, die von der WDAC-Richtlinie nicht zulässig sind, werden weiterhin ausgeführt, jedoch nur im eingeschränkten Sprachmodus.

PowerShell-Dot-Sourcing wird nicht empfohlen. Stattdessen sollten Skripts PowerShell-Module verwenden, um allgemeine Funktionen bereitzustellen. Wenn eine zulässige Skriptdatei versucht, Dot-Source-Skriptdateien auszuführen, müssen diese Skriptdateien auch die Richtlinie erfüllen.

WDAC versetzt interaktive PowerShell in den Eingeschränkten Sprachmodus, wenn eine WDAC-UMCI-Richtlinie erzwungen wird und eine aktive WDAC-Richtlinie die Skripterzwingung aktiviert, auch wenn sich diese Richtlinie im Überwachungsmodus befindet. Um interaktive PowerShell mit Vollsprachrechten auszuführen, müssen Sie die Skripterzwingung für alle Richtlinien deaktivieren.

Weitere Informationen finden Sie unter Informationen zu Sprachmodi und eingeschränktem Sprachmodus.

VBscript, cscript und jscript

Ihre WDAC-Richtlinien müssen die Ausführung aller Skripts mit dem Windows-basierten Skripthost (wscript.exe) oder dem Microsoft Console Based Script Host (cscript.exe) zulassen. Andernfalls wird das Skript blockiert.

Microsoft HTML Application Host (MSHTA) und MSXML

Die gesamte Codeausführung mit MSHTA oder MSXML wird blockiert, wenn eine WDAC-Richtlinie mit Skripterzwingung aktiv ist, auch wenn sich diese Richtlinie im Überwachungsmodus befindet.

COM-Objekte

WDAC erzwingt zusätzlich eine eingeschränkte Zulassungsliste für COM-Objekte, die ihre WDAC-Richtlinie erweitern oder weiter einschränken kann. Com-Objekterzwingung wird von Option 11 Deaktiviert:Skripterzwingungnicht beeinflusst. Weitere Informationen zum Zulassen oder Verweigern von COM-Objekten finden Sie unter Zulassen der COM-Objektregistrierung.

Skripts, die nicht direkt von WDAC gesteuert werden

WDAC steuert nicht direkt Code, der über den Windows-Befehlsprozessor (cmd.exe) ausgeführt wird, einschließlich .bat/.cmd-Skriptdateien. Alles, was ein solches Batchskript auszuführen versucht, unterliegt jedoch der WDAC-Steuerung. Wenn Sie cmd.exe nicht ausführen müssen, wird empfohlen, es direkt zu blockieren oder nur durch Ausnahme basierend auf dem aufrufenden Prozess zuzulassen. Weitere Informationen finden Sie unter Verwenden einer Windows Defender Anwendungssteuerungsrichtlinie zum Steuern bestimmter Plug-Ins, Add-Ins und Module.

WDAC steuert keine Skripts, die über einen nicht vereinfachten Skripthost ausgeführt werden, z. B. viele Java- oder Python-Engines von Drittanbietern. Wenn Ihre WDAC-Richtlinie die Ausführung eines nicht optimierten Skripthosts zulässt, lassen Sie implizit zu, dass alle Skripts über diesen Host ausgeführt werden. Bei Nicht-Microsoft-Skripthosts sollten Sie beim Softwarehersteller überprüfen, ob die Skripthosts für die WDAC-Richtlinie geeignet sind.