Golden SAML is to federated identity infrastructure what Golden Ticket is to Kerberos: an attacker who obtains the token signing private key for an Active Directory Federation Services (ADFS) deployment can forge SAML assertions for any service provider configured to trust that identity provider, for any user, with any attribute claim, with no dependency on Active Directory — and with no expiry constraint derived from AD account state. MFA doesn’t protect against it. Account disablement in Active Directory doesn’t revoke it. Password resets have no effect.

The technique was first documented in 2017 by CyberArk and appeared in the wild in the 2020 SolarWinds compromise, where APT29 (NOBELIUM/Cozy Bear) used it to access Microsoft 365 environments belonging to compromised organisations. It has since appeared in investigations across financial services, government, and critical infrastructure targeting by multiple threat actors. It is underrepresented in most SOC detection stacks.

Understanding the Attack Chain

The Golden SAML technique requires an attacker to have already compromised the ADFS server — either directly through OS-level access or through a credential that allows them to extract the ADFS configuration database.

Step 1: Token signing certificate extraction

ADFS stores its token signing certificate in the Windows certificate store on the ADFS server, typically with the private key marked as non-exportable. The actual certificate and private key are also stored in the ADFS configuration database (stored in a SQL Server instance or Windows Internal Database). An attacker with ADFS server administrative access can extract the token signing private key using ADFSDump, the ADModule, or direct database queries.

The relevant event at extraction time (if ADFS verbose logging is enabled):

  • Event ID 403: ADFS certificate configuration changes
  • Event ID 411: Token signing certificate accessed

Neither fires on simple database reads — only on configuration API interactions — so pure database extraction leaves no ADFS event trail.

Step 2: Offline SAML assertion forgery

With the private key, the attacker can construct a SAML assertion offline using tools such as ADFSpoof or Golden SAML (available in multiple toolkits). The assertion specifies:

  • The subject (any user, identified by UPN or SID claim)
  • The issuer (the legitimate ADFS service URL)
  • Attribute claims (group memberships, roles, MFA completion)
  • Validity window (forged assertions can be set for extended periods)

The assertion is signed with the legitimate token signing key. Service providers that validate the signature against the ADFS signing certificate public key (which is public) accept it as genuine.

Step 3: Service provider authentication

The forged SAML assertion is submitted to the service provider’s SAML endpoint. From the service provider’s perspective, it looks identical to a legitimate ADFS-issued assertion. Microsoft 365 accepts it and issues an OAuth token. AWS accepts it and issues STS credentials. Any SAML SP configured with the compromised IdP’s public certificate is vulnerable.

ADFS Logging: What’s Actually Available

Detection of Golden SAML attacks is constrained by what ADFS logs by default. Standard ADFS audit logging (enabled via Set-AdfsProperties -LogLevel Information) captures:

  • Event ID 299 (Security log): Token issued successfully — includes UPN, client IP, SP identifier, authentication method
  • Event ID 324 (Security log): Token issued with extranet client IP
  • Event ID 500: External authentication provider status

Verbose logging additionally provides:

  • Event ID 1200: Token request detail
  • Event ID 1202: SAML assertion detail (very verbose, not recommended for all environments)

The critical gap: Event ID 299 fires on both legitimate and forged assertions. The token signing operation happens correctly in both cases — the difference is whether the assertion was generated by the ADFS service or by the attacker offline.

Detection Strategy

Because direct detection of the forgery is difficult, effective detection combines three approaches:

1. Impossible access patterns — Forged assertions frequently show impossible client characteristics. An assertion for a user who has never used ADFS before, from an IP outside known authentication IP ranges, accessing a sensitive service directly without prior ADFS activity.

2. Assertion attribute anomalies — Forged assertions often contain attribute claims that ADFS would never issue: MFA completion claims for users who don’t have MFA enrolled, group membership claims not present in AD, custom role claims that indicate attacker-specified privilege.

3. Token signing certificate access and configuration events — Any access to or modification of the ADFS token signing certificate warrants immediate investigation.

Sigma Rules

Rule 1: ADFS Token Issued from Unusual Source IP

title: ADFS Token Issued from Unusual Authentication Source
id: 7f8e2a1b-3c4d-5e6f-7a8b-9c0d1e2f3a4b
status: experimental
description: >
  Detects ADFS token issuance from IP addresses outside established authentication
  baselines. Golden SAML forged assertions are often submitted from attacker
  infrastructure not matching historical ADFS client IP ranges.
references:
  - https://adsecurity.org/?p=1879
  - https://o365blog.com/post/adfs/
author: SOC Analyst Hub
date: 2026-08-03
tags:
  - attack.credential_access
  - attack.t1606.002
  - attack.defense_evasion
logsource:
  product: windows
  service: security
  definition: ADFS audit logging must be enabled (Audit Object Access)
detection:
  selection:
    EventID: 299
    Keywords|contains: 'TokenIssuance'
  filter_known_networks:
    # Populate with your known ADFS client IP ranges
    IpAddress|cidr:
      - '10.0.0.0/8'
      - '192.168.0.0/16'
      - '172.16.0.0/12'
  condition: selection and not filter_known_networks
falsepositives:
  - Legitimate remote access from corporate VPN IPs not captured in filter
  - New office locations or partner network additions
level: high

Rule 2: ADFS Token Issued with MFA Claim for Non-MFA User

title: ADFS SAML Assertion Contains MFA Claim Inconsistent with User Enrollment
id: 8a9b0c1d-2e3f-4a5b-6c7d-8e9f0a1b2c3d
status: experimental
description: >
  Detects ADFS token issuance containing MFA completion claims for accounts
  not enrolled in MFA. Forged SAML assertions can include attribute claims
  that ADFS would never legitimately issue for the subject account.
references:
  - https://github.com/secureworks/whiskeysamlandfriends
author: SOC Analyst Hub
date: 2026-08-03
tags:
  - attack.credential_access
  - attack.t1606.002
logsource:
  product: microsoft-365
  service: unified-audit-log
detection:
  selection:
    Operation: 'UserLoggedIn'
    AuthenticationMethod|contains: 'MultiFactor'
  filter_mfa_enrolled:
    # Cross-reference against your MFA enrollment list
    # Implement via watchlist or lookup in your SIEM
    UserMFAEnrolled: 'true'
  condition: selection and not filter_mfa_enrolled
falsepositives:
  - Users with conditional MFA (exempted then newly enrolled)
  - Enrollment state synchronisation lag in SIEM watchlist
level: critical

Rule 3: ADFS Token Signing Certificate Private Key Access

title: ADFS Token Signing Certificate Private Key Access
id: 1b2c3d4e-5f6a-7b8c-9d0e-1f2a3b4c5d6e
status: stable
description: >
  Detects process access to the ADFS token signing certificate private key
  container in the Windows certificate store. Legitimate ADFS service access
  occurs under the ADFS service account; other process access warrants investigation.
references:
  - https://github.com/fox-it/adfs-tools
  - https://github.com/fireeye/ADFSDump
author: SOC Analyst Hub
date: 2026-08-03
tags:
  - attack.credential_access
  - attack.t1552
  - attack.t1606.002
logsource:
  product: windows
  category: object_access
detection:
  selection:
    EventID: 4663
    ObjectName|contains:
      - 'Microsoft\SystemCertificates\My'
      - 'ADFSSigningCertificate'
    AccessMask|contains: '0x1'  # READ_DATA
  filter_adfs_service:
    ProcessName|contains:
      - 'microsoft.identityserver'
      - 'adfsservice'
  condition: selection and not filter_adfs_service
falsepositives:
  - Certificate management tools accessing the ADFS server
  - Backup agents accessing the certificate store
level: high

Rule 4: ADFSDump or ADFSpoof Tool Execution

title: Golden SAML Tooling Execution Detected on ADFS Server
id: 2c3d4e5f-6a7b-8c9d-0e1f-2a3b4c5d6e7f
status: stable
description: >
  Detects execution patterns associated with known Golden SAML attack tools
  including ADFSDump, ADFSpoof, and the WhiskeySAML framework.
author: SOC Analyst Hub
date: 2026-08-03
tags:
  - attack.credential_access
  - attack.t1606.002
logsource:
  product: windows
  category: process_creation
detection:
  selection_tools:
    CommandLine|contains:
      - 'ADFSDump'
      - 'ADFSpoof'
      - 'WhiskeySAML'
      - 'Get-ADFSConfiguration'
      - 'Export-AADIntADFSCertificates'
  selection_suspicious_adfs_db:
    CommandLine|contains:
      - 'AdfsConfiguration'
      - 'IdentityServerPolicy'
    CommandLine|contains:
      - 'sqlcmd'
      - 'Invoke-SqlCmd'
  condition: selection_tools or selection_suspicious_adfs_db
falsepositives:
  - ADFS administration scripts run by infrastructure team
  - Penetration testing activity on the ADFS server
level: critical

KQL for Microsoft Sentinel

Hunt: ADFS Authentications Outside Normal Patterns

// Golden SAML detection: ADFS authentications with anomalous characteristics
// Requires AADSignInLogs and ADFSSignInLogs tables
let known_adfs_ips = dynamic(["10.0.0.0/8", "192.168.0.0/16"]);
let mfa_enrolled_users = 
    AADUserRiskEvents
    | where AuthenticationDetail contains "MFA"
    | summarize make_set(UserPrincipalName);
ADFSSignInLogs
| where TimeGenerated > ago(7d)
| extend IsKnownIP = ipv4_is_private(IPAddress) or 
    ipv4_is_in_range(IPAddress, "10.0.0.0/8") or
    ipv4_is_in_range(IPAddress, "172.16.0.0/12")
| where not(IsKnownIP)
| extend MFAClaimed = AuthenticationProtocol contains "mfa" or 
    AdditionalDetails contains "MFA"
| join kind=leftouter (
    mfa_enrolled_users
    | mv-expand EnrolledUPN = set_UserPrincipalName to typeof(string)
    | project EnrolledUPN
) on $left.UserPrincipalName == $right.EnrolledUPN
| where MFAClaimed and isnull(EnrolledUPN)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, 
    AuthenticationProtocol, AdditionalDetails, ResourceDisplayName
| order by TimeGenerated desc

Hunt: ADFS Token Signing Certificate Access on ADFS Server

// Detect access to ADFS certificate store by unexpected processes
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4663
| where ObjectName has_any ("ADFSSigningCertificate", "Microsoft\\SystemCertificates\\My")
| where AccessMask == "0x1"
| where not(ProcessName has_any ("microsoft.identityserver", "adfsservice", "mmc.exe"))
| extend AccountName = tostring(split(Account, "\\")[1])
| project TimeGenerated, Computer, AccountName, ProcessName, ObjectName, AccessMask
| order by TimeGenerated desc

Hunt: Service Provider Access Without Prior ADFS Authentication

// Detect M365/Azure access via SAML without matching ADFS session in prior window
// Golden SAML forgeries submitted directly bypass the ADFS session log
let lookback_window = 30m;
let saml_authentications = 
    AADSignInLogs
    | where TimeGenerated > ago(7d)
    | where AuthenticationProtocol == "SAML20"
    | where AppDisplayName in ("Microsoft 365", "Azure Portal", "AWS Console")
    | project SamlTime = TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName;
let adfs_sessions = 
    ADFSSignInLogs
    | where TimeGenerated > ago(7d)
    | project AdfsTime = TimeGenerated, UserPrincipalName, IPAddress;
saml_authentications
| join kind=leftouter (
    adfs_sessions
) on UserPrincipalName
| where isnull(AdfsTime) or 
    (SamlTime - AdfsTime > lookback_window) or 
    (IPAddress != IPAddress1)
| summarize count() by UserPrincipalName, AppDisplayName, IPAddress, bin(SamlTime, 1h)
| where count_ == 1  // One-off anomalous access, not systematic use
| order by SamlTime desc

Response Playbook

When a Golden SAML indicator fires:

  1. Isolate the ADFS server: Any server where the signing certificate was potentially extracted should be treated as compromised. Isolate from the network immediately.

  2. Rotate the token signing certificate: In the ADFS Management Console, add a new token signing certificate, set it as primary, wait for federation metadata propagation, then remove the old certificate. This revokes all outstanding forged assertions — they will fail signature validation once the old public key is removed from the ADFS metadata endpoint.

  3. Enumerate affected service providers: Review the ADFS relying party trust list. Every federated SP is affected by a signing certificate compromise. Audit each SP’s sign-in logs for assertions matching the attacker’s suspected UPN targets or IP addresses.

  4. Review ADFS audit logs for the extraction window: If verbose ADFS logging was enabled, attempt to correlate any unusual database access or certificate store access with the attacker’s known presence timeline.

  5. Force re-authentication across all federated services: Cookie-based sessions at federated SPs may remain valid even after certificate rotation. Force logout at each SP using available admin capabilities (M365: Revoke-MgUserSignInSession, AWS: IAM temporary credential expiry).

Detection Coverage Gaps

Golden SAML is genuinely difficult to detect with high fidelity because the forged assertion is cryptographically valid. The detection opportunities in this guide catch supporting behaviours — anomalous source IPs, unexpected MFA claims, certificate extraction tooling. They do not catch a well-executed forgery from a known IP with correctly attributed claims.

The most reliable detection is prevention: monitor ADFS server access tightly, alert on any unexpected privileged access to the ADFS configuration database, and treat the ADFS signing certificate like a Kerberos KDC key — compromise of either results in complete trust collapse for the respective authentication domain.