Comment récupérer après une attaque gMSA Golden

Cet article décrit une approche pour réparer les informations d’identification d’un compte de service administré de groupe (gMSA) qui sont affectées par un incident d’exposition de base de données de contrôleur de domaine.

              Sʼapplique à : Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Symptômes

Pour obtenir une description d’une attaque gMSA Golden, consultez l’article Semperis suivant :

Présentation de l’attaque GOLDEN GMSA

La description de l’article ci-dessus est exacte. L’approche pour résoudre le problème consiste à remplacer l’objet de clé racine du service de distribution de clés Microsoft (kdssvc.dll, également appelé KDS) et tous les gMSA qui utilisent l’objet clé racine KDS compromis.

Plus d’informations

Dans une attaque réussie sur un gMSA, l’attaquant obtient tous les attributs importants de l’objet clé racine KDS et les Sid attributs et msds-ManagedPasswordID d’un objet gMSA.

L’attribut msds-ManagedPasswordID est présent uniquement sur une copie accessible en écriture du domaine. Par conséquent, si la base de données d’un contrôleur de domaine est exposée, seul le domaine que le contrôleur de domaine héberge est ouvert à l’attaque Golden gMSA. Toutefois, si l’attaquant peut s’authentifier auprès d’un contrôleur de domaine d’un autre domaine dans la forêt, l’attaquant peut disposer des autorisations suffisantes pour obtenir le contenu de msds-ManagedPasswordID. L’attaquant peut ensuite utiliser ces informations pour créer une attaque contre des gMSA dans des domaines supplémentaires.

Pour protéger des domaines supplémentaires de votre forêt après l’exposition d’un domaine, vous devez remplacer tous les gMSA dans le domaine exposé avant que l’attaquant puisse utiliser les informations. En règle générale, vous ne connaissez pas les détails de ce qui a été exposé. Par conséquent, il est suggéré d’appliquer la résolution à tous les domaines de la forêt.

En tant que mesure proactive, l’audit peut être utilisé pour suivre l’exposition de l’objet clé racine KDS. Une liste de contrôle d’accès système (SACL) avec des lectures réussies peut être placée sur le conteneur Clés racines principales, ce qui permet d’auditer les lectures réussies sur l’attribut msKds-RootKeyData de la msKds-ProvRootKey classe. Cette action détermine le paysage d’exposition de l’objet en ce qui concerne une attaque golden gMSA.

Remarque

L’audit permet uniquement de détecter une attaque en ligne sur les données de clé racine KDS.

Vous pouvez envisager de définir le paramètre sur ManagedPasswordIntervalInDays 15 jours ou de choisir une valeur appropriée lors de la création d’un gMSA, car la ManagedPasswordIntervalInDays valeur devient en lecture seule après la création d’un gMSA.

En cas de compromission, ce paramètre peut réduire le temps de roulement suivant.

Cela réduira le nombre théorique de gMSA à recréer entre la date de la sauvegarde restaurée et la fin de l’exposition de la base de données, ou tout au moins la durée de la fenêtre de risque jusqu’à ce que ces gMSA soient exécutés, si vous vous en tenez au scénario 1.

Voici un exemple de scénario :

1. Après une exposition de base de données, vous effectuez la récupération au « Jour J ».

2. La sauvegarde restaurée est à partir de J-15.

   Remarque

   J-15 signifie le jour qui se trouve 15 jours avant le « jour D ».

3. La valeur gMSA ManagedPasswordIntervalInDays est 15.

4. Les gMSA existent et ont été roulés D-1.

5. Des gMSA plus récents ont été créés à partir de D-10.

6. La compromission se produit à D-5, et certains gMSA ont été créés à cette date.

Voici les résultats :

1. Les gMSA créés entre D et D-5 ne sont pas concernés^*.

2. Les gMSA créés entre D-15 (sauvegarde restaurée) et D-5 (compromission)^* doivent être recréés, ou les fenêtres de risque doivent être supposées si vous pouvez attendre de J+5 à D+10. Par exemple :

   • À J+5, les gMSA créés sur D-10 doivent être recréés.
   • À D+10, les gMSA créés sur D-5 doivent être recréés.

   ^*Dépend de l’heure exacte de la compromission ou de la sauvegarde.

Voici un exemple chronologie :

Pour le débogage, vous pouvez consulter les ID d’événements pour le journal des événements système, sécurité, services d’annuaire et Security-Netlogon.

Pour plus d’informations sur une compromission, consultez Utiliser des ressources de sécurité Microsoft et Azure pour faciliter la récupération après une compromission d’identité systémique.

Résolution

Pour résoudre ce problème, utilisez l’une des approches suivantes, en fonction de votre situation. Les approches impliquent la création d’un objet clé racine KDS et le redémarrage du service de distribution de clés Microsoft sur tous les contrôleurs de domaine du domaine.

Scénario 1 : Vous disposez d’informations fiables sur les informations qui ont été exposées et à quel moment

Si vous savez que l’exposition s’est produite avant une certaine date et que cette date est antérieure au mot de passe gMSA le plus ancien dont vous disposez, vous pouvez résoudre le problème sans recréer les gMSA, comme indiqué dans la procédure ci-dessous.

L’approche consiste à créer un objet clé racine KDS inconnu de l’attaquant. Lorsque les gMSA déploient leur mot de passe, ils passent à l’utilisation du nouvel objet clé racine KDS. Pour corriger les gMSA qui ont récemment annulé leur mot de passe à l’aide de l’ancienne clé racine KDS, une restauration faisant autorité est nécessaire pour forcer une mise à jour de mot de passe immédiatement après la restauration.

Remarque

• Vous n’avez pas besoin de réparer manuellement les gMSA créés après la fin de l’exposition de la base de données services de domaine Active Directory (AD DS). L’attaquant ne connaît pas les détails de ces comptes, et les mots de passe de ces comptes sont régénérés en fonction du nouvel objet clé racine KDS.
• Vous devez considérer l’objet gMSA en « mode maintenance » jusqu’à ce que la procédure soit terminée et ignorer les erreurs éventuelles signalées avec les comptes dans le journal des événements Système, Sécurité, Services d’annuaire et Security-Netlogon.
• Le guide suppose que les gMSA sont des objets enfants du conteneur Comptes de service gérés . Si vous avez déplacé les comptes vers des conteneurs parents personnalisés, vous devez exécuter les étapes liées au conteneur Comptes de service gérés sur le compte gMSA dans ces conteneurs.
• Une restauration faisant autorité restaure tous les attributs à l’état dans lequel ils se trouvaient au moment de la sauvegarde, y compris les comptes autorisés à récupérer les informations d’identification gMSA (PrincipalsAllowedToRetrieveManagedPassword).

Dans le domaine contenant les gMSA que vous souhaitez réparer, procédez comme suit :

1. Mettez un contrôleur de domaine hors connexion et isolez-le du réseau.

2. Restaurez le contrôleur de domaine à partir d’une sauvegarde créée avant l’exposition de la base de données AD DS.

   Si l’intervalle de mot de passe pour les gMSA est plus long que l’ancienneté de la sauvegarde, vous pouvez décider de tolérer la fenêtre où le matériel de clé précédent fonctionne toujours. Si vous ne pouvez pas attendre aussi longtemps et que l’ancienne sauvegarde correspondante manque trop de gMSA, vous devez basculer le plan vers le scénario 2.

3. Exécutez une opération de restauration faisant autorité sur le conteneur Comptes de service gérés du domaine. Assurez-vous que l’opération de restauration inclut tous les objets enfants des conteneurs qui peuvent être associés à ce contrôleur de domaine. Cette étape restaure la dernière mise à jour du mot de passe status. La prochaine fois qu’un service récupérera le mot de passe, le mot de passe sera mis à jour vers un nouveau mot de passe basé sur le nouvel objet clé racine KDS.

4. Arrêtez et désactivez le service de distribution de clés Microsoft sur le contrôleur de domaine restauré.

5. Sur un autre contrôleur de domaine, suivez les étapes décrites dans Créer la clé racine KDS des services de distribution de clés pour créer un objet clé racine KDS.

   Remarque

   Dans l’environnement de production, vous devez attendre 10 heures pour vous assurer que la nouvelle clé racine KDS est disponible. Vérifiez l’attribut EffectiveTime pour savoir quand la nouvelle clé racine KDS sera utilisable.

6. Redémarrez le service de distribution de clés Microsoft sur tous les contrôleurs de domaine.

7. Créez un gMSA. Assurez-vous que le nouveau gMSA utilise le nouvel objet clé racine KDS pour créer la valeur de l’attribut msds-ManagedPasswordID .

   Remarque

   Cette étape est facultative, mais elle vous permet de vérifier que la nouvelle clé racine KDS est actuellement utilisée et utilisée dans le service de distribution de clés Microsoft.

8. Vérifiez la msds-ManagedPasswordID valeur du premier compte gMSA que vous avez créé. La valeur de cet attribut est des données binaires qui incluent le GUID de l’objet clé racine KDS correspondant.

   Par exemple, supposons que l’objet clé racine KDS possède le code suivant CN.

   

   Un gMSA créé à l’aide de cet objet a une msds-ManagedPasswordID valeur qui ressemble à ce qui suit.

   

   Dans cette valeur, les données GUID commencent au décalage 24. Les parties du GUID se trouvent dans une séquence différente. Dans cette image, les sections rouge, verte et bleue identifient les parties réorganisées. La section orange identifie la partie de la séquence identique au GUID d’origine.

   Si le premier gMSA que vous avez créé utilise la nouvelle clé racine KDS, tous les gMSA suivants utilisent également la nouvelle clé.

9. Désactivez et arrêtez le service de distribution de clés Microsoft sur tous les contrôleurs de domaine.

10. Reconnectez-vous et rétablissez le contrôleur de domaine restauré. Vérifiez que la réplication fonctionne.

    À présent, la restauration faisant autorité et toutes les autres modifications (y compris les gMSA restaurés) sont répliquées.

11. Réactivez et démarrez le service de distribution de clés Microsoft sur tous les contrôleurs de domaine. Les secrets des gMSA restaurés sont roll, et de nouveaux mots de passe sont créés en fonction du nouvel objet clé racine KDS sur demande.

    Remarque

    Si les gMSA sont restaurés mais non utilisés et que le PrincipalsAllowedToRetrieveManagedPassword paramètre est renseigné, vous pouvez exécuter l’applet Test-ADServiceAccount de commande sur le gMSA restauré à l’aide d’un principal autorisé à récupérer le mot de passe. Si une modification de mot de passe est nécessaire, cette applet de commande roll les gMSA sur la nouvelle clé racine KDS.

12. Vérifiez que tous les gMSA ont été déployés.

    Remarque

    Le compte gMSA sans le PrincipalsAllowedToRetrieveManagedPassword paramètre rempli ne sera jamais roll.

13. Supprimez l’ancien objet clé racine KDS et vérifiez les réplications.

14. Redémarrez le service de distribution de clés Microsoft sur tous les contrôleurs de domaine.

Scénario 2 : Vous ne connaissez pas les détails de l’exposition de l’objet clé racine KDS et vous ne pouvez pas attendre que les mots de passe se déclenchent

Si vous ne savez pas quelles informations ont été exposées ou quand elles ont été exposées, une telle exposition peut faire partie d’une exposition complète de votre forêt Active Directory. Cela peut créer une situation dans laquelle l’attaquant peut exécuter des attaques hors connexion sur tous les mots de passe. Dans ce cas, envisagez d’exécuter une récupération de forêt ou de réinitialiser tous les mots de passe de compte. La récupération des gMSA à un état propre fait partie de cette activité.

Au cours du processus suivant, vous devez créer un objet clé racine KDS. Ensuite, vous utilisez cet objet pour remplacer tous les gMSA dans les domaines de la forêt qui utilisent l’objet clé racine KDS exposé.

Remarque

Les étapes suivantes ressemblent à la procédure décrite dans Prise en main avec les comptes de service gérés de groupe. Toutefois, il y a quelques changements importants.

Procédez comme suit :

1. Désactivez tous les gMSA existants et marquez-les comme comptes à supprimer. Pour ce faire, pour chaque compte, définissez l’attribut sur userAccountControl4098 (cette valeur combine les indicateurs WORKSTATION_TRUST_ACCOUNT et ACCOUNTDISABLE (désactivé ).

   Vous pouvez utiliser un script PowerShell comme celui-ci pour définir les comptes :

    $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. Utilisez un seul contrôleur de domaine et procédez comme suit :

   1. Suivez les étapes décrites dans Créer la clé racine KDS des services de distribution de clés pour créer un objet clé racine KDS.

   2. Redémarrez le service de distribution de clés Microsoft. Après son redémarrage, le service récupère le nouvel objet.

   3. Sauvegardez les noms d’hôte DNS et les noms de principal de service (SPN) associés à chaque gMSA marqué pour être supprimé.

   4. Modifiez les gMSA existants pour supprimer les NOMS de service et les noms d’hôte DNS.

   5. Créez des gMSA pour remplacer les gMSA existants. Ils doivent également être configurés avec les noms d’hôte DNS et les noms de service que vous venez de supprimer.

      Remarque

      Vous devez également examiner toutes les entrées d’autorisation à l’aide des SID gMSA directement supprimés, car ils ne peuvent plus être résolus. Lorsque vous remplacez une entrée de contrôle d’accès (ACE), envisagez d’utiliser des groupes pour gérer les entrées d’autorisation gMSA.

3. Vérifiez les nouveaux gMSA pour vous assurer qu’ils utilisent le nouvel objet clé racine KDS. Pour cela, procédez comme suit :

   1. Notez la CN valeur (GUID) de l’objet clé racine KDS.

   2. Vérifiez la msds-ManagedPasswordID valeur du premier compte gMSA que vous avez créé. La valeur de cet attribut est des données binaires qui incluent le GUID de l’objet clé racine KDS correspondant.

      Par exemple, supposons que l’objet clé racine KDS possède le code suivant CN.

      

      Un gMSA créé à l’aide de cet objet a une msds-ManagedPasswordID valeur qui ressemble à l’image.

      

      Dans cette valeur, les données GUID commencent au décalage 24. Les parties du GUID se trouvent dans une séquence différente. Dans cette image, les sections rouge, verte et bleue identifient les parties réorganisées. La section orange identifie la partie de la séquence identique au GUID d’origine.

      Si le premier gMSA que vous avez créé utilise la nouvelle clé racine KDS, tous les gMSA suivants utilisent également la nouvelle clé.

4. Mettez à jour les services appropriés pour utiliser les nouveaux gMSA.

5. Supprimez les anciens gMSA qui utilisaient l’ancien objet clé racine KDS à l’aide de l’applet de commande suivante :

   $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. Supprimez l’ancien objet clé racine KDS et vérifiez les réplications.

7. Redémarrez le service de distribution de clés Microsoft sur tous les contrôleurs de domaine.

Scénario 3 : Démission d’un administrateur de domaine, aucune information n’a été volée à ce moment-là, et vous pouvez attendre que les mots de passe se annulent

Si un membre hautement privilégié avec des administrateurs de domaine ou des droits équivalents démissionne, il n’y a aucune preuve de l’exposition de la clé racine KDS à ce moment-là, et vous pouvez vous permettre une fenêtre de temps pour le passage du mot de passe. Vous n’avez pas besoin de recréer les gMSA.

À titre préventif, la clé racine KDS doit être déployée pour empêcher toute attaque post-exploitation. Par exemple, un ancien administrateur de domaine s’est avéré être un non autorisé et a conservé certaines sauvegardes.

Un nouvel objet clé racine KDS est créé, et les gMSA se déclenchent naturellement.

Remarque

Pour obtenir une compromission liée à un administrateur de domaine, reportez-vous au scénario 1 ou au scénario 2 en fonction de ce qui a été exposé et suivez les activités de correction locales dans « Utiliser les ressources de sécurité Microsoft et Azure pour aider à récupérer après une compromission d’identité systémique ».

Dans le domaine contenant les gMSA que vous souhaitez roll, procédez comme suit :

1. Sur un contrôleur de domaine, suivez les étapes décrites dans Créer la clé racine KDS des services de distribution de clés pour créer un objet clé racine KDS.

   Remarque

   Dans l’environnement de production, vous devez attendre 10 heures pour vous assurer que la nouvelle clé racine KDS est disponible. Vérifiez l’attribut EffectiveTime pour savoir quand la nouvelle clé racine KDS sera utilisable.

2. Redémarrez le service de distribution de clés Microsoft sur tous les contrôleurs de domaine.

3. Créez un gMSA. Assurez-vous que le nouveau gMSA utilise le nouvel objet clé racine KDS pour créer la valeur de l’attribut msds-ManagedPasswordID .

   Remarque

   Cette étape est facultative, mais elle vous permet de vérifier que la nouvelle clé racine KDS est actuellement utilisée et utilisée dans le service de distribution de clés Microsoft.

4. Vérifiez la msds-ManagedPasswordID valeur du premier compte gMSA que vous avez créé. La valeur de cet attribut est des données binaires qui incluent le GUID de l’objet clé racine KDS correspondant.

   Par exemple, supposons que l’objet clé racine KDS possède le code suivant CN.

   

   Un gMSA créé à l’aide de cet objet a une msds-ManagedPasswordID valeur qui ressemble à l’image suivante.

   

   Dans cette valeur, les données GUID commencent au décalage 24. Les parties du GUID se trouvent dans une séquence différente. Dans cette image, les sections rouge, verte et bleue identifient les parties réorganisées. La section orange identifie la partie de la séquence identique au GUID d’origine.

   Si le premier gMSA que vous avez créé utilise la nouvelle clé racine KDS, tous les gMSA suivants utilisent également la nouvelle clé.

5. En fonction du rôle de mot de passe suivant, les secrets des gMSA sont naturellement routés, et de nouveaux mots de passe sont créés en fonction du nouvel objet clé racine KDS sur demande.

   Remarque

   Si les gMSA utilisés ont été déployés, mais que les gMSA inutilisés avec le même intervalle de roll ne l’ont pas fait et que le PrincipalsAllowedToRetrieveManagedPassword paramètre est renseigné, vous pouvez exécuter l’applet de Test-ADServiceAccount commande . Il utilise un principal autorisé à récupérer le mot de passe gMSA, puis cette étape déplace le gMSA vers la nouvelle clé racine KDS.

6. Vérifiez que tous les gMSA ont été déployés.

   Remarque

   Le compte gMSA sans le PrincipalsAllowedToRetrieveManagedPassword paramètre ne sera jamais roll.

7. Une fois que tous les gMSA ont été déployés sur le nouvel objet clé racine KDS, supprimez l’ancien objet clé racine KDS et vérifiez les réplications.

8. Redémarrez le service de distribution de clés Microsoft sur tous les contrôleurs de domaine.

References

Vue d’ensemble des comptes de service gérés de groupe

Exclusion de responsabilité sur les coordonnées externes

Microsoft fournit des informations de contacts externes afin de vous aider à obtenir un support technique sur ce sujet. Ces informations de contact peuvent être modifiées sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.