threats

Adversary-in-the-Middle (AiTM) Phishing

Updated October 16, 2026

Adversary-in-the-middle (AiTM) phishing places an attacker-controlled service between a user and a legitimate sign-in service. The attacker relays the interaction and may capture credentials and session material. A successful MFA prompt during that interaction does not necessarily mean the resulting session remains under the user’s exclusive control.

2 min. read

What do I need to know about Adversary-in-the-Middle (AiTM) Phishing?

A proxied login can resemble the real service because much of the experience is being relayed.
Reusable session material can be valuable after the initial login. Investigating only failed password attempts may miss the important activity.
Phishing-resistant authentication binds authentication to the legitimate service more strongly than reusable codes.
AiTM is a technique, not a label that can be confirmed from a suspicious email’s appearance alone.

An illustrative example

A user follows a document link, completes a sign-in and MFA, then returns to normal work. Soon afterward, the account accesses mail from an unexpected context. The investigator correlates the link visit, authentication event, and subsequent session activity rather than interpreting the successful MFA event as an all-clear.

Practical checks

Preserve the original lure, destination information, approximate interaction time, and relevant authentication evidence.
Investigate suspicious session use and contain affected access using the identity provider’s supported response controls.
Review follow-on mailbox actions and prioritize phishing-resistant authentication for exposed workflows.

Five FAQs about Adversary-in-the-Middle (AiTM) Phishing

Is AiTM the same as a fake login form?

A basic fake form collects what a user types. AiTM can relay a live interaction with the real service and capture resulting session material, changing both the evidence and response needs.

Can one-time codes stop every AiTM attempt?

No. Codes can be relayed during a live interaction. Stronger methods designed to resist phishing provide different protection from simply adding a reusable or relayable challenge.

Does a successful MFA event prove the login was legitimate?

No. It records that an authentication requirement was satisfied. Responders still need to examine the destination, device context, session use, and subsequent actions.

Is a password reset sufficient after suspected session theft?

Do not assume it is. Use the provider’s account-containment process and assess sessions, tokens, app permissions, and mailbox changes alongside the password.

Does AiTM require a vulnerability in the real login website?

Not necessarily. The deception can involve a user visiting an attacker-controlled intermediary. That distinction helps explain why patching the legitimate website alone does not address the phishing risk.