Ultimate guide to Golden SAML attacks

What is a Golden SAML attack?

Golden SAML is a cyberattack that targets federated authentication systems like Active Directory Federation Services (AD FS). It occurs when an attacker steals the private key or certificate used by an identity provider (IdP), such as AD FS, to sign SAML (security assertion markup language) tokens. This enables the attacker to create fake SAML tokens that appear completely legitimate to all connected services.

With forged SAML tokens, attackers can impersonate any user, including administrators, and gain access to cloud services such as Microsoft 365. Because the forged SAML tokens are cryptographically valid, they bypass traditional authentication methods like multi-factor authentication (MFA) and password checks, making conventional security controls ineffective. The method is similar to Kerberos Golden Tickets but targets federated identity systems.

The main goal of a Golden SAML attack is to acquire stealthy, long-term, high-level access to an organization’s network and cloud services without raising alarms. Armed with the power to impersonate any user and bypass authentication, attackers can view sensitive data, modify configurations, and move laterally across systems while staying under the radar. Even if the organization forces password resets or rotates user credentials, the attacker can maintain access as long as they hold the stolen signing certificate or key.

Federated authentication systems: How do they work

Federated authentication allows users to log in once and access multiple applications, both on-premises and in the cloud, without juggling separate passwords. Here is the usual flow:

1. A user tries to access a cloud app like Microsoft 365.
2. The app redirects the request to the organization’s identity provider (IdP), such as AD FS or Okta.
3. The IdP verifies the user’s credentials and issues a digitally signed SAML token confirming their identity and permissions.
4. The cloud app checks the token’s signature and, if valid, grants the user access without requiring additional logins.

How do attackers exploit it?

Golden SAML attackers target the signing step. By stealing the IdP’s token-signing certificate and private key, they can create their own SAML tokens that look perfectly legitimate, thereby enabling them to access any connected application.

How does a Golden SAML attack work?

A Golden SAML attack unfolds in a series of steps, starting with gaining privileged access and ending with long-term, stealthy control of cloud and on-premises resources. Here are the different phases of the attack:

1. Gain administrative privileges

Attackers begin by breaching the network to reach the AD FS or any other SAML identity provider server, and escalate to local or domain administrator rights. They might exploit unpatched vulnerabilities, steal privileged credentials through phishing or pass-the-hash techniques, or leverage misconfigurations that allow privilege escalation.

2. Extract token-signing certificate and private key

With admin control, attackers use tools like ADFSdump, Mimikatz, and built-in PowerShell modules to extract the following from the AD FS configuration database, Windows certificate store, or Active Directory, depending on where those are located.

• Token signing certificate and its private key: the “master key” for issuing SAML tokens
• Distributed Key Manager (DKM) key: essential for decrypting the stored certificate data in multi-server AD FS clusters
• List of trusted relying parties: gives attackers the roadmap of all applications and services they can access with forged tokens

The tools they use can read the private key material if it is not protected by a hardware security module (HSM).

3. Forge SAML tokens

Using the stolen private key, the attacker uses tools like ADFSpoof to generate fraudulent SAML assertions that appear to be legitimately issued by the IdP. They can set any username or group membership inside the assertion. In this way, they can grant themselves global administrator or root-level access.

4. Access federated applications

The adversary now simply has to use the forged SAML token to sign into cloud services (such as Microsoft 365, Microsoft Entra, AWS, and Salesforce) or on-premises applications that trust the IdP. Because the tokens are cryptographically valid, these services accept them without challenge, granting full access to email, storage, and administrative portals without password or MFA prompts.

5. Maintain persistence

Since the attack relies on the stolen signing certificate rather than passwords, normal password resets or MFA changes do not block the attacker’s access. You must replace the compromised certificate to stop the attacker from issuing new forged tokens.

Attack flow diagram

The Golden SAML attack follows a predictable chain of events. Let’s look at an example attack scenario and visualize the attack stages to understand how an attacker can move from an initial breach to freely accessing cloud or on-premises applications.

A mid-size financial services company notices unusual network scanning activity but nothing serious. Weeks later, attackers lure a privileged IT administrator with a phishing email and steal the AD FS service account credentials.

Using them, they remotely access the AD FS server, export the token-signing certificate, and use it to create their own SAML assertions that impersonate a global administrator. With these forged tokens, and without needing passwords or MFA, they log in to Microsoft 365 and AWS, downloading sensitive client data and creating hidden mail forwarding rules to maintain persistence.

The intrusion remains invisible until the company notices unexplained mailbox forwarding and correlates it with abnormal token-issuance patterns.

Examples of Golden SAML attack

These well-known examples help illustrate how Golden SAML attacks play out in the real world.

Consequences of a Golden SAML attack

A successful Golden SAML attack can have wide-ranging effects that ripple through the organization. It not only compromises immediate security but also threatens operational continuity, financial stability, regulatory compliance, and long-term stakeholder trust.

Common targets of Golden SAML attack: Who is at risk?

Golden SAML attacks aim for organizations that use single sign-on (SSO) and cloud identity providers. They know that stealing a federation signing certificate can unlock broad, long-term access. The following groups are especially attractive to attackers:

Risk assessment

A Golden SAML attack poses a high-impact threat because it exploits the very trust model that supports SSO and federated authentication. By understanding its likelihood, potential damage, technical complexity, and existing security gaps, organizations can assess exposure and build defenses.

How to prevent a Golden SAML attack

Preventing a Golden SAML attack is about protecting signing keys, tightening privileged access, and reducing the chance that attackers can misuse identity infrastructure.

• Rotate signing certificates and private keys regularly: Schedule frequent rotation of token-signing certificates and associated private keys. This way, stolen credentials quickly become useless to an attacker.
• Store AD FS private keys securely: Keep token-signing certificates and private keys in locations with strong access controls and encryption. This will prevent attackers from copying them even if they gain partial system access.
• Use hardware security modules (HSM) for key protection: Place the signing key inside an HSM so that it never leaves secure hardware. This makes it harder for attackers to export or misuse the certificate.
• Restrict AD FS administrative access: Limit who can manage AD FS, enforce the principle of least privilege, and monitor all administrative actions to reduce opportunities for certificate theft.
• Apply strict patching and hardening on identity providers: Keep AD FS and other federation servers fully patched and remove unnecessary services. Organizations must also implement hardening best practices to close any vulnerabilities that could allow escalation to administrator level.
• Enable MFA everywhere: Enable MFA for all privileged and user accounts, including administrators of identity systems. Although it does not prevent a Golden SAML attack in itself, it at least makes initial compromise and lateral movement significantly harder.

Recommended security tools

The following security tools can help detect and block attempts to steal signing certificates and forge tokens:

• Endpoint detection and response (EDR): EDR tools provide real-time monitoring of servers and workstations, detecting suspicious behaviors such as attempts to dump credentials, tamper with AD FS, or exfiltrate private keys. Quick action from EDR can stop an attacker before they reach the identity infrastructure.
• Privileged access management (PAM): PAM solutions tightly control and monitor administrative accounts, enforce just-in-time access, and record privileged sessions. This limits opportunities for attackers to steal the credentials needed to extract a token-signing certificate.
• Security information and event management (SIEM): A SIEM platform aggregates and correlates logs from identity providers, cloud services, and endpoints. By flagging unusual authentication patterns, certificate exports, and unexpected admin activity, it can reveal the lateral movement and privilege escalation that precede a Golden SAML attack.

How Netwrix can help

Netwrix provides a complete identity-focused defense to prevent, detect, and respond to Golden SAML and other identity-based threats by combining continuous auditing, privileged access controls, certificate and key security, and anomaly detection:

Netwrix Privilege Secure

Privilege Secure helps reduce standing privileges by using just-in-time access, session monitoring, and secure credential vaults. If attackers cannot hold persistent admin credentials or access, it is much harder to steal a signing certificate.

Netwrix Identity Manager (SaaS-based IGA)

By automating identity lifecycle (joiners, movers, leavers), mandating that privileged rights are reviewed, and enforcing least privilege and separation of duties, Identity Manager helps ensure that nobody has more access than needed. It detects high-risk roles and mis-aligned permissions, enabling you to catch over-privileged accounts or unused ones that might otherwise give an attacker a foothold.

Netwrix Auditor

Auditor provides visibility into changes in Active Directory (including AD FS-related configurations), group membership changes, modifications to privileged accounts, and logon patterns. With good auditing, unusual or unauthorized changes (for example, export of certificates, modified privileges) can be detected faster.

Netwrix Identity Threat Detection and Response (ITDR)

Netwrix ITDR helps organizations detect and stop identity-based attacks like Golden SAML before they escalate. By combining real-time threat detection with proactive risk reduction and automated response, ITDR enables security teams to quickly identify abnormal authentication behavior, privilege misuse, and token abuse across Active Directory and Entra ID.

With continuous monitoring and behavioral analytics, ITDR surfaces suspicious activity early and triggers automated containment actions to limit attacker movement. By working alongside privileged access management and directory security controls, it reduces the likelihood of token forgery attacks while minimizing attacker dwell time and overall impact.

Detection, mitigation, and response strategies

Golden SAML attacks are hard to spot. Organizations should combine careful monitoring, strict certificate management, and a rapid response plan to detect, contain, and prevent them.

Detection

Golden SAML attacks are tricky to catch because the forged SAML tokens look completely legitimate. But careful monitoring of federation servers and related logs can help you spot unusual activity.

Monitor federation and cloud authentication logs

When a user signs in to a cloud app through AD FS, two things normally happen:

• AD FS records a log entry showing it issued a SAML token for that user.
• The cloud app logs the user’s successful sign-in using that token.

If you see a login recorded by the cloud service without a matching AD FS authentication event, or if the token lacks the expected Correlation ID that ties the two logs together, it suggests the token did not come from your AD FS. This mismatch can be a red flag that someone forged a SAML token (as in a Golden SAML attack) and accessed the cloud app.

Track certificate and trust changes

Enable detailed auditing on AD FS and watch for certificate export attempts or unauthorized modifications to federation trust settings. These Windows and AD FS event IDs help you spot suspicious certificate activity that could signal a Golden SAML attempt:

• Event ID 70 (AD FS server): Logged when an AD FS token-signing or token-decryption certificate is exported or backed up. An unexpected export may mean someone is trying to steal the private key.
• Event ID 1007 (AD FS server): Indicates a change to the AD FS configuration, such as adding or removing a signing certificate or altering trust relationships. Unauthorized changes can enable token forgery.
• Event ID 4662 (domain controller): Generated when a directory object is accessed with specific permissions. If it references the AD FS service account or the certificate store, it can point to attempts to read or copy the private key.
• Event ID 18 (AD FS server): Triggered when a named-pipe connection to the WID database occurs from any process other than the AD FS executable. Detecting it requires Sysmon to be properly installed and configured.

Detect unusual token issuance and admin activity

Correlate token-issuance times, IP addresses, and geolocations with normal user behavior to flag anomalies. Also monitor for suspicious administrator actions, such as unexpected privilege elevation, abnormal service-principal use, or unusual logins to AD FS servers and from the AD FS service account.

Watch for low-level system anomalies

Investigate unexpected named-pipe access to the AD FS database (Sysmon Event ID 18) and other irregular system activities.

Named pipes are special communication channels Windows uses for processes to talk to each other. Under normal conditions, only AD FS and its related services should access the AD FS database through these pipes. Sysmon Event ID 18 records when a process connects to a named pipe. If you see an unexpected process accessing the AD FS database pipe, it can mean an attacker is trying to read or copy the token-signing keys stored there.

Immediate response

When you suspect a Golden SAML compromise, act fast to cut off attacker access, secure new signing credentials, and investigate thoroughly.

Contain and investigate

• Immediately isolate the affected AD FS or identity-provider servers to prevent further tampering.
• Preserve volatile evidence such as memory captures, current network connections, and running processes.
• Begin a detailed forensic analysis to learn how the signing certificate or private key was accessed and to identify any lateral movement.

Replace the token-signing certificate

• Invalidate the compromised certificate immediately. This is the only way to break the attacker’s ability to mint tokens.
• Reissue a new signing certificate and reconfigure every relying party (cloud services like Microsoft 365, AWS, Salesforce, etc.) to trust only the new certificate.
• Audit all active SAML sessions and revoke or invalidate any suspicious tokens.
• Rotate all federated trust relationships and keys.
• Disable or rotate credentials for compromised service accounts.

Communicate and recover

• Notify affected cloud/service providers and seek their help to revoke or invalidate any active forged sessions.
• Inform internal stakeholders, legal/compliance teams, and (if required) regulators.
• Alert your incident response team and begin containment procedures.
• After containment, perform a full root cause analysis and update incident-response plans.

Long-term mitigation

To reduce the chance of a Golden SAML attack and strengthen overall identity security, adopt a strategy that limits attacker opportunities and improves visibility.

• Enforce least-privilege access and harden AD FS/IdP servers, including secure key storage and regular patching.
• Implement enhanced, real-time monitoring and alerting for suspicious authentication activity.
• Enable comprehensive, high-verbosity auditing across AD FS, certificate services, and Sysmon, forwarding logs to a SIEM.
• Correlate AD FS and cloud provider authentication logs in the SIEM and conduct regular threat-hunting exercises.
• Regularly rotate token-signing certificates and update all relying parties.

The guidance in the How to prevent a Golden SAML attack section can serve as effective long-term mitigation strategies.

Industry-specific impact

Golden SAML attacks can strike any sector that relies on federated identity and single sign-on, but the consequences vary by industry. These could include data breaches, regulatory violations, and financial loss tied to each industry’s unique risks.

Attack evolution and future trends

As more organizations move to hybrid and multi-cloud setups, attackers are increasingly targeting federation infrastructure like AD FS. They are sharpening their techniques and looking for new targets, making it essential for organizations to understand how Golden SAML attacks are evolving.

Key statistics and infographics

This section highlights essential numbers and visuals that capture the scale and impact of Golden SAML threats.

1. According to the Global Cybersecurity Outlook 2023 report by the World Economic Forum, over 93% of cybersecurity experts and 86% of business leaders believe that “a far-reaching, catastrophic cyber event is likely in the next two years.”
2. SolarWinds and US government reporting state that up to 18,000 SolarWinds customers downloaded the compromised Orion update, potentially exposing them (see the complete report here). Several authoritative analyses and advisories note that Golden SAML is one of the notable post-compromise techniques the threat actors used in the SolarWinds attack.

Bar graph showing Golden SAML attack incidents by year

The Golden SAML technique was first reported in 2017 by CyberArk. The SolarWinds incident marks the first time it is known to have been used in the wild.

Pie chart showing most frequently targeted industries

Final thoughts

Golden SAML attacks expose a critical vulnerability in modern enterprise security: the very systems meant to secure our digital identities can become powerful weapons in the wrong hands.

As organizations increasingly rely on federated authentication for cloud services and remote access, securing identity infrastructures is imperative. Organizations must implement sophisticated defenses, such as robust certificate management, continuous monitoring of SAML tokens, and security hardening of AD FS or other identity providers.

In an era where identity is the new perimeter, protecting our federated systems is protecting our entire digital ecosystem.