What Is Cookie Logging? Session Theft and Detection

An account logs in from a managed laptop in Chicago at 9 a.m. Forty minutes later the same session is reading mail from a residential IP in another country, on a browser the user has never run, and the identity provider never issued a new sign-in. No failed logons. No MFA prompt. No password reset. The login that mattered already happened on the user's machine, and the attacker just borrowed what it produced: a valid session cookie.

That is cookie logging. An attacker captures the session cookie a web application hands a browser after authentication, then replays it to act as the user without ever knowing the password or answering a second factor. The session is already authenticated, so importing the cookie skips the entire login. This guide covers what session cookies are and why they are worth stealing, how attackers capture them, the two MITRE ATT&CK techniques that describe the theft and the reuse, why multi-factor authentication does not stop it, and the signals a SOC actually uses to catch it. It is written for the people who have to answer "how did they get in with MFA on?" after the fact.

What is cookie logging?

A session cookie is the small token a web application stores in your browser after you authenticate. HTTP is stateless, so the server has no memory of you between requests. The cookie is how it remembers: every subsequent request carries the cookie, the server checks it, and the user stays logged in without re-entering a password on each click. Cloud services lean on this heavily, because re-authenticating to Microsoft 365 or Google Workspace on every action would be unusable.

The cookie is therefore a bearer token. Whoever holds it is treated as the authenticated user, full stop. The server does not re-check who is presenting the cookie, it checks that the cookie is valid and unexpired. That property is the entire problem. A password is something you know, a phishing-resistant key is something you hold, but a session cookie is just a string, and a string can be copied. Once copied, it carries the full weight of the login that produced it, including the multi-factor check the user already passed.

Cookie logging is the act of capturing those cookies, on the host, in the browser, or in transit, and the term also covers the defensive side: the authentication and access logs defenders correlate to spot a stolen cookie being reused. The attack maps to two ATT&CK techniques: stealing the cookie (T1539, Steal Web Session Cookie) and reusing it (T1550.004, Use Alternate Authentication Material: Web Session Cookie). The first is credential access, the second is how the attacker moves with what they took.

Why session cookies are worth stealing

The value is simple: a session cookie is authentication that has already cleared every gate. The user typed the password. The user approved the push or tapped the key. The identity provider issued the session and minted the cookie. All of that is finished by the time the cookie exists, and the cookie carries the result. Steal it and you inherit a fully authenticated session without touching any of the controls that authenticated it.

That makes a cookie more useful to an attacker than the password in many cases. A stolen password still has to survive MFA. A stolen session cookie does not, because the session it represents already did. It is also quieter. Reusing a cookie produces no failed-login noise and no new MFA challenge, so it sails past the alerting most teams built around credential stuffing and password spraying. The detections tuned for "wrong password 50 times" see nothing, because the attacker never submits a password at all.

Cookies are abundant, too. A workstation running a browser holds session cookies for dozens of services at once: email, the identity provider, code repositories, cloud consoles, internal apps. Many are long-lived by design so users are not constantly re-prompted. One compromised endpoint can yield a drawer full of live sessions, which is why infostealer operators sell stolen cookie collections as a product and why initial-access brokers price them alongside credentials.

How attackers capture session cookies

Cookie theft is not one technique. It is a category, and the capture point determines what a defender can see. Five methods dominate.

Infostealer malware. The most common path. Commodity stealers like Lumma, RedLine, and StealC run on a compromised endpoint, read the browser's cookie store straight off disk, decrypt it, and exfiltrate the lot. On Windows, Chrome and Edge keep cookies in an encrypted SQLite database under the user profile; the encryption key lives in the same user context, so a process running as the user can decrypt everything the user could. This is also where credential dumping and cookie theft overlap, the same malware grabs saved passwords, cookies, and crypto wallets in one pass.

Malicious browser extensions. An extension the user installs voluntarily can request permission to read cookies and page content, then quietly ship session tokens to an attacker. Because the extension runs inside the browser with granted permissions, the theft looks like normal browser behavior. This is why over-permissioned browser extensions are treated as an endpoint risk, not a convenience question.

Cross-site scripting (XSS). If an attacker can inject JavaScript into a page the victim trusts, that script runs in the victim's session and can read any cookie not protected by the HttpOnly flag. HttpOnly exists precisely to block script access to cookies, which is why its absence on a session cookie is a finding, not a nitpick.

Adversary-in-the-middle (AiTM) phishing. This is the technique behind the MFA-bypass campaigns of the last few years. The victim clicks a phishing link and lands on an attacker-controlled reverse proxy. The proxy relays every request to the real site and every response back, so the page is genuine, it is just relayed. As the password, the MFA code, and the resulting session cookie pass through, the proxy captures the cookie. Evilginx (tracked by MITRE as evilginx2, software S9003) is the best-known open-source framework for this; campaigns using it have phished session cookies from real SSO portals at scale. The attacker ends up holding a live, post-MFA session.

Network and token interception. Cookies sent over unencrypted HTTP, or pulled from a memory dump, or lifted from a misconfigured proxy log, are all capture opportunities. TLS closes the plain-HTTP case for any serious target, which is why the four methods above carry most real-world theft, but logged-in-the-clear tokens still surface in incident data.

Pass-the-cookie: replaying the session

Once an attacker holds the cookie, the reuse step is trivial. They paste it into their own browser, usually with a developer-tools console or an extension that imports cookies, load the application, and the server greets them as the authenticated user. No login screen. No MFA. This is "pass-the-cookie," and it maps to ATT&CK T1550.004, Use Alternate Authentication Material: Web Session Cookie, under the lateral movement tactic.

The reuse is invisible to most authentication monitoring because there is no authentication event to monitor. The identity provider already authenticated this session; replaying its cookie does not generate a new sign-in, a new token request, or a new MFA challenge in many flows. From the application's perspective the same valid session simply keeps making requests. The only thing that changed, and the only thing a defender has to work with, is the context around those requests: a different IP, a different device fingerprint, a different user agent, an impossible jump in geography.

The blast radius depends on what the session reaches. A stolen email session enables business email compromise (BEC), mailbox rule abuse, and internal phishing from a trusted account. A stolen identity-provider session can reach every app behind that SSO. A stolen cloud-console session can spin up infrastructure or read data stores. The attacker operates as the user for as long as the cookie stays valid, which is the real reason session lifetime matters.

Why MFA alone does not stop it

This is the part that surprises people: MFA was supposed to solve credential theft, and for password-only attacks it largely does. Cookie logging routes around it by attacking a different point in time. MFA gates the act of authenticating. The session cookie is the product of authentication. By the time the cookie exists, the MFA check is in the past, baked into a token the user already earned. Stealing that token does not require passing the check again, because the system has no reason to re-run a check it already passed for this session.

AiTM phishing makes the point sharply. The victim genuinely enters the password and genuinely approves the MFA prompt, through the proxy, against the real identity provider. Both factors are satisfied legitimately. The proxy simply keeps the resulting cookie. Every authentication control did its job and the attacker still walked away with the session, because the session, not the login, was the target.

The exceptions are worth naming because they point at the real fix. Phishing-resistant MFA bound to the origin, FIDO2 and WebAuthn passkeys, defeats AiTM phishing at the capture step, because the cryptographic assertion is tied to the real domain and will not validate against the proxy. And token binding, which ties a session cookie to the specific device or TLS channel that obtained it, makes a stolen cookie useless on the attacker's machine. Neither is universal yet, which is why detection still carries the load.

Cookie theft methods and the signals they leave

Each capture method leaves a different trace, which determines where a SOC looks. The reuse, by contrast, produces one consistent set of session-context anomalies regardless of how the cookie was stolen.

The pattern that catches most cookie theft is the bottom row, and it does not depend on knowing how the cookie was stolen. A session that suddenly appears on a new device or geography, with no fresh authentication event to explain it, is the tell. Everything above it is the SOC narrowing down the entry point after the reuse is flagged.

How SOC teams detect cookie logging

Because the reuse generates no login event, detection is correlation work, not signature matching. It lives in the SIEM, where authentication logs, sign-in logs, and session telemetry come together, and it leans on log analysis across sources that individually look benign.

Session reuse without a matching sign-in. The core detection. A session token is active, but there is no corresponding interactive sign-in or token issuance that explains the current device or location. In Microsoft Entra terms, this is activity on a session with no fresh authentication; the cookie is doing the talking. Correlate active sessions against issued sign-ins and flag the orphans.

Impossible travel. The same account or session active from two locations far enough apart that no traveler could cover the distance in the elapsed time. A login in Chicago and active session use from another continent twenty minutes later is the textbook case. Most identity platforms ship this as a risk signal; the SIEM joins it to session activity.

New device or user-agent on an existing session. The user authenticated from a known, managed browser. The same session is now being driven by a different user-agent string or an unmanaged device fingerprint. A session that changes its client mid-life, without re-authentication, is a strong pass-the-cookie indicator.

Endpoint signals for the theft itself. EDR is where the capture shows up: a process other than the browser opening the Chrome or Edge cookie SQLite database, injection into a browser process, or a known infostealer's file and network behavior. Catching it here stops the cookie before it is replayed.

AiTM phishing indicators. Sign-ins originating from hosting-provider or proxy IP ranges, brand-new lookalike domains in URL and email telemetry, and a sign-in immediately followed by session activity from a different IP all point at a proxy in the middle. Correlating the phishing click to the subsequent foreign session reuse ties the campaign together.

None of these fire on a single log line. They are joins, sign-in logs against session logs against EDR against email, which is exactly why cookie logging is a SIEM detection-engineering problem and not an endpoint-only one.

Defenses that actually shrink the window

Detection catches reuse after the cookie is stolen. The following controls cut the theft off earlier or make a stolen cookie worth less.

Short session lifetimes. A cookie is only dangerous while it is valid. Shorter sessions and shorter token lifetimes shrink the window in which a stolen cookie works. The trade-off is user friction, which is why this is tuned, not maximized.

Token binding. Bind the session cookie to the device or TLS channel that obtained it, so the same cookie presented from a different machine is rejected. This is the control that directly defeats pass-the-cookie, and the direction modern session protection is moving.

Conditional access and continuous evaluation. Policies that require a compliant, managed device or an allowed IP range to use a session block reuse from an attacker's unmanaged machine. Continuous Access Evaluation (CAEP) pushes this further by revoking sessions in near real time when risk changes, location, token, or user state, instead of waiting for the cookie to expire on its own.

Phishing-resistant MFA. FIDO2 and WebAuthn passkeys bind authentication to the real origin, so an AiTM proxy cannot complete the login on the user's behalf. This closes the capture step for the proxy-phishing path specifically.

Infostealer prevention and browser hardening. EDR that catches stealer behavior, application control, and locking down browser extension installation all attack the most common theft path. Setting HttpOnly and Secure on session cookies closes the XSS and plain-HTTP routes. None of these is sufficient alone, which is the recurring theme: cookie logging is a layered problem, and the layer that fails quietly is the one detection has to cover.

The bottom line

Cookie logging is the theft of session cookies and their replay to hijack an already-authenticated session. It works because a session cookie is a bearer token that carries the full result of a login, including the multi-factor check the user already passed, so stealing it skips authentication entirely. Attackers capture cookies with infostealers, malicious extensions, XSS, and adversary-in-the-middle phishing, then pass-the-cookie into their own browser. ATT&CK splits this into T1539 for the theft and T1550.004 for the reuse.

MFA alone does not stop it because MFA gates the login, not the session the login produces. The fixes that close the gap are phishing-resistant MFA, token binding, conditional access with continuous evaluation, and short session lifetimes, backed by infostealer prevention on the endpoint. Until those are universal, detection carries the load, and it is correlation work: a session active from a new device or geography with no sign-in to explain it is the signal that a cookie, not a person, is logged in.