Attaques d'exploitation gMSA et attaques Golden gMSA expliquées

Qu’est-ce qu’une attaque gMSA ?

Une attaque de compte de service géré de groupe est une intrusion où les attaquants compromettent ou calculent les identifiants gMSA pour obtenir un accès non autorisé aux services et escalader les privilèges dans un environnement Active Directory.

Les gMSA sont utilisés pour les services Windows, les pools d'applications IIS, les services SQL Server, les tâches planifiées, les services de sauvegarde et d'autres identités de service automatisées où un service a besoin d'un identifiant de domaine géré automatiquement. L'abus des gMSA offre une large surface d'attaque car chaque système ou service autorisé à récupérer ou à s'exécuter avec un gMSA devient un point d'entrée potentiel pour les attaquants. En lisant les mots de passe gMSA et en exploitant ces comptes, les attaquants peuvent usurper des identités de service, se déplacer latéralement dans le domaine et maintenir une présence persistante difficile à détecter et à remédier.

Les attaquants utilisent principalement les méthodes suivantes pour l'exploitation de gMSA :

• Lire msDS-ManagedPassword : Les attaquants compromettent un hôte ou un compte avec un accès SYSTEM/autorisée et lisent l'attribut msDS-ManagedPassword pour un gMSA depuis Active Directory. Cet attribut contient les mots de passe actuels et précédents du gMSA, donc en lisant les valeurs de l'attribut, les attaquants lisent en fait les mots de passe gMSA.
• Golden gMSA (abus de la clé racine KDS) : Les adversaires obtiennent les attributs de la clé racine KDS (Key Distribution Service) (stockés dans CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=domain,DC=com) et les utilisent pour calculer les mots de passe gMSA hors ligne, sans contacter un contrôleur de domaine. En forgeant des identifiants valides, les attaquants peuvent s'authentifier en tant que ces comptes de service à tout moment.

Attaques Golden gMSA

Voici les caractéristiques clés d'une attaque Golden gMSA :

• La compromission initiale nécessite des droits de haut niveau (par exemple, un compte Domain Admin ou SYSTEM sur un contrôleur de domaine) pour lire ou exporter le matériel de clé racine KDS.
• Une fois les attributs de la clé racine KDS obtenus, les attaquants peuvent :
  • Calculez les mots de passe gMSA actuels et futurs sans contacter un contrôleur de domaine, afin de ne pas générer de journaux d’authentification sur les DC.
  • Élaborez des identifiants pour tout gMSA dans le domaine.
  • Maintenez un accès persistant même après la détection de la compromission initiale (la clé racine est valide par défaut jusqu'à 10 ans).
• Conceptuellement, une attaque Golden gMSA est analogue à une attaque Golden Ticket, car les deux impliquent la création de justificatifs falsifiés ou dérivés.

Utilisations de l'outil

Les outils et scripts suivants facilitent l'exploitation de Golden gMSA :

• Les utilitaires de vidage des identifiants sont utilisés pour extraire des identifiants ou du matériel d'identification d'un hôte afin qu'un attaquant puisse escalader ses privilèges ou se déplacer latéralement. Les cibles incluent la mémoire où résident les jetons d'authentification/hachages NTLM, les identifiants mis en cache et les copies de sauvegarde des magasins d'identifiants.
• Les utilitaires d'énumération AD cartographient les objets, les permissions et les relations d'Active Directory afin qu'un attaquant puisse localiser où se trouvent les clés/objets sensibles (pour gMSA : clés racines KDS, objets msDS-ManagedPassword et liaisons de service). Ils sondent l'appartenance aux groupes, les ACL et les attributs.
• Les utilitaires de preuve de concept et les scripts personnalisés mettent en œuvre une logique mathématique/cryptographique qui dérive les mots de passe gMSA à partir de la clé racine KDS et des métadonnées de l'objet.

Comment fonctionne une attaque gMSA ?

Une attaque d'exploitation de gMSA suit un chemin progressif : l'attaquant commence par découvrir où les gMSA sont utilisés et parvient finalement à se déplacer latéralement et à escalader les privilèges de manière persistante et furtive. Voici les phases de l'attaque :

Découvrez l'utilisation de gMSA

Les attaquants commencent par cartographier où les gMSA sont déployés dans l’environnement. Ils analysent Active Directory et les points de terminaison pour identifier les services, pools d’applications, tâches planifiées, ainsi que les processus de base de données ou de sauvegarde qui s’exécutent sous des identités gMSA. Grâce à cette cartographie, ils sondent ces hôtes à la recherche de vulnérabilités exploitables (comme l’exécution de code à distance sur serveur web, des failles de service non corrigées, et des configurations de service faibles) pouvant être abusées pour obtenir l’exécution de code ou pour escalader les privilèges vers NT AUTHORITY\SYSTEM.

Accéder aux mots de passe gMSA

Sur un hôte compromis avec des privilèges SYSTEM ou via un compte disposant des autorisations suffisantes dans Active Directory, l'attaquant utilise des outils ou des API (par exemple, PowerShell avec DSInternals ou des lectures d'annuaire) pour récupérer l'attribut msDS-ManagedPassword. L'attaquant décode ensuite le blob d'identifiants en clair (ou un hash NTLM), souvent en utilisant la fonction PowerShell ConvertFrom-ADManagedPasswordBlob. Avec ces identifiants en clair ou dérivés, l'attaquant peut se connecter en tant que compte de service, exécuter le service, accéder à toutes les ressources accessibles, et se déplacer vers d'autres systèmes avec peu d'effort.

Attaque Golden gMSA

Dans un scénario Golden gMSA, un adversaire extrait les attributs de la clé racine KDS (tels que msKds-RootKeyData, msKds-KDFParam et les paramètres KDF associés) qu’Active Directory utilise pour dériver les mots de passe gMSA. En utilisant des outils comme GoldenGMSA ou des scripts personnalisés, ils peuvent calculer hors ligne les mots de passe gMSA actuels et futurs. De cette manière, ils peuvent s’authentifier auprès de tout service qui repose sur ces gMSA.

Mouvement latéral ou élévation de privilèges

Une fois que les identifiants gMSA (qu'ils soient lus directement ou calculés à partir de la clé KDS) sont sous le contrôle de l'attaquant, celui-ci peut les utiliser pour :

• Authentifiez-vous aux bases de données, interfaces de gestion, partages de fichiers ou autres services qui acceptent le gMSA.
• Basculez vers d'autres hôtes qui font confiance à l'identité du service.
• Combinez avec les techniques Silver Ticket ou Golden Ticket, ou l’abus de jetons pour escalader les privilèges.
• Exfiltrer des données sensibles.
• Déployez la persistance ou créez de nouveaux comptes de service privilégiés.

Les services fonctionnant sous gMSAs opèrent généralement avec des privilèges élevés et une connectivité étendue, offrant aux attaquants une large surface d’attaque à exploiter.

Diagramme du flux d'attaque

Voici un diagramme de flux expliquant la chaîne d'événements lors d'une attaque gMSA ainsi qu'un exemple d'histoire du point de vue d'une organisation pour vous aider à comprendre l'attaque.

Un attaquant compromet le serveur web orienté client d’une organisation via un plugin vulnérable, installe un web shell, élève ses privilèges au niveau SYSTEM sur cet hôte et extrait les identifiants de service. En utilisant la clé racine KDS et les paramètres KDF extraits, il calcule hors ligne les mots de passe gMSA et s’authentifie aux services backend (base de données et partages de fichiers) sans se connecter au contrôleur de domaine. Sur une période de 48 heures, il exfiltre des dossiers clients sensibles.

Exemples d'attaques gMSA

Il n’existe aucun rapport public ou divulgation de violation indiquant qu’un attaquant ait utilisé une attaque gMSA ou Golden gMSA dans la nature. Cependant, il existe des recherches approfondies, des preuves de concept, des outils et des recommandations de fournisseurs qui prouvent que cette technique est réelle et pratique. Ce qui suit est un résumé des preuves du monde réel.

Conséquences des attaques gMSA

Les équipes informatiques utilisent les gMSA pour un accès automatisé à privilèges élevés. Leur vol peut amplifier un incident, permettant des mouvements latéraux furtifs, un accès prolongé et une large exposition des données. Cela peut entraîner de graves conséquences financières, opérationnelles, réputationnelles et juridiques.

Cibles courantes des attaques gMSA : Qui est à risque ?

De manière générale, les grandes entreprises, les agences gouvernementales et les institutions financières qui exploitent des environnements Active Directory complexes avec de nombreux gMSA pour les services (SQL, IIS, Exchange, sauvegardes) font partie des cibles les plus courantes des attaques gMSA. D'un point de vue technique, les composants suivants d'une infrastructure informatique sont les plus à risque :

Évaluation des risques

Pour évaluer le risque des attaques gMSA, vous devez prendre en compte trois facteurs clés : les dommages potentiels d'une attaque, la difficulté d'exécution de l'attaque et la probabilité qu'elle se produise. Ensemble, ils soulignent pourquoi les gMSA nécessitent une protection et une surveillance renforcées.

Comment prévenir les attaques gMSA

En mettant en œuvre des contrôles techniques solides et des pratiques administratives rigoureuses, les organisations peuvent réduire le risque d’une attaque d’exploitation de gMSA.

Mesures techniques

Les mesures techniques suivantes peuvent aider à prévenir les attaques gMSA et Golden gMSA :

• Configurez les listes de contrôle d'accès système (SACL) sur les clés racines KDS pour enregistrer toute tentative de lecture de l'attribut msKds-RootKeyData. De cette manière, les équipes de sécurité sont alertées si des attaquants tentent d'accéder aux secrets utilisés pour dériver les mots de passe gMSA.
• Appliquez le principe du moindre privilège aux adhésions gMSA. Pour ce faire, limitez les comptes et groupes listés dans l’attribut msDS-GroupMSAMembership d’un gMSA. Seuls les services qui nécessitent réellement le gMSA doivent y avoir accès. Supprimer les adhésions inutiles permet de fermer les voies potentielles d’abus.
• Passez régulièrement en revue les personnes autorisées à gérer et utiliser les gMSA. Les équipes de sécurité doivent auditer les modifications des autorisations et les schémas d’utilisation afin de détecter toute activité suspecte pouvant indiquer un accès non autorisé et des tentatives d’escalade de privilèges.
• Réduisez la valeur du paramètre ManagedPasswordIntervalInDays afin que les mots de passe gMSA soient mis à jour plus fréquemment. Cela limite la fenêtre d'opportunité pour les attaquants de réutiliser des identifiants compromis.

Meilleures pratiques administratives

Dans le cadre des meilleures pratiques administratives, les organisations doivent maintenir un contrôle strict sur le cycle de vie et la gestion des clés des gMSA.

• Créez périodiquement de nouvelles clés racines KDS et réaffectez-les à vos gMSA actifs. Cela empêche l'utilisation de clés anciennes ou potentiellement compromises pour dériver des mots de passe gMSA valides.
• Surveillez l’ID d’événement 4662, qui enregistre les tentatives d’accès aux objets de l’annuaire. Surveiller cet événement spécifiquement pour les attributs gMSA peut aider à détecter les accès non autorisés ou les requêtes suspectes.
• Désactivez de manière proactive les gMSA qui ne sont plus utilisés et supprimez les permissions orphelines des anciens services. Cela réduit le nombre de comptes disponibles pour les attaquants, minimisant ainsi votre surface d'attaque globale.

Comment Netwrix peut aider

La suite Netwrix Identity Threat Detection & Response (ITDR) aide les organisations à identifier les activités suspectes et à sécuriser leur infrastructure d’identité dans les environnements sur site et hybrides. Elle offre des capacités de visibilité, d’alerte, de réponse et de récupération pertinentes pour la défense des gMSA.

Voici quelques-unes de ses capacités principales et comment elles contribuent à prévenir ou atténuer les risques liés aux gMSA :

Détection des menaces

Les produits Netwrix ITDR, tels que Threat Manager et Threat Prevention, peuvent détecter des activités suspectes liées à l'infrastructure d'identité, telles que des modifications inhabituelles ou non autorisées dans Active Directory. Ils peuvent surveiller les modifications et accès au niveau des objets et attributs dans AD (comme les lectures non autorisées des attributs msDS-ManagedPassword et msKds-RootKeyData), et peuvent alerter sur des modifications de configuration risquées ou des changements dans l'appartenance à des groupes privilégiés.

Surveillance et alertes en temps réel

Netwrix ITDR fournit des alertes en temps réel sur les événements critiques d'Active Directory et les schémas d'accès anormaux. Cela inclut la surveillance des comptes non contrôleurs de domaine tentant d'accéder aux attributs sensibles KDS, l'appartenance à des groupes sensibles et les modifications des attributs privilégiés. Ces fonctionnalités de surveillance aident à détecter les abus de gMSA.

Réponse rapide

Netwrix ITDR prend en charge des actions de réponse aux incidents automatisées ou semi-automatisées en cas de compromission détectée, telles que la désactivation des comptes, la génération d’alertes, le retour en arrière des modifications indésirables et le lancement d’enquêtes judiciaires. Dans un scénario d’attaque gMSA, cela signifie que vous pouvez réagir rapidement lorsqu’une activité suspecte est détectée, comme désactiver le gMSA ou révoquer les autorisations.

Audit de sécurité et rapports

Netwrix Auditor fournit des pistes d’audit détaillées, des valeurs « avant et après » pour les modifications AD, des rapports d’évaluation des risques, des tableaux de bord et des rapports de conformité. Ceux-ci sont utiles pour suivre les modifications des autorisations gMSA, l’utilisation au fil du temps et pour identifier les mauvaises configurations.

Stratégies de détection, d'atténuation et de réponse

Pour se défendre contre les attaques liées aux gMSA, les organisations doivent adopter une approche proactive qui couvre la détection précoce, la mitigation préventive et une réponse efficace. Voici quelques étapes pratiques pour renforcer vos défenses contre les compromissions de la clé racine KDS et des gMSA.

Détection

Pour détecter tôt une attaque gMSA, les équipes doivent suivre ces pratiques :

Surveillez les lectures non autorisées d’attributs critiques tels que msDS-ManagedPassword et msKds-RootKeyData

Ces attributs sont directement liés à la récupération des mots de passe gMSA et à la génération hors ligne des mots de passe, et sont rarement consultés en dehors des opérations normales du contrôleur de domaine. Des requêtes inhabituelles à leur encontre peuvent indiquer des tentatives de collecte d’identifiants. Pour détecter cela, les administrateurs peuvent activer l’audit du service d’annuaire dans Active Directory et configurer l’audit de sécurité avancé pour enregistrer l’accès au service d’annuaire (ID d’événement 4662).

Vérifiez les comptes non-DC accédant aux attributs sensibles KDS

Seuls les contrôleurs de domaine doivent interagir avec les données de la clé racine KDS. Surveiller l'accès par des comptes inattendus peut révéler un usage abusif des privilèges ou des tentatives de mouvement latéral.

Combinez la surveillance avec l'analyse

En filtrant les lectures sur les attributs sensibles et en les corrélant avec le type de compte (comme les comptes non-DC), les équipes de sécurité peuvent détecter des requêtes suspectes. Mieux encore, intégrez ces journaux dans une plateforme SIEM pour la corrélation inter-événements, la détection d’anomalies et les alertes en temps réel.

Utilisation normale de base des gMSA sur les services et serveurs

Cela permet la détection d’anomalies lorsque les gMSA sont utilisés en dehors de leur périmètre prévu (par exemple, un gMSA SQL utilisé sur un serveur web).

Atténuation

Les équipes informatiques doivent aborder l’atténuation comme un effort coordonné et stratifié qui non seulement coupe l’accès actuel de l’attaquant, mais renforce également les défenses pour minimiser les risques de compromission future. Certaines étapes importantes d’atténuation sont discutées ci-dessous.

Recréer les gMSA avec une nouvelle clé racine KDS en cas de suspicion de compromission

Générer une nouvelle clé racine empêche un attaquant de dériver des mots de passe à partir d’artefacts précédemment exposés, restaurant ainsi la confiance dans les comptes gérés.

Renouvelez les mots de passe gMSA en exécutant Test-ADServiceAccount

Forcer le rafraîchissement d’un mot de passe garantit que même si les identifiants sont compromis, les attaquants perdent l’accès aux secrets valides.

Appliquer la segmentation et faire respecter la portée

Mettez en œuvre une segmentation réseau et de service pour limiter les endroits où les gMSA peuvent être utilisés. De cette façon, si un niveau est compromis, les attaquants ne peuvent pas facilement se déplacer vers d'autres zones sensibles.

Testez régulièrement vos playbooks de remédiation

Réalisez des exercices pratiques et techniques simulant la rotation de clé KDS et la récupération gMSA pour vous assurer que vos procédures sont efficaces et fonctionnent sous pression.

Réponse

Lorsqu'une attaque gMSA est suspectée ou confirmée, les organisations doivent agir de manière décisive pour contenir la menace, limiter les dégâts et prévenir toute récidive.

Mettre en quarantaine les systèmes affectés

Isolez les hôtes compromis pour empêcher les attaquants de se déplacer latéralement davantage ou de continuer à utiliser de manière abusive les identifiants gMSA compromis. Vous devez également isoler les contrôleurs de domaine si un accès suspect aux msKds-RootKeyData ou à d'autres attributs critiques est détecté, garantissant que les attaquants ne peuvent pas persister dans les services d'annuaire.

Désactiver les gMSA compromis

Désactivez immédiatement les gMSA compromis pour empêcher les adversaires de les utiliser pour l'authentification et les activités malveillantes.

Faites pivoter toutes les informations d'identification pertinentes et mettez à jour les services affectés

Faites pivoter toutes les informations d'identification pertinentes, y compris les gMSA, les comptes de service et les comptes administratifs. Mettez ensuite à jour les services concernés pour garantir une ré-authentification fluide avec les gMSA nouvellement pivotés.

Préserver les artefacts judiciaires et lancer une enquête judiciaire

Une enquête judiciaire aide à déterminer l'étendue et la cause principale de l'incident. Assurez-vous de capturer les données du contrôleur de domaine et de Configuration NC, telles que les journaux et les instantanés NTDS, avant d'effectuer des modifications de remédiation irréversibles. Il est important de trouver un équilibre entre l'urgence d'arrêter l'attaque et la nécessité de conserver des preuves pour l'analyse. Ensuite :

• Examinez les journaux d'événements, les alertes SACL et les anomalies liées à l'identité.
• Capturez les données volatiles (telles que les vidages de mémoire et les journaux d’authentification) des systèmes impactés pour une analyse post-incident.
• Surveillez les mécanismes de persistance tels que les tâches planifiées, les ACL modifiées ou les comptes administrateurs fantômes qui ont pu être introduits lors de la compromission.

Ces étapes peuvent aider à identifier les mécanismes d'attaque et à combler les failles de sécurité.

Impact spécifique à l'industrie

L'impact des attaques gMSA n'est pas le même pour toutes les industries. En comprenant les conséquences spécifiques à chaque secteur, les organisations peuvent prioriser leurs défenses en fonction de leurs actifs les plus précieux.

Évolution des attaques et tendances futures

À mesure que les organisations adoptent les gMSA pour renforcer la sécurité et simplifier la gestion des mots de passe, les attaquants développent activement leurs techniques pour exploiter ces comptes. Les tendances suivantes mettent en lumière comment les adversaires exploitent les faiblesses des gMSA et vers où se dirige le paysage des menaces.

Statistiques clés et infographies

Les gMSA sont conçus avec des fonctionnalités de sécurité robustes, mais les attaquants ciblant la clé racine KDS peuvent contourner ces protections. Examinons quelques faits et statistiques à l’appui :

• Les gMSA changent leur mot de passe tous les 30 jours pour limiter l'exposition des identifiants. Mais si des attaquants volent la clé racine KDS, ils peuvent calculer les mots de passe gMSA hors ligne à tout moment, annulant ainsi efficacement la protection de rotation.
• Parce que chaque gMSA dans un domaine dépend de la même clé racine KDS pour la génération des mots de passe, compromettre cette clé racine unique peut affecter tous les gMSA du domaine. Cela crée un risque à l'échelle du domaine à partir d'un point de défaillance unique.

Le graphique à barres suivant compare la fenêtre de sécurité prévue (rotation de 30 jours) avec la fenêtre d'accès réelle de l'attaquant (indéfinie si le KDS est compromis).

Réflexions finales

En fin de compte, les gMSA sont une arme à double tranchant : ils simplifient l’authentification des services et renforcent la sécurité lorsqu’ils sont correctement gérés, mais entre de mauvaises mains, ils peuvent devenir les clés du royaume. Lorsque des attaquants forgent un Golden gMSA, ils ne volent pas seulement un mot de passe ; ils héritent de la clé maîtresse de votre infrastructure, avec le pouvoir de se déplacer silencieusement à travers les systèmes et services. Le danger réside dans leur invisibilité : ils mijotent inaperçus jusqu’à ce que l’ensemble de l’entreprise soit en danger. Protéger vos clés racines KDS, surveiller les activités suspectes des gMSA et mettre en œuvre une sécurité renforcée des contrôleurs de domaine sont des mesures essentielles pour sécuriser votre environnement Active Directory.