Condividi tramite


Riferimento protezione dagli exploit

Si applica a:

Se si desidera provare Microsoft Defender per endpoint, iscriversi a una versione di valutazione gratuita.

La protezione dagli exploit offre protezioni avanzate per le applicazioni che gli amministratori aziendali e i professionisti IT possono applicare dopo che uno sviluppatore ha compilato e distribuito il software.

Questo articolo consente di comprendere il funzionamento della protezione dagli exploit, sia a livello di criteri che a livello di mitigazione individuale, per semplificare la compilazione e l'applicazione dei criteri di protezione dagli exploit.

Modalità di applicazione delle mitigazioni

Le mitigazioni della protezione dagli exploit vengono applicate per ogni applicazione.

Le mitigazioni vengono configurate tramite una voce del registro di sistema per ogni programma per cui si configurano le protezioni. Queste impostazioni vengono archiviate nella voce del Registro di sistema MitigationOptions per ogni programma (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). Diventano effettive quando si riavvia il programma e rimangono valide fino a quando non vengono modificate e riavviate nuovamente il programma.

Importante

Le opzioni di esecuzione dei file di immagine consentono solo di specificare un nome file o un percorso e non un numero di versione, un'architettura o qualsiasi altro elemento di differenziazione. Prestare attenzione a indirizzare le mitigazioni alle app con nomi o percorsi univoci, applicandole solo nei dispositivi in cui è stata testata la versione e l'architettura dell'applicazione.

Se si configurano mitigazioni di protezione dagli exploit usando un file di configurazione XML usando PowerShell, Criteri di gruppo o MDM, durante l'elaborazione di questo file di configurazione XML, vengono configurate automaticamente le singole impostazioni del Registro di sistema.

Reimpostazione della protezione dagli exploit

Importante

Quando i criteri che distribuiscono il file XML non vengono più applicati, le impostazioni distribuite da questo file di configurazione XML non verranno rimosse automaticamente.

Per rimuovere le impostazioni di protezione dagli exploit, esportare la configurazione XML da un dispositivo Windows 10 o Windows 11 pulito e distribuire questo nuovo file XML. In alternativa, Microsoft fornisce un file XML come parte delle baseline di Sicurezza di Windows per la reimpostazione delle impostazioni di protezione dagli exploit.

Per reimpostare le impostazioni di protezione dagli exploit tramite PowerShell, usare il comando seguente:

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

Di seguito è riportato il file EP-reset.xml distribuito con le linee di base relative alla sicurezza di Windows:

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

Informazioni di riferimento sulla mitigazione

Le sezioni seguenti illustrano in dettaglio le protezioni fornite da ogni mitigazione della protezione dagli exploit, le considerazioni sulla compatibilità per la mitigazione e le opzioni di configurazione disponibili.

Code guard arbitrario

Descrizione

La protezione arbitraria dal codice consente di proteggersi da un utente malintenzionato che carica il codice di propria scelta in memoria tramite una vulnerabilità di sicurezza della memoria ed è in grado di eseguire tale codice.

Il code guard arbitrario protegge un'applicazione dall'esecuzione di codice generato dinamicamente (codice non caricato, ad esempio, dall'exe stesso o da una DLL). Il code guard arbitrario funziona impedendo che la memoria venga contrassegnata come eseguibile. Quando un'applicazione tenta di allocare memoria, controlliamo i flag di protezione. La memoria può essere allocata con flag di protezione di lettura, scrittura e/o esecuzione. Se l'allocazione tenta di includere il flag di protezione dell'esecuzione, l'allocazione della memoria ha esito negativo e restituisce un codice di errore (STATUS_DYNAMIC_CODE_BLOCKED). Analogamente, se un'applicazione tenta di modificare i flag di protezione della memoria già allocati e include il flag di protezione dell'esecuzione, la modifica dell'autorizzazione ha esito negativo e restituisce un codice di errore (STATUS_DYNAMIC_CODE_BLOCKED).

Impedendo l'impostazione del flag di esecuzione, la funzionalità di prevenzione dell'esecuzione dei dati di Windows 10 e Windows 11 può quindi proteggere dall’impostazione del puntatore all'istruzione su tale memoria ed eseguire il codice.

Considerazioni sulla compatibilità

Il code guard arbitrario impedisce l'allocazione di memoria come eseguibile, il che presenta un problema di compatibilità con approcci come i compilatori JIT (Just-in-Time). La maggior parte dei browser moderni, ad esempio, compila JavaScript in codice nativo per ottimizzare le prestazioni. Per supportare questa mitigazione, è necessario riprogettarla per spostare la compilazione JIT all'esterno del processo protetto. Altre applicazioni la cui progettazione genera dinamicamente codice da script o altri linguaggi intermedi sono incompatibili con questa mitigazione.

Opzioni di configurazione

Consenti rifiuto esplicito del thread: è possibile configurare la mitigazione per consentire a un singolo thread di rifiutare esplicitamente questa protezione. Lo sviluppatore deve scrivere l'applicazione con consapevolezza di questa mitigazione e chiamare l'API SetThreadInformation con il parametro ThreadInformation impostato su ThreadDynamicCodePolicy per poter eseguire codice dinamico in questo thread.

Solo audit: è possibile abilitare questa mitigazione in modalità di controllo per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando la rilevazione avanzata in Defender per endpoint.

Blocca immagini con bassa integrità

Descrizione

Blocca immagini a bassa integrità impedisce all'applicazione di caricare file non attendibili, in genere perché sono stati scaricati da Internet da un browser sandbox.

Questa mitigazione blocca il caricamento dell'immagine se l'immagine ha una voce di Controllo di accesso (ACE) che concede l'accesso ai processi Low IL e che non ha un'etichetta di attendibilità ACE. Viene implementato dalla gestione memoria, che impedisce il mapping del file in memoria. Se un'applicazione tenta di eseguire il mapping di un'immagine con integrità bassa, viene generato un errore di STATUS_ACCESS_DENIED. Per informazioni dettagliate sul lavoro relativo ai livelli di integrità, vedere Controllo di integrità obbligatorio.

Considerazioni sulla compatibilità

Blocca immagini a bassa integrità che impediscono all'applicazione di caricare i file scaricati da Internet. Se il flusso di lavoro dell'applicazione richiede il caricamento di immagini scaricate, è necessario assicurarsi che vengano scaricate da un processo con attendibilità superiore o che vengano etichettate in modo esplicito per applicare questa mitigazione.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Blocca immagini remote

Descrizione

Il blocco delle immagini remote consente di impedire all'applicazione di caricare file ospitati in un dispositivo remoto, ad esempio una condivisione UNC. Il blocco delle immagini remote consente di proteggersi dal caricamento di file binari in memoria che si trovano in un dispositivo esterno controllato dall'utente malintenzionato.

Questa mitigazione blocca il caricamento dell'immagine se l'immagine è determinata in un dispositivo remoto. Viene implementato dalla gestione memoria, che impedisce il mapping del file in memoria. Se un'applicazione tenta di eseguire il mapping di un file remoto, viene generato un errore di STATUS_ACCESS_DENIED.

Considerazioni sulla compatibilità

Blocca immagini remote impedisce all'applicazione di caricare immagini da dispositivi remoti. Se l'applicazione carica file o plug-in da dispositivi remoti, non sarà compatibile con questa mitigazione.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Blocca i tipi di carattere non attendibili

Descrizione

Blocca i tipi di carattere non attendibili e riduce il rischio di un difetto nell'analisi dei tipi di carattere che porta l'utente malintenzionato a eseguire il codice nel dispositivo. Solo i tipi di carattere installati nella directory windows\fonts verranno caricati per l'elaborazione da parte di GDI.

Questa mitigazione viene implementata all'interno di GDI, che convalida il percorso del file. Se il file non si trova nella directory dei tipi di carattere di sistema, il tipo di carattere non verrà caricato per l'analisi e la chiamata avrà esito negativo.

Questa mitigazione si aggiunge alla mitigazione predefinita fornita in Windows 10 1607 e versioni successive e Windows 11, che sposta l'analisi dei caratteri dal kernel e in un contenitore di app in modalità utente. Qualsiasi exploit basato sull'analisi dei tipi di carattere, di conseguenza, si verifica in un contesto in modalità sandbox e isolato, riducendo in modo significativo il rischio. Per informazioni dettagliate su questa mitigazione, vedere il blog Protezione avanzata Windows 10 con mitigazioni degli exploit zero-day.

Considerazioni sulla compatibilità

L'uso più comune dei tipi di carattere all'esterno della directory dei tipi di carattere di sistema è con i tipi di carattere Web. I browser moderni, ad esempio Microsoft Edge, usano DirectWrite anziché GDI e non sono interessati. Tuttavia, i browser legacy, ad esempio Internet Explorer 11 (e la modalità IE nel nuovo Microsoft Edge) possono essere interessati, in particolare con applicazioni come Office 365, che usano glifi dei tipi di carattere per visualizzare l'interfaccia utente.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Controllo integrità codice

Descrizione

La protezione dell’integrità del codice garantisce che tutti i file binari caricati in un processo siano firmati digitalmente da Microsoft. La protezione dell'integrità del codice include firme WHQL (Windows Hardware Quality Labs), che consentono l'esecuzione dei driver approvati da WHQL all'interno del processo.

Questa mitigazione viene implementata nell’ambito della gestione memoria, che impedisce il mapping del file binario nella memoria. Se si tenta di caricare un file binario non firmato da Microsoft, la gestione della memoria restituisce l'errore STATUS_INVALID_IMAGE_HASH. Eseguendo il blocco a livello di gestione della memoria, si impediscono sia i file binari caricati dal processo che i file binari inseriti nel processo.

Considerazioni sulla compatibilità

Questa mitigazione blocca in modo specifico qualsiasi file binario non firmato da Microsoft. Di conseguenza, è incompatibile con la maggior parte del software non Microsoft, a meno che tale software non sia distribuito da (e firmato digitalmente da) Microsoft Store e sia selezionata l'opzione per consentire il caricamento delle immagini firmate da Microsoft Store.

Opzioni di configurazione

Consenti anche il caricamento di immagini firmate da Microsoft Store : le applicazioni distribuite da Microsoft Store sono firmate digitalmente da Microsoft Store e l'aggiunta di questa configurazione consente il caricamento da parte dell'applicazione dei file binari che passano attraverso il processo di certificazione dello store.

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Protezione del flusso di controllo (CFG)

Descrizione

La protezione del flusso di controllo (CFG) riduce il rischio di utenti malintenzionati che usano vulnerabilità di danneggiamento della memoria proteggendo le chiamate di funzione indiretta. Ad esempio, un utente malintenzionato potrebbe usare una vulnerabilità di overflow del buffer per sovrascrivere la memoria contenente un puntatore a funzione e sostituire tale puntatore a funzione con un puntatore al codice eseguibile di propria scelta (che potrebbe anche essere inserito nel programma).

Questa mitigazione viene fornita inserendo un altro controllo in fase di compilazione. Prima di ogni chiamata di funzione indiretta, vengono aggiunte altre istruzioni che verificano che la destinazione sia una destinazione di chiamata valida prima che venga chiamata. Se la destinazione non è una destinazione di chiamata valida, l'applicazione viene terminata. Di conseguenza, solo le applicazioni compilate con il supporto CFG possono trarre vantaggio da questa mitigazione.

Il controllo di una destinazione valida viene fornito dal kernel di Windows. Quando vengono caricati i file eseguibili, i metadati per le destinazioni di chiamata indiretta vengono estratti in fase di caricamento e contrassegnati come destinazioni di chiamata valide. Inoltre, quando la memoria viene allocata e contrassegnata come eseguibile (ad esempio per il codice generato), queste posizioni di memoria vengono contrassegnate anche come destinazioni di chiamata valide, per supportare meccanismi come la compilazione JIT.

Considerazioni sulla compatibilità

Poiché le applicazioni devono essere compilate per supportare CFG, dichiarano implicitamente la compatibilità con essa. La maggior parte delle applicazioni, pertanto, deve funzionare con questa mitigazione abilitata. Poiché questi controlli vengono compilati nel file binario, la configurazione che è possibile applicare consiste semplicemente nel disabilitare i controlli all'interno del kernel di Windows. In altre parole, la mitigazione è attivata per impostazione predefinita, ma è possibile configurare il kernel windows in modo che restituisca sempre "sì" se in seguito si determina che si è verificato un problema di compatibilità che lo sviluppatore dell'applicazione non ha individuato nei test, il che dovrebbe essere raro.

Opzioni di configurazione

Usa strict CFG: in modalità strict, tutti i file binari caricati nel processo devono essere compilati per Control Flow Guard (o non contengono codice eseguibile, ad esempio dll di risorse) per poter essere caricati.

Nota

La protezione del flusso di controllo non presenta modalità di audit. I file binari vengono compilati con questa mitigazione abilitata.

Protezione esecuzione programmi (DEP)

Descrizione

La prevenzione dell'esecuzione dei dati impedisce l'esecuzione di memoria non allocata in modo esplicito come eseguibile. La DEP consente di proteggersi da un utente malintenzionato che inserisce un codice dannoso nel processo, ad esempio tramite un overflow del buffer, e quindi l'esecuzione di tale codice.

Se si tenta di impostare il puntatore dell'istruzione su un indirizzo di memoria non contrassegnato come eseguibile, il processore genera un'eccezione (violazione della protezione generale), causando l'arresto anomalo dell'applicazione.

Considerazioni sulla compatibilità

Tutti i file eseguibili x64, ARM e ARM-64 hanno DEP abilitato per impostazione predefinita e non possono essere disabilitati. Poiché un'applicazione non viene eseguita senza DEP, si presuppone la compatibilità.

Tutti i file binari x86 (32 bit) presentano la DEP abilitata per impostazione predefinita, ma la DEP può essere disabilitata per processo. Alcune applicazioni legacy precedenti, in genere applicazioni sviluppate prima di Windows XP SP2, potrebbero non essere compatibili con la DEP. Tali applicazioni generano in genere il codice in modo dinamico (ad esempio, la compilazione JIT) o il collegamento a librerie meno recenti (ad esempio le versioni precedenti di ATL) che generano dinamicamente il codice.

Opzioni di configurazione

Abilitare l'emulazione Thunk ATL: questa opzione di configurazione disabilita l'emulazione Thunk ATL. ATL, la libreria di modelli ActiveX, è progettata per essere quanto più piccola e veloce possibile. Per ridurre le dimensioni binarie, viene usata una tecnica denominata thunking. Il thunking è in genere pensato per interagire tra applicazioni a 32 bit e a 16 bit, ma non sono presenti componenti a 16 bit per ATL. Piuttosto, per ottimizzare le dimensioni binarie, ATL archivia il codice del computer in memoria che non è allineato alle parole (creando un file binario più piccolo) e quindi richiama direttamente il codice. I componenti ATL compilati con Visual Studio 7.1 o versioni precedenti (Visual Studio 2003) non allocano questa memoria come eseguibile. L'emulazione thunk risolve questo problema di compatibilità. Per le applicazioni con un modello di estensione binario (ad esempio Internet Explorer 11) sarà spesso necessario abilitare l'emulazione Thunk ATL.

Disabilita i punti di estensione

Descrizione

Questa mitigazione disabilita vari punti di estensione per un'applicazione, che possono essere usati per stabilire la persistenza o elevare i privilegi di contenuto dannoso.

Tra questi vi sono anche:

  • DLL AppInit : ogni volta che viene avviato un processo, il sistema carica la DLL specificata nel contesto del processo appena avviato prima di chiamare la funzione del punto di ingresso. I dettagli sulle DLL AppInit sono disponibili qui. Con questa mitigazione applicata, le DLL AppInit non vengono caricate. A partire da Windows 7, le DLL AppInit devono essere firmate digitalmente, come descritto qui. Inoltre, a partire da Windows 8, le DLL AppInit non verranno caricate se SecureBoot è abilitato, come descritto qui.
  • IME legacy: un IME (Input Method Editor) consente a un utente di digitare testo in una lingua con più caratteri di quanti possano essere rappresentati su una tastiera. Le terze parti possono creare IME. Un IME dannoso potrebbe ottenere credenziali o altre informazioni riservate da questa acquisizione di input. Alcuni IME, detti IME legacy, funzionano solo nelle app desktop di Windows e non nelle app UWP. Questa mitigazione impedisce anche il caricamento di questo IME legacy nell'app desktop di Windows specificata.
  • Hook di eventi di Windows: un'applicazione può chiamare l'API SetWinEventHook per registrare l'interesse per un evento in corso. Viene specificata una DLL che può essere inserita nel processo. Questa mitigazione impone l'inserimento dell'hook nel processo di registrazione anziché l'esecuzione in-process tramite una DLL inserita.

Considerazioni sulla compatibilità

La maggior parte di questi punti di estensione viene usata relativamente raramente, quindi l'impatto sulla compatibilità è in genere ridotto, in particolare a livello di singola applicazione. L'unica considerazione è se gli utenti usano IME legacy di terze parti che non funzionano con l'applicazione protetta.

Opzioni di configurazione

Non sono disponibili opzioni di configurazione per questa mitigazione.

Nota

La disabilitazione dei punti di estensione non presenta modalità di audit.

Disabilita le chiamate di sistema Win32k

Descrizione

Win32k.sys offre un'ampia superficie di attacco per un utente malintenzionato. Come componente in modalità kernel, è spesso destinato come vettore di escape per le applicazioni in modalità sandbox. Questa mitigazione impedisce le chiamate in win32k.sys bloccando la conversione di un thread in un thread GUI, a cui viene quindi concesso l'accesso per richiamare le funzioni Win32k. Un thread non è GUI quando viene creato, ma convertito alla prima chiamata a win32k.sys o tramite una chiamata API a IsGuiThread.

Considerazioni sulla compatibilità

Questa mitigazione è progettata per i processi dedicati non dell'interfaccia utente. Ad esempio, molti browser moderni usano l'isolamento dei processi e incorporano processi non dell'interfaccia utente. Qualsiasi applicazione che visualizza un'interfaccia utente grafica usando un singolo processo sarà interessata da questa mitigazione.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Non consente i processi figlio

Descrizione

Questa mitigazione impedisce a un'applicazione di creare nuove applicazioni secondarie. Una tecnica comune usata dagli avversari consiste nell'avviare un processo attendibile nel dispositivo con input dannoso (un attacco "allo scoperto"), che spesso richiede l'avvio di un'altra applicazione nel dispositivo. Se non esistono motivi legittimi per cui un'applicazione avvia un processo secondario, questa mitigazione riduce il potenziale vettore di attacco. La mitigazione viene applicata impostando una proprietà sul token del processo, che blocca la creazione di un token per il processo secondario con il messaggio di errore STATUS_CHILD_PROCESS_BLOCKED.

Considerazioni sulla compatibilità

Se l'applicazione avvia applicazioni figlio per qualsiasi motivo, ad esempio il supporto di collegamenti ipertestuali che avviano un browser o un browser esterno o che avviano altre utilità nel computer, questa funzionalità viene interrotta con questa mitigazione applicata.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Filtro di indirizzi da esportare

Descrizione

Il filtro degli indirizzi di esportazione (EAF) riduce il rischio che codice dannoso esamini la tabella degli indirizzi di esportazione di tutti i moduli caricati per trovare moduli che contengono API utili per il loro attacco. Si tratta di una strategia comune usata da shellcode. Per attenuare il rischio di un attacco di questo tipo, questa mitigazione protegge tre moduli di attacchi comuni:

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

La mitigazione protegge la pagina di memoria nella [directory di esportazione che punta alla tabella degli indirizzi di esportazione. A questa pagina di memoria è applicata la protezione PAGE_GUARD . Quando qualcuno tenta di accedere a questa memoria, genera un STATUS_GUARD_PAGE_VIOLATION. La mitigazione gestisce questa eccezione e, se l'istruzione di accesso non supera la convalida, il processo viene terminato.

Considerazioni sulla compatibilità

Questa mitigazione è principalmente un problema per applicazioni come debugger, applicazioni in modalità sandbox, applicazioni che usano DRM o applicazioni che implementano la tecnologia anti-debug.

Opzioni di configurazione

Convalidare l'accesso per i moduli comunemente usati in modo improprio dagli exploit: questa opzione, nota anche come EAF+, aggiunge protezioni per altri moduli comunemente attaccati:

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

Inoltre, abilitando EAF+, questa mitigazione aggiunge la protezione PAGE_GUARD alla pagina contenente l'intestazione "MZ", i primi due byte dell'intestazione DOS in un file PE, un altro aspetto del contenuto di memoria noto che il codice shell può cercare per identificare i moduli potenzialmente di interesse in memoria.

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Forza l'assegnazione casuale per le immagini (ASLR obbligatorio)

Descrizione

L’ASLR (Address Space Layout Randomization) riduce il rischio che un utente malintenzionato agisca grazie alla conoscenza del layout di memoria del sistema per eseguire codice già presente nella memoria del processo e già contrassegnato come eseguibile. Ciò può ridurre il rischio che un utente malintenzionato agisca usando tecniche come gli attacchi return-to-libc, in cui l'antagonista imposta il contesto e quindi modifica l'indirizzo mittente per eseguire il codice esistente con il contesto più adatto allo scopo dell'antagonista.

L’ASLR obbligatoria forza una riassegnazione di tutte le DLL all'interno del processo. Uno sviluppatore può abilitare l’ASLR usando l'opzione del linker /DYNAMICBASE e questa mitigazione ha lo stesso effetto.

Quando la gestione memoria esegue il mapping nell'immagine nel processo, l'ISTANZA ASLR obbligatoria ribaserà forzatamente DLL ed ESE che non hanno acconsentito esplicitamente all'ASLR. Si noti, tuttavia, che questa riassegnazione non ha entropia e può quindi essere posizionata in una posizione prevedibile in memoria. Per la posizione riassegnata e casuale dei file binari, questa mitigazione deve essere abbinata alle allocazioni di memoria casuali (ASLR bottom-up).

Considerazioni sulla compatibilità

Questo impatto sulla compatibilità di ASLR è in genere limitato alle applicazioni meno recenti compilate usando compilatori che presupponevano l'indirizzo di base di un file binario o che hanno rimosso le informazioni sulla rilocazione di base. Ciò può causare errori imprevedibili quando il flusso di esecuzione tenta di passare alla posizione prevista, anziché quella effettiva, in memoria.

Opzioni di configurazione

Non consentire le immagini rimosse: questa opzione blocca il caricamento di immagini con informazioni di rilocazione rimosse. Il formato di file Windows PE contiene indirizzi assoluti e il compilatore genera anche una [tabella di rilocazione di base che il caricatore può usare per trovare tutti i riferimenti di memoria relativi e il relativo offset, in modo che possano essere aggiornati se il file binario non viene caricato nel relativo indirizzo di base preferito. Alcune applicazioni meno recenti eliminano queste informazioni nelle build di produzione e pertanto questi file binari non possono essere ribaseati. Questa mitigazione impedisce il caricamento di tali file binari anziché consentire il caricamento all'indirizzo di base preferito.

Nota

La randomizzazione forzata per le immagini (ASLR obbligatoria) non ha modalità di audit.

Protezione dello stack applicata dall'hardware

Descrizione

La protezione dello stack applicata dall'hardware offre una protezione affidabile dagli exploit ROP poiché mantiene un record del flusso di esecuzione previsto di un programma. Per garantire un'adozione uniforme dell'ecosistema e la compatibilità delle applicazioni, Windows offre questa protezione come modello di consenso esplicito, in modo che gli sviluppatori possano ricevere questa protezione al proprio ritmo.

Considerazioni sulla compatibilità

La protezione dello stack applicata dall'hardware funziona solo su chipset con supporto per stack di shadow hardware, tecnologia di imposizione del flusso di controllo (CET) di Intel o stack di shadow AMD.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di controllo per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando la rilevazione avanzata in Defender per endpoint.

Imponi per tutti i moduli anziché per i moduli compatibili : è possibile abilitare questa mitigazione per Applicare per tutti i moduli anziché per i moduli compatibili.

Filtro di indirizzi da importare (IAF)

Descrizione

La mitigazione del filtro degli indirizzi di importazione (IAF) consente di ridurre il rischio che un antagonista cambi il flusso di controllo di un'applicazione modificando la tabella degli indirizzi di importazione (IAT) per reindirizzare al codice arbitrario scelto dall'utente malintenzionato quando viene chiamata tale funzione. Un utente malintenzionato può usare questo approccio per il controllo di hijack o per intercettare, ispezionare e potenzialmente bloccare le chiamate alle API sensibili.

Alle pagine di memoria per tutte le API protette è applicata la protezione PAGE_GUARD . Quando qualcuno tenta di accedere a questa memoria, genera un STATUS_GUARD_PAGE_VIOLATION. La mitigazione gestisce questa eccezione e, se l'istruzione di accesso non supera la convalida, il processo viene terminato.

Questa mitigazione protegge le API di Windows seguenti:

  • 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

Considerazioni sulla compatibilità

Le applicazioni legittime che eseguono l'intercettazione api potrebbero essere rilevate da questa mitigazione e causare l'arresto anomalo di alcune applicazioni. Ad esempio, software di sicurezza e shim di compatibilità delle applicazioni.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Utilizza le allocazioni di memoria casuali (ASLR bottom-up)

Descrizione

L'allocazione casuale della memoria (ASLR bottom-up) aggiunge entropia alle rilocazioni, in modo che la loro posizione sia casuale e quindi meno prevedibile. Questa mitigazione richiede l'applicazione della richiesta ASLR obbligatoria.

Le dimensioni dello spazio degli indirizzi a 32 bit comportano vincoli pratici sull'entropia che è possibile aggiungere, pertanto le applicazioni a 64 bit rendono più difficile per un utente malintenzionato indovinare una posizione in memoria.

Considerazioni sulla compatibilità

La maggior parte delle applicazioni compatibili con l'ASLR obbligatoria (riassegnazione) è compatibile anche con l'altra entropia di ASLR bottom-up. Alcune applicazioni potrebbero avere problemi di troncamento dei puntatori se salvano i puntatori locali in variabili a 32 bit (prevedendo un indirizzo di base inferiore a 4 GB) e pertanto non saranno compatibili con l'opzione entropia elevata (che può essere disabilitata).

Opzioni di configurazione

Non usare l'entropia elevata: questa opzione disabilita l'uso di ASLR con entropia elevata, che aggiunge 24 bit di entropia (1 TB di varianza) nell'allocazione bottom-up per le applicazioni a 64 bit.

Nota

L'allocazione casuale della memoria (ASLR bottom-up) non ha modalità di controllo.

Simula l'esecuzione (SimExec)

Descrizione

L'esecuzione simulata (SimExec) è una mitigazione solo per le applicazioni a 32 bit. Ciò consente di verificare che le chiamate ad API sensibili tornino a funzioni chiamanti legittime. A tale scopo, intercetta le chiamate nelle API sensibili e quindi simula l'esecuzione di tali API esaminando le istruzioni codificate del linguaggio dell'assembly che cercano l'istruzione RET, che dovrebbe tornare al chiamante. Esamina quindi tale funzione e scorre indietro in memoria per trovare l'istruzione CALL precedente per determinare se la funzione e l'istruzione CALL corrispondono e che il RET non sia stato intercettato.

Le API intercettate da questa mitigazione sono:

  • 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

Se viene rilevato un gadget ROP, il processo viene terminato.

Considerazioni sulla compatibilità

Le applicazioni che eseguono l'intercettazione API, in particolare il software di sicurezza, possono causare problemi di compatibilità con questa mitigazione.

Questa mitigazione non è compatibile con la mitigazione di protezione codice arbitraria.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Convalida chiamata di API (CallerCheck)

Descrizione

Convalidare chiamata API (CallerCheck) è una mitigazione per le tecniche di programmazione return-oriented (ROP) che convalida che le API sensibili siano state chiamate da un chiamante valido. Questa mitigazione controlla l'indirizzo del mittente passato e quindi esegue il disassemblaggio euristico all'indietro per trovare una chiamata sopra l'indirizzo del mittente per determinare se la destinazione della chiamata corrisponde al parametro passato nella funzione.

Le API intercettate da questa mitigazione sono:

  • 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

Se viene rilevato un gadget ROP, il processo viene terminato.

Considerazioni sulla compatibilità

Le applicazioni che eseguono l'intercettazione API, in particolare il software di sicurezza, possono causare problemi di compatibilità con questa mitigazione.

Questa mitigazione non è compatibile con la mitigazione di protezione codice arbitraria.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Convalida catene di eccezione (SEHOP)

Descrizione

Convalidare le catene di eccezioni (SEHOP) è una mitigazione rispetto alla tecnica di sovrascrittura SEH (Structured Exception Handler). La gestione strutturata delle eccezioni è il processo tramite il quale un'applicazione può chiedere di gestire una determinata eccezione. I gestori eccezioni vengono concatenati, in modo che se un gestore eccezioni sceglie di non gestire una determinata eccezione, può essere passata al gestore eccezioni successivo nella catena fino a quando non si decide di gestirla. Poiché l'elenco di gestori è dinamico, viene archiviato nello stack. Un utente malintenzionato può usare una vulnerabilità di overflow dello stack per sovrascrivere quindi il gestore eccezioni con un puntatore al codice scelto dall'utente malintenzionato.

Questa mitigazione si basa sulla progettazione di SEH, in cui ogni voce SEH contiene sia un puntatore al gestore eccezioni che un puntatore al gestore successivo nella catena di eccezioni. Questa mitigazione viene chiamata dal dispatcher di eccezioni, che convalida la catena SEH quando viene richiamata un'eccezione. Verifica che:

  • Tutti i record della catena di eccezioni si trovano all'interno dei limiti dello stack
  • Tutti i record delle eccezioni sono allineati
  • Nessun puntatore del gestore eccezioni sta puntando allo stack
  • Non sono presenti puntatori all’indietro
  • La catena di eccezioni termina in corrispondenza di un gestore eccezioni finale noto

Se queste convalide hanno esito negativo, la gestione delle eccezioni viene interrotta e l'eccezione non verrà gestita.

Considerazioni sulla compatibilità

I problemi di compatibilità con SEHOP sono relativamente rari. Non è comune che un'applicazione acquisisca una dipendenza in relazione al danneggiamento della catena di eccezioni. Tuttavia, alcune applicazioni sono interessate dalle sottili modifiche nel tempo, che potrebbero manifestarsi come una race condition che rivela un bug latente multithreading nell'applicazione.

Opzioni di configurazione

Nota

La convalida delle catene di eccezioni (SEHOP) non ha modalità di audit.

Convalida l'uso di handle

Descrizione

Convalidare l'utilizzo dell'handle è una mitigazione che consente di proteggersi da un utente malintenzionato usando un handle esistente per accedere a un oggetto protetto. Un handle è un riferimento a un oggetto protetto. Se il codice dell'applicazione fa riferimento a un handle non valido, potrebbe indicare che un antagonista sta tentando di usare un handle registrato in precedenza (ma di quale conteggio dei riferimenti all'applicazione non sarebbe a conoscenza). Se l'applicazione tenta di usare un oggetto non valido, anziché restituire semplicemente null, l'applicazione genera un'eccezione (STATUS_INVALID_HANDLE).

Questa mitigazione viene applicata automaticamente alle applicazioni del Windows Store.

Considerazioni sulla compatibilità

Le applicazioni che non monitoravano accuratamente i riferimenti agli handle e che non eseguivano il wrapping di queste operazioni nei gestori di eccezioni potrebbero essere interessate da questa mitigazione.

Opzioni di configurazione

Nota

La convalida dell'utilizzo dell'handle non presenta modalità di audit.

Convalida l'integrità dell'heap

Descrizione

La mitigazione dell’integrità dell'heap di convalida aumenta il livello di protezione delle mitigazioni dell'heap in Windows, causando l'interruzione dell'applicazione se viene rilevato un danneggiamento dell'heap. Le mitigazioni includono:

  • Impedire che venga liberato un handle HEAP
  • Esecuzione di un'altra convalida sulle intestazioni di blocco estese per le allocazioni dell'heap
  • Verifica che le allocazioni dell'heap non siano già contrassegnate come in uso
  • Aggiunta di pagine di protezione a allocazioni di grandi dimensioni, segmenti di heap e sottosegmenti superiori a una dimensione minima

Considerazioni sulla compatibilità

Questa mitigazione è già applicata per impostazione predefinita per le applicazioni a 64 bit e per le applicazioni a 32 bit destinate a Windows Vista o versioni successive. Le applicazioni legacy di Windows XP o versioni precedenti sono più a rischio, anche se i problemi di compatibilità sono rari.

Opzioni di configurazione

Nota

Convalidare l'integrità dell'heap non presenta modalità di audit.

Convalida l'integrità di dipendenza dell'immagine

Descrizione

La mitigazione della convalida delle dipendenze delle immagini consente di proteggersi dagli attacchi che tentano di sostituire il codice per dll collegate in modo statico dai file binari di Windows. La tecnica di planting DLL ha compromesso il meccanismo di ricerca del caricatore per inserire codice dannoso, che può essere usato per eseguire codice dannoso in un contesto con privilegi elevati. Quando il caricatore carica un file binario firmato da Windows e quindi carica tutte le DLL da cui dipende il file binario, questi file binari vengono verificati per assicurarsi che siano firmati digitalmente anche come binario di Windows. Se il controllo della firma non riesce, la DLL non verrà caricata e genererà un'eccezione, restituendo lo stato di STATUS_INVALID_IMAGE_HASH.

Considerazioni sulla compatibilità

I problemi di compatibilità non sono comuni. Le applicazioni che dipendono dalla sostituzione dei file binari di Windows con versioni private locali sono interessate e c'è anche un piccolo rischio di rivelare piccoli bug di temporizzazione nelle applicazioni multithreading.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Convalida l'integrità della pila (StackPivot)

Descrizione

La mitigazione dell’integrità dello stack di convalida (StackPivot) consente di proteggersi dall'attacco Stack Pivot, un attacco ROP in cui un utente malintenzionato crea uno stack falso nella memoria heap e quindi consiglia all'applicazione di tornare nello stack fittizio che controlla il flusso di esecuzione.

Questa mitigazione intercetta molte API di Windows ed esamina il valore del puntatore dello stack. Se l'indirizzo del puntatore dello stack non rientra tra la parte inferiore e la parte superiore dello stack, viene registrato un evento e, se non è in modalità di controllo, il processo viene terminato.

Le API intercettate da questa mitigazione sono:

  • 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

Considerazioni sulla compatibilità

Le applicazioni che usano stack falsi sono interessate e c'è anche un piccolo rischio di rivelare piccoli bug di temporizzazione nelle applicazioni multithreading. Le applicazioni che eseguono l'intercettazione API, in particolare il software di sicurezza, possono causare problemi di compatibilità con questa mitigazione.

Questa mitigazione non è compatibile con la mitigazione di protezione codice arbitraria.

Opzioni di configurazione

Solo audit: è possibile abilitare questa mitigazione in modalità di audit per misurare il potenziale impatto di compatibilità su un'applicazione. Gli eventi di audit possono quindi essere visualizzati nel Visualizzatore eventi o usando Rivelazione avanzata in Microsoft Defender per endpoint.

Consiglio

Per saperne di più, Engage con la community Microsoft Security nella community tech: Microsoft Defender per endpoint Tech Community.