Referens för exploateringsskydd

  • Gäller för: Microsoft Defender for Endpoint Plan 1, Microsoft Defender for Endpoint Plan 2

Exploateringsskydd ger avancerat skydd för appar som företagsadministratörer och IT-experter kan tillämpa efter att en utvecklare har kompilerat och distribuerat programvaran.

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 skyddsåtgärder tillämpas

Riskreducering av sårbarhetsskydd tillämpas per program.

Varje program har en egen registerpost som styr vilka skyddsåtgärder som ska tillämpas. De här inställningarna lagras i registerposten MitigationOptions (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). Dessa minskningsinställningar börjar gälla när du startar om programmet. De förblir aktiva tills du ändrar dem och startar om programmet.

Viktigt

Med alternativ för körning av bildfiler kan du bara ange ett filnamn eller en sökväg. Du kan inte ange ett versionsnummer, en arkitektur eller någon annan differentiering. Rikta åtgärder mot appar som har unika namn eller sökvägar. Använd dem endast på enheter där du har testat den versionen och arkitekturen för programmet.

Du kan konfigurera åtgärder via en XML-fil med hjälp av PowerShell, grupprincip eller MDM. När du använder en XML-fil anger systemet registerposterna åt dig.

Återställning av exploitskydd

Viktigt

När grupprincipen eller MDM-principen som distribuerar XML-filen inte längre tillämpas tas inte inställningar som distribueras av 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 Zabezpečenie-baslinjer för återställning av inställningarna för exploateringsskydd.

Om du vill återställa inställningarna för exploateringsskydd med Hjälp av PowerShell kör du följande kommando för att tillämpa återställningsprincipen från XML-filen och återställa minskningsinställningarna till standardinställningarna:

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

Följande XML-fil är den EP-reset.xml som distribueras med Windows Zabezpečenie-baslinjerna. Den här filen definierar åsidosättningar per program som återställer inställningarna för exploateringsskydd till standardinställningarna för vanliga program, till exempel Microsoft Office, webbläsare och mediespelare:

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

Referens för riskreducering

Följande sårbarhetsskyddsreduceringar innehåller var och en en beskrivning, kompatibilitetsöverväganden och konfigurationsalternativ.

Godtycklig kodskydd

I följande avsnitt beskrivs hur godtycklig kodskydd fungerar, dess kompatibilitetspåverkan och dess konfigurationsalternativ.

Beskrivning

Skydd mot godtycklig kodkörning hjälper till att skydda mot att en angripare, via en sårbarhet i minnessäkerheten, laddar in kod som angriparen själv väljer i minnet och kan köra den.

Skydd mot godtycklig kod skyddar ett program från att köra dynamiskt genererad kod (kod som inte har lästs in, till exempel från själva EXE-filen eller en DLL-fil). Skydd mot godtycklig kod innebär att minnet inte kan markeras som körbar. 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 flaggan execute ställs in kan funktionen Datakörningsskydd i Windows 10 och Windows 11 sedan förhindra att instruktionspekaren pekar på det minnet och att den koden körs.

Kompatibilitetsöverväganden

Arbitrary Code Guard förhindrar att minne allokeras som körbart, vilket medför kompatibilitetsproblem med metoder så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 begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Avancerad jakt i Defender for Endpoint.

Blockera bilder med låg integritet

I följande avsnitt beskrivs hur blockering av bilder med låg integritet fungerar, dess kompatibilitetspåverkan och dess konfigurationsalternativ.

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 inläsning av bilder om bilden har en Access Control Entry (ACE) som ger åtkomst till Low IL-processer och som inte har någon trust label-ACE. 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.

Kompatibilitetsöverväganden

Blockera bilder med låg integritet förhindrar att programmet läser in filer som laddats ned från Internet. Om applikationens arbetsflöde kräver att bilder som har hämtats läses in, bör du se till att de hämtas av en process med högre förtroendenivå eller att de uttryckligen märks om för att denna motåtgärd ska kunna tillämpas.

Konfigurationsalternativ

Endast granskning – Du kan aktivera den här begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting i Microsoft Defender för Endpoint.

Blockera fjärrbilder

I följande avsnitt beskrivs hur blockering av fjärrbilder fungerar, dess kompatibilitetspåverkan och dess konfigurationsalternativ.

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 inläsning av bilder om bilden bedöms finnas 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.

Kompatibilitetsöverväganden

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 begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting i Microsoft Defender för Endpoint.

Blockera teckensnitt som inte är betrodda

I följande avsnitt beskrivs hur blockering av ej betrodda teckensnitt fungerar, dess kompatibilitetspåverkan och dess konfigurationsalternativ.

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 skyddsåtgärden implementeras i GDI, som verifierar filens plats. Om filen inte finns i katalogen systemteckensnitt läses teckensnittet inte in för parsning och 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.

Kompatibilitetsöverväganden

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 begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting i Microsoft Defender för Endpoint.

Kodintegritetsskydd

I följande avsnitt beskrivs hur kodintegritetsskydd fungerar, dess kompatibilitetspåverkan och dess konfigurationsalternativ.

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 ladda en binärfil som inte är signerad av Microsoft, returnerar minneshanteraren 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.

Kompatibilitetsöverväganden

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 begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting i Microsoft Defender för Endpoint.

Skydd för kontrollflöde (CFG)

I följande avsnitt beskrivs hur kontrollflödesskydd fungerar, dess kompatibilitetspåverkan och dess konfigurationsalternativ.

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årbarhet för buffertöverskridning för att skriva över ett minnesområde som innehåller en funktionspekare och ersätta den med en pekare till körbar kod som angriparen själv väljer (vilken också kan injiceras i programmet).

Den här åtgärden åstadkoms genom att en annan kontroll infogas vid kompilering. 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.

Kompatibilitetsöverväganden

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ärfilerna kompileras med den här skyddsåtgärden aktiverad.

Dataexekveringsskydd (DEP)

Följande avsnitt beskriver hur dataexekveringsskydd fungerar, dess påverkan på kompatibiliteten och dess konfigurationsalternativ.

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.

Kompatibilitetsöverväganden

Alla x64-, ARM- och Arm64-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 alternativet styr ATL Thunk-emulering. ATL, ActiveX-mallbiblioteket, är utformat för att vara så litet och snabbt som möjligt. För att minska binär storlek använder den en teknik som kallas thunking. Thunking är ofta kopplat till 32-bitars och 16-bitars interaktion, men ATL har inga 16-bitarsdelar. För att spara utrymme lagrar ATL i stället maskinkod i minnet som inte är ordjusterat. Detta skapar en mindre binär fil. ATL kör sedan koden direkt. ATL-versioner som kompilerats med Visual Studio 7.1 eller tidigare (Visual Studio 2003) markerar inte det här minnet som körbart. Thunk-emulering åtgärdar det problemet. Appar med en modell för binärt tillägg (till exempel Internet Explorer 11) behöver ATL Thunk-emulering aktiverad.

Inaktivera tilläggspunkter

I följande avsnitt beskrivs hur åtgärden för att inaktivera tilläggspunkter fungerar, hur kompatibiliteten påverkas och vilka konfigurationsalternativ som finns.

Beskrivning

Säkerhetsåtgärden Inaktivera tilläggspunkter inaktiverar olika tilläggspunkter för en applikation, vilka kan användas för att upprätta persistens eller eskalera privilegier 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 inmatningsmetoder – En Input Method Editor (IME) 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 återges 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å kompatibilitetseffekten är vanligtvis liten, särskilt på individuell programnivå. Det enda att tänka på är om användarna använder äldre IME:er från andra än Microsoft som inte fungerar med den skyddade appen.

Konfigurationsalternativ

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

Obs!

Inaktivera utökningspunkter har inget granskningsläge.

Inaktivera Win32k-systemanrop

I följande avsnitt beskrivs hur riskreduceringen för att inaktivera Win32k-systemanrop fungerar, dess kompatibilitetseffekter och dess konfigurationsalternativ.

Beskrivning

Win32k.sys tillhandahåller en bred attackyta för en angripare. Som en komponent på kärnnivå är den ofta ett mål som angreppsväg för program som körs i en sandlåda. 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.

Kompatibilitetsöverväganden

Den här åtgärden är avsedd för processer som är särskilt avsedda att köras utan användargränssnitt. Många moderna webbläsare använder till exempel processisolering och införlivar icke-UI-processer. Alla program som visar ett grafiskt användargränssnitt med hjälp av en enda process påverkas av den här begränsningen.

Konfigurationsalternativ

Endast granskning – Du kan aktivera den här begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting i Microsoft Defender för Endpoint.

Tillåt inte blockering av underordnade processer

I följande avsnitt beskrivs hur skyddsåtgärden ”Tillåt inte underordnade processer” fungerar, dess påverkan på kompatibiliteten och dess konfigurationsalternativ.

Beskrivning

Begränsningen Tillåt inte underprocesser hindrar en applikation från att skapa nya underapplikationer. En vanlig teknik som används av angripare är att starta en betrodd process på enheten med skadlig indata (en "living off the land"-attack), vilket ofta kräver att man startar ett annat program på enheten. Om det inte finns några legitima skäl till att en applikation skulle starta en underprocess, motverkar den här åtgärden den potentiella attackvektorn. Skyddsåtgärden tillämpas genom att ange en egenskap på processtoken, vilket förhindrar att en token skapas för underprocessen med felmeddelandet STATUS_CHILD_PROCESS_BLOCKED.

Kompatibilitetsöverväganden

Om ditt program av någon anledning startar andra program, till exempel via hyperlänkar som öppnar en webbläsare eller en extern webbläsare, eller startar andra verktyg på datorn, slutar den här funktionen att fungera när den här skyddsåtgärden används.

Konfigurationsalternativ

Endast granskning – Du kan aktivera den här begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan därefter visas antingen i Loggboken eller med Advanced Hunting i Microsoft Defender för Endpoint.

Export av adressfiltrering

I följande avsnitt beskrivs hur exportadressfiltrering fungerar, dess kompatibilitetspåverkan och dess konfigurationsalternativ.

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 har skyddet PAGE_GUARD tillämpats. När någon försöker komma åt detta minne genereras en STATUS_GUARD_PAGE_VIOLATION. Motåtgärden hanterar det här undantaget, och om instruktionen som försöker få åtkomst inte klarar valideringen avslutas processen.

Kompatibilitetsöverväganden

Denna åtgärd påverkar främst program som felsökare, sandboxade program, program som använder DRM eller program som implementerar teknik för att försvåra 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

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

Endast granskning – Du kan aktivera den här begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan därefter visas antingen i Loggboken eller med Advanced Hunting i Microsoft Defender för Endpoint.

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

I följande avsnitt beskrivs hur obligatorisk ASLR fungerar, dess kompatibilitetspåverkan och dess konfigurationsalternativ.

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 länkaralternativet /DYNAMICBASE, och den här skyddsåtgärden har samma effekt.

När minneshanteraren mappar in avbildningen i processen kommer obligatorisk ASLR att framtvinga en ombasering av DLL-filer och EXE-filer som inte har aktiverat 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ässigt placerade binärfiler bör denna åtgärd paras ihop med Randomisera minnesallokeringar (ASLR nedifrån och upp).

Kompatibilitetsöverväganden

Den här kompatibilitetseffekten av ASLR är vanligtvis begränsad till äldre program som har skapats med kompilatorer som har gjort 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 exekveringsflödet försöker hoppa till den förväntade, snarare än den faktiska, plats i minnet.

Konfigurationsalternativ

Tillåt inte avskalade bilder – Det här alternativet blockerar inläsningen av bilder som har flyttinformation borttagen. 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-sårbarheter. Det fungerar genom att registrera det avsedda körningsflödet för ett program. För att underlätta smidig implementering och appkompatibilitet erbjuder Windows det här skyddet som en opt-in-modell. Utvecklare kan aktivera det i sin egen takt.

Kompatibilitetsöverväganden

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

Om du kör program baserat på .NET Framework fungerar maskinvarubaserat stackskydd med .NET Framework 7 (anmäl dig) eller senare. Om du använder en äldre version kan det uppstå krascher eller hög CPU-användning. Dessa problem kan också uppstå i revisionsläge eller när endast kompatibla moduler används som mål.

Konfigurationsalternativ

Endast granskning – Du kan aktivera den här begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Avancerad jakt i Defender for Endpoint.

Tillämpa för alla moduler i stället för endast kompatibla moduler – Du kan aktivera den här skyddsåtgärden så att den tillämpas på alla moduler i stället för endast kompatibla moduler.

Importadressfiltrering (IAF)

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 detta minne genereras en STATUS_GUARD_PAGE_VIOLATION. Motåtgärden hanterar det här undantaget, och om instruktionen som försöker få åtkomst inte klarar 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

Kompatibilitetsöverväganden

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

Konfigurationsalternativ

Endast granskning – Du kan aktivera den här begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting 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 börjar gälla.

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 kring kompatibilitet

De flesta appar som fungerar med obligatorisk ASLR (ombasering) fungerar också med ASLR nedifrån och upp. Vissa appar kan ha problem med trunkering av pekare om de sparar lokala pekare i 32-bitarsvariabler. Dessa appar förväntar sig en basadress under 4 GB, så de fungerar inte med alternativet hög entropi. Du kan inaktivera hög entropi om det behövs.

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

Simulera körning (SimExec) är en skyddsåtgärd endast för 32-bitarsapplikationer. 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.

Kompatibilitetsöverväganden

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

Den här skyddsåtgärden är inte kompatibel med skyddsåtgärden Arbitrary Code Guard.

Konfigurationsalternativ

Endast granskning – Du kan aktivera den här begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting 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 angivna returadressen och disassemblerar sedan heuristiskt bakåt för att hitta ett anrop ovanför returadressen och 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.

Kompatibilitetsöverväganden

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

Den här skyddsåtgärden är inte kompatibel med skyddsåtgärden Arbitrary Code Guard.

Konfigurationsalternativ

Endast granskning – Du kan aktivera den här begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting i Microsoft Defender för Endpoint.

Validera undantagskedjor (SEHOP)

Beskrivning

Validering av undantagskedjor (SEHOP) är en skyddsåtgärd mot exploateringstekniken överskrivning av Structured Exception Handler (SEH). 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 en stacköversvämningssårbarhet för att sedan skriva över undantagshanteraren med en pekare till kod som angriparen själv 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 begränsningsåtgärden anropas av undantagshanteraren, som validerar SEH-kedjan när ett undantag utlöses. Den verifierar att:

  • Alla poster i undantagskedjan 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.

Kompatibilitetsöverväganden

Kompatibilitetsproblem med SEHOP är relativt sällsynta. Det är ovanligt att ett program är beroende av att förvanska undantagskedjan. Vissa applikationer påverkas dock av subtila förändringar i timingen, vilket kan yttra sig som ett kapplöpningstillstånd som blottlägger ett latent flertrådningsfel i applikationen.

Konfigurationsalternativ

Obs!

Verifiera undantagskedjor (SEHOP) har inget granskningsläge.

Validera referensanvändning

Beskrivning

Verifiera användning av handtag är en skyddsåtgärd som hjälper till att skydda mot att en angripare använder ett befintligt handtag för att få åtkomst till ett skyddat objekt. Ett handtag är en referens till ett skyddat objekt. Om programkoden refererar till ett ogiltigt handle kan det tyda på att en angripare försöker använda ett handle som den tidigare har sparat, men som programmets referensräkning inte känner 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 skyddsåtgärden tillämpas automatiskt på appar från Windows Store.

Kompatibilitetsöverväganden

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 handtagsanvändning saknar granskningsläge.

Verifiera integritet för heap

Beskrivning

Riskreduceringen verifiera heapens integritet ökar skyddsnivån för skyddsåtgärder för heapen i Windows genom att programmet avslutas om korruption i heapen upptäcks. Riskreduceringer inkluderar:

  • Förhindra att ett HEAP-handtag frigörs
  • Utförande av ytterligare en validering av utökade blockhuvuden för heapallokeringar
  • Kontrollera att heap-allokeringar inte redan är markerade som använda
  • Tillägg av skyddssidor i stora allokeringar, heapsegment och undersegment över en viss minsta storlek

Kompatibilitetsöverväganden

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!

Kontrollera heapens integritet har inget granskningsläge.

Verifiera integriteten för bildberoenden

Beskrivning

Åtgärden validering av bildberoenden hjälper till att skydda mot attacker som försöker ersätta DLL-filer som Windows-binärfiler är statiskt länkade till med kod. 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 inte dll-filen in och ett undantag genereras, vilket returnerar statusen STATUS_INVALID_IMAGE_HASH.

Kompatibilitetsöverväganden

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 begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting 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

Kompatibilitetsöverväganden

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

Den här skyddsåtgärden är inte kompatibel med skyddsåtgärden Arbitrary Code Guard.

Konfigurationsalternativ

Endast granskning – Du kan aktivera den här begränsningen i granskningsläge för att mäta den potentiella kompatibiliteten som påverkar ett program. Granskningshändelser kan sedan visas antingen i Loggboken eller med Advanced hunting i Microsoft Defender för Endpoint.

  • Last updated on