Referência da proteção contra exploits

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

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

Como as mitigações são aplicadas

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

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

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

Repor a proteção contra exploits

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. Em alternativa, a Microsoft fornece um ficheiro XML como parte das Linhas de Base do Segurança do Windows para repor as definições de proteção contra exploits.

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

Set-ProcessMitigation -PolicyFilePath EP-reset.xml

Segue-se o EP-reset.xml distribuído com as Linhas de Base 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 secções seguintes detalham as proteções fornecidas por cada mitigação da proteção contra exploits, as considerações de compatibilidade para a mitigação e as opções de configuração disponíveis.

Proteção de código arbitrário

Descrição

O proteção de código arbitrário ajuda a proteger contra um atacante malicioso que carrega o código da sua preferência para a memória através de uma vulnerabilidade de segurança de memória e pode executar esse código.

O code guard arbitrário protege uma aplicação de executar código gerado dinamicamente (código que não é carregado, por exemplo, do próprio exe ou de um dll). 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 alocação tentar incluir o sinalizador executar proteção, a alocação de memória falhará e devolverá 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 incluir o sinalizador executar proteção, a alteração de permissão falhará e devolverá um código de erro (STATUS_DYNAMIC_CODE_BLOCKED).

Ao impedir que o sinalizador de execução seja definido, a funcionalidade de prevenção de execução de dados de Windows 10 e Windows 11 pode, em seguida, proteger contra o ponteiro de instruções que está a ser definido para essa memória e executar esse código.

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.

Apenas auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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 Defender para Ponto Final.

Bloquear imagens de integridade baixa

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 aplicação exigir o carregamento de imagens que são transferidas, deve certificar-se de que são transferidas de um processo de maior confiança ou que são explicitamente reativadas para aplicar esta mitigação.

Opções de configuração

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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

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 a imagem for determinada como num dispositivo remoto. É implementado pelo gestor de memória, o que impede que o ficheiro seja mapeado para a memória. Se uma aplicação tentar mapear um ficheiro remoto, aciona um erro de STATUS_ACCESS_DENIED.

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

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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 tipos de letra não fidedignos

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 é além da mitigação incorporada fornecida no Windows 10 1607 e posterior e Windows 11, que move a análise do tipo de letra do kernel para um contentor de aplicações de 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. Para obter detalhes sobre esta mitigação, veja o blogue Hardening Windows 10 with zero day exploit mitigations (Proteção de Windows 10 com mitigações de exploração de zero dias).

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 browsers legados, como o Internet Explorer 11 (e o modo IE no novo Microsoft Edge) podem ser afetados, especialmente com aplicações como Office 365, que utilizam glifos de tipo de letra para apresentar a IU.

Opções de configuração

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.

Proteção de integridade do código

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. O code integrity guard inclui assinaturas WHQL (Windows Hardware Quality Labs), o que permite que os controladores aprovados pela WHQL sejam 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 esteja assinado pela Microsoft, a manjedoura de memória devolve o 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.

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.

Proteção do fluxo de controlo (CFG)

Descrição

O proteção de fluxo de controlo (CFG) mitiga o risco de os atacantes utilizarem vulnerabilidades de danos na memória ao proteger chamadas de funções indiretas. Por exemplo, um atacante pode utilizar uma vulnerabilidade de capacidade excedida da memória intermédia para substituir a memória que contém um ponteiro de função e substituir esse ponteiro de função por um ponteiro para o código executável à sua escolha (que também pode ser injetado no programa).

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.

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

Descrição

A prevenção de execução de dados (DEP) impede que a memória que não foi explicitamente alocada como executável seja executada. 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 de configuração desativa 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, utilizaria uma técnica chamada thunking. O thunking é normalmente pensado para interagir entre aplicações de 32 bits e de 16 bits, mas não existem componentes de 16 bits no ATL aqui. Em vez disso, para otimizar o tamanho binário, o ATL armazena código de máquina na memória que não está alinhado com palavras (criando um binário mais pequeno) e, em seguida, invoca diretamente esse código. Os componentes ATL compilados com o Visual Studio 7.1 ou anterior (Visual Studio 2003) não atribuem esta memória como executável . A emulação thunk resolve esse problema de compatibilidade. As aplicações que têm um modelo de extensão binária (como o Internet Explorer 11) precisam de ter a emulação ATL Thunk ativada.

Desativar pontos de extensão

Descrição

Esta mitigação desativa vários pontos de extensão para uma aplicação, que podem ser utilizados para estabelecer persistência ou elevar privilégios de conteúdo malicioso.

Isto inclui:

• DLLs do AppInit – sempre que um processo é iniciado, o sistema carrega a DLL especificada para o contexto do processo iniciado recentemente antes de chamar a função de ponto de entrada. Os detalhes sobre DLLs appInit podem ser encontrados aqui. Com esta mitigação aplicada, os DLLs appInit não são carregados. A partir do Windows 7, 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 Legados – um método de entrada Revisor (IME) permite que um utilizador escreva texto num idioma com mais carateres do que os que podem ser representados num teclado. Terceiros são capazes de criar MI. 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.
• Hooks de Eventos do Windows – uma aplicação pode chamar a API SetWinEventHook para registar o interesse num evento que está a decorrer. É 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 consideração é se os utilizadores estiverem a utilizar MI Legadas que não sejam da Microsoft que não funcionem com a aplicação protegida.

Opções de configuração

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

Desativar chamadas do sistema Win32k

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 que não são processos de IU. Por exemplo, muitos browsers modernos utilizam o isolamento de processos e incorporam processos não IU. Qualquer aplicação que apresente uma GUI com um único processo será afetada por esta mitigação.

Opções de configuração

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.

Não permitir processos subordinados

Descrição

Esta mitigação impede que uma aplicação crie novas aplicações subordinadas. Uma técnica comum utilizada pelos adversários é iniciar um processo fidedigno no dispositivo com entrada maliciosa (um ataque "vivendo da terra"), que muitas vezes requer o lançamento de outra aplicação no dispositivo. Se não existirem razões legítimas para uma aplicação iniciar um processo subordinado, esta mitigação mitiga esse potencial vetor de ataque. A mitigação é aplicada ao definir uma propriedade no token do processo, o que bloqueia a criação de um token para o processo subordinado com a mensagem de erro STATUS_CHILD_PROCESS_BLOCKED.

Considerações de compatibilidade

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

Opções de configuração

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.

Exportar filtragem de endereços

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.

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.

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

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 uma nova base de todas as DLLs no processo. Um programador pode ativar o ASLR com a opção /DYNAMICBASE linker e esta mitigação tem o mesmo efeito.

Quando o gestor de memória está a mapear a imagem para o processo, o ASLR obrigatório irá forçar a nova base de DLLs e EXEs que não optaram por participar no ASLR. Tenha em atenção, no entanto, que esta rebastação não tem entropia e, portanto, pode ser colocada numa localização previsível na memória. Para a localização rebasada e aleatória de binários, esta mitigação deve ser emparelhada com alocações de memória aleatórias (ASLR inferior).

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).

Proteção de pilha imposta por hardware

Descrição

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

Considerações 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 com base no .NET Framework, a proteção de pilha imposta por hardware funciona com .NET Framework 7 (optar ativamente por participar) ou mais recente. 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

Apenas auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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 Defender para Ponto Final.

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

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

Descrição

A mitigação 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 shims de compatibilidade de aplicações.

Opções de configuração

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.

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

Descrição

Aleatoriamente, as alocações de memória (ASLR de baixo para cima) adicionam entropia às relocalizações, pelo que a sua localização é aleatória e, portanto, menos previsível. Esta mitigação requer que o ASLR obrigatório 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 compatíveis com o ASLR obrigatório (rebasing) também são compatíveis com a outra entropia do ASLR de baixo para cima. Algumas aplicações podem ter problemas de truncagem de ponteiros se estiverem a guardar ponteiros locais em variáveis de 32 bits (esperando um endereço base inferior a 4 GB) e, portanto, serão incompatíveis com a opção de entropia elevada (que pode ser desativada).

Opções de configuração

Não 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.

Simular exceção (SimExec)

Descrição

A execução simulada (SimExec) é uma mitigação apenas para aplicações de 32 bits. Isto ajuda a validar que as chamadas para APIs confidenciais regressam às funções de autor da chamada 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 anda para trás na memória para encontrar a instrução CHAMADA anterior para determinar se a função e a instrução CHAMAR correspondem 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 detetada uma miniaplicação ROP, o processo é terminado.

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

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.

Validar invocação de API (CallerCheck)

Descrição

Validar invocação de API (CallerCheck) é uma mitigação para técnicas de programação orientada para devolução (ROP) que valida que as APIs confidenciais foram chamadas a partir de um chamador válido. Esta mitigação inspeciona o endereço devolvido transmitido e, em seguida, desmonta-se 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 transmitido para a 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 detetada uma miniaplicação ROP, o processo é terminado.

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

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.

Validar cadeias de exceção (SEHOP)

Descrição

Validar cadeias de exceção (SEHOP) são uma mitigação contra a técnica de exploração de substituição do Processador de Exceções Estruturadas (SEH ). O processamento de exceções estruturados é o processo pelo qual uma aplicação pode pedir para processar 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. Uma vez que a lista de processadores é dinâmica, é armazenada na pilha. Um atacante pode utilizar uma vulnerabilidade de capacidade excedida de pilha para, em seguida, substituir o processador de exceções por um ponteiro para o código da 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
• Não existem ponteiros do processador de exceções a apontar 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. É incomum uma aplicação assumir uma dependência de danificar a cadeia de exceções. No entanto, algumas aplicações são afetadas pelas alterações subtis na temporização, que podem manifestar-se como uma condição race que revela um erro latente de multi-threading na aplicação.

Opções de configuração

Validar utilização de identificador

Descrição

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

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

Validar integridade da área dinâmica para dados

Descrição

A mitigação da integridade da área dinâmica para dados de validação aumenta o nível de proteção de mitigações de área dinâmica para dados no Windows, fazendo com que a aplicação termine se for detetado um dano na área dinâmica para dados. As mitigações incluem:

• Impedir que uma alça HEAP seja libertada
• Efetuar outra validação em cabeçalhos de bloco expandido para alocações de área dinâmica para dados
• Verificar se as alocações de área dinâmica para dados ainda não estão sinalizadas como em utilização
• Adicionar páginas de proteção a alocações grandes, segmentos de área dinâmica para dados 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

Validar integridade da dependência 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

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.

Validar integridade da pilha (StackPivot)

Descrição

A mitigação da validação da integridade da pilha (StackPivot) ajuda a proteger contra o ataque do Stack Pivot, um ataque ROP em que um atacante cria uma pilha falsa na memória de área dinâmica para dados e, em seguida, engana a aplicação para regressar à pilha falsa que controla 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

Apenas Auditoria – pode ativar esta mitigação no modo de auditoria para medir a potencial compatibilidade afetada 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.