ACL Fraca GPO, Tier 0 OU, Active Directory: O Pivô Que Desfaz o Modelo de Tiers Que Você Acabou de Construir

ACL Fraca GPO, Tier 0 OU, Active Directory: O Que Esta Configuração Incorreta Realmente Significa

Uma ACL fraca em uma GPO vinculada à OU Tier 0 é o controle que a maioria das equipes esquece de verificar depois que o modelo de tiers já está em produção. Criar uma unidade organizacional dedicada ao Tier 0 e bloquear a herança de políticas nela é um passo bem conhecido — são os R58 e R59 da ANSSI-PA-099, o guia da agência francesa de cibersegurança sobre a administração segura do Active Directory (veja também nosso resumo das recomendações da ANSSI para o conjunto mais amplo). O R58 exige uma OU dedicada que reúna os objetos de Tier 0 — com uma ressalva explícita: as contas de computador dos controladores de domínio e os usuários e grupos internos permanecem em suas OUs padrão; o R59 exige que essa OU "restrinja as políticas de segurança aplicáveis à unidade organizacional Tier 0", bloqueando a herança e garantindo que qualquer GPO vinculada ou aplicada a ela seja dedicada a recursos de Tier 0 e editável apenas por administradores de Tier 0.

Essa segunda metade do R59 — "editável apenas por administradores de Tier 0" — é a parte que silenciosamente sai de escopo assim que a estrutura de OUs é construída. Bloquear a herança fecha um plano de controle: quais políticas fluem de cima para baixo sobre a OU. Isso não diz nada sobre um segundo plano de controle, independente: quem pode escrever nos objetos de GPO já vinculados ali. Uma GPO é seu próprio objeto do Active Directory, com sua própria lista de controle de acesso. Se essa ACL conceder direitos de edição a alguém abaixo do Tier 0 — um grupo de helpdesk, uma delegação de um projeto encerrado que nunca foi limpa, um grupo de segurança aninhado um nível mais fundo do que o pretendido —, esse principal de baixa confiança pode reescrever o conteúdo da política, e o Active Directory aplicará suas alterações a todo computador e conta de Tier 0 alcançados pela GPO, com ou sem o bloqueio de herança.

Esse é um problema mais restrito e específico do que a questão geral de como um modelo de tiers é construído em primeiro lugar. Uma equipe pode implementar corretamente a hierarquia de OUs do R58, passar em toda revisão da própria estrutura de OUs, e ainda assim entregar uma OU Tier 0 com uma única GPO fracamente permissionada vinculada a ela — porque a ACL própria dessa GPO é um objeto separado que ninguém pensou em reverificar depois que o modelo de tiers foi declarado concluído.

Como Funciona

Um Group Policy Object é, na verdade, dois artefatos mantidos em sincronia: o Group Policy Container (GPC), um objeto do Active Directory sob CN=Policies,CN=System,DC=<domain> que carrega o próprio descritor de segurança da GPO, e o Group Policy Template (GPT), a pasta correspondente no compartilhamento SYSVOL que contém os arquivos de configuração propriamente ditos. O vínculo entre uma GPO e uma OU é uma terceira peça, separada: o atributo gPLink da OU, que apenas referencia a GPO pelo GUID.

A própria documentação da Microsoft sobre o processamento de Group Policy confirma a mecânica por trás da exigência de "bloquear herança" do R59: cada OU tem um atributo GPOptions que pode bloquear políticas de containers de nível superior, mas "embora a herança bloqueada impeça a aplicação da maioria das configurações a uma OU, ela não afeta configurações aplicadas por meio de GPOs com a opção forçada" — forçada é uma propriedade do vínculo e tem precedência sobre o bloqueio de herança, uma propriedade do container. É exatamente por isso que o R59 também exige verificar se nenhuma GPO aplicada com status forçado a partir de uma OU pai é editável por alguém fora do Tier 0: o bloqueio de herança sozinho não impede o problema de permissões de uma GPO forçada, apenas o seu problema de prioridade normal.

Nada disso toca a ACL própria do objeto GPC. Por padrão, apenas Domain Admins, Enterprise Admins e SYSTEM têm direitos de edição sobre uma GPO — a referência do Get-GPPermission da Microsoft mostra exatamente esse conjunto padrão em sua própria saída de exemplo, e nomeia esse nível de permissão como GpoEditDeleteModifySecurity. ACLs fracas surgem por drift, não por uma única decisão ruim: uma GPO é criada por um admin de um tier inferior via GPMC e depois vinculada à OU Tier 0 sem que ninguém reaudite quem ainda detém direitos de edição sobre ela; ou uma delegação de helpdesk restrita a uma GPO específica para uma tarefa específica nunca é revogada; ou um grupo de segurança destinado ao Tier 1 acaba recebendo "Editar configurações" por acidente durante uma limpeza de permissões.

A Cadeia de Ataque

Passo 1 — Encontrar o Elo Fraco

Um atacante (ou um auditor) enumera a ACL de cada GPO em busca de concessões de GenericAll, GenericWrite, WriteDacl ou WriteOwner a um principal abaixo do Tier 0, e então cruza o resultado com o gPLink de cada GPO em uma OU Tier 0 — diretamente, ou via uma GPO forçada em uma OU pai. Get-GPPermission -Guid <GUID da GPO> -All traz essa informação uma GPO por vez — -Guid (ou -Name) é obrigatório, então a varredura precisa iterar em vez de rodar uma única vez: qualquer trustee cujo Permission retorne como GpoEditDeleteModifySecurity — ou uma ACE personalizada que o cmdlet não consiga mapear para um nível nomeado — e que não seja um principal de Tier 0 reconhecido é um achado.

Passo 2 — Armar a Política

A documentação do BloodHound da SpecterOps sobre a aresta de abuso GenericWrite descreve a técnica padrão: abrir a GPO no Group Policy Management Editor e adicionar "uma política maliciosa que permita item-level targeting, como uma nova tarefa agendada imediata" — um recurso do Group Policy Preferences que executa um comando arbitrário como NT AUTHORITY\SYSTEM na próxima vez que a política for aplicada. As ferramentas conhecidas para isso — SharpGPOAbuse no Windows, pyGPOAbuse no Linux — automatizam a escrita desse XML de tarefa agendada na GPO. A mesma documentação aponta um limite importante: GenericWrite restrito a "somente este objeto", sem nenhuma outra ACE, não é suficiente por si só — as configurações do GPT residem no SYSVOL, então o atacante também precisa de acesso de escrita à pasta SYSVOL dessa GPO para de fato alterar o que é implantado. Na prática, os dois caminhos de acesso são concedidos juntos com frequência suficiente para que isso seja um caminho de ataque real, não apenas teórico — mas é também o detalhe que separa uma verdadeira GPO com ACL fraca de um falso positivo.

Passo 3 — Aguardar a Janela de Atualização

Nenhum acesso adicional é necessário após a edição. Segundo a documentação da Microsoft citada acima, computadores e servidores membros do domínio reverificam alterações de GPO a cada 90 minutos, com um deslocamento aleatório de até 30 minutos, enquanto os controladores de domínio verificam a cada cinco minutos. O próprio conteúdo do SYSVOL replica entre controladores de domínio em um cronograma de DFSR de até 15 minutos dentro de um site. Assim que a alteração chega, todo computador de Tier 0 alcançado pela GPO — no caso de uma GPO vinculada à OU Tier 0, isso significa as estações de trabalho de administradores de Tier 0, as contas de administração e as contas de serviço ali mantidas — executa a tarefa do atacante como SYSTEM em seu próprio cronograma, sem necessidade de interação. Os controladores de domínio são um salto separado: o R58 mantém suas contas de computador na OU padrão OU=Domain Controllers, então uma GPO fraca só alcança um DC se também estiver vinculada a essa OU ou aplicada a um container pai com status forçado.

Detecção

O Event ID 5136 ("Um objeto do serviço de diretório foi modificado") é disparado na subcategoria Auditar Alterações do Serviço de Diretório sempre que um objeto com uma entrada SACL apropriada para auditoria de "Gravação" é alterado — ele não aparecerá se essa SACL não estiver configurada previamente nos objetos container de GPO (ou herdada de CN=Policies,CN=System). O campo AttributeLDAPDisplayName do evento é o que permite a um SIEM diferenciar uma edição de política de rotina de uma alteração no descritor de segurança; filtrar por ObjectClass=groupPolicyContainer isola a atividade de GPO de todas as outras alterações do serviço de diretório que esse evento também cobre.

# Varre todas as GPOs em busca de trustees com direitos de edição/controle total e,
# em seguida, cruza com as GPOs vinculadas a uma OU Tier 0
Get-GPO -All | ForEach-Object {
    $gpo = $_   # guarda a GPO: dentro do pipeline aninhado, $_ é uma GPPermission
    Get-GPPermission -Guid $gpo.Id -All |
        Where-Object { $_.Permission -match 'GpoEdit|GpoCustom' } |
        Select-Object @{N='GPO';E={$gpo.DisplayName}}, Trustee, TrusteeType, Permission
}

Remediation

1. Inventariar a exposição. Liste toda GPO vinculada à OU Tier 0, além de qualquer GPO aplicada com status forçado a partir de uma OU pai — segundo a ANSSI-PA-099 R59, ambas contam. (Get-GPInheritance -Target "<DN da OU Tier0>").GpoLinks retorna o conjunto vinculado diretamente; OUs pai precisam ser verificadas manualmente quanto a vínculos forçados.
2. Revisar a aba Delegação. Para cada GPO, abra-a na GPMC e verifique a aba Delegação, depois clique em Avançado para ver a ACL bruta em vez dos níveis de permissão resumidos — a orientação de delegação da Microsoft documenta esse como o caminho suportado para adicionar, remover ou inspecionar concessões de Editar configurações, excluir e modificar segurança em uma GPO.
3. Remover qualquer trustee fora do Tier 0 que detenha o nível de permissão Editar, Editar/Excluir/Modificar Segurança ou um nível personalizado. Confirme que a pasta SYSVOL correspondente a essa GPO não concede separadamente acesso de escrita ao mesmo principal — a ACL do AD e a ACL do SYSVOL são duas verificações diferentes em dois objetos diferentes.
4. Reverificar a outra metade do R59. Confirme que a herança continua bloqueada na OU Tier 0, que a Default Domain Policy está vinculada ali com a prioridade mais baixa, como o R59 especifica, e que nenhuma GPO forçada a partir de uma OU pai ainda carrega uma ACL fraca.
5. Repetir a varredura da seção Detecção em uma programação, não apenas uma vez — permissões de GPO sofrem drift da mesma forma que memberships de grupos, por meio de delegações pontuais que ninguém se lembra de revogar. Essa verificação pertence à mesma rotina de uma auditoria de segurança do Active Directory mais ampla, não como uma limpeza única.

Como a EtcSec Detecta Isso

O catálogo de compliance da EtcSec rastreia exatamente esse modo de falha como ANSSI_R59_TIER0_OU_POLICIES: ele enumera todo vínculo de GPO habilitado, sinaliza os que apontam para uma GPO cuja própria ACL concede acesso de escrita a um principal não administrador, e reporta um achado para cada vínculo que recai sobre uma OU Tier 0. Ele é combinado com GPO_DANGEROUS_PERMISSIONS para o caso geral de ACLs fracas de GPO em qualquer ponto do domínio, PATH_GPO_TO_DA para a visão de caminho de ataque dessa mesma exposição, e ANSSI_R15_TIER_MODEL_VIOLATION para a questão mais ampla de se o próprio modelo de tiers permanece íntegro.