Sécuriser vos comptes de service gérés par groupe

Présentation des comptes de service gérés par groupe

La pratique traditionnelle consistant à utiliser des comptes d'utilisateurs réguliers comme comptes de service impose aux utilisateurs la gestion des mots de passe. En conséquence, les mots de passe des comptes restent souvent les mêmes pendant des années — ce qui les rend très vulnérables aux attaques par force brute et à une utilisation abusive. Les comptes de service gérés par groupe (gMSAs) offrent une manière plus sécurisée d'exécuter des tâches automatisées, des services et des applications.

Les gMSA ont été introduits dans Windows Server 2016 et peuvent être utilisés sur Windows Server 2012 et versions ultérieures. Les mots de passe gMSA sont entièrement gérés par Windows : ils sont générés aléatoirement et tournent automatiquement. De plus, les mots de passe n'ont pas besoin d'être connus par un utilisateur, puisque les comptes de service sont ‘installés’ sur le serveur qui doit interroger les informations de mot de passe depuis Active Directory au moment de l'exécution. En conséquence, les gMSA sont beaucoup moins susceptibles d'être mal utilisés et compromis que les comptes d'utilisateurs utilisés comme comptes de service.

Sécurité des comptes de service gérés par groupe

Les gMSA sont un type d'objet spécifique dans Active Directory: msDS-GroupManagedServiceAccount. Ces objets ont des attributs spéciaux associés à eux liés à leur mot de passe et à sa rotation. De manière similaire à LAPS, vous voudrez vous assurer que les attributs gMSA sont verrouillés pour n'être accessibles qu'aux objets Active Directory qui en ont besoin.

Attributs et permissions gMSA

Les gMSAs possèdent les attributs suivants :

• msDS-ManagedPassword— Un BLOB avec le mot de passe du gMSA
• msDS-ManagedPasswordID— L'ID clé utilisé pour générer le mot de passe gMSA actuel
• msDS-ManagedPasswordPreviousID— L'ID clé utilisé pour générer le mot de passe gMSA précédent
• msDS-GroupMSAMembership— Une liste des objets qui ont la permission de requérir le mot de passe pour le gMSA
• msDS-ManagedPasswordInterval— L'intervalle (en jours) auquel le mot de passe est renouvelé

Étant donné que les informations de mot de passe sont stockées dans l'attribut msDS-ManagedPassword, vous voudrez certainement savoir qui dans votre environnement est capable de consulter le mot de passe. Cette information est définie dans l'attribut msDS-GroupMSAMembership.

Cependant, c'est un peu plus compliqué que juste cet attribut, car les permissions de Active Directory entrent en jeu. Si pour une raison quelconque un utilisateur ou un objet est configuré pour avoir des permissions pour interroger le mot de passe via le compte msDS-GroupMSAMembership, il doit toujours avoir des permissions de 'Lecture' pour l'attribut msDS-ManagedPassword du gMSA.

Cela signifie qu'il y a deux moyens de sécuriser les mots de passe gMSA :

• Assurez-vous que seuls les objets nécessaires ont la permission de requêter le mot de passe et qu'ils existent dans le msDS-GroupMSAMembership
• Assurez-vous que seuls les utilisateurs administratifs qui ont besoin d'accès et les comptes d'ordinateurs où les gMSAs sont installés ont la permission de lire l'attribut. De plus, assurez-vous que seuls les administrateurs ont la capacité de modifier le gMSA et ses attributs, afin que personne ne puisse s'ajouter à l'attribut msDS-GroupMSAMembership.

Idéalement, vous verrouilleriez les gMSAs par les deux voies pour empêcher un attaquant d'avoir la possibilité d'exploiter l'un des scénarios ci-dessus. Ci-dessous, nous allons montrer comment des permissions ou des configurations mal gérées sur un gMSA peuvent conduire à la compromission du compte et à privilege escalation ou à un mouvement latéral.

Abus du mot de passe gMSA

Abuser d'un gMSA est un concept relativement simple. Tout d'abord, obtenez son mot de passe en utilisant un outil comme Mimikatz ou en l'interrogeant directement en raison de configurations non sécurisées dans Active Directory. Puisque les gMSAs sont des comptes de service, ils sont généralement assez privilégiés, vous pourrez donc généralement vous déplacer latéralement ou escalader.

Prenons un exemple de scénario.

1. D'abord, nous compromettons le compte utilisateur Windows ordinaire ‘notadmin’ par une technique telle que le phishing. Ce compte dispose de privilèges minimaux dans Active Directory, mais est un administrateur local sur la machine sur laquelle nous avons atterri.

2. Ensuite, nous allons essayer de déterminer si des gMSA existent. C'est très simple à réaliser si vous avez accès au cmdlet Windows PowerShell. L'exécution d'un script simple nous permet d'obtenir tous les comptes de service gérés dans Active Directory :

      Get-ADServiceAccount -Filter *
      

3. Avec quelques légères modifications du script, nous pouvons identifier qui a accès pour interroger les mots de passe gMSA :

      Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
      

Comme nous pouvons le voir, seul le compte de Kevin Joyce est capable de consulter les mots de passe pour ces comptes de service :

4. Nous pouvons réduire le champ des cibles que nous voulons en vérifiant si ces comptes de service sont membres de groupes privilégiés, et à partir de là, nous pouvons approfondir les permissions définies sur l'un des objets :

      Get-ADServiceAccount -Filter * -Properties memberof
      

En examinant les résultats ici, nous pouvons voir que le compte de service gMSA est membre des Domain Admins, donc ce sera celui que nous allons essayer d'exploiter.

5. En modifiant un script fourni dans un article sur Microsoft LAPS, nous avons pu obtenir une liste de tous les objets disposant de permissions sur un compte de services gérés incluant le Contrôle total, l'Écriture de toutes les propriétés ou l'Écriture de propriété pour l'attribut gMSA spécifique. Le résultat est ci-dessous, et le script est lié en bas de page.

6. Comme vous pouvez le voir, le compte notadmin dispose d'un Contrôle total sur le compte gMSA. Cela nous donne la capacité de modifier l'attribut msDS-GroupMSAMembership, ce qui nous permettra de récupérer le mot de passe pour le compte de service géré :

      Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
      

7. Maintenant que nous sommes réellement capables d'interroger le mot de passe, voyons ce que nous pouvons faire avec :

      Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
      

      $pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
      

8. La valeur stockée dans l'attribut est un BLOB qui contient les données pour le mot de passe, et non le mot de passe lui-même, donc nous devrons décoder le mot de passe à l'aide d'un outil tel que DSInternals :

      $pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
      

Cela nous donne le SecureCurrentPassword et le CurrentPassword. Le CurrentPassword semble inutile mais c’est parce que tous les caractères sont en UTF-16. Le SecureCurrentPassword peut être converti en un hash NTLM et utilisé dans une attaque pass the hash avec mimikatz pour élever nos privilèges.

9. Pour pass the hash, il suffit d'exécuter mimikatz et d'utiliser cette commande :

      sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
      

10. Maintenant que nous avons un shell exécuté en tant que compte de service gMSA qui était membre des Domain Admins, nous pouvons faire tout ce que nous voulons pour compromettre Active Directory. L'une des méthodes les plus rapides, mais probablement les plus bruyantes, est d'exécuter une DCSync attack et de voler le hash du compte krbtgt :

      lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
      

Protection & Surveillance des gMSA

Il existe des stratégies que vous pouvez utiliser pour prévenir et détecter l'abus de gMSA.

Permissions

La protection la plus évidente et sans doute la plus importante que vous pouvez mettre en place est de vous assurer que les permissions appropriées sont définies sur vos comptes de service gérés par groupe. Comprendre qui a un accès en écriture à ces objets est pertinent pour les protéger ; quelqu'un qui peut s'ajouter à l'attribut qui contrôle qui peut interroger le mot de passe a théoriquement déjà accès pour prendre le contrôle de ce compte et abuser de ses privilèges.

La prochaine étape serait de comprendre qui a la capacité d'interroger les mots de passe de ces comptes et qui a réellement besoin d'un tel accès. En réalité, le seul compte qui devrait pouvoir obtenir le mot de passe d'un gMSA est le compte de l'ordinateur sur lequel le gMSA est installé.

Journaux d'événements

Il existe un événement que vous pouvez rechercher dans les journaux d'événements natifs qui vous aidera à identifier qui interroge les mots de passe des comptes gMSA. Si vous activez la politique ‘Audit directory service access’ pour votre domaine et configurez une SACL sur les gMSA que vous souhaitez surveiller, vous pouvez générer des journaux d'événements lorsque des personnes interrogent l'attribut msDS-ManagedPassword :

Activer ce paramètre et créer un nouveau SACL générera un journal d'événements avec l'ID d'événement 4662; cela ressemble à ceci :

Comme vous pouvez le voir, cela a enregistré que le compte ‘notadmin’ a lu une propriété sur le compte gMSA. Les propriétés lues sont les GUID stockés dans le schéma pour Active Directory, mais en utilisant ADSI edit, nous pouvons voir que le GUID mis en évidence correspond à l'attribut msDS-ManagedPassword.

En supposant que vous ayez une sorte de transfert de journaux d'événements ou une solution SIEM, ces journaux seraient inestimables pour déterminer qui accède à ces attributs.

Netwrix StealthDEFEND

Une autre option est un outil comme Netwrix StealthDEFEND. Netwrix StealthDEFEND ne dépend pas des journaux d'événements natifs et peut détecter l'accès au mot de passe gMSA et les attributions de permissions à haut risque directement après installation. Par exemple, le scénario présenté ci-dessus générerait la menace suivante lorsque le compte 'notadmin' interroge le mot de passe :

De plus, avec Netwrix StealthDEFEND, vous pouvez facilement construire un playbook pour exécuter lorsqu'une utilisation abusive de gMSA est détectée. Le playbook peut impliquer plusieurs étapes, telles que demander au compte utilisateur fautif de répondre à une demande MFA, désactiver le compte ou créer un incident ServiceNow.

Annexe

code des permissions gMSA :

      <#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}

<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'

##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target


<#Get objects that have specific permissions on the target(s): 
Full Control(GenericAll) 
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize 
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty 
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access | 
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
      

voir brutgMSA_Permissions_Collection.ps1 hébergé avec par GitHub

FAQ

Qu'est-ce qu'un gMSA ?

Semblable aux comptes de service gérés (MSA), les comptes de service gérés de groupe (gMSAs) sont des comptes de domaine gérés qui sont utilisés pour aider à sécuriser les services et la gestion des accès. La fonctionnalité gMSA offre une gestion automatique des mots de passe par le contrôleur de domaine (DC), une gestion simplifiée du nom principal du service (SPN) et la possibilité de déléguer la gestion à d'autres administrateurs, ce qui améliore la sécurité Active Directory et réduit le nombre de comptes avec un accès privilégié.

Quelle est la différence entre les MSAs et les gMSAs ?

Contrairement à un MSA, un gMSA peut être associé à plusieurs ordinateurs.

Comment trouver un compte de service géré par un groupe ?

Pour obtenir une liste des gMSAs sur votre contrôleur de domaine, ouvrez Gestionnaire de serveur > Outils > Active Directory Users and Computers > Comptes de service gérés.

Un gMSA peut-il être un administrateur de domaine ?

Oui, un compte gMSA peut être membre des Domain Admins, bien que cette pratique puisse être dangereuse pour la sécurité de l'information.

Comment puis-je créer un gMSA ?

Les comptes de service gérés par groupe sont créés avec la cmdlet New-ADServiceAccount.