EtcSecBeta
🏢Active DirectoryMonitoringPrivileged AccessPermissionsIdentityConfig

Auditoria recorrente de Active Directory: porque auditorias anuais ficam obsoletas e como monitorizar a postura continuamente

Auditorias anuais de AD envelhecem depressa. Veja como uma auditoria recorrente de Active Directory mede deriva e valida cada remediação.

ES
EtcSec Security Team
16 min read
Auditoria recorrente de Active Directory: porque auditorias anuais ficam obsoletas e como monitorizar a postura continuamente

Uma auditoria recorrente de Active Directory deve significar mais do que executar a mesma lista de controlo uma vez por ano. Active Directory é um plano de controle vivo: a pertença a grupos privilegiados muda, as ACL derivam, as GPO são alteradas, os modelos de certificado evoluem e a cobertura de registro degrada-se com o tempo. Uma revisão pontual anual ainda pode ser útil, mas não mostra se o diretório permaneceu seguro na semana seguinte. Um modelo melhor é uma auditoria recorrente de Active Directory: medir novamente os mesmos controles de alto valor numa cadência fixa, investigar rapidamente a nova deriva e usar cada nova execução para verificar a remediação, em vez de esperar pelo próximo ciclo de consultoria.

Isto importa porque o diretório foi concebido para mudar. A Microsoft documenta eventos dedicados para alterações de pertença a grupos de segurança, para modificações de objetos de diretório e para alterações de política de domínio. A orientação da ANSSI de 2023 para ambientes que dependem de Microsoft Active Directory centra-se na administração segura e na segmentação, enquanto a orientação da ANSSI para o registo em Active Directory cobre a recolha e a monitorização. Em conjunto, estas referências sustentam melhor um modelo de revisão recorrente do que um relatório pontual que fica arrumado numa prateleira. Na prática, as organizações que mantêm o AD mais saudável são as que voltam a rever as mesmas famílias de controlo e tratam a deriva de postura como um problema operacional, não como uma compra anual.

O que uma auditoria recorrente de Active Directory cobre de facto

Uma auditoria recorrente de Active Directory não é o mesmo que um SIEM, e também não é o mesmo que um pentest. Situa-se entre a revisão pontual e a deteção totalmente orientada por eventos. O objetivo é reavaliar o estado estrutural de segurança do diretório numa frequência compatível com a velocidade real de mudança do ambiente.

Em Active Directory, isso significa voltar a verificar pelo menos quatro camadas:

  • identidades privilegiadas e pertença a grupos;
  • delegações de direitos e caminhos ACL perigosos;
  • definições de segurança do domínio e dos controladores de domínio;
  • controlos de monitorização e recuperação que determinam se será possível detetar ou suportar o próximo incidente.

Este âmbito é mais amplo do que uma revisão restrita de hardening e mais estreito do que uma telemetria contínua de endpoints. Trata-se de medir repetidamente a superfície de ataque que continua a produzir caminhos reais de comprometimento em ambientes AD: direitos de replicação, delegação Kerberos, postura LDAP fraca, reutilização de palavras-passe de administrador local, contas privilegiadas obsoletas, caminhos de abuso de certificados e pontos cegos na política de auditoria.

Porque as auditorias pontuais de AD ficam obsoletas rapidamente

Isto não é linguagem de marketing. É uma propriedade do modo como Windows e AD realmente funcionam.

A Microsoft documenta que a gestão de grupos de segurança produz eventos de auditoria específicos quando membros são adicionados ou removidos. A mesma documentação de auditoria também descreve eventos de modificação de objetos de diretório e eventos de alteração de política de domínio. Só isso já basta para mostrar porque um PDF exportado uma vez por ano não consegue representar por muito tempo o estado do diretório: os objetos que definem privilégio e exposição estão sempre a mudar.

Alguns dos pontos de deriva mais importantes são operacionais, não teóricos:

  • um utilizador é adicionado a um grupo sensível para um projeto e nunca mais é removido;
  • uma conta de serviço recebe um novo SPN ou uma entrada de delegação demasiado ampla;
  • uma GPO ou uma política predefinida é alterada para resolver um problema de curto prazo e nunca é revertida;
  • a aplicação de LDAP signing ou channel binding mantém-se mais fraca do que o previsto porque um cliente legado bloqueou o rollout;
  • a cobertura de LAPS diminui porque novos servidores ficam fora da OU gerida ou porque uma nova imagem foi implantada sem a política correta;
  • modelos de AD CS ou ACL da PKI mudam durante trabalhos em certificados;
  • contas administrativas antigas continuam ativas porque ninguém repetiu a revisão de contas privilegiadas depois da auditoria inicial.

Por isso, o argumento contra revisões apenas anuais é simples: uma auditoria pontual captura o diretório no dia da recolha. Não mostra se os mesmos controlos de maior valor ainda se mantêm depois de mudanças de equipa, projetos, migrações, aquisições, trabalhos de PKI, alterações de GPO ou concessões de privilégio de emergência.

As famílias de controlo que vale a pena rever em cada ciclo

Um bom fluxo recorrente não volta a rever tudo com a mesma urgência. Volta a rever os controlos que envelhecem pior.

1. Grupos privilegiados e contas de administração obsoletas

Se a pertença privilegiada é uma das formas mais comuns de deriva da postura de segurança, deve ser também uma das primeiras coisas a medir novamente. A Microsoft recomenda explicitamente ativar auditoria de sucesso para a gestão de grupos de segurança, precisamente para visualizar criação, alterações, eliminações de grupos e novos membros. Isto importa porque o risco real raramente é "Domain Admins sempre esteve aberto a toda a gente". Mais frequentemente é "a pertença mudou, ninguém reparou, e a exceção tornou-se normal".

A revisão recorrente deve responder aqui a perguntas simples:

  • quem tem hoje pertença privilegiada direta ou indireta;
  • que contas privilegiadas estão obsoletas ou quase não são usadas;
  • se contas administrativas integradas são usadas no trabalho diário;
  • se utilizadores privilegiados continuam fora de controlos adicionais de proteção como Protected Users ou padrões de autenticação mais fortes.

É neste ponto que Contas obsoletas e superprivilegiadas no AD deixa de ser teoria e passa a ser operação.

2. ACL perigosas, direitos de replicação e caminhos de controlo

Um diretório pode parecer saudável ao nível dos grupos e ainda assim expor caminhos de tomada de controlo através de ACL. Direitos de replicação, WriteDACL, WriteOwner, GenericAll, direitos de auto-membro e alterações em AdminSDHolder são precisamente o tipo de problemas que não deveria esperar pela revisão do ano seguinte.

A Microsoft documenta o mecanismo AdminSDHolder porque os objetos protegidos herdam esse modelo de descritor de segurança. Isso faz dele exatamente o tipo de objeto do plano de controlo que merece escrutínio repetido. Se um direito perigoso cair sobre um objeto sensível e lá ficar durante meses, o facto de já ter existido uma auditoria limpa deixa de importar.

A revisão recorrente deve concentrar-se em:

  • principais com capacidade de DCSync e direitos de replicação fora do âmbito esperado dos DC;
  • direitos de escrita perigosos sobre utilizadores, grupos, OU, GPO e computadores sensíveis;
  • desvios em AdminSDHolder e outras alterações de ACL favoráveis à persistência;
  • caminhos de escalada relacionados com certificados quando AD CS está presente.

É por isso que Abuso de ACL e DCSync: caminhos silenciosos para Domain Admin não deve ser tratado como um simples ponto de relatório pontual.

3. Delegação Kerberos, Shadow Credentials e abuso de certificados

Algumas exposições em AD quase não fazem ruído até serem exploradas. Delegação Kerberos, msDS-KeyCredentialLink, mapeamentos de certificado e direitos sobre modelos de certificado são exemplos clássicos. Se só os revê durante uma avaliação anual, está na prática a aceitar muito tempo de exposição para a próxima má configuração.

Estes controlos merecem validação recorrente porque são sensíveis à mudança:

  • delegação não restrita, restrita e resource-based constrained delegation;
  • exposição a Shadow Credentials através de msDS-KeyCredentialLink;
  • weak certificate mapping ou modelos de certificado AD CS arriscados;
  • novas cadeias de abuso de certificados introduzidas por deriva na configuração de modelos ou da CA.

Existem análises específicas em Ataques de delegação Kerberos: de não restrita a RBCD, Shadow Credentials: abuso de msDS-KeyCredentialLink em Active Directory, Weak Certificate Mapping em AD CS: porque a vinculação forte continua importante e Ataques de modelos AD CS: de ESC1 a ESC8 até Domain Admin.

4. Postura dos controladores de domínio e cobertura de registo

Um fluxo recorrente também tem de voltar a verificar se o ambiente continua capaz de observar o próximo incidente. A Microsoft documenta WEF como um mecanismo para encaminhar eventos selecionados para um coletor e deixa claro que WEF é passivo: não cria os eventos por si. Se a geração de eventos, as categorias de auditoria, o tamanho dos logs ou o registo de PowerShell se afastarem da política definida, a visibilidade degrada-se mesmo que a auditoria anterior estivesse correta quando foi executada.

Isso significa que a revisão recorrente deve incluir:

  • cobertura da política de auditoria nos controladores de domínio;
  • tamanho e retenção do Security log;
  • cobertura de registo de PowerShell;
  • aplicação de LDAP signing e channel binding;
  • requisitos de SMB signing nos DC;
  • cobertura de WEF ou de outra recolha centralizada para os eventos de que realmente depende.

Esta é a ponte prática entre Monitoramento de segurança AD: eventos que realmente importam e um fluxo de auditoria que continua útil depois do primeiro relatório.

5. Higiene de palavras-passe de admin local e deriva em rollouts de postos e servidores

Alguns achados não são problemas "partidos para sempre". Voltam a aparecer porque a infraestrutura muda mais depressa do que o rollout do padrão esperado. Windows LAPS é um bom exemplo. A Microsoft documenta Windows LAPS como uma funcionalidade do Windows que gere e guarda automaticamente a palavra-passe de uma conta de administrador local. Mas a existência da funcionalidade não significa que todo o parque esteja coberto hoje.

A revisão recorrente deve portanto verificar:

  • se LAPS está realmente implantado com cobertura suficiente;
  • se novos sistemas entram no âmbito gerido;
  • se a exposição de palavras-passe locais privilegiadas continua demasiado ampla;
  • se sistemas não geridos estão a reintroduzir risco de movimento lateral do tipo pass-the-hash.

Esse é o modelo operacional por trás de Windows LAPS não implantado: porque as palavras-passe locais partilhadas continuam importantes.

Uma cadência prática que funciona melhor do que uma fotografia anual

Não existe uma frequência universal que sirva para todas as organizações. A cadência certa depende da velocidade de mudança, do modelo de administração e de saber se AD CS, múltiplas florestas ou identidade híbrida acrescentam complexidade. Na prática, um ritmo por níveis funciona melhor do que uma única revisão anual.

CadênciaObjetivoO que voltar a medir
SemanalDetetar cedo deriva de privilégios e mudanças de políticapertenças privilegiadas, contas privilegiadas recém-criadas, criação recente de objetos, alterações recentes de SIDHistory, alterações de políticas predefinidas, alterações de ACL de alto risco
MensalRevalidar a exposição estruturalprincipais com capacidade de DCSync, delegação, LDAP/SMB signing, cobertura de LAPS, contas obsoletas, higiene de contas de serviço, configuração de registo
TrimestralRever caminhos de ataque ao nível da arquiteturaexposição de AD CS, relações de confiança, AdminSDHolder, machine account quota, estrutura de OU e GPO, pressupostos de tiering e caminhos de administração
Após cada mudança maiorVerificar a qualidade da remediação e do rolloutfusões, trabalhos de PKI, redesenho de GPO, novas ferramentas administrativas, nova baseline de servidores, alterações de tiering, limpeza de funções privilegiadas

O objetivo não é criar mais reuniões. O objetivo é encurtar o tempo entre a mudança, a medição e a verificação.

Como transformar isto em monitorização contínua de postura com EtcSec

É aqui que o modelo se torna mais útil do que um entregável anual de consultoria.

O catálogo AD atualmente publicado pelo ETC Collector enumera 340 deteções em 14 categorias, com cobertura que inclui contas privilegiadas, Kerberos, permissões, GPO, relações de confiança, monitorização e conformidade, além de controlos ADCS e caminhos de ataque em Pro. Isto importa porque um fluxo recorrente só funciona se o mesmo conjunto de detetores puder ser executado novamente de forma consistente sem transformar cada revisão num novo projeto de consultoria.

Mais importante ainda: o modelo de implantação encaixa no fluxo:

  • o coletor audita AD em modo apenas leitura por LDAP/LDAPS e SMB para SYSVOL;
  • nenhuma alteração é feita ao diretório;
  • não é necessário implantar agentes nos controladores de domínio;
  • em modo daemon, o coletor funciona como um serviço persistente, consulta a plataforma SaaS a cada 30 segundos para receber comandos, executa auditorias localmente e envia os resultados de volta;
  • a API expõe o estado da última auditoria e suporta relançamentos síncronos ou assíncronos, exatamente o que um fluxo recorrente precisa.

Isto faz com que o produto se ajuste melhor a um modelo de postura contínua do que a um PDF anual. O ponto não é "deteção em tempo real" no sentido de SIEM. O ponto é que as mesmas famílias de controlo podem ser medidas de novo vezes sem conta com pouca fricção, e que a remediação pode ser validada relançando a auditoria em vez de esperar pelo próximo ciclo orçamental.

Os controlos da EtcSec que mais importam num fluxo recorrente

Um fluxo recorrente só é credível se corresponder a verificações concretas. Com base no catálogo atual de vulnerabilidades da ETC, os achados seguintes são especialmente adequados para uma revisão repetida de postura:

Área de revisãoAchados da EtcSec para reavaliar com frequênciaPorque envelhecem mal
Deriva de privilégiosPRIVILEGED_ACCOUNT_STALE, PRIVILEGED_GROUP_MEMBER_CHANGES, RECENT_PRIVILEGED_CREATION, ADMIN_NATIVE_RECENT_LOGON, GROUP_EVERYONE_IN_PRIVILEGED, GROUP_AUTHENTICATED_USERS_PRIVILEGEDpertenças e exceções acumulam-se em silêncio
ACL e caminhos de replicaçãoDCSYNC_CAPABLE, ACL_GENERICALL, ACL_WRITEDACL, ACL_WRITEOWNER, ADMIN_SD_HOLDER_MODIFIED, ADMINSDHOLDER_BACKDOORum único direito delegado pode sobreviver muito tempo à mudança que o criou
Kerberos e abuso de credenciaisUNCONSTRAINED_DELEGATION, CONSTRAINED_DELEGATION, RBCD_ABUSE, SHADOW_CREDENTIALS, KERBEROASTING_RISK, ASREP_ROASTING_RISKestas definições mudam durante rollouts de serviços, migrações e exceções administrativas
Postura LDAP e relayLDAP_SIGNING_DISABLED, LDAP_CHANNEL_BINDING_DISABLED, SMB_SIGNING_DISABLED, NTLM_RELAY_OPPORTUNITYtrabalhos de compatibilidade enfraquecem frequentemente estes controlos com o tempo
LAPS e higiene de endpointsLAPS_NOT_DEPLOYED, LAPS_DOMAIN_COVERAGE_LOW, LAPS_PASSWORD_READABLE, COMPUTER_NO_LAPSnovos sistemas e OU falham muitas vezes a baseline prevista
Preparação da monitorizaçãoAUDIT_POLICY_WEAK, POWERSHELL_LOGGING_DISABLED, AUDIT_LOGON_EVENTS_DISABLED, AUDIT_ACCOUNT_MGMT_DISABLED, AUDIT_POLICY_CHANGE_DISABLED, SECURITY_LOG_SIZE_SMALL, DC_AUDIT_POLICY_INCOMPLETEa qualidade do registo deriva à medida que as GPO evoluem e as equipas de servidores introduzem exceções
AD CS e caminhos de certificados (Pro)ESC1-ESC11, ADCS_WEAK_PERMISSIONS, ESC6_EDITF_ATTRIBUTESUBJECTALTNAME2, PATH_CERTIFICATE_ESCos serviços de certificados mudam durante trabalhos em modelos, PKI e emissão

É esta lista que transforma uma auditoria num fluxo. Em vez de pagar todos os anos para redescobrir as mesmas famílias de controlo, a equipa pode continuar a reavaliar primeiro as áreas com maior probabilidade de derivar.

Remediação e validação após cada ciclo de correção

Uma revisão recorrente só funciona se cada correção terminar com verificação. Caso contrário, o fluxo reduz-se a acompanhamento de tickets sem nova medição.

Após cada janela de mudança, a equipa deve executar uma sequência operacional simples:

  • relançar a mesma auditoria imediatamente depois da alteração;
  • confirmar que o finding-alvo desapareceu do relatório seguinte;
  • rever se o risco se deslocou para outra família de controlo, por exemplo de pertença privilegiada para uma ACL perigosa;
  • validar que a remediação não enfraqueceu a monitorização, por exemplo ao tocar em GPO, registo ou aplicação efetiva;
  • documentar exceções aceites e marcar a data da medição seguinte.

Após cada janela de mudança, a equipa também deve conseguir responder a perguntas básicas:

  • o finding visado desapareceu da auditoria seguinte;
  • o risco simplesmente se moveu para outro lado, por exemplo de um problema de pertença de grupo para um problema de ACL;
  • a correção enfraqueceu a monitorização, por exemplo alterando GPO que afetam registo ou aplicação efetiva de políticas;
  • uma exceção supostamente isolada criou um novo caminho através de delegação, direitos de replicação ou configuração de certificados;
  • a pontuação de segurança melhorou pela razão certa, isto é, menos achados relevantes e não apenas menos objetos analisados.

É aqui que um fluxo recorrente supera uma avaliação anual. Não é preciso esperar meses para validar se uma limpeza de privilégios, um rollout de LAPS, um projeto de LDAP signing ou um hardening de AD CS realmente se mantiveram.

Onde o modelo anual de consultoria continua a fazer sentido

Isto não significa que revisões externas pontuais deixem de ter valor. Continuam úteis para revisões profundas de arquitetura, resposta a incidentes, validação red team e marcos de governação. Mas não substituem a medição recorrente do próprio diretório.

Um modelo maduro costuma parecer-se com isto:

  • revisão externa profunda quando arquitetura, limites de confiança ou contexto de incidente o justificam;
  • medição recorrente de postura orientada pelo coletor para as famílias de controlo com maior deriva entre ciclos;
  • acompanhamento direcionado quando surgem novos findings ou quando a remediação bloqueia.

Isto é mais sólido do que comprar uma auditoria cara, arquivar o relatório e esperar que o diretório permaneça no mesmo estado enquanto administradores, projetos e alterações de emergência continuam a remodelá-lo.

Como a EtcSec distingue entre um relatório e um fluxo operativo

A EtcSec é mais útil quando é usada para transformar a revisão de segurança de AD num ritmo operacional:

  • executar repetidamente o mesmo conjunto de detetores;
  • tornar rapidamente visível a nova deriva de privilégios;
  • verificar mudanças de hardening após cada rollout;
  • manter ADCS, Kerberos, ACL e postura de monitorização no mesmo ciclo de revisão;
  • gerir o processo a partir do SaaS enquanto a recolha permanece dentro da rede do cliente.

Esta é a diferença importante. Uma auditoria recorrente de Active Directory não significa apenas "auditar com mais frequência". Significa passar de uma garantia ocasional para monitorização contínua de postura baseada em remediação repetida e de baixa fricção.

Referências primárias