Contas de Serviço Gerenciadas por Grupo: solução contra Kerberoasting ou incentivo ao ataque Golden GMSA?

Escrito por Jessé "tio chik0" Neto

Introdução

Para profissionais de segurança da informação ou administradores de sistemas, a gestão de contas de usuários é sempre um desafio, e, quando se trata de contas serviço o problema só aumenta tendo em vista que tais contas são uma questão crucial para a proteção de infraestruturas corporativas, especialmente pela quantidade de serviços no ambiente. Um incidente comum em ambientes vulneráveis é o comprometimento de contas de serviço, especialmente quando não são adotadas práticas BÁSICAS de gerenciamento de credenciais. Essas contas, muitas vezes utilizadas por aplicações e serviços para executar funções essenciais voltadas para a continuidade do negócio, tornam-se alvos de ataques simples e bem conhecidos, como por exemplo: o Kerberoasting, onde senhas associadas a contas de serviço são extraídas e exploradas.

A Microsoft introduziu, a partir do Windows Server 2012, as Contas de Serviço Gerenciadas (Managed Service Accounts, ou MSAs) e as Contas de Serviço Gerenciadas de Grupo (Group Managed Service Accounts, ou gMSAs). Essas soluções, que inclusive já existe uma atualização no Windows Server 2025, o dMSA (Conta de Serviços Gerenciadas Delegadas), foram projetadas para resolver uma problemática relacionada à gestão manual de contas de serviço, automatizando e deixando o processo mais seguro para a proteção dessas credenciais, eliminando a necessidade de se preocupar com tarefas administrativas como a definição de políticas de senha complexas ou a rotação periódica de credenciais.

Essas contas são integradas ao Centro de Distribuição de Chaves (KDC) do Active Directory, que gerencia automaticamente a geração e atualização de suas senhas. Essa automação garante que senhas sejam em tese, seguras e complexas e que elas também sejam atribuídas e alteradas regularmente, sem a intervenção de administradores ou sysadmins.

As MSAs e gMSAs representam, portanto, um avanço significativo na segurança de do ambiente de Active Directory onpremises que dependem de contas de serviço, proporcionando uma solução eficiente para a gestão de identidade, como podemos ver abaixo:

Por default a senha é alterada a cada 30 dias;

A senha possui um alto nível de comprimento e complexidade;

Ninguém tem acesso à senha da conta;

Não há capacidade de login interativo;

Somente hosts autorizados serão capazes de utilizar a conta para executar serviços e tarefas.

MSAs Vs gMSAs

Com base na documentação oficial da Microsoft, a escolha entre contas de serviço gerenciadas autônomas (MSAs) e contas de serviço gerenciadas de grupo (gMSAs) pode depender do escopo de implementação, ou seja, se o serviço será executado em um único host ou em dois ou mais hosts (um farm de servidores).

Contas de Serviço Gerenciadas Autônomas (MSAs):

Implantação em um único host: são ideais para cenários onde um serviço é implantado em um único servidor com mínima intervenção administrativa. Elas oferecem uma solução de identidade única para serviços em execução em um servidor específico. Se não for possível utilizar uma gMSA e o serviço estiver limitado a um servidor, as MSAs são uma opção.

Contas de Serviço Gerenciadas de Grupo (gMSAs):

Implantação em dois ou mais hosts (Farm de Servidores): As gMSAs são recomendadas quando o serviço é executado em dois ou mais servidores, seja em um farm de servidores ou em um ambiente distribuído. Elas fornecem uma solução de identidade única para serviços em execução em um farm de servidores ou atrás de um balanceador de carga de rede.

Entretanto, a proteção contra o ataque de Kerberoasting pode ser também uma abertura para uma ameaça conhecida como Golden gMSA.

É, em alguns cenários, laboratórios ou inclusive, em alguns clientes nós identificamos uma gMSA mal configurada, onde a falta de ajustes adequados permite que um invasor crie tickets Kerberos com permissões excessivas. Esses tokens podem ser usados para comprometer seriamente a segurança do ambiente, uma vez que concedem ao atacante níveis elevados de acesso e controle sobre os recursos do domínio. Para evitar essa vulnerabilidade, é essencial configurar corretamente as gMSAs, garantindo que os princípios altamente recomendados pela Microsoft, a saber: privilégio mínimos e segregação de funções sejam rigorosamente aplicados à estrutura.

Conceitos iniciais

O Golden gMSA é uma variação do ataque Golden Ticket que se concentra em contas de serviço gerenciadas de grupo (gMSA) no ambiente Windows. Para entender o Golden gMSA é útil revisar os conceitos básicos do funcionamento da autenticação Kerberos, sem entendê-lo a lógica do ataque não será compreendida como deveria.

Autenticação Kerberos:

O Kerberos é um protocolo de AUTENTICAÇÃO amplamente usado em ambientes Windows e preferencial em redes do Active Directory usando a porta 88 TCP/UDP, RFC 4120.

Trata-se no uso de tickets que permitem que o usuário realize a autenticação. Mas, o que tem nesses tickets?

Tickets

SPN – O alvo/serviço de destino que o ticket é aplicável
UPN – [email protected]
Uma chave para conectar o usuário ao serviço
Carimbo de data e hora (timestamp) que determina o período de validade do ticket

PAC – Privilege Attibute Certificate

No PAC você encontra as informações de segurança que estão diretamente associadas ao usuário e verifica se as informações são verdadeiras. Os componentes do PAC são:

SID – Security Identifier;
RID – Relative Identifier;
GroupsIds – Grupos de Domínio ao qual o usuário está inserido;
Extra GroupsIds – Grupos que não pertencem ao domínio.

Além disto, o PAC inclui algumas assinaturas que são responsáveis pela verificação da integridade dos dados do PAC e dos Tickets, como assinatura do servidor que é criada com a chave utilizada para criptografar o ticket, a assinatura do KDC que obviamente usa a chave do KDC para confirmar se o PAC foi criado pelo KDC e por fim, a assinatura do próprio ticket, de certa forma, é bem nova essa assinatura, e ela contém a assinatura do conteúdo do ticket com a chave KDC.

Serviços KDC

É ele quem fornece os tickets para o usuário. No KDC existem dois grandes serviços/atores. O (AS) Authentication Service/Server e o TGS (Ticket-Granting Service/Server), esses dois serviços são responsáveis pela requisição das chaves Kerberos.

OBS: O TGT é gerado pelo AS e, o ST (Service Ticket) é gerado pelo TGS. É muito comum chamarem ou confundirem o ST pelo TGS. Então, dois tickets são criados, o TGT e o ST. Se tiver dúvidas quanto a isso, leia a RFC4120.

Requisição de TGT (Ticket Granting Ticket):

O cliente solicita um Ticket Granting Ticket (TGT) ao AS (que é um serviço do KDC) ao fornecer suas credenciais armazenados no lsass. Essa mensagem é conhecida como AS-REQ. É provável que essa mensagem esteja com o timestamp criptografado. Se você observar o comportamento do Kerberos através do Wireshark poderá perceber que existe uma pré-autenticação.
O AS recebe a solicitação, podendo analisar o timestamp, e depois responde com a mensagem AS-REP. Essa mensagem contém 2 partes criptografadas: Os dados do cliente criptografados e o TGT criptografado que foi gerado.
É importante destacar que apenas o SPN inicial deve ter a permissão para acessar o ticket.
Todos os TGT gerados são criptografados com a chave da conta krbtgt.

Solicitação de ST (Service Ticket):

O cliente em posse do TGT solicita agora um ST através da apresentação do TGT ao serviço TGS para acessar um serviço específico com uma mensagem TGS-REQ. Nesse TGS-REQ é incluído o TGT e agora o SPN. Neste momento a mensagem além do TGT, SPN tem também o UPN, a chave de sessão e o timestamp.
O KDC usa sua própria chave para descriptografar o TGT e assim acessar o nome de usuário + a chave de sessão. Em seguida, o KDC utiliza essa chave de sessão para descriptografar o nome de usuário que o cliente enviou, verificando se é válido(krbtgt). Se tudo estiver correto, o KDC envia uma resposta (TGS-REP) com duas partes criptografadas: uma é o Service Ticket (ST) para o serviço que o cliente pediu o acesso, protegido pela chave do serviço; a outra contém dados do cliente criptografados com a chave de sessão. Algumas informações, como a chave de sessão do serviço, são incluídas nas duas partes para permitir que tanto o cliente quanto o serviço compartilhem a mesma chave e possam se comunicar de forma segura.

Acesso ao Serviço:

Em posse do ST o cliente envia uma mensagem de AP-REQ para o target(SPN) que contém o PAC e a chave de sessão do serviço e então será validado se o usuário em questão tem acesso ou não ao serviço.
Aqui temos um impasse, caso o servidor queira realizar o validação de permissão através do PAC ele irá fazê-lo por meio de um KERB_VERIFY_PAC_REQUEST e após essa validação, caso o cliente necessite será retornado uma mensagem de AP-REP usando a chave de sessão demonstrando que o serviço pode descriptografar o Service Ticket.

A imagem abaixo demonstra bem as requisições e o processo entre uma máquina cliente e o serviço alvo.

1 A simplified version of the Kerberos authentication system: both the... | Download Scientific Diagram — **https://www.researchgate.net/figure/A-simplified-version-of-the-Kerberos-authentication-system-both-the-client-and-a-service_fig1_265007903**

Isso posto, acredito que é de bom tom ter incluído essa explicação sobre o protocolo Kerberos e assim podemos entender agora o ataque de Kerberoasting, onde ele acontece durante o processo de autenticação bem como o motivo do uso das contas gerenciadas de serviço e por fim analisarmos o ataque Golden GMSA com mais tranquilidade obtendo uma melhor compreensão do problema levantado nesse post.

Kerberoasting

É um ataque que explora a maneira como o protocolo Kerberos distribui os STs para serviços no Active Directory. Esse ataque pode ser executado por qualquer usuário autenticado, sem a necessidade de privilégios elevados, tornando-o uma ameaça comum em ambientes Windows. Vamos avaliar o processo do Kerberoasting.

Requisição de Ticket de Serviço(ST) – Qualquer usuário autenticado no domínio pode solicitar um ST para qualquer serviço registrado com um SPN, mesmo que o serviço não esteja em execução;
Criptografia do Ticket: O ST é criptografado com a senha da conta de serviço associada ao SPN;
Tentativa do Ataque: Uma vez obtido o ST, o atacante pode tentar descriptografá-lo para descobrir a senha da conta de serviço.

Uma boa execução do Kerberoasting depende da complexidade e do gerenciamento da senha da conta associada ao SPN. A maioria dos serviços é registrado em contas de máquinas, que possuem senhas geradas automaticamente com 120 caracteres e são rotacionadas a cada 30 dias. Por isso, é difícil.

Entretanto, em alguns casos, serviços são registrados em contas de usuários geridas de forma manual. Essa contas frequentemente possuem senhas mais frágeis, tornando-as alvos para o Kerberoasting. Como muitos serviços estão vinculados inevitavelmente a contas de usuários privilegiadas, até para tornar o dia a dia dos administradores mais fácil, essas contas são as que despertam mais interesse para o atacante.

Embora as gMSAs prometam uma solução segura contra o Kerberoasting, elas introduzem novos riscos que podem ser explorados, como o ataque Golden GMSA. Esse ataque visa comprometer a KDS Root Key, que é usada para gerar e proteger as senhas de todas as gMSAs.

Dentro do processo de autenticação do Kerberos como o ataque de Kerberoasting funcionaria?

Após receber o ST, o atacante salva o ticket e, fora do ambiente Kerberos, usa ferramentas para tentar quebrar a criptografia do ST.
A chave do ST é derivada da senha do serviço no AD, então, se a senha for fraca, o atacante pode usar ataques de força bruta ou dicionário para descobrir a senha do serviço.
Se o ataque for bem-sucedido, o invasor agora tem acesso a uma credencial válida para o serviço e pode usá-la para acessar recursos como o serviço ou os dados que ele gerencia.

Por isso, o uso do gMSA é importante para conter o ataque de Kerberoasting e principalmente entendermos que há uma solução viável para contornar esse problema. Mas, será que ao solucionar um problema como esse estaremos criando outro problema?

Agora que o processo de autenticação do Kerberos e o ataque de Kerberoasting foi minimamente entendido, podemos analisar o processo do ataque de Golden gMSA.

Golden gMSA Attack

O Golden gMSA Attack envolve o comprometimento uma máquina autorizada a acessar as senhas de Group Managed Service Accounts (gMSA) no Active Directory. Isso permite que o invasor roube a senha e utilize a conta de serviço comprometida para acessar recursos. Embora a gMSA possa ser usada em serviços que empregam o Kerberos para autenticação, o ataque em si não interage ou manipula diretamente o Kerberos, ao contrário do Kerberoasting. Aqui estão os elementos essenciais para entendermos o ataque:

Atributos Críticos:

msDS-ManagedPasswordID: Contém o identificador da senha segura da conta gMSA;
SID (Security Identifier): Identificador da conta de serviço;
CurrentPassword: Armazena a senha da gMSA;
msDS-GroupMSAMembership: Controla quem pode acessar a senha da gMSA;

Momento do Ataque:

O ataque ocorre quando um invasor compromete justamente a máquina autorizada a acessar as senhas de Group Managed Service Accounts no Active Directory. O invasor obtém o msDS-ManagedPasswordID e o SID da conta gMSA para gerar a senha gMSA associada, sem precisar criar um TGT. Em posse da senha da gMSA, o invasor pode usar essa conta de serviço para acessar outros recursos de forma ilegítima, mas o ataque não envolve a manipulação direta do Kerberos como acontece no Kerberoasting.

Impacto:

Com o TGT falsificado, o invasor pode se passar pela conta de serviço comprometida, acessando recursos do domínio como se fosse a conta legítima.

As gMSAs utilizam o protocolo Kerberos para autenticação. O protocolo Kerberos por sua vez, gera tickets para acessar serviços, incluindo o TGT, que permite ao serviço solicitar, por meio da extensão S4U2Self, a delegação de autenticação, sem a necessidade de credenciais adicionais, facilitando o acesso contínuo.

Na gMSA, a senha é armazenada no atributo CurrentPassword, e o atributo msDS-GroupMSAMembership controla quais hosts têm permissão para acessar essa senha. As senhas são calculadas dinamicamente usando a função da biblioteca kdscli.dll, necessitando do SID e do msDS-ManagedPasswordID, obtido via consulta LDAP.

Para que o ataque seja preciso será necessário obter alguns atributos do objeto KDS Root Key e os atributos SID e msds-ManagePasswordID do objeto gMSA em questão.

Acredito firmemente que a partir daqui fica fácil entender o ataque por termos conceitos suficientes e o entendimento adequado.

O ataque

Para facilitar a criação do seu lab, os comandos que usei para criação da conta gerenciada de serviço você pode obter abaixo:

Add-KdsRootKey -EffectiveTime ((get-date).AddHours(-10))

New-ADServiceAccount -Name openfire -DNSHostName openfire.purple.local -PrincipalsAllowedToRetrieveManagedPassword dc1$

Get-ADServiceAccount -Filter *

Test-ADServiceAccount openfire

Em posse do cenário proposto, protegendo o ambiente contra o ataque de Kerberoasting usando a conta gerenciada de serviço criada podemos iniciar o simples processo do ataque Golden GMSA.

Primeiramente precisamos recuperar as informações da conta gerenciadas de serviço do nosso domínio purple.local usando duas formas com o Powershell e com o uso da ferramenta GoldenGMSA. A resposta nos dará o objectSid da conta de serviço existente.

Nesta primeira etapa o comando a seguir lista TODAS as contas de Serviço Gerenciadas existentes no domínio e retornaria o tipo de ObjectClass, ObjectGUID e o SID da conta. A conta alvo é a “openfire”

Get-ADserviceAccount -Filter * -Properties HostComputers

Podemos também usar a ferramenta GoldenGMSA para obter o objectSid e o rootKeyGuid.

\.GoldenGMSA.exe gmsainfo

Uma outra forma de obter o SID da conta de serviço é através do próprio PowerShell, neste caso o filtro utilizado foi usando uma conta de serviço previamente identificada.

Write-Host "O SID da GMSA openfire$ é: $((Get-ADServiceAccount -Filter {SamAccountName -eq 'openfire$'}).SID.Value)"

De posse do objectSid (S-1-5-21-744271447-2956764748-1961386095-1103) da conta de serviço desejada, faremos um DUMP do KDS Root Key. Essa chave é usada para criptografar e proteger as senhas gerenciadas associadas a contas gMSA.

\.GoldenGMSA.exe --dump-key a4dfde65-8879-e4ef-3ef5-5834ed0174f1

Agora usaremos a ferramenta GoldenGMSA para obter a senha GMSA em formato Base64.

\.GoldenGMSA.exe kdsinfo

Neste exemplo eu passei o objectSid da conta de serviço resultante do comando.

\.GoldenGMSA.exe compute --sid S-1-5-21-744271447-2956764748-1961386095-1103

A defesa

Para lidar com ameaças relacionadas a contas de serviço gerenciadas (gMSA) e servidores legados, é importante focar em medidas preventivas, como o uso de criptografias mais fortes e a rotação periódica de senhas. Contudo, antes de implementar essas soluções, é essencial realizar uma análise detalhada dos servidores e serviços que utilizam criptografias antigas, a fim de garantir compatibilidade com as atualizações de segurança.

Durante a criação de uma conta de serviço gerenciada, dois parâmetros são essenciais para reforçar a segurança:

Revisar as contas de serviço gerenciadas existentes usando o comando Get-ADServiceAccount -Filter * -Properties HostComputers
ManagedPasswordIntervalInDays: por padrão, a rotação de senhas ocorre a cada 30 dias, mas podemos reduzir esse intervalo para, por exemplo, 15 dias, aumentando a frequência da rotação e dificultando o uso prolongado de credenciais comprometidas.
KerberosEncryptionType: a adoção de criptografia mais forte, como AES256, melhora a proteção contra ataques, especialmente em ambientes que ainda utilizam criptografias mais fracas.

No laboratório, a criação de uma conta de serviço gerenciada pode seguir o comando abaixo, configurando um intervalo de 15 dias para rotação de senha e o uso de criptografia AES256:

New-ADServiceAccount -Name openfire -DNSHostName openfire.purple.local -ManagedPasswordIntervalInDays 15 -KerberosEncryptionType AES256 -PrincipalsAllowedToRetriveManagedPassword adds$

Além dessas configurações, o uso de tecnologias de monitoramento pode ser uma camada adicional de defesa:

User and Entity Behavior Analytics (UEBA): auxilia na identificação de atividades suspeitas relacionadas às contas gerenciadas de serviço, analisando os logs e comportamentos anômalos.
Endpoint Detect and Response (EDR): ajuda a detectar movimentações laterais e padrões de persistência que podem indicar compromissos no ambiente.

Isto posto, entende-se que em alguns casos a aplicação de técnicas para defesa não são e nem podem ser consideradas suficientes, é necessário incluir um processo contínuo de monitoramento.

O monitoramento

O monitoramento do acesso às chaves raiz e contas de serviço gerenciadas, especialmente aquelas associadas ao atributo msKds-ProvRootKey, podem fornecer acessos indevidos a membros não controladores de domínio. Pode-se encontrar essa configuração em Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Directory Service Access(Enable) e Audit Detailed Directory Service Replication.

Para visualizar os eventos do Windows você pode acessar Event Viewer -> Windows Logs -> Security e buscar os Event Ids 4662, 4670 e 5136 relacionados a msKds-ProvRootKey.

Event ID 4662: Registra operações em objetos do Active Directory, como acessos ou modificações, sendo relevante para monitorar acessos a objetos sensíveis.
Event ID 4670: Indica alterações nas permissões de um objeto no Active Directory, sinalizando mudanças no Controle de Acesso Discricionário (DACL), que podem ser indicativos de elevação de privilégios.
Event ID 5136: Registra modificações em atributos de objetos do Active Directory, importante para detectar alterações inesperadas em contas ou configurações críticas.

Um ítem interessante a se monitorar é o Event ID Relacionados a extensão S4U2Self

Event ID 4769: Esse evento ocorre quando um Ticket Granting Service (TGS) é solicitado. Um pedido usando S4U2Self pode gerar esse evento.
Event ID 4771: Esse evento indica uma falha de autenticação Kerberos, o que pode ocorrer em caso de tentativas maliciosas ou erros de configuração no uso de S4U2Self.

Uma questão importante que possivelmente irá elevar a maturidade de um time de detecção é analisar as possíveis anomalias em relação a autenticação com Kerberos.

Solicitações de TGT incomuns;
Expiração incomum de tickets;
Uso de contas de serviços em Hosts não autorizados;
Acessos das contas de serviço em horários incomuns;
Modificação de atributos de segurança aos objetos do Active Directory.

Essas práticas, quando combinadas, oferecem uma defesa eficaz contra esse tipo de ataque.

Conclusão

Ao longo dos anos trabalhando em ambientes com o Active Directory tem se descoberto que existe um grande desafio para os profissionais responsáveis por ambientes de gestão de contas e identidades. O ataque de Kerberoasting, por exemplo, destaca as fraquezas das senhas de serviço e a importância de medidas proativas.

A introdução das Contas de Serviço Gerenciadas (MSAs e gMSAs) pela Microsoft, a partir do Windows Server 2012, foi uma resposta positiva para evitar alguns riscos, já que o sistema operacional passa a gerenciar automaticamente as contas de serviço, eliminando a necessidade de se preocupar com senhas complexas e a rotação frequente.

Entretanto, novas ameaças aparecem o tempo inteiro. O uso de tecnologias legadas passa a ser quase inevitável, então ameaças como o Golden gMSA Attack, expõe vulnerabilidades específicas nas gMSAs, que, apesar de se proporem a mitigar o Kerberoasting, não são uma solução definitiva, pois o ataque explora atributos como msDS-ManagedPasswordID e SID para criar tickets forjados (TGTs), como pôde-se constatar no post.

A defesa contra o Golden gMSA Attack requer a adoção de aplicações de boas práticas, como a rotação frequente de senhas, o uso de criptografias modernas e a avaliação cuidadosa do impacto dessas mudanças para evitar a interrupção dos serviços, mas principalmente soluções como User and Entity Behavior Analytics (UEBA) e Endpoint Detect and Response (EDR), fundamentais para monitorar e detectar comportamentos anômalos, reforçando a segurança do Active Directory e mitigando o risco de ataques como esse.