1) What is AiTM—really?

Adversary-in-the-Middle (AiTM) is a live interception technique where an attacker proxies traffic between a victim and a legitimate service to steal session artifacts (cookies/tokens) or alter requests. Unlike classic MITM that sniffs traffic, AiTM actively relays the user’s login flow so the victim still reaches the real site—but through the attacker’s reverse proxy.

Why it’s scary: AiTM bypasses OTP/MFA by capturing the post-MFA session (bearer cookie or OAuth token). Once the attacker holds a valid session, they log in as you—no password or code needed.

2) The AiTM kill chain (end-to-end)

1. Lure – Phish via email/SMS/IM/QR → link points to attacker’s domain that impersonates the target IdP/app.

2. Reverse proxy – Tools (e.g., Evilginx-style) terminate TLS at attacker → open second TLS to real IdP/app.

3. Credential & MFA relay – Victim enters username/password and MFA; attacker relays in real time.

4. Session capture – Reverse proxy snags Set-Cookie / Authorization headers (OIDC/SAML result).

5. Account takeover – Attacker replays session from their host; adds forwards, app consents, tokens, creates backdoors.

6. Persistence & pivot – Register OAuth apps, create access keys, add inbox/transport rules, new devices, or bypass policies.

3) Protocols & artifacts attackers abuse

• HTTP(S) & TLS: TLS is not broken—users talk TLS to the attacker, and the attacker talks TLS to the real site.

• SAML / OIDC (OAuth2): The prize is session cookies (e.g., ESTSAUTH, FedAuth) or bearer tokens (id_token/access_token).

• MFA flows: TOTP/SMS/push are relay-able; FIDO2/WebAuthn resists (origin-bound, device-bound).

• Mail & SaaS: Post-login API calls (Graph, Gmail API, Slack, Salesforce) with stolen tokens enable silent exfil.

4) Variants you’ll see in the wild

• Reverse-proxy phishing kits: One-click frameworks that generate phishing domains, TLS certs, and relay flows.

• AiTB (Adversary-in-the-Browser): Malicious browser extensions inject JS to steal tokens after login.

• Device-registration abuse: Post-AoD (proof-up) flows that allow adding a “trusted device” to survive re-auth.

• OAuth consent hijack: Trick users into granting a malicious app wide scopes (Mail.Read, Files.ReadWrite)—no password theft needed.

5) What it looks like in logs (detections that actually pop)

A) Identity (Entra ID/Okta/Google Workspace) – KQL-style ideas

kusto
CopyEdit
// Fresh session from rare ASN right after user MFA success
SigninLogs
| where ResultType == 0 and AuthenticationRequirement == "multiFactorAuthentication"
| summarize makeset(IPAddress), makeset(ConditionalAccessPolicies) by UserPrincipalName, bin(TimeGenerated, 15m)
| where array_length(set_IPAddress) > 1  // multiple IPs in short window

kusto
CopyEdit
// Suspicious consent or service principal additions
AuditLogs
| where OperationName in ("Add service principal","Add app role assignment to service principal","Consent to application")

B) Mail abuse (Exchange Online)

kusto
CopyEdit
OfficeActivity
| where Workload == "Exchange"
| where Operation in ("New-InboxRule","Set-InboxRule","UpdateInboxRules","New-TransportRule")
| where Parameters has_any ("ForwardTo","RedirectTo","External")

C) Web telemetry (WAF/Proxy/SIEM)

• JA3/JA4 fingerprint anomalies to login endpoints.

• New ASN / headless UA hitting /authorize, /login, /saml followed by Graph/API calls.

• Set-Cookie captured via proxy patterns; sudden user IP change mid-session.

6) Break the AiTM kill chain (controls that work)

A) Strong MFA that’s AiTM-resistant

• FIDO2/WebAuthn (passkeys) with user verification.

• Enforce MFA strength policies (hardware key > push/TOTP > SMS).

• Disable legacy MFA “approve-only” prompts (fight MFA fatigue).

B) Bind tokens & sessions to the client

• Continuous access evaluation (CAE) + Conditional Access → real-time token invalidation, device/location checks.

• Prefer proof-of-possession tokens (DPoP / OAuth mTLS) over bearer tokens.

• SameSite=Strict cookies, short TTL, re-auth for sensitive ops.

C) Origin & device attestation

• Enforce App/Browser-based access: known clients with device compliance (MDM, Defender/EDR posture).

• Block unknown/unsupported browsers; require device identity with claims in tokens.

D) Phishing-resistant IdP posture

• Custom domain + HSTS + TLS1.2+; disallow basic/legacy protocols (IMAP/POP/BasicAuth/EWS where possible).

• Block consumer sign-ins; geo/ASN allowlists for admin roles; step-up for risky sign-ins.

E) OAuth hygiene

• Tenant-wide admin consent policies; app allowlists; user consent off for risky scopes.

• Alert on high-privilege scopes (Mail.ReadWrite, Files.ReadWrite.All, offline_access).

• Rotate/revoke refresh tokens; monitor ServicePrincipal activity.

F) Mail exfil & persistence controls

• Block external auto-forward, disable legacy “redirect” rules, alert on transport rule creation.

• Quarantine suspicious newly created rules; require approval for org-wide rules.

7) Incident response (AiTM edition)

1. Contain sessions – Revoke refresh/access tokens; invalidate cookies (CAE, sign-out everywhere).

2. Kick out persistence – Remove inbox/transport rules, unknown app consents, service principals, device enrollments.

3. Reset trust – Enforce password & MFA reset; require passkeys rollout for affected users.

4. Hunt – Review sign-ins by IP/ASN/UA; check Graph/API access post-compromise; search for staged exports.

5. Recover & harden – CA policies for device/location, disable weak MFA, deploy DPoP/WebAuthn, mail-forward controls.

8) Red-team notes (so blue can block)

• Phish kits front IdP look-alikes with Let’s Encrypt certs and perfect favicons.

• Timing is tight—AiTM kits relay OTP within seconds. Push MFA fatigue to increase success.

• After foothold, register OAuth apps for stealth; forward mail quietly instead of bulk downloads.

9) Quick executive brief

AiTM is the #1 way MFA gets bypassed today. It steals sessions, not passwords. Deploy WebAuthn passkeys, proof-of-possession tokens, strict Conditional Access, and OAuth consent controls. Monitor for inbox/transport rules and new service principals. Treat any AiTM sign-in as a full account compromise.

MITRE ATT&CK mapping

• Initial Access: T1566 (Phishing), T1189 (Drive-by)

• Credential Access: T1556.004 (Credential-in-the-Middle), T1110 (Brute Force – relayed MFA)

• Defense Evasion/Persistence: T1098 (Account Manipulation), T1136 (Create Account), T1098.003 (Add App Roles)

• Collection/Exfil: T1114 (Email Collection), T1567 (Exfil over Web Services)

• Command & Control: T1102 (Web Service), T1071.001 (Web Protocols)