MITRE ATT&CK T1606 Forge Web Credentials Guide: Detecting Forged Tokens and SAML Assertions

An attacker who holds a signing key does not need to steal anyone's session: they can mint a fresh, perfectly valid one for any user, with any claims, and no MFA prompt ever appears. MITRE ATT&CK tracks this as T1606 Forge Web Credentials, a Credential Access (TA0006) technique with two sub-techniques in ATT&CK v20: T1606.001 Web Cookies and T1606.002 SAML Tokens. Unlike cookie or token theft, the credential is new, so device, location and MFA signals tied to the original login do not exist. This guide explains how forgery differs from theft, where the signing secrets live, the detection strategies ATT&CK maps to the technique, and the hardening and response steps that limit the blast radius. It is written for identity architects, detection engineers and incident responders, and it covers defence only.

Key takeaways

• Forgery is a key management problem first. Every forged cookie or assertion depends on a secret: a token-signing certificate, a framework secret key, a private key or a privileged API. Protect, inventory and rotate those secrets as Tier 0 non-human credentials.
• The detection gap is the missing login. A forged SAML token produces a sign-in at the service provider with no matching authentication at the identity provider. Correlating the two is the core detection.
• Signature checks are not enough. Relying parties must validate issuer, audience, scope and lifetime, as the Storm-0558 key breach showed when consumer-signed tokens were accepted for enterprise mailboxes.
• Response means rotating the key, twice. For AD FS, Microsoft and ATT&CK both advise replacing the token-signing certificate in rapid succession twice, then revoking refresh tokens.
• Fewer federation hops, smaller blast radius. Moving from on-premises federation to cloud authentication removes the token-signing certificate an on-premises attacker could steal.

How the attack works

Web applications and cloud services accept bearer artefacts as proof of identity: session cookies, SAML assertions, OAuth and OIDC tokens, and temporary cloud credentials. Each is trusted because it carries a valid signature or because the server recognises it. ATT&CK describes T1606 as generating these artefacts rather than intercepting them, which separates it from Session Hijacking and Cookie Theft Guide (T1539) and MITRE ATT&CK T1528 Steal Application Access Token. The forged artefact is then used through MITRE ATT&CK T1550 Use Alternate Authentication Material, which ATT&CK notes may bypass multi-factor and other authentication protections.

The prerequisite is always secret material or a privileged minting capability. ATT&CK lists passwords, private keys (T1552.004) and cryptographic seed values, plus legitimate features that issue credentials on request, such as the AWS AssumeRole and GetFederationToken APIs and the Zimbra pre-authentication key. That is why forgery usually follows a deeper compromise, such as administrative access to an identity provider server, a leaked application secret or a key exposed in a repository. See the MITRE ATT&CK T1552 Unsecured Credentials Guide.

Where it shows up

• On-premises federation (AD FS and similar): the token-signing certificate on the federation servers can sign assertions for any user and any relying party. ATT&CK notes the default SAML token lifetime is one hour, but a forger sets NotOnOrAfter to whatever they like. Microsoft's guidance on protecting Microsoft 365 from on-premises attacks states that anyone holding a compromised SAML token-signing certificate can impersonate any user in the cloud. See the SAML Security Guide.
• Federation trust changes: an attacker with enough directory rights can add their own identity provider or a new signing certificate to an existing federated domain, then mint tokens with a key they generated. This overlaps with MITRE ATT&CK T1484 Domain or Tenant Policy Modification.
• Cloud identity provider signing keys: a provider's own token-signing keys are the largest-scope secret of all, as the Storm-0558 incident showed. See the Storm-0558 and Cloud Key Theft Profile.
• Web applications: frameworks that sign session cookies with a server-side secret are forgeable by anyone who obtains that secret, for example from source code, a configuration file or a container image.
• Cloud IAM: in AWS, GetFederationToken issues federated user credentials from an IAM user's long-term keys, with a duration from 900 seconds up to 129,600 seconds (36 hours), default 43,200. A leaked IAM user key can therefore mint fresh credentials that outlive revocation of the leaked key unless sessions are also revoked.

Impact

• Any user, any privilege: ATT&CK notes a forged SAML token claiming a highly privileged account can yield administrative Entra ID privileges.
• MFA becomes irrelevant: MFA happens at the identity provider during issuance; a forged token skips issuance, so the service provider sees an already-authenticated user.
• Persistence that survives password resets: resetting passwords and MFA does nothing while the signing key is still trusted.
• Cross-tenant and cross-customer reach: in the Microsoft Storm-0558 key breach, one consumer signing key that should have been retired was used to forge tokens accepted by Exchange Online, giving access to mail of more than 500 people at 22 organisations from about 15 May 2023.
• Chained identity abuse: in the SolarWinds SUNBURST compromise, forged SAML tokens were followed by credentials added to existing application service principals that already had mail permissions, turning one stolen certificate into durable non-human access.

Detection

ATT&CK v20 maps DET0260 to the parent technique, DET0171 to web cookies and DET0148 to SAML tokens. All three rest on the same idea: a legitimate credential has a birth record at the issuer; a forged one does not. Build detections that join service provider activity back to issuer logs. The ITDR Guide covers where these fit in an identity detection programme.

Prerequisites for these detections

1. Enable AD FS auditing: grant the AD FS service account "Generate security audits", run auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable, tick success and failure audits in the federation service properties, and consider Set-AdfsProperties -AuditLevel Verbose during investigations.
2. Forward AD FS logs, DC Kerberos events, IdP sign-in and audit logs, and cloud provider logs to one place with consistent time and user keys. The AD FS Activity ID ties events for one request across servers.
3. Record the current signing certificate thumbprints for every IdP and relying party, so an unknown thumbprint is detectable.
4. Retain premium mailbox and SaaS access auditing where available: in the Storm-0558 case, detection came from a custom alert on the MailItemsAccessed event that needed premium logging.

Metrics

• Issuance correlation coverage: percentage of federated relying parties whose sign-ins can be joined to an issuer event.
• Signing key inventory completeness: signing keys and certificates with a named owner, storage location (HSM or not), expiry and last rotation date, against the total discovered.
• Key age: number of signing keys past their planned retirement date, target zero.
• Federation change attribution: percentage of federation and signing certificate changes matched to an approved change.
• Rotation rehearsal time: minutes to complete a rehearsed double rotation of a token-signing certificate in a test environment.

Prevention and hardening

Protect the signing secrets

• Treat signing keys as Tier 0 non-human credentials: keep them in an HSM or managed key service where the platform supports it, restrict who can export them, and inventory them like any other machine credential. See the Token and Session Security Guide.
• Restrict access to federation servers (M1026, M1018): ATT&CK advises administering AD FS only from privileged access workstations, with just-in-time and just-enough administration and fewer members of highly privileged directory roles.
• Retire keys on schedule: the Storm-0558 key was created in 2016 and should have been retired in 2021 but was not, because manual rotation stopped. Automate rotation and alert on expired keys that are still trusted.
• Application secrets: never commit session-signing secrets, store them in a secrets manager, and rotate them when staff or pipelines with access change.

Reduce what a forged credential can do

• Prefer cloud authentication to on-premises federation: Microsoft recommends disabling federation trust for Microsoft 365 where possible and using cloud authentication with phishing-resistant methods. See the Federation and Trust Relationships Guide.
• Validate more than the signature: relying parties should check issuer, audience, key scope, NotOnOrAfter and the expected signing certificate. See the SAML Security Guide.
• Short lifetimes: keep token and session lifetimes as short as the use case allows. See the Token Lifetime Policy Design Guide.
• Server-side sessions (M1054): store session state on the server, reject identifiers the server never issued, use the __Host- cookie prefix with Secure, HttpOnly and SameSite, and enforce idle and absolute timeouts, as the OWASP Session Management Cheat Sheet recommends.
• Restrict minting APIs: ATT&CK advises prohibiting sts:GetFederationToken in AWS unless explicitly required, for example through a service control policy, and reducing long-lived IAM user keys.

Choosing controls by environment

Response when forgery is suspected

1. Scope: identify which signing key or secret is suspect and every relying party that trusts it.
2. Rotate twice: for AD FS, run Update-ADFSCertificate -CertificateType Token-Signing -Urgent and then a second update so the cloud side releases the old certificate, push the new certificate to Entra ID with Update-MgDomainFederationConfiguration, and remove the old certificate with Remove-ADFSCertificate. Microsoft warns this causes an outage until partners update trusts, so plan relying party updates.
3. Revoke sessions: revoke refresh tokens for affected users (Microsoft lists Revoke-EntraUserAllRefreshToken) and invalidate application sessions.
4. Remove persistence: check for new federation trusts, signing certificates, service principal credentials and role assignments added during the window.
5. Hunt back: run the issuance correlation over the full retention period, since forged sessions leave no IdP trace to start from.

Lessons from incidents

• A signing certificate is a master key: the SolarWinds SUNBURST compromise showed that on-premises admin access led to the token-signing certificate, forged SAML tokens for any user without MFA, and then new credentials on existing service principals. Few organisations alerted on service principal credential changes at the time.
• Scope validation matters as much as signatures: in the Microsoft Storm-0558 key breach, Microsoft's analysis described a validation flaw that let a consumer signing key be trusted for enterprise tokens, and noted that signing with that key was itself a strong indicator because no legitimate system did so.
• Logging decides whether you see it: the Storm-0558 activity was spotted through mailbox access auditing; organisations without that logging had no way to see it.
• Old keys are dangerous keys: a key past its retirement date still worked because rotation had become manual and then stopped.

Framework mapping

Practitioner checklist

• Inventory every token-signing key and session-signing secret, with owner, storage, expiry and last rotation.
• Move signing keys into an HSM or managed key service where supported, and restrict export.
• Administer federation servers only from privileged access workstations with just-in-time access.
• Enable AD FS success and failure auditing and forward events 1200 and 1202 to the SIEM.
• Build a detection that joins service provider sign-ins to issuer events and alerts on orphans.
• Alert on every federation setting, issuer and signing certificate change.
• Require relying parties to validate issuer, audience, key scope and lifetime, not only the signature.
• Use server-side sessions and reject session IDs the server never issued.
• Block sts:GetFederationToken where not required and remove long-lived IAM user keys.
• Rehearse the double rotation of the token-signing certificate and refresh token revocation.

Standards and references

• MITRE ATT&CK: Forge Web Credentials (T1606)
• MITRE ATT&CK: SAML Tokens (T1606.002)
• Microsoft Learn: Emergency rotation of the AD FS certificates
• Microsoft Learn: AD FS troubleshooting, auditing events and logging
• Microsoft Learn: Protecting Microsoft 365 from on-premises attacks
• Microsoft Security: Analysis of Storm-0558 techniques for unauthorized email access
• AWS: GetFederationToken API reference
• OWASP: Session Management Cheat Sheet

Related NHI Mgmt Group resources: SAML Security Guide · Golden Ticket, Silver Ticket and DCSync Guide · ITDR Guide · MITRE ATT&CK T1556 Modify Authentication Process Guide · APT29 (Midnight Blizzard) Threat Actor Profile