--- id: CP-048 slug: session-hijacking-cookie-theft-bearer-tokens lang: en title: Session cookie theft and bearer tokens description: A stolen session cookie lets an attacker pass for an employee without a password or second factor. How it works, a real case, reflexes. canonical_url: https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens/ markdown_url: https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens.md publisher: Brain (https://startbrain.io) license: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/) cite_as: Brain, "Session cookie theft and bearer tokens", Cyberpedia, 2026. https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens/ (CC BY 4.0) wing: 1 theme: master_passwords reflex: cr-023 schema: G3 updated: "2026-11-03" translations: en: https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens/ fr: https://startbrain.io/cyberpedia/fr/articles/vol-cookies-session-jetons-porteurs/ de: https://startbrain.io/cyberpedia/de/articles/diebstahl-sitzungscookies-bearer-token/ es: https://startbrain.io/cyberpedia/es/articles/robo-cookies-sesion-tokens-portador/ sources: - "n": 1 title: Steal Web Session Cookie publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1539/ accessed: "2026-11-03" - "n": 2 title: "Use Alternate Authentication Material: Web Session Cookie" publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1550/004/ accessed: "2026-11-03" - "n": 3 title: Session hijacking attack publisher: OWASP url: https://community.owasp.org/attacks/Session_hijacking_attack accessed: "2026-11-03" - "n": 4 title: Steal Application Access Token publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1528/ accessed: "2026-11-03" - "n": 5 title: NIST Special Publication 800-63B publisher: NIST url: https://pages.nist.gov/800-63-3/sp800-63b.html accessed: "2026-11-03" - "n": 6 title: "From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud" publisher: Microsoft url: 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/ published: "2022-07-12" accessed: "2026-11-03" - "n": 7 title: Session Management - OWASP Cheat Sheet Series publisher: OWASP url: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html accessed: "2026-11-03" - "n": 8 title: Browser Session Hijacking publisher: MITRE ATT&CK url: https://attack.mitre.org/techniques/T1185/ accessed: "2026-11-03" --- # Session cookie theft and bearer tokens 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 password [1]. 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. ## In 30 seconds - Where it happens: on the workstation (malware), on a fake site that relays the real sign-in page [1], or in a compromised browser [8]. - 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 factors [2]. - 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 active [2]. ## Straight answers ### What is a session cookie? After a successful sign-in, many web applications use a session cookie as proof of authentication [1]. 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 exchange [3]. ### 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 services [4]. 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 ended [5]. ### 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 authenticated [2]. Microsoft specifies that this is not a flaw in multifactor authentication: the stolen cookie authenticates the attacker whatever the user's sign-in method [6]. ### How long does a stolen cookie stay usable? Cookies often stay valid for a long time, even if the application is not actively used [1]. The attacker can use one as long as the cookie is active [2]. 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 open [7]. ## Inside the attacker's head 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 services [1]. 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 do [2]. 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 account [4]. 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 anything [4]. ## What you see on screen 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 address [6]. After the password is entered, the victim is redirected to the legitimate page, and the attack continues in the background [6]. Here is a neutralized illustration of the address of a fake relay site. It is invented for the example. ```text 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 side [6]. 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 target [6]. ## Under the hood Three theft routes are described by the sources cited here. - The stealer malware: malicious software targets the cookies of the browsers present on the workstation [1]. Some extract the session cookie and send it to the attacker's server [1]. - 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 cookie [6]. Free tools such as Evilginx2, Modlishka and Muraena automate this process [6]. - 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 intranet [8]. This technique can also bypass two-factor authentication [8]. It may require particular privileges on the workstation [8]. Why does replay work? The cookie is the proof of sign-in: the server does not re-check the password on every page [6]. NIST SP 800-63B accepts other methods of securely identifying the device, including mutual TLS and token binding [5]. 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-Agent [7]. 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 hours [7]. NIST SP 800-63B, superseded since 1 August 2025 by SP 800-63-4, required that session secrets be erased or invalidated at sign-out [5]. ## Case files ### 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 2021 [6]. The attackers used relay sites to steal passwords and hijack the victim's session, even if multifactor authentication was enabled [6]. 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 page [6]. The victim entered their credentials, was redirected to the legitimate page office.com, and the attacker, meanwhile, was authenticated in their name [6]. 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 claim [6]. 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 nothing [6]. Finally, they deleted their own replies from the sent and deleted items folders [6]. Microsoft recommends phishing-resistant authentication (FIDO 2.0 or certificates) and conditional access policies, which evaluate every attempt to use a stolen cookie [6]. ## What you do 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 side [7]. - 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 sessions [8]. - Check the address before entering your password: the address is the only visible difference between a fake relay site and the real one [6]. - Report any doubt to IT support without delay: as long as the session is active, the attacker can use it [2]. On the company side, MITRE cites configuring browsers to regularly delete persistent cookies [2]. ## 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) --- Original source: Cyberpedia, the public cybersecurity and AI encyclopedia published by Brain. Canonical version: https://startbrain.io/cyberpedia/en/articles/session-hijacking-cookie-theft-bearer-tokens/ You may reuse this text freely under the CC BY 4.0 license (https://creativecommons.org/licenses/by/4.0/), provided you credit "Brain, Cyberpedia" with a link to the canonical URL above.