Adversary-in-the-Middle Session Theft Scams

An adversary-in-the-middle (AiTM) session theft attack is a sophisticated form of credential interception that goes beyond capturing usernames and passwords. Instead of — or in addition to — stealing credentials, the attack captures the authenticated session token that a website issues after you successfully log in and complete any two-factor authentication step. With this token, the attacker can access your account directly without needing your password or your authentication code.

Session tokens are the mechanism by which websites recognise you as logged in: after you authenticate, the site sets a cookie or provides a token that your browser presents on every subsequent request. This is what allows you to stay logged in without re-entering credentials for every page. A stolen session token is functionally equivalent to an authenticated login — the attacker can perform all the same actions you can within the session.

The AiTM technique is most commonly executed through reverse-proxy phishing pages: fake login sites that do not just collect your credentials but act as a live proxy between your browser and the genuine website. You interact with what appears to be the real site, the real site processes your login and sends back a session token, and the attacker's proxy intercepts and stores that token — all in real time, within the seconds it takes you to log in.

This approach defeats SMS and app-based two-factor authentication because the attack captures the session after authentication has been completed, not during it. The attacker does not need to know your one-time code — they just need the resulting session.

The attack begins with a phishing link: an email, SMS, or message containing a URL that appears to belong to the genuine service but actually points to the attacker's reverse-proxy server. When you click the link and navigate to the page, the proxy silently fetches the genuine login page from the real site and displays it to you.

You enter your credentials on what appears to be the real site. The proxy forwards these to the genuine site. The real site sends back any two-factor authentication challenge — an SMS code, an authenticator app prompt — which the proxy displays to you. You complete the authentication. The real site issues a session token and sets your browser cookies. The proxy captures these tokens before your browser receives them.

At this point, the attacker has an authenticated session. They can import the captured cookies into their own browser and access your account immediately, while you may also be logged in and unaware that anything unusual happened. Some proxies then redirect you to the genuine site or show a fake confirmation to prevent immediate suspicion.

The attack is particularly dangerous against high-value accounts such as banking, corporate email, and cryptocurrency because the session gives the attacker the same access you have — with no further authentication required during the session lifetime.

AiTM attacks succeed because they exploit a fundamental architecture of web authentication: session tokens. Two-factor authentication was designed to prevent credential theft, and it does — but it does not protect the session token that results from successful authentication. The attack moves one step later in the authentication flow to capture the thing that two-factor authentication was not designed to protect.

For users, the interaction feels entirely normal — they see what appears to be the genuine site, receive a real authentication code from the genuine service, complete a familiar process, and reach what appears to be the genuine destination. There is no visible indication that anything has gone wrong.

PhaaS toolkits have made this attack accessible to criminals without deep technical expertise, significantly increasing the volume of AiTM phishing observed in the wild.

A person receives an email appearing to be from their corporate email provider, warning that their password is about to expire. The link in the email leads to what looks exactly like the genuine login page. They enter their credentials and receive their usual authenticator code prompt, which they complete. They land on the genuine inbox. An hour later, the attacker uses the captured session token to access the corporate email account, export the contacts list, and set up a mail forwarding rule to an external address. The person is unaware until the IT security team flags the suspicious forwarding rule the following day.

Your [email service] password expires in 24 hours. Update it here to maintain access: [fake proxy link]

Security alert: a new sign-in to your [bank] was attempted. Verify your identity to protect your account: [fake proxy link]

[Crypto exchange]: Complete your identity verification to maintain full account access: [fake proxy link]

Action required: confirm your [service] account credentials to avoid suspension: [fake proxy link]

The primary technical defence against AiTM attacks is a hardware security key (FIDO2 passkey or WebAuthn). Hardware keys are cryptographically bound to the exact domain of the genuine service. When a reverse-proxy phishing page tries to relay an authentication request from the hardware key, the key refuses because the domain does not match — it detects the proxy regardless of how convincing the page looks.

App-based authenticators and SMS codes do not provide this domain-binding property and can be relayed in real time. If you protect high-value accounts with a hardware key, AiTM attacks cannot succeed against those accounts regardless of whether you land on a phishing proxy page.

For accounts that do not support hardware keys, the best available behavioural defence is navigating directly to services rather than following links in messages, and using a password manager that autofills only on exact matching domains — the manager will decline to fill on a proxy page, providing a passive warning.