Security Operations

Name.com hijack sends 15 domains to wallet drainer: DNS lessons

Attackers redirected 15 Name.com domains to a crypto wallet drainer. Why registrar accounts belong in your SOC’s monitoring, and what to lock down now.

Network graphic illustrating domain names redirected to an attacker-controlled server after a registrar compromise

Overnight on 30 to 31 October, someone changed the DNS for 15 domains held at the US registrar Name.com, and visitors to a dozen crypto sites landed on copies built to empty their wallets. The projects’ smart contracts were never touched, which shows that a registrar account is part of your attack surface, and one most SOCs do not watch.

What happened

Late on Friday 30 October, US time, users of several small decentralised finance (DeFi) projects opened sites they use regularly. The address bar showed the correct domain and the pages looked normal. Behind them sat attacker-controlled copies running Step Drainer, a wallet-draining kit that asks visitors to sign transactions which hand over their tokens.

The wallet security firm Blockaid raised the first public alert, naming the token launch platform Flap and the staking service Kintsu. It then named ten more, including Pickle Finance, Origami Finance, FluxBeam, Echelon, StonkFun and StakePoint. Public registry records showed that every domain on the first list was registered through Name.com.

Name.com confirmed on X that domains had been improperly redirected to target visitors’ wallets. It told The Block that 15 customer domains were affected and that all of them had been restored. On the Saturday morning it briefly placed ten domains on client hold, which stops a name resolving at all, and lifted the holds later the same day. Vercel said in a security bulletin that ten of the affected domains were linked to its platform and that it was helping the investigation. Neither company has said how the attackers were able to change the records.

Estimates of the losses differ. The Block traced about $138,000 to three attacker wallets on Ethereum-compatible chains as of Saturday morning. Bitquery later counted what each victim lost and put the total at $202,386 from 32 wallets across six chains. By Bitquery’s count, one Kintsu staker on Monad lost $160,531, and two wallets account for 96 per cent of the total. Neither figure covers possible losses on Solana or Aptos, where several of the affected projects run.

The technical picture

The attack did not touch any smart contract, and Kintsu, Origami, FluxBeam and StonkFun all said their on-chain code was unaffected. The attackers went after the step before the application: resolving its name. Whoever can change a domain’s delegation or records at the registrar can send every visitor to infrastructure of their choosing. TLS does not protect visitors in that case either. An attacker who controls DNS can usually pass the domain validation a certificate authority uses and obtain a valid certificate, so browsers show the usual padlock.

Bitquery found that the hijacked sites did not share a DNS host: between them they used Vercel, NS1, Cloudflare and Name.com’s own service. The one thing they had in common was the registrar. Kintsu blamed something “on Vercel’s end”, and Origami warned of an attack on Vercel-associated nameservers. Vercel’s domain service runs on Name.com, but so far none of the parties has identified the entry point. CircleID notes that DNSSEC would not necessarily have helped, because a change made through a legitimate registrar channel looks authorised to the DNS.

The timeline shows how short the window is. Bitquery’s earliest traced drain landed at 01:00 UTC on 31 October. Blockaid’s warning followed at 02:54 UTC, and nearly all the counted thefts happened before 04:00. Name.com’s holds came around midday. Bitquery also found that the kit swept every chain a wallet held funds on, emptying one victim on Base, BNB Chain and Ethereum within 80 seconds.

Timeline of the Name.com DNS hijack on 31 October 2026, from the first wallet drain at 01:00 UTC to the restoration of all 15 domains

Why it matters for UK organisations

It would be a mistake to file this under crypto. The technique works the same way against a bank login page, a council payments portal, a webmail domain or the hostname that serves your single sign-on. It also does not need to be a front-end swap. Control of DNS lets an attacker redirect MX records and read inbound email, issue certificates, or take over subdomains that third parties trust. Days earlier, the web performance monitoring firm DebugBear, whose script was abused in a 29 October theft from Polymarket users, said its own DNS had been compromised through its registrar. That was a separate incident, and no link to this campaign has been established.

For UK organisations covered by NIS, or preparing for the Cyber Security and Resilience Bill, domain and DNS management belong in supply chain risk assessments in the same way as hosting and SaaS. Registrar accounts often sit on a single shared login, set up years ago by someone who has since left.

Expert view

When we scope external tests, the registrar is almost never in the asset register. Ask who holds the domain account, whether it has multi-factor authentication and whether the domain is locked at the registry, and the room tends to go quiet. In my experience, that one account can undo years of investment in endpoint and identity controls, because it sits upstream of all of them.

The detection gap is just as real. Most SOC monitoring looks inward, at endpoints, identities and cloud logs. A change to your nameservers or A records happens somewhere else entirely, and unless something is watching it from outside, the first sign is often a customer complaint or a third party’s alert, as it was here. When many organisations share only a registrar or reseller platform, that provider is a single point of failure for all of them.

Early disclosure was reasonable but thin. A registrar facing this kind of incident should say quickly whether the access came from customer credentials, an API or reseller channel, or its own systems, because each calls for a different response from its customers. That answer is still missing.

What to do now

  1. Find and secure your registrar accounts. List every domain you own and where it is registered. Enforce phishing-resistant MFA, remove stale users and stop using shared logins. This fits the Cyber Essentials user access control requirements.
  2. Turn on registrar and registry locks for critical domains, so that nameserver or ownership changes need out-of-band verification.
  3. Monitor DNS from outside. Alert on any change to NS, A, AAAA, MX and CNAME records for key domains, and compare the results against an agreed baseline.
  4. Watch Certificate Transparency logs for certificates issued for your domains that you did not request.
  5. Check your supply chain. Ask hosting, DNS and SaaS providers which registrar they rely on and how they would tell you about a compromise.
  6. Write a registrar runbook. Include named contacts, escalation routes, how to request a hold or rollback, and how to warn users fast. Teams that moved their nameservers quickly reportedly limited the damage.
  7. Plan for cached DNS. Kintsu warned that cached records could keep sending users to the malicious site after the fix, so build that delay into your user communications.

Bottom line

Fifteen domains, one registrar and a few hours were enough to steal six figures without touching a single smart contract. Wherever the root cause turns out to be, the takeaway for defenders is clear. Your domain registrar is critical infrastructure. Lock it down, monitor it from outside and rehearse what you would do if your name started pointing somewhere else.

Sources

Related Posts