Beyond MFA: A Defender's Guide to Token Theft and AiTM

Webcast focus: moving beyond MFA for modern identity attacks

The speaker argues that multi-factor authentication (MFA) alone is no longer sufficient to stop modern account compromise techniques—especially token theft and AiTM (Adversary-in-the-Middle)-style attacks.

Core problem

Even after a user passes MFA, identity providers still issue tokens and browser session cookies. If an attacker can intercept them or obtain session artifacts, they can replay those credentials.

---

Threat example driving the discussion: “Captive Crunch”

A Microsoft Threat Intelligence report on Captive Crunch is highlighted.

What the attackers targeted

The attack compromised hotel/conference Wi‑Fi captive portals (via:

• SaaS hotel portals,
• hotel systems, or
• network compromise).

Attack goal

The objective was identity hijacking / token theft using:

• Social engineering (e.g., click-based flows)
• Man-in-the-middle phishing
• Device code phishing (via Microsoft flow abuse)

---

Attack surface: tokens and cookies after sign-in

The talk explains Entra ID / Azure AD authentication at a high level using a “trust triangle”:

• Client (browser/email/messaging)
• Identity provider (Entra ID / Azure AD)
• Resource (API/service)

Key security implication

If an attacker steals tokens, the resource often doesn’t verify who the token sender is beyond validating token correctness/signature/scope. That means stolen bearer tokens can be replayed.

---

Token types (Entra ID context)

• Access token

  • Short-lived (typically ~1 hour, can extend up to ~28 hours)
  • If stolen: attacker can access the scoped resource until expiration
  • Not easily revoked once issued (as stated by the speaker)

• Refresh token

  • Longer-lived (~90 days, sliding window)
  • If stolen: attacker can mint new access tokens for resources the user/principal can access
  • Therefore often more valuable than access tokens

Additional token variants mentioned

• Public key refresh token
• Master refresh token
• FOCI refresh tokens (Microsoft feature where “family” of clients can reuse refresh-token capabilities across related client apps)

---

Browser cookies

Entra ID session cookies discussed include:

• ESTS Auth
• ESTS Auth Persistence

“Stay logged in” persistence cookies are described as more valuable because they remain usable longer.

---

Two major ways discussed to obtain tokens without “winning” MFA directly

The webcast explicitly focuses on these paths:

1. Man-in-the-middle (MitM) phishing

   • Attacker places a reverse proxy in front of the real Entra ID sign-in page.
   • Victim enters credentials into the proxy and completes MFA.
   • Attacker captures cookies/tokens to recreate sessions.
   • Why MFA fails here (per the talk): MFA challenges typically don’t validate browser/origin context, so the MFA request can be approved even from an attacker-controlled flow.

2. Device code phishing

   • Abuse of Microsoft’s device code flow (designed for non-browser devices).
   • Victim enters a code at microsoft.com/devicelogin, which binds device access to the attacker’s session.
   • Common misconfiguration noted: device-code logins may be insufficiently restricted.
   • The talk references examples such as messaging/WhatsApp lures and Teams-related identifiers.

---

What “phishing-resistant MFA” means (and what it doesn’t)

A major theme: MFA alone is not enough—the method/mode matters.

Origin binding as the key protection concept

Phishing-resistant authentication is presented as relying on origin binding (tying authentication to a specific domain such as login.microsoftonline.com).

Proposed mechanism:

• A credential/authenticator private key signs requests for a specific origin
• The private key does not leave the authenticator
• Therefore, a proxy can’t generate valid authentication responses for the real identity provider endpoint

Authentication method “slide scale”

Methods are grouped roughly as:

• Phishing-out (weak MFA)
  • Easy to intercept/guess (email/SMS/voicemail-based factors)
• Passwordless
  • Removes passwords, but does not automatically mean phishing-resistant
• Phishing-resistant
  • FIDO2 keys / Access keys / Windows Hello for Business / certificate-based auth
• Recovery / break-glass
  • Temporary access passes / one-time entry style mechanisms

Explicit clarifications:

• Passwordless ≠ phishing-resistant
• Push-based Microsoft Authenticator with number matching is better against some attacks, but may still be insufficient for all MitM/token-theft scenarios unless configured correctly with origin-bound credentials.

---

Concrete hardening guidance: what to configure/audit

Entra ID policies for authentication strength

• Use Authentication method policy to define which MFA methods are allowed per user (including exceptions).
• Entra ID supports a “phishing-resistant MFA” requirement level (described as token strength Entra ID later issues after compliant auth).

Token-centric defenses (because bearer tokens/cookies are the real prize)

1. Microsoft Token Protection

   • Binds certain tokens to a device cryptographic key/TPM-backed device state using proof-of ownership principles.
   • Mitigates token replay if stolen tokens can’t be used without the associated device key.
   • Limitation emphasized:
     • Not for browsers
     • Applies to specific Microsoft apps (Windows 10+; Mac/iOS mentioned as preview)

2. Continuous access assessment

   • For tokens that can be long-lived (especially when access token lifetime can extend up to ~28 hours), Entra ID can invalidate tokens for critical events such as:
     • password reset
     • session cancellation
     • account disabled/deleted
   • Instead of waiting for token expiration, Entra ID can prompt connected Microsoft resources to reject tokens after compromise-relevant identity events.
   • Limitation emphasized:
     • Not for browsers
     • Initially focused on Microsoft app ecosystem (e.g., Teams/SharePoint/Outlook)

3. Forward-looking: device-bound session credentials

   • An upcoming browser-level improvement idea:
     • Tie session cookies to the device (not just the user) to reduce cookie theft value.
   • Cross-platform for Chrome/Edge
   • Firefox not yet

Device code flow mitigation

The talk recommends:

• Auditing logins through device code
• Locking down device code using Conditional Access (mentioned as beyond detailed scope for that segment, but covered in the course)

---

Summary takeaways (what to stop assuming / investigate)

Key “stop assuming” points:

• Don’t assume MFA is enough
• Don’t assume passwordless is phishing-resistant
• Don’t assume token protection covers the browser
• Block/restrict device code flow as much as possible
• Ensure administrators meet at least zero-level phishing resistance requirements
• Pilot/roll out and verify measurable impact:
  • Token Protection
  • Continuous access assessment

---

Main speaker/source

• Maxim Devirdt — Principal Instructor at SANS
  • Also cites Microsoft Threat Intelligence reporting on Captive Crunch
  • References Microsoft Entra ID / Azure AD concepts