1,010 ETH Lost in Tornado Cash Phishing Attack: How an Old Official Domain Became the Trap

A cryptocurrency user reportedly lost 1,010 ETH after returning to Tornado Cash through an old browser bookmark. At first glance, that sounds like another expensive phishing incident in which someone failed to verify a website before moving a large amount of crypto. The available evidence suggests something more unusual. The bookmark reportedly pointed to tornado.cash, the domain that genuinely served as Tornado Cash's official website years earlier, but historical and current registration records indicate that the domain's ownership lifecycle changed after the original registration expired.
‍

According to community reporting amplified by Wu Blockchain on August 20, 2026, the user returned to the old domain, interacted with what appeared to be a Tornado Cash frontend, and subsequently lost approximately 1,010 ETH. The same reporting says the funds were withdrawn within roughly 12 hours and alleges that wallets associated by the victim with the operation may be connected to nearly 4,000 ETH in similar losses over the preceding year. Those broader claims have not yet been independently confirmed by a major blockchain analytics firm, and Efani has not found a public forensic report that conclusively links the domain controller, the receiving wallets, and the alleged 4,000 ETH cluster to one operator.
‍

What can already be verified is significant. Historical WHOIS records show that tornado.cash was created in July 2019 and had a registry expiration date in July 2024. Current WHOIS records instead show a new creation date of March 25, 2025, which strongly indicates that the original registration did not continue uninterrupted and that the domain was later registered afresh. For high value crypto users, the security lesson is not simply that phishing remains dangerous. It is that a domain can retain years of accumulated trust even after control of that domain has changed.

The initial account describes a user who accessed Tornado Cash through a previously saved bookmark rather than through a search result, social media post, direct message, or newly received link. The site allegedly presented a convincing Tornado Cash interface, and the user reportedly deposited approximately 1,010 ETH through it. Community reporting says the ETH entered legitimate Tornado Cash pools, while the malicious interface captured the secret information required to withdraw those deposits later.
‍

An Ethereum address supplied alongside the incident reporting, 0xd8B356356d7B143D7ece9F5876FE4b954E93b745, reportedly received multiple withdrawals from Tornado Cash pools and held roughly 810 ETH when examined shortly after the incident. The observed transaction pattern reportedly included repeated 100 ETH withdrawals and at least one 10 ETH withdrawal. That is relevant because Tornado Cash Classic historically uses fixed denomination pools, including 100 ETH and 10 ETH pools, so the activity is consistent with the reported note theft theory.
‍

There are still important gaps. Efani has not independently reconstructed every transaction from the victim's original wallet through the Tornado Cash deposits and subsequent withdrawals, partly because Etherscan restricted automated access during our research. We therefore consider the supplied address activity consistent with the reported attack sequence rather than conclusive proof of every detail. The claim that the same group has stolen nearly 4,000 ETH over the previous 12 months deserves even more caution because we have not found a public wallet clustering analysis from Chainalysis, TRM Labs, Elliptic, SlowMist, Scam Sniffer, PeckShield, Arkham, or another major investigator confirming that total.
‍

tornado.cash Really Was the Official Domain
‍

The historical legitimacy of the domain is not in doubt. When the U.S. Treasury's Office of Foreign Assets Control sanctioned Tornado Cash on August 8, 2022, its official designation explicitly identified “Website tornado.cash.” (ofac.treasury.gov)
‍

Historical WHOIS data records the domain as having been created on July 17, 2019, with a registry expiration date of July 17, 2024. Current WHOIS data no longer shows that 2019 creation date. Instead, the present registration begins on March 25, 2025, uses TLD Registrar Solutions Ltd., and is protected by a privacy service. (whois.com)
‍

That change in creation date is one of the strongest independently verifiable facts in the story. A normal domain renewal generally preserves the original creation date, so a new creation date strongly supports the conclusion that the earlier registration ended and the domain was later registered again. We have not found public evidence identifying the current registrant as a particular phishing operator, which means the article should distinguish between what the domain records establish and what community investigators currently allege about the malicious frontend.
‍

The same caution applies to claims that U.S. sanctions directly caused the domain to lapse. The timing makes that possibility worth examining, but we have not found a primary statement from Tornado Cash developers saying that the domain was lost because sanctions prevented renewal. The strongest defensible wording is narrower: the original domain registration lapsed during a period when Tornado Cash was under U.S. sanctions and much of its conventional infrastructure had been disrupted.

OFAC sanctioned Tornado Cash in August 2022, citing its use in laundering cryptocurrency associated with criminal activity, including funds linked to North Korean cyber operations. The designation included the project's website and numerous Ethereum addresses. (ofac.treasury.gov)
‍

The legal dispute that followed eventually focused on whether immutable software could be treated as property under the authority OFAC had used. On November 26, 2024, the U.S. Court of Appeals for the Fifth Circuit ruled that Tornado Cash's immutable smart contracts did not constitute property that could be blocked under the relevant statutory framework. The court emphasized that these contracts could no longer be owned, controlled, altered, or removed, including by their original developers. (law.justia.com)
‍

Treasury formally removed Tornado Cash from the sanctions list on March 21, 2025. Current WHOIS records show the new tornado.cash registration beginning just four days later, on March 25. (ofac.treasury.gov) The proximity is notable, but it should not be treated as proof of intent or coordination because the available evidence does not establish who registered the domain or why.
‍

The more important lesson is architectural. Tornado Cash's immutable contracts could continue to exist on Ethereum despite sanctions, litigation, developer disruption, and changes in conventional infrastructure. A web domain does not have the same permanence because it depends on registrars, DNS, renewal, hosting, certificates, and continuing operational control. The protocol could therefore survive while the web identity users remembered from earlier years ceased to represent the same infrastructure.
‍

How a Malicious Tornado Cash Frontend Can Steal Funds Without Hacking the Smart Contracts
‍

There is currently no evidence that Tornado Cash Classic's immutable pool contracts were compromised in this incident. The reported attack instead appears consistent with a frontend credential theft model, which is particularly dangerous because the on chain transaction itself can remain legitimate.
‍

Tornado Cash Classic works by allowing users to deposit assets into fixed denomination pools and later withdraw them to another address without publicly linking the withdrawal to a specific deposit. During the deposit process, the application generates a private note that contains the information needed to later prove withdrawal rights. Tornado Cash's own documentation warns users that anyone who obtains this note can withdraw the associated funds. (docs.tornado.cash)
‍

At a lower level, the system uses secret values, a nullifier, commitments, a Merkle tree, and a zero knowledge proof. The nullifier ensures that the same deposit cannot be withdrawn twice, while the proof allows someone to demonstrate knowledge of the required secret without revealing which specific deposit belongs to them. (docs.tornado.cash)
‍

The important security consequence is that possession of the note is economically similar to possession of a bearer credential. The smart contract does not know which human is supposed to hold it. It verifies that someone presents the correct cryptographic proof. If a malicious frontend captures the note before the legitimate user withdraws, the attacker may be able to claim the deposit first even though the smart contract itself is functioning exactly as designed.

No verified copy of the malicious frontend code has been publicly analyzed yet, so the precise mechanics should remain qualified. The reported sequence is technically credible, however, because a counterfeit Tornado Cash interface would not necessarily need to redirect the victim's ETH into a fake contract.
‍

The victim reportedly opened an old bookmark and reached tornado.cash. If the domain was under different control at that point, the browser would simply resolve the hostname according to its current DNS configuration. A valid HTTPS certificate would not have solved the problem because HTTPS proves that the browser is communicating securely with whoever currently controls the domain. It does not prove that the current controller is the same organization the user trusted several years earlier.
‍

A sophisticated malicious frontend could reproduce the legitimate Tornado Cash interface, allow the wallet to send ETH to the authentic Tornado Cash pools, and capture the deposit notes generated during the process. This approach would be more convincing than a simple wallet drainer because several things could appear normal to the victim. The hardware wallet might display the correct contract, the blockchain could show the deposit entering a genuine Tornado pool, and the user's seed phrase could remain completely secure.
‍

If the attacker obtained the withdrawal credential, the victim and attacker would effectively possess competing authority over the same deposit. Once the attacker withdrew the funds first, the nullifier would prevent the legitimate owner from withdrawing the same deposit again. From the contract's perspective, a valid proof had been presented, so no smart contract exploit would be required.
‍

The zkLend Case Shows This Attack Class Is Not New
‍

There is an important historical precedent that makes the current report more credible.
‍

In early 2025, the decentralized lending protocol zkLend suffered a major exploit. The exploiter later attempted to move approximately 2,930 ETH through Tornado Cash but reportedly interacted with tornadoeth.cash, a phishing domain impersonating the real service. According to zkLend's public account, the exploiter subsequently lost those funds to another party.
‍

That case is useful because it demonstrates that Tornado Cash phishing frontends capable of affecting thousands of ETH already existed before the August 2026 incident. It also shows why attribution needs to be handled carefully. zkLend itself noted that investigators did not have conclusive evidence proving that the operator of the phishing site was connected to the original zkLend exploiter.
‍

The difference between that case and the new one is particularly important. The zkLend exploiter reportedly visited a lookalike domain, while the August 2026 victim reportedly visited the historically genuine tornado.cash domain. That changes the security lesson from simple URL verification to something more difficult: the possibility that a previously legitimate trust anchor can become hostile after control changes.

For years, cryptocurrency users have been advised to bookmark sensitive websites rather than rely on search engines, advertisements, Telegram messages, Discord links, or direct messages. That remains useful advice because it reduces the risk of being redirected to a typo domain or malicious advertisement. The reported Tornado Cash incident exposes a limitation that is rarely discussed.
‍

A bookmark preserves a hostname, but it does not preserve ownership. It does not tell the user that the domain registration expired, that DNS changed, that the organization abandoned the address, that a new operator registered it, or that the JavaScript served from the site is no longer the same code that was reviewed years earlier. The bookmark therefore preserves a security decision made at one point in time without preserving the conditions that made that decision valid.
‍

What stood out to me in reviewing this case is that the victim's alleged mistake may have begun with a perfectly reasonable security habit. They appear to have verified the website in the past and saved it specifically so they would not need to trust future search results or links. The failure occurred because the trust decision remained static while the infrastructure changed.
‍

That is a useful concept far beyond Tornado Cash. Old security assumptions can become attack surfaces when users continue to rely on them long after the underlying system has changed.
‍

Expired Domains Can Inherit Years of Legitimate Trust
‍

A domain that changes hands can carry far more value than its name alone. Years of legitimate use can leave behind backlinks, bookmarks, social posts, documentation, tutorials, browser histories, password manager entries, forum discussions, YouTube descriptions, and private notes that continue sending users to the same address.
‍

An attacker who acquires such a domain may therefore inherit traffic that was originally earned by the legitimate organization. They do not necessarily need to convince every victim to click a newly created phishing link. Old legitimate material can continue delivering visitors automatically.
‍

This makes abandoned domains particularly dangerous in financial and security sensitive environments. The attacker may acquire not only an address but also the reputation associated with that address. Historical trust becomes reusable infrastructure.
‍

The Tornado Cash case is especially striking because the underlying protocol remained available after the original conventional web infrastructure was disrupted. Users could therefore retain a genuine reason to interact with the protocol while still carrying outdated assumptions about the safest way to reach it.

Many experienced crypto users rely on two checks before making a transaction: confirm the domain and verify the contract address. Both are useful controls, but neither necessarily protects against a malicious frontend that captures an application specific secret.
‍

If an attacker legitimately controls a re-registered domain, they can generally obtain a valid TLS certificate. The browser can show HTTPS, a familiar hostname, and no certificate warning while still serving hostile code.
‍

The same limitation applies to contract verification. A fake frontend could deliberately send the user's deposit to the correct Tornado Cash contract because doing so makes the transaction appear legitimate. The malicious behavior may occur off chain when the frontend generates, copies, or exfiltrates the withdrawal note.
‍

This is why frontend integrity has to be treated as part of the security model rather than as a cosmetic layer sitting above secure smart contracts.
‍

Tornado Cash's Frontend Has Long Been a Critical Security Dependency
‍

Independent analysis from L2BEAT explicitly identifies the frontend as a critical component of Tornado Cash security for ordinary users. Its analysis notes that a compromised frontend can steal assets or undermine privacy even when the core contracts remain unchanged. (l2beat.com)
‍

Modern Tornado Cash access increasingly relies on ENS and IPFS rather than one conventional web domain. The relevant trust model uses an IPFS content hash referenced through tornadocash.eth, which gives technically capable users a way to verify the frontend more directly. That architecture reduces dependence on one centralized domain, but it does not eliminate the need for verification because the ENS content hash and governance process can themselves become part of the trust chain.
‍

For users handling very large transactions, the practical lesson is not simply “use ENS instead.” The stronger approach is to verify the current frontend through multiple maintained sources, compare the relevant ENS and IPFS information where technically practical, and avoid assuming that any interface is trustworthy merely because the URL, branding, or historical reputation looks familiar.

Hardware wallets remain essential for protecting private keys, and transaction simulation can reveal many malicious approvals, unexpected transfers, and wallet drainer techniques. Neither control necessarily addresses the specific failure described in this case.
‍

If a malicious frontend sends ETH to the correct Tornado Cash pool while copying the generated note, the hardware wallet may have nothing obviously malicious to display. The private key remains secure and the destination contract may be correct. The theft occurs because a separate application level secret has been exposed.
‍

Transaction simulation can face the same limitation. A simulator may accurately show that the ETH will enter a legitimate Tornado Cash contract, while the malicious behavior happens in the browser when secret material is copied. This distinction is important because experienced users often treat private key protection and transaction verification as the complete security model for self custody.
‍

They are important layers, but they do not cover every form of authority created during a crypto transaction.
‍

What High Value Crypto Holders Should Change
‍

The most useful response to this incident is not to replace one simplistic rule with another. “Always check the URL” is inadequate if the historically correct URL can change ownership, and “always use a hardware wallet” is inadequate if the attacker can steal an application generated withdrawal credential instead of the wallet key.
‍

For any financial or crypto service that has not been used for an extended period, users should treat the next interaction as a fresh trust decision. That means checking whether the project is still maintained, verifying its currently recognized interface through multiple active sources, reviewing recent security warnings, and confirming that the application being loaded today is the one the community currently recognizes.
‍

Application specific secrets should also be treated with the same seriousness as wallet credentials when they grant direct financial authority. A Tornado Cash note, a recovery secret, or another bearer style token can have economic value equivalent to a private key even if it does not look like one.
‍

For users handling genuinely large holdings, structural controls are more important than relying on perfect attention every time. Separating operational wallets from long term storage, using multisignature custody, requiring additional approval for high value movements, geographically separating keys, or introducing policy controls and withdrawal delays can reduce the damage caused by one compromised browser session or one stale assumption.
‍

Small test transactions can still be useful, but they are not conclusive because a patient attacker can allow a low value transaction to succeed. The larger objective is to avoid creating a system in which one interface, one person, or one browser session can put an entire treasury at risk.

This incident does not appear to involve a SIM swap, unauthorized port out, SMS interception, or carrier account takeover. Efani would not have prevented malicious JavaScript from stealing a Tornado Cash note, and it would be misleading to suggest otherwise.
‍

The connection to Efani's audience is broader. Crypto holders, founders, executives, and other high value targets face multiple attack surfaces that must be protected independently. Secure mobile service addresses the mobile identity layer, including SIM swap and port out risk, while hardware wallets and multisignature systems address custody, browser and endpoint tools address phishing and frontend integrity, and strong account security protects email, passkeys, password managers, and recovery channels.
‍

These controls complement one another because compromise can move laterally between layers. A secure hardware wallet does not stop an attacker from hijacking a phone number and resetting an exchange account. A secure mobile account does not protect against a malicious DeFi frontend. A verified smart contract does not prevent doxxing, coercion, or theft of an application specific credential.
‍

For high risk users, the most resilient model is a layered one in which no single security mechanism is expected to solve every problem. The reported 1,010 ETH incident appears to be a failure at the frontend and operational security layer. Its value as a case study comes from showing that a system can remain secure at several other layers and still suffer a catastrophic loss.

There are still important unanswered questions around this incident. We do not yet have a public forensic reconstruction of the complete 1,010 ETH flow, the alleged 4,000 ETH cluster remains unverified, and the evidence does not establish that U.S. sanctions directly caused the original tornado.cash registration to lapse.
‍

Those uncertainties should remain visible in any responsible account of the story. The verified domain history alone is enough to support the broader security lesson.
‍

tornado.cash genuinely was Tornado Cash's website. Its original registration dates to 2019, while the current registration begins in March 2025. The underlying Tornado Cash contracts continued operating even though the conventional web identity surrounding the protocol no longer had the same registration history.
‍

If the victim's account is ultimately confirmed in full, they were not defeated because they forgot which domain used to be legitimate. They may have been defeated because they remembered it.
‍

For high value systems, verification cannot be treated as a permanent event. Domains expire, organizations disappear, infrastructure changes hands, frontends evolve, and old links continue circulating long after the conditions that made them trustworthy have changed.
‍

A bookmark can preserve an address indefinitely. It cannot preserve the security state that existed when that address was first saved.