Expert Briefing: Identity Security in the Age of Session Theft

A briefing on detecting and containing identity-led attacks that reuse a valid session instead of breaking authentication.

Briefing at a glance	Details
Focus	Detecting and containing identity-led attacks that reuse a valid session instead of breaking authentication
Audience	CISOs and security leaders, identity and access engineers, SOC and detection engineers, incident response leads
Scope	Cross-industry / Enterprise

About this briefing

An employee approves an MFA prompt, opens a few emails and moves on. Within minutes, someone else is in the same mailbox from a different network. Nothing was guessed or cracked. In the adversary-in-the-middle campaign Microsoft analyzed, the attacker replayed a stolen session cookie that already carried the MFA claim, and signed in to Outlook on the web within about five minutes of the victim’s sign-in to the phishing site.

That is the gap this briefing works on. Most identity programs measure how well they authenticate people. Attackers have shifted to what the application trusts afterwards: the session and the token. We treat session theft as a detection and response problem first, then look at the preventive controls that are finally maturing and where each one stops short.

What you will leave with

A clear picture of the three routes by which sessions and identities are taken over, and what each leaves in your logs

A short list of signals worth detecting, with an honest view of their limits

A revocation sequence that actually ends an attacker’s access, not just a password

A realistic read on token binding, device-bound sessions and phishing-resistant MFA: what they stop and what they do not

Briefing flow

Segment	Focus	Question it answers
1	Why MFA completion is not the finish line	What does an application trust after sign-in?
2	Three routes to a stolen session	How do attackers end up holding a valid session?
3	What detection can see, and when	Which signals appear, and how late?
4	Ending a session properly	In what order do we contain, and how do we prove it worked?
5	Controls that change the economics	What do binding and phishing-resistant MFA really cover?
6	Where programs go wrong	Why do mature MFA estates still get breached?

Why MFA completion is not the finish line

Multifactor authentication protects one moment: the sign-in. Once it succeeds, the identity provider issues a session cookie or token, and the application honors that artifact until it expires or is revoked. Whoever holds it is the user for that period.

Microsoft was direct about this when it described adversary-in-the-middle phishing: it is not a vulnerability in MFA, because the stolen cookie authenticates the attacker regardless of how the victim signed in. The proxy sits between the victim and the real site, relays the genuine sign-in page, and keeps the cookie issued at the end.

Mandiant’s latest M-Trends report describes the same shift from the incident response side. Attackers harvest long-lived OAuth tokens and session cookies, which often remain valid after logout. Interactive social engineering frequently bypasses traditional MFA, and voice phishing now accounts for 11% of initial infection vectors in the investigations it reviewed, second only to exploits at 32%.

The implication. An MFA coverage figure tells the board how many front doors have locks. It says nothing about what happens to the session once someone walks through.

Three routes to a stolen session

The routes differ technically but converge on the same outcome: an attacker acting as a legitimate user with a legitimate session or a freshly issued factor. The third is strictly an account takeover rather than token theft. We cover it here because the detection logic overlaps almost completely.

Route	How it works	What the defender sees
Adversary-in-the-middle phishing	A reverse proxy relays the real sign-in page and captures the password plus the session cookie issued after MFA.	A normal sign-in with an MFA claim, then use of the same session from another network, device or browser. In the Microsoft case, new inbox rules and finance-themed mailbox searches followed.
Infostealer malware	Malware on the endpoint collects saved credentials, cookies and browser data. The CISA advisory on Scattered Spider lists infostealers collecting login credentials and cookies.	Often nothing at theft time. The session appears later from unfamiliar infrastructure.
Help desk and enrollment abuse	A caller impersonates an employee to get a password reset or to move MFA to a device the attacker controls. CISA notes the reconnaissance behind these calls draws on purchased credentials, personal data, social media and breach data.	A reset or authentication-method change, followed by sign-in from the new factor. No token was stolen. The identity was re-issued.

What detection can see, and when

Token theft rarely announces itself. The evidence usually appears at replay. Detection therefore leans on a small set of signals, each with a known weakness.

Signal	Why it matters	Limit
Session used from a new network, ASN, device or user agent mid-session	Replay from attacker infrastructure	Noisy for travelers, mobile users and VPN egress. Needs a per-user baseline.
New authentication method or device registered soon after an unusual sign-in	Persistence. The attacker keeps access after the session ends.	Requires identity provider audit logs correlated with sign-in logs.
Inbox rule creation, forwarding, or bulk mailbox search after sign-in	Mirrors the post-access behavior Microsoft documented in the financial-fraud campaign	Specific to email-centered actors.
Help desk reset or MFA change followed by high-risk activity	Social-engineering takeover	Needs ticketing data joined to identity logs, which usually sit in different teams.
Identity provider risk detections	Built-in signals for anomalous tokens and adversary-in-the-middle sessions	Microsoft documents that its anomalous-token detection produces more false positives than others, and that its adversary-in-the-middle detection runs offline, after the fact.

The offline detail deserves attention. If a detection fires after the event, the response plan has to assume a gap between replay and alert. Our recommendation is to decide in advance which combinations of signals are strong enough to trigger automatic session revocation, and which need an analyst.

Ending a session properly

A password reset feels like containment. For a stolen session it often is not. M-Trends reports tokens that stay valid after logout, and Microsoft notes that its continuous access evaluation, which can revoke access within minutes of events such as a password change or an administrator revoking refresh tokens, covers only supported resources and clients and can take up to 15 minutes to propagate. Whether a given session survives a given action depends on the application, the client and the configuration.

A sequence we would defend as a starting point:

1. Revoke sessions and refresh tokens for the account. In Microsoft Entra, this is the Revoke Session action or the equivalent PowerShell command.

2. Reset the credential and require re-authentication.

3. Review authentication methods registered since the suspected start, and remove any the user cannot confirm.

4. Inspect mailbox rules, forwarding, OAuth application consents and delegated access, which are the usual persistence mechanisms after a session takeover.

5. Scope outward. Look for other sessions from the same infrastructure, other accounts touched from the same source, and data accessed.

6. Re-enroll the user through a verified channel, not through the help desk path that may have been the way in.

Then test it. In a non-production tenant or with a test account, replay a session from a second device, apply each step and record how long access survives. Until someone measures it, that number is a guess.

Controls that change the economics

No single control closes session theft. Each removes a route or raises its cost, and each has edges worth knowing.

Control	What it addresses	What it does not
Phishing-resistant MFA (FIDO2/WebAuthn, certificate-based)	Adversary-in-the-middle relays. CISA and Microsoft both recommend it. The credential is tied to the legitimate site, so a proxy cannot relay a usable sign-in.	A session already issued, cookies lifted by infostealers, and help desk resets.
Token binding (Entra Token Protection)	Replay of bound sign-in tokens from another device	Coverage is defined and narrow. Microsoft lists native clients for Exchange Online, SharePoint Online and Teams, and browser-based support is in preview and limited to Azure Resource Manager. The page itself says the feature attempts to reduce replay.
Device-bound browser sessions (DBSC in Chrome)	Cookie export. A key held in the TPM must sign for new short-lived cookies, so a stolen cookie expires and cannot be refreshed elsewhere.	Needs supporting hardware and a site that implements the protocol. Windows support shipped in Chrome 146, macOS is planned, and federated sign-in binding is still in development. Google’s announcement does not say how it treats malware running on the compromised device itself. Assume that case is not solved.
Compliant-device conditions and continuous access evaluation	Replay from unmanaged devices and changed locations, plus faster revocation	Depends on application and client support. Policy and group changes can take time to apply.
Hardened help desk verification	Impersonation-led resets	A process control. Knowledge-based questions fail when the answers sit in breach data.

Where programs go wrong

Measuring authentication instead of sessions. The dashboard reports MFA coverage and phishing-resistant enrollment. It has no number for how long a stolen session would live or how fast the team can end it.

Signals scattered across three systems. Identity provider logs, endpoint telemetry and help desk tickets each hold part of the story. The takeover only becomes visible when they are joined, and different teams often own them.

Response that stops at the password. The runbook says reset and re-enroll. It does not say revoke, hunt for persistence, or check the help desk path that created the exposure.

Questions on the table

If we enforce phishing-resistant MFA everywhere, is session theft solved?

Which signals are strong enough to trigger automatic revocation without an analyst?

How do we hold help desk verification to the same standard as authentication?

What should we expect from token binding in a mixed estate of managed and unmanaged devices?

How do we test session revocation without disrupting production?

What to do next

1. Move privileged, finance and help desk roles to phishing-resistant MFA first. They are where a stolen session costs the most.

2. Run the replay test and write down how long access survives each containment step.

3. Join identity provider, endpoint and help desk data, then build detections for the five signals above.

4. Rewrite the reset and MFA-change procedure for privileged accounts so verification does not rely on information an attacker can buy.

5. Rehearse the revocation sequence with the people who will run it, and time it.

Putting this to work

Teams that want an independent view can look at Cybrilliant’s Identity Threat Detection & Response (ITDR) service, alongside Identity & Access Security, Identity Security Posture Management (ISPM) and Identity Threat Response.

Sources

1. Microsoft Security Blog, From cookie theft to BEC: Attackers use AiTM phishing sites as entry point to further financial fraud. Microsoft Threat Intelligence.

2. Google Cloud, M-Trends report (latest edition). Mandiant / Google Threat Intelligence Group.

3. Cybersecurity Advisory, Scattered Spider. CISA, FBI and partner agencies.

4. Microsoft Learn, Token Protection in Microsoft Entra Conditional Access. Microsoft.

5. Microsoft Learn, Continuous access evaluation in Microsoft Entra. Microsoft.

6. Microsoft Learn, What are risk detections? (Microsoft Entra ID Protection). Microsoft.

7. Google, Protecting cookies with Device Bound Session Credentials. Google Security.