The user enters credentials into a page that looks normal, but the proxy relays them to the real service and checks whether they work. If the password is correct, the attacker can capture the active session and reuse it without re-entering the password. That is what makes adversary-in-the-middle phishing so effective against accounts protected by multi-factor authentication.
How the proxy turns a fake sign-in page into live credential replay
The key shift is that the attacker is no longer waiting for a delayed password reset or a later reuse opportunity. The proxy validates the credentials immediately against the legitimate service, so the attacker learns in real time whether the user has entered a working password and can move straight to session capture while the authentication flow is still active.
That matters because the login form is only the lure. The real control point is the live relay: the proxy can pass back the same challenge, preserve the victim’s experience, and then harvest the authenticated browser session or token after the service accepts the login.
In practice, this means the event is not just “phishing with a better website.” It is a man-in-the-middle style workflow that combines social engineering, credential verification, and session theft into a single transaction. The attacker does not need to crack the password if the victim hands over a valid one during the live exchange.
For practitioners, the practical implication is that the boundary of trust is the session, not the password entry screen. If the session can be relayed or replayed after authentication, strong password policy alone does not stop the attack path.
Why this attack defeats MFA so often
Adversary-in-the-middle phishing is effective because many MFA methods confirm the user at login time but do not bind that proof to the specific browser session or destination. Once the proxy has the working password and the second factor is accepted, the attacker can often inherit the authenticated session without asking the victim to repeat any step.
The weak point is not simply “MFA was bypassed.” The weak point is that the attacker sits between the user and the real service, so the proxy can forward every prompt and every approval in sequence. If the authentication ceremony is not resistant to relay, the attacker can transform a one-time login into persistent access.
That is why the safest interpretation of this pattern is session theft enabled by credential relay, not generic phishing. The fake page is only there to create a trusted-looking moment for the victim to authenticate into an attacker-controlled path.
Teams should treat any control that relies only on reusable secrets or relayed second factors as vulnerable to this class of abuse, especially when the authenticated browser session grants access to mail, identity portals, cloud consoles, or other high-value services.
Risk and Threat Considerations
This technique creates a high-confidence account takeover path because the attacker can validate credentials immediately and then reuse the authenticated session before the victim notices anything unusual. The biggest exposure is not the password itself, but the fact that a live session can be captured and reused as if the legitimate user were still present.
Failure mechanism: The attacker relays the login in real time, forwards the successful authentication to the target service, and then steals the resulting session artifact or browser state. If the target service does not strongly bind the session to the original client or require phishing-resistant authentication, the attacker can continue operating as the user.
Impact: Successful relay can bypass conventional MFA, enable mailbox or cloud-console takeover, and create a foothold for lateral movement, data theft, or further identity abuse. The compromise often looks like a normal login until downstream activity reveals that the session was never truly under the user’s control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A1 — Agent Identity and Access Control | Live relay and session reuse are access-control problems for authenticated agents. |
| Recommendation — Bind authentication to the intended client and block relayable session reuse. | ||
| NIST CSF 2.0 | PR.AA-01 — Identity and Access Management | This attack exploits weak identity assurance and session trust after login. |
| Recommendation — Use phishing-resistant authentication and strengthen session controls for critical accounts. | ||
| CIS Controls v8 | 6 — Access Control Management | Stopping relayed login abuse depends on restricting and verifying access paths. |
| Recommendation — Restrict access paths and enforce stronger authentication for sensitive systems. | ||
| MITRE ATT&CK | T1566 — Phishing | A fake login portal is the delivery mechanism for credential theft and relay. |
| T1557 — Adversary-in-the-Middle | The core technique is live interception and relay between user and service. | |
| Recommendation — Detect and disrupt phishing delivery paths that collect credentials in real time. Hunt for proxy-based interception and session hijacking indicators in authentication traffic. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | The attack depends on capturing usable authentication material during login relay. |
| NHI-06 — Authentication and Session Risks | Session capture after successful relay is the decisive failure mode here. | |
| Recommendation — Treat relayed credentials and sessions as exposed secrets and rotate or invalidate them quickly. Require session binding and limit reuse of tokens captured after authentication. | ||
Practitioner Guidance
What to verify: Confirm whether your highest-value applications accept relayed authentication flows and whether session cookies, tokens, or browser sessions can be reused from a different client context. If they can, assume the control is vulnerable to real-time proxy abuse even when MFA is enabled.
Decision rule: If an account can reach sensitive data or administrative functions, prioritise phishing-resistant authentication and session hardening over additional password policy tuning. The question is whether the login proof can be relayed, not whether the password is strong.
What practitioners underestimate: Many teams look for password reuse or credential stuffing indicators after the fact, but this attack often succeeds on the first attempt. The more useful signal is unusual session acquisition, suspicious redirect chains, and sign-ins that are valid but inconsistent with the user’s normal client or location profile.
Practitioner takeaway: When a login can be proxied live, the security problem is session portability, so the control objective should be to make authentication resistant to relay and make stolen sessions difficult to reuse.
Related resources from NHI Mgmt Group
- What happens when an ITDR tool cannot trigger MFA or block access in real time?
- What happens when users enter credentials into a fake login page that proxies a real identity provider session?
- What happens when attackers use an internal OAuth application instead of creating a new one?
- How should organisations defend against credential stuffing without creating excessive login friction for legitimate users?
