Adversaries may use alternate authentication material, such as password hashes, Kerberos tickets, and application access tokens, in order to move laterally within an environment and bypass normal system access controls.
Authentication processes generally require a valid identity (e.g., username) along with one or more authentication factors (e.g., password, pin, physical smart card, token generator, etc.). Alternate authentication material is legitimately generated by systems after a user or application successfully authenticates by providing a valid identity and the required authentication factor(s). Alternate authentication material may also be generated during the identity creation process.[1][2]
Caching alternate authentication material allows the system to verify an identity has successfully authenticated without asking the user to reenter authentication factor(s). Because the alternate authentication must be maintained by the system—either in memory or on disk—it may be at risk of being stolen through Credential Access techniques. By stealing alternate authentication material, adversaries are able to bypass system access controls and authenticate to systems without knowing the plaintext password or any additional authentication factors.
| ID | Name | Description |
|---|---|---|
| S0661 | FoggyWeb |
FoggyWeb can allow abuse of a compromised AD FS server's SAML token.[3] |
| C0024 | SolarWinds Compromise |
During the SolarWinds Compromise, APT29 used forged SAML tokens that allowed the actors to impersonate users and bypass MFA, enabling APT29 to access enterprise cloud applications and services.[4][5] |
| ID | Mitigation | Description |
|---|---|---|
| M1036 | Account Use Policies |
Where possible, consider restricting the use of authentication material outside of expected contexts. |
| M1015 | Active Directory Configuration |
Configure Active Directory to prevent use of certain techniques; use SID Filtering, etc. |
| M1013 | Application Developer Guidance |
Consider implementing token binding strategies, such as Azure AD token protection or OAuth Proof of Possession, that cryptographically bind a token to a secret. This may prevent the token from being used without knowledge of the secret or possession of the device the token is tied to.[6][7] |
| M1047 | Audit |
Perform audits or scans of systems, permissions, insecure software, insecure configurations, etc. to identify potential weaknesses. |
| M1027 | Password Policies |
Set and enforce secure password policies for accounts. |
| M1026 | Privileged Account Management |
Limit credential overlap across systems to prevent the damage of credential compromise and reduce the adversary's ability to perform Lateral Movement between systems. |
| M1018 | User Account Management |
Enforce the principle of least-privilege. Do not allow a domain user to be in the local administrator group on multiple systems. |
| ID | Name | Analytic ID | Analytic Description |
|---|---|---|---|
| DET0338 | Behavioral Detection Strategy for Use Alternate Authentication Material (T1550) | AN0954 |
Use of stolen Kerberos tickets or token impersonation resulting in logon sessions from accounts without expected interactive logon events. |
| AN0955 |
Access tokens or SSH keys used without corresponding login shell or PAM module activity, particularly for remote execution. |
||
| AN0956 |
Token replay or impersonation in federated logins without interactive browser session or MFA prompts. |
||
| AN0957 |
Unusual reuse of OAuth access tokens from different geographic regions, without full login events. |
||
| AN0958 |
Container process uses mounted cloud credentials or token cache to authenticate without known orchestration. |
||
| AN0959 |
Access token reuse to connect to SharePoint or Outlook APIs without interactive user context. |
||
| AN0960 |
Use of instance metadata tokens across instances or misuse of short-lived tokens issued for different roles. |