gMSA exploitation attacks and Golden gMSA attacks explained

What is a gMSA attack?

A group Managed Service Account attack is an intrusion where attackers compromise or compute gMSA credentials to obtain unauthorized access to services and escalate privileges across an Active Directory environment.

gMSAs are used for Windows services, IIS application pools, SQL Server services, scheduled tasks, backup services, and other automated service identities where a service needs an automatically managed domain credential. gMSA abuse provides a broad attack surface because every system or service that is authorized to retrieve or run with a gMSA becomes a potential entry point for attackers. By reading gMSA passwords and exploiting these accounts, attackers can impersonate service identities, move laterally within the domain, and maintain persistent presence that is difficult to detect and remediate.

Attackers mostly use the following methods for gMSA exploitation:

• Read msDS-ManagedPassword: Attackers compromise a host or account with SYSTEM/authorized access and read the msDS-ManagedPassword attribute for a gMSA from Active Directory. This attribute contains the current and previous passwords for the gMSA, so by reading the attribute values, attackers actually read gMSA passwords.
• Golden gMSA (KDS root key abuse): Adversaries obtain the KDS (Key Distribution Service) root key attributes (stored in CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=domain,DC=com) and use it to compute gMSA passwords offline, without contacting a domain controller. By forging valid credentials, attackers can authenticate as those service accounts at any time.

Golden gMSA attacks

Here are the key characteristics of a Golden gMSA attack:

• Initial compromise requires high-level rights (for example, Domain Admin or SYSTEM account on a domain controller) to read or export the KDS root key material.
• Once the KDS root key attributes are obtained, attackers can:
  • Calculate current and future gMSA passwords without contacting a domain controller, so it does not generate authentication logs on DCs.
  • Devise credentials for any gMSA in the domain.
  • Maintain persistent access even after the initial compromise is detected (the root key is valid for up to 10 years by default).
• Conceptually, a Golden gMSA attack is analogous to a Golden Ticket attack, as both involve creating forged or derived credentials.

Tool uses

The following tools and scripts facilitate Golden gMSA exploitation:

• Credential-dumping utilities are used to extract credentials or credential material from a host so an attacker can escalate or move laterally. Targets include memory where authentication tokens/NTLM hashes live, cached credentials, and backup copies of credential stores.
• AD-enumeration utilities map Active Directory objects, permissions, and relationships so an attacker can find where sensitive keys/objects live (for gMSA: KDS root keys, msDS-ManagedPassword objects, and service bindings). They probe group membership, ACLs, and attributes.
• Proof-of-concept utilities and custom scripts implement mathematical/cryptographic logic that derives gMSA passwords from the KDS root key and object metadata.

How does a gMSA attack work?

A gMSA exploitation attack follows a staged path: the attacker begins by discovering where gMSAs are used and ultimately manages to move laterally and escalate privileges in a persistent, stealthy manner. Here are the phases of the attack:

Discover gMSA usage

Attackers begin by mapping where gMSAs are deployed across the environment. They scan Active Directory and endpoints to identify services, application pools, scheduled tasks, and database or backup processes that run under gMSA identities. With that mapping, they probe those hosts for exploitable vulnerabilities (such as web server RCE, unpatched service flaws, and weak service configurations) that can be abused to gain code execution or escalate to NT AUTHORITY\SYSTEM.

Access gMSA passwords

On a compromised host with SYSTEM privileges or via an account with sufficient Active Directory permissions, the attacker uses tools or APIs (for example, PowerShell with DSInternals or directory reads) to retrieve the msDS-ManagedPassword attribute. The attacker then decodes the credential blob into plaintext (or an NTLM hash), often using the PowerShell function ConvertFrom-ADManagedPasswordBlob. With those plaintext or derived credentials, the attacker can log in as the service account, run the service, access any resources it can reach, and move to other systems with little effort.

Golden gMSA attack

In a Golden gMSA scenario, an adversary extracts the KDS root key attributes (such as msKds-RootKeyData, msKds-KDFParam, and related KDF parameters) that Active Directory uses to derive gMSA passwords. Using tools like GoldenGMSA or custom scripts, they can calculate current and future gMSA passwords offline. In this way, they can authenticate to any service that relies on those gMSAs.

Lateral movement or privilege escalation

Once gMSA credentials (whether directly read or computed from the KDS key) are in the attacker’s control, they can use them to:

• Authenticate to databases, management interfaces, file shares, or other services that accept the gMSA.
• Pivot to other hosts that trust the service identity.
• Combine with Silver Ticket or Golden Ticket techniques, or token abuse to escalate privileges.
• Exfiltrate sensitive data.
• Deploy persistence or create new privileged service accounts.

Services running under gMSAs usually operate with elevated privileges and extensive connectivity, giving attackers a broad attack surface to exploit.

Attack flow diagram

Here is a flow diagram explaining the chain of events in a gMSA attack and an example story from an organization’s perspective to help you understand the attack.

An attacker compromises an organization’s customer-facing web server via a vulnerable plugin, plants a web shell, escalates to SYSTEM on that host, and extracts service credential material. Using the dumped KDS root key and KDF parameters, they compute gMSA passwords offline and authenticate to backend services (database and file shares) without connecting to the domain controller. Over 48 hours, they exfiltrate sensitive customer records.

Examples of gMSA attacks

There are no publicly available reports or breach disclosures saying that an attacker used a gMSA or Golden gMSA attack in the wild. But there is extensive research, PoCs, tools, and vendor guidance that prove that the technique is real and practical. The following is a summary of real-world evidence.

Consequences of gMSA attacks

IT teams use gMSAs for automated, high-privilege access. Their theft can amplify an incident, enabling stealthy lateral movement, long-lived access, and wide data exposure. This can mean severe financial, operational, reputational, and legal consequences.

Common targets of gMSA attacks: Who is at risk?

Broadly speaking, large enterprises, government agencies, and financial institutions that operate complex Active Directory environments with many gMSAs for services (SQL, IIS, Exchange, backups) are among the most common targets for gMSA attacks. From a technical perspective, the following components in an IT infrastructure are most at risk:

Risk assessment

To assess the risk of gMSA attacks, you should consider three key factors: the potential damage from an attack, how difficult the attack is to execute, and the likelihood of it occurring. Together, they highlight why gMSAs demand strong protection and monitoring.

How to prevent gMSA attacks

By implementing strong technical controls and sound administrative practices, organizations can reduce the risk of a gMSA exploitation attack.

Technical measures

The following technical measures can help prevent gMSA and Golden gMSA attacks:

• Configure system access control lists (SACLs) on KDS root keys to log any attempts to read the msKds-RootKeyData attribute. In this way, security teams are alerted if attackers try to access the secrets used to derive gMSA passwords.
• Enforce least privilege on gMSA memberships. To do this, limit which accounts and groups are listed in the msDS-GroupMSAMembership attribute of a gMSA. Only services that actually require the gMSA should have access. Removing unnecessary memberships helps close off potential abuse paths.
• Regularly review who has permission to manage and use gMSAs. Security teams should audit changes to permissions and usage patterns to spot suspicious activity that might signal unauthorized access and privilege escalation attempts.
• Lower the value of the ManagedPasswordIntervalInDays setting so that gMSA passwords are updated more frequently. This limits the window of opportunity for attackers to reuse compromised credentials.

Administrative best practices

As part of administrative best practices, organizations should maintain strict control over gMSA lifecycle and key management.

• Periodically create new KDS root keys and reassign them to your active gMSAs. This prevents old or potentially compromised keys from being used to derive valid gMSA passwords.
• Monitor Event ID 4662, which records attempts to access directory objects. Monitoring this event specifically for gMSA attributes can help detect unauthorized access or suspicious queries.
• Proactively disable gMSAs that are no longer in use and remove orphaned permissions from old services. This reduces the number of accounts available for attackers to exploit, minimizing your overall attack surface.

How Netwrix can help

Netwrix’s Identity Threat Detection & Response (ITDR) suite helps organizations identify suspicious activities and secure their identity infrastructure in on-premises and hybrid environments. It offers visibility, alerting, response, and recovery capabilities that are relevant to defending gMSAs.

Here are some of its core capabilities and how they map to preventing or mitigating gMSA-related risks:

Threat detection

Netwrix ITDR products, such as Threat Manager and Threat Prevention, can spot suspicious activities related to the identity infrastructure, such as unusual or unauthorized changes in Active Directory. They can monitor object and attribute-level changes and access in AD (such as unauthorized reads of the msDS-ManagedPassword and msKds-RootKeyData attributes), and can alert on risky configuration changes or privileged group membership changes.

Real-time monitoring and alerting

Netwrix ITDR provides real-time alerts on critical Active Directory events and anomalous access patterns. This includes monitoring non-domain controller accounts attempting to access sensitive KDS attributes, membership of sensitive groups, and modifications to privileged attributes. These monitoring features help detect gMSA misuse.

Rapid response

Netwrix ITDR supports automated or semi-automated incident response actions in case a compromise is detected, such as disabling accounts, generating alerts, rolling back undesired changes, and initiating forensic investigations. In a gMSA-attack scenario, this means you can respond swiftly when suspicious activity is detected, such as disabling the gMSA or revoking permissions.

Security audit and reporting

Netwrix Auditor provides detailed audit trails, “before and after” values for AD changes, risk assessment reports, dashboards, and compliance reporting. These are useful for tracking gMSA permission changes, usage over time, and identifying misconfigurations.

Detection, mitigation, and response strategies

To defend against gMSA-related attacks, organizations should adopt a proactive approach that spans early detection, preventive mitigation, and effective response. Here are some practical steps to strengthen your defenses against KDS root key and gMSA compromises.

Detection

To detect a gMSA attack early, teams should follow these practices:

Monitor for unauthorized reads of critical attributes such as msDS-ManagedPassword and msKds-RootKeyData

These attributes are directly tied to gMSA password retrieval and offline password generation, and are rarely accessed outside of normal domain controller operations. Unusual queries against them may indicate credential harvesting attempts. To detect this, administrators can enable directory service auditing in Active Directory and configure Advanced Security Auditing to log Directory Service Access (Event ID 4662).

Check for non-DC accounts accessing sensitive KDS attributes

Only domain controllers should interact with KDS root key data. Monitoring access by unexpected accounts can reveal privilege misuse or lateral movement attempts.

Combine monitoring with analytics

By filtering for reads on sensitive attributes and correlating them with account type (such as non-DC accounts), security teams can detect suspicious queries. Better yet, integrate these logs into a SIEM platform for cross-event correlation, anomaly detection, and real-time alerting.

Baseline normal gMSA usage across services and servers

This enables anomaly detection when gMSAs are accessed outside their expected scope (for example, a SQL gMSA being used on a web server).

Mitigation

IT teams should approach mitigation as a coordinated, layered effort that not only cuts off the attacker’s current access but also strengthens defenses to minimize the chances of future compromise. Some important mitigation steps are discussed below.

Recreate gMSAs against a new KDS root key when compromise is suspected

Generating a fresh root key cuts off an attacker’s ability to derive passwords from previously exposed artifacts, restoring trust in managed accounts.

Roll gMSA passwords by running Test-ADServiceAccount

Forcing a password refresh ensures that even if credentials are compromised, attackers lose access to valid secrets.

Apply segmentation and enforce scope

Implement network and service segmentation to limit where gMSAs can be used. This way, if one tier is compromised, attackers cannot easily move into other sensitive areas.

Regularly test your remediation playbooks

Conduct tabletop and technical exercises that simulate KDS key rotation and gMSA recovery to make sure that your procedures are effective and work under pressure.

Response

When a gMSA attack is suspected or confirmed, organizations must act decisively to contain the threat, limit damage, and prevent recurrence.

Quarantine affected systems

Isolate compromised hosts to prevent attackers from further lateral movement or continued misuse of compromised gMSA credentials. You must also isolate domain controllers if suspicious access to msKds-RootKeyData or other critical attributes is detected, ensuring that attackers cannot persist in directory services.

Disable compromised gMSAs

Disable compromised gMSAs immediately to block adversaries from using them for authentication and malicious activity.

Rotate all relevant credentials and update affected services

Rotate all relevant credentials, including gMSAs, service accounts, and administrative accounts. Then update affected services to ensure smooth re-authentication with newly rotated gMSAs.

Preserve forensic artifacts and initiate forensic investigation

A forensic investigation helps determine the scope and root cause of the incident. Make sure you capture domain controller and Configuration NC data, such as logs and NTDS snapshots, before making irreversible remediation changes. It is important to balance the urgency of stopping the attack with the need to retain evidence for analysis. Next:

• Review event logs, SACL alerts, and identity-related anomalies.
• Capture volatile data (such as memory dumps and authentication logs) from impacted systems for post-incident analysis.
• Look out for persistence mechanisms such as scheduled tasks, modified ACLs, or shadow admin accounts that may have been introduced during the compromise.

These steps can help identify attack mechanisms and close security gaps.

Industry-specific impact

The impact of gMSA attacks is not the same for all industries. By understanding industry-specific consequences, organizations can prioritize defenses based on their most valuable assets.

Attack evolution and future trends

As organizations adopt gMSAs to enhance security and simplify password management, attackers are busy advancing their techniques to exploit these accounts. The following trends highlight how adversaries are exploiting gMSA weaknesses and where the threat landscape is headed.

Key statistics and infographics

gMSAs are designed with strong security features, but attackers targeting the KDS root key can bypass these protections. Let’s have a look at some supporting facts and statistics:

• gMSAs rotate their passwords every 30 days to limit credential exposure. But if attackers steal the KDS root key, they can compute gMSA passwords offline at any time, effectively nullifying the rotation safeguard.
• Because every gMSA in a domain relies on the same KDS root key for password generation, compromising this one root key can impact all gMSAs in the domain. This creates a domain-wide risk from a single point of failure.

The following bar chart compares the intended security window (30-day rotation) against the actual attacker access window (indefinite if KDS is compromised).

Final thoughts

In the end, gMSAs are a double-edged sword, they simplify service authentication and strengthen security when managed correctly, but in the wrong hands, they can become keys to the kingdom. When attackers forge a Golden gMSA, they don’t just steal a password; they inherit the master key to your infrastructure, with the power to move silently across systems and services. The danger lies in their invisibility: simmering unnoticed until the entire enterprise is at risk. Protecting your KDS root keys, monitoring for suspicious gMSA activity, and implementing strong domain controller security are essential safeguards for your Active Directory environment.