sysop@hub:~/explainers/aitm-phishing-explained$

aitm-phishing-explained

How an AiTM phishing attack steals a session

Adversary-in-the-middle phishing relays a real sign-in, MFA included, and steals the session cookie afterwards.

Read the steps as text

Phishing email. The victim gets a message with a link to a look-alike domain that the attacker controls.
Opens the link. The proxy fetches the real Microsoft sign-in page live and shows it to the victim. It looks exactly like the real thing.
Relays credentials. The victim types username and password. The proxy forwards them to the real sign-in page.
MFA prompt and approval. Entra ID asks for MFA and the proxy passes the prompt to the victim, who approves it or enters the code. The proxy relays the answer. The MFA is genuine, it is just relayed.
Session cookie. After the successful sign-in Entra ID issues a session cookie. The proxy sits in the middle and copies it. This is the moment the attacker wins: the cookie is proof of a completed MFA.
Replays the cookie. The attacker uses the stolen cookie to open the mailbox. No password or MFA prompt appears because the session already counts as authenticated.

Use phishing-resistant MFA: FIDO2 security keys, passkeys or Windows Hello for Business. The credential is bound to the real domain, so it does not work on a look-alike site.
Use Conditional Access that requires a compliant or managed device, so a cookie replayed from another machine fails.
Use token protection where it is supported, and keep session lifetimes short for sensitive apps.
Watch sign-in logs for sessions that suddenly move to a new IP address or device, and for new inbox rules after a sign-in.
Train users to check the address bar and to report suspicious sign-in pages.