T1606.001: Web Cookies
Adversaries may forge web cookies that can be used to gain access to web applications or Internet services. Web applications and services (hosted in cloud SaaS environments or on-premise servers) often use session cookies to authenticate and authorize user access.
Adversaries may generate these cookies in order to gain access to web resources. This differs from Steal Web Session Cookie and other similar behaviors in that the cookies are new and forged by the adversary, rather than stolen or intercepted from legitimate users. Most common web applications have standardized and documented cookie values that can be generated using provided tools or interfaces.[1] The generation of web cookies often requires secret values, such as passwords, Private Keys, or other cryptographic seed values.
Once forged, adversaries may use these web cookies to access resources (Web Session Cookie), which may bypass multi-factor and other authentication protection mechanisms.[2][1][3]
Analyst context for executives and security teams
Forged web cookies matter because they can turn a weakness in session-cookie design, signing secrets, private keys, or application configuration into direct access to web applications and Internet services. The business issue is not just credential theft; attackers may create new session material that appears valid and can potentially bypass normal authentication and MFA decision points.
Executive priority
Prioritize this where critical SaaS, IaaS, or on-premise web applications depend on cookies for authentication or authorization. Leaders should ask whether session-signing secrets and private keys are governed like privileged credentials, whether web and cloud audit logs can prove how sessions were created and used, and whether incident responders can invalidate sessions and rotate affected secrets quickly. This technique is also relevant to audit readiness because the mapped mitigation emphasizes auditing and software configuration review.
Technical view
T1606.001 is a credential-access sub-technique under Forge Web Credentials. It applies to Linux, macOS, Windows, SaaS, and IaaS environments and focuses on adversaries generating new web cookies rather than stealing existing user cookies. SOC and IR teams should validate logging around web session creation, cookie validation failures, unusual cookie-authenticated access, secret/private-key access, and configuration changes affecting cookie signing or session handling. ATT&CK does not provide official detection text here, but the object is related to DET0171, Detection Strategy for Forged Web Cookies, and mitigations M1047 Audit and M1054 Software Configuration.
Likely telemetry
- Web application authentication, authorization, and session-management logs
- SaaS and IaaS sign-in, session, and administrative audit logs
- Application server logs from Linux, macOS, or Windows-hosted web services
- Logs showing access to passwords, private keys, signing secrets, or cryptographic seed values used by applications
- Configuration-change records for web applications, middleware, identity integrations, and session-cookie settings
Detection direction
- Confirm whether DET0171 or equivalent analytics are implemented for applications that use signed or structured cookies.
- Look for cookie-authenticated access that does not align with expected session issuance, user behavior, source context, or authentication history.
- Correlate suspicious web sessions with access to private keys, passwords, signing secrets, or application configuration changes, since the description notes forged cookies often require secret values.
- Tune carefully for legitimate application behavior, load-balanced environments, session refresh mechanisms, and administrative testing to reduce false positives.
- Identify blind spots where SaaS platforms, custom web applications, or IaaS-hosted services do not expose enough session creation and validation detail for investigation.
Mitigation priorities
- Start with M1047 Audit: ensure web, SaaS, IaaS, and application logs are enabled, retained, reviewed, and usable for anomaly investigation and compliance evidence.
- Apply M1054 Software Configuration: review application and middleware settings for secure cookie handling, session management, and protection of signing material.
- Treat cookie-signing secrets, passwords, private keys, and cryptographic seed values as high-value credentials with controlled access and reviewable audit trails.
- Prepare IR procedures to invalidate sessions and rotate affected secrets or keys when forged-cookie use is suspected.
- Prioritize critical business applications first, especially those where cookie-based sessions protect privileged access or operationally important services.
Analyst notes and limits
This take is based on the ATT&CK T1606.001 object, its external references, and relationships. The SolarWinds Compromise relationship shows this behavior has campaign context in ATT&CK, but local relevance depends on the organization’s applications, identity architecture, cloud services, and logging depth.
Official ATT&CK detection guidance is not provided for this object. The recommended telemetry and validation steps are defensive interpretations of the supplied description, platforms, tactics, mitigations, and detection-strategy relationship; they require environment-specific confirmation.
Web Cookies
Adversaries may forge web cookies that can be used to gain access to web applications or Internet services. Web applications and services (hosted in cloud SaaS environments or on-premise servers) often use session cookies to authenticate and authorize user access.
Adversaries may generate these cookies in order to gain access to web resources. This differs from Steal Web Session Cookie and other similar behaviors in that the cookies are new and forged by the adversary, rather than stolen or intercepted from legitimate users. Most common web applications have standardized and documented cookie values that can be generated using provided tools or interfaces.[1] The generation of web cookies often requires secret values, such as passwords, Private Keys, or other cryptographic seed values.
Once forged, adversaries may use these web cookies to access resources (Web Session Cookie), which may bypass multi-factor and other authentication protection mechanisms.[2][1][3]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1606 | Forge Web Credentials | This object subtechnique of Forge Web Credentials. |
Groups, software, and campaigns
C0024: SolarWinds Compromise
The SolarWinds Compromise was a sophisticated supply chain cyber operation conducted by APT29 that was discovered in mid-December 2020. APT29 used customized malware to inject malicious code into the SolarWinds Orion software build process that was later distributed through a normal software update; they also used password spraying, token theft, API abuse, spear phishing, and other supply chain attacks to compromise user accounts and leverage their associated access. Victims of this campaign included government, consulting, technology, telecom, and other organizations in North America, Europe, Asia, and the Middle East. This activity has been labled the StellarParticle campaign in industry reporting.[1] Industry reporting also initially referred to the actors involved in this campaign as UNC2452, NOBELIUM, Dark Halo, and SolarStorm.[2][3][4][5][1][6][7][8]
In April 2021, the US and UK governments attributed the SolarWinds Compromise to Russia's Foreign Intelligence Service (SVR); public statements included citations to APT29, Cozy Bear, and The Dukes.[9][10][11] The US government assessed that of the approximately 18,000 affected public and private sector customers of Solar Winds’ Orion product, a much smaller number were compromised by follow-on APT29 activity on their systems.[12]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 351204f15cbb… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Pass The Cookie
Rehberger, J. (2018, December). Pivot to the Cloud using Pass the Cookie. Retrieved April 5, 2019.
Open source URL -
[2]
Volexity SolarWinds
Cash, D. et al. (2020, December 14). Dark Halo Leverages SolarWinds Compromise to Breach Organizations. Retrieved December 29, 2020.
Open source URL -
[3]
Unit 42 Mac Crypto Cookies January 2019
Chen, Y., Hu, W., Xu, Z., et. al. (2019, January 31). Mac Malware Steals Cryptocurrency Exchanges’ Cookies. Retrieved October 14, 2019.
Open source URL -
[4]
mitre-attack T1606.001Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.