DNS Security
DNS Security Alert: Registrar Hijack Drains $2.7 Million
By Nattapong Sukkasem · Published · Updated .
TL;DR — On 29 October a page-speed script that Polymarket loaded from a third-party monitoring vendor began emptying traders' accounts. Nobody broke into Polymarket, and the vendor reports no break-in to its own systems. DebugBear says its DNS records were changed at its domain registrar, so an unchanged hostname in Polymarket's markup started answering from someone else's server. About $2.7 million left 726 wallets inside an hour. Two days later researchers tied at least twelve more cryptocurrency sites to registrar-level hijacking. The DNS security lesson is that a dependency loaded by name is re-chosen on every page load.
Most supply-chain stories begin with a poisoned build or a hijacked package release. This one begins with a record change, and that is what makes it the most instructive DNS security incident of the week. No repository was touched. No version number moved. No file in Polymarket's own deployment was altered. The script tag was exactly where it had always been, pointing at exactly the hostname it had always pointed at, and the bytes behind that hostname were somebody else's.
One hostname, two companies, no code change
Polymarket embedded a Real User Monitoring loader from DebugBear, a UK website-performance firm, as an inline script in its server-rendered HTML. The file lived at cdn.debugbear.com and was served out of object storage. On 29 October the genuine 60,493-byte loader was replaced by a 15,187-byte one. The URL did not change. The markup did not change. The storage bucket holding the real file was never the problem.
That is the part worth sitting with, because it is where cloud security as most teams practise it simply does not reach. The object the vendor published was fine. The permissions on it were fine. What changed was the signpost: a name resolved somewhere new, and every browser that asked got the new answer.
Scott Helme's analysis of the incident, published on 30 October, records what the swapped file was allowed to do. Polymarket's Content Security Policy listed cdn.debugbear.com under script-src-elem, and every endpoint the malicious code contacted — the telemetry host, Polymarket's own API, a blockchain RPC provider and a swap-quote service — was already permitted by connect-src. The loader carried no integrity attribute, so nothing compared the delivered file against the hash of the one the vendor had shipped.
What the replaced script did
The drainer was narrow and patient. It waited about a second and a half, checked Polymarket's geoblock API, and then looked for three keys in browser local storage. Absent those keys it did nothing at all; present, it read the trading API credentials stored beside them, walked the React component tree until it found the application's order client, and used the signed-in trader's own session to act.
Self-custody accounts had their outcome tokens moved out in a single batch transfer. Email-login accounts had positions sold through fill-and-kill orders at 97 percent of price, then 50 percent, then the minimum tick, with the proceeds routed out through Polymarket's own offramp contract. Hudson Rock, which reviewed the code, found no routine for stealing passwords, seed phrases or private keys; it did not need one.
| Time (UTC) | Event |
|---|---|
| 27 Oct, 12:50 | Modification time encoded in the malicious file's ETag |
| 29 Oct, 17:10 | First funds reach the attacker wallet on Polygon |
| 29 Oct, 17:59 | Build metadata shows the script removed from Polymarket |
| 29 Oct, 18:05 | Exchange goes cancel-only; the relayer is paused |
| 29 Oct, 18:13 | A different server is observed answering for DebugBear |
| 29 Oct, 18:28–18:38 | 28.6 million POL moved on to three further addresses |
A campaign, not an isolated incident
On 31 October the security firm Blockaid flagged two cryptocurrency sites serving drainer code, then identified ten more. CircleID reported the same day that at least twelve were affected, among them Flap, Kintsu, Pickle Finance, Echelon, Origami Finance and FluxBeam. Kintsu stated that its domain had been hijacked at the registrar level and escalated the matter to its domain provider and to Name.com. No common attacker, registrar or technical cause has been established across the group, and nothing has formally linked the campaign to the DebugBear compromise two days earlier.
What they share is a method rather than a culprit. In each case the application was untouched and the delegation was not. There is no zero-day vulnerability anywhere in this story, and the attackers did not need one, because the control plane for a hostname is not a codebase at all — it is an account at a registrar, and accounts fall to phishing, session theft and support-desk persuasion rather than to exploits.
The supply chain nobody pinned
A decade of supply-chain security has been spent on artifacts: signed packages, lockfiles, reproducible builds, software bills of materials. All of it describes things with hashes. A third-party script tag has no hash unless somebody adds one, and the dependency it names is not resolved at build time. It is resolved in the visitor's browser, on every page load, by whichever nameserver currently holds the delegation.
The blast radius is what makes this DNS security story worth a change-control meeting rather than a shrug. A vendor that provides analytics, fonts, chat widgets, consent banners or performance monitoring typically appears on every page of every customer, including the signed-in ones where money moves. One registrar account, belonging to a company most of those customers have never had a contract review with, decides what that code is.
Detection inherits the same shape. A DDoS attack announces itself: the site stops answering and the graphs move. Here the site answered normally throughout, served the same markup it always had, and reported healthy. Availability was perfect. Integrity was the thing that failed, and the only places it was visible were the bytes behind an unchanged URL and the address behind an unchanged name.
Where resolution comes into it
Two properties of the delegation layer decide how incidents like this end. The first is caching. Kintsu warned that even after a record is corrected, cached answers keep steering visitors to the attacker for as long as their time-to-live permits, so the moment a vendor fixes its DNS is not the moment exposure stops. Checking what the authoritative servers and the public resolvers are each handing out, with a DNS propagation checker, is how you tell those two moments apart.
The second is who does the asking. For a third-party script, the lookup happens on the visitor's machine, not yours. If their browser uses DNS over HTTPS to a public resolver, the query never reaches your corporate resolver, never meets your response-policy zone, and never lands in your logs. Your blocklist cannot help a visitor whose resolution path does not pass through you. DNSSEC is not the backstop here either: a change made with the registrar's authority is a legitimate change, and a validator will sign off on an attacker's records exactly as readily as on yours.
What to check this week
- Lock the names before anything else. Turn on registry lock or the registrar's equivalent for every production domain, put phishing-resistant two-factor authentication on the registrar account.
- Inventory the hostnames that execute, not the packages. Pull every
script src, iframe and tag-manager container across your signed-in pages and list the domains. Those are the names that can be re-pointed without your involvement. - Pin what you can and report on what you cannot. Add
integritywithcrossorigin="anonymous"to third-party scripts that publish stable builds, and use report-only integrity and CSP reporting to find the ones that do not. - Alert on the record, not just the response. Monitor the NS and A records of your vendors' script hosts as well as your own. A delegation change at a dependency is an IT security event even when the site it serves looks perfectly healthy.
- Keep third-party code off pages where value moves. Analytics on a marketing page and analytics on a trading screen are not the same risk, whatever the vendor is called.
- Baseline the answers you depend on. A network diagnostic tool run against your own domains and your vendors' records captures what normal looks like, which is the comparison you will wish you had during the next incident.
What it means
The hedges deserve to be carried at full strength. DebugBear says its registrar was the route in and that it has found no evidence of a breach of its own systems, but it describes the investigation as continuing. The twelve-site campaign has no confirmed entry point, no named registrar beyond the provider Kintsu escalated to, and no established connection to the DebugBear incident. Polymarket has not published a technical post-mortem of its own, and the drainer analysis comes from firms examining the recovered file rather than from the platform.
What is not in doubt is the shape of the exposure, and it is a shape almost every website shares. Code you did not write, fetched from a name you do not control, runs with the full authority of the page it lands on. The protections the industry built for that risk — allow-lists and integrity hashes — are good, and in this case one was in place and the other was not. But they sit downstream of a simpler question that this cycle of DNS security news puts squarely on the table: who, exactly, can change where your dependencies come from, and would you find out from them or from your customers?
Sources
- The Hacker News — Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script
- Scott Helme — Polymarket's CSP Allowed Every Part of the $2.6 Million Crypto Theft
- CircleID — DNS Hijacking Campaign Targets 12 Cryptocurrency Sites as Registrar-Level Compromise Investigated
- Reflectiz — Polymarket Hack: DebugBear Script Drained $2.7M
Related articles
Browse every DNS news article by month →
DNS angle
Review resolver logs for the systems discussed above and compare unexpected names with your approved services. A successful lookup does not establish that a destination is safe. Use the DNS lookup tool to inspect current answers, then compare them with your own resolver and incident records.
Source: The Hacker News — Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script ().