Auditar a segurança do Active Directory: o que revisar primeiro e como comprovar a remediação

Para auditar a seguranca do active directory de forma sólida, é preciso começar pela evidência e não por uma checklist genérica. Um audit de Active Directory defensável precisa mostrar quais identidades podem controlar o diretório, quais permissões podem replicar segredos ou reescrever fronteiras de confiança, quais configurações de protocolo ou certificado ainda criam caminhos de ataque curtos e quais provas serão preservadas para validar a remediação depois.

Este guia permanece focado em Active Directory on-prem. Se seus operadores, papéis privilegiados ou fluxos de recuperação também dependem de Microsoft Entra, essa revisão deve ser executada em paralelo com uma avaliação separada de Entra, em vez de misturar os dois escopos em um relatório vago. O objetivo aqui é mais estreito: mostrar o que um audit AD deve cobrir primeiro, quais achados merecem remediação antecipada e como comprovar que uma correção realmente alterou o plano de controle.

Um audit AD útil deve produzir cinco resultados:

1. um inventário delimitado das superfícies do diretório que realmente importam
2. uma lista de identidades e permissões capazes de controlar ativos privilegiados ou replicar segredos
3. uma lista mais curta de caminhos de ataque que exigem remediação imediata
4. evidência de que controles de hardening estão realmente aplicados em produção
5. um pacote de validação comparável ao ciclo seguinte de revisão

Auditar a segurança do Active Directory: o que isso significa de fato?

Um audit de Active Directory não é apenas uma revisão de política de senha nem um relatório pontual de saúde. É uma revisão baseada em evidências das identidades, permissões, serviços, políticas e telemetria que determinam quem pode controlar o diretório e com que rapidez esse controle pode ser abusado.

Isso significa que o resultado do audit precisa responder perguntas concretas:

• Quais usuários, grupos, contas de serviço ou computadores têm controle de todo o domínio ou quase todo ele?
• Quais direitos podem replicar dados sensíveis do diretório ou reescrever fronteiras de confiança?
• Quais configurações de protocolo e delegação reduzem o custo de ataque para um adversário?
• Quais achados são apenas deriva de configuração e quais criam caminhos diretos de escalada?
• Quais exportações, logs e snapshots de estado provam que uma correção é real?

Se a revisão não consegue responder a essas perguntas, ela continua sendo uma checklist e não um audit. Essa diferença importa porque um ambiente pode parecer aceitável em uma planilha de conformidade e ainda assim expor caminhos curtos até Domain Admin por meio de direitos de replicação, delegação, contas privilegiadas obsoletas ou abuso de certificados.

Defina o escopo antes de revisar os achados

A forma mais rápida de perder tempo é começar a revisar achados antes de definir o escopo.

Decisões obrigatórias de escopo

Primeiro é preciso decidir quais superfícies do diretório estão realmente em jogo:

• o domínio ou a floresta revisados
• os controladores de domínio e os grupos administrativos privilegiados
• os grupos de administração delegada e as contas de serviço de alto impacto
• os direitos de replicação, os objetos sensíveis do ponto de vista ACL e os limites de herança
• a delegação Kerberos e a exposição de service principals
• Group Policy, postura LDAP, Windows LAPS e audit policy
• AD CS, mas apenas se existir na floresta

O escopo deve continuar honesto. Se AD CS não está implantado, é preciso dizer que ele está fora do escopo e seguir em frente. Se uma equipe PKI separada é dona dele, mas AD CS existe na floresta, ele pertence ao audit porque a emissão de certificados ainda pode alterar a exposição privilegiada. A mesma regra vale para identidade híbrida: se Microsoft Entra afeta operadores privilegiados, caminhos de recuperação ou administração de aplicações, registre essa dependência, mas não afirme que uma revisão de Entra substitui uma revisão de AD.

Requisitos de evidência antes do primeiro export

Este também é o momento de decidir quais provas serão preservadas entre os ciclos. Se o audit precisará demonstrar mais tarde que um grupo privilegiado foi limpo ou que um direito perigoso foi removido, esse requisito deve ser capturado antes do primeiro export.

Revise primeiro o acesso privilegiado e o Tier 0

Comece pelo plano de controle do diretório, frequentemente descrito operacionalmente como Tier 0. Isso significa revisar as identidades e os caminhos administrativos que podem alterar diretamente o domínio, os controladores de domínio, as fronteiras de confiança ou os objetos que os protegem.

O que revisar na primeira passada

Revise no mínimo:

• grupos privilegiados nativos e personalizados
• grupos de administração delegada e cadeias de aninhamento de grupos
• contas privilegiadas obsoletas e antigas contas de exceção
• contas de serviço privilegiadas que ainda mantêm acesso permanente
• separação administrativa entre identidades de usuário normais e identidades administrativas

Esse é o ponto de partida correto porque práticas ruins de administração e segmentação fraca são exatamente onde compromissos reais de AD se consolidam. A orientação ANSSI de 2023 sobre administração segura de sistemas baseados em AD afirma explicitamente que compromissos de AD resultam de más práticas administrativas e segmentação insuficiente, e depois descreve como atacantes usam movimento lateral e escalada de privilégios para assumir o controle completo do diretório.

O que essa seção precisa provar

O teste prático é simples: você consegue explicar quem administra o diretório, de onde, com que tipo de conta e por que esse acesso ainda existe? Se não, o audit precisa parar aqui primeiro. Um diretório com política de senha limpa, mas com desenho fraco de acesso privilegiado, continua sendo um diretório fraco.

Para padrões relacionados de deriva, use Privileged Access Drift Active Directory: How Admin Rights Creep Back After Audits e Stale Privileged Accounts: Hidden Risk in Active Directory como revisões complementares.

Audite direitos de replicação, abuso de ACL e caminhos de ataque curtos

Depois dos grupos privilegiados, revise as permissões que podem contorná-los silenciosamente. Um audit AD sério precisa incluir principais com capacidade de replicar segredos e com controle amplo sobre objetos sensíveis.

Direitos que merecem revisão imediata

A Microsoft documenta DS-Replication-Get-Changes-All como um direito de controle de acesso que permite a replicação de dados secretos do domínio. Isso basta para tornar os direitos de replicação um tema de audit de primeira linha, e não um caso avançado de nicho. Se você não sabe exatamente quais principais possuem direitos de replicação, o audit está incompleto.

O mesmo vale para controle de objeto. Não se trata apenas de localizar membros óbvios de grupos admin. Trata-se de identificar caminhos de escrita, gestão de permissões ou tomada de propriedade sobre objetos de alto valor, como:

• a raiz do domínio
• grupos privilegiados
• AdminSDHolder
• OUs que hospedam admins sensíveis, servidores ou GPOs
• contêineres vinculados a GPO capazes de alterar a postura de segurança em escala

Que telemetria ajuda a validar mudanças

O logging importa aqui, mas precisa ser descrito com precisão. Event 5136 é gerado quando um objeto do serviço de diretório é modificado, mas apenas se o objeto tiver a SACL correta. Event 4662 registra operações realizadas sobre um objeto AD, mas novamente só quando a SACL apropriada existe e a operação a aciona. Nenhum desses eventos é um detector mágico. Eles são pontos de evidência úteis para validar mudanças de alto valor e monitorar objetos específicos depois que o escopo foi corretamente definido.

É por isso que pensar em caminhos de ataque importa. A pergunta não é apenas se um direito existe. A pergunta real é se esse direito cria um caminho curto até o controle do diretório. Para uma revisão mais profunda, complemente com ACL Abuse and DCSync: The Silent Paths to Domain Admin e Active Directory Attack Paths to Domain Admin.

Revise Kerberos, delegação e exposição de contas de serviço

Kerberos continua central para a exposição de AD, especialmente por meio de contas de serviço e configurações de delegação.

Contas e configurações a revisar primeiro

Revise no mínimo:

• contas de usuário ou serviço com SPN
• contas privilegiadas que também expõem SPN
• unconstrained delegation
• constrained delegation e resource-based constrained delegation quando existirem
• contas de serviço sem owner claro, sem revisão recente ou com privilégios excessivos

Por que a exposição de contas de serviço pertence ao núcleo do audit

Contas com SPN pertencem ao escopo porque Kerberoasting depende de service tickets solicitados para esses SPNs, e é por isso que MITRE ATT&CK T1558.003 continua sendo uma referência útil de contexto de detecção para um audit técnico. O audit não precisa de um walkthrough de exploração. O que ele precisa é mostrar quais contas de serviço expõem oportunidade de cracking offline e se algumas delas também são privilegiadas.

A delegação exige o mesmo nível de precisão. A Microsoft descreve constrained delegation como uma forma mais restritiva de delegação do que unconstrained delegation, porque limita os serviços para os quais um servidor pode agir em nome de um usuário. Isso não torna constrained delegation automaticamente segura. Significa apenas que ela precisa ser revisada em contexto: quais serviços de front-end estão autorizados, quais serviços de back-end confiam neles e se a necessidade de negócio ainda existe.

Se você quiser a análise específica de delegação, use Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse. No audit em si, mantenha o foco em ownership, privilégio e caminhos de abuso alcançáveis.

Inclua AD CS se ele existir na floresta

Se Active Directory Certificate Services estiver implantado em qualquer ponto da floresta, ele deve ser incluído. A Microsoft documenta AD CS como um papel do Windows Server para emissão e gestão de certificados PKI usados em protocolos de autenticação e comunicação segura. Isso basta para tratá-lo como infraestrutura de identidade, e não como um tema secundário para uma futura revisão de PKI.

O que a parte de AD CS deve cobrir

Um audit AD útil deve, portanto, revisar:

• CAs empresariais que emitem certificados relevantes para autenticação
• templates de certificado publicados
• quem pode se inscrever e quem pode modificar permissões dos templates
• se a emissão de certificados amplia a exposição privilegiada
• se caminhos por certificados criam rotas de escalada que contornam o trabalho já feito em grupos e delegação

Não se deve assumir que todo ambiente AD possui AD CS. Mas, se existir, ele não pode ficar fora do audit. A emissão de certificados e as permissões dos templates podem alterar materialmente quem pode se autenticar e como quem. Para a análise técnica específica de certificados, veja ADCS Certificate Attacks: How ESC1 to ESC8 Lead to Domain Admin.

Verifique GPO, LDAP, LAPS e controles de logging

Depois de entender os caminhos privilegiados e os mecanismos de escalada, é preciso revisar os controles que deveriam endurecer o ambiente e gerar a telemetria em que a equipe confia.

Controles que precisam ser validados diretamente

Para LDAP, a Microsoft afirma que LDAP signing assina criptograficamente as comunicações LDAP para verificar autenticidade e integridade, enquanto channel binding vincula a segurança da camada de aplicação à sessão TLS subjacente. Na prática, o audit precisa confirmar a policy efetiva aplicada nos controladores de domínio, e não apenas o padrão pretendido. Isso importa ainda mais agora porque a Microsoft documenta claramente as fronteiras de versão: novos deployments de Active Directory em Windows Server 2025 exigem LDAP signing por padrão, enquanto ambientes atualizados preservam a policy existente. Isso significa que é preciso auditar a postura efetiva, e não assumir o default. Para detalhes de configuração e validação, use LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

Para Windows LAPS, a Microsoft documenta que a funcionalidade gere automaticamente e faz backup de senhas de administrador local, e que também pode fazer backup da senha DSRM dos controladores de domínio de Active Directory. Um audit AD deve, portanto, verificar não apenas se LAPS está presente, mas se a população prevista está coberta, onde as senhas são armazenadas, quem pode lê-las e se a proteção DSRM está configurada onde for necessária. Para a lacuna operacional, veja Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter.

O logging que prova mudanças de controle

Para logging, a formulação precisa continuar exata:

• Audit Security Group Management cobre mudanças como criação, exclusão e adição ou remoção de membros de grupos.
• Event 5136 ajuda a validar modificações de objetos quando a SACL correta existe.
• Event 4662 ajuda a monitorar operações sobre objetos AD sensíveis quando directory service access auditing e as SACLs estão corretamente configurados.

A Microsoft também afirma que advanced audit policy settings podem ser gerenciados por Group Policy para que organizações possam modificar, testar e implantar auditoria mais granular para os usuários e grupos que realmente importam. Essa é a postura operacional correta: testar a policy, confirmar o volume e a retenção dos eventos e verificar que a equipe realmente revisa a evidência gerada. Para os eventos mais importantes depois do rollout, veja Active Directory Monitoring: Security Event IDs That Matter.

Evidências que devem ser preservadas entre ciclos de audit

Um audit AD útil deixa um pacote de evidências reutilizável, e não apenas um deck de slides.

Pacote mínimo de evidências

Guarde data, escopo, fonte e owner junto de cada artefato. Se o próximo audit não puder comparar exportações equivalentes, a equipe vai gastar tempo discutindo se um achado é novo em vez de provar que um caminho desapareceu.

Priorize a remediação pelo impacto sobre a identidade

Não se deve remediar em fila plana. É preciso começar pelo que altera mais diretamente o alcance de um atacante.

Correções que geralmente vêm primeiro

As remediações de primeira prioridade normalmente incluem:

• direitos ligados à replicação que expõem dados secretos do domínio
• caminhos ACL ou de herança que criam rotas curtas até objetos privilegiados
• unconstrained delegation e contas de serviço privilegiadas muito expostas
• más configurações de AD CS que criam abuso de autenticação ou enrollment

Controles que fortalecem o ciclo seguinte

Depois vêm os controles que reduzem a liberdade do atacante e melhoram a validação futura:

• postura de LDAP signing e channel binding
• cobertura de Windows LAPS e higiene de senhas privilegiadas
• lacunas de audit policy que deixam objetos de alto valor efetivamente sem monitoramento

Só depois disso faz sentido gastar energia em limpezas que melhorem governança, mas não encurtem materialmente um caminho de ataque por si só. É por isso que uma revisão repetível importa mais do que um relatório estático. Recurring AD Audit Workflow: Why Annual Audits Drift and How Continuous Posture Monitoring Works cobre o modelo operacional, enquanto Active Directory Security Audit Tools: What to Compare Before You Choose trata da questão de tooling.

Validação após a remediação

Um achado não está fechado porque um ticket diz que está. É preciso validar a partir da mesma superfície de controle que expôs o problema.

Após uma limpeza de acesso privilegiado, execute novamente exportações de grupos e administração delegada e confirme que a identidade não detém mais o caminho efetivo. Após a limpeza de direitos de replicação, confirme que o principal não aparece mais no conjunto de revisão de replicação. Após hardening de LDAP, verifique a policy efetiva e valide que binds sem assinatura são rejeitados como esperado. Após um rollout de Windows LAPS, confirme a aplicação da policy e o estado do backup de senhas na população-alvo. Após uma correção em AD CS, verifique que o template arriscado, o escopo de enrollment ou o caminho de permissão realmente desapareceram.

O que um achado fechado deve conter

A telemetria também precisa ser validada. Se você espera que mudanças futuras em objetos sensíveis produzam evidência 5136 ou 4662, é preciso provar que o modelo de SACL e a audit policy realmente geram os eventos em que você pretende confiar. Se mudanças de grupo são importantes, é preciso provar que os eventos correspondentes estão presentes no caminho de logging e são retidos por tempo suficiente para serem úteis.

O pacote final de fechamento deve incluir:

• o estado antes e depois
• o owner da mudança
• o método de validação
• a exceção residual, se existir
• a data em que o achado será reavaliado

É isso que transforma um audit AD em um controle repetível, e não em um documento que envelhece assim que a próxima mudança de delegação acontece.

Como a EtcSec ajuda a estruturar um audit AD repetível

A EtcSec deve se encaixar dentro desse workflow, e não substituí-lo por linguagem de marketing. A parte útil é a repetibilidade.

Onde o produto se encaixa, e onde não se encaixa

Um audit AD repetível precisa rodar os mesmos checks nas mesmas superfícies de controle para mostrar se um caminho privilegiado é novo, continua igual ou foi realmente remediado. A EtcSec ajuda a estruturar isso mantendo a revisão ancorada em achados concretos como EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION, ESC1_VULNERABLE_TEMPLATE, PATH_ACL_TO_DA, LDAP_SIGNING_DISABLED e LAPS_NOT_DEPLOYED.

O modelo atual de deployment também suporta coleta local, em vez de forçar que o audit comece como um exercício puramente SaaS. Isso importa operacionalmente porque a evidência AD é melhor quando o caminho de coleta permanece estável, quando os mesmos controles são medidos novamente após a remediação e quando os resultados podem ser preservados entre os ciclos.

A proposta de valor prática permanece, portanto, estreita e testável: estruturar o audit, manter o conjunto de achados mensurável e tornar os reruns mais fáceis de defender. Se a pergunta for sobre seleção de ferramenta e não sobre método de audit, use Active Directory Security Audit Tools: What to Compare Before You Choose.

Referências primárias

• Audit Security Group Management
• 5136(S): A directory service object was modified
• 4662(S, F): An operation was performed on an object
• DS-Replication-Get-Changes-All extended right
• LDAP signing for Active Directory Domain Services
• Manage LDAP signing using Group Policy for Active Directory Domain Service
• What is Windows LAPS?
• Kerberos Constrained Delegation Overview in Windows Server
• What is Active Directory Certificate Services?
• Advanced Audit Policy Configuration
• Audit Active Directory objects in Windows Server 2003
• Recommandations pour l’administration sécurisée des SI reposant sur AD
• MITRE ATT&CK T1558.003: Kerberoasting