Golden SAML and Federation Trust Abuse Defence Guide: Protecting Token-Signing Keys and Trusts

Anyone who holds a federation server's token-signing private key, or who can register a federation trust of their own, can mint a valid sign-in for any user without a password or an MFA prompt. That is Golden SAML, catalogued by MITRE ATT&CK as T1606.002 Forge Web Credentials: SAML Tokens, and its close relative is the federated domain backdoor (T1484.002 Trust Modification). This guide covers both for Active Directory Federation Services (AD FS) and Microsoft Entra ID federated domains: how the key is protected, where it leaks, what to log, how to harden, and how to recover. It is written for identity engineers, AD FS owners and detection teams. It is strictly defensive and contains no attack tooling or procedures. For trust relationships in general, see the Federation and Trust Relationships Guide.

Key takeaways

• The signing key is the identity provider. A relying party that trusts a certificate trusts every token signed by it, so the private key deserves the same protection as a domain controller or a root CA.
• The key lives in more places than the server. AD FS protects its auto-generated signing keys with material in the Distributed Key Manager (DKM) container in Active Directory, and backups can carry the keys too; CVE-2026-56155 showed what a loose DKM ACL means.
• Forged tokens leave a gap, not a trace. A forged token is never issued by AD FS, so the strongest detection is a cloud sign-in with no matching AD FS issuance event.
• Trust changes are as dangerous as key theft. A new federated domain or an added signing certificate gives the same outcome with no key theft at all; alert on every change.
• The durable fix is fewer federation servers. Moving Microsoft 365 and other apps to cloud authentication removes the on-premises signing key from the attack path entirely.

How the attack works

In SAML and WS-Federation, the identity provider (IdP) signs an assertion that names the user and their claims. The service provider checks the signature against the certificate it has on file for that IdP and, if it verifies, signs the user in. It cannot tell a token the IdP produced from one produced by anyone else holding the same private key. ATT&CK notes that an adversary with a valid token-signing certificate can forge tokens "with any permissions claims and lifetimes", and that the default SAML token lifetime of one hour is set by the NotOnOrAfter condition inside the token, which the forger controls.

There are two routes to the same result, and both need high privilege first:

1. Key theft (T1606.002 with T1552.004 Private Keys): the adversary obtains the token-signing private key from the AD FS server, from the material that decrypts it in Active Directory, from an exported certificate or from a backup.
2. Trust modification (T1484.002): with enough cloud rights, the adversary adds their own federated domain, converts a managed domain to federated, or adds a second signing certificate to an existing trust. ATT&CK describes this alternative: establishing a new federation trust with an AD FS server the adversary controls.

Either way, the forged token can claim to be a highly privileged account, and because the relying party believes the IdP already handled authentication, MFA and password changes do not help. Resetting the impersonated user's password does nothing.

Where it shows up

• AD FS farms federated with Entra ID: still common in organisations that adopted Office 365 early. Microsoft's own description of the SolarWinds intrusions was that attackers used admin permissions "to gain access to an organization's trusted SAML token-signing certificate". See the SolarWinds Golden SAML breach analysis.
• The DKM container: AD FS stores the symmetric keys that protect its token-signing and token-encryption private keys under Program Data, Microsoft, ADFS in Active Directory. Microsoft's KB5121391 for CVE-2026-56155 explains that an overly permissive ACL lets anyone who can read that key material decrypt the signing keys. CISA added CVE-2026-56155 to the Known Exploited Vulnerabilities catalog on 14 July 2026.
• Backups and migrations: the AD FS Rapid Restore tool backs up "token signing and decrypting certificates and keys from the DKM container" along with exported certificates and private keys. Any share, storage account or tape holding those backups is a copy of the IdP.
• Entra tenants with cloud admin compromise: Storm-0501 created a new federated domain in a victim tenant, and Microsoft said the resulting tokens "can be used to impersonate any user in the organization and bypass MFA". See the Storm-0501 hybrid cloud attack analysis.
• Other SAML IdPs and SaaS: the technique is protocol-level, so any IdP whose signing key or admin console is exposed has the same problem. See the SAML Security Guide.

Impact

• Tenant-wide impersonation: the forger chooses the user, including Global Administrators in federated domains, so the blast radius is every application that trusts the IdP.
• Persistence that survives resets: password resets, MFA re-registration and even disabling a single account do not invalidate the key. Only rotating the certificate, removing the rogue trust or decommissioning federation does.
• A springboard to non-human identities: in the SolarWinds intrusions, forged access was followed by adding credentials to existing application service principals (T1098.001 Additional Cloud Credentials), so mail could then be read as a trusted app. Those app credentials outlive the key rotation unless they are found. See the Azure RBAC and Service Principals Guide.
• Weak forensic signal: forged tokens do not pass through the AD FS server, so its logs show nothing for the forged sessions.

Detection

Detection works on three layers: the key store, the trust configuration and the sign-ins themselves. Defender for Identity documents the AD FS events it needs: 1202 (the Federation Service validated a new credential), 1203 (failed to validate a new credential), 4624 and 4625, with AD FS auditing set by Set-AdfsProperties -AuditLevel Verbose and the Group Policy setting Object Access, Audit Application Generated (Success and Failure).

The correlation rule in row five is the most important and the hardest to build: forward AD FS logs to the SIEM, normalise user principal names and allow for clock skew. Microsoft's AD FS hardening page asks for the highest logging level and correlation with AD and Entra events. Defender for Identity sensors run on federation servers, not on Web Application Proxy servers, and need read access to the AdfsConfiguration database. See the Entra ID Sign-In and Audit Log Detection Guide and the ITDR Guide.

Prevention and hardening

Protect the key

• HSM-backed signing keys: Microsoft recommends protecting AD FS signing and encryption keys in a hardware security module and installing the farm with HSM-backed certificates (the Install-AdfsFarm -SigningCertificateThumbprint and -DecryptionCertificateThumbprint parameters). A non-exportable key cannot be copied off the box. See the HSM Deployment and Operations Guide.
• Lock the DKM ACL: install the update for CVE-2026-56155 on every farm server. From 13 October 2026 automatic remediation is the default, restricting the container to Domain Admins, Enterprise Admins, SYSTEM and the AD FS service account. Do not set RemediateDkmAcl to 0 unless a tested dependency forces it, and save the previous SDDL from event 510 after event 1135.
• Service account: run AD FS as a group managed service account, as Microsoft recommends. See the gMSA Guide.
• Backups as tier 0: store AD FS backups, exported PFX files and HSM backup blobs with the same access controls as the server, and inventory where they are.

Isolate the server

• Tier 0 administration: Microsoft limits admin rights on AD FS to AD and AD FS administrators, using admin workstations. Put AD FS computer objects in their own top-level OU with GPOs that apply only to them, and restrict management agents. See the Tiered Administration and Enterprise Access Model Guide and the Privileged Access Workstations Guide.
• Proxy surface: keep AD FS behind Web Application Proxy, disable the intranet-only WS-Trust windowstransport endpoints on the proxy, and use revoke proxy trust if a WAP server is suspect.

Protect the trust in Entra ID

• Reject federated MFA claims: set federatedIdpMfaBehavior to rejectMfaByFederatedIdp so Entra performs its own MFA. This does not stop a forged token for a user, but it removes the "MFA already done" claim from what the forger can assert.
• Few domain and federation administrators: keep Global Administrator and Hybrid Identity Administrator assignments small, eligible through PIM and protected by phishing-resistant MFA.
• Change alerting: the two audit activities above, plus domain additions, routed to an on-call queue, not a weekly report.

Remove the dependency

Staged migration of applications from AD FS to Entra ID follows Microsoft's four stages (current state, optional test tenant, test instance against production, production cutover), with modern-protocol apps first. Once Microsoft 365 uses password hash synchronisation or pass-through authentication, the on-premises signing key no longer signs cloud sign-ins. Keep the domain federated only where a documented requirement remains.

Response and recovery

1. Scope: list federated domains and their signing certificate thumbprints in Entra and compare with Get-AdfsCertificate -CertificateType token-signing. Any certificate or domain you cannot account for is a finding.
2. Remove rogue trusts first, then rotate. Microsoft's emergency procedure rotates the token-signing certificate twice because Entra keeps information about the previous certificate; a single rotation can leave the old key able to sign in users. With AutoCertificateRollover enabled this uses Update-ADFSCertificate -CertificateType Token-Signing -Urgent followed by a second update; Entra is then updated with Update-MgDomainFederationConfiguration.
3. Expect an outage: emergency rotation skips the partner grace period. Partners that do not read federation metadata need the new public certificate sent manually.
4. Replace SSL certificates on AD FS and WAP if the server was compromised, then revoke refresh tokens for affected users.
5. Hunt for follow-on persistence: new credentials on apps and service principals, new role assignments, mailbox permissions. See the Identity Incident Response Playbook.

Lessons from incidents

• Key theft follows admin compromise: in the SolarWinds Golden SAML breach, the forging came after on-premises admin access; tier 0 isolation of the AD FS server is a prevention control, not just hygiene.
• Cloud admin equals federation control: the Storm-0501 attack needed no on-premises key at all, only enough Entra rights to add a domain.
• Rotation alone is not recovery: organisations that rotated once, or rotated but left new app credentials in place, kept the adversary in.

Framework mapping

Practitioner checklist

• Record every federated domain, its IdP and its signing certificate thumbprints, and reconcile monthly.
• Install the CVE-2026-56155 update on all AD FS servers and confirm event 1133 or 1135, not 1136 or 1137.
• Place a SACL on the ADFS container and alert on event 4662 reads by anything other than the AD FS service account.
• Move token-signing and token-decryption keys into an HSM, or plan decommissioning if that is not practical.
• Treat AD FS servers, backups, exported certificates and admin workstations as tier 0.
• Alert in real time on "Set federation settings on domain", "Set domain authentication" and domain additions.
• Build the correlation of federated Entra sign-ins against AD FS events 1202 and 4624, and test it.
• Set federatedIdpMfaBehavior to rejectMfaByFederatedIdp on federated domains.
• Rehearse the double rotation, partner notification and refresh token revocation before you need them.
• Set a dated plan to move Microsoft 365 and other relying parties to cloud authentication.

Standards and references

• MITRE ATT&CK: Forge Web Credentials: SAML Tokens (T1606.002)
• MITRE ATT&CK: Domain or Tenant Policy Modification: Trust Modification (T1484.002)
• Microsoft Learn: Best practices for securing AD FS and Web Application Proxy
• Microsoft Support: KB5121391 CVE-2026-56155 AD FS DKM container ACL hardening
• Microsoft Learn: Emergency rotation of the AD FS certificates
• Microsoft Learn: Monitor changes to federation configuration in Microsoft Entra ID
• Microsoft Learn: Configure Windows event collection for Defender for Identity
• Microsoft Learn: Stages of migrating application authentication from AD FS to Microsoft Entra ID

Related NHI Mgmt Group resources: Federation and Trust Relationships Guide · SAML Security Guide · Storm-0558 and Cloud Key Theft Profile · Microsoft Entra Connect and Cloud Sync Hardening Guide · Active Directory and Entra ID Hardening Guide