Welcome to the third in our series of articles on dealing with advanced identity-related attacks. This time, we’ll discuss Golden Security Assertion Markup Language (SAML) attacks.

Password attacks (e.g., password spray, breach replay, and phishing) are responsible for compromising millions of accounts each month. Every second, Microsoft detects and blocks more than 7,000 password attacks. In contrast, Golden SAML attacks are rare. At the time of this writing, the customer-facing cybersecurity response teams at Microsoft have reported 20 Golden SAML attacks on fewer than ten unique customers over the last 24 months. Detections managed by our Identity Security data science team identify around 50 affected users worldwide per month at the time of this writing.

While Golden SAML attacks are less frequent than other attacks, their impact can be huge. Whereas an Adversary in the Middle (AiTM) phishing attack only affects the account that got phished, a successful Golden SAML attack can compromise every account in your organization.

In this blog, we’ll explain how Golden SAML attacks work and what you can do to protect against them, with a particular focus on how they can impact Microsoft Entra deployments.

SAML authentication

First, let’s review the mechanics of SAML 2.0. SAML is an acronym for Security Assertion Markup Language, an Internet standard published in 2005 that supports delegation of authentication authority from one system to another.

The most common use of SAML is for application single sign-on (SSO) in which an application that supports SAML delegates authentication authority to a SAML-enabled identity service, such as Microsoft Entra ID. In SAML terminology, the application is a relying party (RP[i]), and Entra ID is an identity provider (IdP). Because multiple RPs can trust a single IdP, a user can sign into the IdP just once and access multiple applications (or RPs). This is why, for example, a user can sign in to Windows, then get access to SharePoint, Teams, and Exchange without having to sign in again.

The diagram below, which is an expanded version of the diagram from the first blog in this series, illustrates this SAML authentication flow. When the user agent requests content, the RP redirects the user agent to the IdP, which responds by requesting proof of identity. Once the user agent provides their credentials, the IdP returns a token that the user agent presents to the RP to gain access. 

Figure 1: Typical SAML authentication flow

 

To reuse the county fair analogy from the previous blogs in this series, the user agent is like a fairgoer purchasing a ticket to go on a ride at a county fair, the IdP is like a ticket office selling tickets to the fair rides, and the RP is like the ride operator who examines and accepts the ticket from the fairgoer before letting them on the ride.

Public Key Cryptography and magic holograms

As we’ve described previously, these systems work because the ride operator (RP) trusts that the ticket (SAML token) is authentic and came from the ticket office.

In the county fair example, imagine the ride operators know the tickets are authentic because the office imprints them with a magic hologram. The ticket office has published the characteristics of the magic hologram, so that the ride operators know how to recognize an authentic hologram and thus an authentic ticket.

The hologram description must be broadly available, so ride operators can use it to discern a valid ticket hologram, and the ticket office must closely guard the hologram stamping machine to prevent the creation of fraudulent tickets.

Identity and many other digital systems perform this function of guaranteeing authenticity through Public Key Cryptography (PKC). The private key allows entities like the ticket office to sign statements, such as the tickets, which is akin to stamping them with the magic hologram. This is called ‘signing.’ The public key allows any consumer of these statements to validate that it came from the private key holder.

As with our county fair analogy, the public key must be broadly available to allow verification of signatures, and the private key must be closely guarded to prevent the creation of fraudulent signatures. As long as the private key remains safe, PKC is a great mechanism.

However, if a nefarious actor gets hold of the machine used to stamp the magic hologram on tickets (the private key), they can then forge tickets that will perfectly match the description provided to the ride operators. This is far worse than simply stealing a ticket from one fairgoer (token theft) or tricking a fairgoer into purchasing a ticket for them (AiTM phishing) because in this case, the actor can forge tickets for anyone whenever they like, and the ride operators can’t tell the difference.

Stealing a federation server’s private key to forge correctly signed tokens to access its relying parties is the essence of the Golden SAML attack.

The implications of Golden SAML for SAML Chaining

SAML is all about delegation, and delegations can be chained. Using SAML chaining, organizations configure cloud applications as RPs to their cloud IdP, then configure their cloud IdP as an RP to their on-premises directory infrastructure. Because on-premises infrastructure commonly uses older protocols like Kerberos, federation servers like Active Directory Federated Services (AD FS) are used to provide a SAML interface into this legacy infrastructure.  

For example, an app can delegate authentication to a cloud IdP such as Microsoft Entra, which can in turn delegate authentication to an on premises IdP such as AD FS. In this scenario, an attack on the lowest-level IdP (i.e., AD FS) compromises the entire chain of trust, even if the keys used to prove authenticity from the Cloud IdP to the cloud applications are not compromised.

SAML chaining is a very common scenario for Microsoft Entra customers. Here’s why customers frequently want this configuration:

SSO systems have existed for a long time; notably, most organizations deployed SSO in their on-premises environments before cloud IdPs were broadly available. Such systems were often built on Active Directory and the Kerberos protocol. Even for organizations trying to go to a pure cloud identity deployment, these on-premises deployments were (and remain) both mission critical and complex, so decommissioning them in favor of cloud IdPs can be a delicate, years-long operation.  

As a result, many organizations using cloud IdPs for application SSO maintain on premises identity infrastructure for Kerberos, NTLM, and other applications (or to meet other regulatory or security objectives). Their admins have had to maintain identity repositories both on-premises and in the cloud, and users have had to sign in separately for on-premises authenticated resources vs. cloud authenticated resources.

Delegation of authentication using SAML helped mitigate this complexity. Organizations could use SAML chaining to configure cloud IdPs like Entra ID to delegate authentication to on-premises directories like Active Directory, so that users, once signed in on-premises, could access both legacy resources like SMB file shares and SaaS apps such as Exchange Online.

When a cloud application redirects a user agent to the cloud IdP for authentication, the cloud IdP uses SAML to redirect authentication to the federation server, which then “translates” the request for a token from the cloud IdP (e.g., Entra ID) to the on-premises environment (e.g., Active Directory) and returns the result via the user agent to the cloud IdP in the form of a SAML token.[ii] While we don’t recommend this approach, and many organizations are moving away from it, it’s still a common deployment pattern.

Delegated authority at the county fair

Let’s revisit our county fair analogy. Imagine the fair is in the midst of adding the best new rides. These rides require fancy biometric wristbands, so the fair will upgrade from paper tickets to wristbands. Like most major infrastructure upgrades, the fair will implement this change in stages.

For now, customers will go to the familiar paper ticket office where, in exchange for payment, they’ll receive paper tickets to use on the old rides, along with a wristband voucher that they’ll exchange at a new wristband booth for a wristband they can use on upgraded rides. The voucher contains the paper ticket information formatted such that the wristband booth can validate and understand it.

Ultimately, the park will decommission its old paper ticket system as they convert old rides to the new wristband standard and move their point-of-sale systems from the paper ticket office to the new wristband booth. But until then, instead of accepting credit cards, the wristband booth will only accept vouchers from the old paper ticket office and exchange them for wristbands.

When a fairgoer walks up to an upgraded ride, the ride operator tells them they need a wristband to get on the ride and points them to the wristband booth. The fairgoer then goes to the wristband booth, which asks them for their wristband voucher. When the fairgoer says, “I don’t have a voucher,” the wristband booth points them to the main ticket office to get one. The fairgoer purchases a paper ticket, receives a voucher, returns to the wristband booth, presents their voucher to receive a wristband, then shows the wristband to the ride operator and has a great time on the ride.

In this analogy, the fairgoer represents the user agent (browser or app), the ride is the application, the paper ticket is the Kerberos ticket issued by the on-premises IdP, the voucher is the SAML token issued by federation server, and the wristband is the token issued by the cloud IdP. The federation server performs the task of converting the paper ticket to the voucher. Think of the federation server as a ticket office attendant, a temporary worker whose only job is to validate paper tickets and trade them for wristband vouchers.

This may sound cumbersome, but in an SSO system, the redirection from the app (fair ride) to the cloud IdP (the wristband booth) to the federation server (the ticket office attendant) to the on-premises directory (the paper ticket office point-of-sale) to the exchange of the SAML token (the wristband voucher) for the cloud IdP token (the wristband) is nearly invisible to the user. It’s as though when the fairgoer presents their paper ticket to the ride operator, the wristband magically materializes on their wrist so they can get on the ride.

The diagram below illustrates the authentication flow when SAML chaining is involved.

 

Figure two: Typical Hybrid Identity deployment with SAML Chaining.

How Golden SAML unfolds in hybrid identity deployments

In a Golden SAML attack, a bad actor gains control of the private key that a federation server uses to sign SAML tokens. This can happen through a variety of techniques but usually requires administrative control of the federation server.

Having stolen the private key, the attacker then forges tokens representing any users and claims they wish and presents them to the RP. The signature will validate correctly with the public key, so the RP will be unable to distinguish a forged token from a genuine one. Thus, a successful attack allows the bad actor to impersonate any identity within the scope of trust delegated to the IdP and is very challenging for the RP to detect, because it mimics real users and generates authentic-looking requests.

Figure three: Flow of a Golden SAML attack.

 

CyberArk coined the term Golden SAML in November 2017 to describe this attack. The name is derived from the Kerberos Golden Ticket attack, which Benjamin Delpy, author of Mimikatz, described at Black Hat USA 2014. In Kerberos Golden Ticket attacks, an attacker gains the ability to forge Kerberos tokens via the Kerberos Ticket Granting Ticket, giving them broad and persistent access to resources in an Active Directory domain.

CyberArk cautioned that if an attacker could compromise a SAML server’s private signing key, they could use a similar technique to “gain access to any application that supports SAML authentication (e.g., Azure, AWS, vSphere, etc.) with any privileges they desire and be any user on the targeted application.”[iii] CyberArk correctly pointed out that since SAML 2.0 had effectively replaced Kerberos as the key SSO protocol in the world of the cloud, this technique would give successful attackers access to an even broader set of resources than compromising a domain controller.

CyberArk noted that Golden SAML is not an exploit of a vulnerability:

“This attack doesn’t rely on a vulnerability in SAML 2.0. It’s not a vulnerability in AWS/ADFS, nor in any other service or identity provider. Golden ticket is not treated as a vulnerability because an attacker has to have domain admin access in order to perform it… Golden SAML is rather similar. It’s not a vulnerability per se, but it gives attackers the ability to gain unauthorized access to any service in a federation (assuming it uses SAML, of course) with any privileges and to stay persistent in this environment in a stealthy manner.”[iv]

Golden SAML is an attack technique that requires admin-level compromise of the key hosting system. An attacker that has the level of access required to launch a Golden SAML attack can probably already access any resources they want, but the Golden SAML technique greatly reduces the chances of detection.

The remainder of this article will cover what you can do to guard against these attacks and how to respond to them. While the ideas apply to any on-premises SAML IdP deployment, the recommendations below assume you’re using AD FS.

Embrace cloud identity to mitigate Golden SAML attacks

Note: All of the following mitigations are for customers deploying their own on premises SAML IdPs. To understand what Microsoft is doing to prevent this attack against our own infrastructure, see aka.ms/securefutureinitiative.

Just as the best countermeasure for token theft attacks is token binding and for AiTM phishing attacks is passkeys, the most effective countermeasure for Golden SAML attacks against your on-premises federation servers is to avoid maintaining federation servers that require you to manage your own SAML signing certificates at all.[v]

Since Identiverse 2018, we’ve been making the case—with statistical evidence—that cloud-based identity systems are safer than on-premises identity systems. The Golden SAML attack against on-premises infrastructure is just one of a host of well-known attack techniques that can impact on-premises identity deployments.

Given the security risks associated with on-premises identity deployments, particularly key management challenges, we’ve been advising customers to move away from federation servers such as AD FS. If there’s no federation server, then there’s no signing key that attackers can steal. Expanded cloud IdP features, such as Microsoft Entra’s support for certificate-based authentication (CBA), remove the last barriers for migrating off of AD FS.

We offer several tools, such as the Microsoft AD FS to Microsoft Entra guide and the AD FS migration tool to help streamline the transition. Find step-by-step instructions for migrating from AD FS to Entra ID in our documentation.

Securing your federation server deployment

If you must have a federation server, then you must harden it to protect your signing keys, minimize the impact of a compromised AD FS key, and be prepared to detect Golden SAML attacks and related activity.

You can find detailed information on best practices for securing AD FS deployments in our documentation.

Protect AD FS signing keys and certificates

To protect installed certificates against theft, your best solution is a hardware security module (HSM) attached to AD FS, which Microsoft has supported since Windows Server 2012 R2. Your HSM vendor will provide guidance on how to create the X509 certificates for signing and encryption.

If for some reason an HSM isn’t available to you, we recommend storing certificates locally on your federation servers. Never store them on a network share, log them, or allow them to escape your secure environment. The keys AD FS uses to sign tokens should never leave the federation servers.

You can find step-by-step instructions on how to install the custom certificates for your HSM in our documentation.

Ensure you’re using the latest Windows Server software

If your on-premises IdP is deployed on Windows Server, then running the latest software with current updates (Windows Server 2025 at the time of this article) is critical because it ensures previous vulnerability disclosures have been addressed and because Windows Server includes feature improvements to support secure on-premises identity deployments.

Examples include enhanced measures to protect against management plane attacks, Kerberos features designed to minimize the use of NTLM, and improved security for confidential attributes and default machine account passwords.

You can find more details on the latest enhancements to Active Directory Domain Services in our documentation.

Protect and isolate the infrastructure that supports key management

In most environments, the federation server is at the heart of granting access to all other resources. Your federation servers and the private keys they rely on are literally the keys to your kingdom, so you must manage them with the strictest possible adherence to Zero Trust principles. This includes strict network, administrative, and role-based isolation, with least standing privilege, approved just-in-time elevation, and zero tolerance for detected risk.

For example, these servers should be managed on their own micro-segment with access limited to dedicated passkey-protected administrative accounts, secure access workstations, and protected networks. The accounts accessing the servers should not have standing administrative privileges but rather require the administrator to request elevated access that the system will automatically grant for a short interval based on policy and then revoke.

An excellent way to enforce these access restrictions is to combine Conditional Access with the Global Secure Access compliant network check and Microsoft Entra Privileged Identity Management (PIM).

Protect your cloud environment from your on-premises environment

If you have a hybrid environment, you want to protect and isolate your on-premises infrastructure lest a compromise becomes a conduit into your cloud environment, for example, via federated trust relationships or account synchronization.

You can find detailed instructions for protecting your Microsoft 365 environment from compromised on-premises infrastructure in our documentation.

Be prepared to detect and mitigate Golden SAML attacks

While hardening your federation server will help prevent Golden SAML attacks, you still need a way to detect and mitigate them should they occur. Microsoft offers several tools to help you detect and contain attacks against AD FS deployments.

Be prepared to detect Golden SAML attacks

We built new detections in Microsoft Entra ID Protection and Microsoft Defender for Identity to help admins and SOC personnel detect Golden SAML attacks and related activity. Entra ID Protection detections include Token Issuer Anomaly and Session Token Anomaly.

Learn about Entra ID Protection risk detections in our documentation.

Defender for Identity detects suspicious AD FS DKM key read by looking for anomalous access to the stored key in AD FS. Refined Golden SAML detections are under development.

Learn about Defender for Identity credential access alerts in our documentation.

Implement policies to limit the impact of a compromised AD FS key

The Zero Trust principle of assume breach requires least privilege not just for users, but also for systems. In the case of Golden SAML, we can mitigate a successful attack by restricting the scope of the federation servers.

1. Restrict the scope of the delegation of trust to just the users that need it so that a compromised AD FS key could only impact allowed users for that federation.
2. Restrict the claims allowed from a given federation server so that attackers cannot use forged claims to elevate access.
3. Always require MFA handled by Entra, so that even in the case of a token forgery, a user will need to be present to complete the Entra MFA challenge.

Investigate and contain Golden SAML attacks using Microsoft Defender for Identity

If an alert signals a possible Golden SAML attack, Microsoft Defender for Identity shows you which users and computers are involved and links directly to them so you can understand scope and impact. You can also cross-reference the alert data with other security logs and telemetry, such as logs from AD FS, Entra ID, and other identity providers.

To contain a Golden SAML attack, you can immediately revoke any compromised SAML tokens, reset the credentials of affected accounts and enforce MFA, and rotate AD FS token-signing and token-decryption certificates to invalidate any forged tokens.

Learn how to respond to Defender for Identity alerts in our documentation.

 

If you’ve read this far, you’re almost certainly deploying MFA and Zero Trust principles already. Awesome! Preparing for more sophisticated post-MFA attacks, including Golden SAML, is key to adapting faster than your attackers do. Hardening your federation environment—or better, migrating from federation servers to cloud authentication—will go a long way toward defeating the rare but potentially devastating Golden SAML attack. We hope the techniques in this article will help you on your identity security journey.

 

Nitika Gupta – Partner Group Product Manager

Yaron Paryanty – Principal Group Product Manager

 

 

Learn more about Microsoft Entra

Prevent identity attacks, ensure least privilege access, unify access controls, and improve the experience for users with comprehensive identity and network access solutions across on-premises and clouds.

• ⁠Microsoft Entra News and Insights | Microsoft Security Blog
• ⁠⁠Microsoft Entra blog | Tech Community
• ⁠Microsoft Entra documentation | Microsoft Learn
• Microsoft Entra discussions | Microsoft Community 

 

[i] SAML purists will note this would be a SAML Service Provider, or SP, but we are using the more accessible term RP to be consistent with previous publications.

[ii] Non-Microsoft alternatives to cloud identity providers, on-premises infrastructure, and federation servers, which implement SAML 2.0 and are also vulnerable to Golden SAML attacks exist, but for convenience, this article focuses on Microsoft implementations.

[iii] Golden SAML: Newly Discovered Attack Technique Forges Authentication to Cloud Apps. CyberArk. November 21, 2017.

[iv] Ibid.

[v][v] In 2024, Semperis published their findings on Silver SAML, which emphasized the importance of protecting the private keys used for app SSO in Entra if you choose to configure them yourself. In all cases – if you are managing keys, protecting them is essential to preventing this class of attack.