AiTM Phishing Guide: Evilginx, Tycoon and Token Theft

Adversary-in-the-middle (AiTM) phishing defeats passwords, one-time codes and push approvals in a single step, because the attacker relays a real sign-in and keeps the session cookie that comes back. Kits rented as phishing-as-a-service have made this a routine attack on Microsoft 365 and Google workforce accounts, and device code phishing reaches the same outcome without a proxy. This guide explains both at technique level, the kits defenders will see in reporting, which authentication methods resist them, and the identity controls, detections and response steps that close the gap. It is for identity engineers, architects and SOC teams; for phishing in general see the Phishing Guide.

Key takeaways

• AiTM steals the session, not just the password. A reverse proxy relays the user's real sign-in, including MFA, and captures the session cookie, so the attacker never needs to authenticate again while the cookie lives.
• Only origin-bound authenticators break the relay. FIDO2 security keys, passkeys, Windows Hello for Business and certificate-based authentication do not release a usable response to a look-alike domain; OTP codes, push approvals and SMS all do.
• Device code phishing needs a separate control. The user signs in on the genuine Microsoft page, so phishing-resistant MFA does not stop it; block the device code flow with an authentication flows policy and allow it only where a device has no keyboard.
• Bind sessions to managed devices. Requiring a compliant or joined device, plus token protection where supported, means a replayed cookie or token from attacker infrastructure fails Conditional Access.
• Revoke, do not just reset. A password reset alone leaves stolen refresh tokens and attacker-registered MFA methods in place; response must revoke sessions, remove added methods and devices, and delete inbox rules.

How AiTM phishing works

In classic credential phishing the fake page collects a password and stops. In AiTM phishing the attacker runs a reverse proxy that sits between the victim and the legitimate sign-in service. Every page the victim sees is the real one, relayed through the attacker's domain, so branding, error messages and the MFA prompt are all genuine. Microsoft Threat Intelligence, describing a campaign that tried to reach more than 10,000 organisations from September 2021, put it simply: "The URL is the only visible difference." When the user completes sign-in, the identity provider issues a session cookie, the proxy keeps a copy and the attacker imports it into their own browser.

Microsoft is explicit that "this is not a vulnerability in MFA": the user really did authenticate, and the cookie can carry an MFA claim. The move to money is fast: in the same campaign, payment fraud began within about five minutes of the session being stolen. The attackers searched mailboxes for finance threads, created inbox rules to hide replies from the people they were defrauding and deleted evidence, then used the trusted mailbox for follow-on business email compromise. See the Email Identity and BEC Guide.

• Reverse-proxy relay: the proxy forwards traffic both ways and captures credentials, codes and cookies as they pass. This is what Evilginx, Modlishka and Muraena do, and what most commercial kits package.
• Synchronous relay pages: several kits show their own copy of the sign-in page and relay what the user enters to the real service in real time. The outcome, a stolen session, is the same.
• Token use after capture: the attacker reaches mail, files and Microsoft Graph, often through non-interactive sign-ins users never see.

The AiTM kit ecosystem

Sekoia's June 2025 analysis ranked the kits most prevalent from January to April 2025 and found they mainly target Microsoft 365 and, less often, Google accounts. Kits are typically rented on monthly subscriptions, generally between $100 and $1,000, which lowers the skill needed. The table is for recognition, not attribution.

Kit names change faster than controls, so indicator blocking supports the defence but is not it. Lures increasingly arrive as QR codes, HTML attachments and SVG files, which moves the click onto phones outside managed browsers. Every kit ends in the same artefact, a stolen session, so the controls below work whichever kit is used.

Device code phishing

Device code phishing reaches the same result as AiTM without a proxy. The OAuth 2.0 device authorization grant exists for devices with no keyboard: the device shows a short code, the user enters it on a genuine sign-in page from another device, and tokens are issued to the waiting device. In device code phishing the attacker starts that flow, sends the code to the victim with a pretext, and the victim authenticates on the real Microsoft page. The tokens go to the attacker. ATT&CK v20 now describes device code phishing under Spearphishing Link (T1566.002), and the resulting token theft sits under Steal Application Access Token (T1528).

Microsoft reported that Storm-2372, active since August 2024 and assessed with moderate confidence as aligned with Russian interests, used this method against government, NGO, IT, defence, telecoms, health, education and energy organisations. The actor used the tokens to search mail through Microsoft Graph and later shifted to the Microsoft Authentication Broker client ID, which let it register an attacker-controlled device in Entra ID and obtain a Primary Refresh Token (PRT). That turns a phished session into a device identity.

• Block the flow: Microsoft Learn calls device code flow "a high-risk authentication method that can be part of a phishing attack" and recommends "blocking device code flow wherever possible" using the Conditional Access authentication flows condition.
• Allow by exception: only for input-less devices such as digital signage, scoped by platform and location.
• Know the side effects: device code sessions stay protocol tracked through later refreshes, and policies targeting all resources also cover the Device Registration Service (client ID 01cb2876-7ebd-4aa4-9cc9-d28bd4d359a9, which needs excluding if device code is used for registration). Blocked refresh tokens return AADSTS530036.
• Restrict device registration: limit which users can register or join devices, so a phished token cannot become a PRT.

ATT&CK mapping

IDs checked against ATT&CK v20. The T1557 sub-techniques (.001 to .004) are network-layer attacks such as ARP poisoning; web reverse-proxy phishing sits at the parent technique.

Which authentication methods resist AiTM

NIST SP 800-63B-4 is direct: passwords, look-up secrets, out-of-band authenticators and OTPs are "not phishing-resistant". Manual OTP entry fails because "an impostor verifier could relay an authenticator output". Phishing resistance comes from verifier name binding, where the authenticator output is cryptographically bound to the site it is used on, or channel binding. That is the property that breaks a reverse proxy: a passkey created for the real domain is simply not offered to the attacker's domain. CISA's fact sheet reaches the same conclusion, calling FIDO/WebAuthn "the only widely available phishing-resistant authentication", with PKI-based smart cards as the less widely available alternative.

Authenticator strength protects the sign-in moment; device binding protects the session afterwards. A cookie stolen by an infostealer from a security key user is still a valid cookie. See the Passwordless and Passkeys Guide and the Hardware Security Keys Guide.

Controls that close the gap

Phishing-resistant authentication, enforced

• Enforce through policy, not enrolment: in Microsoft Entra, the Conditional Access grant Require authentication strength with the built-in phishing-resistant MFA strength stops the weaker path being chosen. Registration alone does not.
• Remove fallbacks: if SMS, voice or OTP remain allowed, the proxy simply asks for them. See the MFA Fatigue and Bypass Guide.
• Protect registration: require a phishing-resistant credential or a time-limited access pass to register new methods, otherwise a proxied session can add the attacker's authenticator.

Bind the session to a device

• Require a compliant or joined device: both Microsoft's AiTM guidance and ATT&CK mitigation M1032 recommend Conditional Access that only admits trusted devices. The attacker's browser is not enrolled, so the replayed cookie fails policy. See the Device Trust and Posture Guide.
• Token protection: this Conditional Access session control accepts only device-bound sign-in session tokens such as PRTs, so "even if a threat actor steals the token, it can't be used from another device". Native clients for Exchange Online, SharePoint Online and Teams are generally available on Windows, macOS and iOS/iPadOS (Apple devices must be MDM managed, macOS 14 or later, iOS 16 or later); browser support is in preview for selected web apps only.
• Session lifetime: NIST SP 800-63B-4 sets the AAL2 overall reauthentication timeout at no more than 24 hours (SHOULD) with an inactivity timeout of no more than one hour, and AAL3 at no more than 12 hours (SHALL) with 15 minutes inactivity. Sign-in frequency policies for sensitive apps shrink the window a stolen cookie is useful.

Evaluate continuously

• Continuous Access Evaluation (CAE): Exchange Online, SharePoint Online and Teams act on critical events in near real time (up to 15 minutes): account disabled or deleted, password changed or reset, MFA enabled, all refresh tokens revoked by an administrator, and high user risk. IP location enforcement is instant. CAE tokens can last up to 28 hours, so revocation, not expiry, is the control.
• Risk-based policies: sign-in and user risk conditions block or force reauthentication when Identity Protection flags an anomalous token or unfamiliar sign-in properties.

Reduce the click

Link detonation, QR code and SVG attachment inspection and browser reputation blocking cut volume, and blocking end-user consent to unverified OAuth apps (M1021 under T1528) stops a proxied session granting a persistent app. See the Enterprise Browser and Browser Security Guide.

Choosing controls for your organisation

• Security keys or platform passkeys: choose device-bound FIDO2 keys for administrators, finance approvers and help desk staff, where NIST AAL3 or non-exportable keys matter. Choose Windows Hello for Business or platform passkeys for the general workforce on managed devices, where there is nothing extra to issue. Synced passkeys suit customers and bring-your-own-device staff but cannot meet AAL3.
• Device compliance or token protection: device compliance works across browsers and apps today and is the broader control; token protection adds cryptographic binding but covers fewer resources. Use compliance as the baseline and add token protection for the apps it supports.
• Small organisations: enforce phishing-resistant authentication for email and the identity provider, block device code flow and legacy authentication, require managed devices for administrators and turn on built-in risk detections. That covers most of the exposure without a SOC.
• Large organisations: expect exceptions: shared workstations, contractors on unmanaged devices, input-less devices that need device code flow and guest accounts (CAE does not support guests). Make each a named, time-limited exception group with compensating controls such as a virtual desktop.

How to implement

1. Baseline: export a month of sign-in logs and count users by MFA method, device state and device code use (the authentication protocol filter). This shows who breaks when you enforce.
2. Protect administrators first: issue FIDO2 keys and enforce the phishing-resistant authentication strength for privileged roles. CISA recommends starting with IT administrators and help desk staff, then email, remote access and identity systems.
3. Block device code flow in report-only mode: review the report for a full business cycle, build the exception group for legitimate input-less devices, then enforce.
4. Require compliant devices in rings: IT, then one business unit, then everyone, excluding two monitored break-glass accounts.
5. Add token protection: report-only first, reviewing interactive and non-interactive sign-ins across normal use, then enforce for known reliable users.
6. Remove fallbacks: once phishing-resistant coverage passes target, disable SMS, voice and OTP for enforced groups.
7. Roll back safely: rollback means switching a policy back to report-only, not deleting it. Policy changes can take up to a day to reach CAE-enabled services, so revoke sessions when a change must apply at once.

Detection and measurement

AiTM leaves its clearest traces in identity and mailbox logs. Microsoft's token theft playbook notes that some detections, such as anomalous token, have no SigninLogs row, so collect AuditLogs and OfficeActivity and stream Identity Protection risk tables to the SIEM. See the ITDR Guide.

Metrics that show the programme is working:

• Phishing-resistant coverage: percentage of sign-ins, not users, satisfied by a phishing-resistant method, split by privileged and standard accounts.
• Managed-device share: percentage of sign-ins to email and files from compliant or joined devices.
• Device code exposure: device code sign-ins per week outside the exception group (target zero).
• Time to revoke: median minutes from a token theft alert to session revocation, measured against the five-minute fraud window Microsoft observed.
• Fallback population: number of accounts still allowed SMS, voice or OTP.

Responding to a stolen session

Microsoft's playbook states that "containment, or mitigation, is prioritized over information gathering". A password reset alone is not containment. See the Account Takeover Prevention Guide and the Incident Response Guide.

1. Revoke sessions: revoke all refresh tokens (revokeSignInSessions in Microsoft Graph, Revoke-MgUserSignInSession in PowerShell, or Revoke sessions in the portal); CAE-capable services act on this within minutes.
2. Reset the password and mark the user compromised in Identity Protection; for hybrid accounts the playbook advises resetting the password twice.
3. Remove persistence: delete MFA methods and devices registered during the attack window, inbox and forwarding rules, and OAuth consents granted to unknown apps.
4. Scope: find every user who clicked the same URL or signed in from the same IP or user agent, and review changes made by affected privileged accounts.
5. Warn counterparties: if mail was read, alert suppliers and customers in those threads to expect payment instruction fraud.

Framework mapping

Common failure patterns

• Calling OTP "strong MFA": codes from apps or hardware tokens are relayed in real time. The Dropbox GitHub breach began with a fake CircleCI login that collected credentials and a one-time code, and the Twilio 0ktapus campaign used SMS lures to harvest employee sign-ins.
• Phishing-resistant MFA registered but not required: users enrol keys, policy still accepts push or SMS, and the proxy asks for the weaker method.
• Treating sign-in as the end of the problem: session cookies outlive the authentication that created them. The CircleCI breach shows a stolen, already-authenticated SSO session being used directly; device binding and short sessions are the answer, not a stronger authenticator.
• Leaving device code flow open to everyone: it is enabled by default for most tenants and bypasses every authenticator choice.
• Reset without revoke: the password changes, the attacker's refresh token, registered authenticator and inbox rule survive.
• Exception creep: rollout exclusions are never reviewed and become the attacker's path.

Practitioner checklist

• Enforce a phishing-resistant authentication strength for administrators, finance and help desk staff first, then everyone.
• Remove SMS, voice and OTP fallbacks for every enforced group.
• Block device code flow with an authentication flows policy and keep a reviewed exception group.
• Restrict who can register or join devices and who can register security information.
• Require compliant or joined devices for email, files and admin portals; add token protection where supported.
• Enable CAE and risk-based Conditional Access, and stream identity risk tables to the SIEM.
• Alert on inbox rules, MFA method changes and device registrations that follow a risky sign-in.
• Test a token theft runbook that revokes sessions first, quarterly.

Standards and references

• NIST: SP 800-63B-4 Authentication and Authenticator Management
• CISA: Implementing Phishing-Resistant MFA
• MITRE ATT&CK: T1539 Steal Web Session Cookie
• MITRE ATT&CK: T1557 Adversary-in-the-Middle
• Microsoft Learn: Token protection in Conditional Access
• Microsoft Learn: Authentication flows in Conditional Access
• Microsoft Threat Intelligence: From cookie theft to BEC, AiTM phishing sites as entry point to financial fraud
• Sekoia: Global analysis of Adversary-in-the-Middle phishing threats

Related NHI Mgmt Group resources: Phishing Guide · MFA Fatigue and Bypass Guide · Passwordless and Passkeys Guide · Conditional Access Guide · Token and Session Security Guide