Introduction

Golden SAML has become one of the most effective identity-subversion techniques available to red-team operators targeting hybrid environments. Its power comes from its simplicity: if a cloud provider trusts an identity provider’s signing certificate, then anyone holding that private key can mint their own identities out of thin air. This blog will walk through the Golden SAML technique as a hands-on attacker would approach it—identifying weak federation deployments, extracting the cryptographic material that controls cloud trust, and forging cloud identities that slide past MFA, login monitoring, and conditional access gates.

This is not a conceptual overview. This is the operator’s view, focusing on direct methods, artifacts, token structure manipulation, and detection avoidance. Defenders will gain insight into exactly how attackers execute this technique and what traces they tend to leave behind.

1. Understanding the SAML Trust Chain as an Attack Surface

Before exploiting SAML, a red-team operator must understand how federation is actually implemented inside a hybrid enterprise. The vast majority of organizations using Entra ID (Azure AD), AWS, or GCP implement one of two federation patterns:

• On-prem AD FS acts as the SAML Identity Provider (IdP)
• A third-party SAML IdP (PingFederate, Shibboleth, Okta) signs assertions

In every scenario, the cloud provider has one critical question: Do I trust the signature on this SAML assertion?
If the answer is yes, the cloud platform will issue a session to whatever identity appears inside that assertion—regardless of whether MFA was passed, whether the account exists on-prem, or whether the user is even real.

This creates a single point of catastrophic failure: the token-signing certificate’s private key.

Once acquired, the certificate becomes the operator’s master key. It lets the attacker fabricate:

• Any username
• Any UPN
• Any group or role assignment
• Any expiration timestamp
• Any session context

Cloud providers do not call back to the IdP to confirm the assertion. They trust the signature. This unilateral trust is what Golden SAML exploits.

2. Reconnaissance: Identifying Federation & Locating the IdP

The first phase is identifying how the target enterprise federates. Operators typically rely on three reconnaissance vectors:

2.1 Passive DNS, MX, and HTTP Enumeration

Public endpoints often reveal federation footprints:

• https://login.company.com/adfs/ls/
• Presence of AD FS metadata files (FederationMetadata.xml)
• Okta or Ping endpoints in traffic captures
• SAML response headers during authentication redirections

A passive HTTP capture during an Entra login can clearly show if the workflow redirects to an external IdP.

2.2 Cloud Enumeration

Azure’s Get-MgDomainFederationSettings, AWS STS logs, or Okta tenant information often reveal federation settings, sometimes including thumbprints of the certificate used by the IdP.

If the environment shows federation, the target is viable for Golden SAML.

2.3 Internal Discovery After Foothold

Once inside the network, enumerate:

• AD FS servers (Get-AdfsProperties)
• Federation services names
• Group membership of AD FS Admins
• Certificate stores (especially machine-level personal store)
• The AD FS configuration database or WID instance

At this stage, the operator determines whether privilege escalation is needed to reach the signing key.

3. Privilege Escalation: Gaining Access to the Signing Certificate

To extract the signing certificate, the operator generally needs:

• Local admin on the AD FS server
• OR membership in the AD FS Admins group
• OR Domain Admin (which effectively grants everything)

There are three common approaches to escalations:

3.1 Targeting AD FS Service Account

Because AD FS often uses a domain service account, compromise of this account—via Kerberoasting or LSASS extraction—grants the ability to export the certificate.

3.2 Lateral Movement into the AD FS Host

Techniques include:

• Token impersonation (silver ticket)
• Pass-the-hash against AD FS admin accounts
• Exploiting unpatched local privilege escalations

Once on the server, gaining SYSTEM is trivial with common tools.

3.3 Compromising the WID or SQL Server Backing AD FS

Exporting the private key can be done by pulling the certificate directly from the AD FS configuration database. Operators rarely take this route unless the certificate store is heavily hardened.

The most common pattern on real engagements remains:
Gain admin → Dump certificate → Leave quietly.

4. Extracting the Token-Signing Certificate

With SYSTEM on the AD FS host, the operator can now retrieve the signing certificate.

Two primary methods exist:

4.1 Using Built-In Certutil

Operators can export the private key directly:

certutil -exportPFX My <thumbprint> c:\windows\temp\adfs.pfx

If protected with a password, the attacker sets a new one during export.

4.2 Using Mimikatz

Mimikatz has a specific module for Golden SAML:

privilege::debug
token::elevate
crypto::certificates /export

This pulls all certificates with exportable keys from the machine store.
The operator then isolates the AD FS signing certificate based on:

• Thumbprint
• Validity period
• Key usage (Digital Signature)

In some environments, admins inadvertently mark the key as exportable.
In others, operators use DPAPI extraction to bypass restrictions.

Regardless of method, once the .pfx file is retrieved, the red-team operator now controls the identity trust fabric for the entire cloud environment.

5. Forging a Golden SAML Token

The forged token must resemble a legitimate SAML assertion. Tools like Mimikatz’s goldensaml module or custom Python scripts with python3-saml libraries can generate assertions. Operators typically follow these steps:

5.1 Define the Desired Identity

The attacker chooses:

• UPN (often a global admin like admin@company.com)
• ImmutableID (if Azure AD requires it)
• Role claims (AWS roles, Entra directory roles)

It is common to impersonate accounts that exist so that activity blends with real logs.

5.2 Build the SAML Assertion Structure

A SAML assertion contains:

• <Assertion> block
• <Subject> containing the name identifier
• <Conditions> with NotBefore/NotOnOrAfter timestamps
• <AttributeStatement> defining group membership
• <Signature> element referencing the private key

Operators often artificially extend assertion validity windows, creating tokens that can last hours—or days—without requiring renewal.

5.3 Sign the Token

Using OpenSSL or Mimikatz, the attacker signs the constructed token with the stolen certificate. The signature validates against the thumbprint stored in the cloud provider’s federation configuration.

5.4 Encode & Craft the Final SAMLResponse

The assertion is base64-encoded and wrapped in a SAML HTTP POST binding, identical to legitimate IdP output.

At this point, the attacker can submit the forged assertion directly to the cloud provider’s SAML2/ACS endpoint.

6. Consuming the Golden SAML Token

6.1 Azure AD / Entra ID

Submitting the assertion to:

https://login.microsoftonline.com/login.srf

results in Entra issuing a primary refresh token (PRT) and cloud session cookies for:

• Exchange Online
• SharePoint
• Graph API
• Conditional Access–protected resources (if policies don’t require device binding)

The user never appears in AD FS logs because the IdP never saw the request.

6.2 AWS

AWS STS accepts SAML assertions at:

https://signin.aws.amazon.com/saml

The operator can use:

aws sts assume-role-with-saml

to obtain temporary credentials for high-privilege roles.

6.3 GCP and Other SaaS Platforms

Most SaaS platforms that support SAML federation accept fully unsigned sessions once the signing certificate matches their configuration.

7. Maintaining Access via Forged Identity

Real operators rarely generate a single token and walk away. Instead, they use strategic persistence methods:

7.1 Generating API Keys or App Registrations

Once impersonating a cloud admin, create:

• Azure app registrations with certificate-based auth
• AWS IAM access keys
• OAuth secrets

These last long after the federation compromise is cleaned up.

7.2 Implanting Conditional Access Bypass Rules

Operators sometimes create CA exceptions, such as “allow from legacy application,” which effectively grants unbounded access.

7.3 Creating Shadow Admins

Attackers create new accounts, assign roles, and hide them via obscure naming conventions or disabled-by-default groups.

The forged SAML token is simply the initial foothold into long-term cloud control.

8. Detection Avoidance Strategies

Golden SAML’s strength lies in the absence of IdP-side logs. However, cloud trails still exist, and a careful operator tries to remain quiet.

8.1 Mimicking Legitimate Login Patterns

Red teams avoid:

• Impossible travel
• Access from new IP ranges
• Sudden elevation to global admin

They instead:

• Reuse compromised employee workstations
• Tunnel through corporate VPNs
• Log in during business hours

8.2 Matching Token Lifetimes to Policy

An assertion valid for 24 hours stands out.
Operators set lifetimes matching the enterprise’s standard, often 1–10 minutes.

8.3 Using Real Groups Instead of Dumping Everything

Defenders often flag tokens carrying excessive role lists.
Operators copy real attribute sets.

8.4 Avoiding Excessive API Calls

Large SharePoint or S3 data pulls trigger alerts.
Operators do short bursts, blend with normal noise, or exfiltrate via compromised user machines.

8.5 Leveraging Stolen Refresh Tokens

After forging the first SAML assertion, attackers extract the issued refresh tokens from browsers or token caches, then continue sessions without repeated SAML assertion submissions.

This limits the number of artifacts defenders can detect.

9. Defensive Visibility Gaps (Exploited by Attackers)

A red-team operator capitalizes on the following weaknesses:

9.1 Organizations Rarely Rotate Signing Certificates

Many enterprises use token-signing certificates valid for 5+ years.
If a key is compromised in year one, Golden SAML remains viable for the lifespan of the certificate.

9.2 Cloud Providers Don’t Validate Authentication Against the IdP

Entra, AWS, and others never check:

• Did this assertion come from my IdP?
• Was MFA passed?
• Did the user authenticate interactively?

They check only the signature.

9.3 AD FS Logging Is Blind to Forged Tokens

Because the assertion never went through AD FS, none of the expected:

• Event ID 1202 (token issuance)
• Event ID 307 (successful authentication)

appear.

9.4 Legacy Federation Configurations Rarely Monitor Key Access

Attacks often go unnoticed because certificate exports raise no alerts.

9.5 Conditional Access Weaknesses

If device-binding or token protection is not enforced, forged tokens glide through easily.

10. Indicators That Defenders Can Use

Although Golden SAML is stealthy, several artifacts can reveal it:

10.1 Cloud Logins Without IdP Logs

If Entra sign-in events show SAML federation but AD FS shows no matching authentication, this is nearly definitive evidence of Golden SAML.

10.2 Abnormal Assertion Attributes

Signs include:

• Odd NotBefore and NotOnOrAfter timestamps
• Claims appearing that the IdP never issues
• Sudden role assignment changes for users without corresponding AD activity

10.3 Login Behavior Outside Norms

While red-teams try to mimic patterns, subtle indicators often exist:

• Sign-ins from new device types
• Logins that skip MFA entirely
• Admin operations from user accounts that normally don’t perform them

10.4 Unsanctioned Certificate Export

If defenders monitor DPAPI master key usage, LSASS access attempts, or certificate store enumeration, they can detect early stages of the attack.

11. Breaking the Attack: Defensive Countermeasures

From an operator’s perspective, the following defensive controls pose the biggest barriers:

11.1 Rotating Token-Signing Certificates

This instantly kills an attacker’s stolen key.

11.2 Enabling Token Protection / Device Binding

This invalidates forged tokens because they do not have the proper device attestations.

11.3 Replacing AD FS with Cloud-Native Authentication

Passwordless or cloud-native auth flows eliminate Golden SAML entirely.

11.4 Hardening AD FS Servers

Operators struggle when:

• IdP servers are isolated in privileged access workstations (PAW) tiers
• Certificates require HSM-based signing
• LSASS is protected
• Local admin rights are tightly controlled

11.5 Monitoring SAML Token Anomalies in the Cloud

Behavior-based analytics often catch forged sessions before the operator expects.

Conclusion

Golden SAML is not a vulnerability in SAML, AD FS, or cloud identity platforms—it is an exploitation of trust. The entire technique hinges on the fact that cloud providers do not validate the origin of assertions, only the signature. That design choice makes the IdP’s private signing key one of the most sensitive assets in any hybrid environment.

From the red-team viewpoint, Golden SAML is a surgical way to bypass MFA, impersonate privileged accounts, and obtain persistent cloud access with minimal reliance on noisy techniques. It provides a level of control rivaling Golden Tickets in on-prem AD but with broader reach due to cloud adoption.

For defenders, the path to mitigation is clear: rotate signing certificates, harden AD FS, enforce token-binding, restrict privileged logins, and monitor cloud sign-ins for mismatches between the IdP and the cloud provider. Understanding the attacker’s workflow is the first step toward closing the door on this powerful identity-forging technique.