Detecting and Mitigating Forged SAML Tokens (T1606.002)

Forge SAML Tokens (T1606.002) is a Credential Access sub-technique under Forge Web Credentials. MITRE lists these platforms: SaaS, IaaS, Windows, Office Suite and Identity Provider. It matters most to organizations that use federated single sign-on, where one signing certificate vouches for every user.

If an adversary holds a valid SAML token-signing certificate, they can create tokens that claim any permissions and any lifetime. The services that trust that certificate will accept them.

How attackers use it

MITRE explains that the default lifetime of a SAML token is one hour, but the validity period can be set in the NotOnOrAfter value of the conditions element. The lifetime can be changed with the AccessTokenLifetime setting in a LifetimeTokenPolicy. A forger controls these values, so a forged token does not have to expire when a normal one would.

There are two routes to the signing material described on the page:

• The adversary uses private keys (see Private Keys, T1552.004) to compromise the organization's existing token-signing certificate.
• If they have enough permissions to set up a new federation trust with their own Active Directory Federation Services (AD FS) server, they can generate their own trusted token-signing certificate instead.

This differs from Steal Application Access Token, because the tokens here are new and forged rather than taken from legitimate users. A token that claims to represent a highly privileged account could give administrative Entra ID privileges. It can also lead to Use Alternate Authentication Material, which may bypass multi-factor and other authentication protection.

Two procedure examples are listed on the page. AADInternals can create SAML tokens using the AD FS token-signing certificate. During the SolarWinds Compromise, APT29 created tokens using compromised SAML signing certificates.

How to detect it

The core idea in MITRE's detection strategy is that a forged token appears without the events that a real sign-in leaves behind.

• Windows and AD FS: authentication with a valid signature but no preceding Kerberos or authentication events. MITRE suggests correlating SAML assertions with missing Event IDs 4769, 1200 or 1202, and looking for tokens with abnormal lifetimes, issuers or claims compared to your baseline.
• IaaS: cross-account or cross-cloud authentication without matching STS events. For example, AssumeRole or GetFederationToken API use with no corresponding SAML assertion log from the trusted identity provider.
• SaaS and Office Suite: logins that succeed without MFA, claims that do not fit the user's profile, the same SAML assertion ID used from different geographies at the same time, token replay across several clients, and access to privileged mailboxes with no prior interactive login.

Two practical points follow. First, you need AD FS and identity provider logs retained somewhere an attacker on the AD FS server cannot erase. Second, you need a baseline of normal token lifetimes and issuers, or the anomalies have nothing to be measured against.

How to reduce the risk

MITRE lists four mitigations.

1. Rotate the token-signing certificate twice, quickly. To contain the impact of a previously forged token, rotate the token-signing AD FS certificate in rapid succession two times. This invalidates tokens generated with the earlier certificate.
2. Turn on AD FS auditing. Enable advanced auditing on AD FS, check the success and failure audit options in the AD FS Management snap-in, and enable Audit Application Generated events on the AD FS farm through a Group Policy Object.
3. Limit where AD FS is administered from. Allow access to the AD FS server only from privileged access workstations.
4. Tighten admin accounts. Administrative accounts should use privileged access workstations, Just in Time and Just Enough Administration, and strong authentication. Reduce the number of people in highly privileged directory roles.

Check your own environment

Read-only checks on an AD FS server (Windows, PowerShell, run as an administrator):

# List the token-signing certificates AD FS is using
Get-AdfsCertificate -CertificateType Token-Signing

# Show the current properties, including rollover behavior
Get-AdfsProperties

Then work through this list:

• Do you know who can export the token-signing private key, and where backups of it sit?
• Is AD FS auditing enabled, and do those events ship to a central log store?
• Which accounts can create a new federation trust in your tenant?
• Can you tell, from logs, whether a given SaaS login came from a real IdP sign-in?
• Is your plan for double certificate rotation written down and tested?

Quick check

Sources

• MITRE ATT&CK T1606.002 Forge Web Credentials: SAML Tokens