O privilégio que não aparece em auditoria nenhuma

Faça um teste mental. No seu Active Directory, quem consegue resetar a senha de um usuário?

Se sua resposta foi "os administradores", ela está incompleta. E o pedaço que falta é justamente o perigoso.

Rodei uma auditoria de ACL num ambiente enterprise recentemente. Não olhei grupos administrativos, olhei as permissões concedidas diretamente nos objetos do diretório. O que apareceu não estava em Domain Admins, não estava em Enterprise Admins, e não apareceria em nenhuma auditoria que olha só a associação de grupos.

Estava escondido onde quase ninguém procura: nas ACLs.

O que uma auditoria de grupos não vê

Quando alguém audita privilégio no AD, quase sempre olha os grupos: quem está em Domain Admins, quem está em Account Operators, quem está nos grupos de TI.

Isso é necessário, mas é só metade. Porque o AD permite delegar permissão diretamente num objeto, sem passar por grupo administrativo nenhum.

Alguém precisou, um dia, que a equipe de suporte resetasse senhas de um departamento. Em vez de estruturar isso direito, delegou o direito ali, na OU, na pressa. Funcionou. Resolveu o chamado. E ficou.

Anos depois, ninguém lembra que aquela permissão existe. Ela não aparece em Get-ADGroupMember. Não aparece no relatório de grupos privilegiados. Ela só aparece se você for ler a ACL de cada objeto, que é o que quase ninguém faz.

O que a auditoria encontrou

Anonimizei tudo, mas os padrões são exatamente estes:

Uma conta de service desk com GenericAll sobre uma OU. GenericAll é controle total. Criar, apagar, modificar, resetar senha, reescrever permissões. Uma conta de suporte, com poder que normalmente só um administrador de domínio teria, sobre todos os objetos de uma OU inteira.

Contas de suporte com ExtendedRight espalhado. ExtendedRight inclui o direito de resetar senha. Apareceu em várias OUs, em contas diferentes de suporte. Cada uma foi concedida um dia, para resolver algo pontual. Somadas, desenham uma superfície de ataque que ninguém projetou de propósito.

As contas de sincronização com a nuvem, escrevendo em massa. O conector que sincroniza o AD local com a nuvem usa contas de serviço próprias. Elas apareceram com direito de escrita sobre atributos em dezenas de objetos. Isso é esperado até certo ponto pois o conector precisa escrever. Mas essas contas são um alvo conhecido (comprometer uma delas dá acesso de escrita a boa parte do diretório). Elas raramente entram no escopo de uma auditoria de privilégio, e deveriam.

Permissões legadas do Exchange que ninguém revisou. Grupos criados pela instalação do Exchange apareceram com WriteDacl e DeleteTree sobre objetos. WriteDacl é especialmente perigoso. Quem tem esse direito pode reescrever as próprias permissões, ou seja, escalar sozinho, sem ajuda de ninguém. Isso é resquício de instalação que sobreviveu a anos sem revisão, e é um vetor clássico de escalonamento de privilégio em ambientes reais.

E um fantasma. Uma das entradas tinha GenericAll (controle total) concedido a um identificador que não resolve para nome nenhum. É um SID órfão. A conta ou o grupo que tinha aquela permissão foi deletado, mas a permissão ficou. Ninguém sabe o que era. Ninguém sabe se ainda pode ser reaproveitado. E ele tem controle total sobre um objeto do diretório.

Por que isso é pior do que parece

Nenhuma dessas contas está num grupo administrativo. Essa é a parte que assusta.

Um relatório de "usuários privilegiados" do tipo que a maioria das ferramentas gera não mostraria nenhuma delas. A auditoria diria que está tudo certo. E estaria olhando para o lugar errado.

O privilégio que mora na ACL é invisível para quem audita só grupos. Ele foi concedido de forma pontual, direto no objeto, muitas vezes anos atrás, e nunca mais foi olhado. É exatamente o tipo de permissão que um atacante procura, porque ele sabe que você não está olhando.

Como ver isso no seu ambiente

Começa lendo a ACL de uma OU:

(Get-Acl "AD:\OU=SuaOU,DC=seudominio,DC=com").Access

A saída vem crua e com os direitos em GUID, ilegível de primeira. ExtendedRight aparece como um identificador, não como "Reset Password". Para traduzir isso para nome legível e ver quem tem o quê de forma clara, é preciso cruzar com o schema do AD.

O comando abaixo faz o essencial: lista, para as OUs do domínio, quem tem direitos perigosos concedidos diretamente, ignorando os grupos que o próprio AD cria:

$sistema = 'SELF|SYSTEM|BUILTIN|CREATOR|Everyone|Authenticated|Domain Admins|Enterprise Admins|Domain Controllers'

Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor |
    ForEach-Object {
        $ou = $_.Name
        $_.nTSecurityDescriptor.Access |
            Where-Object { -not $_.IsInherited } |
            Where-Object { $_.IdentityReference.Value -notmatch $sistema } |
            Where-Object {
                $_.ActiveDirectoryRights -match 'GenericAll|WriteDacl|WriteOwner|ExtendedRight'
            } |
            ForEach-Object {
                [PSCustomObject]@{
                    Quem    = $_.IdentityReference.Value
                    Direito = $_.ActiveDirectoryRights
                    Onde    = $ou
                }
            }
    } | Sort-Object Quem

O que procurar na saída:

• GenericAll : controle total. Quem tem isso pode tudo naquele objeto.
• WriteDacl : pode reescrever as próprias permissões. Escala sozinho.
• WriteOwner : pode virar dono do objeto, e daí fazer o resto.
• ExtendedRight : inclui reset de senha, entre outros direitos sensíveis.
• Qualquer SID que não vira nome : permissão órfã, lixo de uma conta deletada.

O que fazer com o resultado

Não saia revogando. Uma permissão que parece sem sentido pode estar sustentando uma integração que ninguém documentou. Revogar às cegas pode quebrar a produção.

O primeiro passo não é limpar. É entender. Para cada direito perigoso concedido fora dos grupos administrativos, responder três perguntas. Quem concedeu? Por quê? Ainda é necessário?

Na maioria dos casos, a resposta da terceira pergunta é "não". Foi concedido para um problema que já foi resolvido, por alguém que já saiu, e nunca foi removido. Mas você só descobre isso investigando cada um e não apagando todos.

Isso é trabalho de engenharia de identidade, não de faxina. E é a diferença entre operar um Active Directory e ser responsável por ele.

Quando foi a última vez que você leu a ACL de uma das suas OUs?

Se a resposta honesta for "nunca", você não está sozinho. E é exatamente por isso que o privilégio invisível é tão comum e tão perigoso.