Organisations that rolled out MFA to stop account takeover are still losing accounts, because attackers increasingly skip the login and steal the session that MFA already approved. Credential theft captures what a user knows or holds before authentication; session hijacking captures the token issued after authentication. The two need different controls, raise different detection signals and demand different incident response: resetting a password fixes the first and does nothing for the second. This guide compares the two attack chains, covers infostealers and adversary-in-the-middle (AiTM) phishing as the main delivery routes, explains where token binding and DPoP help, and sets out how detection and response differ. It is for identity engineers, SOC leads and incident responders. Defensive framing only: it describes attacker behaviour at the level needed to detect and stop it.
Key takeaways
- The theft happens at a different point. Credential theft takes secrets used to log in; session hijacking takes the cookie or token issued after login, including the MFA claim.
- MFA only protects the login. Phishing-resistant MFA defeats stolen passwords and AiTM proxies, but a token already issued is accepted until it expires or is revoked.
- Infostealers deliver both at once. One infection typically yields saved passwords and live session cookies, so the response must cover both.
- Binding tokens to a device is the session-side fix. DPoP, device-bound sessions and platform token protection make a copied token useless without a private key the attacker cannot export.
- Response order differs. For credential theft, reset and re-enrol; for session hijacking, revoke sessions and refresh tokens first, then find and clean the device that leaked them.
The short answer
Credential theft is an attack on authentication: the attacker obtains a password, OTP seed, API key or private key and logs in as the user. MFA, especially phishing-resistant MFA, is the main control, because the stolen secret alone is not enough. Session hijacking is an attack on session management: the attacker obtains a session cookie, refresh token or access token and replays it. Authentication has already happened, so MFA is never asked again unless a policy forces reauthentication. The controls that work are short token lifetimes, binding tokens to the device or key that received them, session anomaly detection and fast revocation. The Session Hijacking and Cookie Theft Guide covers the hijacking techniques in detail; this page is about the differences.
Side-by-side comparison
| Dimension | Credential theft | Session hijacking |
|---|---|---|
| What is stolen | Passwords, OTP codes or seeds, API keys, certificates, Kerberos material | Session cookies, refresh tokens, access tokens, primary refresh tokens |
| When in the lifecycle | Before or during authentication | After authentication |
| Typical ATT&CK techniques | T1555.003 Credentials from Web Browsers, T1110 Brute Force, T1566.002 Spearphishing Link, leading to T1078 Valid Accounts | T1539 Steal Web Session Cookie, T1550.004 Web Session Cookie, T1557 Adversary-in-the-Middle, T1606.001 Web Cookies (forged) |
| Does MFA stop it? | Yes, for most cases; phishing-resistant MFA also stops real-time relay | No: the token already carries the completed MFA claim |
| Lifetime of attacker access | Until the credential is changed | Until the token expires or is revoked; refresh tokens can extend this for weeks |
| Visible sign-in event? | Yes: a new interactive sign-in, often from a new location | Often no new interactive sign-in; token reuse appears as activity or non-interactive sign-ins |
| Primary prevention | Phishing-resistant MFA, passwordless, breached-password checks, secrets out of browsers | Token binding, short lifetimes, reauthentication for sensitive actions, endpoint protection |
| Primary response | Reset credential, re-register MFA, check MFA method changes | Revoke sessions and refresh tokens, then clean the source device |
Credential theft: threat model and attack chain
The attacker wants a reusable secret. Sources include phishing pages that harvest passwords, password spraying and credential stuffing with reused passwords, infostealer malware that reads saved browser passwords, and secrets leaked in code or tickets. For machine identities, the equivalent is a stolen API key, client secret or private key, which usually has no MFA at all.
- Architecture in words: the attacker sends the stolen secret to the real identity provider's login endpoint. If the account requires only a password, access follows. If MFA applies, the attacker must also defeat it, by push fatigue (T1621 Multi-Factor Authentication Request Generation), by relaying an OTP in real time, or by switching to session theft.
- Failure modes for defenders: MFA exclusions for legacy protocols or service accounts, OTP and push methods that a proxy can relay, password resets that leave MFA methods an attacker registered, and machine credentials that never expire.
- Controls: phishing-resistant authenticators (FIDO2 passkeys, smart cards) under NIST SP 800-63B-4, which states that passwords, OTPs and out-of-band methods are not phishing-resistant and requires phishing resistance at AAL3; blocking legacy authentication; breached-password screening; and moving machine credentials to workload identity federation. See the Phishing-Resistant MFA Guide and the Password Spraying and Credential Stuffing Defence Guide.
Session hijacking: threat model and attack chain
The attacker wants a token that the application already trusts. After a successful login, the identity provider and each application issue session cookies or OAuth tokens. These are bearer credentials: whoever presents them is treated as the user, from any device, unless something binds them.
- Architecture in words: the attacker imports the stolen cookie into their own browser or presents the token to an API. The application validates signature, expiry and audience, sees an authenticated session with an MFA claim and serves the request. No login page is involved.
- Theft routes: infostealers reading the browser cookie store (T1539), AiTM proxies capturing the cookie as it is issued (T1557), malicious browser extensions, tokens leaked in logs or HAR files, and server-side flaws that leak session memory.
- Failure modes for defenders: long-lived refresh tokens, sessions that survive password reset, no device or key binding, and detection that only watches interactive sign-ins.
- Controls: sender-constrained tokens, short session lifetimes with reauthentication for sensitive actions, Secure and HttpOnly cookies with the
__Host-prefix as the OWASP Session Management Cheat Sheet recommends, session anomaly detection and continuous access evaluation. See the Token and Session Security Guide.
Server-side session theft shows why this matters. In the CitrixBleed 2023 case, a memory leak in internet-facing gateways returned valid session cookies to unauthenticated requests. MFA had already been completed, so replayed cookies gave full access, and organisations that patched without killing existing sessions remained exposed. Citrix's guidance was to upgrade and then terminate all active and persistent sessions.
Delivery routes: infostealers and AiTM
| Route | What it yields | Defeats which MFA | Most effective counter |
|---|---|---|---|
| Password phishing page | Password only | None, if MFA is enforced | Any MFA; phishing-resistant MFA preferred |
| AiTM reverse proxy | Password and the session cookie issued after MFA | OTP, push, SMS (relayed in real time) | Phishing-resistant MFA bound to the real site origin; compliant device requirement |
| Infostealer on endpoint | Saved passwords, autofill data and live cookies and tokens | All MFA types, for already-issued sessions | Endpoint protection, device-bound sessions, app-bound cookie encryption, short lifetimes |
| Credential stuffing or spraying | Working password for accounts without MFA | None, if MFA is enforced | MFA coverage, breached-password checks, rate limits |
| Leaked tokens in logs, HAR files or code | Bearer tokens and API keys | Not applicable: no login | Token redaction, short lifetimes, sender constraint |
AiTM: credential theft and session hijacking in one step
Microsoft Threat Intelligence described an AiTM campaign that, from September 2021, attempted to target more than 10,000 organisations. A proxy sat between the victim and the real Microsoft sign-in page, captured the password and the session cookie after MFA, and attackers used the cookie to reach Outlook on the web, in some cases within five minutes. Microsoft stressed that this was not a vulnerability in MFA: the cookie was simply issued after MFA succeeded. The attackers then created inbox rules that moved replies to the Archive folder and marked them read, and pursued invoice fraud. The recommended defences were phishing-resistant MFA such as FIDO2 or certificate-based authentication, conditional access requiring compliant devices, and monitoring for suspicious sign-ins and inbox rule creation. FIDO2 helps because the authenticator signs a challenge tied to the site origin, so a proxy on a different domain cannot obtain a valid assertion. See the AiTM Phishing Guide.
Infostealers: both at once
An infostealer running as the user can read the browser's password store and cookie database, then ship a log to the operator. The passwords are a credential theft problem; the cookies are a session hijacking problem, and they work even when every account has MFA. Browser vendors have raised the bar. Google introduced App-Bound Encryption for Chrome cookies on Windows in Chrome 127, tying decryption to the Chrome application identity, while noting that malware running elevated or injecting into Chrome can still bypass it. Failed verification logs Event ID 257 in the Windows Application log. See the Infostealer Threat Guide and the Infostealer Logs and Session Token Abuse Guide.
Token binding and DPoP: closing the session gap
Binding makes a token usable only by the holder of a private key that stays on the original device. Platform features below are listed alphabetically by publisher; order is not a ranking.
| Mechanism | What it binds | How it works | Limits to plan for |
|---|---|---|---|
| DPoP (RFC 9449, Standards Track, September 2023) | OAuth access and refresh tokens | Client signs a proof JWT per request with claims htm, htu, iat, jti, ath and optional server nonce; servers check the token is bound to that key | Code running in the client (for example via XSS) can sign proofs; only method and URI are signed; use server nonces to stop pre-generated proofs |
| Mutual TLS certificate-bound tokens | OAuth tokens for confidential clients and workloads | Token is tied to the client certificate used on the TLS connection | Suited to services rather than browsers; certificate lifecycle needed |
| Google Chrome Device Bound Session Credentials (DBSC) | Website session cookies | Browser creates a key pair at login, in a TPM where available; short-lived cookies are refreshed by proving key possession | Malware present at registration may extract the key; falls back to normal cookies where secure key storage is unavailable; HTTPS only |
| Microsoft Entra Token Protection (Conditional Access) | Sign-in session tokens such as the Primary Refresh Token | Entra ID accepts only device-bound session tokens for protected resources | Applies to supported native apps (Exchange Online, SharePoint Online, Teams) and devices; browser support was in preview when checked in November 2026 |
Binding does not help if the attacker controls the device in real time, since the attacker can then use the session from the device itself. That residual risk is why endpoint detection, short lifetimes and reauthentication for sensitive actions remain necessary. See the DPoP Guide and the Device Bound Session Credentials Guide.
Detection signals compared
| Signal | Points to credential theft | Points to session hijacking |
|---|---|---|
| Failed sign-ins then success | Yes: spraying, stuffing or guessing | No |
| Interactive sign-in from new location or ASN | Yes | Rarely, unless the attacker also logs in |
| MFA prompts the user did not start, or new MFA method registered | Yes | No (MFA is never triggered) |
| Same session or token used from two IPs, ASNs or countries | No | Yes: classic replay indicator |
| Token or session used with a different user agent or device ID than issued | No | Yes |
| Sign-in to a lookalike domain or AiTM infrastructure in proxy logs | Yes | Yes (AiTM yields both) |
| Infostealer detection on the endpoint | Yes | Yes |
| Inbox rules, OAuth app consent or mailbox search soon after session start | Possible | Common in AiTM-led business email compromise |
The practical gap is that many SOCs alert on sign-in events, and session hijacking produces few of them. Log session lifecycle events (creation, refresh, revocation) with a hashed session identifier, as OWASP advises, and correlate token use by session ID across IP and device. Binding-aware identity providers also emit failures when an unbound or mismatched token is presented, which is a strong signal. NIST SP 800-53 Rev. 5 SC-23 Session Authenticity and AC-12 Session Termination are the controls to cite. See the MITRE ATT&CK T1539 Steal Web Session Cookie guide.
Response differences
| Step | Credential theft | Session hijacking |
|---|---|---|
| First action | Reset the credential and block the attacker's sign-ins | Revoke all sessions and refresh tokens for the user, in the identity provider and in each affected application |
| MFA | Review and remove attacker-registered methods; re-enrol | Review methods too, since the attacker may have added one during the hijacked session |
| Password reset | Required | Not sufficient alone: existing tokens may stay valid unless revoked |
| Source | Identify the phishing page, reused password or leaked secret | Identify and clean the device or system that leaked the token; reimage if an infostealer is confirmed |
| Persistence check | New devices, app passwords, OAuth consents | Inbox rules, OAuth consents, newly registered devices, API tokens created in-session |
| Scope | Other accounts using the same password | Every application whose cookies were in the stolen browser profile |
The common mistake is to reset the password, see the alert clear and close the case while the attacker keeps using a refresh token. Revoke first, then reset if credentials were also exposed. The How to Revoke All Sessions for a Compromised User guide and the Session Token Theft Response Playbook give the steps.
Where identity fits
Machine identities face the same split. A stolen client secret or API key is credential theft, and since there is no MFA, the controls are federation, short-lived credentials and secret scanning. A stolen OAuth access token or cloud session token is session hijacking, and the fixes are DPoP or mTLS-bound tokens, short lifetimes and revocation. Workload tokens are often long-lived and unmonitored, which makes them attractive. See the OAuth Token Theft Incident Playbook.
Decision guidance
- Close credential theft first where MFA coverage is incomplete. Accounts without MFA fall to the cheapest attack; enforce MFA and block legacy authentication before investing in binding.
- Move privileged and high-risk users to phishing-resistant MFA. This removes AiTM as a route to both credentials and cookies.
- Then bind sessions. Enable platform token protection for supported apps, DPoP for your own OAuth APIs and device-bound sessions for your web applications where browser support allows.
- Shorten and reauthenticate. NIST SP 800-63B-4 recommends reauthentication at AAL2 after 24 hours overall and 1 hour of inactivity, and at AAL3 requires 12 hours overall with a recommended 15 minute inactivity timeout. Require step-up for sensitive actions; see Continuous Authentication vs Step-Up Authentication.
- Harden endpoints against infostealers, since no session control fully survives malware with control of the device.
Small organisations: enforce MFA everywhere, adopt passkeys for admins, require managed devices for email and finance apps and use the identity provider's built-in session revocation. Large organisations: add token protection policies in report-only mode first, DPoP for internal APIs, session-level detection in the SIEM and an automated revoke-sessions action in the SOAR playbook.
Worked scenario
A finance user installs a fake software update. An infostealer copies saved passwords and cookies. Two days later the SOC sees mailbox activity from a hosting provider ASN with no matching interactive sign-in, and a new inbox rule archiving replies from a supplier. The analyst classifies this as session hijacking: no MFA prompt occurred and the session ID matches one issued to the user's laptop. The team revokes all sessions and refresh tokens, removes the inbox rule, reimages the laptop, and then resets the user's passwords for every site in the stolen profile because the same log held credentials. Afterwards they enable token protection for email on managed devices and add an alert for a session ID seen from two ASNs.
Common failure patterns
- Password reset as the only response: the hijacked session or refresh token carries on.
- Patching a leaky system without killing sessions: tokens stolen before the patch remain valid, as CitrixBleed showed.
- Relayable MFA treated as phishing-proof: OTP and push are relayed by AiTM proxies.
- Detection limited to interactive sign-ins: token replay produces activity, not logins.
- Long-lived refresh tokens with no binding: one stolen token gives weeks of access.
- Cleaning the account but not the device: the infostealer collects the new session as well.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-2, IA-5 | Authentication and authenticator management (credential side) |
| NIST SP 800-53 Rev. 5 | SC-23 Session Authenticity; AC-12 Session Termination | Session protection and revocation |
| NIST SP 800-53 Rev. 5 | SI-4, AU-6 | Monitoring and review of session and sign-in activity |
| NIST CSF 2.0 | PR.AA-03; DE.CM-03 | Authentication; monitoring personnel activity |
| NIST SP 800-63B-4 | Phishing resistance; reauthentication timeouts | Authenticator choice and session lifetimes |
| MITRE ATT&CK | T1555.003, T1110, T1078, T1621 | Credential theft and its use |
| MITRE ATT&CK | T1539, T1550.004, T1557, T1606.001 | Session theft, replay and forgery |
Detection and measurement
- Percentage of users, and of privileged users, on phishing-resistant MFA.
- Percentage of sign-in traffic to supported apps covered by token binding policies in enforce mode.
- Median refresh token and session lifetime for high-risk applications.
- Time from detection to full session revocation in token theft incidents.
- Number of session replay detections (same session from two networks) per month, and the share confirmed.
Practitioner checklist
- Classify every account takeover case as credential theft, session hijacking or both before choosing the response.
- Enforce MFA on every account and block legacy authentication.
- Move admins and finance users to phishing-resistant MFA.
- Enable device-bound token protection for supported apps, report-only first.
- Use DPoP or mTLS-bound tokens for your own OAuth APIs.
- Set session and refresh token lifetimes in line with NIST SP 800-63B-4 for the assurance level.
- Alert on the same session used from two networks or devices.
- Make "revoke all sessions" the first step in token theft playbooks and confirm it covers every application.
- Reimage devices with confirmed infostealer infections and reset every credential in the stolen profile.
Standards and references
- IETF: RFC 9449 OAuth 2.0 Demonstrating Proof of Possession (DPoP)
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- OWASP: Session Management Cheat Sheet
- Google: Device Bound Session Credentials
- Google Security Blog: Improving the security of Chrome cookies on Windows
- Microsoft Learn: Token protection in Conditional Access
- Microsoft Security Blog: From cookie theft to BEC (AiTM phishing)
- MITRE ATT&CK: T1539 Steal Web Session Cookie
Related NHI Mgmt Group resources: Session Hijacking and Cookie Theft Guide, Session Cookies vs Bearer Tokens, MFA Fatigue and Bypass Guide, Infostealer Logs Monitoring and Response Guide.