Exclusões no Defender: falsos positivos por pasta e hash (ASR e AV)

Um agente de backup que desaparece do agendamento, uma aplicação interna que abre com o nome de um Trojan, um instalador de ferramenta legítima que a protecção em tempo real insiste em isolar — o padrão repete-se em todas as PME: o Defender bloqueia algo legítimo e a equipa precisa de resolver sem afastar a protecção do resto. A resposta certa não é desligar a protecção, é excluir o mais estreitamente possível — e quando a precisão pedida é um único ficheiro, o mecanismo até muda de sítio: a exclusão por hash vive nos indicadores do portal, não no antivírus.

Este guia percorre a sequência: identificar o motor que bloqueou (antivírus ou regras ASR — Attack Surface Reduction, redução da superfície de ataque), escolher o tipo de exclusão com o âmbito mínimo (pasta, processo, extensão, contexto), aplicar com Add-MpPreference, validar com o MpCmdRun e, quando é um falso positivo isolado, criar o indicador de permitir (allow) por hash no portal.

O primeiro passo: descobrir de onde veio o bloqueio

Os motores de bloqueio são três, e cada um tem exclusões próprias: o antivírus (detecção por assinaturas e comportamento), as regras ASR (bloqueiam comportamentos arriscados — um Office que lança executáveis, um script ofuscado) e as restantes camadas — Device Control, Network Protection, SmartScreen — com listas próprias que as exclusões do antivírus não tocam.

Comece pelas detecções registadas, com PowerShell em modo administrador:

Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 5 InitialDetectionTime, ThreatID, Resources, ProcessName, ActionSuccess | Format-List

Saída típica (uma das detecções do histórico):

InitialDetectionTime : 14/10/2026 09:41:17
ThreatID             : 2147735127
Resources            : {C:\Apps\Lobapp\app1.dll}
ProcessName          : C:\Apps\Lobapp\setup.exe
ActionSuccess        : True

O mesmo histórico existe no Event Viewer, no log Microsoft-Windows-Windows Defender/Operational (caminho Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational):

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Defender/Operational'; Id=1116,1117,1121} -MaxEvents 6 | Select-Object TimeCreated, Id | Format-Table -AutoSize

TimeCreated             Id
-----------             --
14/10/2026 09:41:17   1116
14/10/2026 09:41:19   1117
14/10/2026 09:44:02   1121

Os IDs contam a história: 1116 reporta uma detecção de malware ou software potencialmente indesejado, 1117 a acção tomada (quarantina, remoção), 1118 uma acção que falhou e 1121 uma regra ASR que actuou em modo block. No detalhe do 1116 vêm o nome da ameaça (Name), o caminho (Path), a origem (Detection Origin) e o tipo de detecção (Detection Type). O 1121 traz ainda o campo Hashes do recurso bloqueado — guarde-o, é o valor que o IoC da secção dos indicadores pede.

Como as exclusões funcionam, e onde não chegam

As exclusões do antivírus aplicam-se aos scans agendados, aos scans on-demand, à protecção em tempo real e às detecções de PUA (aplicações potencialmente indesejadas) — com excepção das exclusões de processo, cujo âmbito é outro (secção própria mais abaixo). Não cobrem o resto do Defender for Endpoint (MDE): um ficheiro excluído continua a gerar alertas EDR (Endpoint Detection and Response) e detecções comportamentais no portal, e para excluir em todo o MDE o mecanismo é outro — os indicadores. As exclusões de processo têm efeito ainda mais largo do que parece: tiram o processo também da inspecção das regras ASR e da Network Protection.

Cada exclusão reduz a protecção: os ficheiros excluídos correm sem ser avaliados e, nas regras ASR, sem registo nenhum. Por isso a ordem de preferência da documentação é clara — resolva com a exclusão só quando não há alternativa melhor (um indicador, um ajuste de configuração da aplicação) e mantenha o âmbito mais estreito possível.

O Windows Server já traz exclusões automáticas para as funções instaladas e exclusões de ficheiros do sistema, actualizadas por inteligência de segurança. Excluir essas pastas outra vez à mão é trabalho que não faz falta.

Exclusões por pasta e ficheiro: ExclusionPath

A exclusão por caminho cobre tudo o que está sob um local, com âmbito escolhido pelo administrador: uma pasta inteira, um ficheiro único, uma árvore com wildcards.

Add-MpPreference -ExclusionPath 'C:\Apps\Agent'
Add-MpPreference -ExclusionPath 'C:\Apps\Agent\agent.exe'

Regras do caminho nas boas práticas da documentação:

• Um valor só com o nome do ficheiro (sample.exe) não isenta de forma fiável — use o caminho completo. O wildcard de caminho substitui uma pasta de cada vez: C:\*\sample.exe acerta o ficheiro apenas nas pastas de primeiro nível de C:\.
• Uma pasta exclui tudo o que está dentro, menos as subpastas que são reparse points (ligações especiais de armazenamento). Cada reparse point precisa da sua linha de exclusão, e um reparse point criado depois do serviço Defender ter arrancado só é reconhecido com reboot do Windows.
• Não exclua unidades de rede mapeadas — use o caminho UNC real.
• Variáveis de ambiente resolvem no contexto do serviço (Sistema): %APPDATA% e %USERPROFILE% desembocam no perfil do sistema, não no do utilizador. Para as pastas dos utilizadores, use caminhos completos ou %PUBLIC%.

Para listar o que está efectivamente a aplicar (a lista de extensão, caminho e processo de uma vez):

$p = Get-MpPreference; 'ExclusionExtension','ExclusionPath','ExclusionProcess' | ForEach-Object { $t = $_; $p.$t | ForEach-Object {[pscustomobject]@{Type=$t; Value=$_}} } | Format-Table -AutoSize

Type           Value
----           -----
ExclusionPath  C:\Apps\Agent
ExclusionPath  C:\Apps\Agent\agent.exe

A validação faz-se com o MpCmdRun, a ferramenta de linha de comandos que vem com a plataforma do Defender. A ferramenta fica fora do PATH: entre na pasta da versão da plataforma (a mais recente) e corra o -CheckExclusion:

# uma linha: entra na pasta da plataforma mais recente
# (sem pasta Platform, cai no %ProgramFiles%\Windows Defender)
(set "_done=" & if exist "%ProgramData%\Microsoft\Windows Defender\Platform\" (for /f "delims=" %d in ('dir "%ProgramData%\Microsoft\Windows Defender\Platform" /ad /b /o:-n 2^>nul') do if not defined _done (cd /d "%ProgramData%\Microsoft\Windows Defender\Platform\%d" & set _done=1)) else (cd /d "%ProgramFiles%\Windows Defender")) >nul 2>&1
MpCmdRun.exe -CheckExclusion -Path C:\Apps\Agent

C:\Apps\Agent [\Device\HarddiskVolume3\Apps\Agent] is excluded.

Com exit code 0 fica aplicado, com 1 não está. A resposta inclui duas margens: o resultado is excluded não lhe diz que linha da lista foi que acertou, e uma exclusão de pasta estende-se aos subdirectórios — testar C:\Apps\Agent\Logs\app.log devolve excluído pela pasta acima. O CheckExclusion exige versão de plataforma 4.18.2111-5.0 (Dezembro de 2021) ou posterior.

Para limpar: Remove-MpPreference remove o valor sem tocar nos outros, e o Set-MpPreference substitui a lista inteira do parâmetro — o Add é o seguro quando já há exclusões a respeitar. Nos parques geridos, a regra tem duas variantes: só o Intune e o Configuration Manager sobrepõem as alterações locais (e no arranque). Com GPO, as exclusões locais fundem-se por omissão com as da política — e a GPO ganha em caso de conflito: mude na política, não só no cliente.

Exclusões por processo: ExclusionProcess

A exclusão de processo não isenta um ficheiro: isenta os ficheiros que um processo abre, enquanto ele corre. O parâmetro aponta para a imagem do processo (o executável):

Add-MpPreference -ExclusionProcess 'C:\Apps\Agent\agent.exe'

Duas formas de apontar, e a escolha muda o âmbito:

• Nome da imagem (agent.exe): isenta ficheiros abertos por qualquer processo com esse nome, em qualquer caminho — inclusive de suportes removíveis. É o formato que dá margem ao ataque: um agente malicioso chama-se igual aos legítimos e aproveita a isenção.
• Caminho completo (C:\Apps\Agent\agent.exe): isenta só os ficheiros que esse processo abre. É o formato de preferir sempre.

Três nuances que confundem:

• “Excluir o processo” não isenta o executável desse processo. A exclusão cobre os ficheiros que o processo abre — o executável em si fica sujeito à inspecção; quando o problema está no próprio executável, precisa também de uma exclusão de caminho.
• O âmbito da isenção tem três respostas na documentação. A página de configuração aplica as exclusões de processo só à protecção em tempo real e à monitorização; a página de visão geral menciona também scans agendados; a página do cmdlet Add-MpPreference fala em scheduled and real-time scanning. Não conte com a exclusão de processo para isentar um scan manual: confirme o caso numa exclusão de caminho.
• Wildcard no processo existe: C:\Apps\Agent\* isenta os ficheiros que qualquer executável dessa pasta abre.

A lista da Microsoft de processos a nunca excluir (os que os invasores abusam por excelência): powershell.exe, cmd.exe, cscript.exe, wscript.exe, mshta.exe, msbuild.exe, dotnet.exe, java.exe, schtasks.exe, bitsadmin.exe, psexec.exe, svchost.exe, wmic.exe — entre outros (a página exclusões a evitar traz a lista completa).

Exclusões por extensão: ExclusionExtension

A lista de extensão é separada da lista de caminhos. Um valor como .vhd aplica-se a qualquer ficheiro com essa extensão, em toda a máquina:

Add-MpPreference -ExclusionExtension '.vhd'

O ponto inicial é opcional. O âmbito amplo é o problema: para restringir a extensão a um local, exclua por caminho com wildcard (C:\VMS\*.vhd), como a documentação indica. Use extensões de exclusão para tipos de ficheiros que a sua infra-estrutura gera isolados (um disco de máquina virtual numa pasta própria), nunca para categorias inteiras de executáveis.

Exclusões contextuais: a restrição e o seu limite

As exclusões contextuais estreitam uma exclusão de caminho com condições no fim: só num scan full, só num ficheiro, só quando um processo abre:

Exemplos directos da documentação — um .docx em qualquer pasta de primeiro nível de C:, só em scans on-demand e só como ficheiro (sem a restrição, pastas com nome .docx também ficavam isentas):

c:\*\*.docx\:{PathType:file,ScanTrigger:OnDemand}

E um executável isento só durante a análise rápida:

C:\program.exe\:{ScanType:quick,PathType:file}

A sintaxe exige a barra invertida antes dos dois pontos: <caminho>\:{restrições}. As restrições disponíveis: PathType (file/folder), ScanType (quick/full), ScanTrigger (OnDemand, OnAccess, BM comportamental) e Process (caminho do processo). Vários pares ScanType, ScanTrigger ou PathType combinam-se em E, vários Process em OU — e os valores das keywords são sensíveis à caixa.

O limite importa tanto como a sintaxe: a documentação diz que exclusões contextuais não são uma via fiável para resolver falsos positivos — a via para isso é o indicador allow ou a submissão à Microsoft. A exclusão contextual existe para compatibilidade e performance quando o contexto garante que o ficheiro é seguro. A aplicação Segurança do Windows não as suporta, e estão disponíveis só no Windows. O piso: plataforma 4.18.2205.7 (Maio de 2022) e motor 1.1.19300.2, ou posterior; para as escrever por GPO, o template ADMX tem de ser de 24H2 ou posterior.

Falso positivo por hash: o indicador (IoC) allow no portal

O antivírus não tem exclusão por hash: os parâmetros de exclusão cobrem caminho, extensão, processo e endereço IP, e nada mais. A isenção por hash existe noutra camada: os indicadores de compromisso (Indicators of Compromise, IoC) do portal do Microsoft Defender for Endpoint, com acção Allow. É também o mecanismo mais estreito que existe: um ficheiro exacto, identificado pelos 64 caracteres do SHA-256 — nem uma pasta, nem uma extensão, e a subida de revisões da aplicação não herda a isenção.

Pré-requisitos na máquina: Microsoft Defender Antivirus como antivírus principal em modo activo, versão do cliente 4.18.1901.x ou mais recente, monitorização de comportamento e protecção na nuvem activos. E hash computation, que vem desligado por omissão:

Set-MpPreference -EnableFileHashComputation $true

O equivalente em GPO vive em Computer configuration > Administrative templates > Windows components > Microsoft Defender Antivirus > MpEngine > Enable File Hash Computation. Em macOS e Linux o mesmo recurso existe com requisitos próprios. Só ficheiros PE (executáveis e DLL) são suportados como indicador no Windows, e o EnableFileHashComputation ligado tem custo de performance a calcular hashes (visível em cópias grandes a partir de partilhas de rede).

O hash vem do evento 1121 (campo Hashes) ou do Get-FileHash:

Get-FileHash 'C:\Apps\Lobapp\app1.dll' -Algorithm SHA256

Saída típica (o hash completo tem 64 caracteres hexadecimais):

Algorithm       Hash                        Path
---------       ----                        ----
SHA256          C4B5D2A9E8F13B0A4C...      C:\Apps\Lobapp\app1.dll

No portal (security.microsoft.com): System > Settings > Endpoints > Indicators (no grupo Rules) > separador File hashes > Add item. Indica o hash e a expiração, escolhe a acção Allow com uma descrição que explique o motivo e a data, define o âmbito no grupo de dispositivos e grava. Pode também criar o indicador em contexto na página do ficheiro no portal (Add indicator).

Detalhes de operação: quando dois indicadores apontam o mesmo ficheiro, o SHA-256 vence o SHA-1, que vence o MD5. O limite do tenant é de 15.000 indicadores. Os indicadores não funcionam com o antivírus em modo passivo. A propagação: tipicamente até 15 minutos, em média 30 — podem chegar às 2 horas. Os indicadores Allow não geram alertas — é por desenho, não defeito. E para os bloqueios por IoC funcionar, o toggle Allow or block file tem de estar activo (portal: Settings > Endpoints > General > Advanced features) — a documentação refere-o para bloquear; para Allow, confirma no teu tenant. No Defender for Business o indicador aplica-se a todo o ambiente, sem scoping por grupos — para PME com Business, o pedido de permitir um hash exacto continua a ser a ferramenta mais estreita da lista, mas sem ajuste por grupo de máquinas.

Quando o falso positivo se repete a cada versão do executável, o hash por revisão é uma ratoeira: cada build da aplicação tem hash diferente e o indicador morre com o update. Nesse caso a resposta é submeter o ficheiro à Microsoft (a submissão corrige a inteligência da nuvem para todos os clientes) e, em paralelo, avaliar uma exclusão de caminho estreita enquanto a correcção não chega. Se a aplicação interna é assinada pela mesma organização, o indicador por certificado (allow por assinatura) cobre todas as revisões do mesmo fornecedor.

Exclusões de ASR: globais, por regra e por IoC

As regras da Attack Surface Reduction têm o seu próprio sistema de isenções, com quatro canais:

• Exclusões do antivírus: honradas por algumas regras. A tabela de compatibilidade da documentação lista regra a regra o que cada mecanismo cobre.
• Exclusões globais de ASR (AttackSurfaceReductionOnlyExclusions): aplicam-se a todas as regras, configuráveis em PowerShell, Intune, GPO e CSP.
• Exclusões por regra (per-rule): só GPO, políticas de endpoint security do Intune e políticas do portal do Defender.
• IoC com acção Allow: a maioria das regras honra indicadores de ficheiros e certificados.

Tabela condensada da compatibilidade oficial (a lista completa, regra a regra, está nas fontes):

As exclusões globais em PowerShell seguem o mesmo padrão do antivírus:

Add-MpPreference -AttackSurfaceReductionOnlyExclusions 'C:\Data\Test','C:\Data\LOBApp\app1.exe'
(Get-MpPreference).AttackSurfaceReductionOnlyExclusions

As exclusões por regra têm sintaxe especial e exigem GPO, Intune ou o portal. Em GPO, o setting é o Apply a list of exclusions to specific attack surface reduction (ASR) rules (no caminho Computer configuration > Administrative templates > Windows components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction), em que o Value name leva o GUID da regra e o Value leva a lista de exclusões (Path1\ProcessName1>Path2\ProcessName2, com a documentação a exemplificar uma cadeia C:\Windows\Notepad.exe>c:\Windows\regedit.exe>C:\SomeFolder\test.exe). No Intune, a secção ASR only per rule exclusions aparece na política depois de escolher o modo da regra.

O detalhe que apanha muita equipa: as exclusões de ASR aplicam-se quando a aplicação ou serviço arranca. Se adicionar a exclusão a um serviço que já corre, ele continua a disparar a regra até ser reiniciado — reinicie o serviço (ou o computador) e confirme no histórico.

Para um falso positivo de uma regra específica, a ordem de preferência: teste em modo Audit antes de block (o artigo Regras ASR no Defender: do Modo Auditoria ao Enforcement tem o percurso completo), use exclusão por regra quando a excepção é só dessa regra e o IoC Allow quando é um ficheiro exacto — a regra do ransomware, por exemplo, aceita as duas vias quando os bloqueios de ficheiros legítimos não se resolvem no tempo normal.

O que nunca excluir

A documentação mantém listas de pastas e tipos de ficheiro atacáveis — são os locais e os formatos que o malware abusa por excelência:

A regra geral: não exclua nada pela confiança na aplicação (as aplicações legítimas também são a via de infecção), e revise as exclusões existentes com regularidade. Cada exclusão a mais é uma porta aberta.

Reportar o falso positivo à Microsoft

A exclusão ou o indicador permitem à equipa respirar, não resolvem a inteligência. A submissão à Microsoft corrige a assinatura para todos os clientes: o canal directo é a página Submit a file for analysis da Microsoft Security Intelligence, com o hash (o campo SHA-256 do Get-FileHash serve) e os detalhes da detecção. Com MDE Plan 2 ou Microsoft Defender XDR, a submissão pode vir directamente do portal.

Enquanto a resposta não chega, o indicador allow mantém a aplicação a correr com o mínimo de exposição possível, e a exclusão (quando houver) deve ser revista na rotina: a documentação pede revisões e auditorias periódicas das listas de exclusão, com registo do contexto — porquê cada exclusão foi pedida e quando pode sair. Quando a inteligência corrige e o processo corre limpo, remova a exclusão (Remove-MpPreference) e feche a ficha.

Veredicto

Num ambiente PME, a regra de decisão simplifica-se num par de perguntas: o bloqueio veio do antivírus ou de uma regra ASR? A exceção precisa um ficheiro exacto ou um local? Caminho e extensão resolvem os locais, o processo resolve quem abre o resto, e o hash resolve o ficheiro único com âmbito mínimo — mas vive no portal, não no antivírus. Valide com o MpCmdRun antes de considerar o caso fechado e mantenha a submissão à Microsoft no fim de qualquer falso positivo: A submissão à Microsoft é a única das peças do runbook que melhora a protecção de todas as outras máquinas em vez de só a sua. Para a fase audit → enforcement das regras em si, o artigo Regras ASR no Defender: do Modo Auditoria ao Enforcement é o complemento natural deste guia.

Artigos Relacionados

• Regras ASR no Defender: do Modo Auditoria ao Enforcement
• Microsoft Defender for Endpoint: Implementação e Configuração para PME
• Defender for Business vs Defender for Endpoint: Qual Escolher para PME
• Defender Device Control: Bloquear e Controlar USB no Windows

Fontes oficiais

• Exclusions in Microsoft Defender Antivirus
• Configure custom exclusions for Microsoft Defender Antivirus
• Attack surface reduction (ASR) rules overview
• Configure ASR rules and exclusions
• Overview of indicators in Microsoft Defender for Endpoint
• Create indicators for files
• Use the command line to manage Microsoft Defender Antivirus
• Microsoft Defender Antivirus event IDs and error codes
• Add-MpPreference — PowerShell (Defender module)
• Exclusions to avoid in Microsoft Defender Antivirus and Defender for Endpoint
• Submit a file for malware analysis