A consulta desvio acesso privilegiado active directory descreve uma lacuna concreta: a diferença entre o modelo de privilégios que a organização acredita ter e os direitos efetivos que realmente existem no diretório hoje. O desvio pode começar com uma associação temporária a um grupo, uma delegação de helpdesk para resolver uma operação, uma conta de serviço adicionada durante um incidente ou uma ACL que ninguém revisita depois do fim de um projeto. Com o tempo, essas pequenas mudanças podem recriar caminhos de ataque que uma auditoria anterior já havia removido.
Este artigo é limitado ao Active Directory on-premises. Ele não trata Microsoft Entra Privileged Identity Management como controle substituto e não reduz o desvio apenas a contas administrativas obsoletas. No AD, o acesso privilegiado pode reaparecer por grupos aninhados, ACLs de diretório, direitos de replicação, mudanças no AdminSDHolder, reutilização da conta Administrator integrada, contas de serviço e exceções emergenciais. Detectar isso exige correlação entre a baseline esperada, os direitos efetivos atuais, mudanças recentes e telemetria de segurança.
Desvio acesso privilegiado active directory: o que cobre
O desvio de acesso privilegiado é o acúmulo de direitos administrativos efetivos que já não correspondem ao modelo previsto para o domínio. Uma revisão de acesso limpa pode concluir que apenas grupos administrativos nomeados controlam ativos Tier 0. Algumas semanas depois, um operador pode adicionar um membro temporário a Domain Admins, aninhar um grupo de suporte em um grupo privilegiado, delegar WriteDACL em uma OU ou conceder direitos de replicação a uma conta de migração. Se a mudança não for removida e remensurada, o resultado da revisão fica obsoleto.
O ponto importante é que o privilégio no Active Directory não fica armazenado em um único lugar. A associação a grupos é a camada visível, mas é apenas parte do plano de controle. Um principal pode se tornar perigoso porque é membro direto de um grupo privilegiado, porque chega a esse grupo por aninhamento, porque pode modificar a associação do grupo, porque pode reescrever o security descriptor de um objeto, porque tem direitos de replicação compatíveis com DCSync ou porque pode influenciar contas protegidas por AdminSDHolder. Por isso, um artigo sobre contas obsoletas e superprivilegiadas é útil, mas não suficiente para cobrir todo o desvio de acesso privilegiado.
Uma revisão de desvio deve responder a uma pergunta precisa: quem consegue afetar identidades privilegiadas, grupos privilegiados, controladores de domínio, permissões na raiz do domínio, Group Policy, serviços de certificados e outras superfícies de controle Tier 0 agora? A resposta deve incluir administradores diretos, administradores indiretos, operadores delegados, contas de serviço e principals com caminhos ACL perigosos.
Por que revisões anuais não veem o desvio de AD
Revisões anuais ou trimestrais são fotografias pontuais. Elas são úteis para governança, mas fracas para detectar um diretório que muda toda semana. Mudanças de associação a grupos no Active Directory são auditáveis, e a Microsoft documenta eventos de gerenciamento de grupos de segurança, incluindo eventos de membros adicionados e removidos em grupos globais, locais e universais. Mudanças em objetos de diretório também podem ser auditadas por eventos de alterações do serviço de diretório, e o acesso a objetos pode expor operações sensíveis quando auditoria e SACLs estão configuradas. Esses logs mostram que AD não é estático.
O problema prático é que muitas revisões ainda dependem de exportações. Uma planilha de Domain Admins do mês passado não mostra que um grupo aninhado foi adicionado ontem. Uma lista de usuários privilegiados não mostra que um grupo de helpdesk pode modificar a associação de um grupo admin. Uma revisão manual de contas desabilitadas não mostra que uma conta de serviço ainda mantém DS-Replication-Get-Changes e DS-Replication-Get-Changes-All no contexto de nomenclatura do domínio.
É por isso que auditorias recorrentes de Active Directory são importantes. Se os mesmos controles são executados uma vez por ano, a organização sabe o que estava errado na data da auditoria. Se os controles são reexecutados após mudanças e remediações, a organização consegue ver se o modelo privilegiado continua limpo ou volta a desviar.
Como o desvio de acesso privilegiado acontece
Associação temporária vira permanente
Resposta a incidentes, migrações, configuração de backup e suporte urgente a aplicações às vezes exigem direitos elevados. O risco não é a exceção em si; o risco é uma exceção sem dono, sem expiração e sem revalidação. O Active Directory continuará honrando a associação até que alguém a remova.
Aninhamento de grupos oculta o privilégio efetivo
Um grupo pode parecer inofensivo isoladamente e se tornar privilegiado quando é aninhado em Account Operators, Backup Operators, Domain Admins, Enterprise Admins ou outro grupo sensível. O acesso aninhado também dificulta revisões porque os membros efetivos não aparecem na primeira tela do grupo. Um grupo privilegiado deve ser revisado por associação efetiva, não apenas por membros diretos.
Desvio de ACL cria caminhos de controle
A autorização do Active Directory depende fortemente de discretionary access control lists. GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership e direitos semelhantes podem transformar um principal não administrador em administrador prático sobre objetos específicos. Em uma revisão de caminhos de ataque, a pergunta não é apenas quem está em Domain Admins. É quem pode alterar um principal, grupo, GPO, computador, OU ou ACL que leva ao Tier 0. A mesma lógica se aplica ao revisar abuso de ACL e caminhos DCSync.
Direitos de replicação ampliam a exposição de credenciais
A MITRE documenta DCSync em OS Credential Dumping porque um adversário com direitos suficientes de replicação de diretório pode imitar o comportamento de replicação de um controlador de domínio para obter material de credenciais. Defensores devem revisar principals com DS-Replication-Get-Changes e DS-Replication-Get-Changes-All, além de qualquer direito de replicação específico do ambiente que se aplique a segredos protegidos.
Mudanças em AdminSDHolder são sensíveis para persistência
As Microsoft Open Specifications descrevem AdminSDHolder como o objeto usado pelo sistema para gerenciar security descriptors de objetos administrativos protegidos. Se o security descriptor de AdminSDHolder for alterado, o impacto pode se propagar para contas e grupos protegidos por meio do mecanismo SDProp. Isso torna AdminSDHolder um objeto sensível para persistência, não um contêiner administrativo comum.
Contas de serviço e conta integrada adicionam risco duradouro
Uma conta de serviço em um grupo privilegiado pode ser mais difícil de rotacionar, mais difícil de vincular a um dono humano e mais fácil de esquecer. A conta Administrator integrada com RID 500 não deve virar a identidade administrativa de uso diário. Se ela foi usada recentemente, trate isso como uma exceção que precisa de explicação, não como prova isolada de comprometimento.
Caminhos de ataque criados pelo desvio de privilégios
O desvio de privilégios importa porque cria caminhos, não apenas listas de acesso desorganizadas. Uma conta admin extra é um alvo de credenciais. Um grupo de suporte aninhado pode virar uma rota oculta para Domain Admins. Uma permissão WriteDACL pode permitir que um principal conceda direitos mais fortes a si mesmo. Uma permissão WriteOwner pode permitir que um principal assuma ownership e depois altere a ACL. Direitos AddMember em um grupo privilegiado podem bastar para adicionar uma conta controlada a esse grupo.
O desvio compatível com DCSync é especialmente sensível. Se um principal que não é controlador de domínio tem direitos de replicação que permitem comportamento DCSync, resetar senhas de usuários individuais não basta. A organização deve remover os direitos de replicação, investigar se material de credenciais foi exposto e rotacionar segredos afetados conforme o escopo de resposta a incidentes.
Delegação e infraestrutura de identidade podem ampliar o efeito. Uma conta de computador privilegiada, uma conta de serviço sobredelgada ou um caminho de delegação Kerberos mal gerido pode conectar desvio de privilégios a movimento lateral. Por isso, a análise de desvio deve ser correlacionada com riscos de delegação Kerberos, gerenciamento de senhas de administrador local como Windows LAPS e caminhos de ataque AD CS quando serviços de certificados estão no escopo.
| Superfície de desvio | Pergunta prática | Evidência de validação |
|---|---|---|
| Grupos privilegiados | Quem é membro direto ou aninhado efetivo? | Dono aprovado, ticket, expiração e associação efetiva atual |
| ACLs de diretório | Quem pode modificar objetos privilegiados ou seus security descriptors? | Diff de ACL, revisão do trustee, fonte de herança e dono de negócio |
| Direitos de replicação | Quem pode executar operações de replicação do domínio? | Apenas DCs esperados e principals de replicação aprovados |
| AdminSDHolder | Quem pode influenciar objetos administrativos protegidos? | Security descriptor esperado e nenhuma ACE não autorizada |
Detecção
Nenhum evento Windows individual prova desvio de acesso privilegiado. A detecção deve combinar uma baseline de acesso privilegiado esperado, o estado atual do diretório, análise de ACL e telemetria de mudanças recentes.
Inventariar primeiro o privilégio efetivo
Comece com um inventário efetivo de acesso privilegiado. Enumere associações diretas e aninhadas de grupos privilegiados. Inclua grupos privilegiados integrados, grupos administrativos do domínio, grupos que administram controladores de domínio, grupos de operações de backup ou servidores capazes de afetar ativos Tier 0 e qualquer grupo admin específico da organização. Compare o resultado com uma baseline aprovada com donos nomeados.
Revisar permissões fora da associação a grupos
Depois, inspecione permissões, não apenas associações. Revise ACLs na raiz do domínio, AdminSDHolder, controladores de domínio, grupos privilegiados, usuários privilegiados, OUs sensíveis, GPOs e contas de serviço de alto impacto. Preste atenção a direitos que permitem a um principal modificar associações ou security descriptors, incluindo GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership, Write Property e Control Access. Para replicação, revise DS-Replication-Get-Changes e DS-Replication-Get-Changes-All no contexto de nomenclatura do domínio.
Correlacionar eventos sem exagerar
A Microsoft documenta a categoria Audit Security Group Management e os eventos individuais usados para adições e remoções de membros. Os eventos 4728 e 4729 cobrem mudanças de membros em grupos globais de segurança, 4732 e 4733 cobrem grupos locais de segurança, e 4756 e 4757 cobrem grupos universais de segurança. Esses eventos são úteis quando o grupo privilegiado ou aninhado está no escopo.
Para mudanças de diretório, o evento 5136 registra modificações em objetos do serviço de diretório quando a auditoria correta está habilitada. Ele pode ajudar a identificar atributos alterados, como associação de grupo ou security descriptors, dependendo do que está auditado. O evento 4662 pode ajudar com acesso auditado a objetos e operações sensíveis de diretório, incluindo contextos Write Property, Control Access, WRITE_DAC e WRITE_OWNER quando SACLs estão configuradas. Trate esses eventos como evidência de correlação, não como vereditos isolados.
Por fim, conecte telemetria à intenção. Uma mudança em grupo privilegiado realizada por uma solicitação de acesso documentada pode ser esperada. A mesma mudança fora da janela de manutenção, feita por um operador incomum ou seguida por nova atividade de autenticação em controladores de domínio merece investigação. Para um mapeamento mais amplo, use um guia de monitoramento como eventos importantes de segurança AD para manter explícitos nomes de eventos, escopos e limitações.
Remediation e remediação operacional
A remediação deve remover o caminho e corrigir o processo que permitiu seu retorno.
Remover caminhos de grupos e documentar exceções
Para desvio de associação a grupos, remova membros diretos não aprovados e desfaça aninhamentos perigosos. Faça isso contra a associação efetiva, não apenas a associação direta. Se um grupo aninhado continuar necessário, documente dono, finalidade, caminho de aprovação e cadência de revisão. Evite deixar principals amplos como Authenticated Users ou grupos operacionais grandes demais dentro de grupos privilegiados.
Remover ACLs perigosas com cuidado
Para desvio de ACL, não apague permissões às cegas. Primeiro identifique objeto, trustee, direito, fonte de herança e dono de negócio. Depois remova direitos que criam controle administrativo sem finalidade documentada. Priorize GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership, direitos Write Property excessivos e direitos Control Access em objetos Tier 0. Depois da remoção, verifique se a delegação operacional ainda funciona para tarefas legítimas.
Revogar caminhos de replicação e persistência
Para principals compatíveis com DCSync, remova direitos de replicação de qualquer conta ou grupo que não esteja explicitamente aprovado para esse papel. Controladores de domínio precisam de replicação. Alguns cenários de identidade, migração ou backup podem exigir direitos cuidadosamente delimitados, mas essas exceções devem ser raras, ter dono, ser monitoradas e revisadas. Se existia capacidade DCSync suspeita, trate a limpeza como questão de exposição de credenciais, não apenas como limpeza de ACL.
Para desvio em AdminSDHolder, compare o security descriptor com a baseline esperada e investigue como ele mudou. Como AdminSDHolder afeta objetos administrativos protegidos, trate permissões inesperadas como sensíveis para persistência. Remova entradas não autorizadas e depois valide permissões de contas protegidas após SDProp ter tempo de reaplicar o descriptor previsto.
Reduzir exposição permanente de identidades privilegiadas
Para identidades privilegiadas, reduza acesso permanente. Separe contas de usuário diárias de contas administrativas. Revise contas de serviço privilegiadas e remova-as de grupos admin quando possível. Reserve a conta Administrator RID 500 para cenários break-glass ou emergenciais e investigue uso rotineiro recente. Considere o grupo Protected Users para contas humanas privilegiadas adequadas, mas teste compatibilidade primeiro porque a Microsoft documenta mudanças e restrições de comportamento de autenticação para membros.
Para desvio de processo, exija expiração e ownership para exceções. Um AD limpo após remediação voltará a desviar se o acesso temporário não tiver mecanismo de retirada. O controle deve responder quem aprovou o privilégio, por que ele existe, quando expira e qual evidência prova que foi removido.
Validação após a limpeza
A validação é onde muitos esforços de remediação falham. Remover um membro visível de Domain Admins não basta se um grupo aninhado, ACL ou direito de replicação permanece.
Recalcular associação efetiva
Depois da limpeza, execute novamente o inventário de associação efetiva. Confirme que grupos privilegiados têm apenas membros diretos e indiretos aprovados. Confirme que nenhum principal amplo está presente em grupo privilegiado. Confirme que contas privilegiadas criadas recentemente e mudanças recentes em grupos privilegiados correspondem a tickets ou registros de incidente aprovados.
Verificar novamente ACL e caminhos de replicação
Depois, refaça a revisão de ACL. Confirme que GenericAll, WriteDACL, WriteOwner, AddMember, Self-Membership e direitos de replicação removidos não reapareceram por herança, aninhamento de grupos ou processo de template. Confirme que AdminSDHolder não contém mais entradas inesperadas e que objetos protegidos refletem o security descriptor previsto.
Validar telemetria após remediação
Por fim, valide a telemetria. Procure novas mudanças de associação a grupos após a limpeza. Revise modificações de objetos de diretório em objetos sensíveis. Confirme que qualquer exceção permitida tem dono e data de revisão. O objetivo não é provar que nenhuma mudança futura possa acontecer. O objetivo é provar que os direitos efetivos atuais correspondem à baseline e que mudanças futuras serão visíveis.
Se você está criando um programa de auditoria mais amplo, alinhe esta validação com como auditar a segurança do Active Directory para medir o desvio privilegiado junto com autenticação, delegação, AD CS, GPO, senhas e controles de monitoramento.
Como a EtcSec detecta desvio de acesso privilegiado
A EtcSec identifica e remede condições de desvio de acesso privilegiado na postura AD atual. Os controles relevantes do catálogo cobrem contas privilegiadas, grupos, ACLs, direitos de replicação e AdminSDHolder, em vez de tratar o desvio como um único sintoma.
Para desvio de contas e uso, a EtcSec verifica condições como PRIVILEGED_ACCOUNT_STALE, ADMIN_NATIVE_RECENT_LOGON, EXCESSIVE_PRIVILEGED_ACCOUNTS e RECENT_PRIVILEGED_CREATION. Limiares como 90 dias para contas privilegiadas inativas, 30 dias para uso recente da conta Administrator integrada, 10 dias para contas privilegiadas criadas recentemente ou 7 dias para mudanças recentes em grupos privilegiados são limiares de política do catálogo. Eles não devem ser descritos como padrões da Microsoft.
Para desvio de grupos, a EtcSec verifica GROUP_EVERYONE_IN_PRIVILEGED, GROUP_AUTHENTICATED_USERS_PRIVILEGED, DANGEROUS_GROUP_NESTING e PRIVILEGED_GROUP_MEMBER_CHANGES. Esses findings ajudam a diferenciar uma lista de membros diretos aparentemente limpa de um caminho de privilégio efetivo criado por principals amplos ou grupos aninhados.
Para desvio de ACL e replicação, a EtcSec verifica DCSYNC_CAPABLE, ACL_GENERICALL, ACL_WRITEDACL, ACL_WRITEOWNER, ACL_SELF_MEMBERSHIP, ACL_ADD_MEMBER, ADMIN_SD_HOLDER_MODIFIED e ADMINSDHOLDER_BACKDOOR. Esses findings mapeiam as superfícies de controle que defensores precisam remedir após a limpeza: direitos de replicação, direitos de modificação de grupos, controle de security descriptor e persistência em admins protegidos.
A EtcSec não substitui investigação SIEM nem resposta a incidentes. Seu papel neste workflow é medição de postura: identificar a condição arriscada, explicar por que ela importa, acompanhar a remediação e medir se a condição retorna após a próxima mudança no diretório.
Controles relacionados
O desvio de acesso privilegiado é mais fácil de controlar quando tratado como problema recorrente de postura. Uma revisão de acesso pontual pode remover contas admin óbvias; um workflow recorrente pode detectar quando os mesmos direitos voltam.
Use higiene de contas privilegiadas para reduzir o número de identidades que podem se tornar alvos de credenciais de alto valor. Use revisão de ACL e DCSync para encontrar caminhos que não aparecem em relatórios de associação a grupos. Use eventos de monitoramento para validar quando mudanças aconteceram e quem as realizou. Use controles de senhas de administrador local como Windows LAPS para reduzir o impacto de credenciais admin locais reutilizadas enquanto você trabalha nos caminhos de privilégio do domínio.
O objetivo operacional é simples: cada caminho privilegiado deve ser intencional, ter dono, ser mínimo e ser revalidado. Todo o resto é desvio.
Referências primárias
- Microsoft Learn: Audit Security Group Management
- Microsoft Learn: Event 4728 - A member was added to a security-enabled global group
- Microsoft Learn: Event 4729 - A member was removed from a security-enabled global group
- Microsoft Learn: Event 4732 - A member was added to a security-enabled local group
- Microsoft Learn: Event 4733 - A member was removed from a security-enabled local group
- Microsoft Learn: Event 4756 - A member was added to a security-enabled universal group
- Microsoft Learn: Event 4757 - A member was removed from a security-enabled universal group
- Microsoft Learn: Event 5136 - A directory service object was modified
- Microsoft Learn: Event 4662 - An operation was performed on an object
- Microsoft Open Specifications: AdminSDHolder
- Microsoft Learn: Protected Users security group
- MITRE ATT&CK: Account Manipulation T1098
- MITRE ATT&CK: DCSync T1003.006
- Catálogo local EtcSec: Active Directory vulnerability catalogue - docs/vulnerabilities/active-directory/AD_VULNERABILITY_CATALOG.md
