Back to All Modules

ADFS and SAML Attacks

#Overview

Active Directory Federation Services (ADFS) provides single sign-on (SSO) across organizational and security boundaries using SAML tokens. An attacker who compromises the ADFS infrastructure — specifically the token signing certificate — can forge SAML tokens (Golden SAML) that grant access to any federated application as any user, including cloud services like Office 365 and AWS. Since SAML authentication bypasses password-based and MFA mechanisms, Golden SAML is one of the most powerful persistence techniques in federated environments.

#Prerequisites

  • Access to the ADFS server (local Administrator or DA equivalent)
  • Ability to extract the token signing certificate private key from the ADFS configuration database
  • Knowledge of federated relying party trusts (applications and claims rules)
  • For cloud persistence: understanding of the ImmutableID and how it maps on-premises users to cloud identities

#Detection & Enumeration

#ADFS Endpoint Discovery

# Common ADFS endpoints
# https://<adfs_server>/adfs/ls/IdpInitiatedSignon.aspx  (IdP-initiated sign-on page)
# https://<adfs_server>/adfs/services/trust               (WS-Trust endpoint)
# https://<adfs_server>/FederationMetadata/2007-06/FederationMetadata.xml  (metadata)

# Check DNS for ADFS hostname
nslookup adfs.<domain>
nslookup sts.<domain>

# Port scan for common ADFS ports (443 with specific certificate)
nmap -p 443 --script ssl-cert <target>
# Look for: Subject Alternative Name: DNS:adfs.<domain>

# Check if ADFS is installed via LDAP (service connection point)
# CN=ADFS,CN=Microsoft,CN=Program Data,DC=<domain>,DC=<tld>
BASH

#ADFS Configuration Discovery (on ADFS server)

# PowerShell — ADFS module
Import-Module ADFS
Get-AdfsProperties
Get-AdfsRelyingPartyTrust | Select-Object Name, Enabled, Identifier
Get-AdfsClaimsProviderTrust | Select-Object Name

# Check ADFS version
Get-AdfsProperties | Select-Object ProductVersion, AutoCertificateRollover

# List all relying party trusts and their claims rules
Get-AdfsRelyingPartyTrust | ForEach-Object {
    Write-Host "RP: $($_.Name)"
    Get-AdfsRelyingPartyTrust -Name $_.Name | Select-Object -ExpandProperty IssuanceTransformRules
}
POWERSHELL

#Exploitation / Execution

#Golden SAML Attack

The Golden SAML attack extracts the ADFS token signing certificate (with private key) and uses it to forge SAML tokens for any user to any federated application.

# Step 1: Extract ADFS configuration database
# The signing certificate is stored in the ADFS configuration database
# (Windows Internal Database or SQL Server)

# On ADFS server, locate the DKM (Distributed Key Manager) master key
# The DKM key protects the signing certificate private key

# Step 2: Extract the encrypted PFX using ADFS DKM key
# Tools: ADFSpoof, ADFSDump, or custom PowerShell

# ADFSDump PowerShell (conceptual):
# $dkmKey = Get-ADFSDKMKey
# $encPfx = Get-ADFSEncryptedPfx
# $pfxBytes = Decrypt-ADFSPfx -Encrypted $encPfx -DKMKey $dkmKey

# Step 3: Decrypt the PFX to get signing certificate + private key
# Use the extracted PFX to forge SAML tokens

# Step 4: Forge a SAML assertion for target user
# Include claims: UPN, ImmutableID, objectSID, groups
# Sign the assertion with the extracted signing certificate
# Post the signed SAML assertion to the relying party's ACS endpoint
BASH

#SAML Token Manipulation

# Common SAML claims that can be manipulated (if not properly validated):
# - NameID: the identifier of the authenticated user
# - UPN (User Principal Name): user@domain
# - ImmutableID: the on-premises to cloud identity mapping
# - Groups/Roles: group memberships
# - objectSID: the Active Directory SID

# Tools for SAML manipulation:
# - SAML Raider (Burp Suite extension)
# - SAMLtracer
# - Custom Python/PowerShell scripts using signed XML libraries
BASH

#ImmutableID Manipulation

The ImmutableID is the link between an on-premises AD user and their Azure AD/Office 365 identity. It is typically the Base64-encoded objectGUID.

# Calculate ImmutableID for a user
# Get objectGUID from on-premises AD
Get-ADUser -Identity <target_user> | Select-Object objectGUID
# Output: a1b2c3d4-e5f6-7890-abcd-ef1234567890

# Base64 encode the GUID bytes
$guid = [GUID]"a1b2c3d4-e5f6-7890-abcd-ef1234567890"
$bytes = $guid.ToByteArray()
[Convert]::ToBase64String($bytes)
# This is the ImmutableID

# If you control the ImmutableID claim in a SAML assertion,
# you can impersonate any cloud-synchronized user
BASH

#Token Signing Certificate Rollover

# ADFS has two token signing certificates: Primary and Secondary
# AutoCertificateRollover: True (default) = secondary used first, rotated periodically
# If AutoCertificateRollover is disabled, the primary certificate is static

# Check rollover status
Get-AdfsProperties | Select-Object AutoCertificateRollover, CertificateDuration

# If rollover is automated (default):
# Both certificates must be extracted (primary and secondary)
# The older certificate (being phased out) may still be accepted by RPs
BASH

#Common Pitfalls

  • Encrypted PFX requires DKM key: The signing certificate private key is stored encrypted. You need the DKM key to decrypt it, which requires DA or ADFS admin privileges.
  • Token validity window: SAML tokens have a NotOnOrAfter timestamp. Forged tokens must have a valid (future) expiration time.
  • Audience restriction: SAML tokens specify the intended recipient (Audience). A forged token for the wrong relying party will be rejected.
  • Certificate expiration: The signing certificate may be expired but still trusted by relying parties. Check the NotAfter date.
  • ImmutableID changes: If an on-premises user is deleted and re-created (or hard-matched), the ImmutableID changes. Old ImmutableID values may still map to disabled cloud identities.

#OPSEC Considerations

  • ADFS configuration extraction generates file access events on the ADFS server
  • Golden SAML forged tokens generate successful authentication events at the relying party (e.g., Azure AD sign-in logs)
  • Token signing certificate extraction is a high-privilege action; requires DA on the ADFS server
  • Forged SAML assertions bypass ADFS authentication logs (no 1200/1201 events on the ADFS server)
  • Cloud service sign-in logs (Azure AD, Okta, etc.) will show the SAML authentication but may not flag it as anomalous
  • The ImmutableID is visible in Azure AD sign-in logs, which can be cross-referenced

#Post-Exploitation Value

  • Persistent access to all federated applications (bypassing password changes and MFA)
  • Cloud persistence even if on-premises AD credentials are rotated
  • Access to Office 365, Azure, AWS, Salesforce, and any other SAML-federated application
  • The Golden SAML token works independently of the compromised user's password status
  • Token signing certificate validity can be years, providing very long-term persistence

#Cross-References

#Tool References

ToolLink
ADFSpoofhttps://github.com/fireeye/ADFSpoof
ADFSDumphttps://github.com/mandiant/ADFSDump
SAML RaiderBurp Suite extension
Microsoft ADFS PowerShell ModuleBuilt-in Windows Server role

#Source Machines

  • (Conceptual — Golden SAML patterns documented from real-world nation-state APT campaigns including SolarWinds/UNC2452)