Cyberpediaby Brain
ENDEFR

Session cookie theft and bearer tokens

A stolen session cookie lets an attacker pass for an employee without a password or second factor. How it works, a real case, reflexes.

In 30 seconds

Where it happens
On the workstation (malware), on a fake site that relays the real sign-in page1, or in a compromised browser8.
What the attacker wants
To take over a session that is already open, read messages and act in the victim's name, bypassing some second factors2.
The reflex
Sign out of services when finished, revoke your sessions if in doubt, close browser sessions regularly.
If it has already happened
Tell IT support without delay, because the stolen session stays usable as long as it is active2.

What it is

When an employee signs in to their mailbox or an online tool, the service hands over a small piece of identification, most often a cookie, which proves that the employee is already authenticated. If an attacker gets hold of that piece, they can walk in as the victim, without knowing the password1.

On the employee's side, usually nothing is visible: the session carries on, and so does the work. This page explains where the theft comes from, what an attacker does with it and what each person can do to reduce the risk.

Straight answers

What is a session cookie?

After a successful sign-in, many web applications use a session cookie as proof of authentication1. The web protocol does not, by itself, remember who is who from one request to the next: the server therefore sends the browser a token, which the browser then presents at every exchange3.

What is an access token, and how does it differ from a cookie?

An access token is used to make authorized requests on behalf of a user or a service. It is common in online applications (SaaS) and cloud services4. Both objects share the same weakness: whoever presents one is accepted as the person who obtained it. NIST SP 800-63B, a version superseded since 1 August 2025 by SP 800-63-4, also stated that the presence of an OAuth access token must not be interpreted as the presence of the user in the absence of other signals, and that such a token may remain valid well after the authentication session has ended5.

Doesn't my second factor protect me?

It protects the sign-in, not the session that follows. MITRE states that this technique bypasses some multifactor authentication protocols, since the session is already authenticated2. Microsoft specifies that this is not a flaw in multifactor authentication: the stolen cookie authenticates the attacker whatever the user's sign-in method6.

How long does a stolen cookie stay usable?

Cookies often stay valid for a long time, even if the application is not actively used1. The attacker can use one as long as the cookie is active2. OWASP also notes that an inactivity timeout does not limit an attacker who has taken over the session: they can generate activity to keep it open7.

1Inside the attacker's head1 min

The attacker looks for a reusable item rather than a secret to guess. Cookies are found on disk, in browser memory and in network traffic to remote systems. Other applications on the workstation may also keep authentication cookies in memory, for example those that connect to cloud services1.

Once the cookie is obtained, the attacker imports it into a browser they control. They then use the site as the user, as long as the session is active. They can view sensitive information, read emails or do whatever the victim's account is allowed to do2.

For the access token, one described route is phishing: the attacker registers a rigged application and sends a link to get the victim to grant it access. Once the token is granted, the application can obtain potentially long-lasting access to the account4. Access tokens sometimes have a limited lifetime, but the attacker can also steal a refresh token, which gives them new access tokens without asking the user for anything4.

2What you see on screen1 min

The employee sees nothing: alerts may exist on the administrator's side (see below). In the case of a fake relay site (described below), the page looks exactly like the real one: the only visible difference is the address6. After the password is entered, the victim is redirected to the legitimate page, and the attack continues in the background6.

Here is a neutralized illustration of the address of a fake relay site. It is invented for the example.

Excerpt
Illustration (fictitious address, neutralized):
hxxps://login[.]exemple-connexion[.]invalid/
[page identical to the real sign-in page, only the address differs]

A few indirect signs exist. If the attacker signs in while the victim is working, "impossible travel" alerts may appear on the administrator's side6. Unknown inbox rules are another sign: in the case described below, the attacker created one so that the victim would not see the replies from their target6.

3Under the hoodIT teams2 min

Three theft routes are described by the sources cited here.

  • The stealer malware: malicious software targets the cookies of the browsers present on the workstation1. Some extract the session cookie and send it to the attacker's server1.
  • The fake relay site: in the so-called adversary-in-the-middle attack, the attacker places a proxy server between the user and the targeted site. It thus captures the password and the session cookie6. Free tools such as Evilginx2, Modlishka and Muraena automate this process6.
  • The compromised browser: an attacker can inject software into a browser to inherit the user's cookies, HTTP sessions and client certificates, then use them to enter an authenticated intranet8. This technique can also bypass two-factor authentication8. It may require particular privileges on the workstation8.

Why does replay work? The cookie is the proof of sign-in: the server does not re-check the password on every page6. NIST SP 800-63B accepts other methods of securely identifying the device, including mutual TLS and token binding5. OWASP recommends binding the session identifier to other properties of the client, such as the IP address or the User-Agent. It acknowledges, however, that a skilled attacker can get around this check, for example by sharing the same network as the victim or by copying the User-Agent7.

On durations, OWASP cites common inactivity timeouts of 2 to 5 minutes for high-value applications and 15 to 30 minutes for low-risk applications. For an office worker who uses an application all day, it cites an absolute timeout of 4 to 8 hours7. NIST SP 800-63B, superseded since 1 August 2025 by SP 800-63-4, required that session secrets be erased or invalidated at sign-out5.

4Case filesReal cases2 min

Phishing campaign by fake relay site against Microsoft 365 (documented on 12 July 2022)

On 12 July 2022, Microsoft published the analysis of a large-scale campaign. According to its data, it attempted to target more than 10,000 organizations since September 20216. The attackers used relay sites to steal passwords and hijack the victim's session, even if multifactor authentication was enabled6.

In one of the observed waves, an email with an HTML attachment announced a voice message. The attachment displayed a fake download bar, then redirected to a relay site built with Evilginx2, which reproduced the organization's sign-in page6. The victim entered their credentials, was redirected to the legitimate page office.com, and the attacker, meanwhile, was authenticated in their name6.

What followed aimed at payment fraud. According to Microsoft, it sometimes took only five minutes between the theft and the start of the fraud. The attacker used the stolen cookie to enter the online mailbox, sometimes with a cookie that already carried the multifactor authentication claim6. They then looked for payment-related exchanges, deleted the initial phishing email and created an inbox rule that archived and marked as read the replies from their target, so that the victim would notice nothing6. Finally, they deleted their own replies from the sent and deleted items folders6.

Microsoft recommends phishing-resistant authentication (FIDO 2.0 or certificates) and conditional access policies, which evaluate every attempt to use a stolen cookie6.

5What you do1 min

These actions come from the sources cited here. Their effect is to reduce the duration or the reach of a stolen session, not to guarantee that one will not be stolen.

  • Sign out of services explicitly when finished. OWASP states that closing the browser does not reliably force a sign-out and recommends an explicit sign-out, with timeouts on the server side7.
  • Revoke your sessions if a doubt arises (infected workstation, suspicious sign-in page). The sources cited here do not detail the procedure: the company's IT support gives it.
  • Close the sessions open in the browser regularly. MITRE recommends regularly closing all browser sessions8.
  • Check the address before entering your password: the address is the only visible difference between a fake relay site and the real one6.
  • Report any doubt to IT support without delay: as long as the session is active, the attacker can use it2.

On the company side, MITRE cites configuring browsers to regularly delete persistent cookies2.

Fact sheet

Identifier
CP-048
Wing
1. Attacks and techniques
Brain skill
Mastering Passwords & MFA (master_passwords)
Brain reflex
cr-023
Diagram
G3 · System & Protocol Anatomy
Languages
de, en, fr
Sources
8 sources checked on 3 November 2026
Sources8 sources
  1. MITRE ATT&CK, “Steal Web Session Cookie”. https://attack.mitre.org/techniques/T1539/ (accessed 3 November 2026)
  2. MITRE ATT&CK, “Use Alternate Authentication Material: Web Session Cookie”. https://attack.mitre.org/techniques/T1550/004/ (accessed 3 November 2026)
  3. OWASP, “Session hijacking attack”. https://community.owasp.org/attacks/Session_hijacking_attack (accessed 3 November 2026)
  4. MITRE ATT&CK, “Steal Application Access Token”. https://attack.mitre.org/techniques/T1528/ (accessed 3 November 2026)
  5. NIST, “NIST Special Publication 800-63B”. https://pages.nist.gov/800-63-3/sp800-63b.html (accessed 3 November 2026)
  6. Microsoft, “From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud”, 12 July 2022. https://www.microsoft.com/en-us/security/blog/2022/07/12/from-cookie-theft-to-bec-attackers-use-aitm-phishing-sites-as-entry-point-to-further-financial-fraud/ (accessed 3 November 2026)
  7. OWASP, “Session Management - OWASP Cheat Sheet Series”. https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html (accessed 3 November 2026)
  8. MITRE ATT&CK, “Browser Session Hijacking”. https://attack.mitre.org/techniques/T1185/ (accessed 3 November 2026)

Cite this article

Brain, “Session cookie theft and bearer tokens”, Cyberpedia, 2026. https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens/

BibTeX 
@misc{brain_cp048_en_2026,
  author = {Brain},
  title = {Session cookie theft and bearer tokens},
  year = {2026},
  howpublished = {Cyberpedia},
  url = {https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens/},
  note = {CC BY 4.0}
}
CC BY 4.0 licence