Índice
Sumário executivo
- Pesquisadores da Akamai analisaram o patch da Microsoft para a vulnerabilidade conhecida como BadSuccessor (CVE-2025-53779) para avaliar sua eficácia.
- Concluímos que, embora o patch tenha sido eficaz na mitigação de uma parte significativa do risco associado ao BadSuccessor, a técnica permanece ativa e relevante em determinados cenários.
- Nesta publicação no blog, detalhamos duas técnicas que dependem dos mesmos princípios do BadSuccessor e podem permitir que os invasores extraiam credenciais e comprometam contas de usuários.
Na DEF CON 2025, apresentamos a história do BadSuccessor, uma vulnerabilidade do Active Directory (AD) que abusa do novo tipo de conta do Windows Server 2025: as contas de serviço gerenciado delegadas (dMSAs). A vulnerabilidade permite que um usuário com poucos privilégios escale diretamente para Domain Admin.
Menos de uma semana depois , a Microsoft atribuiu o identificador CVE-2025-53779 à vulnerabilidade e lançou um patch. O caminho de escalonamento direto foi fechado.
Nesta publicação do blog, vamos analisar o patch, explicar o que mudou, o que não mudou e mostrar que, embora o BadSuccessor não forneça mais escalonamento instantâneo, sua mecânica subjacente ainda importa.
Se você perdeu a história original, leia nossa publicação anterior do blog sobre o BadSuccessor.
O que era o BadSuccessor (antes do patch)
O BadSuccessor abusava de dMSA, um tipo de conta do Windows Server 2025 projetado para simplificar o gerenciamento de contas de serviço. Quando uma dMSA controlada era vinculada a qualquer conta no AD, o KDC (Key Distribution Center, centro de distribuição de chaves) a tratava como a sucessora durante a autenticação.
Esse único link fazia duas coisas perigosas de uma vez: Combinou os privilégios efetivos da conta de destino no PAC (Privilege Attribute Certificate, Certificado de atributo de privilégio) da dMSA e retornou um pacote de chave dMSA que incluía as chaves Kerberos (credenciais) do destino. sem mudanças de grupo, sem ferramentas exóticas. Apenas um link silencioso e utilitários internos do Windows.
De forma crítica, o nível de exigência era baixo: O controle sobre qualquer Unidade Organizacional (OU) era suficiente. Um invasor poderia criar um dMSA ali e vinculá-lo a qualquer alvo, até mesmo controladores de domínio, Administradores de domínio, Usuários protegidos ou contas marcadas como “confidencial e não pode ser delegado”, e imediatamente comprometê-los.
Para uma análise mais profunda e para assistir a uma demonstração, consulte nossa publicação anterior no blog BadSuccessor.
O patch da Microsoft para o CVE-2025-53779
Antes do patch, nossa suposição era simples: O bug principal consistia em não ser necessário realizar uma migração real via a operação rootDSE migrateADServiceAccount, bastava editar os atributos de link em um dMSA que o KDC aceitaria.
Esperávamos que a Microsoft protegesse esse atributo para que apenas o caminho adequado de migração pudesse configurá-lo, o que evitaria “migrações simuladas”.
Após instalar o patch, tentamos o teste óbvio: Como um usuário que controla um dMSA, escrevi o atributo de link exatamente como antes. A gravação foi bem-sucedida mesmo assim, sem nenhuma nova proteção no atributo, e seria possível vincular um dMSA a qualquer conta. Mas quando eu me autentiquei como dMSA para "herdar" os privilégios e chaves do destino, o KDC recusou a emissão do tíquete (Figura).
The error when authenticating a dMSA with a one-sided link — failure occurs at ticket issuance
Isso nos levou a analisar o próprio KDC. As alterações em kdcsvc.dll forçam o KDC a validar o relacionamento no momento do tíquete. Um link unidirecional de dMSA para o alvo não funciona mais.
Em nosso teste, a única maneira de obter um tíquete válido para um dMSA que está vinculado a outra conta após a correção era tornar o vínculo mútuo: O alvo também deve referenciar o dMSA, espelhando o que uma migração real produz. Portanto, diferente de antes, “ter sucesso” agora requer controlar o objeto da conta em si, não apenas o dMSA.
Isso significa que a aplicação do patch foi implementada na validação do KDC, não nas proteções do lado do diretório no atributo. O atributo ainda poderá ser escrito, mas o KDC não o reconhecerá, a menos que o emparelhamento pareça uma migração legítima.
Outro fato interessante é que a migração ainda funciona mesmo que a conta de destino permaneça ativada (enquanto o fluxo de migração formal a desabilita ao ser concluído).
O que é BadSuccessor (após o patch)
Embora a vulnerabilidade possa ser corrigida com um patch, o BadSuccessor ainda permanece como uma técnica; ou seja, a verificação do KDC remove o caminho de escalonamento existente antes do patch, mas não mitiga completamente o problema.
Como o patch não introduziu nenhuma proteção para o atributo de link, um invasor ainda pode herdar outra conta vinculando um dMSA controlado e uma conta alvo.
Esse fato permite (pelo menos) duas primitivas práticas que os defensores devem esperar e monitorar:
- Aquisição de credenciais e privilégios
- Extração direcionada de credenciais em domínios já controlados
Primitiva 1 – Aquisição de credenciais e privilégios (alternativas às credenciais de sombra)
Atualmente, se um atacante controla um principal alvo (por exemplo, possui GenericWrite em um usuário ou computador), ele pode compromete‑lo adicionando uma credencial de sombra ou realizando um ataque direcionado de Kerberoasting.
Um BadSuccessor abre um novo caminho de ataque: se um invasor controla uma DMSA, ele pode executar um emparelhamento mútuo e solicitar um tíquete para a dMSA. Isso permite que ele:
- Agir com os privilégios efetivos do alvo enquanto usa a identidade do dMSA (útil quando a conta alvo é monitorada de perto)
- Obtenha as chaves do destino a partir do pacote de chaves da dMSA, o que é mais rápido e mais confiável do que adicionar um SPN e realizar Kerberoasting (que é apenas para usuários, depende de brechas e é mais ruidoso)
- Redirecione a telemetria para que o ataque gere apenas logs nas edições do link de destino da dMSA↔e na emissão de TGT (Ticket Granting Ticket, bilhete de concessão de tíquete) para o DMSA
Primitiva 2 — Extração direcionada de credenciais em domínios já comprometidos (alternativa ao DCSync)
Em um domínio já comprometido, o BadSuccessor fornece uma maneira de descartar as chaves das entidades por meio da emissão normal de tíquetes. Isto não é um substituto para o DCSync, mas sim um caminho diferente com sinais diferentes que podem evitar detecções existentes.
Como a exploração do BadSuccessor pode ser detectada após o patch
O BadSuccessor ainda pode ser explorado por meio de duas primitivas diferentes após o lançamento do patch da Microsoft. Para detectar atividade potencial, tente:
- ACLs (System access control lists, Listas de controle de acesso): auditar a criação de dMSAs e as mudanças nos atributos de link de migração em ambos os lados: no link do dMSA e no link da conta anterior/substituída
- Indícios comportamentais:
- Entradas de log repetidas indicando que uma senha de dMSA foi obtida em um curto período
- Um usuário habilitado aparecendo vinculado a um dMSA (deve ser incomum)
- Um usuário previamente desabilitado sendo vinculado a um novo dMSA
Para uma orientação mais detalhada sobre detecção, leia nossa publicação anterior no blog BadSuccessor.
Mitigação
- Primeiro aplique o patch. Atualize seus controladores de domínio do Windows Server 2025 para o CVE-2025-53779.
- Redução da superfície de ataque. Revise permissões em OUs, contêineres e nos próprios objetos dMSA. Restrinja as delegações e remova direitos amplos para que apenas administradores de nível 0 possam criar ou modificar dMSAs e seus atributos de link de migração.
Conclusão
A Microsoft fechou o caminho de escalonamento direto ao exigir um emparelhamento mútuo que pareça uma migração real. Um link unilateral não gera mais privilégios nem chaves. Mas o BadSuccessor sempre foi mais do que um bug. É uma técnica. Este é um problema crescente dentro do setor: mesmo após a vulnerabilidade principal ter sido corrigida, os invasores ainda podem encontrar pontos de entrada alternativos.
O BadSuccessor permanece após o patch como (1) um método para obter credenciais e privilégios quando um atacante controla um principal alvo e um dMSA, e (2) uma via que não requer replicação para extrair segredos em domínios já comprometidos.
Esses resultados não são inéditos, existem outras formas de alcançar ambos. No entanto, cada uma vem com diferentes requisitos e telemetria, e é por isso que um invasor pode preferir o BadSuccessor.
Uma nota final
Uma breve observação sobre o próprio DMSA: em minha opinião, a dMSA após o patch é um forte reforço à segurança do AD. Quando usado conforme o esperado, melhora a higiene da conta de serviço e reduz segredos de longa duração. Compartilharei mais sobre a dMSA e explicarei por que considero que ela é uma excelente adição em uma próxima publicação no blog. Fique atento!
Tags
