Detecting Golden SAML and Federation Token Forgery

In a Golden SAML attack, an adversary with administrative access to AD FS steals the token-signing certificate and its private key, then mints SAML assertions for any user, including ones that bypass MFA. The cloud tenant sees a validly signed token and issues access. The forged sign-in has no matching issuance on AD FS, and that gap, along with the key theft that precedes it, is where you detect it.

Signals at a Glance

Detecting Key Theft

The attacker needs the token-signing private key, which AD FS protects with the distributed key manager (DKM) key stored in Active Directory. Tools that extract it read the DKM container or query the Windows Internal Database over a named pipe. Alert on the latter first, since it is easy to baseline:

title: AD FS Database Named Pipe Connection From Unexpected Process
logsource:
  product: windows
  category: pipe_created
detection:
  selection:
    PipeName: '\MICROSOFT##WID\tsql\query'
  filter_adfs:
    Image|endswith: '\Microsoft.IdentityServer.ServiceHost.exe'
  condition: selection and not filter_adfs
level: high
# tune/validate: confirm the pipe event source in your Sysmon config (17/18) and allowlist backup or monitoring agents

• Enable auditing on the AD FS DKM container in Active Directory and alert on reads by any account other than the AD FS service account.
• Monitor AD FS servers like domain controllers: treat PowerShell, certutil and certificate export activity there as high severity.
• Prefer a hardware security module for the token-signing key so the private key cannot be exported.

Finding Sign-ins With No Issuance

A forged assertion never passes through AD FS, so it produces a cloud sign-in with no corresponding token issuance event on the federation servers. Correlate the two logs for federated users:

// Microsoft Sentinel (KQL) - federated sign-ins without a nearby AD FS issuance event
// validate: AD FS audit field layout varies by version; adjust the extract() pattern to your events
let adfs = SecurityEvent
    | where TimeGenerated > ago(1d)
    | where EventSourceName == "AD FS Auditing" and EventID in (1200, 1202)
    | extend AdfsUser = tolower(extract(@"<UserId>([^<]+)</UserId>", 1, tostring(EventData)))
    | where isnotempty(AdfsUser)
    | project AdfsTime = TimeGenerated, AdfsUser;
SigninLogs
| where TimeGenerated > ago(1d) and ResultType == 0
| where UserPrincipalName endswith "@contoso.com"   // replace with your federated domain(s)
| extend AdfsUser = tolower(UserPrincipalName)
| join kind=leftouter adfs on AdfsUser
| where isempty(AdfsTime) or abs(datetime_diff('minute', TimeGenerated, AdfsTime)) > 10
| summarize Unmatched = count(), IPs = make_set(IPAddress, 5) by UserPrincipalName
| order by Unmatched desc

• Expect gaps from seamless SSO, pass-through paths and ingestion delay; build the match window from your own data before alerting.
• Watch AD FS Admin events for configuration changes and the addition of new token-signing or relying-party objects, then confirm each against a change record.