Executive summary (TL;DR)

Adversary-in-the-Middle (AitM) phishing kits sit between a victim and the real Identity Provider (IdP). They relay the login flow in real time, capture session cookies / tokens issued after MFA, and then replay those tokens to hijack accounts—no malware required. Once inside, attackers perform malware-free intrusions: OAuth consent abuse, mailbox rules, data theft, wire fraud, and cloud pivots. The right countermeasures are phishing-resistant authentication (FIDO2/passkeys), proof-of-possession (DPoP/MTLS) or token binding equivalents, short-lived sessions with continuous evaluation, and detections for cookie reuse across origins/ASNs/devices.

The anatomy of an AitM cookie replay

1. Traffic relay

   • The victim clicks a link to a reverse-proxy phishing site.

   • The proxy presents a pixel-perfect copy of the target app while forwarding requests to the real IdP/Service.

2. Credential + MFA capture

   • Username, password, and MFA challenges are relayed in real time.

   • The IdP believes it’s talking to the real browser; MFA is satisfied.

3. Token issuance

   • IdP sets session cookies (or returns an auth code → access/refresh tokens).

   • The AitM proxy steals the Set-Cookie/Authorization artifacts.

4. Replay

   • The operator loads the stolen cookie/token into their own browser/session and is instantly signed in—bypassing MFA because it already occurred upstream.

5. Post-auth abuse (malware-free)

   • Create inbox rules, add OAuth apps with broad scopes, mint long-lived refresh tokens, register new devices, or pivot to cloud resources—all with native tools.

Why it works: most web sessions use bearer tokens not bound to the original device, TLS channel, or key material. If a token is copied, it often works anywhere until it expires or is revoked.

What AitM can and cannot bypass

• Can bypass reliably:

  • SMS/OTP/TOTP, push-MFA, email codes, app-based approvals (since MFA happens, then tokens are stolen).

  • Conditional access that only checks at sign-in time (not continuously).

• Hard to bypass (when correctly enforced):

  • WebAuthn/FIDO2 passkeys (origin-bound challenge + device factors make credential relay fail).

  • Token binding / proof-of-possession (DPoP, MTLS) that ties tokens to a key held by the client.

  • Continuous Access Evaluation (CAE) and short sign-in frequency (tokens expire/are re-challenged quickly).

  • Device-bound tokens / PRT-based access with compliant device (IdP evaluates device trust, not just user MFA).

Risk hot spots you should assume are exploitable

• Long-lived refresh tokens & remember-me sessions.

• IdP configs allowing admin consent to unverified OAuth apps.

• Legacy MFA paths (SMS/voice), legacy protocols (IMAP/POP, basic auth) left enabled.

• VIP workflows (Finance, HR, Procurement) without out-of-band callbacks.

• SaaS tenants where SameSite or Secure cookie flags are misconfigured, or session TTLs are days/weeks.

Defensive architecture (priority-ordered)

1) Authentication & tokens

• Enforce FIDO2 / passkeys for users and mandatory for admins.

• Eliminate legacy MFA and block legacy protocols (IMAP/POP/Basic).

• Enable Continuous Access Evaluation (or equivalent) and shorten sign-in frequency.

• Prefer proof-of-possession:

  • DPoP for OAuth/OIDC where supported (access tokens bound to a public key).

  • Mutual-TLS for server-to-server / high-risk apps.

• Issue short-lived access tokens and rotate refresh tokens frequently; revoke on risk.

2) Session & cookie hygiene

• Cookies: HttpOnly, Secure, SameSite=Strict/Lax where compatible; minimize path/domain scope.

• Bind session context on the server: IP/ASN, device posture, OS+browser family; re-challenge on drift.

• Step-up auth for sensitive actions (payments, data export, mailbox rule creation).

3) Identity & SaaS guardrails

• Verified publisher and admin consent workflow for OAuth apps; scope allow-lists.

• Block consent for high-risk scopes (mailbox full-access, drive full-access) unless approved.

• Just-In-Time (JIT) admin elevation; kill standing global admin.

• Device compliance checks for privileged apps (IdP + EDR posture).

4) Email & payment control

• DMARC p=reject, DKIM/SPF alignment; external banners; VIP impersonation detections.

• Finance processes: dual control & callback with shared secrets for any beneficiary or bank change.

5) Network & egress

• Restrict egress from admin/VIP workstations to business domains only; log LLM/AI endpoints too.

• Block/monitor known AitM proxy infrastructure and fresh domains via TI + DNS sinkhole.

Detection engineering (ready-to-adapt patterns)

Field names vary by platform—treat these as starting points and map to your schema.

1) “Same cookie, new world” (multiple ASNs/regions share a session)

KQL (Microsoft Entra/M365)

SigninLogs
| summarize ips=make_set(IPAddress), asn=make_set(NetworkLocationDetails.asn), uas=make_set(DeviceDetail.browser)
  by UserPrincipalName, SessionId=CorrelationId, bin(TimeGenerated, 12h)
| where array_length(ips) > 1 or array_length(asn) > 1
| where array_length(uas) > 1

2) MFA recently satisfied → surge of risky mailbox changes

let window=2h;
let riskyUsers = SigninLogs
  | where AuthenticationRequirement == "multiFactorAuthentication"
  | where ResultType == 0
  | project UserPrincipalName, CorrelationId, TimeGenerated;
AuditLogs
| where OperationName in ("New-InboxRule","Set-Mailbox","Set-MailboxAutoReplyConfiguration")
| join kind=inner (riskyUsers) on UserPrincipalName
| where TimeGenerated between (riskyUsers_TimeGenerated .. riskyUsers_TimeGenerated + window)

3) OAuth consent spike with broad scopes (Workspace/Entra)

• Alert when new app requests Mail.ReadWrite, Files.ReadWrite.All, offline_access, or tenant-wide admin permissions.

• Tie consent events to unusual IP/ASN or new device for that user.

4) Anomalous token reuse (reverse proxy fingerprints)

• Detect short sequences: successful login → unusual User-Agent/headless browser → high-risk API calls (export, delete, create-rule).

• Flag API calls without referrer/origin typical of real browsers (service APIs).

5) Sigma (Windows) – burst of native tools post sign-in

title: Post-Auth LOLBins Burst (AitM Suspected)
logsource: { product: windows, category: process_creation }
detection:
  sel:
    Image|endswith:
      - '\powershell.exe'
      - '\rundll32.exe'
      - '\bitsadmin.exe'
      - '\cmd.exe'
  timeframe: 30m
  condition: sel
level: high

Incident response playbook (cookie replay suspected)

Hour 0–2 — Contain

• Revoke sessions for implicated accounts; invalidate refresh tokens & OAuth grants.

• Temporarily block consent across the tenant; quarantine newly created apps/rules.

• Geo/IP blocks on observed attacker infrastructure.

Hour 2–12 — Scope

• Build an identity-centric timeline: sign-ins, token minting, consents, mailbox changes, file sharing, admin role assignments.

• Compare device posture (EDR) vs. sign-in device claims.

• Inspect payment-related mailboxes and vendor communications for BEC activity.

Hour 12–48 — Eradicate & recover

• Rotate SSO secrets, app keys, CI/CD credentials touched since compromise.

• Enforce FIDO2 for affected users; shorten token TTLs; enable CAE/step-up.

• Conduct user awareness on AitM indicators (URL mismatches, device code scams, odd MFA prompts).

Build-time protections for developers & SaaS owners

• Origin checks everywhere: strict CSP, same-site cookies, and referer/origin validation for sensitive endpoints.

• Session binding: store server-side fingerprint (device posture, UA family, TLS ciphers) and rotate session IDs after privilege changes.

• Action-level approvals: high-risk verbs (export all, delete mailbox, change payee) require fresh WebAuthn.

• Offer DPoP for public clients and MTLS for confidential clients; publish a clear revocation endpoint.

Red-team simulations to validate readiness

• AitM relay exercise against a decoy tenant (blue team approval; legal safe-harbor).

• Consent storm: submit a benign OAuth app requesting risky scopes; test reviews/detections.

• Session drift: reuse a session across two regions (via lab proxies) and confirm alerts fire.

• Finance callback drill: simulate invoice/bank-change requests; verify human checks.

The CyberDudeBivash quick checklist

• Enforce FIDO2/passkeys for admins & VIPs; plan org-wide rollout.

• Turn on CAE (continuous session evaluation) + short sign-in frequency.

• Block unverified OAuth publishers; require admin approval with ticket reference.

• Monitor for session reuse across ASN/continent and post-auth mailbox changes.

• Restrict egress from admin/VIP hosts; block known AitM infrastruture.

• Tabletop AitM → BEC and AitM → OAuth takeover scenarios quarterly.

Author: CyberDudeBivash
Powered by: CyberDudeBivash
Links: cyberdudebivash.com | cyberbivash.blogspot.com

Hashtags: #CyberDudeBivash #AitM #CookieReplay #SessionHijacking #MFABypass #IdentitySecurity #ZeroTrust #OAuthSecurity #BEC #ThreatHunting #BlueTeam #DFIR #cyberdudebivash