What The Name.com Hijack Shows About Domain Recovery
Coinspect’s 31st October findings show why restoring websites left separate work on domain settings and security certificates.
Restoring a domain’s usual destination does not settle every part of a website hijack. On 31st October, Name.com acknowledged that attackers had improperly redirected customer domains in an attempt to access visitors’ crypto wallets. It said the affected domains were restored and its investigation continued.
Our wallet guide explains how control of keys and transaction permissions affect that authority.
DNS translates website names into the information needed to reach them. A DNS zone is a separately managed part of that system, with its own records. A website certificate helps a browser authenticate the server for an encrypted connection.
Our CeFi and DeFi guide explains the separate roles of a website interface and the contracts used by a financial application.
Later that day, security researcher Coinspect reported that all 15 affected domains had recovered, while 13 DNS zones still pointed to an attacker address and 13 certificates remained valid until 29th January 2027. It also reported one server online. Those were observations on 31st October, not a measurement of continuing compromise today.
Where The Redirects Happened
Coinspect’s technical account describes preparations at Name.com between 00:35 and 01:20 UTC: the attacker set up zones covering 14 domains. Most normally used Vercel, Cloudflare, Akamai or NS1. The main attack path changed nameserver delegation at the registrar, rather than transferring ownership of the domains.
Nameserver records identify the servers responsible for answering DNS requests, as Cloudflare’s documentation explains. Changing which servers supply those answers can therefore redirect visitors even when the domain’s registered owner has not changed.
Coinspect said Name.com’s servers still answered queries for zones they hosted after public delegation had been restored elsewhere. Finding those zones established that configuration remained on those servers; it did not establish that normal public lookups still used them.
The researcher also documented two exceptions. SupSwap already used Name.com DNS, and Coinspect said its scanner captured the change in DNS records. Kintsu’s registrar-level nameservers did not change. Coinspect concluded that records within Kintsu’s existing zone had been altered, suggesting a different access path.
Name.com’s acknowledgement did not identify how the attacker initially obtained access.
Why Certificates Are A Separate Recovery Task
Certificate authority Let’s Encrypt documents a specific risk: someone who temporarily controls a server or its DNS configuration may obtain a certificate while retaining its private key, the secret cryptographic key paired with the certificate. Its recovery guidance treats revoking that certificate as a separate action after domain control is regained.
That general guidance does not establish which authority issued the certificates in this incident or their later revocation status.
Name.com’s own customer guidance asked registrants to review their DNS and nameservers, enable two-factor authentication and report unauthorised changes to support.
