Hinweise zum Exploit-Schutz

  • Gilt für:: Microsoft Defender for Endpoint Plan 1, Microsoft Defender for Endpoint Plan 2

Exploit-Schutz bietet erweiterten Schutz für Anwendungen, die Unternehmensadministratoren und IT-Experten anwenden können, nachdem ein Entwickler Software kompiliert und verteilt hat.

In diesem Artikel erfahren Sie, wie Exploit-Schutz sowohl auf Richtlinienebene als auch auf individueller Ebene funktioniert, um Sie beim erfolgreichen Erstellen und Anwenden von Exploit-Schutzrichtlinien zu unterstützen.

Wie Minderungen angewendet werden

Exploit-Schutzminderungen werden pro Anwendung angewendet.

Jedes Programm verfügt über einen eigenen Registrierungseintrag, der steuert, welche Gegenmaßnahmen gelten. Diese Einstellungen werden im Registrierungseintrag "MitigationOptions " (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions) gespeichert. Diese Entschärfungseinstellungen werden wirksam, wenn Sie das Programm neu starten. Sie bleiben aktiv, bis Sie sie ändern und das Programm neu starten.

Wichtig

Mit den Optionen für die Ausführung von Bilddateien können Sie nur einen Dateinamen oder Pfad angeben. Sie können keine Versionsnummer, Architektur oder andere Unterscheidungszeichen angeben. Wenden Sie Abhilfemaßnahmen auf Apps mit eindeutigen Namen oder Pfaden an. Wenden Sie sie nur auf Geräten an, auf denen Sie diese Version und Architektur der Anwendung getestet haben.

Sie können Entschärfungen über eine XML-Datei mithilfe von PowerShell, Gruppenrichtlinien oder MDM konfigurieren. Wenn Sie eine XML-Datei verwenden, legt das System die Registrierungseinträge für Sie fest.

Exploit-Schutz zurücksetzen

Wichtig

Wenn die Gruppenrichtlinie oder MDM-Richtlinie, die die XML-Datei bereitstellt, nicht mehr erzwungen wird, werden die von dieser XML-Konfigurationsdatei bereitgestellten Einstellungen nicht automatisch entfernt.

Um Exploit-Schutzeinstellungen zu entfernen, exportieren Sie die XML-Konfiguration von einem sauberen Windows 10- oder Windows 11-Gerät und stellen Sie diese neue XML-Datei bereit. Alternativ stellt Microsoft eine XML-Datei als Teil der Windows-Sicherheit Baselines zum Zurücksetzen von Exploit-Schutzeinstellungen bereit.

Um Exploit-Schutzeinstellungen mithilfe von PowerShell zurückzusetzen, führen Sie den folgenden Befehl aus, um die Zurücksetzungsrichtlinie aus der XML-Datei anzuwenden und Entschärfungseinstellungen auf ihre Standardwerte wiederherzustellen:

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

Die folgende XML-Datei ist die mit den Windows-Sicherheit Baselines verteilte EP-reset.xml. Diese Datei definiert anwendungsspezifische Mitigation-Überschreibungen, die die Exploit-Schutzeinstellungen für gängige Anwendungen wie Microsoft Office, Webbrowser und Medienplayer auf die Standardwerte zurücksetzen:

<?xml version="1.0" encoding="UTF-8"?>
<MitigationPolicy>
  <AppConfig Executable="ONEDRIVE.EXE">
    <DEP OverrideDEP="false" />
    <ASLR OverrideRelocateImages="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
    <ImageLoad OverrideBlockRemoteImages="false" />
  </AppConfig>
  <AppConfig Executable="firefox.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
  </AppConfig>
  <AppConfig Executable="fltldr.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
    <ImageLoad OverrideBlockRemoteImages="false" />
    <ChildProcess OverrideChildProcess="false" />
  </AppConfig>
  <AppConfig Executable="GROOVE.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
    <ImageLoad OverrideBlockRemoteImages="false" />
    <ChildProcess OverrideChildProcess="false" />
  </AppConfig>
  <AppConfig Executable="Acrobat.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="AcroRd32.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="chrome.exe">
    <DEP OverrideDEP="false" />
  </AppConfig>
  <AppConfig Executable="EXCEL.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="iexplore.exe">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="INFOPATH.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="java.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="javaw.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="javaws.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="LYNC.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="MSACCESS.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="MSPUB.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="OIS.EXE">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="OUTLOOK.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="plugin-container.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="POWERPNT.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="PPTVIEW.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="VISIO.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="VPREVIEW.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="WINWORD.EXE">
    <DEP OverrideDEP="false" />
    <ASLR ForceRelocateImages="true" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="wmplayer.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
  <AppConfig Executable="wordpad.exe">
    <DEP OverrideDEP="false" />
    <Payload OverrideEnableExportAddressFilter="false" OverrideEnableExportAddressFilterPlus="false" OverrideEnableImportAddressFilter="false" OverrideEnableRopStackPivot="false" OverrideEnableRopCallerCheck="false" OverrideEnableRopSimExec="false" />
  </AppConfig>
</MitigationPolicy>

Referenz für Abhilfemaßnahmen

Die folgenden Exploit-Schutz-Gegenmaßnahmen umfassen jeweils eine Beschreibung, Kompatibilitätsaspekte und Konfigurationsoptionen.

Willkürlicher Codewächter

In den folgenden Abschnitten wird beschrieben, wie beliebiger Code guard funktioniert, welche Kompatibilitätswirkungen und konfigurationsoptionen es hat.

Beschreibung

Arbitrary Code Guard schützt vor einem böswilligen Angreifer, der den Code seiner Wahl durch eine Speichersicherheitslücke in den Speicher lädt und diesen Code ausführen kann.

Ein beliebiger Code guard schützt eine Anwendung davor, dynamisch generierten Code auszuführen (Code, der nicht geladen wird, z. B. aus der EXE selbst oder einer DLL). Arbitrary Code Guard verhindert, dass Speicher als ausführbar markiert wird. Wenn eine Anwendung versucht, Speicher zuzuweisen, prüfen wir die Schutz-Flags. (Speicher kann mit Lese-, Schreib- und/oder Ausführen-Schutzflags allokiert werden.) Wenn der Allokierungsversuch das Ausführen-Schutzflag beinhaltet, schlägt die Speicherallokierung fehl und gibt einen Fehlercode (STATUS_DYNAMIC_CODE_BLOCKED) zurück. Ebenso schlägt die Änderung der Zugriffsrechte fehl und gibt einen Fehlercode (STATUS_DYNAMIC_CODE_BLOCKED) zurück, wenn eine Anwendung versucht, die Schutzflags von Speicher zu ändern, der bereits zugewiesen wurde und das Schutzflag execute enthält.

Indem verhindert wird, dass das Ausführungsflag gesetzt wird, kann die Datenausführungsverhinderungsfunktion von Windows 10 und Windows 11 dann davor schützen, dass der Anweisungszeiger auf diesen Speicher gesetzt wird und diesen Code ausführt.

Kompatibilitätsüberlegungen

Arbitrary Code Guard verhindert die Markierung jeglichen Speichers als ausführbar, was bei Ansätzen wie Just-in-Time (JIT)-Compilern zu Kompatibilitätsproblemen führt. Die meisten modernen Browser kompilieren beispielsweise JavaScript in nativen Code, um die Leistung zu optimieren. Um diese Entschärfung zu unterstützen, müssen sie neu strukturiert werden, um die JIT-Kompilierung außerhalb des geschützten Prozesses zu verschieben. Andere Anwendungen, deren Entwurf dynamisch Code aus Skripts oder anderen Zwischensprachen generiert, sind mit dieser Entschärfung ebenfalls nicht kompatibel.

Konfigurationsoptionen

Thread-Opt-out zulassen – Sie können die Risikominderung so konfigurieren, dass ein einzelner Thread diesen Schutz deaktivieren kann. Der Entwickler muss die Anwendung mit Bewusstsein für diese Entschärfung schreiben und die SetThreadInformation-API mit dem ThreadInformation-Parameter aufrufen, der auf ThreadDynamicCodePolicy festgelegt ist, um dynamischen Code in diesem Thread ausführen zu können.

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Audit-Ereignisse können dann entweder in der Ereignisanzeige oder mithilfe von Advanced Hunting in Defender for Endpoint angezeigt werden.

Bilder mit niedriger Integrität blockieren

In den folgenden Abschnitten wird beschrieben, wie das Blockieren von Images mit niedriger Integrität funktioniert, welche Auswirkungen es auf die Kompatibilität hat und welche Konfigurationsoptionen dafür verfügbar sind.

Beschreibung

Bilder mit niedriger Integrität blockieren verhindert, dass die Anwendung Dateien lädt, die nicht vertrauenswürdig sind, in der Regel, weil sie aus einem Sandkastenbrowser aus dem Internet heruntergeladen wurden.

Diese Minderung blockiert das Laden von Images, wenn das Image über einen Access Control Entry (ACE) verfügt, der Zugriff auf Low IL-Prozesse gewährt und nicht über einen vertrauenswürdigen ACE verfügt. Sie wird vom Speicher-Manager implementiert, der verhindert, dass die Datei dem Arbeitsspeicher zugeordnet wird. Wenn eine Anwendung versucht, ein Image mit niedriger Integrität zuzuordnen, wird ein STATUS_ACCESS_DENIED Fehler ausgelöst. Einzelheiten zur Funktionsweise von Integritätsstufen finden Sie unter Mandatory Integrity Control.

Kompatibilitätsüberlegungen

Blockieren von Images mit niedriger Integrität verhindern, dass die Anwendung Dateien lädt, die aus dem Internet heruntergeladen wurden. Wenn Ihr Anwendungsworkflow das Laden heruntergeladener Image-Dateien erfordert, sollten Sie sicherstellen, dass diese von einem vertrauenswürdigeren Prozess heruntergeladen wurden oder explizit neu gekennzeichnet wurden, damit diese Abhilfemaßnahme angewendet werden kann.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Remote-Bilder blockieren

In den folgenden Abschnitten wird beschrieben, wie Das Blockieren von Remoteimages funktioniert, deren Kompatibilitätswirkung und die Konfigurationsoptionen.

Beschreibung

Durch das Blockieren von Remote-Images wird verhindert, dass die Anwendung Dateien lädt, die auf einem Remote-Gerät wie einer UNC-Freigabe gehostet werden. Das Blockieren von Remote-Images schützt vor dem Laden von Binärdateien in den Speicher, die sich auf einem externen Gerät befinden, das vom Angreifer kontrolliert wird.

Diese Abhilfemaßnahme blockiert das Laden von Bildern, wenn festgestellt wird, dass sich das Bild auf einem entfernten Gerät befindet. Sie wird vom Speicher-Manager implementiert, der verhindert, dass die Datei dem Arbeitsspeicher zugeordnet wird. Wenn eine Anwendung versucht, eine Remotedatei zuzuordnen, löst sie einen STATUS_ACCESS_DENIED-Fehler aus.

Kompatibilitätsüberlegungen

Das Blockieren von Remote-Images verhindert, dass die Anwendung Images von Remotegeräten lädt. Wenn Ihre Anwendung Dateien oder Plug-Ins von Remotegeräten lädt, ist sie mit dieser Risikominderung nicht kompatibel.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Nicht vertrauenswürdige Schriftarten blockieren

In den folgenden Abschnitten wird beschrieben, wie das Blockieren nicht vertrauenswürdiger Schriftarten funktioniert, welche Auswirkungen dies auf die Kompatibilität hat und welche Konfigurationsoptionen verfügbar sind.

Beschreibung

Durch das Blockieren nicht vertrauenswürdiger Schriftarten wird das Risiko verringert, dass ein Fehler beim Analysieren von Schriftarten dazu führt, dass der Angreifer Code auf dem Gerät ausführen kann. Nur Schriftarten, die im Verzeichnis windows\fonts installiert sind, werden zur Verarbeitung durch GDI geladen.

Diese Risikominderung wird in GDI implementiert, das den Speicherort der Datei überprüft. Wenn sich die Datei nicht im Verzeichnis "Systemschriftarten" befindet, wird die Schriftart nicht für die Analyse geladen, und der Aufruf schlägt fehl.

Diese Minderung erfolgt zusätzlich zu der integrierten Minderung, die in Windows 10 1607 und höher und Windows 11 bereitgestellt wird, wodurch die Schriftanalyse aus dem Kernel in einen App-Container im Benutzermodus verschoben wird. Jeder auf Font-Parsing basierende Exploit findet daher in einem Sandbox- und isolierten Kontext statt, wodurch das Risiko erheblich reduziert wird.

Kompatibilitätsüberlegungen

Die häufigste Verwendung von Schriftarten außerhalb des Systemschriftartenverzeichnisses sind Webschriftarten. Moderne Browser wie Microsoft Edge verwenden DirectWrite anstelle von GDI und sind nicht betroffen. Legacy-Browser wie Internet Explorer 11 (und der IE-Modus im neuen Microsoft Edge) können jedoch betroffen sein, insbesondere bei Anwendungen wie Office 365, die Schriftzeichen zur Anzeige der Benutzeroberfläche verwenden.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Codeintegritätsschutz

In den folgenden Abschnitten wird beschrieben, wie Codeintegritätsschutz funktioniert, wie die Kompatibilitätswirkungen und die Konfigurationsoptionen funktionieren.

Beschreibung

Code Integrity Guard stellt sicher, dass alle in einen Prozess geladenen Binärdateien von Microsoft digital signiert werden. Der Codeintegritätsschutz umfasst WHQL-Signaturen (Windows Hardware Quality Labs), mit denen WHQL-genehmigte Treiber innerhalb des Prozesses ausgeführt werden können.

Diese Abschwächung wird innerhalb des Speichermanagers implementiert, der verhindert, dass die Binärdatei dem Speicher zugeordnet wird. Wenn Sie versuchen, eine Binärdatei zu laden, die nicht von Microsoft signiert ist, gibt die Speicherverwaltung den Fehler STATUS_INVALID_IMAGE_HASH zurück. Durch das Blockieren auf Ebene der Speicherverwaltung wird verhindert, dass sowohl vom Prozess geladene Binärdateien als auch in den Prozess injizierte Binärdateien blockiert werden.

Kompatibilitätsüberlegungen

Diese Entschärfung blockiert insbesondere jede Binärdatei, die nicht von Microsoft signiert ist. Daher ist es mit den meisten Nicht-Microsoft-Software nicht kompatibel, es sei denn, diese Software wird vom Microsoft Store verteilt (und digital signiert) und die Option zum Zulassen des Ladens von Bildern, die vom Microsoft Store signiert sind, ist ausgewählt.

Konfigurationsoptionen

Lassen Sie auch das Laden von Bildern zu, die vom Microsoft Store signiert wurden. Anwendungen, die vom Microsoft Store verteilt werden, werden vom Microsoft Store digital signiert, und durch das Hinzufügen dieser Konfiguration können Binärdateien, die den Prozess der Store-Zertifizierung durchlaufen, von der Anwendung geladen werden.

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Ablaufsteuerungsschutz (Control Flow Guard, CFG)

In den folgenden Abschnitten wird beschrieben, wie Control Flow Guard funktioniert, welche Auswirkungen es auf die Kompatibilität hat und welche Konfigurationsoptionen verfügbar sind.

Beschreibung

Control Flow Guard (CFG) mindert das Risiko, dass Angreifer Schwachstellen durch Speicherbeschädigung ausnutzen, indem indirekte Funktionsaufrufe geschützt werden. Beispielsweise könnte ein Angreifer ein Sicherheitsrisiko aufgrund eines Pufferüberlaufs verwenden, um Speicher zu überschreiben, der einen Funktionszeiger enthält, und diesen Funktionszeiger durch einen Zeiger auf ausführbaren Code seiner Wahl zu ersetzen (der auch in das Programm eingefügt werden kann).

Diese Abhilfe erfolgt durch das Einfügen einer weiteren Überprüfung beim Kompilieren. Vor jedem indirekten Funktionsaufruf werden weitere Anweisungen hinzugefügt, die überprüfen, ob das Ziel ein gültiges Aufrufziel ist, bevor es aufgerufen wird. Wenn das Ziel kein gültiges Aufrufziel ist, wird die Anwendung beendet. Daher können nur Anwendungen, die mit CFG-Unterstützung kompiliert wurden, von dieser Minderung profitieren.

Die Überprüfung auf ein gültiges Ziel wird vom Windows-Kernel bereitgestellt. Wenn ausführbare Dateien geladen werden, werden die Metadaten für indirekte Aufrufziele zur Ladezeit extrahiert und als gültige Aufrufziele markiert. Wenn Speicher zugewiesen und als ausführbar markiert wird (z. B. für generierten Code), werden diese Speicherorte außerdem auch als gültige Aufrufziele markiert, um Mechanismen wie JIT-Kompilierung zu unterstützen.

Kompatibilitätsüberlegungen

Da Anwendungen zur Unterstützung von CFG kompiliert werden müssen, erklären sie implizit ihre Kompatibilität damit. Die meisten Anwendungen sollten daher mit aktivierter Minderung funktionieren. Da diese Prüfungen in die Binärdatei kompiliert werden, besteht die Konfiguration, die Sie anwenden können, lediglich darin, Prüfungen innerhalb des Windows-Kernels zu deaktivieren. Mit anderen Worten, die Entschärfung ist standardmäßig aktiviert, aber Sie können den Windows-Kernel so konfigurieren, dass immer "Ja" zurückgegeben wird, wenn Sie später feststellen, dass ein Kompatibilitätsproblem vorliegt, das der Anwendungsentwickler bei seinen Tests nicht entdeckt hat, was selten sein sollte.

Konfigurationsoptionen

Strict CFG verwenden – Im Strict-Modus müssen alle in den Prozess geladenen Binärdateien für Control Flow Guard kompiliert werden (oder keinen ausführbaren Code enthalten – wie z. B. Ressourcen-DLLs), um geladen zu werden.

Hinweis

Kontrollflusswächter hat keinen Prüfmodus. Binärdateien werden mit dieser aktivierten Risikominderung kompiliert.

Datenausführungsverhinderung (DEP, Data Execution Prevention)

In den folgenden Abschnitten wird beschrieben, wie die Datenausführungsverhinderung funktioniert, ihre Kompatibilitätswirkungen und die Konfigurationsoptionen.

Beschreibung

Die Datenausführungsverhinderung (Data Execution Prevention, DEP) verhindert, dass Arbeitsspeicher ausgeführt wird, der nicht explizit als ausführbare Datei zugeordnet wurde. DEP schützt vor einem Angreifer, der bösartigen Code in den Prozess einfügt, z. B. durch einen Pufferüberlauf, und diesen Code dann ausführt.

Wenn Sie versuchen, den Anweisungszeiger auf eine Speicheradresse festzulegen, die nicht als ausführbare Datei gekennzeichnet ist, löst der Prozessor eine Ausnahme (allgemeine Schutzverletzung) aus, wodurch die Anwendung abstürzt.

Kompatibilitätsüberlegungen

Für alle ausführbaren x64-, ARM- und Arm64-Dateien ist DEP standardmäßig aktiviert und kann nicht deaktiviert werden. Da eine Anwendung nicht ohne DEP ausgeführt wird, wird kompatibilität vorausgesetzt.

Bei allen x86-Binärdateien (32 Bit) ist DEP standardmäßig aktiviert, DEP kann jedoch pro Prozess deaktiviert werden. Einige alte Legacyanwendungen, in der Regel Anwendungen, die vor Windows XP SP2 entwickelt wurden, sind möglicherweise nicht mit DEP kompatibel. Solche Anwendungen generieren normalerweise Code dynamisch (z. B. JIT-Kompilierung) oder verknüpfen sich mit älteren Bibliotheken (z. B. älteren Versionen von ATL), die Code dynamisch generieren.

Konfigurationsoptionen

ATL Thunk Emulation aktivieren – Diese Option steuert die ATL Thunk Emulation . ATL, die ActiveX-Vorlagenbibliothek, ist darauf ausgelegt, so klein und schnell wie möglich zu sein. Um die Binäre Größe zu reduzieren, wird eine Technik namens Thunking verwendet. Thunking ist oft mit 32-Bit- und 16-Bit-Interaktion verknüpft, aber ATL hat keine 16-Bit-Teile. Um Speicherplatz zu sparen, speichert ATL Computercode stattdessen im Arbeitsspeicher, der nicht wortbündig ausgerichtet ist. Dadurch wird eine kleinere Binärdatei erstellt. ATL führt diesen Code dann direkt aus. ATL-Versionen, die mit Visual Studio 7.1 oder einer früheren Version (Visual Studio 2003) kompiliert wurden, markieren diesen Speicher nicht als ausführbare Datei. Die Thunk-Emulation behebt dieses Problem. Apps mit einem binären Erweiterungsmodell (z. B. Internet Explorer 11) erfordern, dass die ATL-Thunk-Emulation aktiviert ist.

Deaktivieren von Erweiterungspunkten

In den folgenden Abschnitten wird beschrieben, wie die Risikominderung durch das Deaktivieren von Erweiterungspunkten funktioniert, welche Auswirkungen sie auf die Kompatibilität hat und welche Konfigurationsoptionen sie bietet.

Beschreibung

Die Risikominderung „Erweiterungspunkte deaktivieren“ deaktiviert verschiedene Erweiterungspunkte für eine Anwendung, die verwendet werden können, um Persistenz herzustellen oder bösartigen Inhalten höhere Berechtigungen zu verschaffen.

Dies umfasst Folgendes:

  • AppInit-DLLs : Wenn ein Prozess gestartet wird, lädt das System die angegebene DLL in den Kontext des neu gestarteten Prozesses, bevor seine Einstiegspunktfunktion aufgerufen wird. Details zu AppInit-DLLs finden Sie hier. Wenn diese Entschärfung angewendet wird, werden AppInit-DLLs nicht geladen. Ab Windows 7 müssen AppInit-DLLs wie hier beschrieben digital signiert werden. Darüber hinaus werden appInit-DLLs ab Windows 8 nicht geladen, wenn SecureBoot aktiviert ist, wie hier beschrieben.
  • Ältere IMEs – Ein Input Method Editor (IME) ermöglicht es einem Benutzer, Text in einer Sprache einzugeben, die mehr Zeichen hat, als auf einer Tastatur dargestellt werden können. Dritte können IMEs erstellen. Ein böswilliger IME kann aus dieser Eingabeerfassung Anmeldeinformationen oder andere vertrauliche Informationen erhalten. Einige IMEs, die als Legacy-IMEs bezeichnet werden, funktionieren nur für Windows-Desktop-Apps und nicht für UWP-Apps. Diese Abhilfemaßnahme verhindert außerdem, dass dieser veraltete IME in die angegebene Windows-Desktop-App geladen wird.
  • Windows-Ereignis-Hooks – Eine Anwendung kann die SetWinEventHook-API aufrufen, um Interesse an einem stattfindenden Ereignis zu registrieren. Eine DLL wird angegeben und kann in den Prozess injiziert werden. Diese Minderung erzwingt, dass der Hook an den Registrierungsprozess gesendet wird, anstatt prozessintern über eine eingefügte DLL ausgeführt zu werden.

Kompatibilitätsüberlegungen

Die meisten dieser Erweiterungspunkte werden relativ selten verwendet, sodass der Kompatibilitätseffekt in der Regel gering ist, insbesondere auf einzelner Anwendungsebene. Die einzige Überlegung ist, ob Benutzer Nicht-Microsoft Legacy-IMEs verwenden, die nicht mit der geschützten Anwendung funktionieren.

Konfigurationsoptionen

Es gibt keine Konfigurationsoptionen für diese Risikominderung.

Hinweis

Erweiterungspunkte deaktivieren verfügt über keinen Überwachungsmodus.

Win32k-Systemaufrufe deaktivieren

In den folgenden Abschnitten wird beschrieben, wie die Risikominderung durch Deaktivieren von Win32k-Systemaufrufen funktioniert, welche Auswirkungen sie auf die Kompatibilität hat und welche Konfigurationsoptionen verfügbar sind.

Beschreibung

Win32k.sys bietet einem Angreifer eine breite Angriffsfläche. Als Komponente im Kernelmodus wird sie häufig als Ausbruchsvektor für Anwendungen genutzt, die in einer Sandbox ausgeführt werden. Diese Minderung verhindert Aufrufe in win32k.sys, indem ein Thread daran gehindert wird, sich selbst in einen GUI-Thread zu konvertieren, der dann Zugriff zum Aufrufen von Win32k-Funktionen erhält. Ein Thread ist nach seiner Erstellung keine GUI, wird aber beim ersten Aufruf in win32k.sys oder durch einen API-Aufruf in IsGuiThread konvertiert.

Kompatibilitätsüberlegungen

Diese Minderung ist für Prozesse konzipiert, die dedizierte Nicht-UI-Prozesse sind. Viele moderne Browser verwenden beispielsweise Prozessisolation und integrieren Nicht-Ui-Prozesse. Jede Anwendung, die eine GUI mit einem einzelnen Prozess anzeigt, ist von dieser Entschärfung betroffen.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Untergeordnete Prozesse nicht zulassen

In den folgenden Abschnitten wird beschrieben, wie die Risikominderung „Keine untergeordneten Prozesse zulassen“ funktioniert, welche Auswirkungen sie auf die Kompatibilität hat und welche Konfigurationsoptionen verfügbar sind.

Beschreibung

Die Sicherheitsmaßnahme „Untergeordneten Prozesse nicht zulassen“ verhindert, dass eine Anwendung neue untergeordnete Anwendungen erstellt. Eine gängige Technik, die von Angreifern verwendet wird, besteht darin, einen vertrauenswürdigen Prozess auf dem Gerät mit böswilligen Eingaben zu initiieren (ein „Living Off the Land“-Angriff), was häufig das Starten einer anderen Anwendung auf dem Gerät erfordert. Wenn es keine legitimen Gründe für den Start eines untergeordneten Prozesses durch eine Anwendung gibt, schwächt diese Maßnahme diesen potenziellen Angriffsvektor ab. Die Risikominderung wird angewendet, indem eine Eigenschaft für das Prozesstoken festgelegt wird, die das Erstellen eines Tokens für den untergeordneten Prozess mit der Fehlermeldung STATUS_CHILD_PROCESS_BLOCKED blockiert.

Kompatibilitätsüberlegungen

Wenn Ihre Anwendung aus irgendeinem Grund untergeordnete Prozesse startet, beispielsweise die Unterstützung von Hyperlinks, die einen Browser bzw. einen externen Browser öffnen oder andere Dienstprogramme auf dem Computer starten, funktioniert diese Funktion bei Anwendung dieser Abhilfemaßnahme nicht mehr.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Adressfilterung exportieren

In den folgenden Abschnitten wird beschrieben, wie die Exportadressfilterung funktioniert, wie die Kompatibilitätswirkung und die Konfigurationsoptionen funktionieren.

Beschreibung

Die Exportadressfilterung (EAF) mindert das Risiko, dass bösartiger Code die Exportadresstabelle aller geladenen Module durchsucht, um Module zu finden, die nützliche APIs für ihren Angriff enthalten. Dies ist eine gängige Taktik, die von Shellcode verwendet wird. Um das Risiko eines solchen Angriffs zu mindern, schützt diese Minderung drei häufig angegriffene Module:

  • ntdll.dll
  • kernelbase.dll
  • kernel32.dll

Die Risikominderung schützt die Speicherseite im [Exportverzeichnis, das auf die Exportadresstabelle verweist. Auf dieser Speicherseite wird der PAGE_GUARD-Schutz angewendet. Wenn jemand versucht, auf diesen Speicher zuzugreifen, wird eine STATUS_GUARD_PAGE_VIOLATION ausgelöst. Die Abhilfemaßnahme behandelt diese Ausnahme, und wenn die Zugriffsanweisung die Überprüfung nicht besteht, wird der Prozess beendet.

Kompatibilitätsüberlegungen

Diese Minderung ist in erster Linie ein Problem für Anwendungen wie Debugger, Sandbox-Anwendungen, Anwendungen, die DRM verwenden, oder Anwendungen, die Anti-Debugging-Technologie implementieren.

Konfigurationsoptionen

Validieren Sie den Zugriff für Module, die häufig von Exploits missbraucht werden – Diese Option, auch bekannt als EAF+, fügt Schutz für andere häufig angegriffene Module hinzu:

  • mshtml.dll
  • flash*.ocx
  • jscript*.ocx
  • vbscript.dll
  • vgx.dll
  • mozjs.dll
  • xul.dll
  • acrord32.dll
  • acrofx32.dll
  • acroform.api

Zusätzlich fügt diese Abhilfemaßnahme durch Aktivieren von EAF+ der Seite, die den „MZ“-Header enthält – die ersten 2 Bytes des DOS-Headers in einer PE-Datei –, den PAGE_GUARD-Schutz hinzu. Dabei handelt es sich um einen Aspekt bekannten Speicherinhalts, nach dem Shellcode suchen kann, um potenziell interessante Module im Arbeitsspeicher zu identifizieren.

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Randomisierung für Images erzwingen (Verpflichtendes ASLR)

In den folgenden Abschnitten wird beschrieben, wie Erzwungene ASLR funktioniert, welche Auswirkungen sie auf die Kompatibilität hat und welche Konfigurationsoptionen verfügbar sind.

Beschreibung

Address Space Layout Randomization (ASLR) verringert das Risiko, dass ein Angreifer sein Wissen über das Speicherlayout des Systems nutzt, um Code auszuführen, der bereits im Prozessspeicher vorhanden und bereits als ausführbar markiert ist. Dies kann das Risiko eines Angreifers verringern, der Techniken wie Return-to-libc-Angriffe verwendet, bei denen der Angreifer den Kontext festlegt und dann die Rücksendeadresse ändert, um vorhandenen Code mit einem Kontext auszuführen, der dem Zweck des Angreifers entspricht.

Obligatorisches ASLR erzwingt einen Rebase aller DLLs innerhalb des Prozesses. Entwickler können ASLR mithilfe der Linkeroption /DYNAMICBASE aktivieren, und diese Abhilfemaßnahme hat denselben Effekt.

Wenn der Speicher-Manager das Image dem Prozess zuordnet, erzwingt Mandatory ASLR einen Rebase von DLLs und EXEs, für die ASLR nicht aktiviert ist. Beachten Sie jedoch, dass diese Umbasierung keine Entropie hat und daher an einer vorhersagbaren Stelle im Speicher platziert werden kann. Für die rebasierte und randomisierte Lokalisierung von Binärdateien sollte diese Minderung mit Randomize Memory Allocations (Bottom-up ASLR) gekoppelt werden.

Kompatibilitätsüberlegungen

Dieser Kompatibilitätseffekt von ASLR ist in der Regel auf ältere Anwendungen beschränkt, die mit Compilern erstellt wurden, die Annahmen über die Basisadresse einer Binärdatei getroffen oder Basisverschiebungsinformationen entfernt haben. Dies kann zu unvorhersehbaren Fehlern führen, wenn der Ausführungsfluss versucht, zur erwarteten statt zur tatsächlichen Position im Speicher zu springen.

Konfigurationsoptionen

Entfernte Images nicht zulassen : Diese Option blockiert das Laden von Images, deren Verschiebungsinformationen entfernt wurden. Das Windows PE-Dateiformat enthält absolute Adressen, und der Compiler generiert auch eine [Basisverlagerungstabelle, die der Ladeprogramm verwenden kann, um alle relativen Speicherverweise und deren Offset zu finden, sodass sie aktualisiert werden können, wenn die Binärdatei nicht an ihrer bevorzugten Basisadresse geladen wird. Einige ältere Anwendungen entfernen diese Informationen in Produktionsbuilds, sodass für diese Binärdateien kein Rebase durchgeführt werden kann. Diese Abschwächung blockiert das Laden solcher Binärdateien (anstatt ihnen zu erlauben, an ihrer bevorzugten Basisadresse geladen zu werden).

Hinweis

Randomisierung für Images erzwingen (Verpflichtendes ASLR) hat keinen Überwachungsmodus.

Hardware-erzwungener Stapelschutz

Beschreibung

Hardwaregezwungener Stapelschutz bietet einen robusten Schutz vor ROP-Exploits. Es funktioniert, indem ein Datensatz des beabsichtigten Ausführungsflusses eines Programms gehalten wird. Um eine reibungslose Akzeptanz und App-Kompatibilität zu unterstützen, bietet Windows diesen Schutz als Opt-In-Modell. Entwickler können es in ihrem eigenen Tempo aktivieren.

Kompatibilitätsüberlegungen

Hardware-erzwungener Stapelschutz funktioniert nur für Chipsätze mit Unterstützung für Hardwareschattenstapel, Intels Control-Flow Enforcement Technology (CET) oder AMD-Schattenstapel.

Wenn Sie Anwendungen basierend auf dem .NET Framework ausführen, funktioniert der hardwaregestützte Stapelschutz mit .NET Framework 7 (opt-in) oder höher. Wenn Sie eine ältere Version verwenden, können Abstürze oder eine hohe CPU-Auslastung auftreten. Diese Probleme können auch im Überwachungsmodus oder dann auftreten, wenn nur kompatible Module als Ziel ausgewählt werden.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Audit-Ereignisse können dann entweder in der Ereignisanzeige oder mithilfe von Advanced Hunting in Defender for Endpoint angezeigt werden.

Für alle Module statt für kompatible Module erzwingen – Sie können diese Schutzmaßnahme so aktivieren, dass sie für alle Module statt nur für kompatible Module erzwungen wird.

Import-Adressfilterung (IAF)

Beschreibung

Die Importadressfilterung (IAF) trägt dazu bei, das Risiko zu mindern, dass ein Angreifer den Kontrollfluss einer Anwendung ändert, indem er die Importadresstabelle (IAT) so ändert, dass sie beim Aufruf dieser Funktion auf beliebigen Code nach Wahl des Angreifers umleitet. Ein Angreifer könnte diesen Ansatz verwenden, um die Kontrolle zu übernehmen oder um Aufrufe sensibler APIs abzufangen, zu inspizieren und möglicherweise zu blockieren.

Auf die Speicherseiten für alle geschützten APIs wird der PAGE_GUARD-Schutz angewendet. Wenn jemand versucht, auf diesen Speicher zuzugreifen, wird eine STATUS_GUARD_PAGE_VIOLATION ausgelöst. Die Abhilfemaßnahme behandelt diese Ausnahme, und wenn die Zugriffsanweisung die Überprüfung nicht besteht, wird der Prozess beendet.

Diese Risikominderung schützt die folgenden Windows-APIs:

  • GetProcAddress
  • GetProcAddressForCaller
  • LoadLibraryA
  • LoadLibraryExA
  • LoadLibraryW
  • LoadLibraryExW
  • LdrGetProcedureAddress
  • LdrGetProcedureAddressEx
  • LdrGetProcedureAddressForCaller
  • LdrLoadDll
  • VirtualProtect
  • VirtualProtectEx
  • VirtualAlloc
  • VirtualAllocEx
  • NtAllocateVirtualMemory
  • NtProtectVirtualMemory
  • CreateProcessA
  • CreateProcessW
  • WinExec
  • CreateProcessAsUserA
  • CreateProcessAsUserW
  • GetModuleHandleA
  • GetModuleHandleW
  • RtlDecodePointer
  • DecodePointer

Kompatibilitätsüberlegungen

Legitime Anwendungen, die API-Aufrufe abfangen, könnten durch diese Abhilfemaßnahme erkannt werden, wodurch einige Anwendungen abstürzen könnten. Beispiele hierfür sind Sicherheitssoftware und Shims für die Anwendungskompatibilität.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Zufällige Speicherzuweisungen (Bottom-up-ASLR)

Beschreibung

Die Zufallsanordnung von Speicherzuweisungen (ASLR von unten nach oben) erhöht die Entropie von Verschiebungen, sodass ihre Positionen zufällig und daher weniger vorhersehbar sind. Diese Schutzmaßnahme erfordert das Wirksamwerden des verpflichtenden ASLR .

Die Größe des 32-Bit-Adressraums schränkt die hinzuzufügende Entropie praktisch ein, und daher erschweren es 64-Bit-Anwendungen einem Angreifer, einen Speicherort zu erraten.

Kompatibilitätsüberlegungen

Die meisten Apps, die mit verpflichtendem ASLR (Rebasing) funktionieren, funktionieren auch mit ASLR von unten nach oben. Einige Apps haben möglicherweise Zeigerabkürzungsprobleme, wenn sie lokale Zeiger in 32-Bit-Variablen speichern. Diese Apps erwarten eine Basisadresse unter 4 GB, sodass sie nicht mit der Option für hohe Entropie funktionieren. Sie können bei Bedarf hohe Entropie deaktivieren.

Konfigurationsoptionen

Keine hohe Entropie verwenden – Diese Option deaktiviert die Verwendung von High-Entropie-ASLR, wodurch 24 Bit Entropie (1 TB Varianz) zur Bottom-Up-Zuweisung für 64-Bit-Anwendungen hinzugefügt werden.

Hinweis

Zufällige Speicherzuweisungen (Bottom-up-ASLR) haben keinen Überwachungsmodus.

Simulieren der Ausführung (SimExec)

Beschreibung

Ausführung simulieren (SimExec) ist eine Schutzmaßnahme nur für 32-Bit-Anwendungen. Dadurch wird überprüft, ob Aufrufe vertraulicher APIs an legitime Aufruferfunktionen zurückgegeben werden. Dies geschieht, indem Aufrufe an sensitive APIs abgefangen und anschließend die Ausführung dieser APIs simuliert wird, wobei die codierten Assembleranweisungen schrittweise bis zur RET-Anweisung durchlaufen werden, die zum Aufrufer zurückkehren sollte. Er untersucht dann diese Funktion und geht im Speicher rückwärts, um den vorangehenden CALL-Befehl zu finden, um festzustellen, ob die Funktion und der CALL-Befehl übereinstimmen und ob RET nicht abgefangen wurde.

Die von dieser Abhilfemaßnahme abgefangenen APIs sind:

  • LoadLibraryA
  • LoadLibraryW
  • LoadLibraryExA
  • LoadLibraryExW
  • LdrLoadDll
  • VirtualAlloc
  • VirtualAllocEx
  • NtAllocateVirtualMemory
  • VirtualProtect
  • VirtualProtectEx
  • NtProtectVirtualMemory
  • HeapCreate
  • RtlCreateHeap
  • CreateProcessA
  • CreateProcessW
  • CreateProcessInternalA
  • CreateProcessInternalW
  • NtCreateUserProcess
  • NtCreateProcess
  • NtCreateProcessEx
  • CreateRemoteThread
  • CreateRemoteThreadEx
  • NtCreateThreadEx
  • WriteProcessMemory
  • NtWriteVirtualMemory
  • WinExec
  • CreateFileMappingA
  • CreateFileMappingW
  • CreateFileMappingNumaW
  • NtCreateSection
  • MapViewOfFile
  • MapViewOfFileEx
  • MapViewOfFileFromApp
  • LdrGetProcedureAddressForCaller

Wenn ein ROP-Gadget erkannt wird, wird der Prozess beendet.

Kompatibilitätsüberlegungen

Anwendungen, die API-Aufrufe abfangen, insbesondere Sicherheitssoftware, können zu Kompatibilitätsproblemen mit dieser Abhilfemaßnahme führen.

Diese Schutzmaßnahme ist nicht mit der Arbitrary Code Guard-Maßnahme kompatibel.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Überprüfen des API-Aufrufs (CallerCheck)

Beschreibung

Validate API Invocation (CallerCheck) ist eine Abschwächung für Techniken der rückgabeorientierten Programmierung (ROP), die überprüft, ob vertrauliche APIs von einem gültigen Aufrufer aufgerufen wurden. Diese Schutzmaßnahme überprüft die übergebene Rückgabeadresse und disassembliert anschließend heuristisch rückwärts, um einen Aufruf vor der Rückgabeadresse zu finden und festzustellen, ob das Aufrufziel mit dem an die Funktion übergebenen Parameter übereinstimmt.

Die von dieser Abhilfemaßnahme abgefangenen APIs sind:

  • LoadLibraryA
  • LoadLibraryW
  • LoadLibraryExA
  • LoadLibraryExW
  • LdrLoadDll
  • VirtualAlloc
  • VirtualAllocEx
  • NtAllocateVirtualMemory
  • VirtualProtect
  • VirtualProtectEx
  • NtProtectVirtualMemory
  • HeapCreate
  • RtlCreateHeap
  • CreateProcessA
  • CreateProcessW
  • CreateProcessInternalA
  • CreateProcessInternalW
  • NtCreateUserProcess
  • NtCreateProcess
  • NtCreateProcessEx
  • CreateRemoteThread
  • CreateRemoteThreadEx
  • NtCreateThreadEx
  • WriteProcessMemory
  • NtWriteVirtualMemory
  • WinExec
  • CreateFileMappingA
  • CreateFileMappingW
  • CreateFileMappingNumaW
  • NtCreateSection
  • MapViewOfFile
  • MapViewOfFileEx
  • MapViewOfFileFromApp
  • LdrGetProcedureAddressForCaller

Wenn ein ROP-Gadget erkannt wird, wird der Prozess beendet.

Kompatibilitätsüberlegungen

Anwendungen, die API-Aufrufe abfangen, insbesondere Sicherheitssoftware, können zu Kompatibilitätsproblemen mit dieser Abhilfemaßnahme führen.

Diese Schutzmaßnahme ist nicht mit der Arbitrary Code Guard-Maßnahme kompatibel.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Ausnahmeketten überprüfen (SEHOP)

Beschreibung

Die Überprüfung von Ausnahmeketten (SEHOP) ist eine Abwehrmaßnahme gegen die Exploittechnik Überschreiben des strukturierten Ausnahmehandlers (SEH). Die strukturierte Ausnahmebehandlung ist der Prozess, durch den eine Anwendung die Behandlung einer bestimmten Ausnahme anfordern kann. Ausnahmebehandler sind miteinander verkettet, sodass, wenn ein Ausnahmebehandler sich entscheidet, eine bestimmte Ausnahme nicht zu behandeln, diese an den nächsten Ausnahmebehandler in der Kette weitergegeben werden kann, bis einer entscheidet, sie zu behandeln. Da die Liste der Handler dynamisch ist, wird sie im Stapel gespeichert. Ein Angreifer kann eine Stapelüberlauf-Schwachstelle verwenden, um dann den Ausnahmehandler mit einem Zeiger auf den Code seiner Wahl zu überschreiben.

Diese Entschärfung basiert auf dem Entwurf von SEH, wobei jeder SEH-Eintrag sowohl einen Zeiger auf den Ausnahmehandler als auch einen Zeiger auf den nächsten Handler in der Ausnahmekette enthält. Diese Schutzmaßnahme wird vom Ausnahme-Dispatcher aufgerufen, der die SEH-Kette überprüft, wenn eine Ausnahme aufgerufen wird. Es bestätigt Folgendes:

  • Alle Einträge der Ausnahmekette liegen innerhalb der Stackgrenzen
  • Alle Ausnahmedatensätze werden ausgerichtet
  • Kein Exception-Handler-Zeiger verweist auf den Stack
  • Es gibt keine Rückwärtszeiger
  • Die Ausnahmekette endet an einem bekannten letzten Ausnahmehandler

Wenn diese Überprüfungen fehlschlagen, wird die Ausnahmebehandlung abgebrochen, und die Ausnahme wird nicht behandelt.

Kompatibilitätsüberlegungen

Kompatibilitätsprobleme mit SEHOP sind relativ selten. Es kommt selten vor, dass eine Anwendung eine Abhängigkeit von der Beschädigung der Ausnahmekette verwendet. Einige Anwendungen sind jedoch von den geringfügigen Änderungen in den zeitlichen Abläufen betroffen, die sich unter Umständen als Racebedingung äußern können und dadurch einen verborgenen Multithreading-Fehler in der Anwendung aufdecken.

Konfigurationsoptionen

Hinweis

Ausnahmeketten validieren (SEHOP) hat keinen Prüfmodus.

Handle-Verwendung überprüfen

Beschreibung

Die Validierung der Handle-Nutzung ist eine Risikominderung, die zum Schutz vor einem Angreifer beiträgt, der ein vorhandenes Handle für den Zugriff auf ein geschütztes Objekt verwendet. Ein Handle ist eine Referenz auf ein geschütztes Objekt. Wenn der Anwendungscode auf ein ungültiges Handle zugreift, kann dies darauf hindeuten, dass ein Angreifer versucht, ein zuvor erfasstes Handle zu verwenden, von dem die Referenzzählung der Anwendung nichts weiß. Wenn die Anwendung versucht, ein ungültiges Objekt zu verwenden, anstatt einfach NULL zurückzugeben, löst die Anwendung eine Ausnahme aus (STATUS_INVALID_HANDLE).

Diese Risikominderung wird automatisch auf Windows Store-Anwendungen angewendet.

Kompatibilitätsüberlegungen

Anwendungen, die Verweise auf Handles nicht korrekt verfolgt und diese Vorgänge nicht in Ausnahmebehandlungsroutinen umschlossen haben, können potenziell von dieser Schutzmaßnahme betroffen sein.

Konfigurationsoptionen

Hinweis

Handleverwendung validieren verfügt über keinen Überwachungsmodus.

Heap-Integrität überprüfen

Beschreibung

Die Schutzmaßnahme Überprüfung der Heapintegrität erhöht die Schutzstufe von Heap-Schutzmaßnahmen in Windows, indem die Anwendung beendet wird, wenn eine Heapbeschädigung erkannt wird. Zu den Minderungen gehören:

  • Verhindern, dass ein HEAP-Handle freigegeben wird
  • Durchführen einer weiteren Validierung an erweiterten Blockheadern für Heap-Zuweisungen
  • Überprüfen, ob Heapzuordnungen nicht bereits als in Benutzung markiert sind
  • Hinzufügen von Schutzseiten zu großen Zuweisungen, Heapsegmenten und Untersegmenten ab einer Mindestgröße

Kompatibilitätsüberlegungen

Diese Minderung wird bereits standardmäßig für 64-Bit-Anwendungen und für 32-Bit-Anwendungen angewendet, die auf Windows Vista oder höher abzielen. Ältere Anwendungen von Windows XP oder früher sind am stärksten gefährdet, obwohl Kompatibilitätsprobleme selten sind.

Konfigurationsoptionen

Hinweis

Überprüfung der Heapintegrität hat keinen Überwachungsmodus.

Überprüfen der Integrität von Imageabhängigkeiten

Beschreibung

Die Schutzmaßnahme Überprüfen von Imageabhängigkeiten schützt vor Angriffen, bei denen versucht wird, DLLs, die von Windows-Binärdateien statisch eingebunden werden, durch Code zu ersetzen. Die Technik des DLL-Einpflanzens missbraucht den Suchmechanismus des Ladeprogramms, um schädlichen Code einzuschleusen, der verwendet werden kann, um schädlichen Code in einem erhöhten Kontext auszuführen. Wenn das Ladeprogramm eine signierte Windows-Binärdatei lädt und dann alle DLL-Dateien lädt, von denen die Binärdatei abhängt, werden diese Binärdateien überprüft, um sicherzustellen, dass sie auch digital als Windows-Binärdatei signiert sind. Wenn die Signaturprüfung fehlschlägt, wird die DLL nicht geladen, es wird eine Ausnahme ausgelöst, und der Status STATUS_INVALID_IMAGE_HASH wird zurückgegeben.

Kompatibilitätsüberlegungen

Kompatibilitätsprobleme sind selten. Anwendungen, die auf das Ersetzen von Windows-Binärdateien durch lokale, private Versionen angewiesen sind, sind betroffen, und zudem besteht ein geringes Risiko, dass in Multithreadanwendungen subtile Timingfehler sichtbar werden.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

Überprüfen der Stapelintegrität (StackPivot)

Beschreibung

Die Schutzmaßnahme zum Überprüfen der Stackintegrität (StackPivot) hilft, vor dem Stack-Pivot-Angriff zu schützen, einem ROP-Angriff, bei dem ein Angreifer einen gefälschten Stack im Heap-Speicher erstellt und dann die Anwendung dazu verleitet, zur Rückkehr in den gefälschten Stack überzugehen, der den Ausführungsablauf steuert.

Diese Schutzmaßnahme fängt Aufrufe vieler Windows-APIs ab und prüft den Wert des Stapelzeigers. Wenn die Adresse des Stapelzeigers nicht zwischen dem unteren und dem oberen Rand des Stapels liegt, wird ein Ereignis aufgezeichnet, und, wenn nicht im Überwachungsmodus, wird der Prozess beendet.

Die von dieser Abhilfemaßnahme abgefangenen APIs sind:

  • LoadLibraryA
  • LoadLibraryW
  • LoadLibraryExA
  • LoadLibraryExW
  • LdrLoadDll
  • VirtualAlloc
  • VirtualAllocEx
  • NtAllocateVirtualMemory
  • VirtualProtect
  • VirtualProtectEx
  • NtProtectVirtualMemory
  • HeapCreate
  • RtlCreateHeap
  • CreateProcessA
  • CreateProcessW
  • CreateProcessInternalA
  • CreateProcessInternalW
  • NtCreateUserProcess
  • NtCreateProcess
  • NtCreateProcessEx
  • CreateRemoteThread
  • CreateRemoteThreadEx
  • NtCreateThreadEx
  • WriteProcessMemory
  • NtWriteVirtualMemory
  • WinExec
  • CreateFileMappingA
  • CreateFileMappingW
  • CreateFileMappingNumaW
  • NtCreateSection
  • MapViewOfFile
  • MapViewOfFileEx
  • MapViewOfFileFromApp
  • LdrGetProcedureAddressForCaller

Kompatibilitätsüberlegungen

Anwendungen, die Fake-Stacks verwenden, sind betroffen, und es besteht außerdem ein geringes Risiko, dass subtile Timing-Fehler in Multithread-Anwendungen offengelegt werden. Anwendungen, die API-Aufrufe abfangen, insbesondere Sicherheitssoftware, können zu Kompatibilitätsproblemen mit dieser Abhilfemaßnahme führen.

Diese Schutzmaßnahme ist nicht mit der Arbitrary Code Guard-Maßnahme kompatibel.

Konfigurationsoptionen

Nur Überwachen : Sie können diese Entschärfung im Überwachungsmodus aktivieren, um die potenziellen Kompatibilitätsbeeinträchtigungen für eine Anwendung zu messen. Überwachungsereignisse können dann entweder in der Ereignisanzeige oder mit der Erweiterten Suche in Microsoft Defender for Endpoint angezeigt werden.

  • Last updated on