BadSuccessor: Risco do dMSA no Active Directory
O Windows Server 2025 trouxe as Delegated Managed Service Accounts (dMSA), a evolução das gMSA que liga a autenticação de serviços a identidades de máquina específicas. A pesquisa da Akamai que descobriu o vector e a análise da Unit 42 (Palo Alto Networks) que o popularizou deram-lhe um nome: BadSuccessor. O problema não é a funcionalidade — é o poder que ela entrega, por omissão, a quem tem permissões aparentemente inofensivas sobre uma OU.
O Mecanismo do Ataque
Um dMSA tem um atributo, msDS-ManagedAccountPrecededByLink, que aponta para a conta tradicional que ele substitui — é assim que a migração de service accounts funciona. Quando o atributo está preenchido, o KDC emite ao dMSA um ticket que inclui os direitos da conta antiga (superseded account).
O BadSuccessor explora exactamente isso. Quem tiver permissão CreateChild numa OU — uma permissão comum para técnicos que criam objetos — pode:
- Criar um dMSA nessa OU.
- Apontar o
msDS-ManagedAccountPrecededByLinkpara uma conta privilegiada (um admin de domínio, por exemplo). - Marcar
msDS-DelegatedMSAState = 2(migração concluída). - Pedir um Kerberos ticket para o dMSA — e o KDC emite-o com os direitos da conta substituída, sem tocar no KRBTGT nem na palavra-passe de ninguém.
O resultado é escalação para domain admin a partir de uma permissão que a maioria dos ambientes considera inofensiva. A investigação da Akamai estimou que a vasta maioria dos ambientes enterprise tem utilizadores com CreateChild em OUs, e a análise posterior da CovertSwarm quantificou esse padrão em 91% dos domínios reais analisados
A Microsoft corrigiu a escalação directa no Patch Tuesday de 12 de Agosto de 2025: CVE-2025-53779, corrigida pelo KB5063878 (build 26100.4946 de Windows Server 2025). O patch fecha o caminho de escalação directa, mas a análise de follow-up da própria Akamai, no texto BadSuccessor Is Dead, Long Live BadSuccessor? concluiu que a técnica não morreu. Em sistemas corrigidos, quem controla um dMSA e consegue escrever os atributos de migração pode forjar o emparelhamento mútuo que o KDC agora exige e obter material de chaves Kerberos do alvo — útil para persistência e movimento lateral, já não para salto imediato a domain admin.
Condições e Alcance
O ataque exige DCs em Windows Server 2025 (é onde o KDC honra a supersedência do dMSA) e o pedido de ticket a partir de um cliente com suporte à nova autenticação dMSA. Domínios em 2019/2022 sem DCs 2025 não estão expostos — mais um motivo para tratar a introdução de WS 2025 no domínio como um projecto de segurança, não só de infraestrutura.
Detecção: Eventos e Auditing
O Windows registra os passos do ataque se o auditing estiver activo:
| Evento | O que registra |
|---|---|
| 5137 | Criação de um objecto dMSA (Security log, com SACL de OU) |
| 5136 | Modificação do atributo msDS-ManagedAccountPrecededByLink |
| 2946 | TGT gerado para um dMSA |
| 4662 | Acesso a objecto com CreateChild na OU — alternativa proposta pela Unit 42 |
A Unit 42 propõe o 4662 como caminho mais fiável: correlaciona quem criou o dMSA (SubjectUserName) com a modificação do link de supersedência, porque o 5137/5136 exigem SACLs configurados por OU. Para uma PME, o mínimo é activar o auditing de Directory Service Changes e alertar sobre qualquer msDS-ManagedAccountPrecededByLink tocado fora de uma migração planada.
Mitigação
- Aplicar o patch da Microsoft (KB5063878, Agosto de 2025) — corrige o CVE-2025-53779 e fecha o vector de escalação directa em qualquer DC Windows Server 2025. Sem o patch, as restantes medidas reduzem o risco mas não o fecham. Com o patch, manter a revisão de permissões: a técnica continua viável para persistência e movimento lateral.
- Inventariar quem tem CreateChild em OUs —
Get-Aclsobre cada OU do domínio, listar os ACE com CreateChild em objectos msDS-ManagedServiceAccount. Raramente há justificação para técnicos comuns terem essa permissão em OUs de produção. - Auditar a criação de dMSA com os eventos acima, mesmo antes de planear usar a funcionalidade.
- Restringir a criação de objectos nas OUs aos grupos que precisam, e monitorizar as que não podem ficar sem vigilância.
- Se a funcionalidade dMSA for adoptada, migrar service accounts por processo controlado — com aprovação e janela — e não deixar o atributo de supersedência activo mais do que o necessário.
O padrão repete-se: cada versão nova do AD traz melhorias de segurança que também alargam a superfície de ataque. O hardening de Kerberos e a auditoria de delegação continuam a ser o terreno onde os ataques se decidem.
