Jorge de Almeida Pinto

Principais conclusões

  • O BadSuccessor, uma técnica de escalonamento de privilégios que explora as contas de serviço gerido delegadas (dMSAs), apresenta um elevado risco para as organizações que utilizam até um controlador de domínio (DC) do Windows Server 2025. A técnica pode ser utilizada para se fazer passar por qualquer conta no Active Diretory (AD) - até mesmo Admins. do Domínio, a conta KRBTGT ou qualquer outra conta activada ou desactivada com privilégios elevados.
  • Jorge de Almeida Pinto, Líder Sénior de Resposta a Incidentes da Semperis, descobriu uma forma de bloquear completamente o caso de utilização da migração dMSA, o que impede eficazmente os atacantes de utilizarem indevidamente uma dMSA para potencialmente assumirem o controlo de um domínio AD.
  • A solução é configurada no esquema AD e deve ser aplicada a todas as florestas AD.
  • Esta atenuação do risco pode ser implementada até que a Microsoft tenha lançado uma correção para atenuar a vulnerabilidade.

Até ao Windows Server 2025, o AD e o Windows suportavam Contas de Serviço Gerido autónomas (sMSAs) e Contas de Serviço Gerido de grupo (gMSAs). O Windows Server 2025 introduz um novo tipo de conta de serviço gerido: Contas de Serviço Gerido delegadas.

Este novo tipo de conta foi concebido para melhorar a gestão de credenciais de contas de serviço baseadas no utilizador, apoiando a migração da conta de serviço antiga para uma dMSA.

Os investigadores da Akamai1 descobriram que os atacantes podem facilmente criar e configurar um dMSA e, em seguida, abusar dele para se fazerem passar por qualquer entidade de segurança autenticável no AD. Eles chamaram a técnica de ataque de BadSuccessor.

Nesta publicação do blogue, fornecemos uma introdução detalhada e informações para mitigar a vulnerabilidade, incluindo o código PowerShell para implementar a solução sugerida para bloquear o caso de utilização de migração.

Porque é que é necessário bloquear o BadSuccessor?

Quando utilizada como pretendido, a migração dMSA suporta oficialmente apenas contas de serviço antigas como fonte (tipo de conta user). No entanto, o ataque BadSuccessor funciona com qualquer tipo de conta autenticável como fonte, incluindo contas de computador, sMSAs, gMSAs e até dMSAs. Além disso, não importa se a conta de origem está activada ou desactivada.

Os únicos componentes necessários para executar este ataque são:

  • Pelo menos um DC 2025 gravável
  • Uma dMSA (vulnerável) e as ferramentas corretas

Além disso, o ataque não precisa de ter lugar no Windows Server 2025.

O núcleo do ataque BadSuccessor começa com a capacidade de criar um novo dMSA ou de controlar um dMSA existente. Assim, a delegação do controlo de qualquer domínio AD existente exige uma análise e ação imediatas.2

Dado o potencial de comprometimento total do domínio do AD, deve tomar medidas para mitigar este risco assim que introduzir o seu primeiro DC gravável do Windows Server 2025 - mesmo que ainda não esteja a utilizar dMSAs.

Como detetar o BadSuccessor: Indicadores de exposição e comprometimento

A Microsoft ainda não disponibilizou uma correção para mitigar esta vulnerabilidade. A Semperis adicionou capacidades de deteção no Directory Services Protector DSP) para se defender contra o BadSuccessor. A plataforma DSP foi aprimorada com um novo indicador de exposição (IOE) e três novos indicadores de comprometimento (IOCs) focados em permitir a deteção e mitigação de atividades maliciosas envolvendo dMSAs.

Quais são os casos de utilização do dMSA?

A Microsoft concebeu a dMSA para um caso de utilização específico e difícil de resolver que muitas organizações têm atualmente. Na prática, uma dMSA suporta dois casos de utilização.

Devido aos múltiplos casos de utilização, qualquer dMSA tem um estado que determina a forma como a dMSA é utilizada e que é registado no atributo msDS-DelegatedMSAState.

Os estados suportados são:

  • 0: Não utilizado (este estado é o padrão quando indefinido)
  • 1: Utilização da migração iniciada
  • 2: Utilização da migração concluída
  • 3: Utilização nativa

Um dMSA pode ser utilizado como se utiliza um gMSA. Nesse caso, o estado da dMSA será 3, o que significa que é utilizada nativamente.

A dMSA foi concebida para suportar a migração de uma conta de serviço antiga para uma dMSA para uma gestão de credenciais melhor e mais avançada sem afetar a funcionalidade de um serviço, aplicação ou tarefa agendada que utilize a conta de serviço antiga. Uma gestão de credenciais melhor e mais avançada significa tecnicamente uma rotação de palavras-passe mais frequente e automatizada utilizando uma palavra-passe mais forte e muito complexa.

A migração da conta de serviço antiga para a dMSA é iniciada por um administrador. O estado da conta de serviço antiga e da dMSA muda para 1-migração iniciada. Quando o administrador concluir a migração e o estado da conta de serviço antiga e do dMSA mudar para 2-migração concluída - a configuração específica da própria conta de serviço herdada é migrada para o dMSA. No entanto, as associações de grupo da conta de serviço herdada não são migradas para o dMSA e permanecem com a conta de serviço herdada.

Durante o primeiro estado de migração, o sistema descobre automaticamente onde a conta de serviço antiga está a ser utilizada e configura a dMSA em conformidade. No segundo estado de migração, quando o sistema tenta autenticar utilizando a conta de serviço antiga (desactivada), a dMSA assume a autenticação.

Quando o dMSA assume a autenticação, o controlador de domínio do Windows Server 2025 funde o Certificado de Atributo Privilegiado (PAC) da conta de serviço antiga e o PAC do dMSA num PAC que contém todos os membros de grupo combinados e outros objectSIDs aplicáveis. Por conseguinte, o dMSA herda todos os direitos de utilizador, permissões e acesso para que possa substituir a conta de serviço antiga sem afetar o serviço, a aplicação ou a tarefa agendada.

O lado positivo: a sucessão da dMSA como previsto

Os seguintes cmdlets do PowerShell estão disponíveis para a migração de uma conta de serviço herdada para uma dMSA.

CMDlet do PowerShellAção
Start-ADServiceAccountMigrationIniciar a migração da conta de serviço antiga para a dMSA. Este estado transita de inicial para iniciado. Só pode ser executado quando o estado é 0.
Complete-ADServiceAccountMigrationConcluir a migração da conta de serviço antiga para a dMSA. Transições de iniciado para concluído. Só pode ser executado quando o estado é 1.
Undo-ADServiceAccountMigrationDesfazer o último passo da migração e reverter para o passo anterior. Transições de concluído para iniciado ou de iniciado para inicial. Só podem ser executadas quando o estado é 1 ou 2.
Reset-ADServiceAccountMigrationRepor a migração para o estado inicial, desfazendo tudo. Transições de concluído ou iniciado para inicial. Só pode ser executado quando o estado é 1 ou 2.

Dependendo do cmdlet do PowerShell que está a ser utilizado, um atributo operacional com dados de entrada é utilizado contra o RootDSE de um DC gravável. Quando isso acontece, são executadas várias acções simultâneas contra a conta de serviço legado de destino e o dMSA de destino. Os cmdlets do PowerShell ou o atributo operacional só podem ser utilizados por membros do grupo Admins do Domínio.

Para uma melhor compreensão do que cada cmdlet do PowerShell faz, eis uma descrição mais detalhada das acções.

Ao utilizar Start-ADServiceAccountMigrationO sistema está a executar as seguintes acções:

  • Na conta de serviço antiga:
    • Conjunto msDS-SupersededServiceAccountState para 1
    • Conjunto msDS-SupersededManagedAccountLink para o DN da dMSA visada
  • Na dMSA:
    • Conjunto msDS-DelegatedMSAState para 1
    • Conjunto msDS-ManagedAccountPrecededByLink para o DN da conta de serviços antigos visada
    • Atribuir permissões de leitura à conta de serviço antigo visada em todos os atributos da dMSA visada
    • Atribuir permissões de escrita à conta de serviço histórico visada no atributo msDS-GroupMSAMembership da dMSA visada

Ao utilizar Complete-ADServiceAccountMigrationO sistema está a executar as seguintes acções:

  • Na conta de serviço antiga:
    • Conjunto msDS-SupersededServiceAccountState para 2
    • Desativar a conta
  • Na dMSA:
    • Conjunto msDS-DelegatedMSAState para 2
    • Remover as permissões de leitura anteriormente atribuídas à conta de serviço antigo visada de todos os atributos da dMSA
    • Remover do atributo as permissões de escrita anteriormente atribuídas à conta de serviço histórico visada msDS-GroupMSAMembership da dMSA
  • Da conta de serviço antiga para o dMSA, mova as seguintes configurações:
    • Nomes principais de serviço (SPNs)
    • Autorizado a delegar na lista
    • Delegação condicionada baseada em recursos
    • Política de autenticação atribuída
    • Silo de autenticação atribuído
    • Autenticação de confiança para delegação Bit UAC

Ao utilizar Reset-ADServiceAccountMigration, todas as acções executadas por Start-ADServiceAccountMigration ou Complete-ADServiceAccountMigration são anuladas e tanto a conta de serviço antiga como a dMSA voltam ao seu estado inicial.

Ao utilizar Undo-ADServiceAccountMigration, todas as acções executadas por Start-ADServiceAccountMigration ou Complete-ADServiceAccountMigration são anuladas e tanto a conta de serviço antiga como a dMSA voltam ao estado anterior à execução de, respetivamente, Start-ADServiceAccountMigration ou Complete-ADServiceAccountMigration. Tecnicamente, isto significa uma das seguintes transições:

  • De concluído a iniciado
  • Do início ao fim

O mau e o feio: abuso da dMSA

Como os pesquisadores da Akamai descobriram, os atributos da conta de serviço herdada e o dMSA envolvido na migração não estão protegidos contra gravações LDAP regulares. Qualquer pessoa com pelo menos a permissão Write Property nos atributos do dMSA - ou qualquer outra permissão que possa levar a essa permissão - pode gravar dados. Infelizmente, esta lacuna invalida as protecções implementadas através do cmdlet do PowerShell e do atributo operacional subjacente.

Além disso, em termos de validação, o DC gravável de autenticação do Windows Server 2025 parece considerar apenas dois atributos do dMSA e nada da conta de serviço herdada. Se o msDS-DelegatedMSAState da dMSA é definido como 2 (e nem sequer importa como chegou a esse estado), o CD verificará qual a conta especificada no ficheiro msDS-ManagedAccountPrecededByLink atributo.

Com essa informação, e assumindo que a conta requerente (normalmente uma conta de computador, mas pode ser qualquer coisa) tem permissões para pedir a palavra-passe ou as chaves do dMSA, o DC gravável do Windows Server 2025 autenticador funde o Certificado de Atributo Privilegiado (PAC) da conta de serviço antiga e o dMSA num único PAC. Em seguida, o CD emite esse PAC combinado num TGS-REP para a conta requerente.

O Nome Distinto (DN) da conta no ficheiro msDS-ManagedAccountPrecededByLink pode ser qualquer coisa - e o BadSuccessor explora totalmente esta vulnerabilidade.

A utilização de camadas administrativas ajuda a ocultar e proteger as contas com privilégios elevados (utilizadores, serviços, computadores, sMSAs, gMSAs, dMSAs). O foco aqui é "esconder" as contas com privilégios elevados para que o seu DN não seja visível para qualquer conta com privilégios baixos. Também é importante notar que o DN das contas com privilégios elevados também não deve ser facilmente adivinhável.

Este ataque pode rapidamente tornar-se um sucessor muito feio.

If an attacker knows the DN of the default domain Administrator account (CN=administrator,CN=Users, DC=<DOMAIN>,DC=<TLD>) or the KRBTGT account (CN=krbtgt,CN=Users,DC=<DOMAIN>,DC=<TLD>), they can misuse the controlled dMSA to completely take over the AD domain, and ultimately the AD forest.

OBSERVAÇÃO: A conta KRBTGT pode ser movida para um modelo de classificação por níveis protegido e oculto, mas a Microsoft não recomenda movê-la.3

OBSERVAÇÃO: A conta de Administrador pode ser movida para um modelo de classificação por níveis protegido e oculto. Também não há problema em mudar-lhe o nome.4

Se decidir mover a conta de Administrador de domínio predefinida ou a conta KRBTGT para a estrutura de níveis administrativos, certifique-se de que coloca ambas numa UO separada (ou seja, não combinada com outras contas) e concede acesso a essa UO apenas a contas de administrador de Nível 0.

Como bloquear os sucessores

Analisando o funcionamento interno atual de uma dMSA a partir de um "bom sucessor" e de um "mau e feio sucessor", os objectivos da minha investigação foram os seguintes

  • R: Suportar todos os casos de utilização descritos
  • B: Permitir e apoiar o bom sucessor
  • C: Bloquear o sucessor mau e feio

As escritas LDAP normais, conforme descrito para o sucessor mau e feio, requerem que o ator tenha permissões específicas num dMSA. A utilização dos cmdlets do PowerShell requer que o ator seja membro de Admins. do Domínio.

Como referi anteriormente, os cmdlets do PowerShell executam acções diferentes na conta de serviço antiga e na dMSA, tirando partido de um atributo operacional com dados de entrada.

Com estes pensamentos, revi o esquema do AD - especificamente a definição do esquema do msDS-ManagedAccountPrecededByLink pois controla qual a conta que está a ser migrada (oficialmente) ou atacada (Figura 1).

Embora o atributo msDS-DelegatedMSAState desempenha um papel importante, tem ainda de ser gerido através da execução de uma escrita LDAP normal para poder definir o estado do dMSA para 3 quando o utilizar nativamente e não para efeitos de migração.

Figura 1: A definição original do esquema AD do atributo msDS-ManagedAccountPrecededByLink com systemOnly definido como FALSE

Olhando para a definição do atributo apresentado, a minha intenção era bloquear as escritas LDAP normais e suportar escritas de atributos operacionais. Com isso em mente, a propriedade systemOnly destacou-se, pois esperava que atingisse o objetivo da investigação. Esse atributo não pode ser alterado como qualquer outro atributo regular. Uma caraterística do CD tem primeiro de ser activada para suportar uma ação de escrita especial e depois desactivada novamente. A intenção do bloco é impedir o WRITE regular, mas ainda permitir o READ.

Vamos ver isto passo a passo.

Figura 2 mostra a verificação da configuração do dMSA dMSA.weak.5 Essa dMSA tem o seu estado inicial e nenhuma conta está ligada a ela (ou seja, nenhuma conta é apresentada).

Figura 2: Visualização da configuração do dMSA: dMSA.weak

O atacante define o estado de dMSA.weak para 2configura uma conta ligada (o administrador de domínio predefinido, que foi renomeado neste AD para ADM.TEC) e acrescenta-se a si próprio como a conta autorizada a obter a palavra-passe/chaves do dMSA6 (Figura 3). Neste caso, a ação é possível porque o atacante tem uma conta que é membro do grupo de Operadores de Conta antigos.

Figura 3: Reconfiguração dMSA.weak por uso indevido

De seguida, verificamos a configuração de dMSA.weak5 (Figura 4).

Figura 4: Visualização da configuração de dMSA.weak

A dMSA tem agora o estado de migração concluído 2tem uma conta ligada a ela e o atacante pode obter a palavra-passe/chaves da dMSA. Usando RUBEUS, por exemplo, o ataque pode ser iniciado contra o dMSA e especialmente contra a conta ligada.

Em seguida, removemos a configuração anterior6 e validamos que foi efetivamente removida5(Figura 5 e Figura 6).

Figura 5: Remover a configuração previamente definida de dMSA.weak
Figura 6: Visualização da configuração de dMSA.weak

Agora podemos ver o estado do bloco7(Figura 7).

Figura 7: Revisão do estado do bloco no atributo (False indica não bloqueado)

Em seguida, activamos o bloco para o cenário de migração8(Figura 8).

Figura 8: Ativação do bloco no atributo (True indica bloqueado)

Mais uma vez, confirmamos o estado do bloco7(Figura 9).

Figura 9: Revisão do estado do bloco no atributo (True indica bloqueado)

O atacante tenta agora novamente6 para:

  • Definir o estado de dMSA.weak para 2
  • Configurar uma conta associada (novamente o administrador de domínio predefinido renomeado)
  • Adicionar a si próprio como a conta autorizada a obter a palavra-passe/chaves do dMSA(Figura 10).

Agora, a transação não é concluída porque o atacante não está autorizado a escrever o DN da conta associada.
Objetivo C alcançado!

Figura 10: Tentativa de reconfiguração dMSA.weak por uso indevido

Agora, vamos verificar novamente a configuração do dMSA.weak5 (Figura 11).

Figura 11: Visualização da configuração de dMSA.weak

Como a transação completa falhou, nada foi alterado. Se os atributos fossem escritos individualmente, todos teriam sido bem sucedidos, exceto a escrita no msDS-ManagedAccountPrecededByLink atributo. Não é apresentado nada, uma vez que não tem um valor.

Com o bloqueio ativado, o uso da maneira oficial de migrar uma conta de serviço herdada para um dMSA também falha(Figura 12). Isso é lamentável. No entanto, há luz no fim do túnel!

O objetivo do bloco é impedir as escritas contra o msDS-ManagedAccountPrecededByLink atributo. Analisando os cmdlets oficiais do PowerShell para a migração, apenas os cmdlets Start-ADServiceAccountMigration e Reset-ADServiceAccountMigration escrever nesse atributo. O cmdlet Undo-ADServiceAccountMigration também escreve nesse atributo quando anula o passo de iniciado para inicial. Noutras transições, não é necessário nem executado qualquer registo nesse atributo.

Objectivos A e B: parcialmente alcançados.

Figura 12: Iniciar a migração oficial de uma conta de serviço antiga sVC.SQL para uma dMSA chamada dMSA.SQL$

Em seguida, desactivamos o bloco para o cenário de migração9(Figura 13).

Figura 13: Desativar o bloqueio do atributo (False indica não bloqueado)

Agora, voltamos a ver o estado do bloco7(Figura 14).

Figura 14: Revisão do estado do bloco no atributo (False indica não bloqueado)

Agora, quando o atacante tenta6:

  • Definir o estado de dMSA.weak para 2
  • Configurar uma conta associada (novamente o administrador de domínio predefinido renomeado)
  • Adicionar a si próprio como a conta autorizada a obter a palavra-passe/chaves do dMSA

-são bem sucedidos porque, mais uma vez, o bloco desapareceu(Figura 15).

Figura 15: Reconfiguração dMSA.weak por uso indevido

Agora, quando verificamos a configuração do dMSA.weak5 (Figura 16), vemos que o atacante tem o estado de migração concluído 2tem uma conta ligada à dMSA e está autorizado a obter a palavra-passe/chaves da dMSA.

Figura 16: Visualização da configuração de dMSA.weak

Com o bloco desativado, também podemos utilizar o método oficial para iniciar, concluir e repor com êxito a migração de uma conta de serviço legado para uma dMSA(Figura 17). Para este exemplo, foi utilizada outra conta de serviço antiga e dMSA, e a migração foi executada por uma conta de Administrador do Domínio.

Figura 17: Iniciar, concluir e repor a migração da conta de serviço antiga sVC.SQL para uma dMSA chamada dMSA.SQL$

O bloqueio do BadSuccessor requer uma gestão prática

Com esta solução, é possível bloquear o cenário de migração dMSA e, por conseguinte, qualquer utilização indevida.

Continuamos a encorajar as organizações a reverem proactivamente o seu modelo de delegação2 e a agirem em conformidade para mitigar qualquer risco. Neste contexto, o foco da revisão está na criação e gestão de dMSAs em qualquer domínio AD.

As organizações que pretendam atualizar para o Windows Server 2025 AD ou instalar um novo Windows Server 2025 AD podem implementar esta solução para mitigar os riscos de um ataque até a Microsoft lançar um patch.

A implementação do bloqueio no cenário de migração é efectuada no esquema AD e a alteração é reversível: Pode ser definido como block8 e, numa fase posterior, definido como unblock7. Isto significa que são possíveis várias abordagens de gestão.

A sua organização pode implementar este bloco porque não pretende utilizar dMSAs para o cenário de migração.

Se a sua organização pretender utilizar dMSAs para o cenário de migração, pode continuar a implementar o bloco para proteger o AD. Sempre que pretender iniciar a migração de uma conta, pode remover o bloqueio antecipadamente e voltar a implementá-lo posteriormente. Pode concluir a migração de uma conta com ou sem o bloco implementado.

Com esta abordagem, é possível atingir os objectivos A, B e C.

Mesmo que implemente um bloco, os IOEs e IOCs do Semperis DSP ajudam a monitorizar de perto os eventos de criação, gestão e autenticação do dMSA, bem como as modificações de atributos.

Saiba mais sobre os perigos de privilégios excessivos no AD

Notas finais

  1. BadSuccessor: Abusar do dMSA para aumentar os privilégios no Active Diretory
  2. (2025-05-25) Revisando seu modelo de delegação antes de introduzir DCs W2K25 e melhorar a segurança (devido a "BadSuccessor")
  3. Microsoft Learn: Atributos da conta KRBTGT
  4. Microsoft Learn: Conta de administrador
  5. Sucessor Mau - VER DADOS EM ATRIBUTOS "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink"
  6. Mau sucessor - ESCREVER DADOS NOS ATRIBUTOS "msDS-groupMSAMembership", "msDS-DelegatedMSAState", "msDS-ManagedAccountPrecededByLink"
  7. Mau sucessor - VER ESTADO DO BLOCO
  8. Mau sucessor - BLOCO DE ADICÇÃO/ENABLAGEM
  9. Mau Sucessor - REMOÇÃO/DESABORTO DO BLOCO

DECLARAÇÃ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.