Fake Exchange Websites: How Cloned Logins Steal Credentials and 2FA in Real Time

Key Takeaways

Every fake exchange website exists to intercept one of three things: the credentials and 2FA code that unlock a real account, the deposit address a user thinks belongs to them, or the app-store trust a user places in a familiar exchange brand. The most dangerous of these by far is the first, because a well-built fake login page doesn't just steal a password for later use — it can relay a captured password and one-time 2FA code to the real exchange within seconds, completing a live login as the attacker while the victim is still looking at the fake page. That single mechanic is why this page exists as its own guide rather than folding into the general domain-spoofing material this site already covers elsewhere.

Direct answer: Fake exchange websites clone a real exchange's login and deposit pages to capture credentials, 2FA codes, and misdirect deposits. The most dangerous variant relays a stolen password and 2FA code to the real exchange in real time, completing a live account takeover before the code expires — which means 2FA alone, especially a TOTP app code, does not fully protect against this specific attack pattern.

• A cloned exchange login page can relay a captured password and 2FA code to the real exchange in real time, completing a live takeover in seconds.
• A fake deposit-address page needs no credentials at all — it only needs a user to copy an attacker-controlled address instead of their real one.
• Fake exchange-branded apps use the same app-store impersonation pattern covered for wallet apps, adapted to exchange login credentials instead of a seed phrase.
• Time-based 2FA codes (TOTP) are phishable through real-time relay; hardware security keys are structurally resistant to this specific technique.
• Withdrawal whitelisting is the practical backstop for the case where the login itself has already been compromised.
• Reaching a login page through a saved bookmark, never a search result or a shared link, removes the single most common way victims land on a cloned page in the first place.

Scope: This Page vs. the General Typosquatting Guide

Swoopr's Typosquatting and Fake Look-Alike Domains guide covers the general mechanics behind nearly every lookalike domain on the internet: swapped or transposed letters, added hyphens, wrong top-level domains, and Unicode homoglyph characters that render as visually identical to a legitimate letter. Those mechanics apply just as much to a fake exchange domain as they do to a fake wallet site, a fake DeFi protocol, or a fake NFT marketplace — the underlying domain-spoofing technique doesn't change based on what's being impersonated.

This page picks up specifically where that general mechanic leaves off: once a visitor has landed on a domain built to impersonate a real exchange, what does that fake site actually do with the visit? The answer is different from most other phishing targets, because a centralized exchange login flow has a structure — username, password, and a 2FA challenge — that a fake site can mimic step for step and relay live to the real thing, in a way a static wallet-connect prompt or a one-time seed-phrase entry cannot. The tactics on this page — real-time credential-and-2FA relay, fake deposit-address substitution, and fake exchange-branded apps — are specific to that structure and specific to exchanges as a target. Read the typosquatting guide for how the fake domain gets built and distributed in the first place; read this page for what happens once you're on it and it's impersonating your exchange specifically.

The Real-Time Credential-and-2FA Relay: Why 2FA Doesn't Fully Save You Here

The most dangerous tactic used against exchange users is not simple password theft — it's a live relay attack, sometimes called an adversary-in-the-middle or real-time phishing proxy, that turns a fake login page into a pass-through for a real login happening in the background. The mechanics are straightforward once laid out, which is exactly what makes the attack so effective: it doesn't require breaking any encryption or exploiting a software bug, only convincing a user to type their credentials into the wrong page at the right moment.

A victim lands on a fake login page built to be visually indistinguishable from the real exchange's login screen — same layout, same logo, same color scheme, often served over a valid HTTPS certificate for the lookalike domain, which shows the same padlock icon a browser would show on the genuine site. The victim enters a username and password exactly as they would on any ordinary login. The moment that submission happens, the attacker's backend server takes those exact credentials and submits them to the real exchange's real login page, essentially performing the login on the victim's behalf, in parallel, in the same few seconds.

If the real exchange's login flow requires a second factor — which nearly every major exchange does — the real login attempt triggers a genuine 2FA prompt. The fake page, watching for exactly this, immediately shows the victim its own matching 2FA prompt, asking for the same six-digit code a legitimate login would ask for. Because the victim believes they are still interacting with their real exchange account, entering that code feels completely routine — it's the same action performed at every previous login. The instant the code is typed into the fake page, the attacker's system relays it to the real exchange's pending login, completing the authentication before the code's typical thirty-to-sixty-second validity window expires.

At that point, the attacker is logged into the real account. Not a copy, not a simulation — the actual account, with whatever balances, saved payment methods, and account settings exist there, accessed through a completely legitimate login sequence from the exchange's own point of view, because every credential and code the exchange received was correct and current. This is the specific reason this page states plainly, and somewhat uncomfortably, that having 2FA enabled does not fully protect against a fake exchange login page. A time-based one-time password is a shared secret that works for anyone who has it and submits it in time — the fake page doesn't need to break TOTP's underlying math, it just needs to relay the victim's own valid code to the real site faster than the victim can notice something is wrong.

This doesn't mean TOTP-based 2FA is worthless — it still stops the overwhelming majority of account-takeover attempts that rely on a stolen password alone, without a live relay component, which remains by far the more common scenario. The point is narrower and specific to this attack pattern: against a real-time relay attack built specifically to phish both factors together, a standard authenticator app code offers materially less protection than most users assume, and the defenses that actually work against this variant — covered later on this page — look different from generic 2FA advice.

Fake Deposit-Address Pages

A second, structurally simpler tactic skips credential theft entirely and goes straight for a deposit in progress. A fake deposit-address page is built to look like the exact screen an exchange shows when a user wants to deposit crypto — the same layout, the same asset selector, the same warning text about network compatibility — except the wallet address displayed on it belongs to the attacker, not to the user's real exchange account.

This tactic shows up in a few common forms. A cloned page reachable through the same lookalike-domain techniques covered in the typosquatting guide can present a full fake deposit flow, complete with a QR code that encodes the attacker's address rather than the user's. A malicious browser extension or piece of clipboard-hijacking malware can intercept and silently swap a copied address on the real exchange's genuine deposit page, so the address that gets pasted into a sending wallet is different from the one that was copied, without any fake domain being involved at all. And a fake customer-support contact, reached through a scam link or an impersonated chat widget, can simply hand a user an attacker-controlled address directly, framed as help with a deposit that's "stuck" or "pending."

What unites all of these variants is that a deposit sent to the wrong address on a blockchain cannot be recalled, reversed, or clawed back through any customer-support process, regardless of how quickly the mistake is noticed. Unlike the credential-relay attack, this tactic requires no login at all and works even against a user who has never had their password or 2FA compromised — it only requires that the address shown or copied at the moment of sending funds is wrong, and that the sender doesn't independently verify it against a trusted source, such as the exchange's own account dashboard loaded through a saved bookmark, before confirming the transfer.

Fake Exchange-Branded App Downloads

The third exchange-specific tactic borrows a pattern already covered in depth on Swoopr's Fake Mobile Wallet Apps guide and applies it to exchange login credentials instead of a wallet's seed phrase. A fake exchange app is submitted to the Apple App Store or Google Play under a name and icon nearly identical to a real exchange's official app, sometimes boosted with a paid search ad for the exchange's own brand name and a burst of purchased five-star reviews to outrank the genuine listing in the days after it's published.

The mechanism differs from the fake-wallet-app case in one important way: a wallet app's worst-case outcome is typically a stolen seed phrase entered during setup, while a fake exchange app's login screen is functionally identical to a fake website's login screen — it can capture a username, password, and 2FA code and relay them in exactly the same real-time pattern described above, since a mobile app has no structural advantage over a browser when it comes to preventing this. Everything in the credential-relay section of this page applies to a fake exchange app exactly as it applies to a fake exchange website; the only thing that changes is the delivery mechanism, from a browser tab to an installed app icon on a home screen.

The same defense that works for fake wallet apps works here: go to the exchange's own official website first, typed directly or reached through a saved bookmark, and follow the download link posted there rather than searching an app store directly and trusting whatever ranks first. A developer name that doesn't exactly match the exchange's known corporate or publisher name, a review history dominated by generic five-star text posted in a tight cluster of dates, and a request to re-enter login credentials in an app that was just freshly installed rather than one already signed in are all signs worth treating as high-risk, in the same pattern already detailed on the fake wallet apps guide.

Worked Example: The Paid Search Ad and the Live Relay

Hypothetical example — for education only.

Assume a reader wants to log into their exchange account to check a pending order and, instead of using a saved bookmark, searches the exchange's name directly in a search engine. Above the genuine result sits a paid search ad using the exchange's exact name and logo, pointing to a domain that differs from the real one by a single added hyphen — a classic typosquatting technique, described in full on the dedicated domain-spoofing guide, but the entry point here doesn't matter as much as what happens next.

The reader clicks the ad and lands on a login page that is, pixel for pixel, identical to the real exchange's login screen. The URL bar shows a valid padlock, because the attacker has obtained a legitimate certificate for their own lookalike domain — a certificate only proves the connection is encrypted, not that the site is who it claims to be, a distinction the page's polish does nothing to surface. The reader enters their email and password exactly as they would on any other day.

Behind the scenes, the moment that submit button is pressed, the attacker's server takes those exact credentials and logs into the real exchange with them, in the background, within the same second. The real exchange, seeing a login attempt it doesn't recognize as suspicious — because the credentials are entirely correct — responds by requesting the account's configured 2FA code, exactly as it would for a login from the reader's own device. The fake page, watching for this, immediately displays its own "Enter your 2FA code" prompt to the reader, styled identically to what the reader has seen dozens of times before.

The reader opens their authenticator app, reads off the six-digit code, and types it into the fake page without hesitation — nothing about the flow so far has looked different from a normal login. The instant that code is submitted, the attacker's system relays it to the real exchange's pending 2FA challenge, completing the login within the code's short validity window. The fake page then shows the reader a generic "Verifying, please wait" message, sometimes followed by a fake error claiming the session timed out and asking them to try again later — buying the attacker time before the reader realizes anything happened.

Meanwhile, the attacker is now logged into the real account with a live, authenticated session. If the account has withdrawal whitelisting enabled, the attacker's ability to move funds out is limited to whatever addresses were pre-approved, which the attacker doesn't control — a meaningful, concrete backstop covered in the defenses below. If it doesn't, the attacker can attempt to add a new withdrawal address and move funds immediately, sometimes within minutes of the original phishing click, well before the reader has any reason to suspect the earlier login didn't go as it appeared to.

Practical Defenses Specific to This Pattern

Always reach your exchange through a saved bookmark

The single highest-leverage habit against every tactic on this page is never reaching a login page through a search result, a paid ad, an email link, a text message, or a shared social media post. Save the exchange's real URL as a bookmark once, verified carefully at the time it's saved, and use only that bookmark to log in from that point forward. This removes the paid-search-ad and phishing-link entry points entirely, regardless of how convincing a fake ad or lookalike domain becomes, because a bookmark that was correct once stays correct — it isn't re-evaluated, re-searched, or re-clicked each time. Swoopr's How to Verify a Legitimate Site checklist covers the broader verification habits worth applying the one time a new bookmark is created.

Use hardware-key-based 2FA where the exchange supports it

The credential-relay attack works against TOTP codes because a TOTP code is just a shared secret string that's valid anywhere it's submitted within its time window — it carries no information about which domain it's being used on. A hardware security key built on the FIDO2/WebAuthn standard works fundamentally differently: when a key authenticates a login, its cryptographic response is generated specifically for the exact domain that requested it, bound into the challenge-response exchange itself. A hardware key that successfully authenticates against the real exchange's genuine domain will not produce a valid response when a fake, lookalike domain relays the same challenge, even if that fake domain is visually and structurally identical to the real one. This domain-binding is the structural reason a hardware key resists real-time relay in a way a TOTP code fundamentally cannot, and it's the single most effective upgrade available for an account holding meaningful value. See Swoopr's dedicated guide on exchange two-factor authentication for how to compare 2FA methods and set up a hardware key on major exchanges.

Enable withdrawal whitelisting as a backstop

Because the relay attack results in a live, fully authenticated session on the real exchange, no login-level defense is airtight against every possible failure — which is exactly why a backstop that doesn't depend on the login working correctly matters. Withdrawal whitelisting restricts an account's outbound transfers to a short list of pre-approved addresses, typically enforcing a mandatory delay, often twenty-four to forty-eight hours, whenever a new address is added to that list. If an attacker gains live access to an account through a fake login page, whitelisting stops an immediate withdrawal to an address they control, because that address isn't approved and adding one triggers the delay — giving the account holder a realistic window to notice unusual activity and lock the account down before funds actually move. Swoopr's guide to withdrawal whitelist addresses covers setup and the specific tradeoffs involved.

Treat unexpected login or 2FA prompts as a signal, not routine

A 2FA prompt that appears without the account holder having just initiated a login themselves — for instance, a code arriving unprompted, or a login flow that feels slightly different from usual, such as an extra step or an unfamiliar delay — is worth treating as a signal to stop and independently verify, rather than completing on autopilot. This is a weaker defense than a hardware key or whitelisting, since a well-executed relay attack is specifically designed to feel identical to a normal login, but it costs nothing and occasionally catches an attack that a technical control alone would have let through.

Misconceptions Versus Reality

Common Mistakes

Two habits account for the majority of losses tied to fake exchange websites, and both are structural rather than momentary lapses in judgment — worth fixing as standing habits rather than relying on being careful in the moment.

The first is reaching an exchange's login page through a search engine result, a paid ad, or a link shared in an email, text message, or social media post, rather than through a bookmark saved once and reused every time. Paid search ads for an exchange's exact brand name are inexpensive for an attacker to buy and have repeatedly outranked the genuine result for stretches of time, meaning the habit of "just searching for it" carries real, recurring risk even for an experienced user who would never click an obviously suspicious link. A saved bookmark eliminates this entry point permanently, at essentially no cost.

The second is treating a TOTP authenticator app code as sufficient protection for a high-value account, without layering on a hardware key or a withdrawal whitelist. TOTP is a meaningful improvement over a password alone and stops the majority of ordinary account-takeover attempts, but it was never designed to resist a live relay attack built specifically to phish both factors in the same session — a distinction that gets lost when 2FA is discussed only in general terms rather than by mechanism. An account holding a small, disposable amount can reasonably accept this residual risk; an account holding significant value is worth the modest setup effort of a hardware key and a whitelist, precisely because those two controls are the ones actually built to withstand this specific pattern.

Risks, Limitations, and Exceptions

• Not every exchange supports hardware-key-based 2FA or withdrawal whitelisting; where a specific exchange offers only TOTP or SMS codes, a saved bookmark and heightened caution around unexpected prompts become proportionally more important.
• Withdrawal whitelisting's time delay is a deterrent, not a guarantee — an attacker with a long-lived compromised session could theoretically add an address and wait out the delay if the account holder never checks their account in that window.
• A hardware key defends the login itself but does not defend against a fake deposit-address page, since that tactic never touches authentication; the two defenses address different tactics on this page and are not substitutes for each other.
• SMS-based 2FA carries additional risk beyond what's described here, since it's also vulnerable to SIM-swap attacks independent of any fake website; treat SMS as the weakest 2FA option available on any exchange that offers alternatives.
• Even a saved bookmark can be undermined if the device itself is compromised by malware capable of rewriting bookmarks or intercepting traffic; bookmark discipline assumes a reasonably clean device as a starting point.

Practical Implementation Checklist

1. Verify your exchange's real domain carefully once, then save it as a browser bookmark and use only that bookmark to log in going forward.
2. Never click a search ad, email link, text message link, or social media link to reach a login page, regardless of how legitimate it appears.
3. Enable a FIDO2/WebAuthn hardware security key for 2FA if your exchange supports it, rather than relying on a TOTP app or SMS code alone.
4. Enable withdrawal whitelisting and set it to require a delay before any newly added address becomes active for withdrawals.
5. Download exchange mobile apps only through a link posted on the exchange's own official website, not by searching an app store directly.
6. Before sending a deposit, verify the destination address against your exchange account's dashboard loaded through your saved bookmark, not against an address shown by a support agent, QR code from an unverified source, or a page reached any other way.
7. Treat any unexpected 2FA prompt you didn't just trigger yourself as a reason to stop and independently check your account, rather than completing it out of habit.
8. If you ever suspect a login page wasn't genuine, immediately change your exchange password from the real site reached via your bookmark, review and revoke active sessions, and check withdrawal history and any newly added withdrawal addresses.

Sources

• CISA, "Implementing Phishing-Resistant MFA" — federal guidance explaining why hardware-key-based, domain-bound authentication resists real-time relay and adversary-in-the-middle phishing in a way one-time codes do not.
• FBI Internet Crime Complaint Center (IC3), Cryptocurrency Fraud Reports — annual federal data on cryptocurrency-related fraud losses, including account-compromise and impersonation scam categories.
• Federal Trade Commission, "What To Know About Cryptocurrency Scams" — consumer guidance on recognizing crypto-targeted fraud, including impersonation of legitimate platforms.

Conclusion

A fake exchange website is not just a stolen password waiting to be used later — the most dangerous version relays a captured password and 2FA code to the real exchange in real time, completing a live account takeover in seconds, which is the sobering reason 2FA alone does not fully close this gap. A fake deposit-address page and a fake exchange-branded app extend the same impersonation to a deposit flow and an app-store listing, using different mechanics but the same underlying trust in an exchange's familiar branding. The defenses that actually address this pattern are specific: a saved bookmark that removes the search-ad and phishing-link entry point entirely, a hardware security key whose domain-bound cryptography resists relay in a way a TOTP code cannot, and withdrawal whitelisting as a backstop for the case where a login has already been compromised. Read this page alongside the typosquatting and fake domains guide for how the underlying lookalike domain gets built in the first place, and the Exchange & Platform Security hub for the full picture of protecting an exchange account.

Related Reading

• Exchange & Platform Security — the parent hub covering the broader set of exchange and platform-level account protections.
• Typosquatting and Fake Look-Alike Domains — the general mechanics of how lookalike domains like the ones used in exchange impersonation are built and distributed.
• Exchange Two-Factor Authentication — comparing TOTP, SMS, and hardware-key 2FA methods and setting up the strongest option your exchange supports.
• Withdrawal Whitelist Addresses — how whitelisting works as a backstop against a compromised login.
• Fake Mobile Wallet Apps — the same app-store impersonation pattern covered here for exchange apps, applied to wallet apps and seed-phrase theft.
• How to Verify a Legitimate Site — the step-by-step checklist worth applying the one time you save a new exchange bookmark.

Frequently Asked Questions