Authored by: Vikram Navali, Senior Technical Product Manager – Adversaries use various techniques to dump the credentials and obtain account information, normally as a hash or clear-text password. After obtaining a domain user/service account credentials, the adversary goes after Group Managed Service Accounts (gMSAs). The gMSAs provide enhanced security for non-interactive applications or services that run automatically on a server farm, such as systems behind Network Load Balancer or Internet Information Services (IIS) server.
Before digging deeper into how a gMSA password allows someone to escalate privileges, one must look at why gMSA is important and its key benefits.
Importance of gMSAs
Unlike domain user accounts in Active Directory(AD), service account passwords rarely change. Here, Managed Service Accounts (MSAs) play an important role in providing a better approach to password management. They eliminate the need for an administrator to manage the credentials for each service account manually. Organizations use MSAs to run various services for applications that are operating in the AD environment. The MSAs are of the following types:
Standalone managed service accounts – Microsoft introduced Standalone Managed Service Accounts (sMSAs) in Windows Server 2008 R2 and Windows 7 to provide automatic password management, simplified service principal name (SPN) management, and the ability to delegate the management to other administrators.
Group managed service accounts – The gMSA provides the same functionality as sMSAs and extends to multiple servers. The following are the key benefits of gMSAs.
- Sets a strong password – The complexity and length of gMSA passwords minimize the likelihood of a service getting compromised by brute force or dictionary attacks.
- Cycles the passwords regularly – Changes the password every 30 days.
- Supports deployment to server farms – Deploying gMSAs to multiple servers allows for the support of load-balanced solutions where multiple hosts run the same service.
- Supports simplified Service Principal Name (SPN) management.
The problem with gMSAs
As a key benefit, gMSAs offer better password and SPN management. However, the downside of gMSA is protecting its credentials – its password protection is not so great. Attackers can discover unauthorized users who have permission to read the password and obtain credentials as a hash or clear text password. Once the attackers gain access to the hash, they can perform Pass the Hash (PtH) techniques and move laterally.
There are different ways to exploit gMSA passwords. Attackers can compromise a computer hosting service using gMSA with privileged AD rights or compromise an account with rights to request a gMSA password.
The main problem with gMSA lies in its attributes and the critical information that holds inside a specific attribute. For example, attackers can run PowerShell cmdlet “Get-ADServiceAccount” and retrieve information about the gMSA and its specific attributes. The following are attributes specific to the gMSAs that are associated with object class “msDS-GroupManagedServiceAccount”.
- msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) – stores the security principals that can access the gMSA password.
- msDS-ManagedPassword – This attribute contains a BLOB with password information for group-managed service accounts.
- msDS-ManagedPasswordId – This constructed attribute contains the key identifier for a group MSA’s current managed password data.
- msDS-ManagedPasswordInterval – This attribute retrieves the number of days before a managed password gets automatically changed for a group MSA.
A simple PowerShell cmdlet “Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword” can help get one or more Active Directory managed service accounts or group managed service accounts. The msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword) attribute controls who can request and retrieve the password for a gMSA. For example, this attribute contains a group name called “Team-DevOps-01” as shown below.
Attackers can enumerate and discover what computers, users, or groups belong to the group “Team-DevOps-01”. The figure below is an example of the data they can list showing all accounts that can get the clear-text password for the gMSA.
Compromising one of these accounts can lead to compromising the gMSA account.
Attackers leverage the PowerShell cmdlet Get-ADServiceAccount to retrieve the gMSA password data (attribute msDS-ManagedPassword). They can further use tools like the DSInternals module (ConvertTo-NTHash) and convert the password obtained to the NT hash.
Attackers use the converted hashes to perform a Pass-the-Hash (PtH) attack. They can use hash values to trick the authentication system and extract additional information. By laterally moving between endpoints, attackers can use pass-the-hash to gain the right credentials to eventually escalate their domain privileges and access more privileged systems, such as an administrator account on the domain controller.
This attack was the case with the Solorigate incident, where the threat actor attempted to access gMSA passwords with account credentials they had already obtained. Attackers created valid SAML tokens allowing them to impersonate users to access the cloud resources and exfiltrate sensitive information.
Conclusion
To summarize, gMSAs offer a single identity solution with greater security and at the same time helps to reduce administrative overhead. Adversaries look for loopholes on Group Managed Service Accounts. Organizations should conduct Active Directory assessments and take the necessary actions to protect gMSA password exposure that restricts unauthorized user access to critical information.
Singularity™ Ranger AD is a cloud-delivered solution designed to uncover vulnerabilities in Active Directory and Azure AD. Get additional AD attack detection and conditional access capabilities to protect enterprise identity infrastructure with Singularity Ranger AD Protect.
