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

Artigo
11/07/2023

Aplica-se a:

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

A proteção de exploração fornece proteções avançadas para aplicativos que os administradores corporativos e profissionais de TI podem aplicar depois que um desenvolvedor tiver compilado e distribuído software.

Este artigo ajuda você a entender como a proteção de exploração funciona, tanto no nível da política quanto no nível de mitigação individual, para ajudá-lo a criar e aplicar políticas de proteção de exploração com êxito.

Como as mitigações são aplicadas

As mitigações de proteção de exploração são aplicadas por aplicativo.

As mitigações são configuradas por meio de uma entrada do Registro para cada programa para o qual você configura proteções. Essas configurações são armazenadas na entrada do Registro de MitigaçõesOpções para cada programa (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). Eles fazem efeito quando você reinicia o programa e permanece efetivo até alterá-los e reiniciar o programa novamente.

Importante

As opções de execução de arquivo de imagem só permitem especificar um nome ou caminho de arquivo 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 você configurar mitigações de proteção de exploração usando um arquivo de configuração XML usando PowerShell, Política de Grupo ou MDM, ao processar esse arquivo de configuração XML, as configurações de registro individuais serão configuradas para você.

Quando a política que distribui o arquivo XML não for mais imposta, as configurações implantadas por esse arquivo de configuração XML não serão removidas automaticamente. Para remover as configurações do Exploit Protection, exporte a configuração XML de um dispositivo Windows 10 ou Windows 11 limpo e implante esse novo arquivo XML. Como alternativa, a Microsoft fornece um arquivo XML como parte das Linhas de base segurança do Windows para redefinir as configurações do Exploit Protection.

Para redefinir as configurações de proteção de exploração usando o PowerShell, use 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 um aplicativo contra a execução de 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 navegadores modernos, por exemplo, compila o JavaScript em código nativo para otimizar o desempenho. Para dar suporte a essa mitigação, eles precisarão ser rearquitecados para mover a compilação JIT para fora do processo protegido. Outros aplicativos cujo design gera dinamicamente código de scripts ou outros idiomas intermediários são igualmente incompatíveis com essa 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 desenvolvedor deve ter escrito o aplicativo com reconhecimento dessa mitigação e ter chamado a API SetThreadInformation com o parâmetro ThreadInformation definido como ThreadDynamicCodePolicy para ter permissão para executar código dinâmico nesse 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 o aplicativo carregue arquivos não confiáveis, normalmente porque eles foram baixados da Internet de um navegador com área restrita.

Essa mitigação bloqueia o carregamento de imagem se a imagem tiver uma ACE (entrada de Controle de Acesso) que conceda acesso a processos de IL baixos e que não tem um ACE de rótulo de confiança. Ele é implementado pelo gerenciador de memória, que impede que o arquivo seja mapeado para a memória. Se um aplicativo tentar mapear uma imagem de baixa integridade, ele disparará 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 o aplicativo carregue arquivos que foram baixados da Internet. Se o fluxo de trabalho do aplicativo exigir o carregamento de imagens baixadas, você precisará garantir que elas sejam baixadas de um processo de maior confiança ou sejam explicitamente relançadas para aplicar essa mitigação.

Opções de configuração

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.

Essa mitigação bloqueia o carregamento de imagem se a imagem estiver determinada a estar em um dispositivo remoto. Ele é implementado pelo gerenciador de memória, que impede que o arquivo seja mapeado para a memória. Se um aplicativo tentar mapear um arquivo remoto, ele disparará um erro de STATUS_ACCESS_DENIED.

Considerações sobre compatibilidade

Bloquear imagens remotas impede que o aplicativo 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

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 arquivo não estiver no diretório de fontes do sistema, a fonte não será carregada 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. Navegadores modernos, como o Microsoft Edge, usam 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

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 proteção de integridade de código inclui assinaturas WHQL (Windows Hardware Quality Labs), o que permite que drivers aprovados pelo WHQL sejam executados dentro do processo.

Essa mitigação é implementada no gerenciador de memória, o que impede que o binário seja mapeado na memória. Se você tentar carregar um binário que não é assinado pela Microsoft, o manger de memória retornará 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

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

Opções de configuração

Também permitir o carregamento de imagens assinadas pela Microsoft Store – os aplicativos distribuídos pela Microsoft Store são assinados digitalmente pela Microsoft Store e adicionar essa configuração permite que binários que passaram pelo processo de certificação do repositório sejam carregados pelo aplicativo.

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 invasor pode usar uma vulnerabilidade de estouro de buffer 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 de sua escolha (que também pode ter sido injetado no programa).

Essa mitigação é fornecida injetando outra verificação em tempo de compilação. Antes de cada chamada de função indireta, outras instruções são adicionadas 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, o aplicativo será encerrado. 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. Em outras palavras, a mitigação está ativada por padrão, mas você pode configurar o kernel do Windows para sempre retornar "sim" se você determinar posteriormente que há um problema de compatibilidade que o desenvolvedor de aplicativos não descobriu em seus 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 DEP (prevenção de execução de dados) 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 você tentar definir o ponteiro de instrução para um endereço de memória não marcado como executável, o processador gerará uma exceção (violação de proteção geral), fazendo com que o aplicativo falhe.

Considerações sobre compatibilidade

Todos os executáveis x64, ARM e ARM-64 têm DEP habilitado por padrão e não podem ser desabilitados. Como um aplicativo nunca foi executado sem DEP, a compatibilidade é assumida.

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 para o tamanho binário, a ATL armazena o código do computador na memória que não está alinhado a palavras (criando um binário menor) e, em seguida, invoque esse código diretamente. Os componentes ATL compilados com o Visual Studio 7.1 ou anterior (Visual Studio 2003) não alocam essa 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 appInit - Sempre que um processo é iniciado, o sistema carrega a DLL especificada no contexto do processo recém-iniciado antes de chamar sua função de ponto de entrada. Detalhes sobre DLLs AppInit podem ser encontrados aqui. Com essa mitigação aplicada, as DLLs do AppInit não são carregadas. A partir do Windows 7, as DLLs AppInit precisam ser assinadas digitalmente, conforme descrito aqui. Além disso, começando com Windows 8, as DLLs do AppInit não serão carregadas se SecureBoot estiver habilitado, 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, conhecidos como IMEs Herdados, funcionam apenas em aplicativos da Área de Trabalho do Windows e não em aplicativos UWP. Essa mitigação também impede que esse IME herdado carregue no aplicativo windows desktop especificado.
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 usuários estão usando IMEs Herdadas de terceiros que não funcionarão com o aplicativo protegido.

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 um componente do modo kernel, ele é frequentemente direcionado como um vetor de escape para aplicativos que são sandboxed. 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 navegadores modernos usam o isolamento do processo e incorporam processos que não são da interface do usuário. Qualquer aplicativo que exibe uma GUI usando um único processo será afetado por essa mitigação.

Opções de configuração

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 o aplicativo iniciar aplicativos filho por qualquer motivo, como dar suporte a hiperlinks que iniciam um navegador ou um navegador externo ou que iniciam outros utilitários no computador, a funcionalidade será interrompida com essa mitigação aplicada.

Opções de configuração

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 terá a proteção PAGE_GUARD aplicada a ela. Quando alguém tenta acessar essa memória, ela gera uma STATUS_GUARD_PAGE_VIOLATION. A mitigação manipula essa exceção e, se a instrução de acesso não passar pela validação, o processo será encerrado.

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.

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 gerenciador de memória estiver mapeando na imagem no processo, o ASLR Obrigatório rebaseará à força DLLs e EXEs que não optaram pelo 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 arquivo do Windows PE contém endereços absolutos e o compilador também gera uma [tabela de realocação base que o carregador pode usar para encontrar todas as referências de memória relativa e seu deslocamento, para que possam ser atualizadas se o binário não carregar em seu endereço base preferencial. Alguns aplicativos mais antigos tiram essas informações em builds de produção e, portanto, esses binários não podem ser rebasados. 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 contra pilha imposta por hardware

Descrição

A proteção contra pilha imposta por hardware oferece proteção robusta contra explorações ROP, pois mantém um registro do fluxo de execução pretendido de um programa. Para garantir a adoção suave do ecossistema e a compatibilidade do aplicativo, o Windows oferecerá essa proteção como um modelo opt-in, para que os desenvolvedores possam receber essa proteção, no seu próprio ritmo.

Considerações sobre compatibilidade

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

Opções de configuração

Impor para todos os módulos em vez de módulos compatíveis – você pode habilitar essa 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 a elas. Quando alguém tenta acessar essa memória, ela gera uma STATUS_GUARD_PAGE_VIOLATION. A mitigação manipula essa exceção e, se a instrução de acesso não passar pela validação, o processo será encerrado.

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

Aplicativos legítimos que executam interceptação de API podem ser detectados por essa mitigação e fazer com que alguns aplicativos falhem. Exemplos incluem shims de compatibilidade de aplicativos e software de segurança.

Opções de configuração

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. Alguns aplicativos podem ter problemas de truncamento de ponteiro se estiverem salvando ponteiros locais em variáveis de 32 bits (esperando um endereço base abaixo de 4 GB) e, portanto, serão incompatíveis com a opção de entropia alta (que pode ser desabilitada).

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. Isso ajuda a validar se as chamadas para APIs confidenciais retornarão a funções legítimas de chamador. 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

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

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. Como a lista de manipuladores é dinâmica, ela é 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.

Essa mitigação depende do design do SEH, em que cada entrada SEH contém um ponteiro para o manipulador de exceção e um ponteiro para o próximo manipulador 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 essas validações falharem, o tratamento de exceção será anulado e a exceção não será tratada.

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, alguns aplicativos são afetados por mudanças sutis no tempo, que podem se manifestar como uma condição de corrida que revela um bug multi-threading latente no aplicativo.

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 do aplicativo estiver fazendo referência a um identificador inválido, isso pode indicar que um adversário está tentando usar um identificador que ele registrou anteriormente (mas a contagem de referência de aplicativo não estaria ciente dele.) Se o aplicativo tentar usar um objeto inválido, em vez de simplesmente retornar nulo, o aplicativo gerará uma exceção (STATUS_INVALID_HANDLE).

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

Considerações sobre compatibilidade

Aplicativos que não estavam acompanhando com precisão referências de identificador e que não estavam encapsulando essas operações em manipuladores de exceção, potencialmente serão afetados por essa 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 heap ainda não estão sinalizadas como em uso
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á carregando um binário assinado pelo Windows e carrega todas as dlls das quais o binário depende, esses binários são verificados para garantir que eles também sejam assinados digitalmente como um binário do Windows. Se falharem no marcar de assinatura, o dll não será carregado e gerará uma exceção, retornando uma status de STATUS_INVALID_IMAGE_HASH.

Considerações sobre compatibilidade

Problemas de compatibilidade são incomuns. Aplicativos que dependem da substituição de binários do Windows por versões privadas locais são afetados e também há um pequeno risco de revelar bugs de tempo sutis em aplicativos com vários threads.

Opções de configuração

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 de pilha não cair entre a parte inferior e a parte superior da pilha, um evento será registrado e, se não estiver no modo de auditoria, o processo será encerrado.

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

Aplicativos que estão usando pilhas falsas são afetados e também há um pequeno risco de revelar bugs de tempo sutis em aplicativos 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

Dica

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