Microsoft Defender for Identity: Deteção de Ameaças no AD

O controlador de domínio é o activo mais valioso da rede: quem o compromete compromete todos os utilizadores. O Microsoft Defender for Identity (MDI) é o serviço da Microsoft que vigia exactamente esse activo — um sensor instalado no próprio DC que analisa o tráfego Kerberos, NTLM, LDAP e DNS à procura de reconhecimento, roubo de credenciais e lateral movement, com alertas que chegam ao Microsoft Defender portal correlacionados com os restantes produtos Defender. Relevância acrescida para PMEs com AD: várias das detecções visam as falhas de criptografia Kerberos que a desactivação do RC4 torna visíveis — o MDI aprende as cifras Kerberos habituais do ambiente e alerta quando surge uma mais fraca.

O guia verifica as licenças, prepara o AD, instala o sensor e liga as primeiras respostas.

Neste artigo

  1. Como funciona: o sensor no DC
  2. Licenças
  3. Requisitos do servidor
  4. Instalar o sensor
  5. Alertas que importam
  6. Correlação com o Defender XDR

1. Como funciona: o sensor no DC

O sensor instala-se directamente no controlador de domínio (e em servidores AD FS, AD CS e Microsoft Entra Connect que não sejam DCs) e lê o tráfego e os event logs da máquina — sem servidor dedicado nem port mirroring, o modelo antigo do Microsoft ATA (antecessor directo do MDI, herdado da aquisição da Aorato) desapareceu. O sensor captura os dados de que precisa para as detecções e avaliações de postura, sem registar tudo — não o usar como substituto de uma auditoria de eventos.

Na cloud, o workspace do MDI correlaciona os sinais e calcula as lateral movement paths — os caminhos que um atacante podia percorrer a partir de um utilizador ou máquina comprometida até contas sensíveis —, que aparecem no Microsoft Defender portal e no Secure Score.

2. Licenças

O MDI licencia por utilizador protegido, com uma das seguintes licenças (verificadas na documentação de pré-requisitos):

  • Enterprise Mobility + Security E5 (EMS E5/A5)
  • Microsoft 365 E5, A5 ou G5
  • Microsoft 365 E5/A5/G5/F5 Security (as F5 exigem ainda M365 F1/F3 ou Office 365 F3 e EMS E3)
  • Licença standalone do Defender for Identity

Compram-se pelo portal Microsoft 365 ou via CSP. Para a PME com E5 já licenciado, o MDI é activável sem custo adicional. Sem E5, a licença standalone por utilizador é a alternativa.

3. Requisitos do servidor

O sensor v3.x limita-se a ~30% de CPU e 1,5 GB de RAM (limites internos que evitam carga adicional significativa no DC), e pede Windows Server 2019 ou posterior com a atualização cumulativa de julho de 2026 ou posterior — em VM, toda a memória tem de estar reservada: dynamic memory do Hyper-V desactivado, e em VMware a memória configurada igual à reservada (ou “Reserve all guest memory”). Controladores read-only (RODC) são suportados.

Duas versões de sensor: a v3.x cobre DCs em Windows Server 2019 ou posterior (a recomendada), e a v2.x mantém-se só para DCs em Windows Server 2016 ou anterior (é a v2 que exige duas cores, 6 GB de RAM e 6 GB de disco, usa o service tag AzureAdvancedThreatProtection e consulta o directório por LDAP nas portas 389/3268 — v3.x não tem estas constraints, usa os URIs do MDE, tem limitações com ExpressRoute e não suporta VPN integration nem syslog).

A conectividade à cloud do sensor v3.x usa os URIs do Defender for Endpoint (a lista completa de endpoints sai da documentação do MDE), com proxy (inspecção SSL não suportada) e limitações quando se usa ExpressRoute. O service tag AzureAdvancedThreatProtection, o BGP community 12076:5220 (ExpressRoute) e a consulta por LDAP nas portas 389/3268 com LDAPS 636/3269 são do sensor v2.x. A v2.x mantém-se apenas para DCs em Windows Server 2016 ou anterior.

4. Instalar o sensor

O caminho completo no portal:

  1. Criar o workspace e instalar o sensor: Microsoft Defender portal → Settings → Identities, com uma conta Security administrator (ou as permissões Unified RBAC equivalentes)
  2. Confirmar que o DC está onboarded ao Defender for Endpoint (o Microsoft Defender Antivirus pode estar em modo activo ou passivo) — ou, em DCs elegíveis, usar o onboarding do sensor v3.x sem MDE
  3. No portal, Settings → Identities → Sensor management → Activate para activar o sensor instalado, ou usar a activação automática (Settings → Identities → Advanced features). O sensor v3.x corre como LocalSystem e não usa Directory Service Accounts nem gMSA — as contas configuradas para sensores v2.x deixam de se aplicar (a doc é explícita: o v3.x “doesn’t use Directory Service Accounts (DSA) or group Managed Service Accounts (gMSA)”)
  4. Ajustar o event auditing do Windows (NTLM, modificações de grupos) — o que a detecção pede, activável pelo portal ou PowerShell

Antes de instalar, o script oficial valida o ambiente:

# Test-MdiReadiness.ps1 (GitHub Microsoft-Defender-for-Identity)
.\Test-MdiReadiness.ps1

A partir da release do sensor de Julho de 2026 (v3.0.8), a auditoria RPC activa-se automaticamente nos DCs na actualização do sensor — um pré-requisito de detecção menos a gerir à mão.

5. Alertas que importam

Os alertas dividem-se pelas fases do kill chain, e a documentação de alertas clássicos organiza cerca de 64 alertas por fase do kill chain, com severidade e contexto de investigação. Os que a PME deve conhecer de cor:

  • Reconhecimento: Account Enumeration (LDAP), Network-mapping (DNS), User/Group membership (SAMR) — a fase de descoberta de quase todos os ataques internos
  • Persistência e escalada: Suspected Golden Ticket usage (nas variantes encryption downgrade, nonexistent account, ticket anomaly, time anomaly), skeleton key, Netlogon privilege elevation (CVE-2020-1472 / Zerologon), SID-History injection, e as manipulações de AD CS (ESC8) e AdminSDHolder
  • Acesso a credenciais: Brute Force (Kerberos, NTLM), Kerberos SPN exposure (Kerberoasting), AS-REP Roasting, shadow credentials
  • Lateral movement: exploit do Print Spooler (PrintNightmare) contra o DC, e as pass-the-ticket/pass-the-hash que o tráfego do protocolo revela

Os honeytokens — contas isco criadas pelo administrador e registadas no MDI — geram alertas imediatos ao primeiro uso, o truque de detecção mais barato do AD.

6. Correlação com o Defender XDR

Os alertas do MDI aparecem no Microsoft Defender portal (security.microsoft.com) em Incidents & alerts → Alerts, correlacionados com os sinais de endpoints (Defender for Endpoint), email (Defender for Office) e cloud apps. A investigação conjunta é o argumento do XDR: um lateral movement visto no MDI liga-se ao processo que o originou no endpoint e ao email que o entregou. As classificações TP/B-TP/FP e as regras de tuning afinam o ruído — a documentação aconselha tuning só depois de confirmar que a actividade repetida é benigna.

Erros Comuns

Erro Causa provável Correcção
Sensor não conecta à cloud Firewall bloqueia os endpoints Usar o service tag AzureAdvancedThreatProtection ou proxy sem SSL inspection
DC lento após instalar o sensor Memória da VM partilhada Reservar toda a memória da VM (Hyper-V: desligar Dynamic Memory)
Workspace apagado Sem sensor em 60 dias Recriar o workspace e instalar o sensor
Detections ausentes (NTLM, grupos) Event auditing desligado Configurar o Windows event auditing pelo portal
Test-MdiReadiness falha em DNS Registros de conectividade ausentes Verificar os URIs do MDE e a resolução interna

Checklist

  • [ ] Licença E5/EMS E5/standalone confirmada por utilizador
  • [ ] DCs 2019+ com sensor v3, com AD FS/AD CS/Entra Connect cobertos
  • [ ] Windows Server 2019+ com CU de julho 2026+ no DC (v3.x limita-se a 30% CPU e 1,5 GB de RAM: memória reservada em VM)
  • [ ] URIs do MDE alcançáveis a partir do DC (proxy sem inspecção SSL)
  • [ ] Test-MdiReadiness.ps1 executado (falhas de DNS: verificar os URIs do MDE e a resolução interna)
  • [ ] Action accounts migradas para “Automatically use the sensor’s local system account” (o v3.x usa LocalSystem, sem gMSA/DSA)
  • [ ] Windows event auditing configurado
  • [ ] Sensor instalado e activado (Settings → Identities → Sensor management → Activate)
  • [ ] Honeytokens criados e registados
  • [ ] Alertas críticos com notificação à equipa

Artigos Relacionados

Fontes Oficiais