BadSuccessor: abuso de dMSA para escalar privilégios no Active Directory
Sumário executivo
O pesquisador da Akamai, Yuval Gordon, descobriu uma vulnerabilidade de escalonamento de privilégios no Windows Server 2025 que permite que os invasores comprometam qualquer usuário no Active Directory (AD).
O ataque explora o recurso Conta de serviço gerenciado delegada (dMSA), que foi introduzido no Windows Server 2025, funciona com a configuração padrão e é fácil de implementar.
Esse problema provavelmente afeta a maioria das organizações que usam o AD. Em 91% dos ambientes que examinamos, encontramos usuários fora do grupo de administradores de domínio que tinham as permissões necessárias para executar esse ataque.
Embora a Microsoft afirme que planeja corrigir esse problema no futuro, um patch não está disponível no momento. Portanto, as organizações precisam tomar outras medidas proativas para reduzir sua exposição a esse ataque. A Microsoft analisou nossas descobertas e aprovou a publicação dessas informações.
Nesta publicação do blog, fornecemos detalhes completos do ataque, bem como estratégias de detecção e mitigação.
Índice
Introdução
A Microsoft introduziu as Contas de serviço gerenciado delegadas (dMSAs) no Windows Server 2025. Uma dMSA é um novo tipo de conta de serviço no Active Directory (AD) que se expande sobre os recursos das contas de serviço gerenciado em grupo (gMSAs). Um dos principais recursos das dMSAs é a capacidade de migrar contas de serviço não gerenciadas existentes convertendo-as perfeitamente em dMSAs.
Ao analisarmos o funcionamento interno das dMSAs do AD, descobrimos algo interessante. À primeira vista, o mecanismo de migração parecia uma solução limpa e bem projetada. Mas havia algo sobre como funcionava de forma subjacente que chamou nossa atenção.
À medida que investigamos mais a fundo, encontramos um caminho de escalonamento surpreendente: com o abuso de dMSAs, os invasores podem assumir qualquer entidade no domínio. Tudo de que um invasor precisa para executar esse ataque é uma permissão benigna em qualquer UO (organizational unit, unidade organizacional) no domínio, uma permissão que geralmente não é detectada pelo radar.
E a melhor parte: o ataque funciona por padrão, seu domínio não precisa usar dMSAs. Desde que o recurso exista, e ele existe em qualquer domínio que tenha pelo menos um DC (domain controller, controlador de domínio) com Windows Server 2025, ele estará disponível.
Esta postagem no blog explica como descobrimos isso, como o ataque funciona e o que você pode fazer para detectá-lo ou evitá-lo.
O que é uma dMSA?
Antes de analisar os ataques de forma detalhada, é importante entender o que as dMSAs realmente são e como elas devem funcionar.
Uma dMSA é normalmente criada para substituir uma conta de serviço legada existente. Para permitir uma transição perfeita, uma dMSA pode "herdar" as permissões da conta legada executando um processo de migração. Esse fluxo de migração une firmemente a dMSA à conta substituída; ou seja, a conta original que ela deve substituir. Esse fluxo, e as permissões que ele concede ao longo do caminho, é onde tudo começa a ficar interessante.
Fluxo de migração da dMSA
O processo de migração de uma dMSA pode ser acionado ao chamar o novo cmdlet Start-ADServiceAccountMigration. Internamente, ele chama uma nova operação rootDSE do LDAP chamada migrateADServiceAccount, que usa os seguintes argumentos:
O Nome diferenciado (DN) da dMSA
O DN da conta substituída
Uma constante correspondente a StartMigration
O status de migração de uma dMSA é ditado pelo atributo msDS-DelegatedMSAState, um novo atributo que determina o estado atual da dMSA. Atualmente, não há documentação oficial sobre o atributo msDS-DelegatedMSAState, portanto, a tabela a seguir é baseada em nossa própria análise comportamental e experimentação.
Valor |
Significado |
0 |
Desconhecido (possivelmente desativado, mas não confirmado) |
1 |
Migração em andamento |
2 |
Migração concluída |
3 |
dMSA independente (sem migração) |
Valores de migração e significados correlatos do msDS-DelegatedMSAState
Juntamente a esse atributo, alguns outros atributos notáveis são usados durante o processo de migração.
No objeto dMSA:
msDS-GroupMSAMembership: contém uma lista de entidades que estão autorizadas a usar esta dMSA
msDS-ManagedAccountPrecededByLink: DN da conta substituída
No objeto da conta substituída:
msDS-SupersededManagedAccountLink: DN da dMSA "substituta"
msDS-SupersededServiceAccountState: o mesmo significado do msDS-DelegatedMSAState, especificando o estado de migração da conta original
Ao acionar uma migração, a operação faz as seguintes alterações:
Define msDS-DelegatedMSAState como 1 (migração em andamento)
Atualiza o ntSecurityDescriptor da dMSA para conceder à conta substituída:
Permissões de leitura
Acesso de gravação ao atributo msDS-GroupMSAMembership
Define o msDS-ManagedAccountPrecededByLink da dMSA para fazer referência à conta substituída
Define o msDS-SupersededManagedAccountLink da conta substituída para fazer referência à dMSA
Define o msDS-SupersededServiceAccountState da conta substituída como 1
Neste ponto, a dMSA está em um estado de "migração em andamento". Ainda não está totalmente funcional, mas agora sabe quais sistemas ainda estão usando a conta de serviço antiga.
Quando o comando Complete-ADServiceAccountMigration é emitido, ocorre o seguinte:
A dMSA herda as principais configurações, como SPNs, configurações de delegação e outros atributos confidenciais da conta substituída
A conta substituída é desativada
O msDS-DelegatedMSAState e o msDS-SupersededServiceAccountState são definidos como 2 (migração concluída)
A migração é concluída e qualquer serviço que dependa da conta substituída usará agora a dMSA para autenticação.
Autenticação de dMSA
Agora que entendemos o processo de criação e migração das dMSAs, é hora de nos concentrarmos em como a autenticação funciona, as alterações introduzidas para dar suporte às dMSAs e como essas alterações tornam o processo de migração perfeito.
Para facilitar a compreensão, vamos examinar a conta de serviço legada svc_sql, usada para executar um serviço no servidor SQL_SRV$. Sempre que o serviço tem que acessar recursos no domínio, a autenticação normal é realizada usando a conta svc_sql (Figura 1).
Fig. 1: Legacy service account authentication flow
Autenticação durante a migração
Agora, fazemos a transição da conta de serviço para uma nova dMSA chamada DMSA$ e acionamos uma migração. Durante o período de migração, quando o serviço em SQL_SRV$ autentica como svc_sql, o fluxo de autenticação é ligeiramente modificado.
O cliente envia um AS-REQ para se autenticar como svc_sql
O KDC (Key Distribution Center, centro de distribuição de chaves) retorna um AS-REP contendo um campo adicional: KERB-SUPERSEDED-BY-USER (esse campo inclui o nome e o domínio da nova dMSA DMSA$)
Se o host for compatível com dMSAs (Windows Server 2025 ou Windows 11 24H2) e tiver a autenticação de dMSA habilitada, ele vai:
Extrair o nome DMSA$
Realizar uma consulta LDAP no DMSA$ para recuperar os seguintes atributos:
msDS-GroupMSAMembership
distinguishedName
objectClass
Como o serviço está sendo executado em SQL_SRV$ como svc_sql, a própria autenticação aciona uma solicitação de modificação LDAP de svc_sql, que adiciona SQL_SRV$ à lista de entidades com permissão para recuperar a senha de DMSA$ (Figura 2).
Isso é possível porque, durante o processo de migração, o svc_sql recebeu acesso de gravação ao atributo msDS-GroupMSAMembership na dMSA, uma alteração que permite autorizar sua máquina host a acessar as credenciais da conta.
Fig. 2: Kerberos authentication flow during dMSA migration
Essa concessão de permissão contínua garante que, no momento em que a migração for concluída, todas as máquinas que tenham usado svc_sql anteriormente sejam listadas no atributo msDS-GroupMSAMembership da DMSA$, dando a elas a capacidade de autenticação como a dMSA.
Autenticação após a conclusão da migração
Após a conclusão da migração (via Complete-ADServiceAccountMigration), o comportamento muda novamente.
Quando o cliente tenta se autenticar como svc_sql enviando um AS-REQ, ele não recebe mais um AS-REP.
Em vez disso, o DC responde com um KRB-ERROR, indicando que svc_sql está desativado.
O KRB-ERROR conterá o campo KERB-SUPERSEDED-BY-USER, permitindo que o cliente reconheça que svc_sql foi migrado e tente mais uma vez a autenticação automaticamente usando DMSA$ (Figura 3).
Fig. 3: Kerberos authentication flow after the dMSA migration is completed
SQL_SRV$ (e qualquer outra máquina que dependia anteriormente de svc_sql) agora mudará de forma transparente para o uso de DMSA$.
Comportamento UnexPACted
Um aspecto interessante da autenticação Kerberos de dMSA envolve seu PAC (Privilege Attribute Certificate, Certificado de atributo de privilégio).
Durante a autenticação, o Kerberos incorpora um PAC nos tíquetes, uma estrutura que esses serviços usam para determinar o nível de acesso de um cliente. Em um TGT (Ticket Granting Ticket, tíquete de concessão de tíquete) padrão, o PAC inclui os SIDs dos usuários e de todos os grupos dos quais eles fazem parte.
No entanto, ao fazer login com uma dMSA, observamos algo inesperado.
O PAC incluiu não apenas o SID da dMSA, mas também os SIDs da conta de serviço substituída e de todos os seus grupos associados.
abuso do processo de migração de dMSAs para escalonamento de privilégios
Após a migração, o KDC concede à dMSA todas as permissões da conta original (substituída).
Sob uma perspectiva de projeto, isso faz sentido. O objetivo é fornecer uma experiência de migração perfeita na qual a nova conta se comporta exatamente como a que ela substitui: mesmos SPNs, mesmas delegações, mesma participação em grupos.
Mas, do ponto de vista de um pesquisador de segurança, esse tipo de comportamento se destaca imediatamente. Quando vimos um sistema que copia automaticamente privilégios de uma conta para outra, sem exigir reconfiguração manual, começamos a investigar mais a fundo: Como ele decide de qual conta copiar? Isso pode ser influenciado? Isso pode ser violado?
Essa linha de questionamento nos levou diretamente a uma descoberta importante. Esse comportamento interessante de herança de PAC parece ser controlado por um único atributo: msDS-ManagedAccountPrecededByLink.
O KDC depende desse atributo para determinar quem a dMSA está "substituindo". Quando uma dMSA autentica, o PAC é criado com base somente nesse link.
É hora de pensar como um invasor
Como isso é visto por um invasor? Vamos explorar um possível cenário de ataque e ver até que ponto um invasor poderia chegar usando essa funcionalidade.
Nossa primeira ideia: usar uma dMSA para criar um primitivo de apropriação indevida de contas. Se presumirmos que temos permissões sobre uma conta de usuário, seria possível de alguma forma "migrar" as respectivas permissões para uma nova dMSA, a fim de comprometê-la de maneira furtiva? Parecer ser uma abordagem viável! Tudo o que precisamos fazer é:
Criar uma dMSA
Iniciar e concluir a migração entre o usuário de destino e a dMSA usando a operação migrateADServiceAccount rootDSE
Autenticar como a dMSA: obter todas as permissões do usuário de destino
O único problema: Não funciona.
Ainda que tenhamos controle total sobre a dMSA e a conta substituída, não é possível realizar a migração, pois até onde sabemos, a operação migrateADServiceAccount é restrita a administradores de domínio. A Figura 4 mostra um exemplo de tentativa malsucedida.
Fig. 4: A failed attempt to use a dMSA to create an account takeover primitive
Em seguida, examinamos outra possibilidade. Claramente, precisamos de algo complexo, criativo e profundamente técnico. Precisamos explorar comportamentos não documentados, talvez até fazer engenharia reversa de alguma parte do KDC... ou poderíamos apenas definir dois atributos.
Embora não seja possível realizar uma migração diretamente, ela pode ser facilmente "simulada" por meio da definição dos seguintes atributos diretamente no objeto dMSA.
Grave o DN da conta de destino como msDS-ManagedAccountPrecededByLink
Defina msDS-DelegatedMSAState como valor 2 (migração concluída)
A partir deste ponto, toda vez que nos autenticamos como a dMSA, o KDC constrói o PAC usando os SIDs da conta vinculada no atributo msDS-ManagedAccountPrecededByLink, efetivamente concedendo-nos as permissões completas da conta substituída.
Introdução ao BadSucessor
Um fato interessante sobre essa técnica de "migração simulada" é que ela não requer nenhuma permissão sobre a conta substituída. A única exigência é ter permissões de gravação sobre os atributos de uma dMSA. Qualquer dMSA.
Após marcarmos uma dMSA como precedida por um usuário, o KDC presume automaticamente que ocorreu uma migração legítima e concede à nossa dMSA todas as permissões que o usuário original tinha, como se fôssemos seus sucessores legítimos.
Mas, certamente, isso não funcionaria para contas altamente privilegiadas, certo? Bem...
Além disso, essa técnica, que nós apelidamos de "BadSuccessor", funciona com qualquer usuário, incluindo administradores de domínio (Figura 5). Ela permite que qualquer usuário que controla um objeto dMSA controle todo o domínio. Isso é tudo o que é necessário. Nenhuma migração real. Sem verificação. Sem supervisão.
Fig. 5: Full attack flow, showing all steps needed to have a BadSuccessor
Exploração de dMSAs: de poucos privilégios ao controle de domínios
Neste ponto, você pode estar pensando: "Bem, não estou usando dMSAs no meu ambiente, então isso não me afeta". Pode não ser o caso.
Um cenário de abuso: um invasor obtém o controle de uma dMSA existente e usa esse acesso para executar o ataque BadSucessor. Mas, na verdade, há outro cenário que provavelmente estará disponível para os invasores com muito mais frequência: um invasor cria uma nova dMSA.
Quando um usuário cria um objeto no AD, ele tem permissões totais sobre todos os seus atributos. Portanto, se um invasor puder criar uma nova dMSA, ele poderá comprometer todo o domínio.
Normalmente, quando uma dMSA é criada usando o cmdlet New-ADServiceAccount, ela é armazenada no recipiente de Contas de serviço gerenciadas. Embora seja possível que os usuários tenham acesso a esse contêiner, somente grupos privilegiados internos do Active Directory têm permissões sobre ele por padrão. Portanto, não é muito provável que possamos gravar nesse contêiner.
No entanto, as dMSAs não estão restritas ao contêiner de Contas de serviço gerenciadas; elas também podem ser criadas em qualquer UO. Qualquer usuário que tenha o direito Criar msDS-DelegatedManagedServiceAccount ou Criar todos os objetos filho em qualquer UO pode criar uma dMSA.
Criar a dMSA
Permitir que os usuários criem objetos em uma UO é uma configuração bastante comum. Como essa capacidade é vista como benigna, não é provável que os usuários com esse privilégio sejam monitorados e protegidos adequadamente.
Para criar a dMSA, começamos localizando uma UO na qual temos privilégios. Felizmente, alguém criou uma UO chamada "temp" em nosso ambiente de exemplo e deu ao nosso usuário sem privilégios permissões "fracas" para criar todos os objetos filho (Figura 6).
Fig. 6: Example of required privileges on an OU
Em seguida, podemos usar essas permissões para criar uma dMSA usando o cmdlet New-ADServiceAccount. Como visto na Figura 7, embora o usuário não privilegiado não possa criar uma dMSA no contêiner de MSAs padrão, podemos usar o argumento de caminho para criar a dMSA na UO acessível.
Fig. 7: Creating the dMSA in an allowed location using the New-ADServiceAccount PowerShell cmdlet
Agora somos os felizes proprietários de uma dMSA recém-criada e não funcional. Como proprietário criador, podemos conceder a nós mesmos permissão sobre o objeto, incluindo acesso de gravação em ambos os atributos que usaremos para este ataque, que podemos modificar da seguinte maneira:
msDS-ManagedAccountPrecededByLink: definir esse atributo como o DN de qualquer usuário ou computador, incluindo controladores de domínio, membros do grupo de administradores de domínio, usuários protegidos e (ironicamente) até mesmo contas marcadas como "esta conta é confidencial e não pode ser delegada".
msDS-DelegatedMSAState: definir como 2 para simular uma migração concluída (Figura 8).
Fig. 8: Modifying attributes to mimic successful migration
Como mencionamos, esse ataque parece funcionar em todas as contas no AD. Não foi possível encontrar nenhuma configuração que impeça o uso de uma conta como destino substituído.
Obtenção de um TGT para a dMSA
Uma maneira de se autenticar com nossa dMSA seria criar um serviço e configurá-lo para ser executado com a conta dMSA. Tudo isso é possível, mas não é conveniente. Felizmente, graças a uma excelente solicitação pull de Joe Dibley, o Rubeus agora oferece suporte à autenticação de dMSA (Figura 9). Isso significa que podemos usá-lo para solicitar um TGT para nossa dMSA:
Rubeus.exe asktgs /targetuser:attacker_dmsa$ /service:krbtgt/aka.test /dmsa /opsec /nowrap /ptt /ticket:<Machine TGT>
Fig. 9: Requesting TGT for the new dMSA using Rubeus
dMSA → Administrador de domínio
Neste exemplo, nosso alvo foi a conta interna de administrador. Usando o Wireshark, inspecionamos o PAC do tíquete que recebemos para nossa dMSA (Figura 10), que incluiu:
RID da dMSA (1137)
RID da conta substituída (500 – Administrador)
Todas as associações de grupo da conta substituída (512 – Administradores de domínio, 519 – Administradores da empresa)
Fig. 10: dMSA’s PAC that includes the Administrator’s groups’ RIDs
Isso é tudo o que o controlador de domínio precisa para nos tratar como o herdeiro legítimo. Lembre-se: não há necessidade de nenhuma alteração de associação a grupos, nenhum acesso ao grupo de administradores de domínio e nenhuma gravação suspeita via LDAP na conta privilegiada real.
Com apenas duas alterações de atributos, um novo objeto modesto é coroado como sucessor e o KDC não valida a legitimidade do vínculo anterior. Se o vínculo estiver presente, os privilégios serão concedidos. Não alteramos nenhuma associação a grupos, não elevamos nenhuma conta existente e não acionamos nenhum alerta tradicional de escalonamento de privilégios.
Demonstração: fluxo de ataque de ponta a ponta
Assista a este vídeo para uma demonstração completa do ataque em ação.
Demonstração de abuso de dMSA para escalonamento de privilégios no Active Directory
Mas espere, há mais: abuso de dMSAs para comprometer as credenciais
Obter um TGT para qualquer usuário que queremos é legal, mas queremos mais. E se também quiséssemos suas credenciais? Felizmente, a dMSA também pode ser usada nesse cenário.
Quando você solicita um TGT para uma dMSA, ele vem com uma nova estrutura chamada KERB-DMSA-KEY-PACKAGE. Essa estrutura inclui dois campos: current-keys e previous-keys. De acordo com o MSDN, eles devem conter chaves relacionadas à senha atual e à anterior da dMSA, e eles realmente contêm essas chaves. Mas essa não é a história completa.
Ficamos surpresos ao ver que, mesmo ao solicitar um TGT para uma dMSA recém-criada, o campo previous-keys não estava vazio. Como ela acabou de ser criada, não deve haver uma "senha anterior". Ignoramos esse fato até que percebemos algo que parecia realmente familiar.
Como mostrado na Figura 11, o segundo elemento na estrutura tinha uma única chave com o tipo 23 (RC4-HMAC). Esse tipo de criptografia não utiliza salt, o que significa que senhas idênticas geram chaves idênticas, mesmo entre usuários diferentes.
Fig. 11: ASN.1 decoded value of the KERB-DMSA-KEY-PACKAGE, decoded at https://pkitools.net/pages/ca/asn1.html
E essa chave específica? Os anos de reutilização da mesma senha em ambientes de laboratório finalmente compensaram. Nós a reconhecemos imediatamente. Era a chave correspondente a Aa123456, a senha que usamos para nossa conta alvo durante a demonstração.
Pense sobre isso: a chave para uma conta separada acabou de alguma forma na estrutura previous-keys da dMSA.
Comprometimento de chaves em escala
Então, o que está acontecendo aqui? E por quê?
O msDS-ManagedAccountPrecededByLink não apenas vincula a dMSA à conta substituída para fins de permissão, mas também permite que a dMSA herde suas chaves. Isso significa que esse ataque também pode ser usado para obter as chaves de qualquer (ou todo) usuário e computador no domínio. Podemos usar essa chave para autenticação com a conta.
Embora não tenhamos analisado toda a implementação, nossa teoria é que esse comportamento existe para garantir uma continuidade perfeita durante a migração de contas, para benefício do usuário final.
Digamos que tenhamos um serviço em execução com uma conta de serviço legada. As contas em todo o domínio solicitam tíquetes para esse serviço, que são criptografados usando a chave da conta de serviço legada. Agora suponha que substituímos a conta legada por uma dMSA, concluímos a migração e trocamos a conta de serviço pela dMSA, mas ela não tem acesso à chave da conta antiga.
O resultado: quando um cliente tenta se autenticar usando seu tíquete existente, o servidor não consegue decifrá-lo usando a chave da nova dMSA, o que inutiliza todos os tíquetes emitidos, mesmo que eles não tenham expirado.
Para evitar esse tipo de interrupção de serviço, o KDC inclui as chaves da conta anterior na estrutura do pacote de chaves da nova dMSA, tratando-as como se fossem credenciais anteriores da própria dMSA e permitindo que ela decifre tíquetes "antigos".
Assim que compreendemos isso, outro fator estranho começa a fazer sentido. O campo current-keys contém três elementos, cada um consistindo em um número inteiro (representando o tipo de criptografia) e uma string de octeto (a chave correspondente). Você pode consultar esta página para entender os valores de tipos de criptografia. Em nosso caso, a lista inclui chaves para RC4-HMAC, AES256 e AES128. No entanto, o campo previous-keys parece um pouco diferente. Ele contém apenas uma chave, que corresponde a RC4-HMAC (Figura 12). Por que a lista previous-keys contém apenas um tipo de chave e por que ela é especificamente RC4-HMAC?
Fig. 12: KERB-DMSA-KEY-PACKAGE structure, highlighting the different keys
A resposta está nos tipos de criptografia suportados pela conta original (substituída). Os tíquetes de serviço são criptografados somente usando tipos de criptografia compatíveis com o serviço de destino. Como explicado na excelente postagem de blog de Harmj0y, o atributo msDS-SupportedEncryptionTypes controla esse comportamento. Se esse atributo não for definido (caso padrão para contas de usuário), o sistema utiliza apenas RC4-HMAC por padrão, daí a presença isolada da chave RC4-HMAC na lista previous-keys.
Em outras palavras, o KDC fornece à dMSA apenas as chaves da conta original que seriam necessárias para descriptografar os tíquetes de serviço emitidos antes da migração. Elas são determinadas com base nos tipos de criptografia compatíveis com a entidade original, que você pode verificar inspecionando o atributo msDS-SupportedEncryptionTypes.
Resposta da Microsoft
Reportamos esses detalhes à Microsoft via MSRC em 1 de abril de 2025 e, após analisar nosso relatório e a prova de conceito, a Microsoft reconheceu o problema e confirmou sua validade. No entanto, eles a avaliaram como uma vulnerabilidade de gravidade moderada e declararam que ela não entra atualmente no limite para manutenção imediata.
De acordo com a Microsoft, a exploração bem-sucedida exige que o invasor já tenha permissões específicas sobre o objeto dMSA, o que é indicativo de privilégios elevados. Em resposta ao cenário de criação de uma nova dMSA, a Microsoft fez referência à KB5008383, que discute os riscos relacionados à permissão CreateChild.
Embora agradeçamos a resposta da Microsoft, discordamos respeitosamente da avaliação de gravidade.
Essa vulnerabilidade introduz um caminho de abuso anteriormente desconhecido e de alto impacto, que permite a qualquer usuário com permissões CreateChild em uma UO comprometer qualquer usuário no domínio e obter um nível de poder semelhante ao privilégio Replicar alterações no diretório, usado para realizar ataques DCSync.
Além disso, não encontramos nenhuma indicação de que as práticas ou ferramentas atuais do setor sinalizem o acesso CreateChild ou, mais especificamente, CreateChild para dMSAs, como uma preocupação crítica. Acreditamos que isso enfatize a furtividade e a gravidade do problema.
Detecção e mitigação
Detecção
Para detectar possíveis abusos desse vetor de ataque, as organizações devem se concentrar nas seguintes áreas:
Auditar a criação de dMSAs: configure uma SACL para registrar a criação de novos objetos msDS-DelegatedManagedServiceAccount (ID do evento 5137; Figura 13). Preste atenção especial às contas que normalmente não são responsáveis pela criação de contas de serviço.
Fig. 13: Event example of dMSA creation
Monitorar modificações de atributos: configure uma SACL para modificações no atributo msDS-ManagedAccountPrededByLink (ID do evento 5136; Figura 14). As alterações nesse atributo são um sinal forte de uma tentativa ou de um abuso bem-sucedido.
Fig. 14: Event example of dMSA link creation
Rastrear a autenticação de dMSA: quando um TGT é gerado para uma dMSA e inclui a estrutura KERB-DMSA-KEY-PACKAGE, o controlador de domínio registra o ID do evento 2946 (Log de Serviço de diretório).
O campo Objeto de conta de serviço gerenciado em grupo (embora seja uma dMSA e não uma gMSA) mostrará o DN da dMSA sendo autenticado e o campo SID do chamador será exibido como S-1-5-7 (Figura 15). Eventos 2946 frequentes ou inesperados envolvendo dMSAs incomuns devem ser investigados.
Fig. 15: Event example of dMSA authentication
Permissões de revisão: preste muita atenção às permissões em UOs e contêineres. Delegações excessivamente permissivas podem abrir a porta para esse abuso.
Mitigação
Até que um patch formal seja lançado pela Microsoft, os esforços defensivos devem se concentrar em limitar a capacidade de criar dMSAs e restringir permissões sempre que possível.
Os defensores devem identificar todas as entidades (usuários, grupos, computadores) com permissões para criar dMSAs em todo o domínio e limitar essa permissão somente a administradores confiáveis.
Para ajudar com isso, publicamos um script PowerShell que:
Lista todas as entidades não padrão que podem criar dMSAs
Lista as UOs nas quais cada entidade tem essa permissão
A Microsoft nos informou que suas equipes de engenharia estão trabalhando em um patch e atualizaremos a orientação de mitigação nesta publicação do blog assim que mais detalhes técnicos estiverem disponíveis.
Conclusão
Essa pesquisa destaca como até mesmo as permissões de escopo restrito, geralmente consideradas de baixo risco, podem ter vastas consequências em ambientes do Active Directory. Os invasores são bastante criativos e, se os recentes avanços tecnológicos nos ensinaram algo, é que as funções aparentemente benignas podem ter consequências graves nas mãos erradas. A dMSA foi introduzida como uma solução moderna para o gerenciamento de contas de serviço, mas também trouxe uma nova complexidade e, com ela, novas oportunidades de abusos.
As organizações devem tratar a capacidade de criar dMSAs ou controlar as existentes com o mesmo nível de escrutínio que outras operações confidenciais. As permissões para gerenciar esses objetos devem ser muito restritas e as alterações a elas devem ser monitoradas e auditadas regularmente.
Esperamos que essa pesquisa esclareça os riscos que vieram com o Windows Server 2025 em geral (e com as dMSAs, especificamente) e ajude os defensores a entender e mitigar melhor o impacto potencial de permissões mal configuradas.
