Threat intel

Name.com DNS hijack sends DeFi users to a wallet drainer

By Yaali. November 1, 2026, 6 min read, Threat intel, Identity, Resilience.

A dozen DeFi front ends registered at Name.com served the Step Drainer kit for a night. What happened, how to lock down your domain and how to check it.

On the night of Friday, October 30, people who typed the correct address for Flap, Kintsu, Pickle Finance, Origami Finance, FluxBeam, Echelon, StonkFun, StakePoint and four other DeFi projects landed on pages that asked them to connect a wallet and approve transactions. Security firm Blockaid identified 12 sites serving Step Drainer, a wallet drainer kit sold as a service. Every one of the 12 domains was registered at Name.com, and Name.com later said 15 of its customers' domains had been "improperly redirected". No smart contract was touched; the attackers changed where the names pointed.

The Block traced about $138,000 to the attackers' wallets on Ethereum-compatible (EVM) chains, a figure that leaves out any losses on Solana and Aptos. The root cause is still unconfirmed. If you run a public web front end, and especially one that asks users to sign anything, the same path runs through your registrar account, your DNS host and whoever resells either to you.

How it works

A domain has two layers of control. The registrar (here Name.com) holds the registration and tells the registry which nameservers are authoritative for the name. The DNS host then answers the actual lookups, returning the A, AAAA or CNAME records that send a browser to a server. Change the nameserver delegation at the registrar and every lookup goes to whoever runs the new nameservers, whatever DNS host the owner chose.

According to The Block and FinanceFeeds, the affected projects used different DNS hosts: Cloudflare, Vercel and Name.com's own nameservers. The only thing all 12 shared was the registrar. Crypto Briefing reported instead that the domains all relied on Name.com's nameservers, so the outlets disagree on this point. Either way, recovery came at the delegation layer: Flap and Kintsu were left out of the later suspensions because their teams had already moved their nameservers, and Flap moved users to a new address, flap.cool.

Once DNS pointed at attacker servers, visitors saw a copy of the familiar site with drainer code added. Step Drainer shows a fake wallet-connect window and then asks the user to sign token approvals or signatures that let the attacker move funds without ever holding the private key. LevelBlue SpiderLabs documented it in April as malware-as-a-service supporting more than 20 blockchain networks, sold at about $750 for the full source or about $150 plus a 20% share of what affiliates steal.

What attackers did

Flap's site was flagged as compromised at about 9:10 p.m. Eastern on October 30, and Flap warned its users of a DNS hijack shortly after 10 p.m. Blockaid named Flap and Kintsu at 10:54 p.m. and listed ten more sites soon after. At 8:32 a.m. on Saturday, October 31, ten of the domains were placed on clientHold at the registrar, a status that stops a name from resolving at all. By late morning the holds had lifted and the domains resolved again.

On the money side, The Block found a fixed split: each payout went 55%, 30% and 15% to three wallets, with matching payments on Ethereum, Robinhood Chain and Monad. On BNB Chain, one recipient wallet collected about 3.1 BNB from four victims between 9:00 and 9:42 p.m. FluxBeam and StonkFun said they knew of no affected users, and no project has published a victim count.

How the attackers got the access is not established, and the public statements point in different directions:

• Name.com said it restored all affected domains, is securing the accounts involved, and urged customers to check their DNS records and turn on two-factor authentication.
• Kintsu and Origami Finance pointed at Vercel-related infrastructure. Vercel resells domains with Name.com as its registrar, and Vercel's bulletin says 10 of the affected domains were on its platform and that Name.com has restored them.
• Neither company has said whether one compromised account, a reseller or partner interface, or Name.com's own systems made the change.

What to do

Lock the domain at the right layer

1. Find who actually controls each production domain. If you bought it through a hosting platform, the registrar account may belong to that platform, and its security settings are not yours to set.
2. Turn on two-factor authentication for every registrar, DNS host and reseller account that can edit the domain, using a security key or passkey where the provider offers one, since a phished one-time code can be replayed. On Name.com, Two-Step Verification uses an authenticator app code and sits under Settings, then Security Settings; save the backup codes offline. Remove former staff and unused API tokens.
3. Ask the registrar which lock blocks nameserver and record updates, not only transfers. A plain transfer lock (clientTransferProhibited) does nothing against a delegation change.
4. For a domain that carries money, use registry lock. For .com and .net, Verisign sets serverUpdateProhibited, serverDeleteProhibited and serverTransferProhibited, and will only unlock after phoning an authorised person at the registrar who gives a security phrase. It does not cover records changed at your own DNS host. Not every registrar offers it, which is a reason to move a critical name.

Watch for changes

Poll the delegation and your key records from outside every few minutes and alert on any difference: dig +short NS yourdomain.com and dig +short A app.yourdomain.com, compared against a stored known-good list. Most hijacks also need a TLS certificate for the attacker's server, so subscribe your apex domains to a Certificate Transparency monitor and alert on any issuer or ACME account you do not use. Our post on the .gh, .sl and .as registry hijacks covers CAA account binding for that step.

Check whether you were hit

• Pull the registrar's account activity or audit log for October 30 and 31 and look for logins, API calls, nameserver or record changes you did not make.
• Run whois or an RDAP lookup and look for an unexpected clientHold or nameserver set, then compare against a passive DNS history service for the same dates.
• Search crt.sh for %.yourdomain.com and list certificates issued from October 30 onwards.
• If users connected during the window, tell them to revoke token approvals with a tool such as Revoke.cash and move funds to a fresh address.

Protect your users when DNS fails

Publish your contract addresses somewhere outside your own domain, and tell users to use a wallet that simulates each transaction and shows the asset changes before signing. A deposit page should never need an unlimited approval for a spender address the user does not recognise, and a simulation makes that visible before the signature.

The wider lesson

A DeFi team can audit its contracts line by line and still lose users through a registrar login. The domain, the DNS host and the reseller in between are part of the application's attack surface and need the same access review, logging and alerting as production servers.

Our attack surface management work tracks your domains, delegations and new certificates, and our smart contract audits include the front end and the signing prompts users actually see. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: The Block, Crypto Briefing, Crypto Briefing on the restoration, TokenPost, FinanceFeeds, The CyberSec Guru, Crypto Adventure, Verisign registry lock, Name.com Two-Step Verification guide.