Lacunas na Configuração da Política de Auditoria do Active Directory: As Categorias que Ninguém Ativa Antes de Precisar dos Logs

O Que São Lacunas na Configuração da Política de Auditoria do Active Directory

A maioria das equipes de Active Directory presume que, se o log de eventos de segurança está enchendo, o ambiente "está sendo auditado". Não está — pelo menos não da forma que importa para detectar um ataque. Lacunas na configuração da política de auditoria do Active Directory são as subcategorias que o Windows entrega desativadas, parcialmente configuradas ou silenciosamente sobrepostas, de modo que os eventos que um investigador precisaria mais tarde nunca chegam a ser gerados. O Windows organiza o que é registrado por meio de uma Advanced Audit Policy Configuration composta por 10 categorias subdivididas em dezenas de subcategorias — expandida das 9 categorias básicas originais para 53 subcategorias granulares a partir do Windows Vista e do Windows Server 2008 (o número cresceu ainda mais desde então, já que versões posteriores do Windows adicionaram subcategorias como Group Membership e PNP Activity), conforme descrito no histórico da própria Microsoft sobre as políticas avançadas de auditoria do Windows Server. Cada subcategoria é um interruptor independente. Deixe uma desligada, e todo evento que ela geraria simplesmente nunca existe — não há log para revisar depois, nenhuma lacuna perceptível numa análise de incidente, nada.

Na prática, quatro pontos cegos aparecem repetidamente em ambientes AD que nunca tiveram sua política de auditoria revisada deliberadamente, e que correspondem diretamente ao que nossas verificações de auditoria de segurança do Active Directory procuram:

• Account Management deixado nos padrões do Windows em vez de totalmente ativado (sucesso e falha), de modo que alterações em usuários, computadores e grupos ficam parcial ou totalmente sem registro.
• Account Logon (a categoria que de fato cobre a autenticação Kerberos nos controladores de domínio) totalmente desativada — essa vem desligada por padrão até em servidores.
• Policy Change sem cobrir as subcategorias que importam além daquela que o Windows já registra por conta própria.
• Nenhuma conta honeypot ou isca em nenhum lugar do diretório, portanto não há um "fio-desencadeador" de quase zero falsos positivos para enumeração ou abuso de credenciais.

Cada uma é pequena isoladamente. Juntas, significam que as categorias que capturariam criação de privilégios, abuso de credenciais e um invasor cobrindo rastros são exatamente as que menos provavelmente estão registrando algo. Essas lacunas se somam às demais prioridades de hardening cobertas em Hardening do Active Directory: O Que Bloquear Primeiro — a política de auditoria raramente recebe a mesma atenção que ACLs ou o isolamento do Tier 0, justamente porque um log ausente não se anuncia sozinho. Diferente de uma ACL perigosa ou de um grupo com permissões excessivas, uma subcategoria de auditoria desativada não produz nenhum artefato para se tropeçar durante uma revisão de rotina — a única forma de encontrá-la é ir verificar diretamente a política efetiva no controlador de domínio, em vez de presumir que o editor de GPO conta a história completa.

Como a Política de Auditoria do Windows Realmente Funciona — E Onde Ela Falha Silenciosamente

A Microsoft publica uma tabela de recomendações de linha de base exatamente por esse motivo: a política padrão do Windows Server deixa várias subcategorias relevantes para identidade desativadas, e apenas um subconjunto das subcategorias de Account Management registra falhas de fábrica. Dois padrões se destacam especificamente para o AD:

• Audit Credential Validation (a subcategoria em Account Logon que rege a validação de senha NTLM e Kerberos) vem como No | No — completamente desativada — tanto no Windows Client quanto no Windows Server. A própria recomendação de linha de base da Microsoft a eleva para Yes | Yes em servidores (os controladores de domínio de que trata este artigo) e para Yes | No em clientes, e as outras três subcategorias de Account Logon (Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events) não têm padrão nenhum.
• Audit Policy Change (em Policy Change) vem por padrão como Yes | No — apenas sucesso. A linha de base da Microsoft recomenda Yes | Yes.

Esse segundo ponto importa por causa de um detalhe que a própria Microsoft documenta no evento: o Event ID 4719 ("System audit policy was changed") "é sempre registrado independentemente da configuração da subcategoria 'Audit Policy Change'". Isso é tranquilizador para o único evento que a maioria dos administradores conhece — mas Authentication Policy Change e Authorization Policy Change são subcategorias separadas, com interruptores independentes, dentro da mesma categoria Policy Change, e nenhuma delas recebe essa mesma isenção. Se não estiverem explicitamente ativadas, um invasor que afrouxe discretamente as configurações de delegação Kerberos ou uma atribuição de privilégio não deixa rastro nenhum.

A Armadilha da Sobreposição Legada-vs-Avançada

Há uma segunda armadilha, mais operacional, e é o mesmo tipo de problema das configurações incorretas de GPO que transformam o Group Policy em vetor de ataque: mesmo quando um GPO ativa corretamente uma subcategoria avançada, essa configuração pode ser silenciosamente sobreposta pela Local Security Policy legada de 9 categorias, a menos que o domínio também ative "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings" — o valor de registro SCENoApplyLegacyAuditPolicy em HKLM\SYSTEM\CurrentControlSet\Control\Lsa, conforme a documentação da Microsoft para essa política. Pule essa etapa, e o GPMC pode mostrar cada subcategoria corretamente configurada enquanto o controlador de domínio continua silenciosamente aplicando a política antiga baseada em categoria.

Este texto trata deliberadamente apenas de saber se essas categorias estão sequer ativadas. O que fazer depois que estiverem — quais IDs de evento específicos alertar e como construir a lógica de detecção — é abordado em Monitoramento do Active Directory: Os IDs de Evento de Segurança que Importam.

Detecção: Verifique o Que Está Realmente Ativado, Não o Que o GPO Alega

Verificando a Política Efetiva com o auditpol

Não confie apenas no Group Policy Management Console. Execute o auditpol diretamente em um controlador de domínio para ver a política efetiva:

# Política de auditoria efetiva completa neste DC
auditpol /get /category:*

# Apenas as categorias que este artigo aborda
auditpol /get /category:"Account Logon"
auditpol /get /category:"Account Management"
auditpol /get /category:"Policy Change"

# Confirmar se a configuração de sobreposição legada do GPO realmente entrou em vigor
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name SCENoApplyLegacyAuditPolicy -ErrorAction SilentlyContinue

Se alguma subcategoria mostrar "No Auditing", os eventos da tabela abaixo não estão sendo gerados naquela máquina — ponto final, nada para investigar depois:

Por Que uma Conta Honeypot Fecha o Ciclo

Um honey user é uma conta AD isca sem privilégio real, posicionada de modo que ferramentas de enumeração (BloodHound, password sprayers, scripts de Kerberoasting) a encontrem e a testem como qualquer outro alvo. Como um usuário ou serviço legítimo nunca a toca, qualquer 4768/4769/4624 contra essa conta é um sinal com confiança próxima de 100% — o oposto do problema de fadiga de alertas que as outras três categorias podem gerar depois de ativadas. Iscas eficazes precisam de metadados e posicionamento realistas, não de um nome óbvio como honeypot-admin-01, conforme a orientação de tecnologia de decepção nessa área. O mesmo princípio sustenta a detecção de abuso de ACL e caminhos de DCSync: uma solicitação de replicação vinda de uma conta que não tem motivo algum para replicar é exatamente o tipo de sinal de baixo ruído e alta confiança que essas categorias de auditoria existem para revelar.

Também vale verificar: invasores que conseguem desativar o registro por completo estão executando a técnica MITRE ATT&CK T1562.002 — Impair Defenses: Disable Windows Event Logging, uma técnica de evasão de defesa que mira especificamente a política de auditoria de que trata este artigo. Um ambiente que nunca ativou essas categorias oferece a essa técnica uma vitória gratuita que ela não teria de outra forma.

Remediação: Fechando as Quatro Lacunas

Corrija Primeiro o Account Logon e o Account Management

1. Ative o Account Logon por completo, sucesso e falha, via Default Domain Controllers Policy → Computer Configuration → Policies → Windows Settings → Security Settings → Advanced Audit Policy Configuration → System Audit Policies → Account Logon: Credential Validation, Kerberos Authentication Service, Kerberos Service Ticket Operations, Other Account Logon Events.
2. Eleve o Account Management à linha de base da Microsoft (sucesso e falha) para User Account Management, Security Group Management, Computer Account Management e Other Account Management Events — não apenas o padrão de sucesso.

Complete o Policy Change e Trave a Sobreposição via GPO

3. Complete o Policy Change: ative Authentication Policy Change e Authorization Policy Change junto com a subcategoria Audit Policy Change já parcialmente ativa, para que adulterações em política Kerberos e atribuição de privilégios realmente gerem eventos.
4. Configure a sobreposição legada via GPO ("Audit: Force audit policy subcategory settings...") em todo o domínio, depois execute novamente a verificação auditpol /get acima em um DC após um gpupdate /force — verifique a política efetiva, não confie apenas no editor de GPO.

Implante uma Conta Isca e Alerte no 4719

5. Implante pelo menos uma conta honeypot por domínio, com atributos e posicionamento em grupos realistas, e alerte para qualquer evento de autenticação contra ela.
6. Encaminhe tudo isso a um SIEM e alerte incondicionalmente no Event ID 4719 — a própria orientação da Microsoft é tratar qualquer alteração não planejada da política de auditoria como um gatilho de investigação de alta prioridade, já que invasores desativam a auditoria especificamente para operar sem deixar evidências.

Trate isso como uma verificação recorrente, não como um projeto pontual: uma reconstrução de controlador de domínio, um novo GPO que reseta a configuração de sobreposição legada, ou uma migração para uma nova floresta podem reintroduzir silenciosamente qualquer uma dessas quatro lacunas, e nenhuma delas vai aparecer como um alerta — vão aparecer apenas como uma ausência, meses depois, num incidente em que os logs necessários nunca foram escritos. Incorporar essa verificação a um workflow recorrente de auditoria de AD é a única forma confiável de detectar esse desvio antes que ele importe.

Como a EtcSec Detecta Isso

A EtcSec verifica os objetos de Group Policy do Active Directory em cada auditoria exatamente em busca dessas lacunas: AUDIT_POLICY_WEAK sinaliza subcategorias abaixo da linha de base da Microsoft, DC_AUDIT_POLICY_INCOMPLETE sinaliza controladores de domínio onde a política efetiva não corresponde ao que o GPO alega, ANSSI_R38_ADVANCED_AUDIT_NOT_ENABLED verifica a conformidade com a recomendação ANSSI R38 para cobertura de política avançada de auditoria, e NO_HONEYPOT_ACCOUNTS sinaliza diretórios sem nenhuma conta isca em todo o escopo.