Forge Web Credentials (T1606) is a credential access technique in MITRE ATT&CK. Its platforms are SaaS, IaaS, Windows, macOS, Linux, Office Suite and Identity Provider.
The adversary does not steal a login. They make one.
That is the difference MITRE draws. With related behaviors such as stealing a web session cookie or an application access token, an existing credential is taken from a legitimate user. Here the credential is new and forged by the adversary. That matters for defenders, because there is no victim session to match against, and the forged material may never touch a login page.
How attackers use it
MITRE says web applications and services, whether hosted in cloud SaaS environments or on premises, often use session cookies, tokens or other materials to authenticate and authorize users. Adversaries may generate such materials to gain access to web resources.
Forging usually needs a secret. MITRE says generating web credentials often requires secret values such as passwords, private keys or other cryptographic seed values.
MITRE gives two concrete examples of features that can be used to forge tokens:
- In AWS, the AssumeRole and GetFederationToken APIs, which let users request temporary security credentials (the Temporary Elevated Cloud Access idea).
- In Zimbra, the zmprov gdpak command, which generates a pre-authentication key that can be used to generate tokens for any user in the domain.
Once forged, MITRE says these credentials may be used to access resources, through Use Alternate Authentication Material, and may bypass multi-factor and other authentication protection mechanisms.
The two sub-techniques are SAML Tokens (T1606.002) and Web Cookies (T1606.001). Those are covered separately, so this article stays with the parent technique.
Why does the secret matter so much? Because whoever holds a signing key or seed value can mint credentials at will, and the service will accept them as genuine. Protecting those secrets is protecting the ability to say who is who.
How to detect it
MITRE's detection strategy is split by environment.
Cloud IaaS. Monitor for anomalous API activity such as AssumeRole or GetFederationToken run by unusual principals. These events often line up with sudden logon sessions from unfamiliar IP addresses or regions. MITRE describes the typical chain as misuse of secret material, such as a stolen private key or password, then an API request that generates a new token, then access to high-value resources.
Identity providers and SAML, OpenID Connect, Zimbra. Anomalous SAML token issuance, OpenID Connect token minting or Zimbra pre-auth key use. Signs include tokens issued without the normal authentication events, multiple valid tokens generated at the same time, and signing anomalies in identity provider logs.
Windows. Anomalous browser cookie files, local token cache manipulation, or tools that inject tokens into sessions. Processes that unexpectedly access LSASS or browser credential stores, followed by unusual logon sessions.
Linux. Forged credentials injected into browser session files, curl or wget headers, or token caches in memory. MITRE says auditd can track processes that access sensitive files such as browser profile folders and the AWS credentials file in the home directory, correlated with suspicious outbound connections.
macOS. Unified Logs that show abnormal access to Keychain or browser session files, correlated with web session use from Safari or Chrome processes outside the typical user context.
SaaS. Unusual API keys, tokens or session cookies used without corresponding authentication. Simultaneous valid sessions from several geographies, unusual API calls with new tokens, or bypass of expected MFA enforcement.
Office Suite. Abnormal authentication headers in Outlook or Teams traffic, or unexplained OAuth grants in Microsoft 365 and Azure logs. Correlate token use with missing authentication flows and mismatched device and user context.
The common signal across all of these is use without a matching sign-in. A token that appears with no authentication event behind it is the one to chase.
How to reduce the risk
MITRE lists four mitigations.
- Audit. Audit all access lists and the permissions they grant to web applications and services, extensively, to establish a baseline, then re-audit new or updated resources periodically. Investigate and remove suspicious accounts and credentials. For AD FS, enable advanced auditing, check the success and failure audit options, and enable Audit Application Generated events on the AD FS farm through Group Policy.
- Privileged Account Management. Restrict access to the AD FS server so it originates only from privileged access workstations.
- Software Configuration. Configure browsers and applications to regularly delete persistent web credentials such as cookies.
- User Account Management. Make sure administrative accounts follow best practice, including privileged access workstations, Just in Time and Just Enough Administration, and strong authentication. Reduce the number of users in highly privileged directory roles. In AWS, prohibit users from calling the sts:GetFederationToken API unless it is explicitly required.
Since forging depends on secrets, add two things around them:
- Find secrets before an adversary does. Private keys, signing keys and passwords committed to code repositories or left in build files are exactly the material MITRE says forgery needs.
- Limit how long a token is valid, and how many people can mint one.
Check your own environment
In AWS, look through CloudTrail for the two API calls MITRE names (AWS CLI, read-only; this returns recent management events):
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=GetFederationToken
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole
Check who the principals are, and whether each one is expected.
On Linux, list the loaded auditd rules to see whether credential files are watched (requires root, read-only):
sudo auditctl -l
Then ask:
- Which accounts are allowed to call GetFederationToken, and why?
- Who has access to token-signing keys, and is that access logged?
- Can you list every private key and signing secret and say where it is stored?
- Do you alert on a token used with no sign-in event behind it?
Try it yourself
Secrets scanning looks for the passwords, keys and tokens that forgery depends on, before they leak.
Click through it at your own pace, or open it full screen.
Quick check
How is forging a web credential different from stealing a session cookie?
The credential is new and created by the adversary, not taken from a legitimate user, so there is no victim session behind it.
What is the typical chain MITRE describes in cloud environments?
Misuse of secret material such as a stolen private key or password, then an API request that generates a new token, then access to high-value resources.
Which AWS API does MITRE suggest prohibiting unless explicitly required?
sts:GetFederationToken.
