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

BASH

# 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>

#ADFS Configuration Discovery (on ADFS server)

POWERSHELL

# 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
}

#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.

BASH

# 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

#SAML Token Manipulation

BASH

# 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

#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.

BASH

# 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

#Token Signing Certificate Rollover

BASH

# 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

#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

Tool	Link
ADFSpoof	https://github.com/fireeye/ADFSpoof
ADFSDump	https://github.com/mandiant/ADFSDump
SAML Raider	Burp Suite extension
Microsoft ADFS PowerShell Module	Built-in Windows Server role

#Source Machines

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