Regras ASR no Defender: do Modo Auditoria ao Enforcement
Um script PowerShell descarrega um executável pela internet. Uma macro do Office chama APIs do Windows para lançar shellcode. Um instalador aparentemente normal guarda um driver assinado com vulnerabilidades conhecidas. Nenhum destes comportamentos é um ficheiro com assinatura de malware conhecida e é por isso que a detecção por assinaturas os deixa passar. As regras ASR (Attack Surface Reduction) do Microsoft Defender atacam exactamente este espaço: em vez de classificar ficheiros, interceptam comportamentos de risco que os atacantes exploram repetidamente.
Ligar as regras é a parte fácil. A parte difícil é passá-las do modo auditoria para o modo bloqueio sem partir aplicações de linha de negócio no caminho. A Microsoft documenta um processo em quatro fases para essa transição: planear, testar, activar e operacionalizar. Este guia percorre as 19 regras na referência oficial actual, o plano por anéis com o Intune, as exclusões globais e por regra e os eventos 1121 e 1122 que provam o que cada regra está a fazer no dispositivo.
Neste artigo
- O que São as Regras ASR e Que Modos Têm
- As 19 Regras e as Regras de Protecção Standard
- Fase 1 — Planear Anéis, Campeões e Inventário
- Fase 2 — Testar em Modo Auditoria
- Fase 3 — Activar em Modo Bloqueio
- Fase 4 — Operacionalizar e Monitorizar
- Configurar as Regras no Intune
- Exclusões Globais e Exclusões por Regra
- Eventos 1121 e 1122 no Event Viewer
- Erros Comuns
- Checklist
- Artigos Relacionados
- Fontes Oficiais
1. O que São as Regras ASR e Que Modos Têm
As regras ASR são uma funcionalidade do Microsoft Defender Antivirus, disponível em qualquer edição do Windows que o inclua, incluindo o Windows 11 Home. A gestão centralizada, o reporte e os alertas exigem o Defender for Endpoint, com políticas distribuídas pelo Intune, pelo Configuration Manager, por qualquer solução MDM através do Policy CSP ou por Group Policy (referência ASR).
Cada regra tem um GUID próprio e um de cinco estados: 0 desligada, 1 bloqueio, 2 auditoria, 5 não configurada e 6 aviso. Em modo auditoria, a regra regista o que bloquearia sem bloquear nada, com o evento 1122. Em modo bloqueio, corta mesmo a acção, com o evento 1121. O modo aviso (estado 6) mostra a notificação ao utilizador, que pode passar, e o bypass fica no evento 1129. O modo aviso serve para medir o incómodo real de uma regra sem cortar o trabalho de ninguém.
A documentação de deployment fixa uma excepção importante logo no início: as três regras de protecção standard podem tipicamente activar-se directamente em bloqueio ou aviso sem teste. Todas as restantes devem passar por auditoria antes (guia de deployment).
2. As 19 Regras e as Regras de Protecção Standard
A referência oficial organiza as regras em dois grupos: três de protecção standard (abuso de drivers vulneráveis assinados, furto de credenciais do LSASS e persistência através de subscrições de eventos WMI) e as restantes. A tabela seguinte cobre as regras com mais impacto numa implementação, com o GUID que os métodos de configuração por PowerShell, GPO e OMA-URI esperam (referência ASR).
| Regra | GUID | Nota de deployment |
|---|---|---|
| Block abuse of exploited vulnerable signed drivers | 56a863a9-875e-4185-98a7-b882c64b5ce5 | Protecção standard, impede guardar drivers vulneráveis, não impede carregar os existentes |
| Block credential stealing from the Windows local security authority subsystem | 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 | Sem modo aviso e com grande volume de eventos em auditoria, exclusões limitadas |
| Block persistence through WMI event subscription | e6db77e5-3df2-4cf1-b95a-636979351e5b | Protecção standard, alvo de ameaças fileless |
| Block all Office applications from creating child processes | d4f940ab-401b-4efc-aadc-ad5f3c50688a | Ruidosa em ambientes com macros, auditoria obrigatória |
| Block executable files from running unless they meet a prevalence, age, or trusted list criterion | 01443614-cd74-433a-b99e-2ecdc07bfc25 | Exige cloud protection, exclusões limitadas |
| Block execution of potentially obfuscated scripts | 5beb7efe-fd9a-4556-801d-275e5ffc04cc | Depende do AMSI e da cloud protection |
| Block process creations originating from PSExec and WMI commands | d1e49aac-8f56-4280-b9ba-993a6d77406c | Não activar com o cliente Configuration Manager, que vive de WMI |
| Use advanced protection against ransomware | c1db55ab-c21a-4637-bb3f-a12568109d35 | Exige cloud protection, bloqueia também ficheiros sem reputação positiva |
A lista completa com os nomes no Intune, dependências e tipos de acção para advanced hunting fica na página de referência. Duas regras não têm suporte em Windows Server (JavaScript ou VBScript a lançar executáveis descarregados e chamadas Win32 de macros do Office) e a regra de webshell aplica-se apenas a servidores Exchange. Nesse caso específico, se a gestão das regras ASR estiver no portal Defender for Endpoint, a regra de webshell não deve ser configurada por GPO nem por definições locais, porque o valor em conflito impede a aplicação correcta.
Quanto ao método de distribuição, todas as regras têm suporte no Intune, em qualquer MDM via Policy CSP e no Group Policy centralizado. O Configuration Manager só suporta uma parte das regras, o que torna o Intune o caminho natural para o resto deste guia (referência ASR).
3. Fase 1 — Planear Anéis, Campeões e Inventário
O plano oficial parte de uma infra-estrutura de referência com Entra ID, Intune, Windows 10 e 11 e licenças E5 (Microsoft 365 E5, Windows E5 ou A5) para tirar partido de todo o reporte. Com Plano 1, as regras funcionam na mesma, mas faltam os relatórios completos (fase plan).
Cinco passos definem a fase:
- Escolher as unidades de negócio iniciais, preferindo unidades pequenas com amostra representativa de software, pastas partilhadas, scripts e macros
- Identificar os campeões ASR, pessoas com perfil técnico e tolerância a interrupções, num canal de feedback dedicado
- Inventariar as aplicações de linha de negócio e os processos, com atenção às apps internas não assinadas que complicam a transição a bloqueio
- Definir quem recolhe os relatórios, com quem os partilha e quem trata escalamentos de bloqueios indesejados
- Definir os anéis de implementação, reutilizando os anéis de actualizações do Windows se já existirem
Numa PME isto pode resumir-se a um anel com meia dúzia de postos de TI e um segundo anel com um departamento piloto. A dimensão importa menos do que existir um anel antes de qualquer política.
4. Fase 2 — Testar em Modo Auditoria
Antes da fase de testes, desactivar as regras ASR que já estejam activas em bloqueio ou aviso, para os dados de auditoria não misturarem estados (fase test).
Depois, activar todas as regras em modo auditoria ao mesmo tempo no anel 1. Em auditoria as regras não afectam utilizadores e geram os eventos 1122 que alimentam a avaliação. A excepção volta a ser a regra do LSASS: produz um grande volume de eventos de auditoria quase todos ignoráveis e a Microsoft admite saltar essa avaliação, indo directamente a bloqueio a partir de um conjunto pequeno de dispositivos.
Durante a observação, rever os eventos por um ou mais métodos:
| Método | Requisito |
|---|---|
| Relatório de regras ASR no portal, em security.microsoft.com/asr | Defender for Endpoint Plano 2 ou Defender for Business |
| Advanced hunting na tabela DeviceEvents | Defender for Endpoint Plano 2 |
| Linha temporal do dispositivo | Plano 2 ou Defender for Business |
| Event Viewer local, com Windows Event Forwarding para centralizar | Qualquer plano |
O método de distribuição das regras não afecta os dados de reporte, desde que os dispositivos estejam inscritos no Defender for Endpoint. Com os dados em mão, configurar exclusões para os falsos positivos encontrados, no mesmo método usado para distribuir as regras, no Intune na própria política ASR.
5. Fase 3 — Activar em Modo Bloqueio
A transição é regra a regra, começando pela regra com menos eventos accionados em auditoria. O ciclo por regra: mudar o estado para bloqueio (ou aviso), rever a actividade e o feedback dos campeões, afinar exclusões (fase implement).
O modo aviso é o meio-termo para as regras que o suportam, capturando eventos e mostrando a perturbação sem bloquear o utilizador. Duas regras não o suportam de todo: a do LSASS e a de injecção de código em outros processos por aplicações Office.
Para expandir ao anel seguinte, o ciclo repete-se por inteiro: activar em auditoria, rever, criar exclusões, rever, passar a bloqueio, rever, criar exclusões e desactivar regras problemáticas ou devolvê-las a auditoria. A regra prática da documentação: exclusões são melhores do que desligar regras ou voltá-las a auditoria.
6. Fase 4 — Operacionalizar e Monitorizar
Depois do enforcement, o trabalho muda de criação de políticas para revisão recorrente. A frequência da revisão dos eventos ASR acompanha o volume de eventos reportados, de horária a contínua conforme a dimensão da organização (fase operationalize).
O relatório no portal (Reports > Endpoints > Attack surface reduction rules) mostra cada detecção com o estado bloqueado ou auditado, a regra, a aplicação de origem, o dispositivo e o grupo de dispositivos, além do estado das regras por dispositivo (desligadas, não aplicáveis, desconhecido).
Para interrogar os dados directamente, o advanced hunting tem 30 dias de dados na tabela DeviceEvents, com os eventos ASR limitados a processos únicos por hora:
DeviceEvents
| where Timestamp > ago(30d)
| where ActionType startswith "Asr"
| summarize EventCount=count() by ActionType
O resumo por ActionType devolve o volume por regra (os tipos terminam em Audited ou Blocked), o ponto de partida para os relatórios recorrentes. Para problemas pontuais, a página de troubleshooting ASR cobre os casos típicos.
7. Configurar as Regras no Intune
No Intune, o método recomendado são as políticas de endpoint security: em Endpoint security, Attack surface reduction, criar uma política com plataforma Windows e perfil Attack Surface Reduction Rules (configuração ASR). A documentação sublinha uma restrição: a gestão do Defender for Endpoint suporta apenas objectos de dispositivo, pelo que a política se atribui a grupos de dispositivos do Entra ID e nunca a grupos de utilizadores.
Na tab de configuração, cada regra fica num dos estados (Auditar, Bloquear, Avisar, Desligar). Assim que uma regra fica num modo activo, aparece a secção ASR only per rule exclusions para exclusões que só valem para essa regra. A secção Attack surface reduction only exclusions guarda as exclusões globais, com adição manual ou importação de CSV neste formato:
AttackSurfaceReductionOnlyExclusions
"C:\Pasta"
"%ProgramFiles%\Pasta\ferramenta.exe"
Como alternativa ao perfil de endpoint security, um perfil personalizado com OMA-URI configura as regras através do CSP. No OMA-URI ./Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionRules, tipo de dados String, o valor é uma lista de pares GUID e estado:
75668c1f-73b5-4cf0-bb93-3ecf5cb7cc84=2 3b576869-a4ec-4529-8536-b80a7769e899=1 d4f940ab-401b-4efc-aadc-ad5f3c50688a=2
As exclusões globais entram no mesmo perfil ou noutro, com o OMA-URI ./Device/Vendor/MSFT/Policy/Config/Defender/AttackSurfaceReductionOnlyExclusions e os caminhos separados por espaço.
Para confirmar o estado efectivo no dispositivo, o PowerShell:
$p = Get-MpPreference
0..([math]::Min($p.AttackSurfaceReductionRules_Ids.Count,$p.AttackSurfaceReductionRules_Actions.Count)-1) | % {[pscustomobject]@{Id=$p.AttackSurfaceReductionRules_Ids[$_];Action=$p.AttackSurfaceReductionRules_Actions[$_]}} | Format-Table -AutoSize
Quem gere dispositivos com o Intune não deve fixar regras por PowerShell: a plataforma de gestão sobrescreve definições conflituosas no arranque. O Set-MpPreference substitui todas as regras existentes pelos valores indicados, o Add-MpPreference acrescenta sem apagar e é o cmdlet certo para adicionar regras pontualmente em postos não geridos.
8. Exclusões Globais e Exclusões por Regra
Existem dois níveis. As exclusões globais (Attack surface reduction only exclusions no Intune, ou AttackSurfaceReductionOnlyExclusions no CSP) aplicam-se a todas as regras. As exclusões por regra (ASR only per rule exclusions no Intune, ou a definição Apply a list of exclusions to specific attack surface reduction rules na GPO) aplicam-se apenas à regra indicada. Um problema específico de uma regra resolve-se com exclusão por regra, preservando a protecção das restantes.
Várias regras têm suporte de exclusões limitado, documentado na referência: LSASS, ransomware avançado, prevalência e idade de executáveis, PSExec e WMI e Adobe Reader. Nelas, as exclusões restringem-se a ficheiros e pastas.
Na GPO, aspas, espaços no início ou fim e caracteres extra não são suportados nos valores das definições ASR, e o caminho da política mudou de nome em versões anteriores à Windows 10 2004 (Windows Defender Antivirus passou a Microsoft Defender Antivirus, a localização é a mesma). E quando o objectivo é apenas medir o impacto de uma regra, o modo aviso, onde disponível, dispensa a exclusão.
9. Eventos 1121 e 1122 no Event Viewer
Os eventos ASR ficam no registo Windows Defender > Operational, em Applications and Services Logs > Microsoft > Windows > Windows Defender > Operational (eventos ASR):
| Evento | Significado |
|---|---|
| 1121 | Regra disparou em modo bloqueio |
| 1122 | Regra disparou em modo auditoria |
| 1129 | Utilizador passou pelo bloqueio em modo aviso |
| 5007 | Configuração alterada |
Sem inscrição no Defender for Endpoint, os eventos existem apenas no Event Viewer local. O Windows Event Forwarding centraliza a recolha, e é a via apontada pela documentação de testes para quem não tem os relatórios do portal.
Um filtro rápido em PowerShell no dispositivo:
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Windows Defender/Operational'; Id=1121,1122} -MaxEvents 20
Na fase de auditoria, o 1122 em massa é o mapa de trabalho: cada entrada é um bloqueio que aconteceria, com o processo e o ficheiro envolvidos. Depois da transição, o 1121 mede o enforcement real e alimenta a revisão recorrente, enquanto o 1129 revela os avisos que os utilizadores estão a passar, candidatos a exclusão fundamentada ou a formação.
Erros Comuns
| Problema | Causa | Solução |
|---|---|---|
| Activar todas as regras em bloqueio de uma vez | Salto directo da fase de testes, sem dados de auditoria | Voltar às regras a auditoria, rever os 1122 e transitar regra a regra, das com menos eventos |
| Política ASR do Intune não chega aos dispositivos | Política atribuída a grupos de utilizadores | Reatribuir a grupos de dispositivos, a gestão só suporta objectos de dispositivo |
| Regras desaparecem ou mudam de estado sozinhas | Set-MpPreference ou uma segunda plataforma de gestão a sobrescrever valores |
Um único método de gestão, Add-MpPreference para acrescentar sem apagar |
| Regra de ransomware ou de prevalência sem qualquer efeito | Cloud protection desligada no dispositivo | Activar cloud-delivered protection antes do modo bloqueio |
| Exclusão global criada para um problema de uma só regra | Exclusão demasiado larga, protecção perdida nas restantes regras | Mover para exclusão por regra na mesma política do Intune |
| Valores ASR rejeitados na GPO | Aspas ou espaços extra nos valores, sintaxe do nome antigo da política | Valores limpos sem aspas nem espaços e caminho actual da política |
| Anel seguinte recebe a política sem re-teste | Copiar a política do anel 1 para todos os dispositivos | Repetir o ciclo completo de auditoria e exclusões por anel |
| Regra de PSExec e WMI em bloqueio quebra ferramentas internas | Cliente Configuration Manager ou scripts de gestão vivem de WMI | Avaliar antes na auditoria, exclusão por regra dirigida ou aviso, nunca exclusão global |
| Regra de webshell configurada por GPO em ambiente gerido pelo portal | Valor local em conflito com a gestão do Defender for Endpoint | Deixar a definição GPO em Not Configured e gerir a regra no portal |
Checklist
- [ ] Licenciamento confirmado para os relatórios completos (Plano 2, Microsoft 365 E5 ou Windows E5)
- [ ] Anel 1 definido, com campeões ASR e canal de feedback
- [ ] Regras já activas em bloqueio ou aviso desactivadas antes da fase de auditoria
- [ ] Restantes regras em modo auditoria no anel 1, com a posição da regra do LSASS decidida explicitamente
- [ ] Eventos 1122 revistos por regra, no relatório do portal ou em advanced hunting
- [ ] Exclusões por regra documentadas com caminho e motivo
- [ ] Cloud protection activada para as regras que a exigem
- [ ] Transição a bloqueio começou pelas regras com menos eventos
- [ ] Modo aviso em uso nas regras de transição difícil que o suportam
- [ ] Eventos 1121 e 1129 incluídos na revisão recorrente agendada
- [ ] Plano de reversão por regra: voltar a auditoria em vez de desligar
Artigos Relacionados
- Microsoft Defender for Endpoint: Implementação e Configuração para PME em 2026 — o onboarding e a configuração base do Defender for Endpoint onde as regras ASR assentam
- Curso M365 Dia 22: Microsoft Defender — Endpoint, Office 365 e Cloud Apps — o enquadramento do Defender no Microsoft 365 completo
- Windows Autopatch: Actualizações Automáticas com Intune — os anéis de implementação que se reutilizam no rollout das regras ASR
- Defender for Business vs Defender for Endpoint: Qual Escolher para PME? — o plano certo para ter os relatórios ASR que o processo de deployment exige
Fontes Oficiais
- Attack surface reduction (ASR) rules reference — Microsoft Learn
- Attack surface reduction (ASR) rules deployment guide — Microsoft Learn
- Plan your attack surface reduction (ASR) rules deployment — Microsoft Learn
- Test your attack surface reduction (ASR) rules deployment — Microsoft Learn
- Enable your attack surface reduction (ASR) rules deployment — Microsoft Learn
- Manage and monitor your attack surface reduction (ASR) rules deployment — Microsoft Learn
- Configure attack surface reduction (ASR) rules and exclusions — Microsoft Learn
- Attack surface reduction events in Windows Event Viewer — Microsoft Learn
- Monitor attack surface reduction (ASR) rule activity — Microsoft Learn