Beyond the Login: The Mechanics of Session Cookie Theft

In February 2024, a finance employee at the engineering firm Arup received a video call. On the call were his CFO and several colleagues. They discussed an urgent, confidential transaction. He transferred $25.6 million. Every person on that call was AI-generated. But the deepfakes were not the attack — they were the final step. Before any of that happened, the attacker already had access to the accounts they needed. That access did not come from breaking a password or bypassing MFA. It came from something stolen silently, weeks earlier, from a compromised machine.

This is not a story about deepfakes. It is a story about a gap in how authentication actually works — one that most organizations have not closed, and that most individuals do not know exists.

The Gap MFA Does Not Cover

Multi-factor authentication has become the default defense against unauthorized account access. Enable MFA, and even if your password is stolen, an attacker cannot log in without the second factor. This is true. It is also incomplete.

MFA secures the login event. It does not secure the session.

When you successfully authenticate — password entered, second factor verified — the server issues a session token. Think of it as a temporary badge: it proves you already cleared security, so you do not have to do it again with every page load. Your browser stores this token and presents it automatically with every subsequent request. The server trusts it completely.

Steal the token, and you are inside the account as if you authenticated yourself. No password prompt. No MFA prompt. The authentication already happened — to the server, you are the legitimate user. This is the gap. And it is exactly what infostealer malware is built to exploit.

Where the Keys Are Kept

This applies specifically to Chromium-based browsers on Windows — Chrome, Edge, and Brave, collectively used by over 70% of desktop users. On Windows, session tokens are stored at:

%LocalAppData%\Google\Chrome\User Data\Default\Network\Cookies

This is a standard SQLite database. The tokens inside are encrypted, which sounds reassuring — but the encryption is a three-layer system, and each layer depends on the one before it:

The master key. Chromium generates a randomized AES-256 encryption key and stores it in a file called Local State in the same directory.
DPAPI locks the master key. That AES key is itself encrypted using Windows DPAPI — the Data Protection API — which ties decryption to the active Windows user account.
The cookies are encrypted with the master key. Each session token in the database is encrypted using the AES key from step one.

The design is solid — unless an attacker already has code running as you. Any process operating under your Windows login can call the same DPAPI function your browser uses. Windows will comply, because as far as the operating system is concerned, you asked. It has no way to distinguish your browser making that request from malware making the same one.

Once malware is on your machine, the rest of the sequence is mechanical:

Malware executes under your user account. The most common delivery method is a file that looked legitimate — pirated software, a fake browser update, a "fix" you were instructed to paste into a terminal. Once it runs as you, it has everything it needs.
It calls the DPAPI function to retrieve the master decryption key. The OS hands it over.
It queries the cookie database for high-value session tokens — GitHub, AWS, banking portals, corporate SSO.
It decrypts each token and packages everything into a compressed archive.
It sends the archive to a remote server.

The entire process typically takes under 60 seconds. There is no visible sign anything happened.

The Malware Families Doing This at Scale

Infostealer malware is sold as a service — criminal groups rent access to the tools, keep the infrastructure running, and take a cut of what their customers steal. Three families dominate the market.

RedLine is the most widely deployed. It communicates over standard HTTP and HTTPS — making its traffic look identical to normal web browsing. It sweeps comprehensively: browser credentials, crypto wallet files, VPN configurations, and session tokens across all installed browsers.

LummaC2 is built for evasion. It resolves its function calls dynamically at runtime, which means automated analysis tools that look for known patterns often miss it entirely. In May 2025, the DOJ and Microsoft seized over 2,300 Lumma-associated domains in a coordinated takedown. The infrastructure was operational again within weeks. A government-level disruption bought less than a month of downtime.

Vidar retrieves its command server address dynamically from the bio sections of fake Telegram and Mastodon profiles — regular-looking social media accounts where an IP address is embedded in the profile text and rotated regularly. Standard IP blocklists cannot keep up with infrastructure that updates itself through public social media.

What Happens After Your Tokens Are Stolen

Once session tokens are exfiltrated, attackers import them into specialized tools called anti-detect browsers — software built specifically to impersonate another person's machine. These replicate the exact fingerprint of the victim's device: browser version, screen resolution, installed fonts, hardware identifiers. From the server's perspective, the incoming request is indistinguishable from the legitimate user.

There is no password challenge. There is no MFA prompt. The session token is a bearer credential — whoever holds it, the server trusts. The attacker is inside the account.

This is the mechanism behind the Arup attack. The deepfake video call was the social engineering layer, designed to authorize a specific transaction. The account access that made it possible was already established before the call began.

What To Do About It

The most effective individual protection is the simplest: log out of sensitive accounts — banking, email, work portals — when you are done using them. A session token that has been invalidated is worthless to an attacker who steals it. Most people leave sessions open indefinitely because it is convenient. That convenience is what this attack exploits.

The primary infection vector is software installation. Infostealer malware does not typically arrive through sophisticated browser exploits — it arrives because someone installed something. A cracked application. A fake update. A file from an unofficial source. The malware on the machine is the prerequisite for everything that follows. Download software only from the official source of the developer.

If you suspect your machine has been compromised, changing your password is not enough. Go to the security settings of your important accounts and revoke all active sessions — typically labeled "sign out of all devices" or "manage active sessions." This invalidates any tokens already stolen, forcing reauthentication on every device. Do this before changing the password, not after.

The Long-Term Fix

The individual mitigations are patches on a deeper architectural problem. Session tokens are bearer credentials — they grant access to whoever holds them, with no verification of the device presenting them. The machine that originally authenticated is not part of the equation once the token exists.

The permanent solution is Device Bound Session Credentials (DBSC) — a standard in active development that binds session tokens cryptographically to the hardware of the originating device. A stolen token becomes useless on any other machine because the cryptographic proof of device identity cannot be replicated. Active development is underway in Chrome and Edge.

Until that standard ships and achieves broad adoption, the gap remains. Log out when you are done. Only install software from sources you trust. Know that MFA, for all its value, does not cover the session that begins the moment login succeeds.

The login is secure. Everything after it is not.