Definition
A reverse-proxy phishing kit is a phishing infrastructure that does not host a cloned copy of the targeted platform's frontend. Instead, it transparently proxies the platform's real, live production application — forwarding legitimate static assets, API calls, telemetry, and fraud-detection signals back to the platform's actual backend — while intercepting only the one thing it needs: submitted credentials.
This page describes a real investigation into a major crypto exchange, referred to here only as "the Exchange." The exchange's identity and any infrastructure specifics that would identify it (domains, IP addresses, vendor integration names) are deliberately withheld: the exchange went dark after being told it owned the implicated infrastructure, so it's not confirmed whether the configuration has since been fixed. The technique itself — not the specific target — is the reusable, citable content here.
How It Compares
| Static clone phishing | Reverse-proxy phishing | |
|---|---|---|
| Frontend | A copied, often stale or slightly-off replica of the real site | The platform's actual, live production frontend, loaded directly from the platform's own infrastructure |
| Backend calls | Attacker-controlled endpoints for everything | Legitimate API calls pass through to the real backend; only credential submission is intercepted |
| Detectability by appearance | Often detectable — outdated assets, broken flows, mismatched branding | Effectively undetectable by appearance — the UI is pixel-perfect because it is the real UI |
| Root cause | N/A — clones can be built against any target | Only possible because the exchange's own servers accept API requests from any origin, with no restriction to domains the exchange actually owns |
The Evidence
Most web applications are built so that only the company's own domains can talk to its backend servers — meaning a normal phishing clone can only ever offer the functionality the attacker builds by hand, since it has no way to actually reach the real backend. In this investigation, the Exchange's servers were configured to accept requests from any origin, with no restriction to domains the company actually owns. That single gap changes the entire risk profile: an attacker doesn't need to fake anything. They can host the real frontend and let it talk to the real backend, live.
That's exactly what was observed: a site that routed login/credential traffic through a proxy the attacker controlled, while every other request — asset loads, analytics, fraud-detection calls, general API traffic — flowed straight through to the Exchange's real backend, unmodified. From the user's point of view, the page didn't just look like the Exchange, it behaved like the Exchange, because behind the scenes, for everything except the login step, it was talking to the Exchange. Tooling built for exactly this kind of interception (e.g. Evilginx-class man-in-the-middle proxies) is a logical fit for this setup, though account takeovers weren't directly observed as a result in this investigation.
The exchange's own anti-fraud and monitoring systems ran inside the phishing session as a direct consequence: device-fingerprinting, behavioral-biometric, and network-fingerprinting integrations embedded in the Exchange's frontend executed against phishing victims with no check on which domain was invoking them, meaning the Exchange's own fraud tooling was unintentionally profiling its own phishing victims. Error-monitoring/telemetry keys embedded in the frontend accepted and forwarded data from the phishing domain the same way, capable of polluting genuine incident monitoring with attacker-session noise. A CAPTCHA key embedded in the frontend was similarly usable from the phishing domain without restriction, consuming the Exchange's own quota while making the fake page feel more legitimate to visitors. And because the phishing kit ran the real frontend unmodified, an internal domain-validation call the frontend makes as part of normal operation fired from the phishing domain too — giving the Exchange, in principle, a built-in and reliable way to spot non-Exchange domains running its application in real time, if it chose to monitor for it.
What To Do About It
For platform security teams:
- Restrict backend API access to your own domains — this single control is what prevents the entire reverse-proxy pattern described here from being possible in the first place.
- Enforce origin validation on any endpoint that accepts fingerprinting, telemetry, or fraud-detection data — restrict execution to approved domains rather than trusting the frontend's own origin claims.
- Monitor any internal domain-validation or allowlist-check calls your frontend makes for unexpected domains — this is often the most reliable, lowest-effort detection signal available, since a reverse-proxy kit's own unmodified code produces it.
- Rotate exposed telemetry/monitoring keys and add origin filtering to ingestion endpoints.
For individual users:
- Confirm the domain in your address bar independently before entering credentials — a pixel-perfect, fully-functional interface is not evidence of a legitimate domain in this attack class.
- Use a password manager that autofills only on the exact registered domain; reverse-proxy kits defeat visual inspection but not domain-bound autofill.
- Report suspected reverse-proxy phishing to the platform's security or bug bounty program with the domain and any observed behavior.
Caveats & Edge Cases
This technique defeats most user-facing legitimacy checks, since the rendered page is not a forgery — visual inspection, functional testing, and even some automated content-similarity scanners will find nothing wrong with the page itself. Detection has to happen at the infrastructure and telemetry layer (origin validation, domain-allowlist signals), not by asking whether the site "looks right." This is a technical, researcher-oriented investigation, and — per the note in the Definition above — deliberately withholds the specific exchange's identity since it's unconfirmed whether the underlying configuration has been fixed.