Notifications
Clear all
Topic starter
06/07/2026 9:44 am
TL;DR: Reverse-proxy phishing still defeats MFA by capturing credentials and one-time passcodes in real time, according to Arkose Labs, while attackers continue to industrialise phishing with high-volume infrastructure and cybercrime-as-a-service tooling. Session-bound verification and adaptive mitigation now matter as much as login factors.
NHIMG editorial — what this means for IAM teams
By the numbers:
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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.
👉 Read Arkose Labs' analysis of reverse-proxy phishing and MFA compromise →
Reverse-proxy phishing and MFA compromise: what teams need to know?
Explore further
06/07/2026 10:01 am
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.
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.
A question worth separating out:
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.
👉 Read our full editorial: MFA compromise through reverse-proxy phishing is still a live risk
