Golden dMSA: O que é o desvio de autenticação dMSA?

Principais conclusões

• O investigador de segurança da Semperis, Adi Malyanker, encontrou uma falha de conceção crítica nas contas de serviços geridos delegados (dMSAs) introduzidas no Windows Server 2025.
• Como a falha simplifica muito a geração de senhas de força bruta, explorá-la é de baixa complexidade.
• O ataque Golden dMSA permite que os atacantes contornem a autenticação e gerem senhas para todos os dMSAs e gMSAs e suas contas de serviço associadas.
• A deteção da atividade do Golden dMSA requer a configuração manual do registo e a auditoria, o que dificulta a mitigação.
• Os investigadores da Semperis classificam esta vulnerabilidade como MODERADA porque, para a explorar, os atacantes têm de possuir uma chave de raiz KDS disponível apenas para as contas com mais privilégios: Admins. do Domínio raiz, Admins. da Empresa e SYSTEM.
• No entanto, este ataque pode ter um impacto elevado, permitindo o movimento lateral entre domínios e o acesso persistente a todas as contas de serviços geridos e aos seus recursos indefinidamente.

O Windows Server 2025 da Microsoft oferece inovações de segurança significativas, incluindo a introdução de contas de serviço gerido delegadas (dMSAs) concebidas para revolucionar a gestão de contas de serviço. Ao contrário das contas estáticas baseadas em palavras-passe que podem ser vítimas de ataques Kerberoasting, as dMSAs associam a autenticação diretamente a máquinas autorizadas no Active Diretory (AD).

Esta abordagem centrada na máquina elimina o roubo de credenciais ao associar a autenticação à identidade do dispositivo e não às palavras-passe geridas pelo utilizador. Somente máquinas explicitamente autorizadas podem acessar o dMSA.

Este artigo revela um novo ataque contra Managed Service Accounts delegadas, denominado ataque Golden DMSA. A técnica permite que os atacantes contornem a autenticação gerida por máquina pretendida e gerem palavras-passe para todas as dMSAs associadas offline.

O que é a Golden dMSA?

O Golden dMSA é um método de persistência e escalonamento de privilégios que permite que os invasores gerem senhas para todos os dMSAs - e contas de serviço gerenciado de grupo (gMSAs) - e suas contas de serviço associadas.

O ataque aproveita uma falha de conceção crítica: uma estrutura utilizada para o cálculo da geração de palavras-passe contém componentes previsíveis baseados no tempo com apenas 1024 combinações possíveis, tornando a geração de palavras-passe de força bruta computacionalmente trivial.

Este ataque pode ser utilizado tanto para persistência como para aumento de privilégios em qualquer ambiente AD com contas dMSA. A Semperis classifica esta vulnerabilidade como de risco moderado porque a sua execução depende do comprometimento parcial da floresta.

Continue lendo para saber como descobrimos a vulnerabilidade que permite o Golden dMSA, os detalhes que encontramos por trás da falha de design,
e como você pode detetar e mitigar a atividade de desvio de autenticação.

Como é que um ataque Golden dMSA funciona?

Depois de um atacante ganhar privilégios elevados dentro de um domínio, pode comprometer sistematicamente todas as contas dMSA e gMSA através de um ataque simples de quatro fases.

Fase 1: Extração do material da chave raiz do KDS (pré-requisito para o ataque). O atacante extrai material criptográfico da chave raiz do Key Distribution Services (KDS) - a base para todas as senhas de contas de serviços gerenciados.

Fase 2: Enumerar contas dMSA. Na fase 1, o utilizador SYSTEM ou Administrador de Domínio não tem permissões para enumerar dMSAs noutros domínios. Nesta segunda fase, o atacante tenta, por força bruta ou utilizando LDAP, descobrir dados como sAMAccountName atributos e identificadores de segurança (SIDs) em contas dMSA na floresta AD.

Fase 3: Adivinhando o ManagedPasswordID. Em seguida, o atacante tenta identificar a ManagedPasswordId hashes de atributos e palavras-passe através de adivinhação direcionada.

Fase 4: Geração de senhas. Usando ferramentas especializadas como o GoldenDMSA, o atacante pode gerar senhas válidas para qualquer gMSA ou dMSA associado à chave comprometida.

Este processo não requer qualquer acesso privilegiado adicional, uma vez obtida a chave de raiz do KDS, o que o torna um método de persistência particularmente perigoso.

O ataque realça o limite crítico de confiança das contas de serviços geridos. Estas dependem de chaves criptográficas ao nível do domínio para segurança. Embora a rotação automática de senhas forneça excelente proteção contra ataques típicos de credenciais, os administradores de domínio, administradores de DNS e operadores de impressão podem ignorar totalmente essas proteções e comprometer todos os dMSAs e gMSAs na floresta.

O que são as dMSA? Um breve historial da conta de serviço

Durante décadas, os administradores do Windows utilizaram contas de domínio normais para executar serviços - uma abordagem funcional, mas com falhas, que evoluiu com a introdução das contas de serviço. Ao contrário das contas de utilizador interactivas que representam pessoas reais, as contas de serviço existem apenas para fornecer um contexto de identidade para processos automatizados.

As primeiras contas de serviço dependiam de senhas estáticas que criavam pesadelos operacionais. A coordenação das alterações de palavra-passe entre várias equipas, serviços e aplicações conduzia frequentemente a interrupções e à resistência às melhores práticas de segurança.

Pior ainda, as palavras-passe estáticas permitiam ataques devastadores. As explorações Kerberoasting permitem que os atacantes solicitem bilhetes de serviço e descodifiquem palavras-passe offline, enquanto as credenciais fracas ou inalteradas proporcionam alvos fáceis para o aumento de privilégios.

Desde então, a Microsoft criou diferentes versões de contas de serviço.

• Contas de serviço geridas (MSAs). O Windows Server 2008 R2 introduziu a rotação automática da palavra-passe de 240 caracteres a cada 30 dias, juntamente com a gestão automática do nome principal de serviço (SPN). O senão? As MSAs estão limitadas a máquinas individuais.
• Contas de serviço gerenciadas por grupo (gMSAs). O Windows Server 2012 resolveu a limitação de várias máquinas, permitindo identidades de serviço partilhadas em clusters, equilibradores de carga e serviços distribuídos, mantendo as vantagens de segurança da MSA.
• Contas de serviço gerido delegadas (dMSAs). A mais recente inovação do Windows Server 2025 passa da gestão centralizada de palavras-passe para a autenticação ligada à máquina, representando uma mudança fundamental na segurança da conta de serviço.

Esta evolução das contas tradicionais para a gMSA e para a dMSA cria uma superfície de ataque interessante - uma superfície que a técnica Golden dMSA explora aproveitando a base criptográfica partilhada entre os sistemas gMSA e dMSA.

Como é que os atacantes encontram os dMSAs: Quebrando a barreira da invisibilidade

Do ponto de vista de um atacante, a capacidade de enumerar dMSAs como um utilizador sem privilégios é crucial para a escalada de privilégios e movimento lateral. Para obter a palavra-passe de um dMSA, é necessário saber o seu nome e SID.

No entanto, um dos desafios mais intrigantes quando se lida com dMSAs é encontrar estas contas esquivas em primeiro lugar.

De acordo com a documentação da Microsoft, para criar dMSAs, começamos com o CreateDelegatedServiceAccount comando que Figura 1 espectáculos.

Agora vem a parte divertida. Vamos tentar exibir nossa conta DMSA-Demo recém-criada usando Get-ADServiceAccount (Figura 2).

É aqui que encontramos o nosso primeiro obstáculo. Um utilizador privilegiado pode ver a conta sem problemas, mas um utilizador não privilegiado não obtém absolutamente nada - resultados vazios(Figura 3). Porquê? Tudo se resume às predefinições nas listas de controlo de acesso (ACLs) da conta. E, acredite, nenhum administrador quer mexer nelas.

Reparou em algo suspeito na Figura 4? Tanto os utilizadores autenticados como Todos estão completamente impedidos de ler quaisquer dados nestas contas.

Então, como é que um utilizador não privilegiado pode aceder a informações sobre contas dMSA?

É aqui que começa o trabalho de detetive. Após inúmeras investigações e tentativas falhadas, descobri que podemos construir uma lista de potenciais SIDs e traduzir cada um deles para objectos NTAccount. (Usei C# para essa mágica).

Por baixo do capô, a função translate aproveita estas poderosas APIs Win32: LsaOpenPolicy e LsaLookupSids (Figura 5).

Os nomes das funções revelam o seu objetivo, mas a Figura 6 mostra a documentação oficial da Microsoft para tornar tudo muito claro.

Curiosamente, uma ferramenta do Impacket chamada lookupsid¹ utiliza exatamente a mesma técnica, empregando hLsarOpenPolicy2 e hLsarLookupSids para enumerar SIDs.

Agora a parte emocionante: Vamos ver o que acontece quando libertamos estas funções Win32(Figura 7).

Jackpot! Recuperámos todas as contas do domínio, bem como outros objectos com SIDs.

Esse método é bem-sucedido porque ignora completamente o LDAP, contornando efetivamente essas ACLs restritivas. Aqui está a beleza técnica: LsaLookupSids e LsaOpenPolicy não dependem de todo do LDAP. Em vez disso, o protocolo LSA comunica através de \PIPE\lsarpc como o ponto de extremidade RPC sobre SMB.

Mas espere - como podemos identificar quais contas dessa lista enorme são dMSAs?

Aqui está a parte inteligente: Marcamos todas as contas que terminam em $ como suspeitas. Depois eliminamos sistematicamente as contas de máquinas e gMSAs.

Pronto! Ficamos com um inventário completo de todos os dMSAs no domínio.

Reviravolta: Esta técnica também funciona para além dos limites do domínio! Podemos enumerar dMSAs de outros domínios utilizando exatamente o mesmo método.

Aqui está uma descoberta bónus.

Graças aos meus colegas Andrea Pierini e Shai Laronne, descobrimos uma abordagem alternativa baseada em LDAP(Figura 8).

O segredo? Quando iniciamos a pesquisa diretamente a partir do próprio contentor, podemos procurar estes tipos de conta específicos. Combinado com o nosso método anterior de enumeração de SID, podemos extrair a informação SID enquanto filtramos as gMSAs e as contas de computador(Figura 9).

Esta abordagem dupla dá-nos vários vectores de ataque para a descoberta do dMSA - um fator de mudança para qualquer avaliação de segurança.

Porque é que a chave de raiz KDS é fundamental para os ataques Golden dMSA?

Introduzida pela primeira vez no Windows Server 2012, a chave raiz KDS é a joia da coroa da infraestrutura gMSA da Microsoft. Pense nela como o cérebro criptográfico por trás do Serviço de Distribuição de Chaves da Microsoft, o mecanismo que gera e distribui senhas para gMSAs.

A obtenção desta chave de raiz é o primeiro passo crítico na cadeia de ataque, pois permite que os atacantes calculem as palavras-passe de qualquer gMSA no domínio offline. Esta capacidade é devastadora porque as gMSAs são concebidas para que as suas palavras-passe sejam automaticamente rodadas pelo controlador de domínio (DC), fazendo com que pareçam seguras para os administradores. No entanto, com a chave de raiz do KDS na mão, um atacante pode derivar matematicamente a palavra-passe atual de qualquer conta gMSA sem nunca mais se ligar ao DC.

Eis o que a torna tão poderosa: A chave raiz do KDS funciona como a chave mestra definitiva. A partir dela, todas as senhas gMSA são derivadas através de um elegante processo de derivação de chaves.

Mas há mais. A Microsoft expandiu recentemente a chave de raiz KDS para controlar as contas dMSA.

Agora, a chave de raiz KDS é duas vezes mais valiosa para os atacantes, uma vez que desbloqueia as palavras-passe gMSA e dMSA.

A chave de raiz do KDS reside normalmente no DC de raiz da floresta - o local mais protegido do AD. A Microsoft não estava a brincar com a segurança aqui. As ACLs nestas chaves são incrivelmente restritivas(Figura 10), limitando o acesso apenas às contas mais privilegiadas: Admins. do Domínio raiz, Admins. da Empresa e SYSTEM.

No entanto, apesar destas restrições rígidas, estas preciosas chaves ainda podem ser recuperadas de outros DCs em toda a floresta, mas apenas com acesso ao nível SYSTEM(Figura 11).

Nesta altura, poderá pensar que ter permissões SYSTEM num DC diminui a capacidade de exploração do Golden dMSA. No entanto, este é um único DC de toda a floresta, e o fluxo de ataque muda fundamentalmente o cenário de ameaças de um comprometimento localizado para um backdoor persistente em toda a floresta.

Isso significa que, embora o acesso SYSTEM em um DC já represente uma violação significativa, a técnica Golden dMSA transforma essa violação em uma ameaça muito mais perigosa e duradoura, permitindo que o invasor mantenha o acesso persistente a gMSAs, dMSAs e suas contas de serviço associadas em toda a floresta - sem exigir presença contínua no DC comprometido.

Preste muita atenção a este pormenor crítico: As chaves de raiz KDS não têm data de expiração

A recomendação da Microsoft é manter apenas uma chave de raiz KDS por ambiente.

Faça as contas aqui. Teoricamente, depois de comprometer uma única chave de raiz KDS, um atacante poderia potencialmente gerar palavras-passe para todas as futuras contas dMSA e gMSA indefinidamente.

Eu descobri algo ainda mais intrigante durante minha pesquisa. Mesmo em ambientes com várias chaves de raiz KDS, o sistema utiliza consistentemente a primeira (mais antiga) chave de raiz KDS por motivos de compatibilidade. Isto significa que a chave original que comprometemos pode ser preservada pelo design da Microsoft - criando uma backdoor persistente que pode durar anos.

Esta decisão arquitetónica transforma uma única extração de chave bem sucedida numa vantagem estratégica a longo prazo para os atacantes, tornando a chave de raiz KDS um dos alvos mais valiosos em qualquer domínio Windows.

Decifrar o código: Da gMSA à geração de palavras-passe dMSA

Agora estamos a mergulhar no coração do ataque - extraindo os dados do dMSA ManagedPasswordId atributo.

ManagedPasswordId é um atributo armazenado no AD que contém os metadados necessários para derivar a palavra-passe atual de um MSA. Precisamos de adquirir este atributo porque contém os parâmetros criptográficos essenciais - incluindo o identificador de chave, a hora de criação e outros detalhes de derivação - que funcionam em conjunto com a chave de raiz KDS para calcular matematicamente a palavra-passe atual do gMSA.

Se isto lhe soa familiar, tem toda a razão. A excelente investigação de Yuval Gordon sobre Ataques ao Active Directory do gMSA apresentou ao mundo Golden gMSA. Essa técnica de ataque envolve a extração da chave de raiz KDS do AD, a consulta dos gMSAs disponíveis juntamente com o seu SID e ManagedPasswordId e calcular as palavras-passe a partir dos dados.

Ao investigar a Golden dMSA, a minha hipótese era simples mas poderosa: A Microsoft poderia ter reciclado o mesmo código da gMSA para a dMSA para a criação e renovação de senhas. Mas será que poderíamos de facto reproduzir o ataque Golden gMSA contra contas dMSA?

É aqui que encontramos o nosso primeiro grande obstáculo. Essas ACLs restritivas que descobrimos anteriormente nos impedem completamente de ler esses dados críticos nas contas dMSA. Precisávamos de ir mais fundo e expandir o nosso algoritmo.

Engenharia reversa da estrutura ManagedPasswordId

Para decifrar este puzzle, comecei a investigar a ManagedPasswordId estrutura em si. Criei uma nova conta dMSA e extraí a sua ManagedPasswordID atributo.

Depois de analisar a matriz de bytes e compará-la em diferentes instâncias, descobri que ela contém os componentes que a Figura 12 mostra.

Esta estrutura parece-me familiar. É praticamente idêntica à da gMSA ManagedPasswordID formato (Figura 13).

A figura 14 mostra a repartição completa desta estrutura, com os seguintes componentes principais:

• Versão: Valor inteiro com valor decimal (1,0,0,0)
• Reservado: Valor inteiro com valor decimal de (75, 68, 83, 75)
• isPublicKey: Valor inteiro com valor decimal (2,0,0,0)
• L0Index: Valor inteiro que representa uma variável de tempo (exploraremos isto mais tarde)
• L1Index: Valor inteiro que representa uma variável de tempo (exploraremos isto mais tarde)
• L2Index: Valor inteiro que representa uma variável temporal (exploraremos isto mais tarde)
• RootKeyIdentifier: Valor GUID construído a partir do ID da chave de raiz do KDS.

O domínio da RootKeyIdentifier pode ser construído a partir das chaves de raiz KDS (RKL é o ID da chave de raiz KDS, ou seja, f06c3c8d-b2c2-4cc6-9a1a-8b3b3c82b9f0), como Figura 15 espectáculos.

• cbUnknown: Valor inteiro com valor decimal (0, 0, 0, 0, 0)
• cbDomainName: Valor inteiro que representa (comprimento do nome de domínio * 2) + 2.
• cbForestName: Valor inteiro que representa (comprimento do nome da floresta * 2) + 2.
• Nome do domínio: Nome de domínio da conta dMSA neste formato especial
• ForestName: Nome da floresta da conta dMSA neste formato especial

Repare em algo no cbDomainName e cbForestName: Multiplicamos por 2 e adicionamos 2 porque os bytes ASCII com valor 0 são inseridos entre cada carácter. Assim, root.test torna-se r.o.o.t…t.e.s.t.. na estrutura atual.

Ao estudar o Artigo do Microsoft Learn sobre msDS-ManagedPassword e o fornecedor KDS da Microsoft KdsCli.dll (que implementa a maior parte da lógica da palavra-passe), tracei o fluxo a partir de GetgMSAPasswordBlob(), como Figura 16 espectáculos.

A lógica é elegante. Quando o ManagedPasswordId não existir ou expirar, o sistema estabelece uma nova hora de início e chama GetPasswordBasedOnTimestamp(), como Figura 17 espectáculos.

Este facto leva-nos a uma das observações mais significativas da nossa investigação. Os valores L0, L1 e L2 são gerados em GetIntervalID()e, em seguida, passa para GetKey() ao construir uma nova chave BLOB (Figura 18).

A partir desta observação, descobri algo crucial: Os valores L1 e L2 estão limitados a 31 (inclusive). Isto não é apenas teoria; é confirmado tanto na DLL (Figura 19) e a Microsoft GetKey() documentação (Figura 20).

O GetPasswordBasedOnTimestamp() também será chamado quando uma renovação do método ManagedPasswordId é necessário.

A descoberta revolucionária

Agora vem a revelação que muda o jogo.

Podemos prever a maior parte do que o ManagedPasswordID vetor necessário para calcular as palavras-passe gMSA e dMSA. Sabemos que L1Index e L2Index estão limitados a valores que podemos obter por força bruta. O principal desafio parece ser L0Indexque, sendo um número inteiro de 4 bytes, pode ter milhares de milhões de valores potenciais.

Ao aprofundar o algoritmo do Golden gMSA, descobri que ele cria estes objectos:

• L0Keyque contém atributos da chave de raiz KDS (Figura 21)
• L0KeyIdcalculada a partir da hora atual
• GenerateKDFContext e GenerateDerivedKey, que derivam L1Key e L2Key vectores de bytes uma vez (Figura 21) ou um par de vezes (Figura 22)

Aqui está a visão crítica.

• L0Keyid, L1Keyide L2Keyid são inteiramente baseados no tempo e independentes do utilizador (como Figura 19 acima mostra).
• O único valor controlado pelo utilizador é o ManagedPasswordId que fornecemos juntamente com a chave de raiz KDS, os nomes de domínio e de floresta e o SID.

Foi aqui que tudo fez clique. Quando eu rastreei onde L0Index (do ManagedPasswordId) é efetivamente utilizado no algoritmo, encontrei as revelações de que Figura 23 e Figura 24 espetáculo.

Este é um pormenor espantoso. L0index não é utilizado de todo a partir do MsdsManagedPasswordId o que significa que é indiferente o valor que utilizamos.

Adivinhação de palavras-passe: Juntando tudo

Podemos agora construir quase todo o ManagedPasswordId o vetor - a peça final necessária para prever as palavras-passe e hashes gMSA e dMSA. Uma vez que L0Index é ignorado, e L1Index e L2Index deve estar entre 0-31 (inclusive), temos apenas 32 × 32 = 1024 vectores possíveis para testar.

Testei esta conclusão calculando a palavra-passe correta e o hash NTLM para cada vetor, depois tentei ataques Pass the Hash usando o ^smbclient2 do Impacket(Figura 25).

Sucesso! Este método funcionou na perfeição para as contas gMSA. Conseguimos prever os seus hashes em 1.024 tentativas, sem necessitar da informação específica ManagedPasswordId.

Mas, mesmo assim, não consegui passar o hash com o hash da palavra-passe do dMSA. Além disso, precisávamos de perguntar como poderíamos aproveitar este ataque quando os ataques Pass the Hash são mitigados a partir deste domínio.

Depois de examinar os atributos de um dos meus dMSAs, vi que requer ligação com o tipo de encriptação AES 256 do Kerberos, como mostra a Figura 26 . (Recorda-se que segui a recomendação da Microsoft para impor o AES 256 ao criar um dMSA).

Tentei gerar um hash AES 256 a partir da senha do serviço. Após algumas tentativas exaustivas, descobri que os gMSAs e dMSAs usam um formato de sal ligeiramente diferente para o hashing AES 256:

<Domain name in UPPER case>host<user's full UPN in lower case (without $)>

Por exemplo:

ROOT.TESThostdmsa-demo8.root.test

Com este formato de sal, pude finalmente gerar bilhetes Kerberos válidos para contas dMSA.

Mapeamento do fluxo de ataque do Golden dMSA

O diagrama da Figura 27 resume o ataque Golden dMSA.

1. Comece com privilégios SYSTEM num dos DCs do domínio ou com privilégios Enterprise Admin para descarregar as chaves de raiz do KDS.
2. Força bruta dos SIDs das contas dMSA ou utiliza consultas LDAP para identificar contas alvo.
3. Criar uma lista de palavras contendo todas as 1024 possíveis ManagedPasswordIds para este utilizador específico.
4. Calcular a palavra-passe para cada par possível (chaves de raiz KDS), ManagedPasswordIds) e fazer o hash para NTLM/AES256.
5. Teste cada hash de palavra-passe através das técnicas Passar o Hash ou Ultrapassar o Hash.

Este ataque transforma as contas dMSA de alvos aparentemente impenetráveis em desafios de força bruta gerenciáveis, exigindo apenas 1.024 tentativas para quebrar qualquer senha dMSA no domínio.

Como é que um ataque Golden dMSA contorna a autenticação normal

Na sua documentação, a Microsoft afirma que "o segredo da dMSA não pode ser recuperado ou encontrado noutro local que não o DC", destacando uma diferença fundamental entre os mecanismos de autenticação gMSA e dMSA. Com as gMSAs, o processo é simples. Uma entidade autentica-se e solicita diretamente as credenciais da gMSA (palavra-passe), recebendo depois a palavra-passe real para efeitos de autenticação.

Os dMSAs operam com um princípio totalmente diferente. Têm de se autenticar utilizando a identidade da máquina para obter um bilhete para o utilizador dMSA. A senha do dMSA nunca deixa o DC. Em vez disso, é utilizada para encriptar o bilhete que é devolvido ao computador requerente.

Para evitar casos em que um invasor rouba o hash do computador e o usa para solicitar um tíquete, a Microsoft recomenda o uso do Credential Guard. Essa atenuação cria uma barreira robusta que deve interromper a maioria dos ataques de roubo de credenciais em seu caminho.

Mas é aqui que o ataque do Golden dMSA muda tudo. O Golden dMSA contorna completamente as proteções normais do Credential Guard(Figura 28). Já não estamos a seguir as regras normais de autenticação.

Em vez de seguir o fluxo de autenticação pretendido pela Microsoft, as credenciais dMSA são utilizadas diretamente através do ataque criptográfico(Figura 29). Isto significa que:

• Não é necessária a identidade da máquina. Não precisamos de comprometer a máquina anfitriã.
• A Proteção de Credenciais torna-se irrelevante. Uma vez que não estamos a roubar credenciais de máquinas, esta proteção não oferece qualquer defesa.

A Microsoft reconheceu que, "A partir da atualização de segurança do Windows de abril(KB5055523), as contas de computador protegidas pelo Credential Guard estão temporariamente desactivadas no Windows Server 2025 e no Windows 11, versão 24H2. Esta funcionalidade foi desactivada devido a um problema com a rotação de palavras-passe de máquina utilizando o Kerberos. A funcionalidade permanece desactivada até estar disponível uma correção permanente."

Qual é o verdadeiro risco da Golden dMSA? Devastação de toda a floresta

Uma vez que um atacante tenha comprometido com sucesso uma conta dMSA usando a técnica Golden dMSA, a verdadeira diversão começa. Não se trata apenas de obter acesso a uma conta de serviço. Trata-se de aproveitar esse ponto de apoio para um movimento lateral devastador. Além disso, essa técnica permite que os invasores decifrem senhas e obtenham permissões de contas de serviço que iniciaram e concluíram migrações para o dMSA comprometido.

É aqui que o ataque se torna verdadeiramente aterrador do ponto de vista da segurança. O ataque Golden dMSA não é limitado por fronteiras de domínio. Funciona ao nível da floresta. Uma vez que comprometemos a chave raiz KDS de qualquer domínio dentro da floresta, podemos sistematicamente visar e comprometer cada conta dMSA em todos os domínios dessa floresta.

Isto significa que uma única extração de chave de raiz KDS bem sucedida se transforma em:

• Compromisso de contas entre domínios. Nenhum limite de domínio pode deter-nos.
• Recolha de credenciais em toda a floresta. Cada dMSA em cada domínio torna-se vulnerável.
• Movimento lateral ilimitado. Podemos saltar entre domínios à vontade utilizando contas dMSA comprometidas.
• Acesso persistente. Sem expiração nas chaves KDS, este acesso pode durar indefinidamente.

O ataque é escalonado exponencialmente. O que começa com o comprometimento de um DC, passa a controlar todos os serviços protegidos por dMSA em toda uma floresta corporativa. Não se trata apenas de uma escalada de privilégios. É o domínio digital de toda a empresa através de uma única vulnerabilidade criptográfica.

O que é a ferramenta Golden dMSA?

Para saber como esta técnica de ataque é explorada, pegámos na lógica do ataque e incluímo-la numa ferramenta chamada ^GoldenDMSA3. A ferramenta incorpora os princípios estruturais da ferramenta GoldenGMSA^.4

Um atacante pode usar a ferramenta GoldenDMSA para enumerar todos os gMSAs, dMSAs e as suas chaves de raiz KDS associadas, usar ataques de força bruta para obter as suas palavras-passe e obter bilhetes para as contas. Um atacante com privilégios elevados pode também utilizar a ferramenta GoldenDMSA para descarregar as chaves de raiz do KDS.

Para demonstrar a ferramenta em ação, vejamos uma exploração entre domínios numa floresta.

Para começar, o atacante senta-se num domínio chamado child.root.test (Figura 30) e tenta obter dMSAs de root.test (Figura 31).

Em seguida, o atacante deve criar uma lista de palavras (Figura 32) que será utilizado para o ManagedPasswordIds ataque de força bruta.

Finalmente, lançaremos um ataque de força bruta com a ajuda da lista de palavras(Figura 33).

A palavra-passe é codificada em Base64(Figura 34) porque pode incluir caracteres não imprimíveis. Para testar a validade do ticket, criei um novo usuário - oculto no DC raiz - que somente a conta dMSA poderia ler. Se conseguirmos ler com êxito os dados do utilizador, sabemos que o nosso bilhete gerado é válido.

Como detetar a Golden dMSA: Descobrir indicadores ocultos

Por padrão, nenhum evento de segurança é registrado quando uma chave raiz do KDS é comprometida. Para detetar ataques Golden dMSA, os defensores devem configurar manualmente uma SACL (Lista de Controlo de Acesso ao Sistema) nos objectos de chave de raiz do KDS para auditar o acesso de leitura à msKds-RootKeyData atributo.

Para o fazer, abra a ferramenta Interface do Editor do Active Diretory (ADSI Edit) e:

• Selecionar o contexto de nomeação Configuração
• Navegue até Serviços e clique em Serviço de distribuição de chaves de grupo
• Selecione Master Root Keys e clique com o botão direito do rato na chave de raiz KDS relevante
• Aceda ao separador Segurança, clique no botão Avançadas
• Selecione o separador Auditoria e configure uma regra de auditoria para o acesso de leitura em Utilizadores autenticados/Todos

Quando este SACL está em vigor, qualquer tentativa não autorizada de extrair dados da chave de raiz do KDS accionará o evento de segurança 4662 no DC (Figura 35). Este evento mostrará um tipo de objeto de msKds-ProvRootKey e um nome de conta que não é um DC, o que indica uma potencial atividade maliciosa.

Novo indicador de segurança DSP ajuda na deteção do Golden dMSA

Como se pode ver, a deteção manual do comprometimento da chave raiz do KDS é um desafio para a maioria das equipas. A Semperis forneceu um novo módulo de Proteção de Contas de Serviço, um aprimoramento dos recursos do Directory Services Protector DSP). O módulo inclui um indicador de segurança chamado KDS root key ACL was modified, que procura modificações de ACL nas chaves raiz do KDS(Figura 36) que poderiam permitir que os invasores lessem essas chaves e lançassem um ataque Golden dMSA.

Pistas adicionais a que estar atento

Além disso, os defensores devem:

• Monitorização de volumes anormais de pedidos de autenticação AS-REQ que visem a mesma conta de serviço (identificável por contas terminadas em $), nomeadamente quando seguidas de PREAUTH-FAILED (código de erro 24) respostas. Este padrão pode indicar uma tentativa de ataque Overpass the Hash.
• Procure pedidos anormais de Ticket-Granting Ticket (TGT) de contas dMSA, especialmente quando lançados por contas de utilizador.

Instantâneo da Semperis

O ataque Golden dMSA tira partido de uma vulnerabilidade criptográfica que pode minar a mais recente inovação de segurança da Microsoft no Windows Server 2025. Esta técnica explora a base arquitetónica das Contas de Serviço Gerido delegadas. O ataque tira partido de uma falha de conceção crítica: a ManagedPasswordId contém componentes previsíveis baseados no tempo com apenas 1.024 combinações possíveis, tornando a geração de palavras-passe de força bruta computacionalmente trivial.

O que torna esta situação particularmente devastadora é o seu alcance em toda a floresta. Uma única extração de chave bem sucedida permite o movimento lateral entre domínios e o acesso persistente a todas as contas de serviço geridas e respectivos recursos indefinidamente, uma vez que as chaves de raiz KDS não têm data de validade. A vulnerabilidade transforma a tecnologia de conta de serviço mais segura da Microsoft numa potencial porta traseira para toda a empresa, contornando protecções modernas como o Credential Guard e desafiando fundamentalmente os benefícios de segurança assumidos da autenticação ligada à máquina.

Divulgação

O problema foi inicialmente comunicado ao Centro de Resposta de Segurança da Microsoft (MSRC) em 27 de maio de 2025.

Em 8 de julho de 2025, a Microsoft respondeu em parte: "Se tiver os segredos utilizados para derivar a chave, pode autenticar-se como esse utilizador. Estas funcionalidades nunca se destinaram a proteger contra o comprometimento de um controlador de domínio."

Saiba mais sobre as ameaças às contas de serviços geridos

• BadSuccessor: Como detetar e mitigar a escalada de privilégios do dMSA
• Como bloquear o BadSuccessor
• Ataques ao Active Directory do gMSA

Notas finais

1. https://github.com/fortra/impacket/blob/master/examples/lookupsid.py
2. https://github.com/fortra/impacket/blob/master/examples/smbclient.py
3. https://github.com/Semperis/GoldenDMSA/tree/main
4. https://github.com/Semperis/GoldenGMSA

Declaração de exoneração de responsabilidade

Este conteúdo é fornecido apenas para fins educacionais e informativos. Destina-se a promover a consciencialização e a correção responsável das vulnerabilidades de segurança que possam existir nos sistemas que possui ou que está autorizado a testar. O uso não autorizado dessas informações para fins maliciosos, exploração ou acesso ilegal é estritamente proibido. A Semperis não endossa ou tolera qualquer atividade ilegal e se isenta de qualquer responsabilidade decorrente do uso indevido do material. Além disso, a Semperis não garante a exatidão ou a integridade do conteúdo e não assume qualquer responsabilidade por quaisquer danos resultantes da sua utilização.