> ## Content Index
> Fetch the complete content index at: https://yokai.hakaisecurity.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# Group Managed Service Accounts: A Solution Against Kerberoasting or an Incentive for Golden GMSA Attacks?
- URL: https://yokai.hakaisecurity.io/group-managed-service-accounts-a-solution-against-kerberoasting-or-an-incentive-for-golden-gmsa-attacks/
- Published: 2025-01-24T12:00:58.000Z
- Updated: 2026-09-08T16:17:00.000Z
- Author: jesse neto
- Tags: Insights Blog, #wp, en, #pair-kerberoasting

### Introduction

For information security professionals or system administrators, user account management is always challenging. When it comes to service accounts, the problem becomes even more significant, given their critical role in protecting corporate infrastructures, especially considering the sheer number of services in a typical environment. A common incident in vulnerable environments is the compromise of service accounts, particularly when BASIC credential management practices are not adopted. These accounts, often used by applications and services to perform essential functions for business continuity, become prime targets for simple and well-known attacks, such as **Kerberoasting**, where passwords associated with service accounts are extracted and exploited.

Starting with **Windows Server 2012**, Microsoft introduced **Managed Service Accounts (MSAs)** and **Group Managed Service Accounts (gMSAs)**. Furthermore, with the release of Windows Server 2025, an update known as **Delegated Managed Service Accounts (dMSAs)** has been introduced. These solutions were designed to resolve manual service account management challenges by automating the process and making it more secure, eliminating concerns about administrative tasks such as defining complex password policies or periodic credential rotation.

These accounts are integrated with the **Key Distribution Center (KDC)** in Active Directory, which automatically handles the generation and updating of their passwords. This automation ensures that the passwords are inherently secure and complex and are assigned and rotated regularly without requiring intervention from administrators or sysadmins.

MSAs and gMSAs thus represent a significant advancement in securing **on-premises Active Directory environments** that depend on service accounts. They provide an efficient solution for identity management, as illustrated by the following default features:

- Passwords are rotated every 30 days by default.
- Passwords are long and complex.
- No one has access to the account’s password.
- Interactive login is not allowed.
- Only authorized hosts can use the account to execute services and tasks.

---

# MSAs vs. gMSAs

Based on Microsoft's official documentation, the choice between standalone **Managed Service Accounts (MSAs)** and **Group Managed Service Accounts (gMSAs)** depends on the scope of implementation, specifically whether the service will run on a single host or across two or more hosts (e.g., a server farm).

### Standalone Managed Service Accounts (MSAs)

- **Deployment on a Single Host:**  
MSAs are ideal for scenarios where a service is deployed on a single server with minimal administrative intervention. They provide a unique identity solution for services running on a specific server.  
If a gMSA cannot be used and the service is limited to a single server, MSAs are a suitable option.

### Group Managed Service Accounts (gMSAs)

- **Deployment on Two or More Hosts (Server Farms):**  
gMSAs are recommended when a service is distributed across two or more servers, whether in a server farm or a load-balanced environment. They provide a unified identity solution for services running in distributed systems or behind a network load balancer.

However, while gMSAs protect against **Kerberoasting**, they may introduce vulnerabilities to an attack known as **Golden gMSA**.

In some environments, labs, or client setups, misconfigured gMSAs have been identified. Improper adjustments can allow an attacker to create Kerberos tickets with excessive privileges. These tickets can severely compromise security by granting the attacker elevated access and control over domain resources. To avoid this vulnerability, it is critical to configure gMSAs correctly, adhering strictly to Microsoft's recommended principles of **least privilege** and **role segregation**.

# Initial Concepts

The **Golden gMSA** attack is a variation of the **Golden Ticket** attack, specifically targeting **Group Managed Service Accounts (gMSA)** in Windows environments. To understand the Golden gMSA attack, it is useful to review the foundational concepts of **Kerberos authentication**. Without this understanding, the attack logic cannot be fully grasped.

## Kerberos Authentication

Kerberos is a widely used **authentication protocol** in Windows environments and the preferred choice for **Active Directory** networks. It operates on **TCP/UDP port 88**, as defined in **RFC 4120**.

The protocol relies on the use of **tickets** that enable user authentication. But what exactly do these tickets contain?

### Ticket Components:

- **SPN (Service Principal Name):** Target/service for which the ticket is applicable.
- **UPN (User Principal Name):** Format `user@domain.local`.
- **Key:** Connects the user to the service.
- **Timestamp:** Defines the ticket’s validity period.

### PAC (Privilege Attribute Certificate):

The PAC contains security information directly associated with the user, verifying the authenticity of the information. PAC components include:

- **SID (Security Identifier):** Identifies the user.
- **RID (Relative Identifier):** Identifies the user within a domain.
- **GroupIds:** Domain groups the user belongs to.
- **ExtraGroupIds:** Non-domain groups the user belongs to.

Additionally, the PAC includes signatures for data integrity verification:

- **Server signature:** Created using the key used to encrypt the ticket.
- **KDC signature:** Confirms the PAC was created by the KDC.
- **Ticket signature:** Newly introduced, sign the ticket contents with the KDC key.

---

# KDC Services

The **Key Distribution Center (KDC)** issues tickets for user authentication. It comprises two key components:

1. **Authentication Service (AS):** Handles initial authentication requests.
2. **Ticket Granting Service (TGS):** Issues service tickets for accessing specific services.

**Note:** The **TGT (Ticket Granting Ticket)** is generated by the AS, while the **ST (Service Ticket)** is issued by the TGS. It is common to confuse STs with the TGS itself. To clarify, consult **RFC 4120**.

---

**TGT (Ticket Granting Ticket) Request:**

The client requests a Ticket Granting Ticket (TGT) from the AS (a service of the KDC) by providing its credentials stored in LSASS. This message is known as an AS-REQ. This message likely includes an encrypted timestamp. If you observe Kerberos's behavior using Wireshark, you will notice pre-authentication taking place.  
The AS receives the request, analyzes the timestamp, and then responds with the AS-REP message. This message contains two encrypted parts: the client’s encrypted data and the encrypted TGT that was generated.  
It is important to highlight that only the initial SPN should have permission to access the ticket.  
All TGTs generated are encrypted with the key of the `krbtgt` account.

---

**ST (Service Ticket) Request:**

With the TGT in hand, the client now requests an ST by presenting the TGT to the TGS service to access a specific service, sending a TGS-REQ message. This TGS-REQ includes the TGT and now also the SPN. At this stage, the message contains the TGT, the SPN, the UPN, the session key, and the timestamp.  
The KDC uses its key to decrypt the TGT and thereby access the username and session key. Then, the KDC uses this session key to decrypt the username sent by the client, verifying its validity (`krbtgt`). If everything checks out, the KDC sends a response (TGS-REP) containing two encrypted parts: one is the Service Ticket (ST) for the requested service, protected by the service's key; the other contains client data encrypted with the session key. Some information, such as the service session key, is included in both parts to allow both the client and the service to share the same key and communicate securely.

---

**Service Access:**

With the ST in hand, the client sends an AP-REQ message to the target (SPN), which contains the PAC and the service session key. The service then validates whether the user has access to the service.  
Here, there is a potential decision point: if the server needs to validate permissions using the PAC, it will do so via a `KERB_VERIFY_PAC_REQUEST`. After this validation, if necessary, the server returns an AP-REP message using the session key to indicate that it can decrypt the Service Ticket, confirming access.

---

The image below illustrates the requests and the process between the client machine and the target service.

[![1 A simplified version of the Kerberos authentication system: both the... |  Download Scientific Diagram](https://www.researchgate.net/publication/265007903/figure/fig1/AS:647538654855168@1531396654190/A-simplified-version-of-the-Kerberos-authentication-system-both-the-client-and-a-service.png)](https://www.researchgate.net/figure/A-simplified-version-of-the-Kerberos-authentication-system-both-the-client-and-a-service%5Ffig1%5F265007903?ref=yokai.hakaisecurity.io)

[***https://www.researchgate.net/figure/A-simplified-version-of-the-Kerberos-authentication-system-both-the-client-and-a-service\_fig1\_265007903**](https://www.researchgate.net/figure/A-simplified-version-of-the-Kerberos-authentication-system-both-the-client-and-a-service%5Ffig1%5F265007903?ref=yokai.hakaisecurity.io)

That said, I believe it is appropriate to include this explanation about the Kerberos protocol so we can now understand the Kerberoasting attack, where it occurs during the authentication process, the reason for using managed service accounts, and, finally, analyze the Golden GMSA attack with greater clarity, obtaining a better understanding of the issue raised in this post.

**Kerberoasting**

Kerberoasting is an attack that exploits how the Kerberos protocol distributes Service Tickets (STs) for services in Active Directory. This attack can be performed by any authenticated user without requiring elevated privileges, making it a common threat in Windows environments. Let’s evaluate the Kerberoasting process:

- **Requesting a Service Ticket (ST):** Any authenticated user in the domain can request an ST for any service registered with an SPN (Service Principal Name), even if the service is not running.
- **Encryption of the Ticket:** The ST is encrypted using the password of the service account associated with the SPN.
- **Attack Attempt:** Once the ST is obtained, the attacker can try to decrypt it to discover the service account’s password.

The success of a Kerberoasting attack depends on the complexity and management of the password associated with the SPN. Most services are registered to machine accounts, which have automatically generated passwords that are 120 characters long and rotated every 30 days, making them difficult targets.

However, in some cases, services are registered under manually managed user accounts. These accounts often have weaker passwords, making them attractive targets for Kerberoasting. Since many services are inevitably linked to privileged user accounts—often to make administrators' daily tasks easier—these accounts are of greater interest to attackers.

Although gMSAs (Group Managed Service Accounts) promise a secure solution against Kerberoasting, they introduce new risks that can be exploited, such as the **Golden GMSA attack**. This attack targets the KDS Root Key, which is used to generate and protect the passwords for all gMSAs.

### How does Kerberoasting work within the Kerberos authentication process?

- After receiving the ST, the attacker saves the ticket and, outside the Kerberos environment, uses tools to try to crack the ST encryption.
- The ST key is derived from the service account password in AD. If the password is weak, the attacker can use brute-force or dictionary attacks to uncover the service account password.
- If the attack is successful, the attacker now has a valid credential for the service and can use it to access resources managed by the service.

Thus, the use of gMSA is critical to mitigating Kerberoasting attacks. It is important to recognize that there is a viable solution to address this problem. But does solving this problem create another one?

Now that the Kerberos authentication process and the Kerberoasting attack have been minimally understood, we can analyze the Golden GMSA attack process.

---

**Golden GMSA Attack**

The Golden GMSA Attack involves compromising a machine authorized to access the passwords of Group Managed Service Accounts (gMSA) in Active Directory. This allows the attacker to steal the password and use the compromised service account to access resources. While gMSAs can be used in services that leverage Kerberos for authentication, this attack itself does not directly interact with or manipulate Kerberos, unlike Kerberoasting. Here are the essential elements to understand the attack:

**Critical Attributes:**

- **msDS-ManagedPasswordID:** Contains the identifier for the secure password of the gMSA account.
- **SID (Security Identifier):** Identifies the service account.
- **CurrentPassword:** Stores the gMSA password.
- **msDS-GroupMSAMembership:** Controls which entities can access the gMSA password.

**Attack Timing:**

- The attack occurs when an attacker compromises a machine authorized to access the passwords of Group Managed Service Accounts in Active Directory.
- The attacker obtains the `msDS-ManagedPasswordID` and the `SID` of the gMSA account to generate the associated gMSA password without needing to create a Ticket Granting Ticket (TGT).
- With the gMSA password in hand, the attacker can use the service account to access other resources illegitimately. However, unlike Kerberoasting, this attack does not involve direct manipulation of Kerberos.

**Impact:**

- With a forged TGT, the attacker can impersonate the compromised service account and access domain resources as if they were the legitimate account.

gMSAs use the Kerberos protocol for authentication. Kerberos generates tickets to access services, including the TGT, which allows a service to request, via the S4U2Self extension, authentication delegation without needing additional credentials, enabling continuous access.

For gMSAs, the password is stored in the `CurrentPassword` attribute, and the `msDS-GroupMSAMembership` attribute controls which hosts are allowed to access this password. Passwords are dynamically calculated using the `kdscli.dll` library function, requiring the `SID` and `msDS-ManagedPasswordID`, which can be obtained via LDAP queries.

For the attack to succeed, the following attributes are needed: the KDS Root Key object attributes, along with the `SID` and `msDS-ManagedPasswordID` of the target gMSA object.

From this point, it becomes easier to understand the attack, as we now have sufficient concepts and understanding.

---

**The Attack**

To assist in creating your lab, the commands I used to create the managed service account are provided below:

```powershell
Add-KdsRootKey -EffectiveTime ((get-date).AddHours(-10))
New-ADServiceAccount -Name openfire -DNSHostName openfire.purple.local -PrincipalsAllowedToRetrieveManagedPassword dc1$
Get-ADServiceAccount -Filter *
Test-ADServiceAccount openfire
```

With the proposed scenario and by securing the environment against the Kerberoasting attack using the created managed service account, we can begin the simple process of the Golden GMSA attack.

First, we need to retrieve the managed service account information from our `purple.local` domain using two methods: PowerShell and the GoldenGMSA tool. This will provide us with `objectSid` of the existing service account.

In this initial step, the following command lists ALL existing managed service accounts in the domain and returns the ObjectClass, ObjectGUID, and SID of the account. The target account is "openfire."

```powershell
Get-ADServiceAccount -Filter * -Properties HostComputers
```

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2025/01/image.png)

We can also use the GoldenGMSA tool to obtain the objectSid and rootKeyGuid.

```powershell
\.GoldenGMSA.exe gmsainfo
```

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2024/10/image-2.png)

Another way to obtain the SID of the service account is through PowerShell itself. In this case, the filter used was based on a previously identified service account.

```powershell
Write-Host "The SID of the GMSA openfire$ is: $((Get-ADServiceAccount -Filter {SamAccountName -eq 'openfire$'}).SID.Value)"
```

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2024/10/image-3.png)

With the **objectSid** (S-1-5-21-744271447-2956764748-1961386095-1103) of the desired service account in hand, we will perform a **DUMP** of the **KDS Root Key**. This key is used to encrypt and protect the managed passwords associated with gMSA accounts.

```powershell
\.GoldenGMSA.exe --dump-key a4dfde65-8879-e4ef-3ef5-5834ed0174f1

```

```powershell
\.GoldenGMSA.exe kdsinfo
```

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2024/10/image-4.png)

In this example, I provided the objectSid of the service account resulting from the command.

```powershell
\.GoldenGMSA.exe compute --sid S-1-5-21-744271447-2956764748-1961386095-1103
```

![](https://yokai.hakaisecurity.io/content/images/hakaisecurity-io/wp-content/uploads/2024/10/image-1.png)

### The Defense

To address threats related to Group Managed Service Accounts (gMSA) and legacy servers, it is crucial to focus on preventive measures such as the use of stronger encryption methods and periodic password rotation. However, before implementing these solutions, it is essential to conduct a detailed analysis of the servers and services that rely on older encryption protocols to ensure compatibility with security updates.

During the creation of a managed service account, two parameters are essential to enhance security:

- **Review existing managed service accounts** using the command:powershellCopiarEditar`Get-ADServiceAccount -Filter * -Properties HostComputers`
- **ManagedPasswordIntervalInDays**: By default, password rotation occurs every 30 days. However, this interval can be reduced to, for instance, 15 days, increasing the frequency of rotation and making it harder for compromised credentials to be used for prolonged periods.
- **KerberosEncryptionType**: Adopting stronger encryption methods, such as AES256, enhances protection against attacks, particularly in environments that still use weaker encryption protocols.

In the lab environment, the creation of a managed service account can follow the command below, configuring a 15-day password rotation interval and enforcing AES256 encryption:

```powershell
New-ADServiceAccount -Name openfire -DNSHostName openfire.purple.local -ManagedPasswordIntervalInDays 15 -KerberosEncryptionType AES256 -PrincipalsAllowedToRetrieveManagedPassword adds$
```

In addition to these configurations, leveraging monitoring technologies can add another layer of defense:

- **User and Entity Behavior Analytics (UEBA)**: Assists in identifying suspicious activity related to managed service accounts by analyzing logs and detecting anomalous behavior.
- **Endpoint Detection and Response (EDR)**: Helps detect lateral movements and persistence patterns that may indicate potential compromises in the environment.

With that said, it’s important to understand that in some cases, the implementation of defense techniques is not sufficient on its own; a continuous monitoring process is necessary.

---

### Monitoring

Monitoring access to root keys and managed service accounts, particularly those associated with the `msKds-ProvRootKey` attribute, can help identify unauthorized access by non-domain controller members. This configuration can be found at:

```text
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> Audit Directory Service Access (Enable) and Audit Detailed Directory Service Replication.
```

To view Windows events, access **Event Viewer -> Windows Logs -> Security**, and search for the following Event IDs related to `msKds-ProvRootKey`:

- **Event ID 4662**: Logs operations on Active Directory objects, such as access or modifications, making it relevant for monitoring access to sensitive objects.
- **Event ID 4670**: Indicates changes to permissions on an Active Directory object, signaling modifications to the Discretionary Access Control List (DACL), which may suggest privilege escalation.
- **Event ID 5136**: Logs modifications to attributes of Active Directory objects, critical for detecting unexpected changes to accounts or configurations.

An interesting item to monitor is the Event ID related to the S4U2Self extension:

- **Event ID 4769**: This event occurs when a Ticket Granting Service (TGS) is requested. A request using S4U2Self can trigger this event.
- **Event ID 4771**: Indicates a Kerberos authentication failure, which may occur due to malicious attempts or configuration errors when using S4U2Self.

A key aspect that can elevate a detection team's maturity is analyzing potential anomalies related to Kerberos authentication, such as:

- Unusual Ticket Granting Ticket (TGT) requests;
- Uncommon ticket expiration patterns;
- Use of service accounts on unauthorized hosts;
- Access to service accounts at unusual times;
- Modifications to security attributes of Active Directory objects.

When combined, these practices provide an effective defense against such types of attacks.

---

### Conclusion

Over the years of working in Active Directory environments, it has become evident that managing service accounts and identities poses significant challenges. Attacks like **Kerberoasting**, for instance, highlight the weaknesses of service account passwords and emphasize the importance of proactive measures.

The introduction of Managed Service Accounts (MSAs and gMSAs) by Microsoft, starting with Windows Server 2012, was a positive step to mitigate some risks. The operating system now automatically manages service accounts, eliminating the need to handle complex passwords and frequent rotations manually.

However, new threats constantly emerge. The use of legacy technologies is often inevitable, leading to vulnerabilities like the **Golden gMSA Attack**, which exposes specific weaknesses in gMSAs. Despite their aim to mitigate Kerberoasting, gMSAs are not a definitive solution, as the attack exploits attributes like `msDS-ManagedPasswordID` and `SID` to forge tickets (TGTs), as demonstrated in this post.

Defending against the Golden gMSA Attack requires the adoption of best practices, such as frequent password rotation, modern encryption, and a careful assessment of the impact of these changes to prevent service disruptions. Furthermore, solutions like **User and Entity Behavior Analytics (UEBA)** and **Endpoint Detection and Response (EDR)** are essential for monitoring and detecting anomalous behavior, reinforcing Active Directory security, and mitigating the risk of such attacks.

---

### References

"[https://learn.microsoft.com/pt-br/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts](https://learn.microsoft.com/pt-br/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts?ref=yokai.hakaisecurity.io)"

"[https://learn.microsoft.com/pt-br/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos](https://learn.microsoft.com/pt-br/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos?ref=yokai.hakaisecurity.io)"

"[https://learn.microsoft.com/pt-br/troubleshoot/windows-server/windows-security/recover-from-golden-gmsa-attack](https://learn.microsoft.com/pt-br/troubleshoot/windows-server/windows-security/recover-from-golden-gmsa-attack?ref=yokai.hakaisecurity.io)"

"[https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/recover-from-golden-gmsa-attack](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/recover-from-golden-gmsa-attack?ref=yokai.hakaisecurity.io)"

"[https://github.com/Semperis/GoldenGMSA](https://github.com/Semperis/GoldenGMSA?ref=yokai.hakaisecurity.io)"

"[https://learn.microsoft.com/en-us/openspecs/windows\_protocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13](https://learn.microsoft.com/en-us/openspecs/windows%5Fprotocols/ms-kile/b4af186e-b2ff-43f9-b18e-eedb366abf13?ref=yokai.hakaisecurity.io)"

"[https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-managedpasswordid](https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-managedpasswordid?ref=yokai.hakaisecurity.io)"

"[https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-groupmsamembership](https://learn.microsoft.com/en-us/windows/win32/adschema/a-msds-groupmsamembership?ref=yokai.hakaisecurity.io)"

"[https://we.tl/t-w4qHj8Ejmi](https://we.tl/t-w4qHj8Ejmi?ref=yokai.hakaisecurity.io)"

"[https://learn.microsoft.com/pt-br/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd560670(v=ws.10)?WT.mc\_id=WDIT-MVP-5003815](https://learn.microsoft.com/pt-br/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/dd560670%28v=ws.10%29?WT.mc%5Fid=WDIT-MVP-5003815&ref=yokai.hakaisecurity.io)"

"[https://www.semperis.com/pt/blog/golden-gmsa-attack/](https://www.semperis.com/pt/blog/golden-gmsa-attack/?ref=yokai.hakaisecurity.io)"

"[https://blog.improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-5-golden-gmsa-trust-attack-from-child-to-parent](https://blog.improsec.com/tech-blog/sid-filter-as-security-boundary-between-domains-part-5-golden-gmsa-trust-attack-from-child-to-parent?ref=yokai.hakaisecurity.io)"

"[https://blog.netwrix.com/2022/10/13/group-managed-service-accounts-gmsa/](https://blog.netwrix.com/2022/10/13/group-managed-service-accounts-gmsa/?ref=yokai.hakaisecurity.io)"

"[https://www.trustedsec.com/blog/splunk-spl-queries-for-detecting-gmsa-attacks](https://www.trustedsec.com/blog/splunk-spl-queries-for-detecting-gmsa-attacks?ref=yokai.hakaisecurity.io)"

"[https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-acl?view=powershell-7.2](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/get-acl?view=powershell-7.2&ref=yokai.hakaisecurity.io)"