MITRE ATT&CK T1539 Steal Web Session Cookie Guide

A stolen session cookie lets an intruder act as a signed-in user without a password and without passing MFA again, because the cookie is the proof that authentication already happened. MITRE ATT&CK records this as T1539 Steal Web Session Cookie in the Credential Access tactic (ATT&CK v20), across Windows, macOS, Linux, SaaS and Office Suite platforms. This page is the technique reference in our ATT&CK series: what the technique covers, where defenders can see it, the mitigations ATT&CK maps to it, and how to respond when a session is stolen. It is written for detection engineers, identity teams and incident responders, and deliberately contains no attack procedures. For the broader discipline of protecting sessions, read the Session Hijacking and Cookie Theft Guide first; this page goes deeper on the ATT&CK mapping, detection analytics and response.

Key takeaways

Theft and reuse are two techniques. T1539 is the theft; replaying the cookie to sign in is T1550.004 Web Session Cookie (Lateral Movement), so detection needs both endpoint and identity provider telemetry.
MFA does not stop replay. ATT&CK notes that session cookies can bypass some MFA protocols, because the cookie is issued after MFA completes.
Two theft routes dominate. Infostealer malware reading browser cookie stores on the endpoint, and adversary-in-the-middle (T1557) phishing proxies that capture the cookie during sign-in.
Binding beats lifetime. Shorter sessions limit the damage, but device-bound tokens and phishing-resistant authenticators remove the value of a copied cookie.
Response means revocation, not a password reset. Resetting the password does not always kill live sessions; revoke refresh tokens and sessions explicitly and confirm in the logs.

What T1539 covers in ATT&CK v20

ATT&CK describes T1539 as an adversary stealing web application or service session cookies and using them to access web applications or internet services as an authenticated user without needing credentials. It notes that cookies are often valid for an extended period even when the application is not in use, and that they can be found on disk, in browser process memory and in network traffic. Other applications on the device, such as desktop apps that authenticate to cloud services, may also hold authentication cookies in memory.

Attribute	ATT&CK v20 value	Defender implication
Technique	T1539 Steal Web Session Cookie	No sub-techniques; one detection strategy covers all platforms
Tactic	Credential Access	Treat a cookie like a credential in your incident scope
Platforms	Linux, macOS, Office Suite, SaaS, Windows	Endpoint and SaaS logs both matter
Follow-on technique	T1550.004 Web Session Cookie	Replay shows up in identity provider and SaaS sign-in logs
Related techniques	T1557 Adversary-in-the-Middle, T1185 Browser Session Hijacking, T1555.003 Credentials from Web Browsers, T1528 Steal Application Access Token	Map controls once across the cluster rather than per technique
Detection strategy	Detection of Web Session Cookie Theft via File, Memory, and Network Artifacts	Analytics for Windows, Linux, macOS, Office Suite and SaaS

Theft routes defenders should plan for

Endpoint malware: ATT&CK cites several malware families that read browser cookie stores on the local system. Infostealer logs are then traded or reused. See the Infostealer Logs and Session Token Abuse Guide.
Adversary-in-the-middle phishing: a malicious reverse proxy relays the real sign-in page and captures the session cookie once the user completes MFA. See the AiTM Phishing Guide.
Malicious script in the browser: ATT&CK notes injected JavaScript on websites and user execution, where victims are tricked into running script in their own browser.
Leaked artefacts: cookies captured in HAR files, debug logs or support tickets. See the HAR Files and Session Token Leakage Guide.

Groups ATT&CK records using T1539

ATT&CK v20 links T1539 to a range of state and criminal groups, which shows the technique is mainstream rather than niche. Examples include APT42 and Kimsuky (custom malware stealing browser cookie data), Sandworm Team (information stealer malware), Scattered Spider (retrieving browser cookies via an infostealer), Star Blizzard (phishing proxies that capture session cookies), and LuminousMoth, Lotus Blossom and Evilnum (cookie theft from browsers). See the Kimsuky Threat Actor Profile and the Charming Kitten (APT35) Threat Actor Profile for related actor context.

Detection

The ATT&CK detection strategy for T1539 splits into endpoint analytics (the theft) and SaaS analytics (the reuse). Most organisations get better return from the identity side first, because it covers both malware and proxy phishing, then add endpoint coverage for high-value users.

Platform	What to watch (from the ATT&CK v20 analytics)	Log source	Tuning notes
Windows	Non-browser processes reading browser cookie databases; memory access or injection into browser processes	Sysmon Event ID 10 (process access), Sysmon Event ID 2, Security Event ID 4688	Maintain a list of browser processes and cookie store paths; allow-list backup and EDR agents
Linux	Reads of browser cookie files by unexpected processes; ptrace or reads of browser process memory	auditd SYSCALL records	Correlate a cookie read with outbound upload in a short time window
macOS	File opens on browser cookie databases; task_for_pid or vm_read against browser processes	Unified log, file system usage events	Keep a per-browser path list as browsers change storage locations
Office Suite	Macros or VBA that touch browser file paths or post cookie data over HTTP	Microsoft 365 unified audit log, Sysmon	Block untrusted macros first; the analytic then catches the residue
SaaS and identity provider	Session reuse from an unusual user agent, IP, ASN or location; token reuse without reauthentication	Identity provider sign-in logs, SaaS audit logs	Score user agent and geolocation deviation per user; set a maximum delta between issuance and reuse

Identity-side signals that work

Session context change: the same session identifier or refresh token used from a new IP, ASN, country or device fingerprint mid-session. OWASP lists mid-session changes in location or user agent as hijacking indicators, while noting they are unreliable alone behind NAT and proxies.
No preceding interactive sign-in: access from a new location with no matching authentication event, which suggests replay rather than login.
Impossible travel and hosting ranges: ATT&CK's Audit mitigation (M1047) calls out impossible travel and anomalous behaviour as signs of stolen session cookies or tokens.
Post-replay behaviour: new inbox rules, MFA method registration, OAuth consent or mass downloads soon after a context change. These raise severity sharply.
User reports: security notification emails about new sign-ins, with a report button feeding the SOC.

Metrics

Percentage of high-value users on devices that send endpoint cookie store access telemetry.
Median time from a session context-change alert to session revocation.
Percentage of sign-ins to critical apps protected by device-bound tokens or phishing-resistant authenticators.
Number of applications with server-side idle and absolute timeouts configured and verified.
Infostealer exposure matches (corporate domains in stealer logs) per month, and the share closed with session revocation within 24 hours.

Prevention and hardening

ATT&CK maps six mitigations to T1539. The table turns each into a concrete control and adds the binding controls that have matured since the technique was first written.

ATT&CK mitigation	What ATT&CK says	Practical control
M1032 Multi-factor Authentication	Hardware tokens that include the login domain in the protocol prevent cookie theft through proxy methods; restrict sign-in to trusted devices	FIDO2 passkeys or security keys for workforce sign-in; Conditional Access requiring compliant or managed devices
M1054 Software Configuration	Regularly delete persistent cookies and minimise how long a cookie is viable	Server-side idle and absolute timeouts; browser policies that clear cookies on exit for shared or high-risk devices
M1047 Audit	Audit authentication activity; monitor impossible travel and anomalous session use	Identity provider and SaaS logs into the SIEM with session context analytics
M1021 Restrict Web-Based Content	Restrict content that could extract cookies; restrict extensions and third-party cookies	Extension allow-listing, script and download controls. See the Browser Security Hardening Guide
M1051 Update Software	Keep browsers and password managers current	Managed browser update channels with short deadlines
M1017 User Training	Spot wrong domains on sign-in pages; never paste untrusted script into the browser	Short, specific training plus a one-click report route

Binding sessions to the device

Device-bound tokens: Microsoft Entra Token Protection is a Conditional Access session control that accepts only device-bound sign-in session tokens, such as the Primary Refresh Token, for supported applications. Microsoft describes it as reducing replay rather than guaranteeing prevention, and recommends a pilot group, report-only mode and log analysis before enforcement.
Device Bound Session Credentials: a browser approach that ties a session to a key held on the device, so an exported cookie stops working. See the Device-Bound Session Credentials (DBSC) Guide.
Browser cookie encryption: Google introduced App-Bound Encryption for cookies in Chrome 127 on Windows, tying decryption to the app identity so malware running as the user needs elevation or code injection, which is noisier. Google notes it does not work correctly with roaming profiles, where the ApplicationBoundEncryptionEnabled policy may be needed, and that Chrome logs Event ID 257 in the Application log when verification fails.
Least privilege on endpoints: because elevation weakens app-bound protections, preventing users from running downloads as administrator raises the cost of cookie theft. See the Endpoint Privilege Management Guide.

Application-side session hygiene

For applications you build, the OWASP Session Management Cheat Sheet recommends the __Host- cookie prefix with Secure, HttpOnly and an explicit SameSite value, session ID regeneration after login and privilege change, server-side enforcement of idle and absolute timeouts (it suggests roughly 2 to 5 minutes idle for high-value applications and 15 to 30 minutes for low-risk ones), and server-side invalidation on logout. HttpOnly blocks script access but does nothing against malware reading the cookie store, so it complements rather than replaces binding. See the Cookie Security Guide.

Choosing controls by organisation size

Small organisations: start with phishing-resistant authentication for administrators and finance, managed browser updates, extension allow-listing and the identity provider's built-in risky sign-in alerts.
Large organisations: add device-bound token enforcement for supported apps, continuous access evaluation, endpoint analytics on cookie store access and stealer log monitoring, and automate revocation from the SIEM.

Response when a session is stolen

Revoke, then verify: revoke all refresh tokens and sessions for the user in the identity provider and in each affected SaaS application, then confirm in the sign-in logs that the suspicious context stops. In Microsoft Entra, continuous access evaluation evaluates events such as an administrator revoking refresh tokens or a password reset for supported services, with Microsoft noting propagation can take up to 15 minutes.
Scope the replay: list every sign-in and API call from the suspicious session context, and check for persistence such as inbox rules, new MFA methods, OAuth grants and API tokens created during the session. See the OAuth Token Theft Incident Playbook.
Clean the source: if the theft came from the endpoint, isolate and reimage the device and treat every saved browser credential and session on it as compromised, not just the one you detected.
Reset credentials where needed: reset the password and re-register MFA if the stealer could also have captured credentials (T1555.003).
Preserve evidence: keep identity provider sign-in logs, SaaS audit logs and endpoint telemetry before retention windows close.
Close the gap: move the affected user group to device-bound or phishing-resistant controls and shorten session lifetimes for the targeted application.

Where identity fits

Session cookies are bearer credentials, and the same logic applies to non-human identities: CI runners, automation accounts and desktop sync clients hold long-lived session and access tokens that are just as replayable. Include those tokens in inventories, prefer short-lived workload credentials, and monitor their use from new networks the same way you monitor users. See the MITRE ATT&CK T1078 Valid Accounts Guide and the ITDR Guide.

Framework mapping

Framework	Reference	Relevance to T1539
MITRE ATT&CK	T1539, T1550.004, T1557, T1185	Theft, replay and capture routes
NIST SP 800-53 Rev. 5	SC-23 Session Authenticity; AC-12 Session Termination; IA-2 Identification and Authentication	Protect session integrity, enforce termination, strengthen authentication
NIST SP 800-53 Rev. 5	AU-6 Audit Record Review, Analysis, and Reporting	Review session anomalies
NIST CSF 2.0	PR.AA (Identity Management, Authentication, and Access Control); DE.CM (Continuous Monitoring)	Authentication strength and monitoring of session use
OWASP ASVS 5.0	V7 Session Management	Application-side cookie and timeout controls

Common failure patterns

Resetting the password and closing the ticket: live sessions and refresh tokens survive in many applications unless revoked explicitly.
Counting push MFA as protection: push, SMS and OTP do not stop proxy capture; only origin-bound authenticators do.
Revoking only in the identity provider: SaaS applications with their own sessions keep the intruder signed in until they expire.
Weeks-long sessions on admin consoles: convenience settings on high-value applications extend the useful life of a stolen cookie.
Cleaning one browser: stealers take everything, so all saved sessions and passwords on the device need rotating.

Practitioner checklist

Map T1539, T1550.004 and T1557 together in your coverage matrix and assign an owner.
Stream identity provider and critical SaaS sign-in logs to the SIEM with session context analytics.
Deploy endpoint analytics for non-browser access to cookie stores on high-value user devices.
Require phishing-resistant authenticators for administrators and finance users.
Pilot device-bound token enforcement in report-only mode, then enforce for supported apps.
Set server-side idle and absolute timeouts on admin consoles and sensitive applications.
Allow-list browser extensions and keep managed browsers on short update deadlines.
Write and test a session revocation runbook covering the identity provider and each major SaaS app.

MITRE ATT&CK T1539 Steal Web Session Cookie: Detect, Prevent and Respond to Cookie Theft