Cowrie Research

curve-finance-dns-hijack-malicious-approval-drain-2022-08-09

15 min read

Curve Finance DNS Hijack / Malicious Approval Drain (2022-08-09)

  • Name: Curve Finance DNS hijack / malicious approval drain
  • Date: 2022-08-09
  • Protocol: Curve Finance
  • Chain: Ethereum
  • Category: front-end compromise / DNS hijack / approval phishing / ice phishing / wallet-permission drain
  • Loss: about 340 ETH, roughly $573k-$605k depending on pricing and later fund-freeze accounting
  • Summary: Curve’s core AMM and gauge contracts were not exploited. Instead, the curve.fi domain was hijacked at the DNS / nameserver layer and briefly redirected to an attacker-controlled front end. Users who visited the real Curve domain during the incident saw a malicious wallet prompt that approved attacker contract 0x9eb5f8e83359bb5013f3d8eee60bdce5654e8881. Once victims signed, the attacker used those permissions to pull tokens from their wallets and route proceeds toward exchange accounts and Tornado Cash. Curve’s unaffected alternate interface at curve.exchange kept working because the exploit lived in web delivery, not in the onchain protocol.
  • Trigger / entry point:
    • On 2022-08-09, the curve.fi domain began resolving to attacker-controlled infrastructure after a registrar / nameserver compromise affecting Curve’s DNS path.
    • Curve publicly warned users that curve.fi was compromised, emphasized that the protocol’s contracts were safe, and redirected users to curve.exchange while the DNS incident was contained.
    • The malicious site preserved Curve branding and workflow closely enough that victims believed they were performing normal DeFi actions through the canonical domain.
    • The injected front end asked wallets to approve attacker contract 0x9eb5f8e83359bb5013f3d8eee60bdce5654e8881, after which the attacker could drain approved ERC-20 balances with ordinary transferFrom() style calls.
  • Root cause:
    • The decisive failure was not in Curve’s smart contracts. It was in the web2 naming and delivery control plane that users relied on to reach the real interface.
    • Curve’s contracts remained trustworthy, but DNS stopped directing users to Curve-controlled web infrastructure. Once that happened, the genuine domain name no longer implied genuine transaction construction.
    • The preserved invariant is the canonical Curve domain must never prepare approvals to an attacker-controlled spender. DNS hijack broke that invariant before any onchain interaction reached Curve’s contracts.
    • This incident is worth preserving separately from generic phishing because the victim did not necessarily mistype a URL or click an obviously fake link; the trusted domain itself temporarily served the wrong wallet instructions.
    • It is also a useful boundary case against third-party runtime allowance and integrity pinning: Curve did not first fail because its real page allowed one still-legitimate remote wallet script to mutate signer behavior; it failed earlier, because the naming layer itself stopped proving that the browser was even talking to Curve-controlled infrastructure.
  • Exploit path:
    1. The attacker gained control over the DNS / nameserver path for curve.fi.
    2. Visitors to the real Curve domain were redirected to attacker-controlled infrastructure serving a malicious clone of the Curve interface.
    3. The clone prompted victims to approve attacker contract 0x9eb5f8e83359bb5013f3d8eee60bdce5654e8881 while the surrounding workflow still looked like normal Curve usage.
    4. Victims signed because the request came from the expected domain and matched the rough interaction pattern of a DeFi approval flow.
    5. After approval landed onchain, the attacker called into the malicious contract and drained approved tokens from victim wallets.
    6. The attacker consolidated proceeds in address 0x50f9202e0f1c1577822bd67193960b213cd2f331, then moved funds to CEX deposit paths and Tornado Cash.
    7. Curve restored control of the domain, but any approval already granted to the malicious spender had to be revoked by users; contract safety alone could not undo wallet permissions that had already been signed.
  • What the attacker needed to be true:
    • Control of the curve.fi DNS / nameserver path had to be sufficient to serve attacker-controlled frontend code from the canonical domain.
    • Wallet UX had to make the malicious spender approval look close enough to a routine DeFi permission prompt that users would sign it.
    • Victims needed to hold ERC-20 balances with no extra transfer restrictions once spender approval existed.
    • Detection and takedown had to lag long enough for a meaningful set of approvals to accumulate.
  • Technical anatomy worth remembering:
    • This was not a protocol drain in the Solidity sense. Onchain, users simply approved a spender and that spender later used standard token-transfer authority.
    • DNS control was effectively wallet-policy control because the frontend assembled the transaction request that users trusted.
    • Curve’s unaffected curve.exchange endpoint is a useful contrast: the same protocol contracts remained safe while one naming / delivery path became malicious. That makes the web-delivery boundary unusually legible.
    • The incident also shows why contracts are safe is not enough operationally. If the canonical domain is compromised, users can still lose funds without any bug in the protocol contracts themselves.
  • Representative transactions and addresses:
    • Malicious spender / approval target: 0x9eb5f8e83359bb5013f3d8eee60bdce5654e8881
    • Attacker consolidation address: 0x50f9202e0f1c1577822bd67193960b213cd2f331
    • Example victim approval transaction to the malicious contract: 0xf63d9f7cc45395f3cfaaedadac14f86b0b0669c5314e0a23928c800c12fc5ad5
    • Example attacker transfer / drain transaction highlighted in incident analysis: 0x525fb894ed485b2cbdbdfaccedc3d405ba0f4659816ca4b639be7dd22e31a5e4
    • Curve’s public emergency revoke target during the incident: 0x9eb5f8e83359bb5013f3d8eee60bdce5654e8881
  • Response / mitigation:
    • Curve publicly warned users away from curve.fi, redirected them to curve.exchange, and later announced that control of the affected domain path had been restored.
    • Security researchers, exchanges, and monitoring firms traced stolen assets; public reporting indicated that some funds reaching CEX paths were frozen while other proceeds moved into Tornado Cash.
    • The immediate user-side fix was approval revocation, because the main danger after the frontend was restored was the already-granted spender permission.
    • Curve’s public post-incident commentary pointed toward the registrar / nameserver layer rather than a compromised Curve application account as the likely root of the DNS takeover.

Pattern tags

  • frontend-compromise-approval-phishing
  • Same canonical domain, different resolver-controlled site: curve.fi still looked like the right destination to users, but DNS / nameserver control no longer proved they were reaching Curve-controlled infrastructure
  • User-signed allowance capture, not protocol-contract breakage: the draining primitive was still an attacker-earned spender approval later exercised with ordinary token-transfer authority
  • Separate unaffected fallback interface mattered operationally: curve.exchange kept serving the same contracts through a different DNS path, which made the failure boundary unusually clear and gave users a live-safe alternate route during containment
  • Fast public revocation guidance limited additional damage, but could not retract allowances already granted from user wallets while the malicious frontend was live

Why the exploit worked

  • Curve’s strongest user trust signal — the canonical curve.fi domain — remained visually intact while the naming layer beneath it stopped proving that the browser was still talking to Curve-controlled infrastructure. That let the attacker harvest approvals without needing typo-squatted branding or obvious phishing lures.
  • The malicious prompt stayed close to a normal DeFi approval flow. Users were not being asked to do something categorically foreign to Curve usage; they were being asked to authorize the wrong spender inside a familiar sequence.
  • DNS / nameserver control was enough to become wallet-policy control. Once resolver trust moved traffic to the attacker’s cloned interface, the attacker effectively chose what spender address victim wallets were asked to trust.
  • Curve’s contracts being safe did not matter for already signed approvals. After a wallet authorized 0x9eb5f8e83359bb5013f3d8eee60bdce5654e8881, the attacker no longer needed any further weakness in Curve itself.
  • The incident shows why web naming and delivery recovery are only half the response problem: the other half is finding every wallet that granted live authority during the compromise window and getting those permissions revoked before they are fully monetized.

Three signer-authority promotions this incident collapsed

  1. A canonical signer-facing domain still existed

    • Users were still going to curve.fi, which remained the socially recognized Curve destination even after the attacker-controlled DNS answer stopped routing browsers to Curve-controlled infrastructure.
    • The weak first claim therefore still held in users’ heads: this is the real Curve site I normally trust when I decide whether to sign.

  2. That resolver-controlled site was still treated as canonical Curve prompt truth

    • Once the DNS / nameserver path stopped proving that the browser was reaching Curve-controlled delivery, the fetched clone was no longer Curve-authored wallet-prompt truth even though the hostname still looked right.
    • The dangerous promotion was from the browser is at curve.fi to the spender this page is asking me to approve must still be Curve's intended authority object for this exact action.

  3. Those accepted prompts still inherited live wallet authority after recovery

    • Victims did not just view a fake site; they signed approvals to 0x9eb5f8e83359bb5013f3d8eee60bdce5654e8881 that remained economically live after Curve restored control of the domain.
    • That is why domain recovery and user recovery were separate jobs: the accepted prompt had already become durable spender authority in user wallets, so restoring curve.fi could not retract what the attacker had already harvested.

Detection and audit pivots

  • Inventory every authority that could have changed where curve.fi resolved during the incident window: registrar account controls, nameserver delegation, DNS provider access, domain recovery channels, and any emergency failover path to alternate providers.
  • Monitor for approvals originating from the canonical domain to fresh spender contracts or EOAs, especially when the approvals cluster tightly in time and are not followed by normal protocol interaction patterns.
  • Ask whether the protocol can independently verify and publish the spender addresses its live frontend is currently presenting, so users and wallets are not forced to treat the domain name alone as sufficient evidence.
  • Treat fallback interface on a different DNS provider still works as a design clue, not only an incident anecdote. If alternate entrypoints differ in trust dependencies, responders need a preplanned way to steer users onto the still-trustworthy route fast.
  • Test whether incident response can push two messages at once: stop using the canonical domain immediately and revoke this exact spender now. In wallet-drain incidents, the second message is often the one that actually limits realized losses.

Failure-prevention checklist

  • Treat registrar, DNS provider, nameserver delegation, recovery email, and registrar-support escalation paths as signer-critical custody infrastructure. The system that decides where the canonical domain resolves is already deciding who gets to ask users for wallet authority.
  • Keep signer-facing entrypoints smaller and more static than the rest of the product. If curve.fi can ask for approvals, its runtime and routing path should have fewer mutable dependencies, fewer admins, and tighter change visibility than ordinary marketing or documentation pages.
  • Pin or machine-verify the spender addresses the live frontend is allowed to present, so a recovered domain cannot silently keep asking wallets to trust a fresh EOA or unknown contract after the main DNS issue appears resolved.
  • Prefer exact-amount approvals, bounded permits, short expiries, and route-local signer authority over durable unlimited allowances wherever Curve-style flows permit it.
  • Rehearse degraded-mode routing before the next incident. If curve.exchange or another fallback interface is supposed to carry users safely during a naming-layer incident, operators should already know how to publish, verify, and steer users onto that path fast.
  • Build response around the asymmetry this incident exposed: restoring the domain and revoking already granted wallet authority are different jobs. User comms, spender-specific revoke guidance, wallet-partner alerts, and blocklist publication should already be prepared.
  • Continuously reconcile live frontend spender inventory against onchain approval telemetry so canonical domain, wrong spender becomes detectable within minutes instead of after drains consolidate.
  • Keep wallet-critical trust proofs explicit after recovery: which registrar state, DNS answers, TLS endpoints, frontend bundle hashes, and spender allowlists prove that the canonical domain is genuinely safe again right now?

Audit prompts

  • Which exact people, vendors, and recovery channels can change where curve.fi resolves today, and which of those paths still depend on weak account recovery, legacy registrar support, or manual human escalation?
  • If curve.fi suddenly resolved somewhere else for one hour, what largest authority could the attacker realistically harvest from users now: unlimited ERC-20 approvals, Permit2 rights, signature-based permits, or broader account/session authority?
  • What independent control proves that the spender currently shown by the live Curve UI is one of Curve’s intended protocol destinations rather than a fresh attacker EOA or unknown contract?
  • Can responders quickly prove that curve.exchange or another fallback entrypoint really differs in trust dependencies from curve.fi, or would both routes quietly share the same underlying naming, CDN, or runtime failure?
  • Which alert would fire first if the canonical domain began farming approvals again right now: changed DNS / nameserver state, unexpected frontend-byte drift, unfamiliar spender prompts, or only later transferFrom() drains?
  • Once a naming-layer compromise is suspected, how quickly can Curve both stop new signatures and push exact revoke instructions for wallets that already authorized the malicious spender?
  • Does the wallet-critical route depend on mutable remote scripts, config blobs, or loader-selected runtime code even after DNS resolves correctly, and if so what stronger control proves those bytes still belong to Curve?
  • After recovery, what exact evidence would justify telling users the domain is safe again rather than only the homepage is back?

Lessons that should already be standard

  • The canonical domain is custody infrastructure once users trust it to construct wallet transactions. DNS and registrar control are not just web-ops hygiene; they are delegated authorization control.
  • Contracts are safe is operationally incomplete when the real user loss path is wallet approved the wrong spender from the right-looking site.
  • Domain authenticity is only useful if it still proves runtime authenticity. curve.fi on the address bar did not mean the browser was still executing Curve-authored transaction-construction logic.
  • Recovery from naming-layer compromise is not complete when the domain resolves again; it is complete when operators can prove the fetched bytes are clean and users know which malicious approvals still need revocation.
  • Safe fallback routes are real security controls only if the team already understands which trust dependencies they do and do not share with the canonical domain.
  • Approval telemetry is incident telemetry. In a DNS-hijack wallet drainer, the first meaningful exploit transaction is often the user approval, not the later attacker cash-out.
  • Unlimited allowances turn a short DNS incident into durable theft rights. Shorter-lived and narrower approvals are not minor UX polish; they are containment tools.
  • The phrase visit the real domain is not enough guidance on its own. Users and operators both need a stronger answer to what proves the real domain is still serving the right wallet-prompt bytes?

Why this incident matters

  • It is a clean large-scale example of the real domain, wrong spender branch of wallet-permission theft.
  • It preserves a sharp same canonical domain, different resolver-controlled site case where the canonical hostname remained socially authentic while the fetched wallet-prompt surface had already stopped being Curve-controlled.
  • It sharpens the control-surface lesson that DNS, registrar, and nameserver integrity are custody infrastructure for any protocol whose users depend on a web interface to build wallet transactions.
  • It is also a clean exemplar for canonical-domain runtime-byte integrity: the naming layer itself stopped proving that the browser session still resolved to Curve-controlled HTML, script URLs, and wallet-construction logic.
  • It also complements third-party runtime allowance and integrity pinning by marking the earlier failure boundary: before asking which third-party scripts the real Curve page should have been allowed to execute, users first needed curve.fi itself to keep resolving to Curve-controlled delivery at all.
  • It is also a useful where this note stops contrast for the release-integrity branch. Curve is not the same real site, different loader-resolved bytes cousin preserved by Ledger Connect Kit, and it is not the same familiar runtime URL, different operator-resolved bytes cousin preserved by Polyfill.io. The naming layer itself stopped proving that the browser was still reaching Curve-controlled delivery.
  • It also complements BadgerDAO well: Badger showed the same real site, different edge-served bytes cousin inside the real site, while Curve showed the even earlier naming-layer failure where the canonical domain stopped proving the browser was still reaching Curve-controlled delivery at all.
  • It also preserves the routing boundary against software supply-chain compromise and release-provenance failure: the decisive compromise sat in Curve’s own registrar / DNS / nameserver path, not in a shared upstream package ecosystem or in the reviewed artifact vs loader-resolved artifact drift family.

Internal linkages

  • Core recurring pattern: frontend-compromise-approval-phishing.
  • Positive-design companion: canonical-domain-runtime-byte-integrity — the narrower architecture question here is what the canonical Curve domain should have proved about registrar control, DNS resolution, fallback entrypoints, and the exact browser-fetched runtime bytes before users trusted any spender approval.
  • Boundary-setting browser-policy companion: third-party-runtime-allowance-and-integrity-pinning — Curve is useful partly because it shows where that narrower third-party-runtime question starts too late: here the browser had already left Curve-controlled delivery before script-allowance policy on the real page could even matter.
  • Adjacent positive-design companion: signer-intent-truth-security-object — the user-facing lesson is that the human intent object broke before chain execution, because the canonical domain cue no longer corresponded to Curve’s intended spender meaning.
  • Boundary note: software-supply-chain-compromise and release-provenance-failure — useful contrasts for the broader wrong bytes reached the user family, but Curve stays on the naming-layer compromise branch because the decisive authority failure was Curve’s own registrar / DNS / nameserver path rather than the same real site, different loader-resolved bytes branch preserved by Ledger Connect Kit or the same familiar runtime URL, different operator-resolved bytes branch preserved by Polyfill.io.
  • Adjacent pattern: arbitrary-call-token-approval-drain — both end with approved wallets losing tokens, but Curve captured the approval upstream through a compromised interface rather than through a buggy onchain router.
  • Related incident with a different front-end control-point failure: badgerdao-cloudflare-worker-injected-approval-drain-2021-12-02.

Control surface

Graph View

Backlinks