Cowrie Research

balancer-fi-eurodns-social-engineering-nameserver-hijack-approval-drain-2023-09-20

15 min read

Balancer.fi EuroDNS Social-Engineering Nameserver Hijack / Approval Drain (2023-09-20)

  • Name: Balancer.fi EuroDNS social-engineering nameserver hijack / approval drain
  • Date: 2023-09-20
  • Protocol: Balancer
  • Chain: Multi-chain EVM (Ethereum, Avalanche, Arbitrum, Polygon)
  • Category: front-end compromise / registrar social engineering / nameserver hijack / approval phishing / permit phishing / wallet-permission drain
  • Loss: community tracking later estimated about $364k, while Balancer’s later restitution process validated 7 claimant wallets totaling about $330,521.91 at attack-time prices
  • Summary: Balancer’s pools and Vault contracts were not exploited directly. Instead, on 2023-09-20 at about 00:42 CET, an attacker used social engineering against EuroDNS—the registrar managing the balancer.fi domain—to change the domain’s nameservers. Visitors to the real balancer.fi hostname were then served a phishing frontend forked from the real Balancer app. That clone prompted users to approve or sign permissions for attacker-controlled spend paths, including a conspicuous allowance target 0x00006deacd9ad19db3d81f8410ea2b45ea570000. Balancer’s later postmortem said the attacker mixed token approvals, permit signatures, and Permit2 transactions depending on the wallet and token set they encountered. Community reports and Balancer DAO reimbursement proposals later tied the incident to at least seven verified damaged wallets across Ethereum, Avalanche, Arbitrum, and Polygon.
  • Trigger / entry point:
    • Balancer’s official postmortem said the incident began when a hacker updated the nameservers for balancer.fi through a successful social-engineering attack on EuroDNS, the registrar used for the .fi domain.
    • The malicious site was a fork of Balancer’s actual frontend, so the surrounding UX, branding, and transaction flow still looked plausibly genuine.
    • Users noticed suspicious prompts asking them to Allow tokens to use our new protocol, with one highlighted spender address padded with zeros at both ends: 0x00006deacd9ad19db3d81f8410ea2b45ea570000.
    • Balancer’s postmortem explicitly said no one on the frontend team or elsewhere in the Balancer ecosystem had lost credentials or been infected with malware; the decisive failure lived at the registrar / naming layer instead.
  • Root cause:
    • The decisive failure was not in Balancer’s Solidity or Vault accounting. It was in the web2 naming control plane users relied on to reach the real Balancer interface.
    • Once EuroDNS accepted the attacker’s social-engineered registrar changes, balancer.fi stopped proving that the browser was still reaching Balancer-controlled infrastructure.
    • Because Balancer’s frontend is signer-authority infrastructure in practice, nameserver control became wallet-prompt control: whoever decided what balancer.fi resolved to also decided what spender or permit target users were asked to trust.
    • The preserved invariant is the canonical Balancer domain must never ask a wallet to grant authority outside the intended Balancer route. The registrar compromise broke that invariant before any interaction reached Balancer’s contracts.
    • This case is also a clean boundary marker against third-party runtime allowance and integrity pinning: Balancer did not first fail because one still-legitimate Balancer page loaded the wrong third-party script; it failed earlier, because the naming layer stopped proving the browser had even reached Balancer-controlled delivery.
  • Exploit path:
    1. At roughly 00:42 CET on 2023-09-20, the attacker changed the nameservers for balancer.fi after socially engineering EuroDNS.
    2. The attacker served a phishing frontend forked from the genuine Balancer app under the real balancer.fi domain.
    3. The malicious app presented signer prompts that could vary by wallet and token set, including ordinary ERC-20 approvals, permit signatures, and Permit2 flows.
    4. One reported allowance target was 0x00006deacd9ad19db3d81f8410ea2b45ea570000, which the fake UI presented as part of a plausible Balancer interaction flow.
    5. Victims signed because the domain, branding, and product context still looked canonical.
    6. Community members reported suspicious behavior quickly; Balancer posted a Discord warning at about 01:43 CET and publicly warned users not to trust the frontend while the issue was being investigated.
    7. EuroDNS did not respond until about 08:30 CET, and Balancer said control over the domain was not restored until about 10:30 CET.
    8. Cloudflare and MetaMask added balancer.fi to phishing / malicious-site blocklists during the active incident window, which Balancer later credited as important damage containment.
    9. Even after control returned, already granted approvals and signed permit-style permissions remained dangerous until users revoked them or migrated funds.
    10. Balancer later documented and reimbursed seven verified claimant wallets through DAO proposals BIP-443, BIP-455, and BIP-535, preserving a reasonably concrete public record of the exploit’s realized damage.
  • What the attacker needed to be true:
    • EuroDNS support and recovery channels had to accept a socially engineered registrar-side change to the nameserver configuration for the real domain.
    • Users had to keep trusting balancer.fi as the canonical Balancer interface during the compromise window.
    • The fake frontend had to stay close enough to legitimate Balancer UX that approval / permit / Permit2 prompts looked routine rather than obviously foreign.
    • Victims needed to hold transferable assets on routes the attacker’s prompt logic could monetize across supported EVM chains.
    • Registrar response, DNS propagation, and anti-phishing blocklist rollout had to be slow enough that at least a handful of victims signed before the warnings dominated.
  • Technical anatomy worth remembering:
    • This was not a contract exploit. Onchain, users signed ordinary-looking approvals or permit-style authorities and the attacker later exercised them.
    • Balancer’s postmortem is especially useful because it preserves a mixed authority-harvest shape: the malicious frontend did not rely on one single spender primitive, but selected among approvals, permits, and Permit2 depending on the victim’s wallet state.
    • The incident is a useful cousin to Curve Finance DNS hijack, but Balancer’s public record is sharper about the registrar-side social-engineering ingress and about later restitution accounting for concrete victim wallets.
    • It is also a useful contrast to BadgerDAO. Badger preserved same real site, different edge-served bytes; Balancer preserved same real site label, different registrar-controlled answer, where the browser no longer reached Balancer-controlled delivery at all.
    • The later DAO reimbursement proposals also preserve an unusual operational lesson: once users lose funds through signer-surface compromise, restitution, proof-of-wallet ownership, and attacker/fraud-claim filtering become part of the incident surface too.
  • Representative transactions and addresses:
    • Malicious approval target highlighted by Balancer: 0x00006deacd9ad19db3d81f8410ea2b45ea570000
    • Verified heavily impacted claimant wallet in BIP-443 (auramaxi.eth): 0xD14f076044414C255D2E82cceB1CB00fb1bBA64c
    • Additional verified claimant wallets later reimbursed in BIP-455 and BIP-535: 0x1511e7Fe2e06BBc75Eb4CeeE7c7dC5f9af6bb781, 0x5d119666CD68dDD9b3b3b5Ee7552EEdeD6843918, 0x3056b7039deb4347ca9ab2abd7b5785fcdcc0ebf, 0xa7A13659692239c143daE313a0116D5b5C18d26C, 0xde5cbe25c58c49ee7635216de6998f8dacd63b96, 0xc4f95f674b393a49410ace864833abe836848526
    • Later Balancer-validated claimant-loss totals: 7 wallets, about $330,521.91 at attack-time prices
  • Response / mitigation:
    • Balancer warned users via Discord and social channels not to interact with the frontend while the attack was live.
    • Cloudflare and MetaMask blocked or flagged the compromised domain during the incident, which Balancer later cited as important containment.
    • After control of balancer.fi returned and propagation stabilized, Balancer announced recovery of the domain path.
    • Balancer’s postmortem told affected users to revoke suspicious approvals immediately and to treat accounts that had signed malicious messages as compromised enough to justify moving funds to a fresh account.
    • The Balancer team said it was evaluating more secure registrar options for the .fi domain and even reconsidering a move back to .finance if that produced a stronger registrar-security posture.
    • The Balancer DAO later reimbursed verified victims through BIP-443, BIP-455, and BIP-535, paying 75% of accepted loss amounts while preserving onchain ownership proofs and claimant attestations.

Pattern tags

  • frontend-compromise-approval-phishing
  • Same canonical domain, different registrar-controlled answer: balancer.fi still looked like the right destination, but the registrar-induced nameserver answer no longer routed browsers to Balancer-controlled infrastructure
  • Mixed wallet-authority harvest rather than one single prompt type: Balancer’s own postmortem said the phishing frontend used ordinary approvals, permit signatures, and Permit2 transactions depending on each victim’s wallet state
  • Domain recovery and approval recovery were separate jobs: regaining balancer.fi did not retract already granted spender rights or already signed permit-style authorities
  • Restitution itself became a secondary control surface: verifying which losses really came from the Balancer frontend, rather than from the same drainer family elsewhere, required wallet-ownership proofs and human review

Why the exploit worked

  • Balancer’s strongest user trust signal — the canonical balancer.fi domain — remained recognizable while the registrar / nameserver path underneath it stopped proving that the browser was still reaching Balancer-controlled infrastructure.
  • The phishing frontend looked close enough to the real Balancer app that users were still willing to sign authorities in a familiar DeFi interaction flow.
  • The attacker did not need one single approval primitive. By mixing direct approvals, permit signatures, and Permit2-style authorities, the malicious frontend could adapt to different wallet states and token surfaces.
  • Balancer’s contracts being safe did not matter for already signed permissions. Once a victim granted or signed transferable authority, the attacker no longer needed a bug in Balancer itself.
  • Registrar response latency mattered. Community detection was relatively fast, but EuroDNS response and safe re-propagation still left enough time for real losses to accumulate.
  • The postmortem also shows why incident closure is wider than site restored: users had to revoke approvals, migrate compromised accounts, and later prove claim legitimacy in restitution flows because the same drainer family was still active elsewhere.

Three signer-authority promotions this incident collapsed

  1. A canonical signer-facing domain still existed

    • Users were still going to balancer.fi, which remained the socially recognized Balancer destination even after the attacker changed the nameservers at EuroDNS.
    • The weak first claim therefore still held in users’ heads: this is the real Balancer domain label I normally trust when I decide whether to sign.

  2. That registrar-controlled answer was still treated as canonical Balancer prompt truth

    • Once the nameserver answer stopped routing browsers to Balancer-controlled infrastructure, the fetched phishing frontend was no longer Balancer-authored wallet-prompt truth even though the hostname still looked right.
    • The dangerous promotion was from the browser is at balancer.fi to the spender, permit, and Permit2 objects this page is showing must still be Balancer's intended authority objects for this exact route.

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

    • Victims did not just view a fake site; they signed approvals, permits, and Permit2 transactions that remained economically live after the registrar state was fixed.
    • 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 balancer.fi did not retract what the attacker had already harvested.

Detection and audit pivots

  • Inventory every authority that could change where balancer.fi resolves: registrar staff workflows, account-recovery paths, nameserver delegation, TLD-specific vendor policies, and emergency failover procedures.
  • Monitor for signer prompts from the canonical domain that introduce fresh spender addresses, permit targets, or Permit2 flows outside the reviewed Balancer route set.
  • Treat mixed prompt drift as an expected attacker tactic. If the malicious frontend can choose between approvals, permits, and Permit2 based on wallet state, looking only for one suspicious approval pattern is too narrow.
  • Ask whether the protocol can independently publish and machine-check the currently expected spender / permit targets for the live frontend, instead of asking users to trust the domain name alone.
  • Rehearse the domain compromised, but contracts safe message path together with exact revoke and migration guidance. In wallet-drainer incidents, the second message often limits more damage than the first.
  • Preserve claimant-quality evidence early. If restitution or user triage later matters, responders should already know what onchain signatures, domain-window timing, and drain-address correlations will distinguish real victims from unrelated drainer losses.

Failure-prevention checklist

  • Treat registrar, TLD-provider support flows, nameserver delegation, recovery email, and registrar-human escalation paths as signer-critical custody infrastructure.
  • Minimize the authority the canonical domain can request by default: exact approvals, bounded permits, short expiries, and route-specific authority should be preferred over broad standing permissions.
  • Pin or machine-verify spender destinations, permit domains, Permit2 targets, and router families so a recovered domain cannot silently continue to ask for fresh attacker authority after apparent restoration.
  • Build emergency routing and public-proof workflows before the next incident: who can prove the domain is safe again, how users verify that proof, and which alternate read-only or safer routes remain available during containment.
  • Continuously reconcile live signer-target inventory against onchain approval / permit telemetry so canonical domain, wrong authority object becomes visible within minutes.
  • Coordinate fast with wallet vendors, phishing blocklists, and browser security partners; Balancer’s postmortem preserved how much MetaMask and Cloudflare intervention mattered during the active window.
  • Prepare revoke / migrate guidance for all relevant authority types, not just ERC-20 approvals. Permit and Permit2 compromise should trigger the same seriousness as an onchain approve().
  • If restitution is part of the playbook, predefine evidence standards and claimant-review procedures before the incident rather than improvising them once public pressure is high.

Audit prompts

  • Which exact humans, vendors, and recovery channels can change where balancer.fi resolves today, and which of those paths still depend on social-engineering-prone support workflows?
  • If the canonical Balancer domain were malicious for one hour, what largest authority could it realistically harvest now: unlimited ERC-20 approvals, Permit2 blanket permissions, one-shot permits with reusable scope, or broader wallet-session authority?
  • What independent control proves that the live Balancer frontend is asking for one of Balancer’s intended spender / permit targets rather than a fresh address or unauthorized Permit2 flow?
  • Which alerts would fire first if the attack repeated right now: nameserver-change alerts, spender-inventory drift, permit-domain drift, suspicious approval clustering, or only later drain transactions?
  • How quickly can Balancer both stop new signatures and help already exposed users revoke or outrun previously signed permissions?
  • If affected users later seek reimbursement, what exact evidence distinguishes loss from the Balancer frontend compromise window from loss to the same drainer family through some unrelated site?
  • Does Balancer still rely on any signer-critical trust assumption tied to one registrar or one TLD support process that could be replaced with a higher-friction, more auditable control path?
  • After recovery, what exact combination of registrar state, DNS answers, frontend-bundle provenance, and spender / permit allowlists justifies telling users balancer.fi is safe again?

Lessons that should already be standard

  • The canonical domain is custody infrastructure once users trust it to prepare wallet permissions.
  • Registrar social engineering is not a web-ops footnote. If registrar staff can be tricked into changing nameservers, they can indirectly become wallet-policy administrators.
  • Contracts are safe is not enough when the real user loss path is wallet signed the wrong authority from the right-looking domain.
  • Mixed approval surfaces matter. A frontend drainer may not rely on only approve(); it can pivot among approvals, permits, and Permit2 depending on what the wallet exposes.
  • Restoring the domain is only half the response. The other half is unwinding or outrunning the permissions users already granted while the domain was malicious.
  • Anti-phishing vendors and wallet blocklists are part of real containment for signer-surface incidents; Balancer’s case preserved how much those outside controls can cut the active window.
  • Restitution quality depends on evidence quality. If the same drainer family is active elsewhere, post-incident claims need more than a generic statement that funds were lost around the same time.
  • The real reviewer question is not only does balancer.fi resolve? but what proves the currently resolving site is still the exact wallet-authority surface Balancer intended users to trust?

Why this incident matters

  • It preserves a high-signal real domain, wrong authority object incident where the decisive ingress sat in registrar social engineering rather than in a Solidity bug or a downstream package compromise.
  • It adds an especially useful bridge case between Curve Finance and BadgerDAO: Curve preserved generic DNS / nameserver hijack, Badger preserved compromised edge-served bytes, and Balancer preserved a registrar-social-engineering path with a mixed approval / permit / Permit2 wallet-harvest profile.
  • It is also a sharp exemplar for canonical-domain runtime-byte integrity: the canonical domain label stopped proving that the fetched frontend still belonged to Balancer at all.
  • It also clarifies where third-party runtime allowance and integrity pinning starts too late. Before asking which third-party code the real Balancer page should have been allowed to execute, users first needed the domain to keep resolving to Balancer-controlled delivery.
  • It preserves an unusually concrete aftermath trail through BIP-443, BIP-455, and BIP-535, which makes the incident useful not only for exploit mechanics but also for understanding how frontend-drainer restitution and claimant verification become part of the governance and ops surface.
  • It also helps the corpus keep front-end compromise families distinct from software supply-chain compromise and release-provenance failure: the decisive compromise did not first live in a shared package ecosystem or loader-selected runtime, but in Balancer’s own domain-control path.

Internal linkages

Control surface

Graph View

Backlinks