Como se recuperar de um ataque gMSA dourado

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

Sintomas

Para obter uma descrição de um ataque Golden gMSA, consulte o seguinte artigo da Semperis:

Apresentando o Golden GMSA Attack

A descrição no artigo acima é precisa. A abordagem para resolver o problema é substituir o objeto de chave raiz do Microsoft Key Distribution Service (kdssvc.dll, também conhecido como KDS) e todas as gMSAs que usam o objeto de chave raiz KDS comprometido.

Mais informações

Em um ataque bem-sucedido a uma gMSA, o invasor obtém todos os atributos importantes do objeto de chave raiz do KDS 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 ao ataque Golden gMSA. No entanto, se o invasor puder se autenticar em um controlador de domínio de um domínio diferente na floresta, ele poderá ter permissões suficientes para obter o conteúdo do msds-ManagedPasswordID. O invasor poderia então usar essas informações para criar um ataque contra gMSAs em domínios adicionais.

Para proteger domínios adicionais de sua floresta depois que um domínio foi exposto, você precisa substituir todas as 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, sugere-se aplicar a resolução a todos os domínios da floresta.

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

Observação

A auditoria ajuda apenas a detectar um ataque online nos dados da chave raiz do KDS.

Você pode considerar definir o ManagedPasswordIntervalInDays parâmetro como 15 dias ou escolher um valor apropriado ao criar uma gMSA, pois o ManagedPasswordIntervalInDays valor se torna somente leitura após a criação de uma gMSA.

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

Isso reduzirá o número teórico de gMSA a serem recriados entre a data do backup restaurado e o final da exposição do banco de dados ou, pelo menos, a duração da janela de risco até que essas gMSAs sejam implementadas, se você ficar com o Cenário 1.

Este é um cenário de exemplo:

1. Após uma exposição do 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 de gMSA ManagedPasswordIntervalInDays é 15.

4. gMSAs existem e rolaram D-1.

5. As gMSAs mais recentes foram criadas a partir de D-10.

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

Estes são os resultados:

1. gMSAs criados entre D e D-5 não estão em causa^*.

2. As gMSAs criadas entre D-15 (backup restaurado) e D-5 (comprometimento)^* 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, as gMSAs criadas em D-10 devem ser recriadas.
   • Em D+10, as gMSAs criadas em D-5 devem ser recriadas.

   ^*Depende da hora exata do comprometimento ou backup.

Aqui está um exemplo de linha do tempo:

Para depuração, você pode examinar as IDs de evento para o log de eventos Sistema, Segurança, Serviços de Diretório e Security-Netlogon.

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

Resolução

Para resolver esse problema, use uma das seguintes abordagens, dependendo da sua situação. As abordagens envolvem a criação de um novo objeto de Chave Raiz do KDS 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, poderá resolver o problema sem recriar as gMSAs, conforme mostrado no procedimento abaixo.

A abordagem é criar um novo objeto de chave raiz do KDS desconhecido para o invasor. Quando as gMSAs rolarem sua senha, elas passarão a usar o novo objeto de Chave Raiz do KDS. Para corrigir gMSAs que rolaram recentemente sua senha usando a Chave Raiz do 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 as gMSAs que foram criadas após o término da exposição do banco de dados dos Serviços de Domínio Active Directory (AD DS). O invasor não sabe os detalhes dessas contas e as senhas dessas contas serão regeneradas com base no novo objeto de Chave Raiz do KDS.
• Você deve considerar o objeto gMSA no "modo de manutenção" até que o procedimento seja concluído e ignorar possíveis erros relatados com as contas no log de eventos do Sistema, Segurança, Serviços de Diretório e Security-Netlogon.
• O guia pressupõe que as gMSAs são objetos filho do contêiner de Contas de Serviço Gerenciado . Se você moveu as contas para contêineres pai personalizados, precisará executar as etapas relacionadas ao contêiner Contas de Serviço Gerenciado na gMSA nesses contêineres.
• Uma restauração autoritativa reverte todos os atributos para o 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 as gMSAs que você deseja reparar, siga estas etapas:

1. Coloque 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 para as gMSAs for maior que a idade do backup, você poderá decidir tolerar a janela em que o material de chave anterior ainda funciona. Se você não puder esperar tanto tempo e o backup mais antigo correspondente não tiver muitas gMSAs, será necessário mudar o plano para o Cenário 2.

3. Execute uma operação de restauração autoritativa no contêiner de 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 status da última 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 de Chave Raiz do KDS.

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 Chave Raiz KDS.

   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 poderá ser usada.

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

7. Crie uma nova gMSA. Certifique-se de que a nova gMSA use o novo objeto de chave raiz do KDS para criar o valor para o msds-ManagedPasswordID atributo.

   Observação

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

8. Verifique o msds-ManagedPasswordID valor da primeira gMSA que você criou. O valor desse atributo são dados binários que incluem o GUID do objeto de Chave Raiz do KDS correspondente.

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

   

   Uma gMSA criada usando esse objeto tem um msds-ManagedPasswordID valor semelhante ao seguinte.

   

   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 peças reordenadas. A seção laranja identifica a parte da sequência que é igual ao GUID original.

   Se a primeira gMSA que você criou usar a nova chave raiz do KDS, todas as 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 coloque o controlador de domínio restaurado online novamente. Verifique se a replicação está funcionando.

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

11. Reative e inicie o Serviço de Distribuição de Chaves da Microsoft em todos os controladores de domínio. Os segredos das gMSAs restauradas serão exibidos e novas senhas serão criadas com base no novo objeto de Chave Raiz do KDS mediante solicitação.

    Observação

    Se as gMSAs forem restauradas, mas não usadas, e tiverem o PrincipalsAllowedToRetrieveManagedPassword parâmetro preenchido, você poderá executar o Test-ADServiceAccount cmdlet na gMSA restaurada usando uma entidade de segurança que tenha permissão para recuperar a senha. Se uma alteração de senha for necessária, esse cmdlet distribuirá as gMSAs para a nova Chave Raiz do KDS.

12. Verifique se todas as gMSAs foram implementadas.

    Observação

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

13. Exclua o objeto de 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 conhece os detalhes da exposição do objeto de Chave Raiz do KDS e não pode esperar que as senhas sejam implementadas

Se você não souber quais informações foram expostas ou quando foram expostas, essa exposição pode 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 uma Recuperação de Floresta ou redefinir todas as senhas da conta. A recuperação das gMSAs para um estado limpo faz parte dessa atividade.

Durante o processo a seguir, você precisa criar um novo objeto de Chave Raiz do KDS. Em seguida, você usa esse objeto para substituir todas as gMSAs nos domínios da floresta que usam o objeto de chave raiz do KDS exposto.

Observação

As etapas a seguir são semelhantes ao procedimento em Introdução às contas de serviço gerenciado de grupo. No entanto, existem algumas mudanças importantes.

Siga estas etapas:

1. Desative todas as gMSAs existentes e marque-as 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 (desabilitado )).

   Você pode usar um script do PowerShell como este 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 de Chave Raiz KDS.

   2. Reinicie o Serviço de Distribuição de Chaves da Microsoft. Depois de reiniciado, o serviço seleciona 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 as gMSAs existentes para remover os SPNs e os nomes de host DNS.

   5. Crie novas gMSAs para substituir as 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 podem mais ser resolvidos. Ao substituir uma entrada de controle de acesso (ACE), considere o uso de grupos para gerenciar entradas de permissão gMSA.

3. Verifique as novas gMSAs para garantir que elas usem o novo objeto de chave raiz do KDS. Para fazer isso, siga estas etapas:

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

   2. Verifique o msds-ManagedPasswordID valor da primeira gMSA que você criou. O valor desse atributo são dados binários que incluem o GUID do objeto de Chave Raiz do KDS correspondente.

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

      

      Uma gMSA criada usando esse objeto tem um msds-ManagedPasswordID valor semelhante à imagem.

      

      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 peças reordenadas. A seção laranja identifica a parte da sequência que é igual ao GUID original.

      Se a primeira gMSA que você criou usar a nova chave raiz do KDS, todas as gMSAs subsequentes também usarão a nova chave.

4. Atualize os serviços apropriados para usar as novas gMSAs.

5. Exclua as gMSAs antigas que usavam o objeto de 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 de 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: renúncia de um administrador de domínio, nenhuma informação foi roubada no momento e você pode esperar que as senhas sejam roladas

Se um membro altamente privilegiado com administradores de domínio ou direitos equivalentes renunciar, não há prova da exposição da chave raiz do KDS no momento e você pode pagar uma janela de tempo para rolagem de senha. Você não precisa recriar as gMSAs.

Como medida preventiva, a chave raiz do KDS deve ser rolada 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 de chave raiz do KDS é criado e as gMSAs serão distribuídas naturalmente.

Observação

Para um comprometimento relacionado a um administrador de domínio, consulte o Cenário 1 ou o 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 de identidade sistêmica".

No domínio que contém as gMSAs que você deseja implantar, 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 Chave Raiz KDS.

   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 poderá ser usada.

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

3. Crie uma nova gMSA. Certifique-se de que a nova gMSA use o novo objeto de chave raiz do KDS para criar o valor para o msds-ManagedPasswordID atributo.

   Observação

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

4. Verifique o msds-ManagedPasswordID valor da primeira gMSA que você criou. O valor desse atributo são dados binários que incluem o GUID do objeto de Chave Raiz do KDS correspondente.

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

   

   Uma gMSA criada usando esse objeto tem um msds-ManagedPasswordID valor semelhante à imagem a seguir.

   

   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 peças reordenadas. A seção laranja identifica a parte da sequência que é igual ao GUID original.

   Se a primeira gMSA que você criou usar a nova chave raiz do KDS, todas as gMSAs subsequentes também usarão a nova chave.

5. Dependendo da próxima rolagem de senha, os segredos das gMSAs serão rolados naturalmente e novas senhas serão criadas com base no novo objeto de Chave Raiz do KDS mediante solicitação.

   Observação

   Se as gMSAs usadas tiverem sido distribuídas, mas as gMSAs não utilizadas com o mesmo intervalo de distribuição não tiverem sido e tiverem o parâmetro preenchido PrincipalsAllowedToRetrieveManagedPassword , você poderá executar o Test-ADServiceAccount cmdlet. Ele usa uma entidade de segurança que tem permissão para recuperar a senha da gMSA e essa etapa move a gMSA para a nova Chave Raiz do KDS.

6. Verifique se todas as gMSAs foram implementadas.

   Observação

   O gMSA sem o PrincipalsAllowedToRetrieveManagedPassword parâmetro nunca rolará.

7. Depois que todas as gMSAs tiverem sido transferidas para o novo objeto de chave raiz do KDS, exclua o objeto de chave raiz do KDS 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 Gerenciado de 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.