Aninhamento Perigoso de Grupos AD: Caminhos para Domain Admin

O Que É o Aninhamento Perigoso de Grupos AD?

O aninhamento perigoso de grupos AD ocorre quando cadeias de associação a grupos do Active Directory criam privilégios efetivos que os revisores não pretendiam conceder. Um usuário, uma conta de serviço ou um grupo operacional pode não ser membro direto de Domain Admins, Enterprise Admins, Schema Admins ou de outro grupo sensível. Mas, se estiver aninhado por meio de um ou mais grupos intermediários, a conta ainda pode herdar o contexto de autorização resultante.

Os grupos de segurança do Active Directory são objetos de autorização. Podem ser colocados em listas de controle de acesso, receber direitos e ser adicionados a outros grupos. Esse aninhamento é útil para a administração, mas também dificulta a revisão de privilégios. A associação direta responde a apenas uma pergunta: quem está explicitamente no grupo? A associação efetiva responde à pergunta mais importante: quem recebe esse privilégio depois que todas as associações aninhadas são resolvidas?

O problema é comum em domínios de longa duração. Grupos sobrevivem a migrações, reorganizações, fusões, reconstruções de aplicações, mudanças emergenciais e trocas de propriedade. Um grupo criado para administração de servidores em 2016 ainda pode estar aninhado em um caminho protegido em 2026, mesmo que ninguém na equipe atual se lembre do motivo.

Como o Aninhamento de Grupos Cria Privilégios Ocultos

Quando o Grupo A é membro do Grupo B, os membros do Grupo A herdam as permissões efetivas do Grupo B. Se o Grupo B for membro de um grupo Tier 0, os membros do Grupo A agora têm um caminho Tier 0, mesmo que nenhuma dessas contas apareça como membro direto do grupo privilegiado final.

Esse é o risco central: caminhos aninhados escondem privilégio no meio da cadeia. Uma revisão direta de Domain Admins pode mostrar apenas um ou dois grupos. Mas cada um desses grupos pode conter outros grupos, contas de serviço, usuários obsoletos ou identidades operacionais compartilhadas.

A Microsoft documenta contas e grupos protegidos no Active Directory, incluindo grupos como Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators, Server Operators, Print Operators e outros. Esses grupos merecem revisão especial porque a associação pode conceder capacidade administrativa poderosa ou acionar o comportamento de conta protegida por meio do AdminSDHolder.

Associação Direta vs. Associação Efetiva

Uma revisão útil separa três visões:

Somente a terceira visão fornece um plano de remediação. Se um usuário de helpdesk resolve para Domain Admins por meio de cinco grupos, remover o usuário do grupo final não é a correção, porque o usuário não está diretamente ali. É preciso remover ou redesenhar a aresta de grupo que cria o caminho.

Onde os Caminhos Ocultos para Tier 0 Costumam se Esconder

Problemas de aninhamento perigoso costumam vir de padrões previsíveis:

• grupos de migração mantidos após uma consolidação de diretório
• grupos de administração de servidores aninhados para cima para solução de problemas temporária
• contas de backup, deployment ou monitoramento com acesso amplo concedido durante uma interrupção
• grupos operacionais compartilhados usados por várias equipes sem proprietário atual
• grupos de suporte de aplicações que herdaram direitos de grupos de administração legados
• grupos criados para uma região ou unidade de negócio e depois reutilizados em outro lugar
• grupos de projetos antigos que ainda contêm ex-funcionários ou contas de serviço

Uma revisão prática começa no topo do limite de privilégio e percorre para baixo. Comece pelos grupos Tier 0 e comprove quem consegue alcançá-los transitivamente. Revisar todos os grupos em ordem alfabética desperdiça tempo e geralmente perde o caminho que realmente importa.

A Cadeia de Ataque

Passo 1 - Encontrar o Caminho Aninhado

O atacante ou avaliador mapeia a associação recursiva a partir dos grupos privilegiados. O objetivo é encontrar uma conta mais fácil de comprometer do que um Domain Admin direto, mas que ainda se resolva em um caminho privilegiado.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Select-Object SamAccountName, ObjectClass, DistinguishedName

Passo 2 - Identificar o Elo Mais Fraco

O elo mais fraco geralmente não é um administrador nomeado. Pode ser uma conta de serviço com SPN, uma conta de usuário obsoleta, uma conta de operador compartilhada ou um grande grupo de suporte. O caminho aninhado transforma essa identidade mais fraca em um alvo de escalada relevante.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive |
  Where-Object {$_.objectClass -eq 'user'} |
  Get-ADUser -Properties Enabled, PasswordLastSet, ServicePrincipalName, LastLogonDate |
  Select-Object SamAccountName, Enabled, PasswordLastSet, LastLogonDate, ServicePrincipalName

Passo 3 - Usar a Autorização Existente

Se a identidade comprometida já herda os direitos necessários, o atacante não precisa de uma nova vulnerabilidade no Active Directory. O diretório já concede o acesso. Por isso o aninhamento perigoso é um problema de caminho de ataque, não apenas de higiene.

Detecção

Windows Event IDs

Monitore mudanças em grupos de segurança nos controladores de domínio. A Microsoft documenta as principais famílias de eventos em Audit Security Group Management, e a lista de eventos obrigatórios do Microsoft Defender for Identity também inclui as variantes de "membro adicionado" desses eventos (4728, 4732, 4756).

Não alerte apenas para inclusões diretas em Domain Admins. Alerte para mudanças em grupos um ou dois saltos abaixo do Tier 0, porque é ali que caminhos ocultos costumam ser criados.

Verificações Práticas de Revisão

Use verificações recorrentes em vez de limpeza pontual:

• exportar a associação recursiva dos grupos protegidos
• comparar associação direta com associação efetiva
• sinalizar contas de serviço, contas compartilhadas, usuários desativados e usuários obsoletos em caminhos recursivos
• identificar grupos sem proprietário, sem descrição ou sem data de revisão recente
• verificar se as mudanças de grupo foram aprovadas e esperadas
• monitorar se a mesma aresta de grupo é recriada após a limpeza

Remediação

O objetivo não é achatar todos os grupos. O objetivo é remover a herança oculta de Tier 0 e tornar os caminhos privilegiados restantes explícitos, com proprietário e revisáveis.

1. Auditar a Associação Recursiva a Partir do Tier 0

Comece pelos grupos que definem o limite de privilégio.

$tier0Groups = @('Domain Admins','Enterprise Admins','Schema Admins','Administrators','Backup Operators')
$results = foreach ($group in $tier0Groups) {
  Get-ADGroupMember -Identity $group -Recursive | ForEach-Object {
    [PSCustomObject]@{
      RootGroup = $group
      Account = $_.SamAccountName
      Type = $_.ObjectClass
      DistinguishedName = $_.DistinguishedName
    }
  }
}
$results | Export-Csv tier0-recursive-membership.csv -NoTypeInformation

2. Encontrar a Aresta de Grupo Que Cria o Caminho

Remover um usuário do grupo errado não corrige o modelo. Encontre a relação de grupo intermediária que concede o privilégio e decida se ela ainda é necessária. Se um grupo de administração de servidores está aninhado em um caminho de domain admin, redesenhe o modelo administrativo em vez de criar exceções caso a caso.

3. Reconstruir os Limites de Tier Explicitamente

O objetivo é impedir que grupos de tier inferior herdem direitos de tier superior por meio de aninhamento por conveniência. Um grupo de helpdesk não deveria se tornar privilegiado por ter sido aninhado em um grupo de admin de servidor que depois foi aninhado para cima.

4. Atribuir Propriedade e Cadência de Revisão

Todo grupo próximo ao Tier 0 deve ter um proprietário, um propósito e uma cadência de revisão. Se ninguém conseguir explicar por que um grupo está aninhado em um caminho privilegiado, remova-o ou coloque-o em quarentena até que a dependência seja comprovada. Documente exceções como exceções, não como arquitetura normal.

O Que Não Fazer

Não corrija o aninhamento perigoso excluindo grupos às cegas. Alguns grupos ainda podem sustentar administração de aplicações, jobs de backup ou fluxos operacionais. A sequência correta é identificar o caminho exato, confirmar a propriedade, remover arestas desnecessárias e testar o fluxo dependente. Evite também substituir o privilégio aninhado por associação direta de usuário no mesmo grupo protegido. Isso pode tornar o caminho mais visível, mas não reduz o privilégio. O objetivo é reduzir o privilégio efetivo e melhorar a responsabilização, não apenas encurtar a lista de grupos.

Validação Após a Limpeza

Depois da remediação, comprove que o caminho desapareceu:

• reexecutar as exportações de associação recursiva para grupos protegidos
• confirmar que nenhuma conta compartilhada, conta de serviço, conta desativada ou usuário obsoleto ainda se resolve em Tier 0
• revisar os eventos 4728, 4732, 4756, 4735, 4737 e 4755 durante e após a remediação
• confirmar que os grupos aninhados restantes têm proprietário e propósito documentado
• verificar se os alertas de monitoramento disparam para mudanças em grupos abaixo do limite privilegiado
• comparar os resultados do grafo antes e depois da limpeza para que o caminho removido fique claro

O alvo da validação é simples: o ambiente não deveria depender de herança de privilégio oculta que só uma consulta de grafo consegue explicar depois do fato.

Como o EtcSec Detecta Isso

O EtcSec mapeia o grafo efetivo de grupos em vez de depender apenas da associação direta. Isso torna o achado útil por dois motivos: mostra o caminho de privilégio completo e ajuda os revisores a identificar qual objeto na cadeia é mais fácil de um atacante comprometer.

Leituras Relacionadas

Revise o aninhamento perigoso de grupos AD junto com Caminhos de Ataque do Active Directory para Domain Admin, Abuso de ACL e DCSync: Os Caminhos Silenciosos para Domain Admin, Ataques de Confiança do Active Directory: Do Domínio Filho à Raiz da Floresta, Configurações Incorretas de GPO: Como a Diretiva de Grupo Se Torna um Vetor de Ataque e Contas Privilegiadas Obsoletas: Risco Oculto no Active Directory. O privilégio aninhado geralmente importa porque se conecta a outro caminho de ataque.

Referências Primárias

• Active Directory Security Groups
• Protected accounts and groups in Active Directory
• Audit Security Group Management
• 4732: A member was added to a security-enabled local group
• Configure Windows event auditing - Microsoft Defender for Identity