Reverse Proxy Phishing

Blackhatpakistan · 2026-10-03T01:03:26+0100

Reverse proxy phishing explained: how Evilginx-class kits relay credentials and session tokens in real time, why second factors never stop a man-in-the-middle, and what the victim, the defender and the token each see. The clearest phishing evolution since the browser invented the session cookie.

TL;DR - The page is real, only the relay is not - MFA authenticates victim to origin.

THE ARCHITECTURE

Classic phishing proxies a form; reverse proxy phishing proxies a relationship:

Victim reaches a lookalike domain fronting a reverse proxy
Proxy forwards every request live to the real login origin - content is always authentic, rendered by the actual provider
Victim enters password - forwarded to real provider, real second factor challenge returns through the proxy
Victim completes MFA on the genuine page; the resulting session token passes through the proxy, which records it
Attacker replays the captured session cookie from their own browser - authenticated, MFA satisfied, IP change just another new device

No fake forms exist at any point - the page is real, the origin is real, only the relay is not.

WHY MFA DOES NOT HELP

MFA class	Relay result
SMS / email OTP	Captured in-band - victim types it into the genuine challenge through the proxy
TOTP codes	Same - the challenge comes from the real provider
Push approval	Victim taps approve on the genuine push - attacker never sees the code, only the resulting session
Hardware key	Depends on token binding - unbound sessions still replay; bound tokens raise the bar significantly

The second factor authenticates the victim to the origin; the relay only harvests what that authentication produces.

KIT COMPONENTS

Phishlet - the per-service configuration: lure paths, redirect handling, token extraction rules per provider
Landing infrastructure - lookalike domains, TLS certificates (automated issuance), geo or referrer filters so scanners see nothing
Redirection layer - post-capture bounce to the real login page so the victim never suspects
Session store - captured cookies tagged by target, export for replay

THE CAPTURE WINDOW

Tokens die on triggers: password change, admin revocation, risk-based re-auth, and cookie TTL. Operators replay within hours, not days, and victim activity on the account concurrently can invalidate the session they hold - concurrency discipline applies the same as log replay (session workflow).

DEFENSIVE VISIBILITY

Infra signals: fresh registrable domains, certificate velocity, reverse-proxy fingerprints in headers
User signals: impossible-travel after login, new device tokens stacked in minutes, session cookie replay from different ASN
Post-auth: OAuth consent abuse and mail rules planted immediately after capture - the standard persistence layer

Which is why harvest-to-action time matters: the same device and velocity signals that catch stuffing catch relayed sessions minutes after replay.

Operational rule of the format: the session is the objective, every action after capture is a race against revocation.

★ MEMBER BONUS — FIELD CHEAT SHEET

To view the content, you need to Sign In or Register.

Hit reply to unlock the sheet - takes five seconds.

Post relay observations below - provider class, token lifetime observed, and which revocation path killed the session if it died.

— RELATED GUIDES —

Search

Blackhat Pakistan — Ethical Hacking, Hacking Tools & Cybersecurity Tutorials

Reverse Proxy Phishing

Blackhatpakistan

Administrator

Legal warning