BadSuccessor dMSA Privilege Escalation: como um usuário com poucos privilégios se torna Domain Admin

BadSuccessor dMSA privilege escalation — batizada de BadSuccessor pela Akamai — é uma técnica que abusa das Delegated Managed Service Accounts (dMSA), um recurso introduzido no Windows Server 2025, para permitir que um usuário com poucos privilégios se passe por qualquer conta do domínio, até Domain Admin. Foi documentada pelo pesquisador da Akamai Yuval Gordon em maio de 2025 e recebeu o identificador CVE-2025-53779; a Microsoft lançou uma correção na atualização de segurança de 12 de agosto de 2025 (KB5064010).

Este artigo explica o mecanismo, por que ele afeta uma parcela tão grande de ambientes reais, e como detectá-lo e corrigi-lo — incluindo o que o patch realmente mudou e o que a pesquisa pública diz que ainda vale a pena observar depois.

Para caminhos de escalonamento do Active Directory relacionados, veja Delegação Kerberos não restrita: do abuso ao RBCD e Abuso de ACL e DCSync: os caminhos silenciosos até Domain Admin. O BadSuccessor é um mecanismo distinto de ambos — ele não toca na ACL nem nas configurações de delegação de uma conta existente; ele abusa dos direitos de criação de objetos em uma OU para fabricar um novo. Também compartilha um ar de família com Shadow Credentials: abuso de msDS-KeyCredentialLink no Active Directory — ambas as técnicas escalam privilégios escrevendo em um atributo de vinculação de identidade em vez de quebrar uma credencial.

O que é BadSuccessor dMSA Privilege Escalation?

As Delegated Managed Service Accounts (dMSA) são um recurso do Windows Server 2025 projetado para permitir que organizações migrem contas de serviço legadas para um modelo de identidade gerenciado e sem senha, sem precisar reprovisionar cada dependência. Parte desse design de migração inclui um mecanismo de "sucessão": um dMSA pode ser vinculado a uma conta mais antiga que ele deve substituir, e o Active Directory transfere parte do acesso dessa conta durante a transição.

Por que o dMSA existe

A Microsoft projetou o dMSA para resolver um problema operacional real: contas de serviço autônomas legadas costumam carregar senhas estáticas, raramente rotacionadas, e privilégios amplos e permanentes, porque migrar para um modelo de identidade gerenciado tradicionalmente significava reprovisionar cada aplicação dependente. O modelo de sucessão do dMSA — vincular a nova conta gerenciada à antiga que ela substitui — visava tornar essa migração quase transparente. O BadSuccessor abusa da confiança embutida nessa transparência, não de um bug no tratamento de senhas em si.

O mecanismo do BadSuccessor

Segundo a pesquisa original da Akamai (corroborada pela Unit 42, Semperis e Tarlogic), o ataque abusa de dois atributos do dMSA nos quais o KDC confia sem verificação cruzada durante a "migração" que representam:

• msDS-ManagedAccountPrecededByLink — um vínculo (DN, distinguished name) com a conta que o dMSA deve "suceder". A pesquisa pública descreve o KDC anterior ao patch como alguém que constrói o PAC (Privilege Attribute Certificate) da conta a partir de qualquer DN presente nesse campo, sem verificar se existe de fato uma relação de migração.
• msDS-DelegatedMSAState — o estado de migração (0 = nenhum, 1 = em andamento, 2 = concluído).

Passo a passo: como o ataque funcionava antes do patch

1. O invasor identifica uma OU ou contêiner onde possui direitos CreateChild — segundo os testes da Akamai, uma permissão ao mesmo tempo comum e raramente auditada em detalhe.
2. O invasor cria um novo objeto dMSA nessa OU.
3. O invasor grava o DN da conta alvo (por exemplo, um Domain Admin) em msDS-ManagedAccountPrecededByLink.
4. O invasor define msDS-DelegatedMSAState como 2 ("concluído"), marcando a migração fabricada como finalizada.
5. A pesquisa pública descreve que o KDC anterior ao patch então tratava toda autenticação subsequente como o dMSA como se fosse uma continuação da identidade da conta alvo — construindo o PAC com os SIDs e associações de grupo do alvo, sem que a conta alvo fosse modificada em nenhum momento.

Os testes da Akamai relataram que 91% dos ambientes examinados tinham pelo menos um usuário não administrador com permissões suficientes para realizar esse ataque, em grande parte porque a delegação CreateChild em nível de OU é comum e raramente auditada em detalhe.

Impacto do patch de agosto de 2025

A atualização de 12 de agosto de 2025 da Microsoft (KB5064010, CVE-2025-53779) mudou a forma como o kdcsvc.dll valida a relação de sucessão: a emissão de tickets agora exige que o vínculo reflita um pareamento mútuo genuíno, em vez de aceitar uma gravação unilateral em msDS-ManagedAccountPrecededByLink. Simplesmente apontar um dMSA recém-criado para uma conta privilegiada, como descrito acima, não produz mais um ticket de personificação após a atualização.

A avaliação de severidade da Microsoft

O MSRC inicialmente avaliou o problema relatado como não atingindo o limiar para uma correção imediata e o classificou como de severidade moderada quando a Akamai o relatou pela primeira vez; ele foi entregue como uma correção regular no ciclo de Patch Tuesday de agosto de 2025, em vez de como um lançamento fora de banda. A avaliação atual da Microsoft classifica a exploração como "menos provável", e os relatos públicos não descrevem exploração confirmada em ambiente real até a data de publicação.

O que a pesquisa diz sobre o patch

A própria pesquisa de acompanhamento da Akamai ("BadSuccessor Is Dead, Long Live BadSuccessor(?)") e um artigo posterior da comunidade publicado pela AlteredSecurity ("BetterSuccessor") descrevem ambos o patch como o fechamento do caminho direto de vínculo unilateral, ao mesmo tempo em que observam que a pesquisa sobre abuso de dMSA continuou em cenários mais restritos. Este artigo não reproduz essas técnicas derivadas; considere que o patch fecha substancialmente — não necessariamente por completo — o caminho original do BadSuccessor, e priorize as etapas de detecção e fortalecimento da delegação abaixo, independentemente do status do patch.

Por que é tão difundido

O BadSuccessor é incomum entre as técnicas de escalonamento de privilégios do AD porque não exige uma configuração incorreta no sentido tradicional. Ele funciona contra o modelo de permissões padrão do dMSA assim que um DC Windows Server 2025 existe no domínio. A exposição real vem de quão amplamente os direitos CreateChild em OUs e contêineres costumam ser delegados em ambientes reais — muitas vezes para equipes de suporte, equipes de aplicações, ou delegações legadas nunca revisadas. A pesquisa pública da Semperis e da Unit 42 aponta ambas para a mesma causa raiz: práticas de delegação de OU e da raiz do domínio mais amplas do que o pretendido, não um único patch ausente.

Isso se conecta diretamente a um padrão tratado em Caminhos de ataque do AD: más configurações em cadeia: as exposições mais perigosas quase nunca são um único bug crítico — são delegações e permissões acumuladas que ninguém revisou desde que foram configuradas.

Detecção

Correção — passos práticos

1. Aplique o patch primeiro

Aplique a atualização de segurança de 12 de agosto de 2025 (KB5064010 / CVE-2025-53779) em cada controlador de domínio Windows Server 2025.

2. Audite e restrinja a delegação CreateChild

Revise as permissões de OU e da raiz do domínio para contas e grupos que podem criar objetos — particularmente objetos msDS-DelegatedManagedServiceAccount — e remova delegações que não sejam ativamente necessárias. Esse é o controle que determina se o caminho de ataque existe, independentemente do status do patch.

3. Habilite a auditoria baseada em SACL

Configure a auditoria para criação de objetos dMSA (ID de evento 5137) e para modificações em msDS-ManagedAccountPrecededByLink / msDS-DelegatedMSAState (ID de evento 5136), e alerte sobre qualquer alteração desse tipo feita por uma conta não privilegiada.

4. Inventarie os dMSAs existentes

Confirme que cada dMSA do domínio corresponde a uma migração legítima e esperada, e revise o valor de msDS-ManagedAccountPrecededByLink de cada um.

# Inventariar todos os objetos dMSA e seu vínculo de sucessão, para revisão manual
Get-ADServiceAccount -Filter "ObjectClass -eq 'msDS-DelegatedManagedServiceAccount'" -Properties msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState |
  Select-Object Name, msDS-ManagedAccountPrecededByLink, msDS-DelegatedMSAState

Como a EtcSec detecta isso

O catálogo de vulnerabilidades de AD da EtcSec inclui uma verificação dedicada, BADSUCCESSOR_DMSA_ESCALATION, que sinaliza esse risco de escalonamento via dMSA. Como a exposição raiz é a amplitude da delegação, e não um objeto isolado mal configurado, a EtcSec também traz achados de DELEGATION_PRIVILEGE — delegações amplas em nível de OU ou de raiz do domínio — como a condição subjacente que torna o BadSuccessor viável em um determinado ambiente, independentemente de já existir ou não um DC Windows Server 2025. Equipes que já acompanham o desvio de acesso privilegiado com Desvio de acesso privilegiado no Active Directory: como direitos de administrador retornam após auditorias estão observando o mesmo problema subjacente — delegação nunca revisada — sob um ângulo diferente.

Referências principais

• Akamai: BadSuccessor — Abusing dMSA to Escalate Privileges in Active Directory
• Akamai: BadSuccessor Is Dead, Long Live BadSuccessor(?)
• Microsoft Security Update Guide: CVE-2025-53779
• NVD: CVE-2025-53779
• Help Net Security: Microsoft fixes "BadSuccessor" Kerberos vulnerability (CVE-2025-53779)
• Unit 42 (Palo Alto Networks): When Good Accounts Go Bad — Exploiting Delegated Managed Service Accounts in Active Directory
• Semperis: BadSuccessor — How to Detect and Mitigate dMSA Privilege Escalation
• Tarlogic: BadSuccessor — Escalating Privilege Using dMSA Abuse in Active Directory
• AlteredSecurity: BetterSuccessor — Still Abusing dMSA for Privilege Escalation (BadSuccessor After Patch)