Forge Web Cookies (T1606.001) is a Credential Access sub-technique of Forge Web Credentials. MITRE lists it for Windows, Linux, macOS, SaaS and IaaS. The idea is simple: instead of stealing a session cookie from a user, the adversary builds a brand new one that the web application will accept.
Web applications and cloud services use session cookies to decide who you are after you log in. If someone can produce a cookie the server trusts, the login step never happens. That is why MITRE notes that forged cookies may bypass multi-factor and other authentication protection.
How attackers use it
MITRE separates this from Steal Web Session Cookie. In that technique the cookie belongs to a real user. Here the cookie is new, created by the adversary.
Many common web applications use standardized, documented cookie formats, and the tools or interfaces to generate them are provided. The missing ingredient is a secret. Generating a valid cookie often needs passwords, private keys or other cryptographic seed values.
The one procedure example on the MITRE page comes from the SolarWinds Compromise, where APT29 bypassed MFA on Outlook Web Access accounts by generating a cookie value from a previously stolen secret key. Once forged, the cookie is used as described in Web Session Cookie (T1550.004) to reach resources.
The takeaway for defenders: the secret that signs or seeds your cookies is as sensitive as a password database.
How to detect it
MITRE's detection strategy for this technique has an analytic for each platform. The common thread is a session with no matching login.
- SaaS: valid web sessions without matching login activity, MFA enforcement that seems to be bypassed, cookies reused across several devices or IP addresses, concurrent sessions from multiple geographies, or session tokens generated by unrecognized apps.
- IaaS: authentication that bypasses MFA through session or role APIs with cookies that were never legitimately issued, followed by resource access from unfamiliar IP addresses.
- Windows, Linux, macOS endpoints: processes other than the browser writing directly to cookie stores, then authentication events to SaaS or IaaS services. On Linux, MITRE also names curl or wget commands that embed cookies in headers, correlated with abnormal session activity.
In practice, start with your identity and application logs. A session that exists without a logon event for the same user is the strongest signal. Then add endpoint file auditing on browser cookie databases for the machines you care about most.
How to reduce the risk
MITRE lists two mitigations for this sub-technique.
- Audit access lists. Review every access list and the permissions granted to web applications and services. Build a baseline first, then repeat the audit for new or changed resources. Investigate and remove suspicious accounts and credentials.
- Configure cookie handling. Set browsers and applications to regularly delete persistent web cookies, which shortens how long any cookie stays useful.
Beyond the MITRE list, treat cookie signing keys and seed values as secrets: store them in a vault, restrict who can read them, and rotate them after any suspected exposure. That is general hygiene, not a MITRE mitigation, but it follows directly from the fact that forging needs a secret.
Check your own environment
- List every web application that issues its own session cookies and note where each signing secret lives.
- Check that those secrets are not in source repositories, config files or CI variables that many people can read.
- Confirm your logs let you join a session to the login event that created it.
- Review lifetime settings for persistent cookies and shorten any that outlast a working day without a good reason.
- Ask whether any app still accepts a session after the user's password or MFA device was reset.
Quick check
How does a forged cookie differ from a stolen one?
A stolen cookie belongs to a real user who logged in. A forged cookie is newly generated by the adversary, usually with a secret such as a password, private key or seed value, so there may be no matching login at all.
What is the best single log signal?
A valid web session with no matching login activity for that user, especially when it appears from unfamiliar IP addresses or in several places at once.
