Safeguard
Application Security•

Use Alternate Authentication Material: A Defender's Guide (T1550)

Hashes, Kerberos tickets, tokens and cookies let an attacker act as a user without a password. MITRE T1550 explained, with the common detection pattern and mitigations for each.

Safeguard Security Team
4 min read

When you log in, the system gives you something to prove it later: a hash cached in memory, a Kerberos ticket, an access token, a session cookie. That saves you from retyping a password and a second factor on every request. It also creates material that is worth stealing. MITRE tracks the use of that stolen material as T1550, Use Alternate Authentication Material, a Lateral Movement technique.

The platforms are broad: Containers, IaaS, Identity Provider, Linux, Office Suite, SaaS and Windows.

How attackers use it

MITRE explains the logic. Authentication normally needs an identity (a username) and one or more factors such as a password, PIN, smart card or token generator. Alternate authentication material is generated legitimately by systems after a user or application authenticates successfully. It can also be generated during identity creation.

Because the system must keep this material, in memory or on disk, it may be at risk of theft through Credential Access techniques. With stolen material, an adversary bypasses system access controls and authenticates without knowing the plaintext password or any additional factors.

MITRE splits the technique into four sub-techniques, each with its own post in this series.

  • Application Access Token (T1550.001), for cloud, container and SaaS APIs.
  • Pass the Hash (T1550.002), on Windows.
  • Pass the Ticket (T1550.003), for Kerberos on Windows.
  • Web Session Cookie (T1550.004), for web applications and cloud services.

How to detect it

MITRE's detection strategy for the parent technique lists one analytic per setting. They share a shape: authentication material is used, but the events you would expect around a real login are missing.

  • Windows: use of stolen Kerberos tickets or token impersonation, producing logon sessions from accounts with no expected interactive logon events.
  • Linux: access tokens or SSH keys used without a matching login shell or PAM module activity, especially for remote execution.
  • Federated identity: token replay or impersonation in federated logins with no interactive browser session or MFA prompt.
  • OAuth: unusual reuse of access tokens from different geographic regions, without full login events.
  • Containers: a process using mounted cloud credentials or a token cache to authenticate without a known orchestration reason.
  • Office Suite: access token reuse to reach SharePoint or Outlook APIs with no interactive user context.
  • Cloud instances: use of instance metadata tokens across instances, or misuse of short-lived tokens issued for different roles.

The missing event is the signal. A session that never had a login is more suspicious than a login that looks a bit odd.

How to reduce the risk

MITRE lists seven mitigations.

  • Account Use Policies: restrict the use of authentication material outside expected contexts.
  • Active Directory Configuration: configure AD to prevent use of certain techniques, for example with SID Filtering.
  • Application Developer Guidance: consider token binding, such as Azure AD token protection or OAuth Proof of Possession, that cryptographically ties a token to a secret. That can stop a token being used without the secret or the device it belongs to.
  • Audit: audit systems, permissions, insecure software and configurations to find weaknesses.
  • Password Policies: set and enforce secure password policies.
  • Privileged Account Management: limit credential overlap across systems so one compromise cannot spread.
  • User Account Management: enforce least privilege, and do not allow a domain user to be a local administrator on multiple systems.

Two ideas run through the list. Make material hard to use away from where it was issued, and make sure a stolen item opens as little as possible.

Check your own environment

  • Which of your applications issue long-lived tokens, and could any of them use token binding?
  • Do your logs let you join a token or ticket use to a login event? If you cannot join them, you cannot see the gap.
  • Where does an administrator credential work? List the systems.
  • Are tokens or keys mounted into containers that do not need them?

Quick check

Why is alternate authentication material a lateral movement problem?

It lets an adversary authenticate to other systems as the user without the password or extra factors, so one stolen item can open many places.

What detection pattern appears in almost every analytic for this technique?

Authentication material is used without the login, MFA or interactive session events that should come with it.

Sources

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.