Session hijacking: when MFA is not enough

Why does account takeover bypass MFA?

Many account security programs focus on the sign-in: strong passwords, then MFA. Account takeover can skip that step. After a user signs in, the site issues a session cookie that proves the sign-in already happened. Whoever holds that cookie can often act as the user until it expires or is revoked.

MITRE ATT&CK, the public catalog of attacker techniques, describes adversaries stealing web session cookies to access web applications, and notes that stolen session cookies can be used to get around some multi-factor authentication protocols.^[1] For a B2B company, one hijacked session can mean a compromised mailbox, CRM, ad account or company social page.

What is session hijacking?

When a user signs in, the server issues a temporary secret, usually a cookie, that the browser sends with each later request. NIST's digital identity guideline is clear that cookies "are not authenticators but are suitable as short-term secrets for the duration of a session".^[4] It also notes that hijacking attacks on the session after sign-in "can have similar security impacts" to attacks on the sign-in itself.^[4]

Session hijacking is any use of that secret by someone other than the user. Because the session already carries the result of the sign-in, including any MFA check, the attacker does not need the password or the second factor.

How do infostealers steal sessions?

Infostealers are malware built to collect stored credentials and cookies from an infected device and send them to the attacker. Google describes the usual start as a user unknowingly installing malware, names LummaC2 as one family that has become "increasingly sophisticated at harvesting these credentials", and notes that the resulting account access is often sold or traded.^[2]

Typical infection routes are the ones defenders already know: a malicious attachment, a fake software download, a cracked app or a poisoned ad. Once collected, the cookies can be replayed from another machine, and the application sees what looks like the real user's session.

Why are B2B companies a target?

B2B teams concentrate valuable sessions in one browser:

• Single sign-on. A session at the identity provider can open every connected app.
• Long sessions. "Stay signed in" options and long-lived cookies widen the window for replay.
• Shared and partner access. Agencies, contractors and partners often sign in from devices you do not manage.
• Quiet persistence. A replayed session does not create a failed sign-in, so it can go unnoticed until something changes, such as a new mail rule or a new admin on a social page.

Social and ad accounts are a common target for the last reason. Our guide to social media hijacking covers that side.

How does a hijack usually unfold?

At the level a defender needs:

1. Infection. A user runs malware on a work or personal device.
2. Collection. The malware gathers saved passwords and session cookies and sends them out.
3. Replay. The attacker uses a still-valid cookie from their own machine.
4. Abuse. They read mail, add forwarding rules, export data, change payment details or post from company accounts.

Each step offers a control point, which is how the defenses below are grouped.

Which session controls limit the damage?

Bind sessions to the device. Chrome's Device Bound Session Credentials (DBSC) keep a private key in secure hardware, such as a TPM, and require proof of that key before a short-lived cookie is renewed.^[2] Google says DBSC entered public availability for Windows on Chrome 146, with macOS to follow,^[2] and that it is now generally available and on by default for Google Workspace and personal Google accounts on Chrome for Windows.^[3] Sites can adopt it by adding registration and refresh endpoints.^[2] In Microsoft Entra ID, token protection is a conditional access control that accepts only device-bound sign-in session tokens; Microsoft lists it as generally available for native apps on Windows, with Apple device support and browser apps partly in preview.^[6]

Shorten session lifetimes. NIST SP 800-63B-4 sets an overall timeout of no more than 24 hours at AAL2 and says the inactivity timeout should be no more than 1 hour.^[4] OWASP cites idle timeouts of 2 to 5 minutes for high-value applications and 15 to 30 minutes for low-risk ones.^[5]

Harden the cookie. Mark session cookies Secure and HttpOnly,^[4][5] set SameSite to Strict or Lax,^[5] and regenerate the session ID at sign-in and after any privilege change.^[5]

Which identity and endpoint controls help?

• Conditional access. MITRE lists phishing-resistant MFA and conditional access that limits sign-ins to trusted devices as mitigations.^[1]
• Monitoring. Watch for sessions used from unusual locations or user agents, including impossible travel.^[1]
• Endpoint detection. Alert on processes reading browser cookie stores or browser memory, a detection MITRE describes.^[1]
• Browser hygiene. Keep browsers patched, restrict extensions and clear persistent cookies regularly.^[1]
• Fewer saved secrets. Discourage saving work passwords in the browser and use a managed password manager or passkeys instead.

Leaders' accounts deserve these first; our executive cybersecurity checklist sets out the baseline, and executive impersonation explains how stolen access is used against finance teams.

What if a device is suspect?

Write the steps down before you need them: revoke all active sessions for the affected user, reset passwords, remove unknown sign-in methods and mail rules, and isolate the device. Malware removal, forensics and incident response are work for your IT team or a specialist firm you contract with. Our social media protection service covers MFA, company-owned logins and recovery planning for company social accounts as part of our digital asset security work.