Registrar DNS hijacks hit DebugBear and at least 12 Name.com domains

Two separate attacks in the last week of October changed DNS at the domain registrar level and used the result to steal cryptocurrency from website visitors. Neither attack touched the victims' web servers. Both worked because whoever controls a domain's registrar record controls where every hostname under it points, including the hostnames that serve JavaScript to other companies' sites.

DebugBear's monitoring script served a wallet drainer on October 29

DebugBear sells real user monitoring (RUM), a script that site owners embed to measure page load times for visitors. Polymarket loaded that script. On October 29, Polymarket users began reporting unauthorized withdrawals, and the company put its international exchange into cancel-only mode at about 2:00 p.m. ET before resuming trading around 3:00 p.m. Hudson Rock researchers traced the activity to malicious JavaScript served from a cdn.debugbear.com URL that Polymarket's pages loaded.

The script ran inside logged-in browser sessions and used each session's trading permissions to sell positions or move funds to attacker wallets. It needed no passwords or private keys. Polymarket's October 30 update put the count at 726 affected wallets (one outlet reported 710). About $2.7 million was taken directly, and Polymarket added roughly $1.19 million in payouts to about 5,500 wallets hurt by the trading halt or forced sales, for a total near $3.9 million.

DebugBear's statement was short: "Our DNS server records were compromised through our domain registrar." It said it could not receive email at its own domain, found no sign of an internal breach, and believes one customer was targeted. It has not named the registrar or said how the attackers got access.

Name.com domains redirected to Step Drainer pages on October 30 and 31

Late on Friday, October 30 (U.S. time), visitors to several decentralized finance sites started landing on fake copies that prompted them to connect wallets. Blockaid flagged Flap and Kintsu at 02:54 UTC on October 31, tied the pages to a drainer kit sold as Step Drainer, and later identified ten more sites. Name.com posted that domains on its platform "were improperly redirected late Friday as part of a plan to access visitors' crypto wallets" and said it had restored them. ForkLog reports Name.com confirmed 15 domains; Name.com's public post said only "a number of domains."

The 12 publicly named domains were spread across four DNS providers. Six used Vercel DNS, three used NS1, two used Cloudflare, and one used Name.com's own nameservers, according to checks by Bitquery and Unchained. The only common factor was the registrar. Vercel, whose domain service runs on Name.com, counted 10 affected domains tied to its platform. Bitquery counted $202,386 drained from 32 wallets across six chains; The Block reported about $138,000, close to what attacker wallets held that evening.

No one has linked the two incidents to the same attacker or the same registrar, and neither root cause has been published.

Registrar controls that stop unauthorized nameserver changes

Moving DNS hosting to a different provider would not have helped any of these sites. The registrar holds the delegation, and DNSSEC does not stop a change made through the registrar, because the same account that edits nameservers can also remove or replace the DS record. Protection has to be on the registrar account and the registry record.

• Require two-factor authentication on the registrar account, preferably a hardware key or TOTP app rather than SMS. Remove former staff.
• Check the account's recovery email address. If it sits on the domain being protected, a hijack also locks you out of the reset process. Use an address on a different domain.
• Confirm the domain shows clientTransferProhibited. That status blocks transfers only. If your registrar offers clientUpdateProhibited, enable it so nameserver edits require unlocking first.
• For domains that carry revenue, ask about registry lock. It sets serverUpdateProhibited, serverTransferProhibited, and serverDeleteProhibited at the registry, and changes then require out-of-band verification by the registrar. Verisign offers it for .com and .net through participating registrars, usually for a fee.

Check current status with whois or RDAP:

whois example.com | grep -i 'domain status'
curl -s https://rdap.verisign.com/com/v1/domain/example.com | jq '.status'

A cron job that alerts on NS and MX changes

DebugBear lost inbound email when its records changed. An attacker who controls MX records can receive password-reset messages for every account tied to that domain, so watch MX alongside NS. This script stores a baseline on first run and mails a diff when either set changes. Send the alert to an address on a different domain.

#!/bin/sh
DOMAIN="example.com"
STATE="/var/lib/dnswatch"
mkdir -p "$STATE"
CURRENT=$( { dig +short NS "$DOMAIN" @8.8.8.8; dig +short MX "$DOMAIN" @8.8.8.8; } | sort )
if [ ! -f "$STATE/$DOMAIN" ]; then
  echo "$CURRENT" > "$STATE/$DOMAIN"
  exit 0
fi
if [ "$CURRENT" != "$(cat "$STATE/$DOMAIN")" ]; then
  printf 'Old:\n%s\n\nNew:\n%s\n' "$(cat "$STATE/$DOMAIN")" "$CURRENT" \
    | mail -s "DNS change on $DOMAIN" alerts@example.net
fi

Run it from cron every five minutes, and add the vendor domains your pages load scripts from, using NS records only, since CDN address records change constantly.

Third-party scripts on login and checkout pages

Every external script tag trusts the vendor's registrar account as much as your own. Gareth Bowker of Jscrambler noted that a content security policy allowing the vendor's domain would have permitted the malicious traffic, and that integrity hashes are impractical for RUM scripts that change often.

• List every script your site loads from another domain, including those injected by tag managers and WordPress plugins.
• Remove analytics, RUM, and chat widgets from login, account, checkout, and admin pages.
• Self-host static libraries you control and pin them with an integrity attribute.

Recovery steps after a hijack

Restore the correct nameservers, then change the registrar password and 2FA, and review the account's user list and API keys. Resolvers keep old answers until the TTL expires, and Kintsu warned users that some visitors would keep reaching the malicious site for a while. Search crt.sh for certificates issued for your domain during the hijack window, since anyone who controlled your DNS could have passed domain validation. Revoke any you did not request, and invalidate all active user sessions.

At Falcon Internet we treat a nameserver change on a client domain as an incident until someone confirms it was requested.