Attackers use adversary-in-the-middle kits to place themselves between a user and a legitimate service, capture credentials, and steal session cookies or MFA tokens in real time. These kits defeat some one-time password flows because the session is hijacked after authentication. Defenders should use phishing-resistant MFA, monitor sign-in anomalies, and shorten session lifetime where possible.
How Adversary-in-the-Middle Kits Turn Login Flows Into Session Theft
Adversary-in-the-middle kits work by relaying traffic between the victim and the real service while the attacker quietly sits in the path. That lets the kit collect usernames, passwords, one-time codes, and the authenticated session artefacts that matter more than the password itself. The practical danger is that the victim may complete a normal login while the attacker receives a usable session.
These kits are effective because many users still depend on authentication factors that can be replayed or relayed in real time. Once the attacker has the session cookie or token, they may not need to know the password again. For a deeper view of the phishing and relay patterns behind this tradecraft, see the AiTM Phishing Guide.
In practice, the kit is not trying to defeat the login page by force. It is trying to preserve the illusion of a normal authentication flow long enough to steal the authenticated state. That is why session protection, token binding where available, and phishing-resistant MFA are more important than password complexity alone.
Why MFA Can Still Fail When the Session Is Stolen
AiTM kits are a good example of how authentication and session management are different problems. Even if the user successfully completes MFA, the attacker can capture the resulting session and ride it as if they were the user. That is why OTP-based flows are weaker than phishing-resistant methods when the adversary can proxy the entire exchange.
The same pattern shows up across identity providers and SSO stacks, where the value of the attack is often in the post-authentication token rather than the credential pair. If your login flow issues long-lived or broadly reusable sessions, the attacker’s job becomes easier even when the initial MFA prompt looks strong. The Identity Provider and SSO Security Guide is useful for understanding where session, federation, and recovery controls tend to weaken the boundary.
Another reason these kits succeed is human timing. The user is often responding to a convincing prompt at exactly the moment the attacker needs the session to be minted. That makes the attack less about cracking credentials and more about intercepting trust at the point where the service accepts the login as legitimate. A broader comparison of MFA methods and bypass patterns is covered in the MFA Guide.
What Defenders Should Look For After an AiTM Login
Once the session is stolen, the attacker often behaves like a normal user first. That means successful logins alone are not enough to prove safety. Defenders should look for impossible travel, unusual device or browser fingerprints, unfamiliar IP reputation, new MFA enrolment attempts, changes to recovery settings, and any follow-on mailbox, file, or admin activity that does not fit the user’s usual pattern.
Session theft also makes blast-radius thinking important. A compromised session can expose mail, chat, cloud apps, password reset paths, and downstream SSO-linked services without ever triggering another password prompt. That is why monitoring should focus on what the session can do next, not only how it was obtained. The Workforce Identity Security Guide is a practical reference for phishing-resistant MFA, session theft, and recovery-path hardening.
Where authentication logs are available, defenders should correlate the login with token issuance, device registration, and any immediate privilege or recovery changes. That sequence often tells you more than a single sign-in event. If the user approved a prompt but the resulting activity looks mechanically normal and geographically or behaviourally odd, treat the session itself as suspect.
Risk and Threat Considerations
AiTM kits are dangerous because they break the assumption that successful MFA means the session is trustworthy. Once the attacker has a valid session, they can access the same resources as the user and may bypass controls that only inspect the initial login event.
Failure mechanism: The attacker proxies the login in real time, captures the session artefact after authentication, and reuses it before it expires or is bound to a stronger trust signal.
Impact: The victim can appear fully authenticated while the attacker gains access to mail, cloud apps, internal portals, and any linked workflows that accept the stolen session.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-63 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | N/A — Digital Identity Guidelines | Relay attacks target authentication assurance and session trust after login. |
| Recommendation — Use phishing-resistant authenticators and strengthen session assurance against relayed logins. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | AiTM kits abuse the login process for organizational users. |
| IA-5 — Authenticator Management | The attack steals and reuses authenticators and session material. | |
| AC-2 — Account Management | Session theft often leads to account misuse and recovery-path abuse. | |
| Recommendation — Require stronger user authentication that resists credential relay and token theft. Shorten authenticator and session lifetimes, and revoke compromised session material quickly. Review account recovery and disable stale access paths that can amplify stolen sessions. | ||
| MITRE ATT&CK | T1550 — Use Alternate Authentication Material | AiTM kits steal session cookies and tokens to impersonate the user. |
| Recommendation — Hunt for stolen session material and investigate authentication replay paths. | ||
Practitioner Guidance
What to prioritise: Treat phishing-resistant MFA and short session lifetime as the primary controls when the threat model includes relay or token theft. If you cannot eliminate replayable authentication factors immediately, reduce session value by tightening reauthentication thresholds and recovery-path exposure.
What to verify: Confirm that sign-in logs, token issuance, and session revocation are visible enough to support fast investigation. If you cannot distinguish a genuine login from a relayed one in telemetry, assume you are relying too heavily on the front door and not enough on session behaviour.
Practitioner takeaway: The real control objective is not just proving that the user authenticated, but limiting how much authority the resulting session can carry if an attacker successfully steals it.