Cyberdudebivash

AitM Cookie Replay — How Adversaries Bypass MFA Without Dropping Malware By CyberDudeBivash — your daily dose of ruthless, engineering-grade threat intel

, , ,

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

Leave a comment

Design a site like this with WordPress.com
Get started