What happens when a banking user completes MFA on a fake reverse proxy site?

When the user completes MFA on a fake reverse proxy site, the attacker can intercept the authenticated session and steal the resulting token or code in transit. That can allow unauthorized access to the banking account even though the victim used a second factor. From there, the attacker may move quickly into fraud, account manipulation, or resale of access.

What the Fake Reverse Proxy Is Actually Doing

A fake reverse proxy sits between the user and the real banking site and relays logins in real time. The victim still sees a convincing login flow, but the attacker is capturing the session material that comes back from the bank after MFA succeeds. That makes the attack especially effective against phishing-resistant users who would otherwise trust the second factor.

The important detail is that MFA has not “failed” in the normal sense. The attacker is not necessarily breaking the factor itself; they are abusing the fact that a valid login session can be handed to the wrong party if the user authenticates through a hostile intermediary. In practice, the attacker often gets a usable session cookie, token, or authorization code immediately after completion.

That is why real-time proxy attacks are often treated as a session theft problem as much as a credential theft problem. Once the session is replayable, the attacker can act as the user until the bank detects and invalidates the session or forces step-up controls.

How Access Turns Into Fraud

After session interception, the attacker can usually work faster than the victim can notice. Banking portals often expose payee management, transfers, card controls, contact details, and notification settings from the same authenticated session. If the account allows high-risk actions without a fresh challenge, the attacker may immediately initiate transfers or alter recovery paths.

Even when a bank limits immediate movement, the stolen session still has value. It can be used for account reconnaissance, harvesting personal and financial data, changing profile fields to support later fraud, or reselling access to another criminal operator. In many incidents, the initial compromise is only the entry point, not the end objective.

For defenders, the key question is whether the banking application binds the session tightly enough to the original device, origin, and transaction context. If it does not, a valid MFA outcome can still become an unauthorised banking session in seconds.

Controls That Matter After MFA Is Bypassed

Phishing-resistant MFA helps, but it is not sufficient by itself when the session token can be captured and replayed. Banking teams need session binding, short-lived tokens, transaction confirmation for high-risk actions, and anomaly detection for impossible travel, new device use, and unusual payee behaviour. The more the bank can re-check risk at action time, the less a stolen session can accomplish.

Responding quickly also matters. If a user reports a suspicious login, the bank should be able to revoke active sessions, freeze risky transfers, and review recent account changes without waiting for a full password reset cycle. Session invalidation is often the decisive containment step because the attacker already passed the front-door MFA check.

One useful way to think about this attack is that MFA proved the user once, but the business still needs to decide whether the current session should be trusted for every subsequent action. That is where fraud controls, step-up policy, and session lifecycle management become part of the authentication story.

Risk and Threat Considerations

Real-time proxy phishing is dangerous because it converts a successful MFA event into an attacker-controlled session. The main exposure is not just initial account access, but the speed with which the attacker can abuse that access before the user or bank reacts.

Failure mechanism: The attacker relays the login to the genuine bank, captures the resulting session token or code, and reuses it from their own environment, often before the session expires or is challenged again.

Impact: That stolen session can enable unauthorised transfers, profile takeover, recovery-path changes, and resale of bank access, even though the victim completed MFA.

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 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63, 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 — Prompt Injection and Tool Misuse	Real-time proxy phishing abuses trusted interaction flow and stolen session authority.
Recommendation — Bind sensitive actions to fresh trust checks and reject replayable session handoff.
NIST SP 800-63	5.1.1 — Phishing Resistance	Phishing-resistant authenticators reduce credential capture but not session token theft.
Recommendation — Prefer phishing-resistant authenticators and pair them with session binding.
NIST CSF 2.0	PR.AA — Identity Management, Authentication and Access Control	The attack exploits authentication outcomes and weak post-login access assurance.
Recommendation — Reassess access after login and enforce step-up controls for risky banking actions.
CIS Controls v8	6.3 — Require MFA for Externally-Exposed Applications	MFA is central, but the scenario shows why MFA alone does not stop proxy-based session theft.
Recommendation — Combine MFA with session revocation and transaction-level verification.
OWASP Non-Human Identity Top 10	NHI-03 — Secrets and Token Protection	The attacker steals the resulting session token or code, which is identity-bearing material.
Recommendation — Protect session tokens with binding, expiry, and revocation controls.

Practitioner Guidance

What to verify: Check whether the bank re-authenticates or step-ups for payee creation, transfer approval, contact-detail changes, and device changes. If all high-risk actions ride on the same session created at login, the account is still highly exposed after MFA.

Decision rule: Treat any report of “I completed MFA but something still happened” as a possible session-compromise event, not just a password problem. The response should prioritise session revocation, transaction review, and recovery-path inspection before routine credential resets.

Practitioner takeaway: The real control objective is not merely proving the user once, it is ensuring the resulting session cannot be stolen, replayed, or reused for high-risk banking actions without fresh risk checks.