Referência da proteção contra exploits

Aplica-se a: Microsoft Defender for Endpoint Plan 1, Microsoft Defender for Endpoint Plan 2

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 medidas de mitigação da proteção contra exploits são aplicadas a cada aplicação.

Cada programa tem a sua própria entrada no registo que controla quais as mitigações aplicáveis. Estas definições estão armazenadas na entrada do registo MitigationOptions (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\*ImageFileName*\MitigationOptions). Estas definições de mitigação entram em vigor quando reinicia o programa. Mantêm-se ativas até as alterares e reiniciares o programa.

Importante

As opções de execução de ficheiros de imagem só permitem especificar um nome ou caminho de ficheiro. Não podes especificar um número de versão, arquitetura ou qualquer outro diferenciador. Direcionar mitigações para aplicações que tenham nomes ou caminhos únicos. Aplica-as apenas em dispositivos onde testaste essa versão e arquitetura da aplicação.

Pode configurar mitigações através de um ficheiro XML usando PowerShell, Group Policy ou MDM. Quando usa um ficheiro XML, o sistema define as entradas do registo por si.

Repor a proteção contra exploits

Importante

Quando a Política de Grupo ou MDM que implementa o ficheiro XML deixa de ser aplicada, as definições implementadas por este ficheiro de configuração XML não serão automaticamente removidas.

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

Para redefinir as definições de proteção contra exploits usando o PowerShell, execute o seguinte comando para aplicar a política de reset do ficheiro XML e restaurar as definições de mitigação aos seus valores predefinidos:

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

O ficheiro XML seguinte é o EP-reset.xml distribuído com as Segurança do Windows Baselines. Este ficheiro define sobreposições de mitigação por aplicação que redefinem as definições de proteção contra exploits para os seus valores predefinidos para aplicações comuns como Microsoft Office, navegadores web e leitores multimédia:

<?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 seguintes mitigações de proteção contra exploits incluem cada uma uma descrição, considerações de compatibilidade e opções de configuração.

Proteção de código arbitrário

As secções seguintes descrevem como funciona o code guard arbitrário, o seu impacto na compatibilidade e as opções de configuração.

Descrição

A proteção contra código arbitrário ajuda a proteger contra um atacante malicioso que consiga carregar, na memória, código à sua escolha através de uma vulnerabilidade de segurança da memória e executá-lo.

A proteção contra código arbitrário impede uma aplicação de executar código gerado dinamicamente (código que não é carregado, por exemplo, a partir do próprio EXE ou de uma DLL). O proteção de código arbitrário funciona ao impedir que a memória seja marcada como executável. Quando uma aplicação tenta alocar memória, verificamos os sinalizadores de proteção. (A memória pode ser alocada com sinalizadores de proteção de leitura, escrita e/ou execução.) Se a tentativa de alocação incluir o sinalizador de proteção de execução, a alocação de memória falha e devolve um código de erro (STATUS_DYNAMIC_CODE_BLOCKED). Da mesma forma, se uma aplicação tentar alterar os sinalizadores de proteção da memória que já foi alocada e que inclui o sinalizador de proteção executar, a alteração das permissões falhará e devolverá um código de erro (STATUS_DYNAMIC_CODE_BLOCKED).

Ao impedir que o sinalizador de executar seja definido, a funcionalidade de prevenção da execução de dados do Windows 10 e do Windows 11 pode impedir que o ponteiro de instruções seja definido para essa memória e que esse código seja executado.

Considerações de 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 Just-in-Time (JIT). 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 que o thread opte ativamente por não participar – pode configurar a mitigação para permitir que um thread individual opte ativamente por não participar nesta 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.

Só auditoria - Pode ativar esta mitigação no modo de auditoria para medir o potencial impacto na compatibilidade de uma aplicação. Em seguida, os eventos de auditoria podem ser consultados quer no Visualizador de Eventos quer utilizando a Pesquisa Avançada no Defender for Endpoint.

Bloquear imagens de integridade baixa

As secções seguintes descrevem como funcionam as imagens de baixa integridade em blocos, o seu impacto na compatibilidade e as opções de configuração.

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 Controlo de Acesso (ACE) que concede acesso a processos IL baixos e que não tem 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 funcionam os níveis de integridade, veja Controlo de Integridade Obrigatório.

Considerações de 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 sua aplicação exigir o carregamento de imagens descarregadas, deve certificar-se de que estas são descarregadas a partir de um processo de maior confiança ou explicitamente reetiquetadas para que esta mitigação seja aplicada.

Opções de configuração

Só auditoria - Pode ativar esta mitigação no modo de auditoria para medir o potencial impacto na compatibilidade numa aplicação. Em seguida, os eventos de auditoria podem ser visualizados no visualizador de eventos ou através da Investigação Avançada no Microsoft Defender para Endpoint.

Bloquear imagens remotas

As secções seguintes descrevem como funciona o bloqueio de imagens remotas, o seu impacto na compatibilidade e as respetivas opções de configuração.

Descrição

Bloquear imagens remotas ajuda a impedir que a aplicação carregue ficheiros alojados num dispositivo remoto, como uma partilha UNC. Bloquear imagens remotas ajuda a proteger contra o carregamento de binários para a memória que estão num dispositivo externo controlado pelo atacante.

Esta mitigação bloqueia o carregamento da imagem se se determinar que a imagem está 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 de compatibilidade

Bloquear imagens remotas impede que a aplicação carregue imagens de dispositivos remotos. Se a sua aplicação carregar ficheiros ou plug-ins a partir de dispositivos remotos, não será compatível com esta mitigação.

Opções de configuração

Bloquear tipos de letra não fidedignos

As secções seguintes descrevem como funcionam as fontes de bloco não confiáveis, o seu impacto na compatibilidade e as opções de configuração.

Descrição

Bloquear tipos de letra não fidedignos mitiga o risco de uma falha na análise de tipos de letra, o que leva a que o atacante possa executar código no dispositivo. Apenas os tipos de letra instalados no diretório windows\fonts serão carregados para processamento por GDI.

Esta mitigação é implementada no GDI, que valida a localização do ficheiro. 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 a chamada falhará.

Esta mitigação soma-se à mitigação integrada fornecida no Windows 10, versão 1607 e posteriores, e no Windows 11, que retira o processamento de tipos de letra do kernel e o coloca num contentor de aplicações em modo de utilizador. Qualquer exploração baseada na análise de tipos de letra, como resultado, ocorre num contexto em sandbox e isolado, o que reduz significativamente o risco.

Considerações de compatibilidade

A utilização mais comum de tipos de letra fora do diretório de tipos de letra do sistema é com tipos de letra Web. Os browsers modernos, como o Microsoft Edge, utilizam DirectWrite em vez de GDI e não são afetados. No entanto, os navegadores antigos, como o Internet Explorer 11 (e o modo IE no novo Microsoft Edge), podem ser afetados, sobretudo em aplicações como o Office 365, que utilizam glifos de tipos de letra para apresentar a interface de utilizador.

Opções de configuração

Proteção de integridade do código

As secções seguintes descrevem como funciona o code integrity guard, o seu impacto na compatibilidade e as opções de configuração.

Descrição

A proteção de integridade do código garante que todos os binários carregados num processo são assinados digitalmente pela Microsoft. A proteção da integridade do código inclui as assinaturas WHQL (Windows Hardware Quality Labs), o que permite que os controladores aprovados pela WHQL possam ser executados no processo.

Esta mitigação é implementada no gestor de memória, o que impede que o binário seja mapeado para a memória. Se tentar carregar um binário que não tenha sido assinado pela Microsoft, o gestor de memória devolve o código de erro STATUS_INVALID_IMAGE_HASH. Ao bloquear ao nível do gestor de memória, isto impede ambos os binários carregados pelo processo e os binários injetados no processo.

Considerações de 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.

Proteção do Fluxo de Controlo (CFG)

As secções seguintes descrevem como funciona o control flow guard, o seu impacto na compatibilidade e as opções de configuração.

Descrição

A proteção do fluxo de controlo (CFG) mitiga o risco de os atacantes explorarem vulnerabilidades de corrupção de memória ao proteger as chamadas indiretas de funções. Por exemplo, um atacante pode explorar uma vulnerabilidade de transbordo de memória intermédia para sobrescrever a memória que contém um ponteiro de função e substituir esse ponteiro de função por um ponteiro para código executável à sua escolha (que também pode ser injetado no programa).

Esta mitigação é fornecida ao injetar outra verificação no momento da 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. Como tal, apenas as aplicações compiladas com suporte do CFG podem beneficiar desta mitigação.

A verificação de um destino válido é fornecida pelo kernel do Windows. Quando os ficheiros executáveis são carregados, os metadados para destinos de chamadas indiretas são extraídos no momento da carga e marcados como destinos de chamada válidos. Além disso, quando a memória é alocada e marcada como executável (por exemplo, para código gerado), estas localizações de memória também são marcadas como destinos de chamada válidos, para suportar mecanismos como a compilação JIT.

Considerações de compatibilidade

Uma vez que as aplicações têm de ser compiladas para suportar o CFG, declaram implicitamente a sua compatibilidade com o mesmo. Por conseguinte, a maioria das aplicações deve trabalhar com esta mitigação ativada. Uma vez que estas verificações são compiladas no binário, a configuração que pode aplicar é apenas para desativar as verificações no 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

Utilizar CFG restrito – no modo restrito, todos os binários carregados para o processo têm de ser compilados para o Control Flow Guard (ou não têm código executável nos mesmos, como dlls de recursos) para serem carregados.

Nota

Proteção do fluxo de controlo não tem modo de auditoria. Os binários são compilados com esta mitigação ativada.

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

As secções seguintes descrevem como funciona a Prevenção de Execução de Dados, o seu impacto na compatibilidade e as opções de configuração.

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. O DEP ajuda a proteger contra um atacante que injeta código malicioso no processo, tal como através de uma capacidade excedida da memória intermédia 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 de compatibilidade

Todos os executáveis x64, ARM e Arm64 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 o DEP ativado por predefinição, mas o DEP pode ser desativado por processo. Algumas aplicações antigas legadas, normalmente as aplicações desenvolvidas antes do Windows XP SP2, podem não ser compatíveis com o DEP. Normalmente, estas aplicações geram código dinamicamente (por exemplo, compilação JIT) ou ligam a bibliotecas mais antigas (como versões mais antigas do ATL) que geram código dinamicamente.

Opções de configuração

Ativar a emulação ATL Thunk - Esta opção controla a emulação ATL Thunk. O ATL, a Biblioteca de Modelos ActiveX, foi concebido para ser o mais pequeno e rápido possível. Para reduzir o tamanho binário, utiliza uma técnica chamada thunking. Thunking está frequentemente associado à interação entre 32 e 16 bits, mas o ATL não tem componentes de 16 bits. Em vez disso, para poupar espaço, o ATL armazena código máquina na memória que não está alinhado com palavras. Isto cria um binário menor. A ATL então executa esse código diretamente. As versões ATL compiladas com Visual Studio 7.1 ou anteriores (Visual Studio 2003) não marcam esta memória como executável. A emulação de Thunk resolve esse problema. Aplicações com um modelo de extensão binária (como o Internet Explorer 11) precisam de emulação ATL Thunk ativada.

Desativar pontos de extensão

As secções seguintes descrevem como funciona a mitigação de desativação dos pontos de extensão, o impacto na compatibilidade e as opções de configuração.

Descrição

A mitigação «Disable extension points» desativa vários pontos de extensão numa aplicação, que podem ser utilizados para garantir persistência ou elevar privilégios de código malicioso.

Isto inclui:

DLLs do AppInit - Sempre que um processo é iniciado, o sistema carrega a DLL especificada no contexto do processo acabado de iniciar antes de chamar a sua função de entrada. Os detalhes sobre DLLs appInit podem ser encontrados aqui. Com esta mitigação aplicada, as bibliotecas DLL AppInit não são carregadas. A partir do Windows 7, os DLLs appInit têm de ser assinados 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.
IMEs antigos - Um editor de método de entrada (IME) permite a um utilizador escrever texto numa língua com mais carateres do que os que podem ser representados num teclado. As terceiras partes podem criar IMEs. Um IME malicioso pode obter credenciais ou outras informações confidenciais desta 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.
Intercetores de eventos do Windows - Uma aplicação pode chamar a API SetWinEventHook para registar interesse na ocorrência de um evento. É especificada uma DLL e pode ser injetada no processo. Esta mitigação força o hook a ser publicado no processo de registo em vez de ser executado em processo através de uma DLL injetada.

Considerações de compatibilidade

A maioria destes pontos de extensão são relativamente pouco utilizados, pelo que o efeito de compatibilidade é normalmente pequeno, particularmente ao nível da aplicação individual. A única questão a ter em conta é que, caso os utilizadores utilizem IMEs legados que não sejam da Microsoft, estes não funcionarão com a aplicação protegida.

Opções de configuração

Não existem opções de configuração para esta mitigação.

Nota

Desativar pontos de extensão não dispõe de modo de auditoria.

Desativar chamadas do sistema Win32k

As secções seguintes descrevem como funciona a mitigação de desativação das chamadas de sistema Win32k, o impacto na compatibilidade e as respetivas opções de configuração.

Descrição

Win32k.sys fornece uma ampla superfície de ataque para um atacante. Como componente do modo kernel, é frequentemente direcionado como um vetor de escape para aplicações em sandbox. Esta mitigação impede as chamadas para win32k.sys ao bloquear a conversão de um thread num thread GUI, ao qual é concedido acesso para invocar funções Win32k. Um thread não é GUI quando criado, mas convertido na primeira chamada para win32k.sys ou através de uma chamada à API para IsGuiThread.

Considerações de compatibilidade

Esta mitigação foi concebida para processos dedicados sem interface de utilizador. Por exemplo, muitos navegadores modernos utilizam isolamento de processos e incluem processos sem interface de utilizador. Qualquer aplicação que apresente uma GUI com um único processo será afetada por esta mitigação.

Opções de configuração

Não permitir processos filhos

As secções seguintes descrevem como funciona a mitigação «Não permitir processos subordinados», o respetivo impacto na compatibilidade e as respetivas opções de configuração.

Descrição

A mitigação "Não permitir processos subordinados" impede que uma aplicação crie novos processos subordinados. Uma técnica comum utilizada pelos adversários consiste em iniciar um processo de confiança no dispositivo com dados maliciosos (um ataque de tipo «living off the land»), o que muitas vezes requer iniciar outra aplicação no dispositivo. Se não existirem razões legítimas para uma aplicação iniciar um processo filho, esta mitigação mitiga esse vetor de ataque potencial. A mitigação é aplicada através da definição de uma propriedade no token do processo, bloqueando a criação de um token para o processo filho com a mensagem de erro STATUS_CHILD_PROCESS_BLOCKED.

Considerações de compatibilidade

Se a sua aplicação iniciar aplicações-filhas por qualquer motivo, por exemplo, para suportar hiperligações que abram um navegador ou um navegador externo, ou que iniciem outros utilitários no computador, esta funcionalidade deixa de funcionar quando esta mitigação é aplicada.

Opções de configuração

Exportar filtragem de endereços

As secções seguintes descrevem como funciona a filtragem de endereços de exportação, o seu impacto na compatibilidade e as opções de configuração.

Descrição

A filtragem de endereços de exportação (EAF) mitiga o risco de código malicioso ao analisar a tabela de endereços de exportação de todos os módulos carregados para encontrar módulos que contenham APIs úteis para o ataque. Esta é uma tática comum utilizada pelo shellcode. Para mitigar o risco de tal ataque, esta mitigação protege três módulos frequentemente 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 a tabela de endereços de exportação. 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 de compatibilidade

Esta mitigação é principalmente um problema para aplicações como depuradores, aplicações em sandbox, aplicações que utilizam DRM ou aplicações que implementam tecnologia anti-depuração.

Opções de configuração

Validar o acesso a módulos que são frequentemente abusados por exploits – esta opção, também conhecida como EAF+, adiciona proteções para outros módulos frequentemente 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 ativar o EAF+, esta mitigação adiciona a proteção de PAGE_GUARD à página que contém o cabeçalho "MZ", os primeiros 2 bytes do cabeçalho dos DOS num ficheiro PE, este é um aspeto do conteúdo de memória conhecido que o shellcode pode procurar para identificar módulos potencialmente interessantes na memória.

Forçar a aleatoriedade de imagens (ASLR Obrigatório)

As secções seguintes descrevem como funciona a ASLR Obrigatória, o seu impacto na compatibilidade e as opções de configuração.

Descrição

A Aleatoriedade do Esquema de Espaço de Endereços (ASLR) mitiga o risco de um atacante utilizar o respetivo conhecimento do esquema 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. Isto pode mitigar o risco de um atacante utilizar técnicas como ataques return-to-libc, em que o adversário define o contexto e, em seguida, modifica o endereço de retorno para executar o código existente com contexto que se adequa à finalidade do adversário.

O ASLR obrigatório força a redefinição da base de todas as DLLs dentro do processo. Um programador pode ativar o ASLR utilizando a opção /DYNAMICBASE do linker, e esta mitigação produz o mesmo efeito.

Quando o gestor de memória está a mapear a imagem no processo, o ASLR obrigatório forçará a alteração do endereço base de DLLs e EXEs que não aderiram ao ASLR. Tenha em atenção, no entanto, que este rebaseamento não tem qualquer entropia e, portanto, pode ser colocado num local previsível da memória. Para a localização aleatorizada e com rebase dos binários, esta mitigação deve ser combinada com Aleatorizar as alocações de memória (ASLR ascendente).

Considerações de compatibilidade

Este efeito de compatibilidade do ASLR está normalmente limitado a aplicações mais antigas que foram criadas com compiladores que fizeram suposições sobre o endereço base de um ficheiro binário ou que despojaram informações de reposicionamento base. Isto pode originar erros imprevisíveis à medida que o fluxo de execução tenta passar para a localização esperada, em vez da localização real na memória.

Opções de configuração

Não permitir imagens despojadas – esta opção bloqueia o carregamento de imagens que têm informações de reposicionamento 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. Esta mitigação impede que esses binários sejam carregados (em vez de permitir que carreguem no endereço base preferido).

Nota

A aleatoriedade forçada para imagens (ASLR obrigatório) não tem o modo de auditoria.

Proteção de pilha imposta por hardware

Descrição

A proteção da pilha garantida por hardware oferece uma proteção robusta contra ataques ROP. Funciona mantendo um registo do fluxo de execução pretendido de um programa. Para apoiar uma adoção fluida e compatibilidade com aplicações, o Windows oferece esta proteção como modelo opt-in. Os programadores podem ativá-lo ao seu próprio ritmo.

Considerações de 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.

Se executar aplicações baseadas no .NET Framework, a proteção da pilha imposta por hardware funciona com o .NET Framework 7 (adesão opcional) ou posterior. Se utilizar uma versão mais antiga, poderá deparar-se com falhas ou utilização elevada da CPU. Estes problemas também podem ocorrer no modo de auditoria ou ao filtrar apenas módulos compatíveis.

Opções de configuração

Aplicar a todos os módulos em vez de módulos compatíveis - Pode ativar esta mitigação para se aplicar a todos os módulos, em vez de módulos compatíveis.

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

Descrição

A mitigação da filtragem de endereços de importação (IAF) ajuda a mitigar o risco de um adversário alterar o fluxo de controlo de uma aplicação ao modificar a tabela de endereços de importação (IAT) para redirecionar para o código arbitrário à escolha do atacante quando essa função é chamada. Um atacante pode utilizar esta abordagem para sequestrar o controlo ou para intercetar, inspecionar e potencialmente bloquear chamadas a 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.

Esta 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 de 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. Os exemplos incluem software de segurança e camadas de compatibilidade de aplicações.

Opções de configuração

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

Descrição

A aleatorização das alocações de memória (ASLR ascendente) acrescenta entropia às relocalizações, pelo que a sua localização é aleatorizada e, por conseguinte, menos previsível. Esta mitigação requer que a ASLR obrigatória entre em vigor.

O tamanho do espaço de endereços de 32 bits coloca restrições práticas na entropia que pode ser adicionada e, portanto, as aplicações de 64 bits tornam mais difícil para um atacante adivinhar uma localização na memória.

Considerações de compatibilidade

A maioria das aplicações que funcionam com ASLR obrigatório (rebaseing) também funciona com ASLR de baixo para cima. Algumas aplicações podem ter problemas de truncamento do ponteiro se guardarem ponteiros locais em variáveis de 32 bits. Estas aplicações esperam um endereço base abaixo de 4 GB, por isso não funcionam com a opção de alta entropia. Podes desativar a entropia alta se necessário.

Opções de configuração

Não utilize entropia elevada - esta opção desativa o uso de ASLR de alta entropia, que adiciona 24 bits de entropia (1 TB de variância) na alocação de baixo para cima para aplicações de 64 bits.

Nota

As alocações de memória aleatórias (ASLR de baixo para cima) não têm modo de auditoria.

Simular execução (SimExec)

Descrição

A execução simulada (SimExec) é uma mitigação apenas para aplicações de 32 bits. Isto ajuda a validar se as chamadas a APIs sensíveis retornam a funções chamadoras legítimas. Fá-lo intercetando chamadas em APIs confidenciais e, em seguida, simulando a execução dessas APIs, percorrendo as instruções de linguagem de assemblagem codificadas que procuram a instrução RET, que deve regressar ao autor da chamada. Em seguida, inspeciona essa função e recua na memória para encontrar a instrução CALL anterior, para determinar se a função e a instrução CALL coincidem e se o RET não foi intercetado.

As APIs interceptadas por esta 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 for detetado um gadget ROP, o processo é encerrado.

Considerações de compatibilidade

As aplicações que executam a intercepção de API, particularmente o software de segurança, podem causar problemas de compatibilidade com esta mitigação.

Esta mitigação é incompatível com a mitigação arbitrária do Code Guard.

Opções de configuração

Validar invocação de API (CallerCheck)

Descrição

A validação da invocação da API (CallerCheck) é uma mitigação para técnicas de programação orientada para retorno (ROP), que verifica se as APIs sensíveis foram chamadas a partir de uma origem válida. Esta mitigação inspeciona o endereço de retorno passado e, em seguida, efetua uma desassemblagem heurística para trás para encontrar uma chamada acima do endereço de retorno, de modo a determinar se o alvo da chamada corresponde ao parâmetro passado à função.

As APIs interceptadas por esta 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 for detetado um gadget ROP, o processo é encerrado.

Considerações de compatibilidade

As aplicações que executam a intercepção de API, particularmente o software de segurança, podem causar problemas de compatibilidade com esta mitigação.

Esta mitigação é incompatível com a mitigação arbitrária do Code Guard.

Opções de configuração

Validar cadeias de exceção (SEHOP)

Descrição

A validação de cadeias de exceção (SEHOP) é uma mitigação contra a técnica de exploração de sobrescrita do Structured Exception Handler (SEH). O tratamento estruturado de exceções é o processo pelo qual uma aplicação pode pedir para tratar uma exceção específica. Os processadores de exceções são ligados em conjunto, pelo que, se um processador de exceções optar por não processar uma exceção específica, pode ser transmitido para o processador de exceções seguinte na cadeia até que se decida processá-la. Como a lista de manipuladores é dinâmica, é armazenada na pilha. Um atacante pode explorar uma vulnerabilidade de transbordo da pilha para depois substituir o manipulador de exceções por um ponteiro para o código à escolha do atacante.

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. Esta mitigação é chamada pelo distribuidor de exceções, que valida a cadeia SEH quando é invocada uma exceção. Verifica se:

Todos os registos da cadeia de exceções estão dentro dos limites da pilha
Todos os registos de exceção estão alinhados
Nenhum ponteiro para manipulador de exceção aponta para a pilha
Não existem ponteiros para trás
A cadeia de exceções termina num processador de exceções final conhecido

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

Considerações de compatibilidade

Os problemas de compatibilidade com o SEHOP são relativamente raros. É invulgar que uma aplicação dependa de corromper a cadeia de exceções. No entanto, algumas aplicações são afetadas por alterações subtis na temporização, que se podem manifestar como uma condição de corrida que expõe um erro latente de multithreading na aplicação.

Opções de configuração

Nota

Validar cadeias de exceção (SEHOP) não dispõe de modo de auditoria.

Validar a utilização do manipulador

Descrição

Validar a utilização do handle é uma medida de mitigação que ajuda a proteger contra um atacante que utilize um handle existente para aceder a um objeto protegido. Um handle é uma referência a um objeto protegido. Se o código da aplicação estiver a referenciar um manipulador inválido, isso pode indicar que um adversário está a tentar utilizar um manipulador que tenha registado anteriormente (mas do qual a contagem de referências da aplicação 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).

Esta mitigação é aplicada automaticamente às aplicações da Loja Windows.

Considerações de 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

Nota

Validar a utilização do manipulador não tem modo de auditoria.

Validar a integridade da heap

Descrição

A mitigação validar a integridade da heap aumenta o nível de proteção das mitigações da heap no Windows, fazendo com que a aplicação seja terminada se for detetada corrupção da heap. As mitigações incluem:

Impedir que um identificador HEAP seja libertado
Realizar outra validação nos cabeçalhos de bloco estendidos para alocações em memória dinâmica
Verificar se as alocações na heap já não estão assinaladas como estando em utilização
Adição de páginas de proteção a alocações grandes, segmentos da heap e subsegmentos acima de um tamanho mínimo

Considerações de compatibilidade

Esta mitigação já está aplicada por predefinição para aplicações de 64 bits e para aplicações de 32 bits destinadas ao Windows Vista ou posterior. As aplicações legadas do Windows XP ou anteriores estão mais em risco, embora os problemas de compatibilidade sejam raros.

Opções de configuração

Nota

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

Validar a integridade das dependências da imagem

Descrição

A mitigação da dependência de imagem validada ajuda a proteger contra ataques que tentam substituir o código por dlls que estão estaticamente ligados por binários do Windows. A técnica de plantação de DLL abusa do mecanismo de pesquisa do carregador para injetar código malicioso, que pode ser utilizado para executar código malicioso num 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 falharem a verificação da assinatura, a dll não será carregada e emitirá uma exceção, devolvendo um estado de STATUS_INVALID_IMAGE_HASH.

Considerações de compatibilidade

Os problemas de compatibilidade são invulgares. 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

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 Stack Pivot, um ataque ROP em que um atacante cria uma pilha falsa na memória heap e, em seguida, engana a aplicação para retornar para a pilha falsa, que passa a controlar o fluxo de execução.

Esta mitigação interceta muitas APIs do Windows e inspeciona o valor do ponteiro da 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 esta 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 de 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. As aplicações que executam a intercepção de API, particularmente o software de segurança, podem causar problemas de compatibilidade com esta mitigação.

Esta mitigação é incompatível com a mitigação arbitrária do Code Guard.

Opções de configuração

Comentários

Esta página foi útil?

Last updated on 2026-07-29