Tornado Cash Website Clones and How Key Theft Works

Prepared by the editorial team. Updated August 31, 2026.

Tornado Cash website searches reliably surface pages whose purpose is to take assets rather than to provide software, and they succeed because most people evaluate a page by how it looks. This article describes the general mechanics of credential and seed-phrase theft through look-alike interfaces so that the pattern becomes recognizable. It is written for defense, and deliberately contains nothing that would help anyone build such a page.

What does a look-alike page actually try to obtain?

Three things, in descending order of value to whoever built it: a seed phrase or private key, which hands over permanent control of a wallet; a signed permission, which allows specific assets to be moved later; and a direct payment made under a pretext such as an unlock fee, a compliance charge or a recovery service.

The first is the most damaging because it is total and permanent. A seed phrase regenerates every key in a wallet, so surrendering one is not like losing a password that can be changed. There is nothing to revoke and nobody to appeal to, and the loss covers every account derived from that seed rather than the one balance the visitor had in mind.

The second is quieter and, for that reason, often more effective. A permission signature leaves assets in place while granting another party the standing right to move them, so nothing appears to happen at the moment of the mistake. The assets can be taken weeks later, long after the page has been closed and forgotten.

The third does not involve keys at all. It relies on a plausible reason to send funds directly, and the pretexts cluster around anxiety: an account said to be flagged, a withdrawal said to need a release fee, a specialist offering to retrieve an earlier loss. This name draws people already worried about compliance consequences, which is the emotional state those pretexts are written for.

Why does no legitimate interface ever ask for a seed phrase?

Because it has no use for one. A seed phrase reconstructs the private keys of an entire wallet, and an interface does not need keys to work: it assembles an unsigned transaction and hands it to wallet software, which signs locally and returns the result. Any page with a field for a seed phrase is attempting theft.

This is architecture rather than etiquette. In the ordinary flow, the secret never leaves the wallet, whether that wallet is a browser extension, a mobile application or a hardware device with its own screen. The page receives a signature and a public address, which is all it needs. A page that asks for the phrase itself is asking for something no honest design has any way to use.

The request is rarely phrased as a demand. It appears as importing a wallet, syncing an account, validating a balance, restoring access, or completing a verification step before a withdrawal can proceed. People posing as support staff ask for it as troubleshooting, and fake device prompts ask for a recovery phrase to be typed into a computer, which no genuine hardware wallet requires once it is initialised.

The rule that follows is unusually clean, and worth holding without exceptions. No legitimate circumstance requires typing a recovery phrase into a web page, a chat window, a form or a support ticket. Migration, airdrops, compliance checks and technical support are all contexts in which the request has been made, and in every one of them the request is the attack.

How do fake connect prompts and approval requests work?

A cloned interface reproduces a familiar connection flow, then presents a signature request whose real effect differs from what the surrounding text implies. The request may seek broad spending permission over a token, an off-chain message that authorizes a transfer, or an interaction with a contract that the page gives the visitor no way to identify.

Everything visible except the wallet prompt is under the page’s control. Logos, layout, wording and reassurances are files the page serves, and copying them takes no skill. The wallet confirmation screen is generated by software the page cannot edit, which makes it the only description of the action worth reading, and explains why attackers work to keep attention away from it.

Permission requests are the workhorse of this pattern. A token allowance lets a named party spend an amount on your behalf, and when that amount is effectively unlimited the permission has no natural expiry. Similar mechanisms exist for collectibles, where one approval can cover a whole collection, and for off-chain signatures that carry the weight of a transaction while presenting as a harmless message.

Two wrinkles explain why victims often misremember the sequence. Some pages draw an imitation wallet window inside the page itself, so the visitor thinks they are reading a wallet prompt when they are reading the page. Others behave normally at first and escalate once clicking through prompts has become a habit.

How can you check what permissions a page is requesting?

You read the wallet’s own confirmation screen rather than the page, identify which of the three request types it is, check the amount and the counterparty, compare all of that against what you intended, and reject anything you cannot explain. This is a verification routine for a prompt already on screen, not a guide to any protocol.

Step 1: Stop at the wallet prompt and read it

Treat the wallet confirmation screen as the only trustworthy description of what is about to happen, because the page around it controls every other word you can see. The pause matters, since these interfaces are built to make confirmation feel like a formality.

Step 2: Identify what kind of request it is

Work out whether you are being asked to transfer assets, to grant a spending permission or to sign an off-chain message, because those three request types have very different consequences. The third is the one people underestimate, since a message signature looks harmless and can carry real authority.

Step 3: Read the amount and the counterparty

Look for the amount the request covers and the address or contract that would gain the permission, because an unlimited allowance to an unknown party is the most common form this attack takes. An unfamiliar counterparty is a reason to stop rather than a detail to check afterwards.

Step 4: Compare the request with your intention

Ask whether the request matches the action you thought you were taking, since a mismatch between a button labelled connect and a prompt seeking transfer rights is the signal that matters most. Attackers rely on visitors reading the button rather than the prompt.

Step 5: Reject anything unclear and review old permissions

Reject any request you cannot fully explain to yourself, then separately review the permissions your wallet has already granted in the past, because old approvals stay active until they are revoked. A periodic review turns a permanent exposure into a temporary one.

Why does this particular name attract such pages?

Because it combines strong intent with an absent owner. People searching it often want an interface rather than an explanation, the name retains enough recognition to sustain steady traffic, and no maintained project exists to object to impersonation or to publish a reference that would settle which page is which.

Legal history thins the field further. Following the August 2022 Treasury designation and the prosecutions that followed, cautious publishers stepped back from anything resembling an interface for this protocol. Withdrawal by careful parties leaves the space to parties who are not careful, which is a general dynamic in reputationally risky corners of the web.

The audience is also unusually attractive to attackers. Someone seeking financial privacy may hold meaningful balances, may be reluctant to report a loss to authorities, and may be primed to read access problems as the normal consequence of a contested tool. Each trait raises the expected return on a convincing imitation.

What each visible signal actually proves

Almost all of the reassurance a page offers is generated by the page itself, which makes the ordinary checklist of trust signals close to useless in this setting. The table below separates what each familiar element genuinely demonstrates from what visitors routinely assume it demonstrates, as a general orientation rather than a verdict.

What you see on the page	What it actually proves
Familiar logo, colors and layout	Nothing, since these are files copied in seconds
A padlock and a valid certificate	Traffic to that server is encrypted, not that the server is honest
A field requesting a recovery phrase	Positive evidence of theft, since no honest design has a use for one
Testimonials, audit badges, partner logos	Nothing, unless each one is confirmed at its supposed source
A countdown, a warning or an urgent tone	A pressure technique, and a reason for more caution rather than less

The pattern across the rows is that appearance is free and authority is not. Only the wallet prompt and independently held records tell you anything the page did not choose to tell you.

Frequently asked questions

If I connected a wallet but signed nothing, am I exposed?

Connecting shares your public address and lets the page read your balances, which is unpleasant but not a transfer of control. Real exposure begins at a signature, so a session where nothing was signed is far less serious, though reviewing existing approvals afterwards is still sensible.

Does a hardware wallet prevent this kind of loss?

A hardware wallet protects the key from being copied, which defeats seed harvesting, but it cannot stop you approving a harmful transaction yourself. Its real benefit is the device screen, which shows what is being signed independently of the computer, and only if the screen is read.

Are transfers made through a malicious approval reversible?

Settled transactions on a public blockchain cannot be reversed by any party, including the network itself. Reporting to the relevant platforms and to law enforcement is still worthwhile, and a service promising recovery for an upfront fee is usually a second attempt on the same victim.

Why do these pages sometimes work perfectly at first?

Some are built to behave normally for small interactions so the visitor’s confidence grows before a larger request appears. Others harvest a permission quietly and use it days later, which breaks the mental link between the page that was visited and the loss that eventually shows up.