Referência da proteção de exploração

Aplica-se a:

• Plano 1 do Microsoft Defender para Ponto de Extremidade
• Plano 2 do Microsoft Defender para Ponto de Extremidade
• Microsoft Defender XDR

Deseja experimentar o Microsoft Defender para Ponto de Extremidade? Inscreva-se para uma avaliação gratuita.

A proteção contra exploits fornece proteções avançadas para aplicações que os administradores empresariais e os profissionais de TI podem aplicar após um programador compilar e distribuir software.

Este artigo ajuda-o a compreender como funciona a proteção contra exploits, tanto ao nível da política como ao nível da mitigação individual, para o ajudar a criar e aplicar políticas de proteção contra exploits com êxito.

Como as mitigações são aplicadas

As mitigações da proteção contra exploits são aplicadas por aplicação.

As mitigações são configuradas por meio de uma entrada do Registro para cada programa para o qual você configura proteções. Estas definições são armazenadas na entrada de registo MitigationOptions para cada programa (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). Estes efeitos são aplicados quando reinicia o programa e permanecem em vigor até que os altere e reinicie o programa novamente.

Importante

As opções de execução de ficheiros de imagem só lhe permitem especificar um nome ou caminho de ficheiro e não um número de versão, arquitetura ou qualquer outro diferenciador. Tenha cuidado ao direcionar mitigações para aplicativos que têm nomes ou caminhos exclusivos, aplicando-os somente em dispositivos em que você testou essa versão e essa arquitetura do aplicativo.

Se configurar mitigações de proteção contra exploits através de um ficheiro de configuração XML com o PowerShell, Política de Grupo ou MDM, ao processar este ficheiro de configuração XML, as definições de registo individuais são configuradas para si.

Repor a proteção contra exploits

Importante

Quando a política de distribuição do ficheiro XML já não for imposta, as definições implementadas por este ficheiro de configuração XML não serão removidas automaticamente.

Para remover as definições de proteção contra exploits, exporte a configuração XML de um dispositivo limpo Windows 10 ou Windows 11 e implemente este novo ficheiro XML. Em alternativa, a Microsoft fornece um ficheiro XML como parte das Linhas de Base do Segurança do Windows para repor as definições de proteção contra exploits.

Para repor as definições de exploit protection com o PowerShell, utilize o seguinte comando:

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

A seguir está o EP-reset.xml distribuído com as Linhas de base de segurança do 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>

Referência de mitigação

As seções a seguir detalham as proteções fornecidas por cada mitigação de proteção contra explorações, as considerações de compatibilidade para a mitigação e as opções de configuração disponíveis.

Proteção de código arbitrária

Descrição

A proteção de código arbitrária ajuda a proteger contra um invasor mal-intencionado que carrega o código de sua escolha na memória por meio de uma vulnerabilidade de segurança de memória e pode executar esse código.

O code guard arbitrário protege uma aplicação de executar código gerado dinamicamente (código que não é carregado, por exemplo, do próprio exe ou de um dll). A proteção de código arbitrária funciona impedindo que a memória seja marcada como executável. Quando um aplicativo tenta alocar memória, verificamos os sinalizadores de proteção. (A memória pode ser alocada com sinalizadores de proteção de leitura, gravação e/ou execução.) Se a alocação tentar incluir o sinalizador de proteção execute, a alocação de memória falhará e retornará um código de erro (STATUS_DYNAMIC_CODE_BLOCKED). Da mesma forma, se um aplicativo tentar alterar os sinalizadores de proteção da memória que já foi alocada e incluir o sinalizador de proteção executar, a alteração de permissão falhará e retornará um código de erro (STATUS_DYNAMIC_CODE_BLOCKED).

Ao impedir que o sinalizador executar seja definido, o recurso de prevenção de execução de dados do Windows 10 e do Windows 11 pode proteger contra o ponteiro de instrução que está sendo definido para essa memória e executar esse código.

Considerações sobre compatibilidade

A proteção de código arbitrária impede a alocação de qualquer memória como executável, o que apresenta um problema de compatibilidade com abordagens como compiladores JIT (Just-In-Time). A maioria dos browsers modernos, por exemplo, compila JavaScript em código nativo para otimizar o desempenho. Para suportar esta mitigação, têm de ser rearquitetadas para mover a compilação JIT para fora do processo protegido. Outras aplicações cujo design gera código dinamicamente a partir de scripts ou outras linguagens intermédias são igualmente incompatíveis com esta mitigação.

Opções de configuração

Permitir recusa de thread – Você pode configurar a mitigação para permitir que um thread individual recuse essa proteção. O programador tem de escrever a aplicação com deteção desta mitigação e chamar a API SetThreadInformation com o parâmetro ThreadInformation definido como ThreadDynamicCodePolicy para poder executar código dinâmico neste thread.

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Defender para Ponto de Extremidade.

Bloquear imagens de baixa integridade

Descrição

Bloquear imagens de baixa integridade impede que a aplicação carregue ficheiros não fidedignos, normalmente porque foram transferidos da Internet a partir de um browser em sandbox.

Esta mitigação bloqueia o carregamento da imagem se a imagem tiver uma Entrada de Controle de Acesso (ACE) que conceda acesso a processos IL baixos e que não tenha uma etiqueta de fidedignidade ACE. É implementado pelo gestor de memória, o que impede que o ficheiro seja mapeado para a memória. Se uma aplicação tentar mapear uma imagem de baixa integridade, aciona um erro de STATUS_ACCESS_DENIED. Para obter detalhes sobre como os níveis de integridade funcionam, consulte Controle de Integridade de Credenciais.

Considerações sobre compatibilidade

Bloquear imagens de baixa integridade impede que a aplicação carregue ficheiros que foram transferidos a partir da Internet. Se o fluxo de trabalho da aplicação exigir o carregamento de imagens que são transferidas, deve certificar-se de que são transferidas de um processo de maior confiança ou que são explicitamente reativadas para aplicar esta mitigação.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Bloquear imagens remotas

Descrição

O bloqueio de imagens remotas ajuda a impedir que o aplicativo carregue arquivos hospedados em um dispositivo remoto, como um compartilhamento UNC. O bloqueio de imagens remotas ajuda a proteger contra o carregamento na memória de binários que estão em um dispositivo externo controlado pelo invasor.

Esta mitigação bloqueia o carregamento da imagem se a imagem for determinada como num dispositivo remoto. É implementado pelo gestor de memória, o que impede que o ficheiro seja mapeado para a memória. Se uma aplicação tentar mapear um ficheiro remoto, aciona um erro de STATUS_ACCESS_DENIED.

Considerações sobre compatibilidade

Bloquear imagens remotas impede que a aplicação carregue imagens de dispositivos remotos. Se o aplicativo carregar arquivos ou plug-ins de dispositivos remotos, ele não será compatível com essa mitigação.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Bloquear fontes não confiáveis

Descrição

Bloquear fontes não confiáveis reduz o risco de uma falha na análise de fontes, levando o invasor a executar código no dispositivo. Somente as fontes instaladas no diretório windows\fonts serão carregadas para processamento pela GDI.

Essa mitigação é implementada na GDI, que valida o local do arquivo. Se o ficheiro não estiver no diretório de tipos de letra do sistema, o tipo de letra não será carregado para análise e essa chamada falhará.

Essa mitigação existe além da mitigação interna fornecida no Windows 10 1607 e posterior e no Windows 11, que move a análise de fontes para fora do kernel e para um contêiner de aplicativo no modo de usuário. Qualquer exploração baseada na análise de fonte, como resultado, ocorre em um contexto isolado e em área restrita, o que reduz significativamente o risco. Para obter detalhes sobre essa mitigação, consulte o blog Proteção do Windows 10 com mitigações de exploração de dia zero.

Considerações sobre compatibilidade

O uso mais comum de fontes fora do diretório de fontes do sistema é com web fonts. Os browsers modernos, como o Microsoft Edge, utilizam DirectWrite em vez de GDI e não são afetados. No entanto, navegadores herdados, como o Internet Explorer 11 (e o modo IE no novo Microsoft Edge) podem ser afetados, especialmente com aplicativos como o Office 365, que usam glifos de fonte para exibir a interface do usuário.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Proteção da integridade do código

Descrição

A proteção de integridade de código garante que todos os binários carregados em um processo sejam assinados digitalmente pela Microsoft. O code integrity guard inclui assinaturas WHQL (Windows Hardware Quality Labs), o que permite que os controladores aprovados pela WHQL sejam executados no processo.

Essa mitigação é implementada no gerenciador de memória, o que impede que o binário seja mapeado na memória. Se tentar carregar um binário que não esteja assinado pela Microsoft, a manjedoura de memória devolve o erro STATUS_INVALID_IMAGE_HASH. Bloquear no nível do gerenciador de memória impede que os binários sejam carregados pelo processo e injetados no processo.

Considerações sobre compatibilidade

Esta mitigação bloqueia especificamente qualquer binário que não esteja assinado pela Microsoft. Como tal, é incompatível com a maioria do software que não seja da Microsoft, a menos que esse software seja distribuído pela Microsoft Store (e assinado digitalmente) e a opção para permitir o carregamento de imagens assinadas pela Microsoft Store esteja selecionada.

Opções de configuração

Permitir também o carregamento de imagens assinadas pela Microsoft Store – as aplicações distribuídas pela Microsoft Store são assinadas digitalmente pela Microsoft Store e adicionar esta configuração permite que os binários que passam pelo processo de certificação da loja sejam carregados pela aplicação.

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Proteção de fluxo de controle (CFG)

Descrição

A CFG (Proteção de Fluxo de Controle) reduz o risco de invasores usarem vulnerabilidades de corrupção de memória protegendo chamadas de função indiretas. Por exemplo, um atacante pode utilizar uma vulnerabilidade de capacidade excedida da memória intermédia para substituir a memória que contém um ponteiro de função e substituir esse ponteiro de função por um ponteiro para o código executável à sua escolha (que também pode ser injetado no programa).

Essa mitigação é fornecida injetando outra verificação em tempo de compilação. Antes de cada chamada de função indireta, são adicionadas outras instruções que verificam se o destino é um destino de chamada válido antes de ser chamado. Se o destino não for um destino de chamada válido, a aplicação será terminada. Dessa forma, somente aplicativos compilados com suporte a CFG podem se beneficiar dessa mitigação.

A verificação de um destino válido é fornecida pelo kernel do Windows. Quando arquivos executáveis são carregados, os metadados para destinos de chamada indireta são extraídos no tempo de carregamento e marcados como destinos de chamada válidos. Além disso, quando a memória é alocada e marcada como executável (como para código gerado), esses locais de memória também são marcados como destinos de chamada válidos para dar suporte a mecanismos como compilação JIT.

Considerações sobre compatibilidade

Como os aplicativos devem ser compilados para dar suporte ao CFG, eles declaram implicitamente sua compatibilidade com ele. A maioria dos aplicativos, portanto, deve funcionar com essa mitigação habilitada. Como essas verificações são compiladas no binário, a configuração que você pode aplicar é simplesmente desabilitar verificações dentro do kernel do Windows. Por outras palavras, a mitigação está ativada por predefinição, mas pode configurar o kernel do Windows para devolver sempre "sim" se mais tarde determinar que existe um problema de compatibilidade que o programador da aplicação não detetou nos testes, o que deve ser raro.

Opções de configuração

Usar CFG estrito – No modo estrito, todos os binários carregados no processo devem ser compilados para a proteção de fluxo de controle (ou não têm nenhum código executável neles – como dlls de recurso) para serem carregados.

Observação

A proteção de fluxo de controle não tem nenhum modo de auditoria. Os binários são compilados com essa mitigação habilitada.

Prevenção de Execução de Dados (DEP)

Descrição

A prevenção de execução de dados (DEP) impede que a memória que não foi explicitamente alocada como executável seja executada. A DEP ajuda a proteger contra um invasor que injeta código malicioso no processo, como por meio de um estouro de buffer e, em seguida, executa esse código.

Se tentar definir o ponteiro de instruções para um endereço de memória não marcado como executável, o processador lança uma exceção (violação de proteção geral), o que faz com que a aplicação falhe.

Considerações sobre compatibilidade

Todos os executáveis x64, ARM e ARM-64 têm o DEP ativado por predefinição e não podem ser desativados. Uma vez que uma aplicação não é executada sem DEP, é assumida a compatibilidade.

Todos os binários x86 (32 bits) têm a DEP habilitada por padrão, mas ela pode ser desabilitada por processo. Alguns aplicativos herdados antigos, normalmente aplicativos desenvolvidos antes do Windows XP SP2, podem não ser compatíveis com a DEP. Esses aplicativos normalmente geram código dinamicamente (por exemplo, compilação JIT) ou vinculam a bibliotecas mais antigas (como versões mais antigas da ATL) que geram código dinamicamente.

Opções de configuração

Habilitar emulação de ATL Thunk - Essa opção de configuração desabilita a emulação do ATL Thunk. A ATL, a Biblioteca de Modelos ActiveX, foi projetada para ser menor e mais rápida possível. Para reduzir o tamanho binário, ela usaria uma técnica chamada thunking. Normalmente, a escrita à tinta é considerada para interagir entre aplicativos de 32 bits e 16 bits, mas não há componentes de 16 bits para a ATL aqui. Em vez disso, para otimizar o tamanho binário, o ATL armazena código de máquina na memória que não está alinhado com palavras (criando um binário mais pequeno) e, em seguida, invoca diretamente esse código. Os componentes ATL compilados com o Visual Studio 7.1 ou anterior (Visual Studio 2003) não atribuem esta memória como executável . A emulação thunk resolve esse problema de compatibilidade. Aplicativos que têm um modelo de extensão binária (como o Internet Explorer 11) geralmente precisarão ter a emulação do ATL Thunk habilitada.

Desabilitar os pontos de extensão

Descrição

Essa mitigação desabilita vários pontos de extensão para um aplicativo. Eles podem ser usados para estabelecer persistência ou elevar privilégios de conteúdo mal-intencionado.

Isso inclui:

• DLLs do AppInit – sempre que um processo é iniciado, o sistema carrega a DLL especificada para o contexto do processo iniciado recentemente antes de chamar a função de ponto de entrada. Detalhes sobre DLLs AppInit podem ser encontrados aqui. Com esta mitigação aplicada, os DLLs appInit não são carregados. A partir do Windows 7, as DLLs AppInit precisam ser assinadas digitalmente, conforme descrito aqui. Além disso, a partir de Windows 8, os DLLs do AppInit não serão carregados se o SecureBoot estiver ativado, conforme descrito aqui.
• Legacy IMEs - Um IME (Editor de Método de Entrada) permite que um usuário digite texto em um idioma que tenha mais caracteres do que pode ser representado em um teclado. Terceiros podem criar IMEs. Um IME mal-intencionado pode obter credenciais ou outras informações confidenciais dessa captura de entrada. Alguns IMEs, referidos como IMEs Legados, só funcionam em aplicações de Ambiente de Trabalho do Windows e não em aplicações UWP. Esta mitigação também impede que este IME legado seja carregado para a aplicação de Ambiente de Trabalho do Windows especificada.
• Windows Event Hooks - Um aplicativo pode chamar aAPI SETWinEventHook para registrar o interesse em um evento que está ocorrendo. Uma DLL é especificada e pode ser injetada no processo. Essa mitigação força o gancho a ser postado no processo de registro em vez de executar em processo por meio de uma DLL injetada.

Considerações sobre compatibilidade

A maioria desses pontos de extensão é relativamente pouco usada, portanto, o impacto da compatibilidade normalmente é pequeno, especialmente em um nível de aplicativo individual. A única consideração é se os utilizadores estiverem a utilizar MI Legadas de terceiros que não funcionarão com a aplicação protegida.

Opções de configuração

Não há opções de configuração para essa mitigação.

Observação

Desabilitar pontos de extensão não tem modo de auditoria.

Desabilitar chamadas do sistema Win32k

Descrição

Win32k.sys fornece uma ampla superfície de ataque para um invasor. Como componente do modo kernel, é frequentemente direcionado como um vetor de escape para aplicações em sandbox. Essa mitigação impede chamadas em win32k.sys bloqueando a conversão de um thread em um thread de GUI, que recebe acesso para invocar funções Win32k. Um thread não é GUI quando criado, mas convertido na primeira chamada para win32k.sys ou por meio de uma chamada à API para IsGuiThread.

Considerações sobre compatibilidade

Essa mitigação foi projetada para processos dedicados que não são da interface do usuário. Por exemplo, muitos browsers modernos utilizam o isolamento de processos e incorporam processos não IU. Qualquer aplicativo que exibe uma GUI usando um único processo será afetado por essa mitigação.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Não permitir processos filho

Descrição

Essa mitigação impede que um aplicativo crie novos aplicativos filho. Uma técnica comum usada por adversários é iniciar um processo confiável no dispositivo com entrada mal-intencionada (um ataque de "vida fora da terra"), que geralmente requer a inicialização de outro aplicativo no dispositivo. Se não houver motivos legítimos pelos quais um aplicativo iniciaria um processo filho, essa mitigação mitigará esse possível vetor de ataque. A mitigação é aplicada definindo uma propriedade no token de processo, o que bloqueia a criação de um token para o processo filho com a mensagem de erro STATUS_CHILD_PROCESS_BLOCKED.

Considerações sobre compatibilidade

Se a sua aplicação iniciar aplicações subordinadas por qualquer motivo, como o suporte de hiperligações que iniciam um browser ou um browser externo, ou que iniciam outros utilitários no computador, esta funcionalidade é interrompida com esta mitigação aplicada.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Filtragem de endereços de exportação

Descrição

A EAF (filtragem de endereços de exportação) reduz o risco de código mal-intencionado examinar a tabela de endereços de exportação de todos os módulos carregados para encontrar módulos que contenham APIs úteis para seu ataque. Essa é uma tática comum usada pelo shellcode. Para atenuar o risco de tal ataque, essa mitigação protege três módulos comumente atacados:

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

A mitigação protege a página de memória no [diretório de exportação que aponta para exportar tabela de endereços. Esta página de memória tem a proteção PAGE_GUARD aplicada à mesma. Quando alguém tenta aceder a esta memória, gera uma STATUS_GUARD_PAGE_VIOLATION. A mitigação processa esta exceção e, se a instrução de acesso não passar na validação, o processo será terminado.

Considerações sobre compatibilidade

Essa mitigação é principalmente um problema para aplicativos como depuradores, aplicativos em área restrita, aplicativos que usam DRM ou aplicativos que implementam tecnologia anti-depuração.

Opções de configuração

Validar o acesso para módulos que normalmente são atacados por explorações – Essa opção, também conhecida como EAF+, adiciona proteções para outros módulos comumente atacados:

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

Além disso, ao habilitar o EAF+, essa mitigação adiciona a proteção do PAGE_GUARD à página que contém o cabeçalho "MZ", os dois primeiros bytes do cabeçalho DOS em um arquivo PE, que é outro aspecto do conteúdo de memória conhecido que o shellcode pode procurar para identificar módulos potencialmente de interesse na memória.

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Forçar a aleatorização para imagens (ASLR obrigatória)

Descrição

O ASLR (Address Space Layout Randomization) reduz o risco de um invasor usar seu conhecimento do layout de memória do sistema para executar o código que já está presente na memória do processo e já marcado como executável. Isso pode reduzir o risco de um invasor usar técnicas como ataques de return-to-libc, em que o invasor define o contexto e modifica o endereço de retorno para executar o código existente com contexto que atenda à finalidade do adversário.

O ASLR obrigatório força uma rebase de todas as DLLs dentro do processo. Um desenvolvedor pode habilitar o ASLR usando a opção de vinculador /DYNAMICBASE e essa mitigação tem o mesmo efeito.

Quando o gestor de memória está a mapear a imagem para o processo, o ASLR obrigatório irá forçar a nova base de DLLs e EXEs que não optaram por participar no ASLR. Observe, no entanto, que essa base não tem entropia e, portanto, pode ser colocada em um local previsível na memória. Para um local baseado e aleatório de binários, essa mitigação deve ser emparelhada com Randomizar alocações de memória (ASLR de baixo para cima).

Considerações sobre compatibilidade

Esse impacto de compatibilidade do ASLR normalmente é restrito a aplicativos mais antigos que foram criados usando compiladores que fizeram suposições sobre o endereço base de um arquivo binário ou removeram informações de realocação base. Isso pode levar a erros imprevisíveis à medida que o fluxo de execução tenta ir para o local esperado, em vez do local real na memória.

Opções de configuração

Não permitir imagens removidas - Essa opção bloqueia o carregamento de imagens que tiveram as informações de realocação removidas. O formato de ficheiro do Windows PE contém endereços absolutos e o compilador também gera uma [tabela de reposicionamento base que o carregador pode utilizar para localizar todas as referências de memória relativa e o respetivo desvio, para que possam ser atualizados se o binário não carregar no endereço base preferencial. Algumas aplicações mais antigas eliminam estas informações em compilações de produção e, por conseguinte, estes binários não podem ser reutilizados. Essa mitigação impede que esses binários sejam carregados (em vez de permitir que eles carreguem em seu endereço base preferencial).

Observação

Forçar randomização para imagens (ASLR obrigatório) não tem modo de auditoria.

Proteção de pilha imposta por hardware

Descrição

A proteção de pilha imposta por hardware oferece proteção robusta contra exploits ROP, uma vez que mantém um registo do fluxo de execução pretendido de um programa. Para garantir uma adoção suave do ecossistema e a compatibilidade de aplicações, o Windows oferece esta proteção como um modelo de opção ativa, para que os programadores possam receber esta proteção ao seu próprio ritmo.

Considerações sobre compatibilidade

A proteção de pilha imposta por hardware só funciona em chipsets com suporte para pilhas sombra de hardware, Tecnologia de Imposição de Fluxo de Controlo (CET) da Intel ou pilhas sombra AMD.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Defender para Ponto de Extremidade.

Impor para todos os módulos em vez de Módulos compatíveis – pode ativar esta mitigação para Impor para todos os módulos em vez de Módulos compatíveis.

Filtragem de endereços de importação (IAF)

Descrição

A mitigação de IAF (filtragem de endereços de importação) ajuda a reduzir o risco de um adversário alterar o fluxo de controle de um aplicativo modificando a IAT (tabela de endereços de importação) para redirecionar para o código arbitrário de escolha do invasor quando essa função é chamada. Um invasor pode usar essa abordagem para sequestrar o controle ou interceptar, inspecionar e potencialmente bloquear chamadas para APIs confidenciais.

As páginas de memória de todas as APIs protegidas têm a proteção PAGE_GUARD aplicada às mesmas. Quando alguém tenta aceder a esta memória, gera uma STATUS_GUARD_PAGE_VIOLATION. A mitigação processa esta exceção e, se a instrução de acesso não passar na validação, o processo será terminado.

Essa mitigação protege as seguintes APIs do Windows:

• 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

Considerações sobre compatibilidade

As aplicações legítimas que executam a intercepção de API podem ser detetadas por esta mitigação e causar a falha de algumas aplicações. Exemplos incluem shims de compatibilidade de aplicativos e software de segurança.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Usar aleatoriamente alocações de memória (ASLR de baixo para cima)

Descrição

Alocações de memória aleatórias (ASLR de baixo para cima) adicionam entropia a realocações, para que sua localização seja aleatória e, portanto, menos previsível. Essa mitigação exige que o ASLR obrigatório entre em vigor.

O tamanho do espaço de endereço de 32 bits coloca restrições práticas na entropia que podem ser adicionadas e, portanto, os aplicativos de 64 bits tornam mais difícil para um invasor adivinhar um local na memória.

Considerações sobre compatibilidade

A maioria dos aplicativos compatíveis com ASLR obrigatório (rebasing) também é compatível com a outra entropia do ASLR de baixo para cima. Algumas aplicações podem ter problemas de truncagem de ponteiros se estiverem a guardar ponteiros locais em variáveis de 32 bits (esperando um endereço base inferior a 4 GB) e, portanto, serão incompatíveis com a opção de entropia elevada (que pode ser desativada).

Opções de configuração

Não use entropia alta – Essa opção desabilita o uso de ASLR de alta entropia, que adiciona 24 bits de entropia (1 TB de variância) à alocação de baixo para cima para aplicativos de 64 bits.

Observação

Alocações de memória aleatórias (ASLR de baixo para cima) não tem nenhum modo de auditoria.

Simular a execução (SimExec)

Descrição

Simular execução (SimExec) é uma mitigação somente para aplicativos de 32 bits. Isto ajuda a validar que as chamadas para APIs confidenciais regressam às funções de autor da chamada legítimas. Ele faz isso interceptando chamadas em APIs confidenciais e, em seguida, simulando a execução dessas APIs percorrendo as instruções de linguagem de assembly codificada procurando a instrução RET, que deve retornar ao chamador. Em seguida, ele inspeciona essa função e percorre para trás na memória para localizar a instrução CALL anterior e determinar se a função e a instrução CALL correspondem e se o RET não foi interceptado.

As APIs interceptadas por essa mitigação são:

• 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 um gadget ROP for detectado, o processo será encerrado.

Considerações sobre compatibilidade

Aplicativos que executam interceptação de API, especialmente software de segurança, podem causar problemas de compatibilidade com essa mitigação.

Essa mitigação é incompatível com a mitigação da proteção de código arbitrária.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Validar a invocação da API (CallerCheck)

Descrição

Validar invocação de API (CallerCheck) é uma mitigação para técnicas ROP (programação orientada a retorno) que valida que APIs confidenciais foram chamadas de um chamador válido. Essa mitigação inspeciona o endereço de retorno passado e, em seguida, desmonta heuristicamente para trás para encontrar uma chamada acima do endereço de retorno para determinar se o destino da chamada corresponde ao parâmetro passado para a função.

As APIs interceptadas por essa mitigação são:

• 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 um gadget ROP for detectado, o processo será encerrado.

Considerações sobre compatibilidade

Aplicativos que executam interceptação de API, especialmente software de segurança, podem causar problemas de compatibilidade com essa mitigação.

Essa mitigação é incompatível com a mitigação da proteção de código arbitrária.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Validar as correntes de exceção (SEHOP)

Descrição

Validar cadeias de exceção (SEHOP) é uma mitigação em relação à técnica de exploração de substituição do SEH (Manipulação de exceções estruturadas). A manipulação de exceções estruturadas é o processo pelo qual um aplicativo pode pedir para lidar com uma exceção específica. Manipuladores de exceção são encadeados, de modo que, se um manipulador de exceção optar por não manipular uma exceção específica, ele poderá ser passado para o próximo manipulador de exceção na cadeia até que se decida manipulá-la. Uma vez que a lista de processadores é dinâmica, é armazenada na pilha. Um invasor pode usar uma vulnerabilidade de excedente de pilha para substituir o manipulador de exceção por um ponteiro para o código de escolha do invasor.

Esta mitigação baseia-se na estrutura do SEH, em que cada entrada SEH contém um ponteiro para o processador de exceções e um ponteiro para o processador seguinte na cadeia de exceções. Essa mitigação é chamada pelo despachante de exceção, que valida a cadeia SEH quando uma exceção é invocada. Ele verifica se:

• Todos os registros de cadeia de exceção estão dentro dos limites de pilha
• Todos os registros de exceção estão alinhados
• Nenhum ponteiro do manipulador de exceção está apontando para a pilha
• Não há ponteiros para trás
• A cadeia de exceção termina em um manipulador de exceção final conhecido

Se estas validações falharem, o processamento de exceções será abortado e a exceção não será processada.

Considerações sobre compatibilidade

Problemas de compatibilidade com SEHOP são relativamente raros. É incomum que um aplicativo tenha uma dependência de corromper a cadeia de exceção. No entanto, algumas aplicações são afetadas pelas alterações subtis na temporização, que podem manifestar-se como uma condição race que revela um erro latente de multi-threading na aplicação.

Opções de configuração

Observação

Validar cadeias de exceção (SEHOP) não tem modo de auditoria.

Validar o uso do identificador

Descrição

Validar o uso do identificador é uma mitigação que ajuda a proteger contra um invasor usando um identificador existente para acessar um objeto protegido. Um identificador é uma referência a um objeto protegido. Se o código da aplicação estiver a referenciar um identificador inválido, pode indicar que um adversário está a tentar utilizar um identificador que registou anteriormente (mas que contagem de referências de aplicações não teria conhecimento). Se a aplicação tentar utilizar um objeto inválido, em vez de simplesmente devolver nulo, a aplicação gera uma exceção (STATUS_INVALID_HANDLE).

Essa mitigação é aplicada automaticamente a aplicativos da Windows Store.

Considerações sobre compatibilidade

As aplicações que não estavam a controlar com precisão as referências de identificadores e que não estavam a encapsular estas operações em processadores de exceções serão potencialmente afetadas por esta mitigação.

Opções de configuração

Observação

Validar o uso do identificador não tem nenhum modo de auditoria.

Validar integridade da pilha

Descrição

A mitigação de integridade do heap de validação aumenta o nível de proteção das mitigações de heap no Windows, fazendo com que o aplicativo seja encerrado se uma corrupção de heap for detectada. As mitigações incluem:

• Impedindo que um identificador HEAP seja liberado
• Executando outra validação em cabeçalhos de bloco estendido para alocações de heap
• Verificar se as alocações de área dinâmica para dados ainda não estão sinalizadas como em utilização
• Adicionando páginas de proteção a grandes alocações, segmentos de heap e subseções acima de um tamanho mínimo

Considerações sobre compatibilidade

Essa mitigação já é aplicada por padrão para aplicativos de 64 bits e para aplicativos de 32 bits direcionados ao Windows Vista ou posterior. Aplicativos herdados do Windows XP ou anteriores estão mais em risco, embora os problemas de compatibilidade sejam raros.

Opções de configuração

Observação

Validar a integridade do heap não tem nenhum modo de auditoria.

Validar a integridade da dependência da imagem

Descrição

A mitigação de dependência de imagem de validação ajuda a proteger contra ataques que tentam substituir o código por dlls vinculadas estaticamente por binários do Windows. A técnica de plantio de DLL abusa do mecanismo de pesquisa do carregador para injetar código malicioso, que pode ser usado para executar código malicioso em um contexto elevado. Quando o carregador está a carregar um binário assinado pelo Windows e, em seguida, carrega quaisquer dlls de que o binário depende, estes binários são verificados para garantir que também estão assinados digitalmente como um binário do Windows. Se a assinatura falhar marcar, o dll não será carregado e emitirá uma exceção, devolvendo uma status de STATUS_INVALID_IMAGE_HASH.

Considerações sobre compatibilidade

Problemas de compatibilidade são incomuns. As aplicações que dependem da substituição de binários do Windows por versões privadas locais são afetadas e existe também um pequeno risco de revelar erros subtis de temporização em aplicações com vários threads.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Validar a integridade da pilha (StackPivot)

Descrição

A mitigação de validação da integridade da pilha (StackPivot) ajuda a proteger contra o ataque do Stack Pivot, um ataque ROP em que um invasor cria uma pilha falsa na memória do heap e, em seguida, induz o aplicativo a retornar à pilha falsa que controla o fluxo de execução.

Essa mitigação intercepta muitas APIs do Windows e inspeciona o valor do ponteiro de pilha. Se o endereço do ponteiro da pilha não se enquadrar entre a parte inferior e a parte superior da pilha, é registado um evento e, se não estiver no modo de auditoria, o processo é terminado.

As APIs interceptadas por essa mitigação são:

• 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

Considerações sobre compatibilidade

As aplicações que estão a utilizar pilhas falsas são afetadas e existe também um pequeno risco de revelar erros subtis de temporização em aplicações com vários threads. Aplicativos que executam interceptação de API, especialmente software de segurança, podem causar problemas de compatibilidade com essa mitigação.

Essa mitigação é incompatível com a mitigação da proteção de código arbitrária.

Opções de configuração

Somente auditoria – Você pode habilitar essa mitigação no modo de auditoria para medir o impacto potencial de compatibilidade em um aplicativo. Os eventos de auditoria podem ser exibidos no visualizador de eventos ou usando a Busca Avançada no Microsoft Defender para Ponto de Extremidade.

Dica

Você deseja aprender mais? Engage com a comunidade de Segurança da Microsoft na nossa Comunidade Tecnológica: Microsoft Defender para Ponto de Extremidade Tech Community.