Steal Web Session Cookie (T1539) is a Credential Access technique. An adversary takes the session cookie of a web application or service and uses it to sign in as the authenticated user, with no credentials required. MITRE lists Linux, Office Suite, SaaS, Windows and macOS.
After a user signs in, websites commonly keep them authenticated with a session cookie. That cookie is effectively a bearer token. Whoever holds it is treated as the user.
How attackers use it
MITRE gives several facts that make this technique attractive:
- Cookies are often valid for a long time, even when the app is not actively used.
- They can be found on disk, in the memory of the browser process and in network traffic. Other apps on the machine, such as those that authenticate to cloud services, may also keep sensitive cookies in memory.
- Session cookies can bypass some multi-factor authentication protocols, since the cookie is issued after MFA completes.
MITRE describes three broad ways to get them. Malware on the local system can target browser cookies. Adversaries can steal cookies by injecting malicious JavaScript into websites or by tricking victims into running malicious JavaScript in their browser. And open source frameworks such as Evilginx2 and Muraena can collect session cookies through a malicious proxy, an Adversary-in-the-Middle setup used in phishing campaigns.
With a valid cookie in hand, the adversary can then use the Web Session Cookie technique to sign in to the web application.
How to detect it
MITRE's detection strategy covers file, memory and network artifacts:
- Windows: suspicious access to browser cookie storage such as the Chrome cookie database, or memory reads of browser processes, and injection or memory dump utilities that target chrome.exe, firefox.exe or msedge.exe.
- Linux: access to browser cookie files in user profile folders, and suspicious reads of browser memory through /proc or ptrace.
- macOS: unauthorized access to browser cookie paths, and calls such as task_for_pid or vm_read against Safari or Chrome memory.
- Documents with macros or scripts that access browser file paths, read cookie data or try to send session tokens out over HTTP.
- Identity layer: session cookies or tokens used from unusual user agents or locations, token reuse without reauthentication, or attempts to bypass MFA with a previously stolen cookie.
The identity layer is often the most reliable place to catch this. A session that appears from a new country, a new device type or a different network just after normal use is a strong signal. MITRE's Audit mitigation names impossible travel and anomalous behavior as indicators.
How to reduce the risk
MITRE lists five mitigations:
- Audit. Audit authentication activity and logins to catch use of stolen session cookies, including impossible travel and anomalous behavior.
- Software Configuration. Set browsers or tasks to delete persistent cookies regularly, and shorten how long a cookie is valid. That reduces the impact of a stolen cookie and forces attackers to steal more often, which gives defenders more chances to notice.
- Restrict Web Based Content. Restrict or block web content that could be used to pull cookies or credentials from browsers. Disable third party cookies and restrict browser extensions.
- Multi-factor Authentication. Use hardware backed tokens such as FIDO keys, which include the sign in domain in the negotiation and so defeat cookie theft through a proxy. Add Conditional Access policies that only allow sign ins from trusted, managed devices, so a stolen token cannot be reused on an unauthorized device.
- Update Software. Keep browsers, password managers and related software current to reduce flaws that can be used to extract credentials or cookies.
Check your own environment
No special command is needed. Work through these questions with your identity and endpoint teams:
- How long do sessions last in your most important web apps, and can that be shortened?
- Do your high value apps require sign in from managed devices?
- Do admins and finance staff use phishing resistant security keys?
- Do your logs record user agent, device and IP for each session, so you can spot a session that moves?
- Can you revoke all sessions for a user at once, and has anyone practiced it?
- Does endpoint monitoring alert on processes reading browser profile folders?
Quick check
Why does MFA not always stop this technique?
The cookie is issued after MFA has completed. If an adversary steals it, they replay the already authenticated session. Phishing resistant keys and device bound sessions are the controls MITRE points to.
Why shorten cookie lifetime?
A shorter lifetime limits how long a stolen cookie works and means the adversary has to steal again more often, which gives defenders more chances to detect it.
