Exposição de Senha GMSA Active Directory: Quando a Rotação Automática Não é um Limite de Segurança

Exposição de Senha GMSA Active Directory

Exposição de senha GMSA Active Directory está entre as lacunas mais consequentes que a EtcSec observa na higiene de contas de serviço, porque a conta exposta costuma ser justamente aquela que todos presumiam segura por padrão. Uma Group Managed Service Account (gMSA) é a solução da Microsoft para um dos problemas mais antigos do Active Directory: senhas estáticas de contas de serviço, conhecidas por humanos, que permanecem inalteradas por anos em scripts, tarefas agendadas e arquivos de configuração. O controlador de domínio gera uma senha aleatória de 256 bytes e a rotaciona automaticamente — por padrão, a cada 30 dias — de modo que nenhum administrador jamais a digita ou a armazena em lugar algum (Microsoft Learn — Manage Group Managed Service Accounts). Essa é a promessa, e em seus próprios termos ela se sustenta.

O que ainda causa essa exposição não é uma senha vazada — é uma lista excessivamente ampla de principals autorizados a lê-la. "Ninguém tem a senha" só se sustenta enquanto a lista de quem pode recuperá-la permanecer restrita, e essa lista é controlada por um único atributo que fica amplo demais com muito mais frequência do que os defensores esperam.

Para Que Serve Uma gMSA

Serviços que rodam de forma idêntica em uma farm balanceada — pools de aplicativos IIS, tarefas agendadas, serviços do Windows — precisam de um principal que se comporte da mesma forma em todos os hosts para que a autenticação mútua Kerberos funcione. Uma gMSA oferece isso sem uma senha compartilhada e sincronizada manualmente: qualquer host com direitos de recuperação obtém a senha atual diretamente do AD via LDAP sempre que o serviço precisa dela (Microsoft Learn).

Por Que a Lista de Direitos de Leitura Ainda Cria Exposição

A lacuna aparece de duas formas na prática: um grupo de segurança criado para a gMSA é reaproveitado para algo não relacionado e silenciosamente ganha novos membros ao longo do tempo, ou o grupo é aninhado dentro de um grupo administrativo mais amplo já existente durante a configuração, porque essa era a forma mais rápida de colocar o serviço para funcionar. Qualquer um dos dois caminhos deixa a lista de leitores mais ampla do que os um ou dois hosts que realmente precisam dela — e, diferentemente de uma verificação normal de grupo privilegiado, essa ACL não é revisada na mesma cadência que a associação a grupos.

Como Funciona: PrincipalsAllowedToRetrieveManagedPassword

O Atributo msDS-GroupMSAMembership

Ao criar uma gMSA, você especifica quais contas de computador ou grupos de segurança podem buscar sua senha:

New-ADServiceAccount -Name svc-app01 -DNSHostName svc-app01.corp.local `
  -PrincipalsAllowedToRetrieveManagedPassword "SG-App01-Hosts"

Esse parâmetro grava em msDS-GroupMSAMembership, um atributo que contém um security descriptor no formato String(NT-Sec-Desc) — uma ACL codificada em base64 que não pode ser lida diretamente. PrincipalsAllowedToRetrieveManagedPassword é o wrapper amigável do PowerShell que o AD expõe para ler e gravar esse atributo (Microsoft Learn — Set-ADServiceAccount); a mecânica bruta do atributo está documentada em detalhes pela DSInternals e pela referência gMSA do InternalAllTheThings.

Quem estiver listado ali pode consultar o atributo msDS-ManagedPassword, que o AD calcula no momento da leitura e retorna como um MSDS-MANAGEDPASSWORD_BLOB contendo a senha atual em texto claro. Criticamente, isso não é uma verificação baseada em grupo privilegiado — Domain Admins não recebem acesso implícito nenhum. Somente os principals explicitamente listados em msDS-GroupMSAMembership podem ler a senha, sejam eles quem forem (DSInternals).

Como a Lista Fica Ampla Demais

Não há aviso embutido quando PrincipalsAllowedToRetrieveManagedPassword cresce além do escopo original. Um grupo adicionado "temporariamente" durante uma migração, uma associação aninhada herdada da delegação de uma OU pai, ou um grupo administrativo aninhado adicionado porque já continha as contas de computador certas — qualquer um desses expande silenciosamente quem pode se passar pela conta de serviço, sem nenhuma alteração correspondente no próprio objeto gMSA que chamaria atenção durante uma revisão de rotina. É a mesma classe de problema coberta em Abuso de ACL e DCSync: uma permissão que ninguém lembra de ter concedido, ainda válida, ainda explorável.

A Cadeia de Ataque: De Um Grupo Amplo Demais À Personificação Total

Um Caso Real: A gMSA da Citrix em Domain Admins

O relato de Sean Metcalf no ADSecurity.org documenta um caso concreto desse padrão: uma gMSA da Citrix que era, ela mesma, membro de Domain Admins tinha seus direitos de recuperação de senha delegados a um grupo chamado "Citrix04" — que, ao ser inspecionado, continha uma conta de usuário comum. Comprometer essa única conta de usuário foi suficiente para obter a senha de uma gMSA equivalente a Domain Admin (ADSecurity.org — GMSA Security Tip #14).

Lendo a Senha Depois de Estar na Lista

Assim que um principal está na lista de leitores autorizados, extrair a senha não exige nenhum exploit — apenas uma leitura:

# Usando os módulos AD + DSInternals
$gmsa = Get-ADServiceAccount -Identity "svc-app01" -Properties 'msDS-ManagedPassword'
$blob = ConvertFrom-ADManagedPasswordBlob $gmsa.'msDS-ManagedPassword'
ConvertTo-NTHash -Password $blob.SecureCurrentPassword

Get-ADServiceAccount retorna o blob, ConvertFrom-ADManagedPasswordBlob (DSInternals) o decodifica na senha atual e anterior em texto claro, e ConvertTo-NTHash deriva o hash NT para uso offline (DSInternals). Ferramentas como GMSAPasswordReader.exe e gMSADumper.py automatizam a mesma leitura LDAP remotamente, sem nunca tocar no host de destino.

Essa relação é exatamente o que a edge ReadGMSAPassword do BloodHound mapeia: qualquer usuário, grupo ou computador com direitos de recuperação sobre uma gMSA. A SpecterOps documenta três caminhos de abuso a partir dessa edge — roubar ou injetar o token da gMSA, caso ela já esteja logada em um host autorizado; agendar uma tarefa ou serviço para rodar como a gMSA em um host autorizado; ou recuperar a senha remotamente e usar o hash NT resultante para overpass-the-hash (BloodHound — ReadGMSAPassword). Nenhum desses caminhos exige que a rotação automática da gMSA falhe — a rotação apenas significa que o atacante relê a senha após cada ciclo, da mesma forma que um host autorizado faz.

Detecção

IDs de Evento do Windows Para Correlacionar

Esses IDs de evento e a abordagem de correlação (cruzando 4662, 2946 e 4624 pelo Logon ID dentro de uma janela curta) estão documentados no relato da TrustedSec sobre a caça a abusos de gMSA (TrustedSec — Splunk SPL Queries for Detecting GMSA Attacks). Sem uma SACL no objeto gMSA, o 4662 nunca é disparado — a auditoria precisa ser ativada deliberadamente, objeto por objeto.

Auditando a Lista de Leitores Diretamente

A detecção baseada em logs só captura uma leitura depois que ela acontece. Audite a lista de autorização diretamente e em todo o domínio, em vez de esperar por um evento:

Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

Execute isso contra todas as gMSAs do domínio e expanda qualquer grupo retornado — um único nome de grupo de segurança pode esconder uma conta de usuário obsoleta, um grupo baseado em OU excessivamente amplo, ou um grupo privilegiado aninhado que nunca deveria ter tido direitos de recuperação.

Remediação (Remediation)

1. Enumere cada gMSA e seus leitores usando a consulta acima. Expanda a associação de grupos, não apenas o nome do principal de nível superior — é aqui que a surpresa no estilo Citrix04 se esconde.
2. Restrinja PrincipalsAllowedToRetrieveManagedPassword exatamente aos hosts que precisam dele. Use Set-ADServiceAccount -Identity <NomeDaGMSA> -PrincipalsAllowedToRetrieveManagedPassword <grupo-restrito> para substituir um grupo excessivamente amplo por um restrito às contas de computador específicas que executam o serviço (Microsoft Learn — Set-ADServiceAccount).
3. Verifique que nada quebra antes e depois da mudança com Test-ADServiceAccount -Identity <NomeDaGMSA> em cada host que deve manter o acesso (Microsoft Learn — Manage Group Managed Service Accounts).
4. Nunca aninhe um grupo leitor de gMSA dentro de um grupo administrativo mais amplo para economizar um passo durante a configuração — esse aninhamento é exatamente como um único grupo acaba controlando a recuperação de senha de contas para as quais nunca deveria ter acesso. Veja Aninhamento Perigoso de Grupos para entender como a associação transitiva cria caminhos que os defensores não esperam.
5. Se a própria gMSA estiver em um grupo privilegiado (Domain Admins ou equivalente), trate isso como uma descoberta adicional e independente — direitos de leitura de senha excessivamente amplos em um membro de grupo privilegiado são um caminho mais rápido para Domain Admin do que qualquer um dos dois problemas isoladamente. Isso é diferente da higiene simples de associação a grupo privilegiado, coberta em Active Directory Privileged Accounts: Protected Users, Delegation e Lacunas em Contas de Serviço.
6. Ative a auditoria de acesso ao Directory Service (SACL) nos objetos gMSA para que eventos 4662 sejam realmente gerados para as contas que mais importam, em vez de descobrir a lacuna somente durante um incidente.

Como a EtcSec Detecta Isso

A verificação GMSA_PASSWORD_READERS da EtcSec sinaliza objetos gMSA em que PrincipalsAllowedToRetrieveManagedPassword inclui um principal mais amplo do que o escopo de host esperado — contas de usuário, grupos de segurança genéricos ou associações aninhadas que não deveriam poder recuperar a senha. Ela é combinada com a GMSA_OLD_PASSWORD, que sinaliza gMSAs cuja senha gerenciada não rotacionou conforme o cronograma, e a DANGEROUS_GROUP_NESTING, que detecta o padrão de associação transitiva que geralmente causa esse excesso de escopo.

Leitura relacionada: Kerberoasting Detection Prevention Guide cobre o ataque baseado em SPN ao qual as gMSAs são amplamente imunes (nenhum ticket crackeável, já que a senha é composta por 256 bytes de dados aleatórios) — contexto útil para entender por que a adoção de gMSA não elimina o risco em contas de serviço, apenas o realoca para essa ACL. BadSuccessor dMSA Privilege Escalation cobre um caminho de escalonamento relacionado, mas distinto, em contas gerenciadas via MSAs delegadas.