Os casos de uso de detecção para Active Directory que mais reduzem risco em um SOC são aqueles que vigiam o abuso de funções legítimas do domínio: replicação de diretório, manipulação de contas e extração de credenciais. O Active Directory concentra identidades, permissões e segredos de autenticação em um só lugar, e justamente por isso quase todo incidente grave passa por ele em algum momento. A boa notícia é que esses abusos deixam rastro em logs nativos e já existem regras públicas que os traduzem em alertas acionáveis; a seguir, você encontra os cenários prioritários, os sinais que cada um produz e o caminho prático para implementá-los.
O que monitorar no Active Directory
A detecção eficaz em Active Directory começa pela premissa de que o atacante usa ferramentas administrativas legítimas, e não exploits exóticos. Isso significa monitorar três famílias de comportamento: operações de replicação do serviço de diretório, alterações em contas e grupos, e acesso a material de credencial. Cada família tem dono natural no SOC, mas o analista que entende o encadeamento entre elas investiga mais rápido: uma replicação anômala após a criação de uma conta suspeita conta uma história diferente de cada evento isolado. O mesmo raciocínio vale para movimento lateral clássico baseado em credenciais reaproveitadas, como descrito no guia de detecção de pass-the-hash no SOC.
DCSync: replicação que vaza hashes
O DCSync é o caso de uso mais valioso porque explora a própria arquitetura de replicação do domínio: atacantes com permissões de replicação conseguem extrair hashes de qualquer conta, inclusive a KRBTGT, sem tocar em um único arquivo do controlador de domínio. Segundo o MITRE ATT&CK, membros dos grupos Administrators, Domain Admins e Enterprise Admins, ou contas de máquina do próprio controlador, podem executar essa operação simulando a replicação de um controlador remoto — e os hashes obtidos permitem forjar um Golden Ticket para acesso persistente ao domínio. Na prática, o sinal aparece quando um endpoint que não é controlador de domínio inicia operações de replicação via Directory Replication Service, comportamento que o MITRE cataloga como OS Credential Dumping: DCSync e associa a grupos como LAPSUS$ e Storm-0501.
Do lado da implementação, o Wazuh já distribui regras prontas que detectam DCSync e DCShadow com os IDs 87301 e 87302, cobrindo tanto a elevação por metadados de replicação quanto o ataque de replicação em si, conforme a documentação oficial de sintaxe de regras do Wazuh. Isso reduz o caso de uso a três tarefas: garantir que os eventos de replicação cheguem ao agente, ativar as regras do ruleset padrão e definir quem responde quando o alerta dispara fora de janelas de manutenção.
Contas manipuladas e persistência silenciosa
O segundo caso de uso acompanha o que acontece depois que o atacante obtém um mínimo de privilégio. A técnica de manipulação de contas descrita no MITRE ATT&CK sob o identificador T1098 inclui desde adições a grupos privilegiados até atualizações iterativas de senha para burlar políticas de duração e preservar credenciais comprometidas. Essas ações são silenciosas porque usam ferramentas nativas de administração, mas produziram alertas valiosos quando correlacionadas com linhagem de processo incomum, horário atípico ou origem fora da estação de administração. Um playbook de resposta a incidentes bem estruturado encurta o tempo entre esse alerta e a decisão de suspender a conta, conforme detalhado no caso do ransomware Gunra e o bypass de MFA detectado no SOC, em que o abuso de identidade foi o fio condutor da investigação.
Priorização dos casos de uso
Nem todo cenário merece o mesmo investimento. A tabela abaixo resume a ordem que recomendamos para uma operação com recursos limitados, combinando probabilidade de abuso, impacto e esforço de implementação:
| Prioridade | Caso de uso | Sinal central | Ação do analista |
|---|---|---|---|
| 1 | DCSync fora do controlador | Replicação iniciada por endpoint comum | Isolar host e trocar senha da KRBTGT |
| 2 | Adição a grupos privilegiados | Alteração de associação fora da janela de mudança | Confirmar ticket e reverter alteração |
| 3 | Reset de senha em cascata | Série de resets pelo mesmo operador | Entrevistar proprietário da conta |
| 4 | Dump de SAM e hives do registro | Comandos de gravação de hives em horário atípico | Colete memória e revise sessões ativas |
A ordem não é dogma: ambientes com forte exposição de VPN ou help desk abundante podem elevar o reset de senha em cascata ao topo, porque é a porta de entrada mais barata para o atacante.
Como implementar as detecções
Com os casos de uso priorizados, a implementação segue um roteiro curto e verificável:
- Confirme o encaminhamento dos logs de replicação e de gerenciamento de contas dos controladores de domínio para o SIEM.
- Ative as regras do ruleset do Wazuh que cobrem DCSync e DCShadow e valide com um teste controlado em ambiente de homologação.
- Documente cada alerta em um playbook com critério de escalonamento e responsável definido.
- Meça falsos positivos por duas semanas e ajuste filtros de janela de manutenção antes de ampliar a base.
- Repita o teste controlado a cada trimestre para garantir que a detecção continua viva após atualizações.
Para equipes com mais de um SIEM, o formato aberto da Sigma resolve o problema de portabilidade: escrever a lógica uma única vez em YAML e converter para a query do SIEM evita retrabalho e mantém a regra auditável, como mostra a documentação oficial do Sigma. Para o ciclo completo de transformar técnica em regra validada, o método já discutido no guia de detecção e resposta a ransomware no SOC se aplica sem alterações.
