Share via

Como se recuperar de um ataque gMSA dourado

  • Artigo

Este artigo descreve uma abordagem para reparar as credenciais de um grupo de gMSA (Conta de Serviço Gerenciado) que são afetadas por um incidente de exposição do banco de dados do controlador de domínio.

Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Sintomas

Para obter uma descrição de um ataque gMSA dourado, consulte o seguinte artigo semperis:

Apresentando o ataque GMSA dourado

A descrição no artigo acima é precisa. A abordagem para resolver o problema é substituir o objeto chave raiz do Serviço de Distribuição de Chaves da Microsoft (kdssvc.dll, também conhecido como KDS) e todos os gMSAs que usam o objeto chave raiz KDS comprometido.

Mais informações

Em um ataque bem-sucedido a um gMSA, o invasor obtém todos os atributos importantes do objeto KDS Root Key e os Sid atributos e msds-ManagedPasswordID de um objeto gMSA.

O msds-ManagedPasswordID atributo está presente apenas em uma cópia gravável do domínio. Portanto, se o banco de dados de um controlador de domínio for exposto, somente o domínio que o controlador de domínio hospeda estará aberto para o ataque gMSA dourado. No entanto, se o invasor puder se autenticar em um controlador de domínio de um domínio diferente na floresta, o invasor poderá ter permissões suficientes para obter o conteúdo de msds-ManagedPasswordID. Em seguida, o invasor pode usar essas informações para criar um ataque contra gMSAs em domínios adicionais.

Para proteger domínios adicionais da floresta depois que um domínio tiver sido exposto, você precisa substituir todos os gMSAs no domínio exposto antes que o invasor possa usar as informações. Normalmente, você não sabe os detalhes do que foi exposto. Portanto, é sugerido aplicar a resolução a todos os domínios da floresta.

Como medida proativa, a auditoria pode ser usada para controlar a exposição do objeto Chave Raiz do KDS. Uma SACL (lista de controle de acesso do sistema) com leituras bem-sucedidas pode ser colocada no contêiner chaves raiz mestre, o que permite a auditoria de leituras bem-sucedidas no msKds-RootKeyData atributo da msKds-ProvRootKey classe. Esta ação determina a paisagem de exposição do objeto em relação a um ataque gMSA dourado.

Observação

A auditoria só ajuda a detectar um ataque online aos dados da Chave Raiz do KDS.

Você pode considerar definir o ManagedPasswordIntervalInDays parâmetro como 15 dias ou escolher um valor apropriado ao criar um gMSA, pois o ManagedPasswordIntervalInDays valor se torna somente leitura depois que um gMSA é criado.

Em caso de comprometimento, essa configuração pode reduzir o próximo tempo de rolagem.

Ele reduzirá o número teórico de gMSA a ser recriado entre a data do backup restaurado e o fim da exposição do banco de dados ou, pelo menos, a duração da janela de risco até que esses gMSAs rolem, se você ficar com o Cenário 1.

Aqui está um cenário de exemplo:

  1. Após uma exposição de banco de dados, você executa a recuperação no "Dia D".

  2. O backup restaurado é do D-15.

    Observação

    D-15 significa o dia que é 15 dias antes do "Dia D".

  3. O valor gMSA ManagedPasswordIntervalInDays é 15.

  4. GMSAs existem e rolaram D-1.

  5. GMSAs mais recentes foram criados a partir do D-10.

  6. O compromisso acontece no D-5 e alguns gMSAs foram criados nesta data.

Aqui estão os resultados:

  1. GMSAs criadas entre D e D-5 não estão preocupadas*.

  2. GMSAs criadas entre d-15 (backup restaurado) e D-5 (compromisso)* devem ser recriadas ou as janelas de risco devem ser assumidas se você puder esperar de D+5 até D+10. Por exemplo:

    • Em D+5, gMSAs criadas na D-10 devem ser recriadas.
    • Em D+10, gMSAs criadas no D-5 devem ser recriadas.

    *Depende da hora exata do compromisso ou do backup.

Aqui está um exemplo linha do tempo:

Diagrama de um exemplo de gMSAs linha do tempo.

Para depuração, você pode examinar as IDs de evento para o log de eventos System, Security, Directory Services e Security-Netlogon.

Para obter mais informações sobre um compromisso, consulte Usar recursos de segurança da Microsoft e do Azure para ajudar a se recuperar do compromisso de identidade sistêmico.

Resolução

Para resolve esse problema, use uma das abordagens a seguir, dependendo da sua situação. As abordagens envolvem a criação de um novo objeto KDS Root Key e a reinicialização do Serviço de Distribuição de Chaves da Microsoft em todos os controladores de domínio do domínio.

Cenário 1: você tem informações confiáveis sobre quais informações foram expostas e quando

Se você souber que a exposição ocorreu antes de uma determinada data, e essa data for anterior à senha gMSA mais antiga que você tem, você pode resolve o problema sem recriar os gMSAs, conforme mostrado no procedimento abaixo.

A abordagem é criar um novo objeto KDS Root Key que é desconhecido para o invasor. Quando os gMSAs rolarem sua senha, eles passarão para o uso do novo objeto KDS Root Key. Para corrigir gMSAs que recentemente rolaram sua senha usando a chave raiz KDS antiga, uma restauração autoritativa é necessária para forçar uma atualização de senha imediatamente após a restauração.

Observação

  • Você não precisa reparar manualmente gMSAs que foram criadas após o término da exposição do banco de dados do Active Directory Domain Services (AD DS). O invasor não sabe os detalhes dessas contas e as senhas dessas contas serão regeneradas com base no novo objeto KDS Root Key.
  • Considere o objeto gMSA no "modo de manutenção" até que o procedimento seja concluído e ignore possíveis erros relatados com as contas no log de eventos System, Security, Directory Services e Security-Netlogon.
  • O guia pressupõe que os gMSAs são objetos filho do contêiner Contas de Serviço Gerenciado . Se você tiver movido as contas para contêineres pai personalizados, precisará executar as etapas relacionadas ao contêiner Contas de Serviço Gerenciado no gMSA nesses contêineres.
  • Uma restauração autoritativa reverte todos os atributos ao estado em que estavam no momento do backup, incluindo as contas que têm permissão para recuperar as credenciais gMSA (PrincipalsAllowedToRetrieveManagedPassword).

No domínio que contém os gMSAs que você deseja reparar, siga estas etapas:

  1. Tire um controlador de domínio offline e isole-o da rede.

  2. Restaure o controlador de domínio de um backup criado antes da exposição do banco de dados do AD DS.

    Se o intervalo de senha dos gMSAs for maior que a idade do backup, você poderá decidir tolerar a janela em que o material da chave anterior ainda funciona. Se você não puder esperar tanto tempo e o backup mais antigo correspondente estiver faltando muitos gMSAs, você precisará alternar o plano para o Cenário 2.

  3. Execute uma operação de restauração autoritativa no contêiner Contas de Serviço Gerenciado do domínio. Verifique se a operação de restauração inclui todos os objetos filho dos contêineres que podem estar associados a esse controlador de domínio. Esta etapa reverte o último status de atualização de senha. Na próxima vez que um serviço recuperar a senha, a senha será atualizada para uma nova com base no novo objeto KDS Root Key.

  4. Pare e desabilite o Serviço de Distribuição de Chaves da Microsoft no controlador de domínio restaurado.

  5. Em um controlador de domínio diferente, siga as etapas em Criar a Chave Raiz KDS dos Serviços de Distribuição de Chaves para criar um novo objeto KDS Root Key.

    Observação

    No ambiente de produção, você precisa aguardar 10 horas para garantir que a nova chave raiz do KDS esteja disponível. Verifique o EffectiveTime atributo para saber quando a nova chave raiz do KDS será utilizável.

  6. Reinicie o Serviço de Distribuição de Chaves da Microsoft em todos os controladores de domínio.

  7. Crie um novo gMSA. Verifique se o novo gMSA usa o novo objeto KDS Root Key para criar o valor do msds-ManagedPasswordID atributo.

    Observação

    Essa etapa é opcional, mas permite que você valide que a nova Chave Raiz do KDS está atualmente em uso e usada no Serviço de Distribuição de Chaves da Microsoft.

  8. Verifique o msds-ManagedPasswordID valor do primeiro gMSA que você criou. O valor desse atributo são dados binários que incluem o GUID do objeto chave raiz KDS correspondente.

    Por exemplo, suponha que o objeto Chave Raiz do KDS tenha o seguinte CN.

    Captura de tela que mostra o valor do atributo CN de um objeto chave raiz KDS.

    Um gMSA criado usando esse objeto tem um msds-ManagedPasswordID valor que se assemelha ao seguinte.

    Captura de tela do valor do atributo msDS-ManagedPasswordId de um objeto gMSA, mostrando como ele inclui as partes do atributo CN da chave raiz KDS.

    Nesse valor, os dados GUID começam no deslocamento 24. As partes do GUID estão em uma sequência diferente. Nesta imagem, as seções vermelha, verde e azul identificam as partes reordenadas. A seção laranja identifica a parte da sequência que é a mesma que o GUID original.

    Se o primeiro gMSA que você criou usar a nova chave raiz KDS, todos os gMSAs subsequentes também usarão a nova chave.

  9. Desabilite e interrompa o Serviço de Distribuição de Chaves da Microsoft em todos os controladores de domínio.

  10. Reconecte e retome o controlador de domínio restaurado. Verifique se a replicação está funcionando.

    Agora, a restauração autoritativa e todas as outras alterações (incluindo os gMSAs restaurados) são replicadas.

  11. Habilite novamente e inicie o Serviço de Distribuição de Chaves da Microsoft em todos os controladores de domínio. Os segredos dos gMSAs restaurados serão rolados e novas senhas serão criadas com base no novo objeto KDS Root Key após a solicitação.

    Observação

    Se os gMSAs forem restaurados, mas não forem usados e tiverem o PrincipalsAllowedToRetrieveManagedPassword parâmetro preenchido, você poderá executar o Test-ADServiceAccount cmdlet no gMSA restaurado usando uma entidade de segurança que tem permissão para recuperar a senha. Se uma alteração de senha for necessária, esse cmdlet rolará os gMSAs para a nova chave raiz do KDS.

  12. Verifique se todos os gMSAs foram enrolados.

    Observação

    O gMSA sem o PrincipalsAllowedToRetrieveManagedPassword parâmetro preenchido nunca será rolado.

  13. Exclua o objeto chave raiz do KDS antigo e verifique as replicações.

  14. Reinicie o Serviço de Distribuição de Chaves da Microsoft em todos os controladores de domínio.

Cenário 2: Você não sabe os detalhes da exposição do objeto Chave Raiz do KDS e não pode esperar que as senhas rolem

Se você não souber quais informações foram expostas ou quando elas foram expostas, essa exposição poderá fazer parte de uma exposição completa da floresta do Active Directory. Isso pode criar uma situação em que o invasor pode executar ataques offline em todas as senhas. Nesse caso, considere executar um Forest Recovery ou redefinir todas as senhas da conta. Recuperar os gMSAs em um estado de limpo faz parte dessa atividade.

Durante o processo a seguir, você precisa criar um novo objeto KDS Root Key. Em seguida, você usa esse objeto para substituir todos os gMSAs nos domínios da floresta que usam o objeto KDS Root Key exposto.

Observação

As etapas a seguir se assemelham ao procedimento que está em Introdução com contas de serviço gerenciadas em grupo. No entanto, há algumas alterações importantes.

Siga estas etapas:

  1. Desabilite todos os gMSAs existentes e marque-os como contas a serem removidas. Para fazer isso, para cada conta, defina o userAccountControl atributo como 4098 (esse valor combina sinalizadores WORKSTATION_TRUST_ACCOUNT e ACCOUNTDISABLE (desabilitados ).

    Você pode usar um script do PowerShell assim para definir as contas:

     $Domain = (Get-ADDomain).DistinguishedName
 $DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter 'objectclass=msDS-GroupManagedServiceAccount').DistinguishedName
 ForEach ($GMSA In $DomainGMSAs)
 {
     Set-ADObject "$GMSA" -Add @{ adminDescription='cleanup-gsma' } -Replace @{ userAccountControl=4098 }
 }

  2. Use um único controlador de domínio e siga estas etapas:

    1. Siga as etapas em Criar a Chave Raiz KDS dos Serviços de Distribuição de Chaves para criar um novo objeto KDS Root Key.

    2. Reinicie o Serviço de Distribuição de Chaves da Microsoft. Depois que ele é reiniciado, o serviço pega o novo objeto.

    3. Faça backup de nomes de host DNS e SPNs (nomes de entidade de serviço) associados a cada gMSA marcada para ser removida.

    4. Edite os gMSAs existentes para remover os nomes de host SPNs e DNS.

    5. Crie novos gMSAs para substituir os gMSAs existentes. Eles também precisam ser configurados com os nomes de host DNS e SPNs que você acabou de remover.

      Observação

      Você também precisa examinar todas as entradas de permissão usando os SIDs gMSA removidos diretamente, pois eles não são mais resolvíveis. Ao substituir uma ACE (entrada de controle de acesso), considere usar grupos para gerenciar entradas de permissão gMSA.

  3. Verifique os novos gMSAs para garantir que eles usem o novo objeto chave raiz do KDS. Para fazer isso, siga estas etapas:

    1. Observe o CN valor (GUID) do objeto Chave Raiz do KDS.

    2. Verifique o msds-ManagedPasswordID valor do primeiro gMSA que você criou. O valor desse atributo são dados binários que incluem o GUID do objeto chave raiz KDS correspondente.

      Por exemplo, suponha que o objeto Chave Raiz do KDS tenha o seguinte CN.

      Captura de tela do valor do atributo CN de um objeto chave raiz KDS.

      Um gMSA criado usando esse objeto tem um msds-ManagedPasswordID valor que se assemelha à imagem.

      Captura de tela do valor do atributo msDS-ManagedPasswordId de um objeto gMSA, mostrando como ele inclui as partes do atributo CN da chave raiz KDS.

      Nesse valor, os dados GUID começam no deslocamento 24. As partes do GUID estão em uma sequência diferente. Nesta imagem, as seções vermelha, verde e azul identificam as partes reordenadas. A seção laranja identifica a parte da sequência que é a mesma que o GUID original.

      Se o primeiro gMSA que você criou usar a nova chave raiz KDS, todos os gMSAs subsequentes também usarão a nova chave.

  4. Atualize os serviços apropriados para usar os novos gMSAs.

  5. Exclua os gMSAs antigos que usaram o objeto chave raiz do KDS antigo usando o seguinte cmdlet:

    $Domain = (Get-ADDomain).DistinguishedName
$DomainGMSAs = (Get-ADObject -Searchbase "$Domain" -LdapFilter '(&(objectClass=msDS-GroupManagedServiceAccount)(adminDescription=cleanup-gsma))').DistinguishedName
ForEach ($GMSA In $DomainGMSAs)
{
    Remove-ADObject "$GMSA" -Confirm:$False
}

  6. Exclua o objeto chave raiz do KDS antigo e verifique as replicações.

  7. Reinicie o Serviço de Distribuição de Chaves da Microsoft em todos os controladores de domínio.

Cenário 3: demissão de um administrador de domínio, nenhuma informação foi roubada no momento e você pode aguardar a distribuição de senhas

Se um membro altamente privilegiado com administradores de domínio ou direitos equivalentes renunciar, não haverá nenhuma prova da exposição da Chave Raiz do KDS no momento e você poderá pagar uma janela de tempo para a rolagem de senha. Você não precisa recriar os gMSAs.

Como medida preventiva, a Chave Raiz do KDS deve ser revertida para evitar ataques pós-exploração. Por exemplo, um ex-administrador de domínio acabou sendo um desonesto e manteve alguns backups.

Um novo objeto KDS Root Key é criado e gMSAs serão rolados naturalmente.

Observação

Para obter um compromisso relacionado a um administrador de domínio, consulte Cenário 1 ou Cenário 2 de acordo com o que foi exposto e siga as atividades de correção local em "Usar recursos de segurança da Microsoft e do Azure para ajudar a se recuperar do comprometimento sistêmico da identidade".

No domínio que contém os gMSAs que você deseja rolar, siga estas etapas:

  1. Em um controlador de domínio, siga as etapas em Criar a Chave Raiz KDS dos Serviços de Distribuição de Chaves para criar um novo objeto KDS Root Key.

    Observação

    No ambiente de produção, você precisa aguardar 10 horas para garantir que a nova chave raiz do KDS esteja disponível. Verifique o EffectiveTime atributo para saber quando a nova chave raiz do KDS será utilizável.

  2. Reinicie o Serviço de Distribuição de Chaves da Microsoft em todos os controladores de domínio.

  3. Crie um novo gMSA. Verifique se o novo gMSA usa o novo objeto KDS Root Key para criar o valor do msds-ManagedPasswordID atributo.

    Observação

    Essa etapa é opcional, mas permite que você valide que a nova Chave Raiz do KDS está atualmente em uso e usada no Serviço de Distribuição de Chaves da Microsoft.

  4. Verifique o msds-ManagedPasswordID valor do primeiro gMSA que você criou. O valor desse atributo são dados binários que incluem o GUID do objeto chave raiz KDS correspondente.

    Por exemplo, suponha que o objeto Chave Raiz do KDS tenha o seguinte CN.

    Captura de tela do valor do atributo CN de um objeto chave raiz KDS.

    Um gMSA criado usando esse objeto tem um msds-ManagedPasswordID valor que se assemelha à imagem a seguir.

    Captura de tela do valor do atributo msDS-ManagedPasswordId de um objeto gMSA, mostrando como ele inclui as partes do atributo CN da chave raiz KDS.

    Nesse valor, os dados GUID começam no deslocamento 24. As partes do GUID estão em uma sequência diferente. Nesta imagem, as seções vermelha, verde e azul identificam as partes reordenadas. A seção laranja identifica a parte da sequência que é a mesma que o GUID original.

    Se o primeiro gMSA que você criou usar a nova chave raiz KDS, todos os gMSAs subsequentes também usarão a nova chave.

  5. Dependendo do próximo rolo de senha, os segredos dos gMSAs serão naturalmente rolados e novas senhas serão criadas com base no novo objeto KDS Root Key após a solicitação.

    Observação

    Se os gMSAs usados tiverem rolado, mas gMSAs não utilizados com o mesmo intervalo de rolagem não tiverem, e eles tiverem o PrincipalsAllowedToRetrieveManagedPassword parâmetro preenchido, você poderá executar o Test-ADServiceAccount cmdlet. Ele usa uma entidade de segurança que pode recuperar a senha gMSA e, em seguida, move o gMSA para a nova chave raiz do KDS.

  6. Verifique se todos os gMSAs foram enrolados.

    Observação

    O gMSA sem o PrincipalsAllowedToRetrieveManagedPassword parâmetro nunca será rolado.

  7. Depois que todos os gMSAs tiverem rolado para o novo objeto chave raiz do KDS, exclua o objeto KDS Root Key antigo e verifique as replicações.

  8. Reinicie o Serviço de Distribuição de Chaves da Microsoft em todos os controladores de domínio.

Referências

Visão geral das contas de serviço gerenciadas por grupo

Aviso de isenção de responsabilidade para contatos de terceiros

A Microsoft fornece informações de contato de terceiros para ajudá-lo a encontrar informações adicionais sobre esse tópico. Essas informações de contato podem ser alteradas sem aviso prévio. A Microsoft não garante a precisão das informações de contato de terceiros.