MITRE ATT&CK T1550 Use Alternate Authentication Material Guide: Detecting Token and Hash Replay

Once a user or workload has authenticated, the hash, ticket, token or cookie it was given can be replayed by anyone who steals it, and the replay skips the password and the MFA prompt entirely. MITRE ATT&CK tracks this as T1550 Use Alternate Authentication Material, a Lateral Movement (TA0008) technique that spans Windows, Linux, identity providers, IaaS, SaaS, Office suites and containers. This guide treats T1550 as one detection and hardening problem across all four sub-techniques, with most depth on the cloud half: application access tokens and web session cookies. The Windows half (NTLM hashes and Kerberos tickets) has its own deep guide, which this page summarises and links rather than repeats. It is for detection engineers, identity and cloud owners, and incident responders.

Key takeaways

• The material is proof of a past login. ATT&CK describes alternate authentication material as something systems generate after a successful authentication and cache so the user is not asked again; stealing it lets an adversary authenticate without the password or any additional factor.
• Four sub-techniques, one pattern. T1550.001 Application Access Token, T1550.002 Pass the Hash, T1550.003 Pass the Ticket and T1550.004 Web Session Cookie all present valid material from the wrong place, so detection looks for use without a matching authentication event.
• MFA has already happened. Replayed tokens and cookies carry the earlier MFA result with them; password resets alone often leave them working, as CitrixBleed showed.
• Binding beats lifetime tuning. Short lifetimes shrink the window, but device-bound and sender-constrained tokens (Entra Token Protection, DPoP, DBSC) make a stolen copy useless elsewhere.
• Revocation is a capability you test. Know which systems honour a refresh token revocation in minutes, which wait an hour for access tokens to expire, and which keep their own session cookies until you kill them separately.

How the attack works

ATT&CK v20 (T1550 version 2.0, last modified 12 May 2026) defines the technique as using password hashes, Kerberos tickets and application access tokens to move laterally and bypass normal system access controls. The material is cached in memory or on disk, so it can be stolen through Credential Access techniques and presented elsewhere; theft and use usually happen on different systems.

For T1550.001, ATT&CK highlights two cloud specifics. A refresh token granted to a malicious application gives long-term background access to features such as mail search and contact enumeration. And in AWS and GCP, an identity allowed to request short-lived tokens for another principal can act with that principal's privileges; the AWS example given is sts:GetFederationToken, which creates a federated session with the same permissions as the compromised user. ATT&CK notes that direct API access with a token negates a second factor and may survive a password change.

For the Windows sub-techniques (NTLM authentication with a hash, ticket injection, overpass-the-hash, tiering and logon restrictions, Protected Users, Credential Guard and NTLM reduction), see the Pass-the-Hash and Pass-the-Ticket Guide. Forged tickets are covered in the Golden Ticket, Silver Ticket and DCSync Guide.

Where it shows up

ATT&CK v20 procedure examples show how much of T1550.001 now involves non-human identities rather than people.

• Developer and pipeline tokens: ATT&CK records the Shai-Hulud, Mini Shai-Hulud and CanisterWorm worms using captured npm and other application tokens to publish packages, and TeamPCP using stolen access tokens to inject code into CI/CD workflows. See the npm Tokens Security Guide.
• Cloud service principals: during the SolarWinds compromise APT29 used compromised service principals to make changes in Office 365, and HAFNIUM abused service principals with administrative permissions for exfiltration.
• SaaS OAuth grants: ShinyHunters is recorded using stolen OAuth keys to access cloud infrastructure and bypass two-factor authentication; APT28 used malicious applications that abused OAuth access tokens for webmail. See the SaaS API Token Security Guide.
• Admin tokens in phishing kits: the Kali365 kit captured Exchange admin tokens and used them to create rogue mailbox connectors and change mail-flow rules.
• Browser sessions: infostealer logs routinely include session cookies for SaaS and cloud consoles. See the Infostealer Threat Guide and the Session Hijacking and Cookie Theft Guide.

Impact

• MFA and password controls are bypassed: the attacker inherits a session that already satisfied them.
• Persistence outlives remediation: refresh tokens, long-lived cookies and Kerberos TGTs keep working after a password reset unless explicitly revoked or expired.
• Privilege follows the material, not the person: a CI/CD token or service principal often carries broader rights than any individual user, and NHI tokens rarely trigger user-focused risk policies.
• Blast radius crosses platforms: ATT&CK notes that a token for a victim's primary mailbox can be used to trigger password resets for other services the target subscribes to.

Detection

ATT&CK v20 publishes detection strategies DET0338 (T1550 overall), DET0185 (T1550.001) and DET0074 (T1550.004). They share one idea: material in use without the authentication that should have produced it, or from a context that does not match where it was issued.

Building the analytics

1. Collect non-interactive sign-ins and API audit logs. Many tenants ingest only interactive sign-ins. Without non-interactive and service principal sign-ins, T1550.001 is invisible.
2. Key on session and token identifiers. Join on session ID, unique token identifier or STS access key ID, then flag when the IP, ASN, device ID or user agent changes mid-session. A session that hops country in minutes is the classic replay signal.
3. Baseline workloads, not just users. A CI/CD token, managed identity or service principal normally calls a small set of APIs from known egress IPs. Alert on new source networks and new API families for each workload identity.
4. Use vendor detections as one input. Microsoft Defender for Identity, for example, maps "Suspected pass-the-ticket attack" to T1550 and "Suspicious authentication attempt" and "Possible overpass-the-hash attack" to T1550.002. Treat them as triage starts, not complete coverage of the cloud sub-techniques.

Metrics that show it is working

• Telemetry coverage: percentage of identity providers, cloud accounts and SaaS tenants whose non-interactive and API audit logs reach the SIEM.
• Binding coverage: share of privileged and high-value sessions protected by device binding or sender-constrained tokens.
• Time to revoke: median minutes from a confirmed token or cookie theft to all sessions for that identity being unusable, measured in exercises.
• Replay detection rate: percentage of red team or purple team token replays detected, and median time to alert.

Prevention and hardening

Bind the material to where it was issued

ATT&CK mitigation M1013 Application Developer Guidance recommends token binding, naming Azure AD token protection and OAuth proof of possession.

Constrain where material can be used

• Network conditions on cloud credentials: ATT&CK M1036 suggests restricting token use outside expected contexts, citing AWS data perimeters. AWS implements these with service control policies, resource control policies and VPC endpoint policies; condition keys such as aws:SourceIp, aws:SourceVpc and aws:PrincipalOrgID express the expected network and organisation.
• Location enforcement in Entra ID: Continuous Access Evaluation (CAE) enforces IP-based named locations instantly at supporting resources; country locations are not enforced instantly.
• Disable delegation you do not need: ATT&CK M1047 recommends disabling the ability to request temporary tokens on behalf of other accounts where possible, and auditing which accounts hold it.
• Least privilege for workload tokens: M1018 and M1026 apply directly to NHIs: one token per workload, scoped to the resources it needs, never shared across environments.

Shorten and contain sessions

• Lifetimes: non-CAE access tokens in Entra ID default to one hour; CAE sessions can run up to 28 hours because critical events, not a timer, drive revocation. That is a good trade only for CAE-capable clients and resources. See the Token Lifetime Policy Design Guide.
• Persistent cookies: ATT&CK M1054 for T1550.004 suggests configuring browsers to delete persistent cookies regularly; for admin portals, set sign-in frequency and disable persistent browser sessions.

Implementation sequence

1. Telemetry first: ingest non-interactive sign-ins, cloud audit logs and SaaS API logs, and build the session-context analytics above before tightening policy.
2. Pilot binding in report-only mode: Microsoft recommends creating Token Protection policies in report-only mode, piloting with a small group and reviewing interactive and non-interactive sign-in logs long enough to cover normal application use.
3. Enforce for privileged users and workloads: admins, break-glass review paths and high-value service principals first, then broader populations.
4. Add network constraints: data perimeter policies and named locations, tested in a non-production account or with exclusions for known automation.
5. Rollback: keep enforcement policies scoped by group so a failing client population can be excluded quickly, and record every exclusion with an expiry date.

Decision guidance

• Small organisations: rely on platform features: Conditional Access with CAE, sign-in frequency for admins, phishing-resistant MFA, short-lived cloud credentials instead of access keys, and a rehearsed revocation runbook.
• Large or regulated organisations: add token binding at scale, data perimeters, workload identity federation to remove static secrets, and per-identity behavioural baselines in an ITDR or SIEM platform. See the ITDR Guide.

Responding to confirmed replay

Microsoft's revocation guidance is a useful model of what actually ends access: disabling the account and calling revokeSignInSessions (Revoke-MgUserSignInSession) stops new tokens, but existing access tokens stay valid until expiry, and an application's own session cookie is not revoked by the identity provider. CAE-capable apps react in near real time, with propagation latency of up to 15 minutes. For on-premises accounts Microsoft advises resetting the password twice to mitigate pass-the-hash. Revoke at every layer: identity provider, each SaaS application's sessions, OAuth grants, cloud access keys and workload tokens. See the OAuth Token Theft Incident Playbook.

Framework mapping

Lessons from incidents

• Patch, then kill the sessions: in CitrixBleed (CVE-2023-4966) NetScaler appliances leaked AAA session cookies that attackers replayed without credentials or MFA. Patching stopped new leaks but not stolen sessions; Citrix told customers to terminate all active and persistent sessions, and one victim reported unauthorised access after it had patched.
• Developer tokens are lateral movement material: the token-stealing npm worms recorded in ATT&CK used each stolen publishing token to reach new packages and new victims, which is T1550.001 at supply chain scale.

Practitioner checklist

• Ingest non-interactive sign-ins, service principal sign-ins, cloud audit logs and SaaS API logs into one detection platform.
• Build analytics that join on session or token identifiers and alert when IP, ASN, device or client changes mid-session.
• Baseline each high-value workload identity's source networks and API calls, and alert on deviation.
• Pilot Entra Token Protection or equivalent device binding in report-only mode, then enforce for administrators first.
• Require DPoP or mTLS-bound tokens for your own high-value APIs where clients can hold a key.
• Apply network and organisation conditions to cloud credentials through data perimeter policies.
• Remove standing ability to mint tokens for other principals, such as unneeded AssumeRole or GetFederationToken rights.
• Write and rehearse a revocation runbook covering identity provider, each SaaS app session, OAuth grants, cloud keys and workload tokens.

Standards and references

• MITRE ATT&CK: Use Alternate Authentication Material (T1550)
• MITRE ATT&CK: Application Access Token (T1550.001)
• MITRE ATT&CK: Web Session Cookie (T1550.004)
• IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
• Microsoft Learn: Token Protection in Microsoft Entra Conditional Access
• Microsoft Learn: Continuous Access Evaluation
• Chrome for Developers: Device Bound Session Credentials
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Pass-the-Hash and Pass-the-Ticket Guide · MITRE ATT&CK T1528 Steal Application Access Token Guide · Session Hijacking and Cookie Theft Guide · Token and Session Security Guide · MITRE ATT&CK T1606 Forge Web Credentials Guide