Dela via

Referens för exploateringsskydd

  • Artikel

Gäller för:

Vill du uppleva Microsoft Defender för Endpoint? Registrera dig för en kostnadsfri utvärderingsversion.

Exploateringsskydd ger avancerade skydd för program som företagsadministratörer och IT-proffs kan använda när en utvecklare har kompilerats och distribuerat programvara.

Den här artikeln hjälper dig att förstå hur exploateringsskydd fungerar, både på principnivå och på enskild åtgärdsnivå, för att hjälpa dig att skapa och tillämpa principer för sårbarhetsskydd.

Hur åtgärder tillämpas

Riskreducering av sårbarhetsskydd tillämpas per program.

Åtgärder konfigureras via en registerpost för varje program som du konfigurerar skydd för. De här inställningarna lagras i registerposten MitigationOptions för varje program (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). De börjar gälla när du startar om programmet och förblir effektiva tills du ändrar dem och startar om programmet igen.

Viktigt

Med körningsalternativ för bildfiler kan du bara ange ett filnamn eller en sökväg, inte ett versionsnummer, en arkitektur eller någon annan differentiering. Var noga med att rikta åtgärder mot appar som har unika namn eller sökvägar, och tillämpa dem bara på enheter där du har testat den versionen och den arkitekturen för programmet.

Om du konfigurerar sårbarhetsskyddsminskningar med hjälp av en XML-konfigurationsfil med hjälp av PowerShell, grupprincip eller MDM konfigureras enskilda registerinställningar åt dig när du bearbetar XML-konfigurationsfilen.

Återställa sårbarhetsskydd

Viktigt

När principen som distribuerar XML-filen inte längre tillämpas tas inte inställningar som distribueras av den här XML-konfigurationsfilen bort automatiskt.

Om du vill ta bort inställningarna för exploateringsskydd exporterar du XML-konfigurationen från en ren Windows 10 eller Windows 11 enhet och distribuerar den nya XML-filen. Alternativt tillhandahåller Microsoft en XML-fil som en del av Windows-säkerhet-baslinjer för återställning av inställningarna för sårbarhetsskydd.

Om du vill återställa inställningarna för exploateringsskydd med PowerShell använder du följande kommando:

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

Följande är EP-reset.xml som distribueras med Windows-säkerhet-baslinjer:

<?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>

Referenser för åtgärder

I följande avsnitt beskrivs de skydd som tillhandahålls av varje sårbarhetsskyddsåtgärd, kompatibilitetsöverväganden för begränsningen och de konfigurationsalternativ som är tillgängliga.

Godtycklig kodskydd

Beskrivning

Godtycklig code guard hjälper till att skydda mot en angripare som läser in valfri kod i minnet via en säkerhetsrisk för minnet och kan köra koden.

Godtycklig kodskydd skyddar ett program från att köra dynamiskt genererad kod (kod som inte läses in, till exempel från själva exe-filen eller en dll-fil). Godtycklig kodskydd fungerar genom att förhindra att minnet markeras som körbart. När ett program försöker allokera minne kontrollerar vi skyddsflaggorna. (Minne kan allokeras med läs-, skriv- och/eller kör skyddsflaggor.) Om allokeringen försöker inkludera flaggan för att utföra skydd misslyckas minnesallokeringen och returnerar en felkod (STATUS_DYNAMIC_CODE_BLOCKED). Om ett program på samma sätt försöker ändra skyddsflaggorna för minne som redan har allokerats och inkluderar flaggan för att utföra skydd, misslyckas behörighetsändringen och returnerar en felkod (STATUS_DYNAMIC_CODE_BLOCKED).

Genom att förhindra att körningsflaggan anges kan funktionen för datakörningsskydd i Windows 10 och Windows 11 sedan skydda mot att instruktionspekaren anges till det minnet och att koden körs.

Överväganden för bakåtkompatibilitet

Godtycklig code guard förhindrar allokering av minne som körbart, vilket ger ett kompatibilitetsproblem med metoder som JUST-in-Time-kompilatorer (JIT). De flesta moderna webbläsare kompilerar till exempel JavaScript till inbyggd kod för att optimera prestanda. För att stödja den här begränsningen måste de omkompileras för att flytta JIT-kompileringen utanför den skyddade processen. Andra program vars design dynamiskt genererar kod från skript eller andra mellanliggande språk är på samma sätt inkompatibla med den här begränsningen.

Konfigurationsalternativ

Tillåt att tråden avregistreras: Du kan konfigurera riskreduceringen så att en enskild tråd kan välja bort det här skyddet. Utvecklaren måste skriva programmet med medvetenhet om den här begränsningen och anropa SetThreadInformation-API :et med parametern ThreadInformation inställd på ThreadDynamicCodePolicy för att kunna köra dynamisk kod på den här tråden.

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Defender för Endpoint.

Blockera bilder med låg integritet

Beskrivning

Blockera bilder med låg integritet förhindrar att programmet läser in filer som inte är betrodda, vanligtvis eftersom de har laddats ned från Internet från en webbläsare i begränsat läge.

Den här åtgärden blockerar bildinläsningar om avbildningen har en Access Control Entry (ACE) som ger åtkomst till Low IL-processer och som inte har någon ace-betrodd etikett. Den implementeras av minneshanteraren, som blockerar filen från att mappas till minnet. Om ett program försöker mappa en bild med låg integritet utlöser det ett STATUS_ACCESS_DENIED fel. Mer information om hur integritetsnivåer fungerar finns iMandatory Integrity Control.

Överväganden för bakåtkompatibilitet

Blockera bilder med låg integritet förhindrar att programmet läser in filer som laddats ned från Internet. Om ditt programarbetsflöde kräver inläsning av avbildningar som laddas ned, vill du se till att de laddas ned från en process med högre förtroende eller uttryckligen etiketteras om för att den här begränsningen ska kunna tillämpas.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Blockera fjärrbilder

Beskrivning

Om du blockerar fjärravbildningar kan du förhindra att programmet läser in filer som finns på en fjärrenhet, till exempel en UNC-resurs. Blockering av fjärrbilder skyddar mot inläsning av binärfiler i minnet som finns på en extern enhet som kontrolleras av angriparen.

Den här åtgärden blockerar bildinläsningar om avbildningen har fastställts vara på en fjärrenhet. Den implementeras av minneshanteraren, som blockerar filen från att mappas till minnet. Om ett program försöker mappa en fjärrfil utlöser det ett STATUS_ACCESS_DENIED fel.

Överväganden för bakåtkompatibilitet

Blockera fjärrbilder hindrar programmet från att läsa in bilder från fjärrenheter. Om programmet läser in filer eller plugin-program från fjärrenheter är det inte kompatibelt med den här åtgärden.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Blockera teckensnitt som inte är betrodda

Beskrivning

Blockera ej betrodda teckensnitt minskar risken för ett fel i teckensnittsparsning som leder till att angriparen kan köra kod på enheten. Endast teckensnitt som installeras i katalogen windows\fonts läses in för bearbetning av GDI.

Den här åtgärden implementeras i GDI, som verifierar filens plats. Om filen inte finns i katalogen systemteckensnitt läses inte teckensnittet in för parsning och det anropet misslyckas.

Den här åtgärden är utöver den inbyggda begränsningen som tillhandahålls i Windows 10 1607 och senare, och Windows 11, som flyttar teckensnittsparsning från kerneln och till en appcontainer i användarläge. Alla sårbarheter som baseras på teckensnittsparsning sker därför i en sandbox-miljö och isolerad kontext, vilket minskar risken avsevärt. Mer information om den här begränsningen finns i bloggen Härdning Windows 10 med nolldagars sårbarhetsminskningar.

Överväganden för bakåtkompatibilitet

Den vanligaste användningen av teckensnitt utanför systemets teckensnittskatalog är med webbteckensnitt. Moderna webbläsare, till exempel Microsoft Edge, använder DirectWrite i stället för GDI och påverkas inte. Äldre webbläsare, till exempel Internet Explorer 11 (och IE-läge i den nya Microsoft Edge) kan dock påverkas, särskilt med program som Office 365, som använder teckenglyfer för att visa användargränssnittet.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Kodintegritetsskydd

Beskrivning

Kodintegritetsskydd säkerställer att alla binärfiler som läses in i en process signeras digitalt av Microsoft. Kodintegritetsskydd innehåller WHQL-signaturer (Windows Hardware Quality Labs) som gör att WHQL-godkända drivrutiner kan köras i processen.

Den här åtgärden implementeras i minneshanteraren, vilket blockerar binärfilen från att mappas till minnet. Om du försöker läsa in en binär fil som inte är signerad av Microsoft returnerar minnesskötaren felet STATUS_INVALID_IMAGE_HASH. Genom att blockera på minneshanterarnivå förhindrar detta både binärfiler som läses in av processen och binärfiler som matas in i processen.

Överväganden för bakåtkompatibilitet

Den här begränsningen blockerar specifikt alla binärfiler som inte är signerade av Microsoft. Därför är den inte kompatibel med de flesta icke-Microsoft-program, såvida inte programvaran distribueras av (och digitalt signeras av) Microsoft Store, och alternativet för att tillåta inläsning av bilder som signerats av Microsoft Store har valts.

Konfigurationsalternativ

Tillåt även inläsning av avbildningar som signerats av Microsoft Store – Program som distribueras av Microsoft Store signeras digitalt av Microsoft Store, och om du lägger till den här konfigurationen kan binärfiler som går igenom processen för butikscertifiering läsas in av programmet.

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Control Flow Guard (CFG)

Beskrivning

Cfg (Control Flow Guard) minskar risken för angripare som använder sårbarheter för minnesskada genom att skydda indirekta funktionsanrop. En angripare kan till exempel använda en säkerhetsproblem med buffertspill för att skriva över minne som innehåller en funktionspekare och ersätta funktionspekaren med en pekare till valfri körbar kod (som också kan matas in i programmet).

Den här åtgärden tillhandahålls genom att en annan kontroll matas in vid kompileringstillfället. Innan varje indirekt funktionsanrop läggs ytterligare instruktioner till som kontrollerar att målet är ett giltigt anropsmål innan det anropas. Om målet inte är ett giltigt anropsmål avslutas programmet. Därför kan endast program som kompileras med CFG-stöd dra nytta av den här begränsningen.

Kontrollen av ett giltigt mål tillhandahålls av Windows-kerneln. När körbara filer läses in extraheras metadata för indirekta anropsmål vid inläsningen och markeras som giltiga anropsmål. När minne allokeras och markeras som körbart (till exempel för genererad kod) markeras dessutom dessa minnesplatser som giltiga anropsmål för att stödja mekanismer som JIT-kompilering.

Överväganden för bakåtkompatibilitet

Eftersom program måste kompileras för att stödja CFG deklarerar de implicit sin kompatibilitet med den. De flesta program bör därför fungera med den här åtgärden aktiverad. Eftersom dessa kontroller kompileras till binärfilen är konfigurationen du kan tillämpa bara för att inaktivera kontroller i Windows-kerneln. Med andra ord är åtgärden aktiverad som standard, men du kan konfigurera Windows-kerneln så att den alltid returnerar "ja" om du senare fastställer att det finns ett kompatibilitetsproblem som programutvecklaren inte identifierade i testningen, vilket bör vara sällsynt.

Konfigurationsalternativ

Använd strikt CFG: I strikt läge måste alla binärfiler som läses in i processen kompileras för Control Flow Guard (eller ha ingen körbar kod i sig, till exempel resurs-dlls) för att kunna läsas in.

Obs!

Kontrollflödesskyddet har inget granskningsläge. Binärfiler kompileras med den här åtgärden aktiverad.

Dataexekveringsskydd (DEP)

Beskrivning

Datakörningsskydd (DEP) förhindrar att minne som inte uttryckligen allokerats som körbart körs. DEP hjälper till att skydda mot en angripare som matar in skadlig kod i processen, till exempel via ett buffertspill, och sedan kör den koden.

Om du försöker ange instruktionspekaren till en minnesadress som inte är markerad som körbar utlöser processorn ett undantag (överträdelse av allmänt skydd), vilket gör att programmet kraschar.

Överväganden för bakåtkompatibilitet

Alla x64-, ARM- och ARM-64-körbara filer har DEP aktiverat som standard och kan inte inaktiveras. Eftersom ett program inte körs utan DEP förutsätts kompatibilitet.

Alla x86-binärfiler (32-bitars) har DEP aktiverat som standard, men DEP kan inaktiveras per process. Vissa gamla äldre program, vanligtvis program som utvecklats före Windows XP SP2, kanske inte är kompatibla med DEP. Sådana program genererar vanligtvis kod dynamiskt (till exempel JIT-kompilering) eller länkar till äldre bibliotek (till exempel äldre versioner av ATL) som genererar kod dynamiskt.

Konfigurationsalternativ

Aktivera ATL Thunk-emulering: Det här konfigurationsalternativet inaktiverar ATL Thunk-emulering. ATL, ActiveX-mallbiblioteket, är utformat för att vara så litet och snabbt som möjligt. För att minska binärstorlek skulle den använda en teknik som kallas thunking. Thunking är vanligtvis tänkt för att interagera mellan 32-bitars och 16-bitars program, men det finns inga 16-bitarskomponenter till ATL här. För att optimera för binär storlek lagrar ATL i stället maskinkod i minnet som inte är ordjusterad (skapar en mindre binär fil) och anropar sedan koden direkt. ATL-komponenter som kompilerats med Visual Studio 7.1 eller tidigare (Visual Studio 2003) allokerar inte det här minnet som körbart – tonkemulering löser kompatibilitetsproblemet. Program som har en binär tilläggsmodell (till exempel Internet Explorer 11) måste ofta ha ATL Thunk-emulering aktiverat.

Inaktivera tilläggspunkter

Beskrivning

Den här åtgärden inaktiverar olika tilläggspunkter för ett program, som kan användas för att upprätta beständighet eller öka behörigheter för skadligt innehåll.

Detta omfattar följande:

  • AppInit-DLL:er – När en process startar läser systemet in den angivna DLL:en i kontexten för den nyligen startade processen innan den anropar sin startpunktsfunktion. Information om AppInit-DLL:er finns här. När den här begränsningen tillämpas läses inte AppInit-DLL:er in. Från och med Windows 7 måste AppInit-DLL:er signeras digitalt, enligt beskrivningen här. Från och med Windows 8 läses appinit-DLL:er inte in om SecureBoot är aktiverat, enligt beskrivningen här.
  • Äldre snabbmeddelanden – En IME (Input Method Editor) gör det möjligt för en användare att skriva text på ett språk som innehåller fler tecken än vad som kan representeras på ett tangentbord. Tredje part kan skapa snabbmeddelanden. En skadlig IME kan hämta autentiseringsuppgifter eller annan känslig information från den här indatainsamlingen. Vissa snabbmeddelanden, som kallas äldre snabbmeddelanden, fungerar bara i Windows Desktop-appar och inte UWP-appar. Den här åtgärden förhindrar också att den här äldre IME:en läses in i den angivna Windows Desktop-appen.
  • Windows Event Hooks: Ett program kan anropa SetWinEventHook-API :et för att registrera intresse för en händelse som äger rum. En DLL-fil anges och kan matas in i processen. Den här åtgärden tvingar hooken att publiceras i registreringsprocessen i stället för att köras i processen via en inmatad DLL.

Överväganden för bakåtkompatibilitet

De flesta av dessa tilläggspunkter används relativt sällan, så kompatibilitetspåverkan är vanligtvis liten, särskilt på enskild programnivå. Ett övervägande är om användarna använder äldre snabbmeddelanden från tredje part som inte fungerar med det skyddade programmet.

Konfigurationsalternativ

Det finns inga konfigurationsalternativ för den här åtgärden.

Obs!

Inaktivera tilläggspunkter har inget granskningsläge.

Inaktivera Win32k-systemanrop

Beskrivning

Win32k.sys tillhandahåller en bred attackyta för en angripare. Som en komponent i kernelläge är den ofta riktad som en escape-vektor för program som är begränsade. Den här åtgärden förhindrar anrop till win32k.sys genom att blockera en tråd från att konvertera sig själv till en GUI-tråd, som sedan ges åtkomst att anropa Win32k-funktioner. En tråd är icke-GUI när den skapas, men konverteras vid första anropet till win32k.sys eller via ett API-anrop till IsGuiThread.

Överväganden för bakåtkompatibilitet

Den här åtgärden är utformad för processer som är dedikerade icke-UI-processer. Många moderna webbläsare använder till exempel processisolering och införlivar icke-UI-processer. Alla program som visar ett GUI med hjälp av en enda process påverkas av den här begränsningen.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Tillåt inte blockering av underordnade processer

Beskrivning

Den här åtgärden förhindrar att ett program skapar nya underordnade program. En vanlig teknik som används av angripare är att initiera en betrodd process på enheten med skadliga indata (en Levande från landet-attack), som ofta kräver att ett annat program startas på enheten. Om det inte finns några legitima skäl till varför ett program skulle starta en underordnad process, minskar den här begränsningen den potentiella attackvektorn. Åtgärden tillämpas genom att ange en egenskap för processtoken, vilket blockerar skapandet av en token för den underordnade processen med felmeddelandet STATUS_CHILD_PROCESS_BLOCKED.

Överväganden för bakåtkompatibilitet

Om ditt program startar underordnade program av någon anledning, till exempel stöd för hyperlänkar som startar en webbläsare eller en extern webbläsare eller som startar andra verktyg på datorn, bryts den här funktionen med den här begränsningen.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Exportera adressfiltrering

Beskrivning

Exportadressfiltrering (EAF) minskar risken för skadlig kod som tittar på exportadresstabellen för alla inlästa moduler för att hitta moduler som innehåller användbara API:er för attacken. Det här är en vanlig taktik som används av shellcode. För att minska risken för en sådan attack skyddar den här åtgärden tre ofta angripna moduler:

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

Åtgärden skyddar minnessidan i [exportkatalogen som pekar på exportadresstabellen. På den här minnessidan används det PAGE_GUARD skyddet. När någon försöker komma åt det här minnet genereras en STATUS_GUARD_PAGE_VIOLATION. Åtgärden hanterar det här undantaget, och om åtkomstinstruktionen inte godkänns i valideringen avslutas processen.

Överväganden för bakåtkompatibilitet

Den här åtgärden är främst ett problem för program som felsökningsprogram, begränsade program, program som använder DRM eller program som implementerar teknik för felsökning.

Konfigurationsalternativ

Verifiera åtkomst för moduler som ofta missbrukas av sårbarheter: det här alternativet, även kallat EAF+, lägger till skydd för andra ofta angripna moduler:

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

Genom att aktivera EAF+ lägger den här åtgärden dessutom till PAGE_GUARD skydd på sidan som innehåller "MZ"-huvudet, de två första byteen av DOS-huvudet i en PE-fil, vilket är en annan aspekt av känt minnesinnehåll som shellcode kan leta efter för att identifiera moduler som kan vara intressanta för minnet.

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Framtvinga slumpmässighet för bilder (obligatorisk ASLR)

Beskrivning

ASLR (Address Space Layout Randomization) minskar risken för att en angripare använder sin kunskap om systemets minneslayout för att köra kod som redan finns i processminnet och som redan har markerats som körbar. Detta kan minska risken för en angripare med hjälp av tekniker som return-to-libc-attacker, där angriparen anger kontexten och sedan ändrar returadressen för att köra befintlig kod med kontext som passar angriparens syfte.

Obligatorisk ASLR tvingar fram en ombasering av alla DLL-filer i processen. En utvecklare kan aktivera ASLR med alternativet /DYNAMICBASE linker, och den här åtgärden har samma effekt.

När minneshanteraren mappas i avbildningen till processen kommer obligatorisk ASLR med två skäl att återbasera DLL:er och EXE:er som inte har valt ASLR. Observera dock att den här ombaseringen inte har någon entropi och därför kan placeras på en förutsägbar plats i minnet. För ombaserade och slumpmässiga platser för binärfiler bör den här åtgärden kombineras med Randomisera-minnesallokeringar (nerifrån och upp ASLR).

Överväganden för bakåtkompatibilitet

Den här kompatibilitetseffekten av ASLR är vanligtvis begränsad till äldre program som har skapats med kompilatorer som gjorde antaganden om basadressen för en binär fil eller har tagit bort information om basflytt. Detta kan leda till oförutsägbara fel när körningsflödet försöker hoppa till den förväntade, snarare än den faktiska, platsen i minnet.

Konfigurationsalternativ

Tillåt inte avskalade bilder: Det här alternativet blockerar inläsningen av bilder som har tagit bort flyttinformation. Windows PE-filformatet innehåller absoluta adresser, och kompilatorn genererar också en [basflytttabell som inläsaren kan använda för att hitta alla relativa minnesreferenser och deras förskjutning, så att de kan uppdateras om binärfilen inte läses in på önskad basadress. Vissa äldre program tar bort den här informationen i produktionsversioner och därför kan inte dessa binärfiler byggas om. Den här åtgärden blockerar sådana binärfiler från att läsas in (i stället för att tillåta att de läses in på önskad basadress).

Obs!

Framtvinga slumpmässighet för bilder (obligatorisk ASLR) har inget granskningsläge.

Maskinvarubaserat stackskydd

Beskrivning

Maskinvarubaserat stackskydd ger robust skydd mot ROP-kryphål eftersom det upprätthåller en post för det avsedda körningsflödet i ett program. För att säkerställa en smidig implementering av ekosystem och programkompatibilitet erbjuder Windows det här skyddet som en opt-in-modell, så att utvecklare kan få det här skyddet i din egen takt.

Överväganden för bakåtkompatibilitet

Maskinvarustyrt stackskydd fungerar bara på kretsuppsättningar med stöd för maskinvaruskuggastackar, Intels CET (Control-flow Enforcement Technology) eller AMD-skuggstackar.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Defender för Endpoint.

Framtvinga för alla moduler i stället för kompatibla moduler – Du kan aktivera den här begränsningen för att framtvinga för alla moduler i stället för kompatibla moduler.

IAF (Import address filtering)

Beskrivning

Åtgärden för importadressfiltrering (IAF) bidrar till att minska risken för att en angripare ändrar kontrollflödet för ett program genom att ändra importadresstabellen (IAT) för att omdirigera till valfri kod för angriparen när den funktionen anropas. En angripare kan använda den här metoden för att kapa kontroll eller för att fånga upp, inspektera och eventuellt blockera anrop till känsliga API:er.

Minnessidorna för alla skyddade API:er har det PAGE_GUARD skydd som tillämpas på dem. När någon försöker komma åt det här minnet genereras en STATUS_GUARD_PAGE_VIOLATION. Åtgärden hanterar det här undantaget, och om åtkomstinstruktionen inte godkänns i valideringen avslutas processen.

Den här åtgärden skyddar följande Windows-API:er:

  • 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

Överväganden för bakåtkompatibilitet

Legitima program som utför API-avlyssning kan identifieras av den här åtgärden och orsaka att vissa program kraschar. Exempel är shims för säkerhetsprogramvara och programkompatibilitet.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Randomisera minnesallokering (nerifrån och upp ASLR)

Beskrivning

Slumpmässiga minnesallokeringar (ASLR nedifrån och upp) lägger till entropi till flyttningar, så deras plats är slumpmässig och därför mindre förutsägbar. Den här åtgärden kräver att obligatorisk ASLR träder i kraft.

Storleken på 32-bitars adressutrymmet sätter praktiska begränsningar för den entropi som kan läggas till, och därför gör 64-bitarsprogram det svårare för en angripare att gissa en plats i minnet.

Överväganden för bakåtkompatibilitet

De flesta program som är kompatibla med mandatory ASLR (rebasing) är också kompatibla med den andra entropi av ASLR nedifrån och upp. Vissa program kan ha problem med pekartrunkering om de sparar lokala pekare i 32-bitarsvariabler (förväntar sig en basadress under 4 GB) och därför inte är kompatibel med alternativet hög entropi (som kan inaktiveras).

Konfigurationsalternativ

Använd inte hög entropi: det här alternativet inaktiverar användningen av ASLR med hög entropi, vilket lägger till 24 bitar entropi (1 TB varians) i tilldelningen nedifrån och upp för 64-bitarsprogram.

Obs!

Slumpmässiga minnesallokeringar (ASLR nedifrån och upp) har inget granskningsläge.

Simulera körning (SimExec)

Beskrivning

Simulerad körning (SimExec) är endast en åtgärd för 32-bitarsprogram. Detta hjälper dig att verifiera att anrop till känsliga API:er återgår till legitima anroparfunktioner. Den gör detta genom att fånga upp anrop till känsliga API:er och sedan simulera körningen av dessa API:er genom att gå igenom de kodade instruktionerna för sammansättningsspråket och leta efter RET-instruktionen, som bör återgå till anroparen. Den inspekterar sedan den funktionen och går bakåt i minnet för att hitta föregående ANROP-instruktion för att avgöra om funktionen och ANROP-instruktionen matchar och att RET inte har spärrats.

De API:er som fångas upp av den här åtgärden är:

  • 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

Om en ROP-gadget identifieras avslutas processen.

Överväganden för bakåtkompatibilitet

Program som utför API-avlyssning, särskilt säkerhetsprogramvara, kan orsaka kompatibilitetsproblem med den här åtgärden.

Den här åtgärden är inte kompatibel med den godtyckliga Code Guard-åtgärden.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Verifiera API-anrop (CallerCheck)

Beskrivning

Verifiera API-anrop (CallerCheck) är en begränsning för returorienterade programmeringstekniker (ROP) som verifierar att känsliga API:er anropades från en giltig anropare. Den här åtgärden inspekterar den skickade avsändaradressen och demonterar sedan heuristiskt bakåt för att hitta ett anrop ovanför avsändaradressen för att avgöra om anropsmålet matchar parametern som skickas till funktionen.

De API:er som fångas upp av den här åtgärden är:

  • 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

Om en ROP-gadget identifieras avslutas processen.

Överväganden för bakåtkompatibilitet

Program som utför API-avlyssning, särskilt säkerhetsprogramvara, kan orsaka kompatibilitetsproblem med den här åtgärden.

Den här åtgärden är inte kompatibel med den godtyckliga Code Guard-åtgärden.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Verifiera undantagskedjor (SEHOP)

Beskrivning

Verifiera undantagskedjor (SEHOP) är en riskreducering mot SEH-metoden (Structured Exception Handler) som skriver över exploateringstekniken. Strukturerad undantagshantering är den process som ett program kan begära för att hantera ett visst undantag. Undantagshanterare kopplas samman, så om en undantagshanterare väljer att inte hantera ett visst undantag kan den skickas vidare till nästa undantagshanterare i kedjan tills en bestämmer sig för att hantera det. Eftersom listan över hanterare är dynamisk lagras den på stacken. En angripare kan använda ett stackspill för att sedan skriva över undantagshanteraren med en pekare till den kod som angriparen väljer.

Den här begränsningen bygger på seh-designen, där varje SEH-post innehåller både en pekare till undantagshanteraren och en pekare till nästa hanterare i undantagskedjan. Den här åtgärden anropas av undantagsdispatchern, som verifierar SEH-kedjan när ett undantag anropas. Den verifierar att:

  • Alla undantagskedjeposter ligger inom stackgränserna
  • Alla undantagsposter är justerade
  • Inga undantagshanterarpekare pekar på stacken
  • Det finns inga bakåtpekare
  • Undantagskedjan slutar med en känd slutlig undantagshanterare

Om dessa valideringar misslyckas avbryts undantagshanteringen och undantaget hanteras inte.

Överväganden för bakåtkompatibilitet

Kompatibilitetsproblem med SEHOP är relativt sällsynta. Det är ovanligt att ett program använder ett beroende för att skada undantagskedjan. Vissa program påverkas dock av de subtila förändringarna i tidsinställningen, som kan visas som ett konkurrenstillstånd som avslöjar en latent bugg med flera trådar i programmet.

Konfigurationsalternativ

Obs!

Verifiera undantagskedjor (SEHOP) har inget granskningsläge.

Verifiera referensanvändning

Beskrivning

Verifiera referensanvändning är en åtgärd som hjälper till att skydda mot en angripare med hjälp av en befintlig referens för att komma åt ett skyddat objekt. En referens är en referens till ett skyddat objekt. Om programkoden refererar till ett ogiltigt handtag kan det tyda på att en angripare försöker använda en referens som den tidigare har registrerat (men som räknar programreferenser inte skulle känna till). Om programmet försöker använda ett ogiltigt objekt, i stället för att helt enkelt returnera null, genererar programmet ett undantag (STATUS_INVALID_HANDLE).

Den här åtgärden tillämpas automatiskt på Windows Store-program.

Överväganden för bakåtkompatibilitet

Program som inte korrekt spårade hanterar referenser och som inte omsluter dessa åtgärder i undantagshanterare, kommer potentiellt att påverkas av den här begränsningen.

Konfigurationsalternativ

Obs!

Validera referensanvändningen har inget granskningsläge.

Verifiera integritet för heap

Beskrivning

Valideringen av heapintegritetsriskreducering ökar skyddsnivån för heap-åtgärder i Windows, vilket gör att programmet avslutas om en heap skadas. Riskreduceringer inkluderar:

  • Förhindra att en HEAP-referens frigörs
  • Utföra en annan validering på utökade blockrubriker för heapallokeringar
  • Verifiera att heap-allokeringar inte redan har flaggats som använda
  • Lägga till skyddssidor i stora allokeringar, heapsegment och undersegment över en minsta storlek

Överväganden för bakåtkompatibilitet

Den här åtgärden tillämpas redan som standard för 64-bitarsprogram och för 32-bitarsprogram som riktar sig mot Windows Vista eller senare. Äldre program från Windows XP eller tidigare är mest utsatta för risk, men kompatibilitetsproblem är sällsynta.

Konfigurationsalternativ

Obs!

Verifiera heapintegritet har inget granskningsläge.

Verifiera integritet för bildberoende

Beskrivning

Åtgärden validera bildberoende hjälper till att skydda mot attacker som försöker ersätta kod för dll-filer som är statiskt länkade av Windows-binärfiler. Tekniken för DLL-plantering missbrukar inläsarens sökmekanism för att mata in skadlig kod, som kan användas för att få skadlig kod att köras i en upphöjd kontext. När inläsaren läser in en Windows-signerad binärfil och sedan läser in eventuella dll-filer som binärfilen är beroende av verifieras dessa binärfiler för att säkerställa att de också signeras digitalt som en Windows-binär fil. Om signaturkontrollen misslyckas läses dll-filen inte in och ett undantag genereras, vilket returnerar statusen STATUS_INVALID_IMAGE_HASH.

Överväganden för bakåtkompatibilitet

Kompatibilitetsproblem är ovanliga. Program som är beroende av att ersätta Windows-binärfiler med lokala privata versioner påverkas, och det finns också en liten risk för att subtila tidsfel avslöjas i program med flera trådar.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Verifiera stackintegritet (StackPivot)

Beskrivning

Åtgärden verifiera stackintegritet (StackPivot) hjälper till att skydda mot Stack Pivot-attacken, en ROP-attack där en angripare skapar en falsk stack i heapminnet och sedan lurar programmet att återgå till den falska stacken som styr körningsflödet.

Den här åtgärden fångar upp många Windows-API:er och inspekterar stackpekarens värde. Om stackpekarens adress inte hamnar mellan längst ned och överst i stacken registreras en händelse och om den inte är i granskningsläge avslutas processen.

De API:er som fångas upp av den här åtgärden är:

  • 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

Överväganden för bakåtkompatibilitet

Program som använder falska staplar påverkas, och det finns också en liten risk att avslöja subtila tidsfel i flertrådade program. Program som utför API-avlyssning, särskilt säkerhetsprogramvara, kan orsaka kompatibilitetsproblem med den här åtgärden.

Den här åtgärden är inte kompatibel med den godtyckliga Code Guard-åtgärden.

Konfigurationsalternativ

Endast granskning: Du kan aktivera den här åtgärden i granskningsläge för att mäta den potentiella kompatibilitetspåverkan på ett program. Granskningshändelser kan sedan visas antingen i loggboken eller med avancerad jakt i Microsoft Defender för Endpoint.

Tips

Vill du veta mer? Engage med Microsofts säkerhetscommunity i vår Tech Community: Microsoft Defender för Endpoint Tech Community.