MFA compromise through reverse-proxy phishing is still a live risk

At a glance

What this is: This is an Arkose Labs briefing on reverse-proxy phishing and MFA compromise, showing how attackers intercept credentials and one-time codes in real time.

Why it matters: It matters because identity teams still have to defend consumer, workforce, and machine-adjacent login flows against session theft, fraud, and account takeover even when MFA is deployed.

By the numbers:

• 58% increase in phishing attacks in 2023
• a new phishing site is created every 11 seconds

👉 Read Arkose Labs' analysis of reverse-proxy phishing and MFA compromise

Context

Reverse-proxy phishing is a credential interception pattern where an attacker relays a victim through a fake login site to the real one, then captures credentials and MFA codes in the same session. For identity programmes, the problem is not whether MFA exists, but whether the login flow can distinguish a legitimate user from a live interception layer.

This is a consumer identity and authentication resilience issue, but it also affects broader IAM assumptions. When access is proven only once at sign-in, downstream trust can be inherited from a compromised session, which makes phishing resistance, session risk checks, and adaptive challenge design central to the control model.

Arkose Labs frames the issue as a real-time fraud and account takeover problem rather than a purely email-security problem. That is the right lens, because the compromise happens at the identity boundary, not in the inbox.

Key questions

Q: How should security teams reduce the risk of reverse-proxy phishing against MFA?

A: Security teams should reduce relay risk by binding authentication to session context, device signals, and origin checks rather than treating a valid OTP as sufficient proof. Phishing-resistant methods, adaptive challenges, and step-up controls at high-risk sign-ins make live interception harder to reuse.

Q: Why do one-time passcodes still fail against modern phishing campaigns?

A: One-time passcodes fail when the attacker captures them in the same live session and immediately relays them to the real service. The weakness is not the code itself, but the lack of binding between the code, the user, and the authentic session context.

Q: What signs indicate a session may have been hijacked after login?

A: Watch for unusual token reuse, sudden geolocation shifts, mismatched device signals, and access that continues after the original authentication context should have changed. Those patterns suggest the attacker did not just steal credentials, but retained authenticated state.

Q: Who should own response when reverse-proxy phishing leads to account takeover?

A: Account takeover response should be shared across IAM, fraud operations, and security monitoring because the attack crosses authentication, session integrity, and abuse detection boundaries. If those functions are separate, the attacker can move from login compromise to misuse before containment closes the loop.

How it works in practice

How reverse-proxy phishing defeats MFA

A reverse-proxy phishing site sits between the user and the genuine service, forwarding traffic in both directions so the victim sees a believable login flow while the attacker captures credentials, cookies, and one-time passcodes. MFA stops reused passwords, but it does not automatically stop a live relay unless the authentication process is bound to device, origin, or session context. That is why code interception remains effective in otherwise mature environments.

Practical implication: treat MFA as one layer in a phishing-resistance design, not as proof that the login channel itself is trustworthy.

Why session hijacking matters more than password theft

Once an attacker has intercepted a valid session, they may not need the password again. Session cookies can carry the authenticated state forward, allowing access to continue even after the initial login event is over. In practice, this shifts the control problem from credential strength to session integrity, token binding, and step-up checks when the session context changes.

Practical implication: increase scrutiny on active sessions and reauthentication triggers, not just on password and OTP issuance.

Why adaptive challenges disrupt cybercrime-as-a-service

Arkose Labs describes adaptive challenges and signal-based detection as a way to slow automated abuse at the point of interaction. The key technical idea is not blocking all bots, but forcing a live attacker or proxy framework to solve a challenge that cannot be reliably replayed at scale. That changes phishing from a cheap, repeatable pipeline into a costlier and noisier operation.

Practical implication: place adaptive friction where credential replay and proxy automation are most likely to surface, especially at sign-in and recovery flows.

NHI Mgmt Group analysis

Phishing resistance is now a session integrity problem, not just an authentication problem. Reverse-proxy attacks succeed because the identity boundary is still too often defined at the login prompt. Once an attacker can relay the user through a believable site, MFA becomes a captured artefact rather than a control. Practitioners need to treat the authenticated session as the primary security object.

Consumer identity programmes cannot rely on factor count as a proxy for trust. The article shows why stronger-looking authentication does not automatically mean stronger protection if the channel itself is compromised. This is where adaptive challenges, risk signals, and origin awareness matter more than simply adding another factor. For IAM teams, assurance must extend beyond successful sign-in.

Reverse-proxy trust gap: a login flow that trusts any valid OTP is still vulnerable when the attacker can relay the entire session in real time. That assumption was designed for a world where authentication events were local and discrete. It fails when the adversary can stand in the middle of the interaction and preserve the illusion of legitimacy. The implication is that practitioners must rethink where trust is established and how it is continuously validated.

Cybercrime-as-a-service changes the economics of phishing defence. The article points to commercialised tooling such as EvilProxy and Caffeine Proxy, which lowers the skill barrier for high-quality phishing operations. That means detection has to absorb more variation in attack infrastructure, not just more volume. Security teams should expect commodity access to become more persistent, more adaptive, and more difficult to fingerprint.

Identity teams should align anti-phishing controls with fraud operations, not leave them in separate silos. Reverse-proxy compromise affects authentication, account recovery, and downstream abuse in one chain. When those controls are owned by different teams, the attacker exploits the seams. The practical conclusion is that phishing defence has to be measured as an identity control outcome, not only a security awareness metric.

From our research:

• 3B spam emails sent each day, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Attackers attempt access within 17 minutes of public AWS credential exposure in the same research, showing how quickly intercepted identity artefacts are exploited.
• For a broader identity view, see 52 NHI Breaches Analysis, which helps teams connect credential exposure patterns to repeatable control failures.

What this signals

Reverse-proxy phishing is becoming a control design issue, not just a user behaviour issue. The more authentication depends on reusable sessions and passcodes, the more attractive live interception becomes. IAM teams should expect phishing resistance to migrate from awareness and factor choice toward session binding, adaptive policy, and recovery hardening. The governance question is whether the programme can still tell the difference between a legitimate login and a relayed one.

With 92% of organisations agreeing that governing AI agents is critical but only 44% having policies in place, according to AI Agents: The New Attack Surface report, the broader lesson is that identity governance now has to anticipate machine-driven abuse patterns as well as human ones. The same control seams that let phishing succeed for people will also matter when automated actors start chaining identity actions.

Phishing resistance needs a measured operating model. Teams should track whether high-risk sign-ins are being challenged, whether session tokens are being reassessed after context changes, and whether recovery flows are more exposed than primary login. That is where the next wave of compromise will surface first.

For practitioners

• Harden authentication flows against relay attacks Bind login assurance to origin, device, or session context so a captured OTP is not enough to complete access. Use phishing-resistant methods where possible and reserve one-time codes for lower-risk paths.
• Add adaptive friction to high-risk sign-ins Trigger challenges, step-up checks, or throttling when login patterns match proxy abuse, credential replay, or abnormal geolocation and device combinations. The goal is to interrupt live relay attempts before session completion.
• Inspect active sessions for hijack indicators Review token age, reuse patterns, impossible travel, and session changes that indicate a valid login has been relayed or stolen. Reauthentication should be triggered when the session context shifts materially.
• Unify fraud and IAM response paths Route reverse-proxy phishing signals to the teams that own authentication policy, account recovery, and account takeover response so containment does not stop at the mailbox or awareness layer.

Key takeaways

• Reverse-proxy phishing succeeds because it targets the live authentication path, not just the credential store.
• The scale of phishing infrastructure and spam volume shows why MFA alone is no longer a sufficient control boundary.
• Identity teams need session-aware, adaptive defence and coordinated fraud response to reduce account takeover risk.

Key terms

• Reverse-proxy phishing: A phishing technique where an attacker places a proxy between the victim and the real service so the victim interacts with a convincing fake while the attacker captures credentials and session artefacts. The method is effective because it preserves the look and feel of a legitimate login flow.
• Session hijacking: The takeover of an authenticated session after login, often by reusing a stolen cookie or token. In identity programmes, the risk is that the attacker no longer needs to reauthenticate, so the compromise can continue even if the original password or MFA code is no longer available.
• Phishing-resistant authentication: An authentication method designed to make credential relay and impersonation materially harder, typically by binding the authenticator to the real origin or device. For practitioners, the key distinction is not simply stronger MFA, but authentication that resists real-time interception.

What's in the full announcement

Arkose Labs' full article covers the operational detail this post intentionally leaves for the source:

• Specific reverse-proxy phishing examples and how the attacker relays MFA prompts in real time.
• Detection and mitigation flow details for the platform's immediate risk assessment and true/false API responses.
• Examples of adaptive challenge behaviour and how it blocks automated replay attempts.
• References to bot and fraud tooling used in cybercrime-as-a-service campaigns.

👉 The full Arkose Labs post covers the detection flow, adaptive challenge model, and fraud mitigation detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.