Contas Privilegiadas Active Directory: Protected Users, Delegação e Lacunas em Contas de Serviço

O Que É a Proteção para Contas Privilegiadas do Active Directory (Protected Users e Delegação)

Domain Admins, Enterprise Admins e outras contas Tier 0 são as contas que um atacante precisa para comprometer totalmente um domínio. Para contas privilegiadas do Active Directory, três controles nativos e independentes fazem a maior parte do trabalho real de proteção: a associação ao grupo de segurança Protected Users, a flag de delegação "esta conta é confidencial e não pode ser delegada" e a regra básica de higiene de que contas de serviço não pertencem a grupos privilegiados. Além disso, o atributo SID History — destinado a migrações de domínio — pode conceder silenciosamente acesso privilegiado se nunca for auditado.

Nada disso é exótico. São recursos nativos e padrão do AD. A lacuna abordada neste artigo não é um patch ausente nem um zero-day — é simplesmente esses controles não estarem ativados para as contas que precisam deles, e é por isso que ela continua aparecendo como uma das principais ofensoras em avaliações de segurança do Active Directory. Cada lacuna abaixo é explorável de forma independente, e nenhuma exige ferramentas residentes em memória ou injeção de processo: são configurações incorretas em nível de atributo, visíveis a qualquer pessoa que consulte o diretório da maneira correta.

Como Funciona

Protected Users: existe, mas não é usado

O grupo de segurança global Protected Users, introduzido no Windows Server 2012 R2, aplica proteções não configuráveis a qualquer conta adicionada a ele. De acordo com a documentação da Microsoft sobre Protected Users, os membros não podem se autenticar com NTLM, não podem usar DES ou RC4 para pré-autenticação Kerberos, não podem ser delegados com delegação restrita ou irrestrita, e recebem um tempo de vida fixo de 4 horas para o TGT Kerberos, sem renovação. A simples associação já faz o trabalho — não há política a configurar incorretamente depois que uma conta está no grupo.

O problema é que a maioria dos ambientes nunca o preenche. Domain Admins e outras contas Tier 0 continuam se autenticando com protocolos legados e armazenando credenciais em cache no LSASS exatamente como se o grupo não existisse, porque ninguém as adicionou a ele.

A flag "confidencial e não pode ser delegada"

Separadamente do Protected Users, toda conta do AD possui um bit userAccountControl — NOT_DELEGATED (0x100000 / 1048576) —, exibido na interface como "Esta conta é confidencial e não pode ser delegada". Quando definida, o ticket Kerberos da conta não pode ser encaminhado para um serviço configurado para delegação, mesmo que esse serviço seja, de outra forma, confiável para delegação. De acordo com a avaliação de segurança do Microsoft Defender for Identity para esse controle, deixar essa flag desativada em contas privilegiadas significa que um serviço comprometido ou malicioso, confiável para delegação, pode solicitar e reutilizar o ticket dessa conta para se passar por ela em outro ponto da rede — um caminho de escalonamento independente de a conta estar ou não em Protected Users.

Exposição à delegação na própria conta

Além da flag confidencial, uma conta pode carregar diretamente uma configuração de delegação: TRUSTED_FOR_DELEGATION (irrestrita), msDS-AllowedToDelegateTo (restrita) ou delegação restrita baseada em recursos via msDS-AllowedToActOnBehalfOfOtherIdentity. Qualquer uma delas em uma conta Tier 0 significa que um serviço comprometido, confiável para delegação, pode solicitar tickets como essa conta. Cobrimos a exploração desses mecanismos em detalhes em Ataques de Delegação Kerberos: de Irrestrita a Abuso de RBCD — o ponto deste artigo é mais restrito: uma conta confidencial nunca deveria ser alvo de delegação, independentemente da técnica de ataque usada contra ela.

Contas de serviço em grupos privilegiados

Uma conta de serviço com um Service Principal Name (SPN) é kerberoastable por design — qualquer usuário autenticado do domínio pode solicitar um ticket de serviço para ela e tentar quebrar o ticket offline (veja nosso guia de Kerberoasting para essa cadeia de ataque). Esse risco é tolerável quando a conta tem acesso apenas ao serviço que executa. Ele deixa de ser tolerável no momento em que a conta também é membro de Domain Admins ou Enterprise Admins.

A orientação da Microsoft sobre redução da associação em grupos administrativos altamente privilegiados é explícita: grupos privilegiados devem ser mantidos vazios ou limitados a um pequeno número de administradores responsáveis, e contas de serviço devem receber permissões delegadas e restritas, em vez de direitos amplos de Domain Admin. Uma conta de serviço em Domain Admins combina uma senha quebrável com privilégio em todo o domínio — qualquer pessoa capaz de consultar SPNs já tem um caminho para tentar o comprometimento total do domínio.

SID History: o quarto caminho silencioso

O atributo sIDHistory existe para preservar o acesso durante migrações entre domínios — um usuário migrado mantém a SID de sua conta antiga, anexada ao seu token, para que as permissões existentes continuem funcionando. De acordo com a MITRE ATT&CK T1134.005, um atacante com direitos equivalentes a Domain Admin (ou capacidade de DCSync) pode inserir uma SID privilegiada coletada ou conhecida — como a de Enterprise Admins — na SID History de uma conta de baixo privilégio. O token dessa conta passa então a carregar direitos de Enterprise Admin sem nunca aparecer como membro do grupo Enterprise Admins, o que é exatamente o que a torna perigosa: a revisão de associação a grupos a ignora completamente.

Por Que Atacantes Encadeiam Essas Lacunas

Nenhum desses quatro problemas precisa existir isoladamente para ser útil a um atacante, e na prática raramente existem. Uma conta privilegiada sem a flag confidencial é um alvo viável de delegação; a mesma conta fora do Protected Users ainda pode se autenticar com NTLM, então um atacante com um hash retransmitido nem precisa do Kerberos. Se esse mesmo ambiente também tiver uma conta de serviço em Domain Admins, um atacante que faça Kerberoasting e quebre sua senha obtém uma segunda rota, independente, para o mesmo nível de privilégio — sem necessidade de abuso de delegação. E a SID History oferece uma opção de persistência que sobrevive inteiramente a uma rotação de credenciais na conta privilegiada original, já que a SID injetada viaja em uma identidade completamente diferente e de baixo privilégio.

É também por isso que essa lacuna é diferente de contas privilegiadas obsoletas (credenciais inativas que ninguém desativou — veja Contas Privilegiadas Obsoletas: Risco Oculto no Active Directory) e do desvio de acesso privilegiado (direitos que retornam depois de uma limpeza — veja Desvio de Acesso Privilegiado no Active Directory). Esses casos tratam de contas que não deveriam mais ter acesso, ou de acesso que voltou a existir. Este artigo trata de contas que estão corretamente privilegiadas hoje, mas sem as proteções em nível de atributo que o Active Directory já oferece para contê-las.

Detecção

Consulte o diretório diretamente para cada lacuna — nada disso exige ferramentas de terceiros.

# Contas privilegiadas que NÃO estão em Protected Users
$protected = (Get-ADGroupMember "Protected Users" -Recursive).SamAccountName
Get-ADGroupMember "Domain Admins" -Recursive |
    Where-Object { $_.SamAccountName -notin $protected } |
    Select-Object SamAccountName

# Contas privilegiadas sem a flag "confidencial, não pode ser delegada" (bit 0x100000)
Get-ADGroupMember "Domain Admins" -Recursive |
    Get-ADUser -Properties userAccountControl |
    Where-Object { -not ($_.userAccountControl -band 1048576) } |
    Select-Object SamAccountName

# Contas ainda confiáveis para delegação irrestrita/restrita
Get-ADUser -Filter 'TrustedForDelegation -eq $true -or msDS-AllowedToDelegateTo -like "*"' `
    -Properties TrustedForDelegation, msDS-AllowedToDelegateTo

# Contas de serviço (com SPN definido) dentro de grupos privilegiados
Get-ADGroupMember "Domain Admins","Enterprise Admins" -Recursive |
    Get-ADUser -Properties ServicePrincipalNames |
    Where-Object { $_.ServicePrincipalNames.Count -gt 0 }

# Qualquer conta com SID History
Get-ADUser -Filter * -Properties SIDHistory |
    Where-Object { $_.SIDHistory.Count -gt 0 } |
    Select-Object SamAccountName, SIDHistory

Para um mapeamento mais amplo de quais Event IDs importam no restante do seu ambiente AD, veja Monitoramento do Active Directory: os Event IDs de Segurança que Importam.

Correção

1. Preencha o Protected Users apenas com contas humanas Tier 0. Teste primeiro em um grupo piloto — o Protected Users quebra aplicativos dependentes de NTLM, logon em cache/offline e qualquer fluxo que dependa de renovação de ticket Kerberos além de 4 horas. Nunca adicione contas de serviço ou de computador.
2. Defina a flag confidencial em toda conta humana privilegiada:

   Get-ADUser -Identity "jdoe" | Set-ADAccountControl -AccountNotDelegated:$true
   

   Faça isso mesmo para contas já presentes no Protected Users — o bloqueio de delegação do Protected Users é aplicado na autenticação, mas uma flag confidencial explícita é defesa em profundidade e importa imediatamente para qualquer conta ainda não totalmente migrada para o grupo.
3. Remova a confiança de delegação das contas Tier 0. Limpe TrustedForDelegation e msDS-AllowedToDelegateTo em qualquer conta privilegiada; contas privilegiadas nunca deveriam ser alvos de delegação. Veja nosso guia Ataques de Delegação Kerberos para saber como auditar a configuração de delegação em todo o domínio antes de começar a removê-la.
4. Retire contas de serviço de grupos privilegiados. Substitua a associação a Domain Admin por uma Group Managed Service Account (gMSA) com permissões estritamente delegadas na OU ou no recurso específico de que o serviço realmente precisa. Se o serviço genuinamente precisa de direitos em todo o domínio, isso é um sinal para redesenhar o serviço, não para deixar uma conta kerberoastable com privilégio total de domínio.
5. Audite e limpe a SID History obsoleta. Execute a consulta de detecção acima; qualquer valor de sIDHistory que não esteja vinculado a uma migração de domínio documentada e ainda relevante deve ser investigado e removido com Set-ADUser -Clear sIDHistory após confirmar que nenhum acesso legítimo depende dele. Para trusts entre florestas e externos, ative a filtragem de SID (quarentena) para que as SIDs injetadas do outro lado do trust sejam removidas antes de chegarem ao seu domínio — veja Ataques de Confiança do Active Directory: do Domínio Filho à Raiz da Floresta para saber como lacunas na filtragem de SID são exploradas entre trusts.

Como a EtcSec Detecta Isso

A auditoria de Active Directory da EtcSec verifica as quatro lacunas em cada varredura: NOT_IN_PROTECTED_USERS sinaliza contas privilegiadas ausentes do grupo Protected Users, SENSITIVE_DELEGATION identifica contas privilegiadas sem a flag "não pode ser delegada", SERVICE_ACCOUNT_PRIVILEGED encontra contas com SPN dentro de Domain Admins/Enterprise Admins, e SID_HISTORY revela qualquer conta com uma sIDHistory não vazia para revisão.