Session Hijacking: Why a Stolen Browser Cookie Shouldn't Unlock Your Databases
On December 16, 2022, malware compromised a CircleCI engineer's laptop, bypassing the company's antivirus software. The malware stole a session cookie from the engineer's 2FA-backed SSO session, which let the attacker "impersonate the targeted employee in a remote location" and move into production systems. From there, they exfiltrated data from a subset of CircleCI's databases, including customer environment variables, tokens and keys.
The engineer's MFA did exactly what it was designed to do, but it made no difference.
That's session hijacking, and it's one of the cleanest ways around the security control you probably trust most.
TABLE OF CONTENTS
2. Why a Stolen Cookie is Worse than a Stolen Password
3. The Question that Matters: What can a Stolen Session Reach?
4. How Mamori MFA on Every Rsource Access Shuts Down Cookie Replay
5. What If the Attacker is on the User’s Laptop
No Cost, Big Protection.
Download Mamori Freemium and begin securing your network, users, and databases with zero-trust.
What is Session Hijacking?
Session hijacking, also called cookie hijacking, is "the exploitation of a valid computer session" to gain unauthorized access to data, information, or services. It is a form of MITM (man-in-the-middle) attack. It's the theft of the cookie or token a server uses to recognize you after you log in.
Here's why that matters. When you sign in and approve your MFA prompt, the application doesn't ask you to authenticate again on every click. It gives your browser a session cookie instead. Until that cookie expires, anyone holding it looks like you, from any computer.
Attackers steal session cookies in 4 main ways:
Session fixation. The attacker plants a known session ID on the victim, for example through a link in an email, then waits for the victim to log in with it.
Session side jacking. The attacker sniffs network traffic and lifts cookies that are sent unencrypted, often on public Wi-Fi. In 2010, a Firefox extension called Firesheep made this point-and-click easy against sites like Flickr, Amazon and Windows Live. That pushed Facebook and Twitter to adopt HTTPS.
Cross-site scripting (XSS). The attacker gets malicious code to run in the victim's browser as if it came from a trusted site, and the code reads the cookie.
Malware and physical access. Malware copies the browser's cookie files straight off the device, or someone with access to the machine pulls session keys from files or memory.
HTTPS has mostly closed off side jacking. The fourth method is now the big one.
Why a Stolen Cookie is Worse than a Stolen Password
A stolen password still runs into your MFA prompt. A stolen session cookie doesn't, because MFA already happened. The attacker inherits a session that's been fully verified and replays it from their own machine.
Three trends make this worse.
Infostealer malware operates at industrial scale. Between March 16 and May 16, 2025, Microsoft identified more than 394,000 Windows computers infected with a single infostealer, Lumma Stealer. Lumma takes data from web browsers, crypto wallets, chat apps and user files. That's one malware family over two months.
Attackers log in instead of breaking in. In CrowdStrike's 2026 Global Threat Report, 82% of detections were malware-free. Adversaries used valid credentials, trusted identity flows and approved SaaS integrations to move between systems. A hijacked session is about as trusted as an identity flow gets.
Your identity provider can be the source of the leak. Between September 28 and October 17, 2023, an attacker got into Okta's support case management system. Customers had uploaded troubleshooting files (HAR files) to it, and some of those files contained session tokens. Files from 134 customers were accessed, and the attacker hijacked sessions belonging to 5 of them.
Then there's the blast radius. One SSO session cookie can open every application behind that SSO. In the CircleCI incident, the chain ended at production databases.
The standard textbook defenses are TLS encryption, long random session keys, regenerating the session ID after login, checking that the user's IP stays the same and rotating cookies. Two of them matter most here.
Session hijacking depends on two gaps: MFA that only happens at login, and no check that the cookie is still being used from the IP that started the session.
Close both and a stolen cookie becomes useless. The trouble is that these are controls each application team has to build on its own, and most never do. None of them stop malware on a legitimate user's laptop from copying a valid cookie in the first place.
The Question that Matters: What can a Stolen Session Reach?
At Mamori.io, we assume your security parameters have already been breached. We believe "Every password is already compromised or will be compromised one day." Now, we believe the same applies to sessions. At some point, someone in your organization will run an infostealer, use a device they shouldn't, or upload a file with a live token in it.
So stop asking only "how do we stop cookie theft?" Also ask: when a session is stolen, what can the attacker reach with it?
If the answer is "everything the user could reach," your MFA is protecting a single moment, the login, while attackers target everything that comes after it.
How Mamori's MFA on Every Resource Access Shuts Down Cookie Replay
Mamori moves MFA from the front door to every resource you care about.
A stolen cookie is blocked from an unknown IP. Mamori checks that a session's cookie is being used from the client IP that started the session. If the cookie shows up from a different IP, Mamori blocks it. That's the exact move the CircleCI attacker made: steal the session, then impersonate the employee in a remote location. With Mamori, that replay fails at the first request.
MFA on every resource, so the real user gets the prompt. Mamori enforces MFA on every resource access, not only at login. The first time anyone reaches a resource, they must complete MFA. If an attacker requests a resource with a stolen cookie, the MFA prompt goes to the real user's device, not the attacker's. The cookie gets the attacker nowhere. MFA applies to any TCP/IP address, so it covers servers, databases, and any application sitting on a server, such as a firewall admin console, with no code changes to the application.
Every device is registered. With Mamori's zero trust network module (M4IP), every device that accesses the network must be registered, so unknown machines don't get in at all.
Idle access expires by your policy. When access to a resource sits idle for longer than the period your policy sets, Mamori requires MFA again. You decide how long that window is.
MFA alone doesn't grant access. Each TCP/IP address has to be on the accessible list for the user's role and ID, based on preset customizable policies. Passing MFA gets a user to the resources their role allows, nothing more.
Databases require individual identity. Mamori's DBPAM (Database Privileged Access Management) replaces shared database credentials with SSO and MFA, so every database session is tied to a named person.
What If the Attacker is on the User's Own Laptop?
This is the case most vendors skip. If malware is running on a legitimate user's registered device, and that user is actively connected to a resource, the attacker can reach that same resource. Their requests come from the same machine and the same IP, so the IP check can't tell them apart. No MFA scheme on the market changes that.
What Mamori changes is how far that attacker can go:
No lateral movement. The compromised endpoint can reach only the few TCP/IP addresses that user and device are entitled to. Everything else on the network stays off-limits.
No network scanning. The endpoint can't scan the network, so the attacker can't map your servers and databases to plan the next hop.
MFA for every other resource. Anything the user isn't actively using still needs a fresh MFA approval on the user's own device. An unexpected prompt is a signal your security team can immediately act on.
Database access limited to the user's entitlements. Even inside an active database session, the attacker sees only the tables, rows and columns that user's role allows. What the user can do with those data (edit, download, delete, etc.) is limited to that compromised user’s role.
Just-in-time (JIT) approval not just for data-access. Access to data can be gated with a JIT request that someone else has to approve. Data operations such as update, delete, drop tables, etc. can also be gated with JIT request. The attacker can't approve it themselves.
In addition, Mamori has SQL Firewall, which blocks bulk extraction queries and records sessions by identity. That means a compromised laptop stops being the master key of the attacker, but instead, a narrow, closely monitored and recorded session.
The table below shows how a login-only MFA compares with Mamori:
| Stolen SSO session cookie | Login-only MFA | Mamori MFA on every resource access |
|---|---|---|
| Replayed from the attacker's computer | Works | Blocked: different IP, and the MFA prompt goes to the real user |
| Attacker on the user's own laptop | Reaches everything the user can | Only what the user is actively using, within their entitlements |
| Lateral movement and network scanning | Often possible | Blocked |
| Sensitive data | Reachable with standing access | Requires an elevated JIT approval |
| Bulk data extraction | Undetected until too late | Can be blocked by SQL Firewall and flagged in real time |
A 5-Point Checklist Against Session Hijacking
Assume session cookies will be stolen, and map what data each user has access to.
Require MFA on every access to servers, admin consoles, databases, and data, not only at login.
Register every device that touches your network so replayed sessions from unknown devices will fail.
Limit each device to the IP addresses its user is entitled to, and block lateral movement and scanning.
Put sensitive data behind just-in-time approval, and record every database session by identity.
Frequently Asked Questions
What is session hijacking?
Session hijacking, also called cookie hijacking, is the exploitation of a valid computer session to gain unauthorized access to information or services. After you log in and approve your MFA prompt, the application gives your browser a session cookie so you don't have to authenticate on every click. Until that cookie expires, anyone holding it looks like you, from any computer.
How do attackers steal session cookies?
There are 4 main methods: session fixation, session side jacking (sniffing unencrypted traffic, often on public Wi-Fi), cross-site scripting (XSS), and malware or physical access to the device. HTTPS has mostly closed off side jacking, so malware is now the big one. Between March 16 and May 16, 2025, Microsoft identified more than 394,000 Windows computers infected with a single infostealer, Lumma.
Can session hijacking bypass MFA?
Yes. A stolen password still runs into your MFA prompt, but a stolen session cookie doesn't, because MFA already happened. In December 2022, malware stole a session cookie from a CircleCI engineer's 2FA-backed SSO session, letting the attacker impersonate the employee from a remote location and exfiltrate data from production databases. The MFA worked as designed, and it made no difference.
How do you prevent session hijacking?
Session hijacking depends on two gaps: MFA that only happens at login, and no check that the cookie is still being used from the IP that started the session. Close both by requiring MFA on every access to servers, databases and admin consoles, and by binding sessions to the IP that started them. Then limit the damage of any stolen session by eliminating shared database credentials, replacing standing privileges with time-limited access, and keeping endpoint protection in place.
How does Mamori stop stolen cookies from being used?
Mamori blocks any use of a session cookie from a different IP, and it enforces MFA on every resource access, not only at login. If an attacker requests a resource with a stolen cookie, the MFA prompt goes to the real user's device, so the cookie gets the attacker nowhere. Even if malware sits on the user's own laptop, it can reach only what that user is actively using, can't scan the network or move laterally, and needs an approved just-in-time request to reach sensitive data.
Stop Protecting Doors. Start Protecting Vaults.
Mamori adds MFA at every resource and device registration on top of them, with no agents and no application changes. A stolen cookie stops working from someone else's computer, and a compromised laptop can reach only what its user is entitled to.
If your organization has under $10 million in revenue or 20 staff or fewer, you'd qualify for Mamori freemium. It gives you the full platform, including MFA on every resource access and zero trust network access, for free (yes, completely free). That's part of why more than 800 organizations worldwide have downloaded it as of Q3 2026.
For larger environments, especially ones where MFA stops at the SSO login, schedule a sales call with us.
CircleCI's incident report is worth the ten-minute read. They were open about how a single stolen cookie led to their production databases, and that openness is why the rest of us can learn from it. Our takeaway: MFA can't stop at the login. It has to sit in front of every resource.
