O Que E o Monitoramento de Seguranca do Active Directory?
O monitoramento de seguranca do Active Directory e a combinacao de politica de auditoria, coleta de eventos, correlacao e analise de baseline necessaria para detectar ataques de identidade contra Domain Controllers e contas privilegiadas. Muitos ambientes AD geram eventos do Windows Security, mas bem menos ambientes geram os eventos corretos e os encaminham para deteccoes que um analista realmente consiga usar.
Monitoramento em AD nao e apenas retencao de logs. E a disciplina de escolher as subcategorias que importam, provar que os eventos estao presentes nos Domain Controllers e construir deteccoes em torno do comportamento do atacante, e nao do volume bruto.
Um programa util de monitoramento AD comeca pelos caminhos de ataque que os defensores realmente precisam ver: abuso de tickets Kerberos, DCSync, mudancas em grupos privilegiados, gravacoes em objetos do diretorio, autenticacao NTLM, emissao de certificados e movimento lateral para servidores sensiveis.
Como Funciona o Monitoramento de Seguranca do Active Directory
A auditoria do Windows Security e controlada pela Politica de Auditoria Avancada e so produz dados uteis se as subcategorias corretas estiverem habilitadas.
Um pipeline de monitoramento pratico se parece com isto:
- A Politica de Auditoria Avancada habilita os eventos necessarios
- O Windows Event Log armazena os eventos de Security localmente
- WEF ou um agente encaminha os eventos para uma plataforma central
- A correlacao no SIEM transforma esses eventos em deteccoes e investigacoes
A falha mais comum continua sendo o primeiro passo: o coletor e o SIEM existem, mas as subcategorias essenciais de AD nunca foram habilitadas nos Domain Controllers que importam.
A documentacao do Microsoft Defender for Identity reforca esse ponto ao listar os eventos do Windows exigidos para sensores e infraestrutura relacionada. A lista inclui eventos de identidade essenciais como 4662, 4728, 4732, 4756 e 4776. Se seus domain controllers nao gerarem e encaminharem esses eventos, a logica de deteccao posterior nao consegue recuperar a evidencia ausente.
A Cadeia de Ataque Sem Monitoramento
DCSync - Sem Auditoria de Directory Service Access
Sem Audit Directory Service Access, o evento 4662 nao oferece aos defensores a visibilidade que eles esperam para o abuso de direitos de replicacao. O evento 4662 e gerado quando uma operacao e realizada em um objeto do Active Directory, mas a auditoria de objeto e a configuracao de SACL continuam essenciais para uma cobertura util.
Kerberoasting - Sem Visibilidade de Tickets Kerberos
Sem a coleta e revisao do 4769, solicitacoes incomuns de service ticket se misturam ao trafego normal, e solicitacoes com criptografia RC4 sao facilmente ignoradas. A Microsoft documenta o evento 4769 como um evento de solicitacao TGS gerado nos domain controllers. Atualizacoes mais recentes do Windows expoem campos Kerberos adicionais, o que pode melhorar a investigacao quando disponiveis.
Abuso de Grupo Privilegiado - Sem Alerta de Mudanca de Associacao
Sem cobertura para 4728, 4732 e 4756, um atacante pode adicionar uma conta backdoor a um grupo privilegiado e contar com o fato de que os administradores so vao perceber depois. Esses eventos correspondem a mudancas de associacao em grupos de seguranca globais, locais e universais.
Abuso de Delegacao ou GPO - Sem Visibilidade de Mudancas
Sem o 5136 e a auditoria de mudancas relacionada, modificacoes de alto impacto no diretorio podem ocorrer com muito pouco contexto investigativo. O evento 5136 e gerado quando um objeto do servico de diretorio e modificado, e se torna muito mais util quando combinado com o atributo alterado e o contexto do objeto.
Deteccao
Configuracao Essencial da Politica de Auditoria
Implante via GPO: Configuracao do Computador > Configuracoes do Windows > Configuracoes de Seguranca > Configuracao Avancada de Politica de Auditoria
| Categoria | Subcategoria | Configuracao | Eventos-Chave |
|---|---|---|---|
| Logon de Conta | Autenticacao Kerberos | Sucesso/Falha | 4768, 4771 |
| Logon de Conta | Operacoes de Ticket de Servico Kerberos | Sucesso/Falha | 4769 |
| Gerenciamento de Conta | Gerenciamento de Conta de Usuario/Grupo | Sucesso/Falha | 4720, 4728, 4732, 4738 |
| Acesso DS | Acesso ao Servico de Diretorio | Sucesso | 4662 |
| Acesso DS | Mudancas no Servico de Diretorio | Sucesso | 5136, 5137, 5141 |
| Logon/Logoff | Logon | Sucesso/Falha | 4624, 4625, 4648 |
| Uso de Privilegio | Uso de Privilegio Sensivel | Sucesso | 4672 |
| Mudanca de Politica | Mudanca de Politica de Auditoria | Sucesso | 4719 |
| Acesso a Objeto | Servicos de Certificacao | Sucesso/Falha | 4886, 4887 |
Referencia de Event IDs Criticos
| Event ID | Categoria | Prioridade de Alerta | O Que Ajuda a Detectar |
|---|---|---|---|
| 4662 | Acesso DS | CRITICA | Abuso de direitos de replicacao e investigacao de DCSync |
| 4769 | Kerberos | ALTA | Kerberoasting e atividade suspeita de service ticket |
| 4771 | Kerberos | MEDIA | Password spray ou padroes repetidos de falha de pre-autenticacao |
| 4728 / 4732 / 4756 | Gerenciamento de Grupo | CRITICA | Mudancas em associacao de grupo privilegiado |
| 4720 | Gerenciamento de Conta | ALTA | Criacao de nova conta em contextos sensiveis |
| 4738 | Gerenciamento de Conta | MEDIA | Mudancas em conta de usuario, como alternancia de flags de risco |
| 5136 | Mudancas de Diretorio | ALTA | Modificacao de GPO, delegacao ou objeto sensivel |
| 4887 | Servicos de Certificado | ALTA | Emissao de certificado que pode favorecer abuso de ADCS |
| 4624 (Tipo 3) | Logon | MEDIA | Movimento lateral e logons de rede incomuns |
| 4672 | Uso de Privilegio | ALTA | Logons que recebem privilegios especiais |
| 4776 | Validacao de Credencial | MEDIA | Atividade de validacao NTLM para contas de dominio |
Consultas de Deteccao SIEM (Elastic KQL)
Deteccao de DCSync:
event.code: "4662" AND
winlog.event_data.Properties: ("*1131f6ad*" OR "*1131f6aa*") AND
NOT winlog.event_data.SubjectUserName: ("*$")
Deteccao de Kerberoasting:
event.code: "4769" AND
winlog.event_data.TicketEncryptionType: "0x17" AND
NOT winlog.event_data.ServiceName: ("krbtgt" OR "*$")
Mudanca de Grupo Privilegiado:
event.code: ("4728" OR "4732" OR "4756") AND
winlog.event_data.TargetUserName: ("Domain Admins" OR "Enterprise Admins" OR "Schema Admins")
Dica: Comece com um pequeno conjunto de deteccoes de alta confianca que o time realmente vai investigar. DCSync, mudancas em grupos privilegiados e abuso de service ticket costumam gerar muito mais valor do que um grande conjunto de regras sem manutencao.
Mapeamento de Campos e Validacao do Parser
Antes de escrever logica de deteccao complexa, valide o mapeamento de campos do seu SIEM. O mesmo evento do Windows pode chegar com nomes de campo diferentes dependendo do conector, do agente ou da camada de normalizacao. Para cada deteccao critica, confirme:
- o event ID e interpretado de forma consistente
- os campos de conta separam contas de usuario, dominio e maquina
- os campos de workstation de origem e endereco do cliente sao preservados
- os campos de criptografia de ticket estao presentes para deteccoes Kerberos
- os campos de objeto e atributo de diretorio sao preservados para 4662 e 5136
- os campos de solicitacao e template de certificado sao preservados para eventos AD CS
Uma regra que funciona em laboratorio, mas perde o campo critico em producao, nao e cobertura.
Remediacao
Ganho Rapido: Habilite
Directory Service Access,Directory Service Changese as subcategorias Kerberos em todos os Domain Controllers antes de ajustar qualquer outra coisa.
1. Implantar Politica de Auditoria Avancada via GPO
auditpol /get /category:*
auditpol /set /subcategory:"Directory Service Changes" /success:enable
auditpol /set /subcategory:"Directory Service Access" /success:enable
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable
auditpol /set /subcategory:"Security Group Management" /success:enable
auditpol /set /subcategory:"Certification Services" /success:enable /failure:enable
2. Aumentar a Capacidade do Log de Security
O tamanho padrao do log de Security costuma ser pequeno demais para Domain Controllers muito movimentados.
wevtutil sl Security /ms:1073741824 /rt:false /ab:true
A capacidade do log deve ser dimensionada com base no volume real de eventos. Dominios com muito trafego Kerberos e DCs movimentados podem sobrescrever evidencias rapidamente se os logs de Security permanecerem nos valores padrao pequenos.
3. Encaminhar Eventos dos Domain Controllers Centralmente
winrm quickconfig
wecutil cs subscription.xml
gpupdate /force
O encaminhamento deve preservar o XML do evento ou os campos normalizados exigidos para deteccao. Se seu coletor descartar Properties, ObjectDN, TicketEncryptionType ou os campos de workstation de origem, regras de alto valor degradam para alertas genericos.
4. Estabelecer Baselines Antes de Ajustar Limiares
Get-WinEvent -ComputerName DC01 -FilterHashtable @{LogName='Security'; Id=4768} |
Group-Object {$_.TimeCreated.Hour} |
Select-Object Name, Count |
Sort-Object Name
Use essas baselines para entender o volume normal de Kerberos e logon antes de introduzir limiares de anomalia.
5. Mapear Deteccoes para Caminhos de Ataque
Nao monitore event IDs isoladamente. Mapeie cada deteccao para o caminho de ataque que ela sustenta:
- DCSync precisa de eventos de direitos de replicacao e mudancas privilegiadas no diretorio
- Kerberoasting precisa de visibilidade de service ticket, contexto de criptografia e inventario de contas de servico
- abuso de delegacao precisa de visibilidade de mudanca de atributo e autenticacao incomum de conta de maquina
- NTLM relay precisa de validacao NTLM, logons de destino e acoes subsequentes especificas do servico
- abuso de AD CS precisa de contexto de solicitacao, emissao e template de certificado
Esse mapeamento evita que o programa de monitoramento vire uma lista desconexa de eventos.
Como o EtcSec Detecta Isso
O EtcSec verifica a cobertura de politica de auditoria que os defensores precisam para investigar os principais caminhos de ataque AD apresentados no restante do relatorio.
Os achados relacionados a monitoramento destacam subcategorias de auditoria ausentes, retencao insuficiente e outras lacunas que deixariam abuso de identidade de alto valor invisivel ou dificil de reconstruir.
Deteccoes para Implementar Primeiro
Se o time de monitoramento so puder implantar algumas regras de alto valor inicialmente, comece pelos ataques que sao ao mesmo tempo comuns e operacionalmente revisaveis:
- abuso de direitos de replicacao e tentativas de DCSync
- mudancas em associacao de grupo privilegiado
- solicitacoes suspeitas de service ticket associadas a Kerberoasting
- mudancas de alto valor em objetos de diretorio, como gravacoes de GPO ou delegacao
- atividade de emissao de certificado em ambientes com ADCS habilitado
- padroes de validacao NTLM e logon de rede para investigacoes de relay ou movimento lateral
Essas deteccoes criam uma base util sem inundar os analistas com ruido de baixa qualidade.
Revisao de Retencao e Cobertura
O monitoramento de seguranca do Active Directory tambem deve incluir uma revisao de retencao. Um domain controller pode produzir grandes volumes de eventos de Kerberos, logon e gerenciamento de conta, e um log de Security local pequeno pode sobrescrever exatamente a evidencia necessaria durante a resposta a incidentes. Revise juntos o tamanho maximo do log de Security, a latencia de encaminhamento, falhas de ingestao no SIEM e a retencao em hot-storage. Se o SIEM mantem 90 dias de dados pesquisaveis, mas o coletor descarta silenciosamente event IDs de alto volume em periodos de pico, a politica de retencao aparente nao e a cobertura investigativa real.
Para evidencias Tier-0, defina quais eventos devem permanecer pesquisaveis durante toda a janela de resposta. Mudancas em grupos privilegiados, modificacoes de objetos de diretorio, emissao de certificados, acessos a objetos relevantes para DCSync e eventos Kerberos de alto valor nao devem ser tratados como telemetria de debug descartavel. Sao a evidencia que permite aos defensores reconstruir o que mudou, quem mudou e se o mesmo caminho foi reutilizado apos a remediacao.
Validacao Apos Mudancas na Politica de Auditoria
Apos alterar a politica de auditoria, confirme que a cadeia de monitoramento funciona de ponta a ponta:
- verifique se os eventos esperados aparecem nos Domain Controllers dentro do escopo
- confirme que os mesmos eventos chegam ao seu coletor ou SIEM sem atraso excessivo ou perdas silenciosas
- teste pelo menos uma acao administrativa controlada e uma acao Kerberos benigna para validar parsing e mapeamento de campos
- revise a retencao para garantir que a evidencia critica ainda esteja presente quando os investigadores precisarem dela
- confirme que 4662 e 5136 incluem o contexto de objeto e atributo necessario para investigacoes de diretorio
- confirme que 4769 inclui as informacoes de criptografia e servico necessarias para investigacoes Kerberos
- confirme que os eventos de AD CS estao presentes caso existam servicos de certificado no ambiente
Controles Relacionados
Este artigo combina naturalmente com Seguranca de Senhas no Active Directory: As Ma Configuracoes que os Atacantes Adoram, Ataques NTLM Relay: Sequestrar Autenticacao Sem Crackear Senhas, Ma Configuracoes de GPO: Quando a Group Policy Se Torna um Vetor de Ataque, Contas Obsoletas e Superprivilegiadas no AD e Ataques Delegacao Kerberos: Nao Restrita a RBCD. Um bom monitoramento e o que permite aos times provar que esses problemas foram corrigidos e detectar quando eles reaparecem.
Referencias Primarias
Explore as paginas de identidade que sustentam este tema

