Comment récupérer à partir d’une attaque gMSA golden

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

Symptômes

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

Présentation de l’attaque GMSA d’or

La description de l’article ci-dessus est exacte. L’approche de résolution du problème consiste à remplacer l’objet de clé racine microsoft Key Distribution Service (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 msds-ManagedPasswordID attributs 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 les hôtes du contrôleur de domaine sont ouverts à l’attaque gMSA Golden. 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 d’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 une fois qu’un domaine a été exposé, 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 concernant une attaque gMSA d’or.

Note

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 ManagedPasswordIntervalInDays paramètre sur 15 jours ou de choisir une valeur appropriée lors de la création d’un compte gMSA, car la ManagedPasswordIntervalInDays valeur devient en lecture seule après la création d’un compte gMSA.

En cas de compromission, ce paramètre peut réduire la durée de déploiement suivante.

Il réduit 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 au moins, la durée de la fenêtre de risque jusqu’à ce que ces GMSA se restaurent, si vous respectez le scénario 1.

Voici un exemple de scénario :

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

2. La sauvegarde restaurée provient de D-15.

   Note

   D-15 signifie le jour qui est de 15 jours avant « Jour D ».

3. La valeur gMSA ManagedPasswordIntervalInDays est 15.

4. Les GMSA existent et ont roulé D-1.

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

6. La compromission se produit sur 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 (compromis)^* doivent être recréés, ou les fenêtres à risque doivent être supposées si vous pouvez attendre de D+5 jusqu’à D+10. Par exemple :

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

   ^*Dépend du temps exact de compromission ou de sauvegarde.

Voici un exemple de chronologie :

Pour le débogage, vous pouvez consulter les ID d’événement pour le journal des événements System, Security, Directory Services et Security-Netlogon.

Pour plus d’informations sur une compromission, consultez Utiliser les ressources de sécurité Microsoft et Azure pour faciliter la récupération d’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 exposées et quand

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 que vous avez, 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 annulent leur mot de passe, ils passent à l’utilisation du nouvel objet clé racine KDS. Pour corriger les gMSA qui ont récemment déployé leur mot de passe à l’aide de l’ancienne clé racine KDS, une restauration faisant autorité est requise pour forcer une mise à jour de mot de passe immédiatement après la restauration.

Note

• Vous n’avez pas besoin de réparer manuellement les GMSA qui ont été 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 régénéreront 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 possibles signalées avec les comptes dans le journal des événements System, Security, Directory Services et Security-Netlogon.
• Le guide part du principe que les gMSA sont des objets enfants du conteneur Comptes de service géré. Si vous avez déplacé les comptes vers des conteneurs parents personnalisés, vous devez exécuter les étapes associées au conteneur Comptes de service gérés sur le compte de service administré 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’âge de la sauvegarde, vous pouvez décider de tolérer la fenêtre dans laquelle le matériel de clé précédent fonctionne toujours. Si vous ne pouvez pas attendre si 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 managé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 l’état de la dernière mise à jour du mot de passe. La prochaine fois qu’un service récupère le mot de passe, le mot de passe est mis à jour vers un nouvel objet 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 Key Distribution Services pour créer un objet clé racine KDS.

   Note

   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 .

   Note

   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 a les éléments suivants 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 ramenez le contrôleur de domaine restauré en ligne. 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 seront roulés et de nouveaux mots de passe seront créés en fonction de l’objet clé racine KDS à la demande.

    Note

    Si les gMSA sont restaurés, mais pas utilisés et que le PrincipalsAllowedToRetrieveManagedPassword paramètre est rempli, 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 restaure ensuite les gMSA sur la nouvelle clé racine KDS.

12. Vérifiez que tous les GMSA ont été inscrits.

    Note

    Le gMSA sans le PrincipalsAllowedToRetrieveManagedPassword paramètre rempli n’est jamais roulé.

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 puissent être roulés

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 dans un état propre fait partie de cette activité.

Pendant le 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é.

Note

Les étapes suivantes ressemblent à la procédure de prise en main des comptes de service gérés de groupe. Toutefois, il existe quelques changements importants.

Effectuez les étapes suivantes :

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

   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 de la procédure de création de la clé racine KDS KDS Services pour créer un objet clé racine KDS.

   2. Redémarrez le service de distribution de clés Microsoft. Une fois qu’il a redémarré, le service récupère le nouvel objet.

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

   4. Modifiez les gMSA existants pour supprimer les noms d’hôtes SPN et DNS.

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

      Note

      Vous devez également passer en revue toutes les entrées d’autorisation à l’aide des SID gMSA directement supprimés, car elles ne sont plus résolvables. Lors du remplacement d’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 ce faire, 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 a les éléments suivants 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 à l’époque, et vous pouvez attendre que les mots de passe se déploient

Si un membre hautement privilégié avec des administrateurs de domaine ou des droits équivalents démissionne, il n’existe aucune preuve de l’exposition clé racine KDS au moment de l’exécution, et vous pouvez vous permettre une fenêtre de temps pour le déploiement du mot de passe. Vous n’avez pas besoin de recréer les GMSA.

En guise de mesure préventive, 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 non autorisé et a conservé certaines sauvegardes.

Un nouvel objet clé racine KDS est créé, et les GMSA s’exécutent naturellement.

Note

Pour 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 vous aider à récupérer contre la compromission d’identité systémique ».

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

1. Sur un contrôleur de domaine, suivez les étapes décrites dans Créer la clé racine KDS Key Distribution Services pour créer un objet clé racine KDS.

   Note

   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 .

   Note

   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 a les éléments suivants 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. Selon le prochain rouleau de mot de passe, les secrets des GMSA sont naturellement roulés et de nouveaux mots de passe seront créés en fonction du nouvel objet clé racine KDS à la demande.

   Note

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

6. Vérifiez que tous les GMSA ont été inscrits.

   Note

   Le gMSA sans le PrincipalsAllowedToRetrieveManagedPassword paramètre ne sera jamais roulé.

7. Une fois que tous les gMSA ont été inscrits 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 administré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 changer sans préavis. Microsoft ne garantit pas l’exactitude des informations concernant les sociétés externes.