Adversary-in-the-Middle (AiTM) phishing

What adversary-in-the-middle phishing is

Adversary-in-the-Middle phishing, usually shortened to AiTM, is a phishing technique in which the fake page does not merely collect what the victim types. It relays it. The attacker runs a reverse proxy: every keystroke the victim enters is forwarded to the genuine service in real time, and every response from that service is forwarded back to the victim. From the victim's side the login works exactly as it should, because it really is the genuine login, just seen through someone else's server.

The distinction from classic credential harvesting matters. A traditional fake login page is a dead end: it stores a username and password and shows an error or a redirect. If the account is protected by a second factor, the stolen password is often worthless on its own. An AiTM proxy has no such limitation, because it never needs the second factor at all. It waits for the victim to complete authentication and then steals the artefact the service issues afterwards.

How an AiTM attack runs, step by step

The sequence is consistent across campaigns, whatever the branding on the lure. Understanding the order is what lets a defender interrupt it, because two of the six steps leave evidence before any damage is done.

1. The victim receives a lure and follows a link. The domain is a lookalike, or a legitimate service abused as a redirector so the first hop looks clean.
2. The link resolves to the attacker's proxy, which fetches the real sign-in page and serves it back. The rendering is perfect because it is not a copy - it is the real page, relayed.
3. The victim enters their username and password. The proxy records them and passes them upstream to the genuine service.
4. The genuine service issues an MFA challenge. The proxy relays it. The victim approves the push, types the code, or taps the prompt.
5. Authentication succeeds and the genuine service issues a session cookie. The proxy captures that cookie before forwarding the victim on, usually to the real site so nothing looks wrong.
6. The attacker imports the cookie into their own browser and is inside the account, already authenticated, with no password prompt and no MFA challenge.

Step five is the whole attack. A session cookie is the service's own statement that this browser has already proved who it is. Replaying it is not a bypass of authentication so much as a theft of its outcome. Until that session expires or is explicitly revoked, the attacker has the same access the user does.

None of this requires the attacker to be skilled. Reverse-proxy phishing is sold as a subscription service, complete with hosting, lookalike domains, bot filtering and a dashboard of captured sessions. The operator picks a target brand from a list. This commoditisation is the reason the technique moved from research demos to routine within a couple of years, and it belongs alongside the other shifts covered in phishing email examples.

Which forms of MFA AiTM defeats

The useful question is not whether a method is "secure" in the abstract, but whether the secret it produces can be relayed by a proxy. Anything the user reads, types or taps can be relayed. Anything the browser signs against a specific origin cannot.

The pattern in that table is the single most useful thing to take away. Four of the five methods fail for the same reason: they produce a shared secret that the user physically moves from one place to another, and a proxy sitting in the middle gets to see it in transit. The fifth does not fail, because the browser refuses to sign for a domain that is not the real one. This is the same reasoning set out at greater length in can phishing bypass MFA?.

How to spot AiTM in your own logs

Because authentication genuinely succeeds, there is no failed-login spike to alert on. The signals are all about the mismatch between the session the service issued and the session the attacker is now using.

• A successful sign-in from an autonomous system, hosting provider or country the user has no history with, minutes after a legitimate sign-in from their usual location.
• A user agent that does not match any device the person owns - a Linux browser string on an account that only ever signs in from Windows and iOS.
• Session activity that continues from a second location without a fresh authentication event, which is the fingerprint of a replayed cookie rather than a second login.
• A new mailbox forwarding or inbox rule created shortly after sign-in, frequently one that moves security notifications straight to a rarely-opened folder.
• A newly granted OAuth application consent, which gives the attacker access that outlives any password reset you perform later.
• Sign-in telemetry flagged as impossible travel, which catches the crude cases even though a careful operator will proxy through the victim's own region.

The mailbox rule and the OAuth grant are the two most valuable detections on that list, because they are persistence rather than access. An attacker who creates them has decided to stay. They are also the two most commonly missed during clean-up: resetting a password while a forwarding rule and an app consent remain in place means the intruder never actually loses their foothold.

What actually stops it

Be honest with yourself about the order of these. Most of the controls organisations reach for first make AiTM slightly harder. Only one of them makes it structurally not work.

• Phishing-resistant credentials. Passkeys and FIDO2 security keys are origin-bound: the authenticator will not produce a valid assertion for a domain that is not the registered one, so there is nothing for the proxy to relay. This is the control that changes the outcome rather than the odds.
• Conditional access on device compliance. Requiring a managed, compliant device means a stolen cookie replayed from the attacker's own machine fails the policy even though the cookie itself is valid.
• Token protection and shorter session lifetimes. Binding a session to the device it was issued to, and expiring it sooner, shrinks the window in which a captured cookie is worth anything.
• Continuous access evaluation, so that a revoked session actually ends promptly rather than surviving until the token expires on its own schedule.
• Domain and certificate monitoring, which will not stop the attack but will often surface the lookalike domain before the campaign is sent.
• Reporting culture. Users who report the lure - even after interacting with it - buy the response team the minutes that matter, which is the argument made in phishing tests for employees.

Email filtering deserves a mention and a caveat. Gateways do catch a share of these campaigns, but AiTM operators specifically engineer around inspection: links are gated behind a CAPTCHA, filtered by geography so a scanner in the wrong country sees a harmless page, and hosted on infrastructure with a clean reputation for the first few hours of a campaign. Treat the gateway as one layer that reduces volume, never as the control that closes the technique.

What to do if you think it has already happened

A password reset is not containment. The attacker holds a session, not a credential, and a session survives a password change on many platforms unless you explicitly end it. The order below matters more than the speed of any individual step.

1. Revoke the account's active sessions and refresh tokens, then reset the password - in that order, so the new password is not immediately visible to an attacker still holding a live session.
2. Audit mailbox rules, forwarding addresses and delegate permissions on the account, and remove anything created since the suspected compromise.
3. Review OAuth application consents granted by the user and revoke any that are unfamiliar.
4. Check sent items and deleted items for messages the attacker sent onward, since internal phishing from a genuine compromised account is the usual next move.
5. Re-enrol the user on a phishing-resistant credential rather than restoring the same MFA method that was relayed.
6. Look for the same lure in other mailboxes, because these campaigns are rarely aimed at one person.

For an individual rather than an administrator, the immediate steps are set out in I clicked a phishing link - what now?. Worth noting too that AiTM and MFA fatigue are frequently run together: the proxy captures the password, and prompt spam or a fake helpdesk call handles the approval. Neither DMARC nor any other sender-authentication control addresses this technique once the message has been delivered, which is why the defence has to sit at the credential rather than at the mail gateway.