Case Study — Galxe Frontend DNS Hijack (October 6, 2023)

“The smart contract was never touched. The Cloudflare account was never touched. The npm tree was never touched. The attacker called a registrar’s support line, sent a forged document, and rerouted a top-50 Web3 brand’s traffic to a wallet drainer for four hours. There is no Solidity audit in the world that would have caught this.”

“Customer support is a privileged action on your protocol. If the person on the other end of the phone can change your NS records by pasting a Google Drive link, your DNS is whatever the cheapest human in the loop says it is.” — Auditor’s gloss.

Tags: web3-security case-study frontend dns social-engineering wallet-drainer infrastructure registrar incident-response Course position: Tuan-13-Frontend-dApp-Infrastructure §3.1 (DNS hijack) + §3.7 (incident response). Read those first; this case is the canonical worked example of the registrar-social-engineering vector and the four-hour drainer window. Related cases: Case-BadgerDAO-Frontend-2021 (CDN/Cloudflare worker — same outcome, different surface) · Case-Curve-Frontend-2022 (DNS provider account compromise — same surface, different access path) · Case-Ledger-Connect-Kit-2023 (npm supply chain — same drainer kit family, December 2023) · Case-Radiant-Capital-2024 (signer-display vs. signed-bytes mismatch, “what the user sees ≠ what the contract executes”) Vault context: This is the canonical “registrar account is in scope of the audit” case. The point is not that Galxe was negligent — the point is that virtually every Web3 protocol in 2023 had the same exposure and most still do. Pair with Tuan-13-Frontend-dApp-Infrastructure §3.1 to make the lesson actionable in a checklist.

1. At a glance

Field	Value
Date of incident	October 6, 2023
Start of hijack (DNS change observed)	~06:00 UTC October 6, 2023 [verify exact timestamp from CertStream / passive-DNS logs]
Galxe public acknowledgement	~06:30 UTC October 6, 2023 (Twitter/X) [verify]
Domain reclaimed	~10:00 UTC October 6, 2023 — approximately 4 hours of phishing exposure [verify]
Protocol	Galxe — Web3 credential / loyalty network (formerly Project Galaxy), publisher of on-chain credentials, quests, NFT loyalty programs; one of the highest-trafficked Web3 brands in 2023 (millions of MAU)
Chains affected	None — no smart contracts compromised; users lost funds on whatever chains they signed approvals from (Ethereum, BNB Chain, Polygon, Arbitrum, etc.)
Loss (direct)	~ $160 k -$ 269k USD across approximately 1,120 victims [verify against Galxe official statement]
Loss (indirect)	Reputational; multi-week trust damage; downstream incident-response cost; ongoing audit / DNS-hardening work across affected partner protocols
Attack class	DNS hijack via registrar account social engineering → drop in wallet drainer kit (Inferno Drainer or similar) → harvest of `Permit`, `Permit2`, and `setApprovalForAll` signatures
Vulnerable surface	Domain registrar account (Dynadot) + customer-support trust process — not the protocol, not the Cloudflare account, not the npm tree, not the Solidity
Registrar	Dynadot (US-based ICANN-accredited registrar) [verify]
Vector	Threat actor impersonated a Galxe employee to Dynadot customer support, provided falsified identity documentation, convinced support staff to bypass standard transfer-lock / verification flow, and changed the NS (nameserver) records for `galxe.com`
Recovery	Galxe regained registrar control after coordinating with Dynadot; community alert chain was rapid (CertStream watchers, Twitter, security researchers from SlowMist + PeckShield); Galxe announced a victim-compensation programme covering all confirmed losses from the four-hour window
Significance	Canonical 2023 example of “registrar is in scope”. After this incident, registry-lock (per RFC 5731’s `serverTransferProhibited` / `serverUpdateProhibited` / `serverDeleteProhibited` statuses) became a near-universal recommendation in Web3 infrastructure audits, alongside hardware-MFA on registrar accounts and out-of-band DNS-change monitoring

The whole incident in one line: the attacker did not exploit Galxe — they exploited Dynadot’s customer service. Galxe’s defence-in-depth at the application layer was irrelevant once the NS records pointed at the attacker’s authoritative nameserver.

2. Background — Galxe and what made it a high-value target

2.1 What Galxe is

Galxe (rebranded from Project Galaxy in mid-2023) is the largest Web3 credential and loyalty network. By October 2023 it had:

>16 million registered addresses claiming credentials [verify against Galxe’s 2023 reports]
>2,000 partner projects running quests / campaigns on Galxe
Daily traffic of hundreds of thousands of distinct wallets connecting to galxe.com to claim NFTs, OATs (On-chain Achievement Tokens), and credential mints

That last property is what made the hijack so effective: users come to galxe.com with the explicit expectation of connecting a wallet and signing something. The friction that protects a banking website (“why is my bank asking me to sign a typed-data blob?”) is gone. Signing is the product.

In a phishing context, this is the perfect demographic:

High-volume, multi-chain wallets.
Habituated to clicking through setApprovalForAll and Permit prompts.
Used to being awarded NFTs they don’t recognise — so a “sign this to claim your reward” prompt with unfamiliar fields is the normal user experience, not a red flag.

2.2 Why the registrar was the soft underbelly

Galxe’s smart contract surface was — by 2023 standards — reasonably well audited. Multiple firms had reviewed the credential-mint contracts, the OAT contracts, and the quest infrastructure. The frontend was hosted on professional infrastructure with Cloudflare in front. None of that matters when a DNS NS record change reroutes the entire domain.

The hierarchy of trust for any normal-looking dApp URL is:

flowchart LR
    U[User types galxe.com] --> R[Recursive resolver<br>queries registry]
    R --> Reg[Registry .com<br>VeriSign root]
    Reg -->|"NS records<br>(controlled by registrar account)"| Rgs[Registrar<br>Dynadot]
    Rgs --> NS[Authoritative nameservers<br>Cloudflare DNS / similar]
    NS -->|A / AAAA / CNAME| CDN[CDN edge<br>Cloudflare]
    CDN -->|HTML / JS bundle| BR[User's browser]
    BR -->|window.ethereum| W[Wallet extension]
    W -->|signed tx / signature| C[Smart contracts]

    style Rgs fill:#ffcccc
    style Reg fill:#ffe7cc
    style NS fill:#fff2cc
    style CDN fill:#fff2cc

The red box (the registrar) sits upstream of everything else. Compromising it bypasses every defence below it. The yellow boxes (registry, authoritative DNS, CDN) are also abuseable, but the registrar account is uniquely vulnerable because it sits at the intersection of:

Self-service web UI — credentials phishable, sessions hijackable.
Human customer-support process — social-engineerable, document-forgable.
Permanent destructive privilege — one NS change moves a brand’s entire user base.

In 2023, the typical Web3 protocol’s registrar account was protected by a password + maybe TOTP. Galxe’s wasn’t unusually weak. The industry baseline was the vulnerability.

2.3 The threat-actor side: wallet-drainer-as-a-service economy

By 2023, wallet drainer kits (the malicious JavaScript payload that ran on the phishing clone of galxe.com) had matured into a Software-as-a-Service market. The economically relevant operators in late 2023 were:

Drainer kit	Operator profile	Revenue model
Inferno Drainer	Telegram-based, ~250 affiliates; claimed >$80M stolen by late 2023 [verify]	20% cut of all drained funds; provides kit + phishing site templates
Monkey Drainer	Active 2022–2023, retired in early 2023 publicly; ~$13M attributed [verify]	Similar affiliate model; replaced by Inferno and successors
Angel Drainer	Linked to the Ledger Connect Kit incident (Dec 2023); supply-chain-aware variant	Similar; sometimes branded as a “premium” tier
Pink / Pinkbox	Newer 2023 entrant; specialised in EIP-712 signature abuse	Affiliate-based

Public attribution by ScamSniffer, SlowMist, and PeckShield of the Galxe incident at the time pointed to Inferno Drainer as the most likely kit involved, based on:

The on-chain consolidation pattern of stolen funds.
The structure of the signing prompts seen on the clone site.
The destination address clustering with known Inferno-affiliate wallets.

[verify final attribution — the post-incident reports from SlowMist and PeckShield are the authoritative sources here].

The economic implication for the threat actor: the social engineering effort against Dynadot was a high-yield investment. A few hours of phone work, a forged document, and a brand impersonation netted **> $160 kin f o u r h o u rs * *, o f w hi c h t h e a ff i l ia t e k e pt 80$ 10k per incident.

3. The vulnerability — what actually happened at the registrar

Critical framing: the “vulnerability” here is not a CVE, not a bug. It is a process failure at a customer-support function combined with the absence of registry-lock on a high-value domain. Auditors who treat “the protocol does not have control of its own registry status” as a finding will save protocols from this attack class. Auditors who don’t, won’t.

3.1 The five things that had to be true for the attack to work

For the Galxe-style attack to succeed, all five of these conditions had to hold simultaneously. Breaking any one would have blocked it:

#	Condition	Status at Galxe (Oct 2023)	What would have broken it
1	Registrar customer support is empowered to make NS changes via human-decisioned process	True (industry standard at most registrars)	Move to registrar that requires out-of-band confirmation (e.g., MarkMonitor, CSC)
2	No registry-lock on the domain	True [verify — Galxe’s post-mortem implies this]	Apply `serverTransferProhibited` + `serverUpdateProhibited` + `serverDeleteProhibited` EPP statuses (RFC 5731) — these require registry-level action to remove, not registrar-level
3	No out-of-band notification to the legitimate owner when NS records change	True	DNS-change alerting (see §6.3); Cloudflare, Tenderly, or custom cron+alert
4	No hardware-MFA enforced on registrar account session (orthogonal to the support-channel attack but relevant if attacker tried the web UI path first)	Likely true [verify]	FIDO2-only registrar (Cloudflare Registrar enforces this); 2FA-required on Dynadot but does not protect against support-channel bypass
5	Users in 2023 did not have a habit of verifying the domain via an out-of-band canonical source (ENS contenthash, social channels, bookmarked IPFS gateway)	True (industry-wide)	ENS canonical record published, in-wallet domain reputation indicators (RabbyDB-style)

The Galxe registrar account itself did not need to be compromised. The attacker did not log in. They convinced support staff that they were the rightful owner who had lost access.

The Dynadot side of the attack is reconstructed (not officially confirmed in granular detail) from Galxe’s incident statement, SlowMist and PeckShield post-mortems, and the standard playbook of registrar social-engineering known from non-Web3 cases (the 2018 Naoki Hiroshima @N Twitter handle incident, the 2020 Twitter VIP-account hijack, the 2022 KlaySwap BGP/DNS hijack [verify Klayswap details]).

The attacker’s steps, in approximately this order, were almost certainly:

Step 1 — Reconnaissance (hours to days before the attack)

The attacker established:

Which registrar galxe.com was registered at — trivial: whois galxe.com shows the registrar in the public WHOIS record. In October 2023 this was Dynadot LLC.
The legitimate owner’s organisational details — Galxe Foundation / Galxe Inc. listings, the names of key engineering / operations staff (LinkedIn, GitHub, Discord moderator lists), recent media interviews with their CTO/CEO providing voice samples (often unwittingly).
The registrar’s support workflow — Dynadot’s published help docs (or a phone call posing as a prospective customer) reveal what documents the registrar will accept as “proof of ownership” in a lost-access flow.

$ whois galxe.com
Domain Name: GALXE.COM
Registrar: Dynadot Inc                        ← attacker's first datapoint
Registrar IANA ID: 472
...
Registry Domain ID: ... (pre-attack)
Name Server: NS1.DYNADOT.COM                  ← legitimate, before hijack
Name Server: NS2.DYNADOT.COM
Domain Status: clientTransferProhibited       ← typical baseline; not registry-lock
[verify pre-incident NS records and status]

Step 2 — Document forgery

The attacker prepared one or more of:

A forged government ID (typically PDF scan of a passport or driver’s license, with photoshopped details matching a legitimate Galxe officer or a plausible-sounding “owner” name).
A forged company incorporation document or business letter on Galxe-letterhead.
An email address spoof — either via lookalike domain (galxe.co instead of galxe.com), via a compromised tangential email account, or via simply claiming “we lost access to our @galxe.com email, please use this Gmail”.

Forensic verification of identity documents is notoriously difficult for customer-support agents. There is no consumer-tier registrar in 2023 that runs registrar-side passport-MRZ validation or company-registry cross-reference at the support-ticket level. Most agents are checking “does this look like a real driver’s license? Did the support template approve it?“. Under volume, the answer drifts toward “approve”.

Step 3 — Contact the registrar and request NS change

The attacker — possibly by phone, possibly by support ticket, possibly by both — contacted Dynadot support claiming to be the rightful owner of galxe.com, having lost access to the registered email and 2FA device, and requested an emergency NS-record update to “their new hosting provider”.

Why this is the high-yield phase for the attacker: the support agent’s job is to be helpful. The metric they are evaluated on includes “tickets resolved per shift” and “customer satisfaction score”. The fastest way to resolve a “I lost access, please update my NS records” ticket is to accept the documentation and update the NS records.

[verify the exact Dynadot internal process and what was bypassed — Galxe’s public statement says Dynadot acknowledged a process failure but redacted specifics].

Step 4 — NS records change

At approximately 06:00 UTC October 6, 2023, the NS records for galxe.com were changed from Dynadot’s nameservers (or whichever authoritative DNS provider Galxe was using) to attacker-controlled nameservers. The propagation TTL is dictated by the parent zone (.com) — typically two days at the registry level, but most resolvers cache aggressively and the practical effective TTL for a new lookup against a recursive resolver that hasn’t cached the old records is single-digit minutes.

The attacker had pre-staged:

Their authoritative nameservers with galxe.com zone files pointing to attacker-controlled web servers.
A pixel-perfect clone of galxe.com hosted on a beefy server / CDN ready to absorb the spike of legitimate Galxe traffic.
The drainer kit embedded in the clone’s JavaScript.
A wallet infrastructure to receive drained funds — typically a tree of disposable EOAs that consolidate into a mixer (Tornado Cash by 2023 was sanction-encumbered; alternatives by late 2023 included eXch, FixedFloat, and various cross-chain bridge laundering via Sinbad/[verify]).

Step 5 — Users hit the clone, attacker harvests signatures

Once the NS records propagated to a recursive resolver, every user who typed galxe.com (or clicked a Galxe link) got the clone. The clone’s flow:

User connects wallet (looks identical — wagmi/viem under the hood will work fine against a legitimate wallet provider since it’s still the user’s real wallet talking to the real wallet’s UI).
User clicks “Claim your credential” (or whatever quest the user came for; the clone may have been generic).
The clone presents an eth_signTypedData_v4 prompt for what looks like a routine Galxe credential.
The signed payload is actually a Permit / Permit2 / setApprovalForAll authorising the attacker contract to spend the user’s tokens or move their NFTs.
The drainer’s backend submits the signed approval and immediately calls the spend path, transferring assets out of the user’s wallet to the attacker’s consolidator address.

The drained assets included ETH, USDC, USDT, popular NFTs, and any approved-by-default tokens. Users who had previous Permit2 approvals to common router contracts were not directly affected by the clone (those approvals were to legitimate routers), but the clone could request new approvals that the user, in the trusting context of “I’m on galxe.com, this prompt is legit”, clicked through.

The signed-bytes vs. shown-bytes problem from Tuan-12-Wallet-AA-Key-Management is the actual vulnerability that converts a DNS hijack into a $160k loss. If wallets reliably surfaced “you are signing a permit2 with amount = MAX_UINT256 and spender = 0xUnknownEOA”, the drainer would have a much harder time. Most wallets in October 2023 did not.

4. Attack flow — detailed timeline reconstruction

[Timestamps marked verified from official Galxe statement or contemporaneous community reports; otherwise [verify]]

sequenceDiagram
    participant A as Attacker
    participant D as Dynadot Support
    participant NS as Authoritative DNS
    participant U as End Users
    participant W as Wallet
    participant C as Attacker Contracts
    participant G as Galxe Team
    participant SM as SlowMist / PeckShield / ScamSniffer

    Note over A,D: T-day to T-hours: Reconnaissance + document forgery
    A->>D: Support ticket / phone call<br/>"Lost access to galxe.com, change NS"
    D->>D: Review forged documents<br/>(insufficient process)
    D->>NS: Update NS records for galxe.com<br/>~06:00 UTC Oct 6
    Note over NS: Records propagate;<br/>recursive resolvers re-query
    U->>NS: DNS lookup for galxe.com
    NS-->>U: Attacker NS IP
    U->>U: Browser loads clone site
    U->>W: Connect wallet
    W-->>U: Account exposed
    U->>W: Sign permit2 / setApprovalForAll<br/>(prompted by clone)
    W-->>C: Signature exfiltrated to attacker backend
    C->>C: Submit approval + drain in same flashbot bundle
    Note over U,C: Loop for ~4 hours;<br/>~1,120 victims;<br/>~$160-269k drained
    SM->>SM: Detect anomalous galxe.com cert via CertStream
    SM->>G: Alert via Twitter / Telegram<br/>~06:30 UTC Oct 6
    G->>G: Confirm hijack;<br/>public Twitter warning
    G->>D: Emergency: revert NS records;<br/>secure account
    D->>NS: Restore legitimate NS records<br/>~10:00 UTC Oct 6
    Note over U,G: Domain restored;<br/>SlowMist / PeckShield publish analyses
    G->>G: Compensation programme announced

4.1 The four-hour window — phase by phase

Phase 1 — Quiet propagation (~06:00–06:30 UTC)

The NS change is in effect but few users have hit it yet because most recursive resolvers still hold the old records. The first victims are users on networks with aggressive DNS refresh policies or those who flushed their local DNS cache for unrelated reasons.

This is also when CertStream-watching detectors typically fire first. CertStream is the live feed of certificate-transparency logs; when the attacker provisions a TLS certificate for galxe.com (Let’s Encrypt or similar) to make the phishing site HTTPS-green, a CT log entry appears within seconds. Researchers and bots watching CertStream for high-value Web3 brand names (Galxe, Uniswap, Curve, Aave, etc.) see the new certificate appear from an unexpected issuer/fingerprint and raise the alarm.

[verify whether the attacker pre-provisioned the cert hours before the NS change, or did it inline — both patterns exist].

Phase 2 — Mass exposure and active drain (~06:30–09:00 UTC)

DNS propagation is well past the early-adopter stage. The bulk of galxe.com visitors are hitting the clone. The drainer is harvesting signatures and executing drains at ~1–10 per minute peak [verify rate from on-chain forensics]. The attacker’s consolidator address starts showing the characteristic fan-in pattern visible on Etherscan/BSCScan.

Galxe’s social channels have warnings up by this phase (“DO NOT visit galxe.com; we are dealing with a DNS incident”). But the warning has limited reach: Twitter/X posts compete with the attention economy, and many users who typed galxe.com did so without first checking Twitter.

Phase 3 — Coordinated takedown (~09:00–10:00 UTC)

Galxe’s incident response is now coordinated with Dynadot (forcing the NS records back), with the wallet-kit providers (warning Web3Modal/WalletConnect to flag the domain), with SlowMist + PeckShield (publishing analyses with attacker addresses for community defenders to track), and with users (compensation programme announcement preparation).

The NS records revert to legitimate. But DNS doesn’t propagate the revert instantly either — for some users, the clone is still resolvable for another 1–2 hours depending on their resolver’s cache.

Phase 4 — Post-incident (10:00 UTC onward through Oct 7)

Galxe publishes their incident statement. The compensation programme is announced. The community on-chain trackers (@realScamSniffer, @PeckShieldAlert, @SlowMist_Team) publish attacker-address tags so that exchanges and bridges can attempt to freeze deposits from those addresses. Some funds end up frozen on centralised venues; most laundered out before the freeze takes effect.

5. Reproduction — why this case is NOT on-chain reproducible

Critical point for your case-study log: unlike Nomad, Wormhole, Euler, BadgerDAO (where you can replay the exploit on a forked node), the Galxe incident has no Solidity reproduction. The attack lives in the DNS-and-process layer.

What you can reproduce in a lab — and what is highly recommended for the Tuan-13-Frontend-dApp-Infrastructure Lab 4 / 5 exercises — is the defensive instrumentation:

5.1 Reproducing the detection side

You can simulate the detector that would have notified Galxe within minutes:

# DNS change detector (cron every 60s)
#!/usr/bin/env bash
DOMAIN="galxe.com"
KNOWN_NS_HASH="$(cat /var/lib/dns-monitor/${DOMAIN}.ns.sha256)"
CURRENT_NS=$(dig +short NS ${DOMAIN} | sort | sha256sum | cut -d' ' -f1)
 
if [ "$CURRENT_NS" != "$KNOWN_NS_HASH" ]; then
    curl -X POST https://hooks.slack.com/services/XXX \
         -d "{\"text\":\"ALERT: NS records changed for ${DOMAIN}.\nWas: $(cat /var/lib/dns-monitor/${DOMAIN}.ns.txt)\nNow: $(dig +short NS ${DOMAIN})\"}"
    # Also: SMS, PagerDuty, on-chain log via signed message, etc.
fi

This is a 30-line script. There is no reasonable excuse for a high-value Web3 protocol not to have something like this in 2026. The 2023-era industry simply did not.

5.2 Reproducing the CertStream watcher

Subscribe to CertStream and filter for certificates matching your brand keywords:

import certstream
 
WATCH_KEYWORDS = ["galxe", "galxie", "ga1xe", "galxe-claim", "galxe-rewards"]
TRUSTED_ISSUERS = {"R10", "R11", "E1", "E5", "E6"}  # Let's Encrypt prod issuers [verify current]
 
def callback(message, context):
    if message["message_type"] != "certificate_update":
        return
    leaf = message["data"]["leaf_cert"]
    domains = leaf["all_domains"]
    issuer = leaf["issuer"]["O"]
 
    for kw in WATCH_KEYWORDS:
        for d in domains:
            if kw in d.lower():
                send_alert(domain=d, issuer=issuer,
                           subject=leaf["subject"]["CN"])
                break
 
certstream.listen_for_events(callback,
    url="wss://certstream.calidog.io/")

A typo-squat clone provisioning galxe-claim.com would trip this in seconds; even a hijack of the legitimate galxe.com with a new certificate (different fingerprint than the existing legitimate one) would trip a variant of this detector that tracks per-domain certificate fingerprints rather than just keyword matches.

5.3 Reproducing the drainer-prompt side (defensive lab)

Stand up a local web app that mimics the malicious prompt and observe what your wallet shows. This is the most instructive exercise:

Deploy a minimal HTML page locally that connects to window.ethereum.
Construct an EIP-712 payload that is a Permit2 authorising MAX_UINT256 spend to an attacker EOA.
Trigger eth_signTypedData_v4 with that payload.
Screenshot what each major wallet shows the user — MetaMask, Rabby, Frame, Trust Wallet, Coinbase Wallet, Phantom EVM mode, etc.

The point: different wallets render the same malicious prompt very differently. Rabby (post-2023) is significantly better at decoding permit-style payloads and flagging unfamiliar spenders. MetaMask in late 2023 was demonstrably worse [verify state in your target month]. Knowing which wallets blind-sign vs. surface the threat is a real audit-relevant property to track.

6. Aftermath — what Galxe did, what the industry did

6.1 Galxe’s immediate response (Oct 6–7, 2023)

Galxe’s incident response, by community contemporaneous accounts, was relatively well-executed for a sudden frontend hijack:

Action	Time from detection	Quality
Public Twitter warning	~30 min	Fast
Coordination with Dynadot	~1 hour	Required external dependency on Dynadot’s responsiveness
Domain restored	~4 hours total	Acceptable given the external dependency
Public statement with details	Same day	Transparent; named Dynadot, named the social-engineering vector
Victim compensation programme	Announced ~24h after	Galxe pledged to compensate confirmed victims from the four-hour window
Detailed post-mortem	Multi-week	Published via help-centre article; some specifics redacted at Dynadot’s request [verify]

6.2 The compensation

Galxe announced that all confirmed victims would be compensated from a Galxe-controlled fund. The reasoning was twofold:

Brand trust — for a credential / loyalty network whose entire value proposition is trust in the credential mint flow, losing user funds without compensation would have been existential.
Affordability — the total drained sum (~ $160 k -$ 269k) was small relative to Galxe’s treasury. For a larger incident (BadgerDAO at $120 M, B y bi t a t$ 1.4B), full compensation is rarely tractable; Galxe was, in a perverse sense, lucky to have an affordable disaster.

The structure of the compensation programme was: victims submit transaction hashes and proof-of-signing on the clone domain to a Galxe-operated form; verified victims receive USD-stablecoin reimbursement from a Galxe wallet. [verify whether this completed in full and how many claims were paid].

6.3 What the industry adopted post-Galxe

The Galxe incident — along with the BadgerDAO archetype, Curve frontend, Ledger Connect Kit (which followed two months later), and the early 2024 wave of similar registrar attacks — produced a near-universal DNS / registrar hardening checklist that is now table stakes for any serious Web3 protocol’s infrastructure audit:

Defence	Status pre-Galxe (industry baseline)	Status post-Galxe (industry baseline 2024–2026)
Registry-lock (EPP `serverTransferProhibited`/`serverUpdateProhibited`/`serverDeleteProhibited` per RFC 5731)	Rarely deployed for Web3 protocols	Standard for top-100 protocols; always a finding if missing in audit
Hardware-MFA on registrar account	Inconsistent; many used TOTP	Expected; FIDO2-only registrars (Cloudflare Registrar) become preferred
Out-of-band DNS-change monitoring	Almost nobody	Required by most professional audit firms
ENS `contenthash` canonical record published	Niche	Common — `protocol.eth` resolves to IPFS hash of the UI, served via Cloudflare Web3 gateway, browser-extension-aware (MetaMask)
IPFS pinning of canonical UI (multi-provider)	Rare	Increasingly common as a fallback domain-independent surface
`dnssec` enabled on the zone	Inconsistent	Recommended baseline; not a panacea (doesn’t protect against registrar-side NS change but blocks cache-poisoning class)
CertStream / certificate-transparency monitoring for the brand	Niche, security-team only	Many protocols subscribe to ScamSniffer / Forta / Tenderly alerts that include CT monitoring

The most important of these is registry-lock. It is the single change that would have certainly defeated this attack, because registry-lock requires registry-level action (VeriSign for .com) to remove — meaning the registrar’s customer-support agent cannot change NS records even if fully social-engineered. Only the registry, with the registrar acting as intermediary and typically a 24-48 hour cooling-off period, can lift the lock.

For your audit checklist: when reviewing a protocol’s infrastructure posture, run whois protocol.com and look for serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited. Their absence is a finding. The presence of only clientTransferProhibited (the default Dynadot/GoDaddy state in 2023) is insufficient — client* statuses can be removed by the registrar account itself or by support.

6.4 Wider second-order effects

Wallet UX: the Galxe incident accelerated the industry-wide push for better signing-prompt rendering. Rabby’s Permit2 explanation UI, MetaMask’s improved typed-data display (rolled out incrementally through 2024), Phantom’s transaction simulation pop-ups — all are partly downstream of the year-2023 streak of drainer-driven losses, of which Galxe was a prominent mid-size case.
Drainer-kit visibility: ScamSniffer, SlowMist’s MistTrack, PeckShield, Web3Antivirus, and Pocket Universe all expanded their domain-reputation databases significantly in late 2023, partly using the Galxe and Ledger Connect Kit incidents as canonical training examples for “what a drainer-served URL looks like”.
ENS adoption for canonical UI: Curve already moved to curve.fi → curve.finance + curve.eth after the August 2022 incident; Galxe did not become an ENS-first project, but the broader industry pattern of “publish your canonical UI to IPFS, point ENS at it, market the .eth as the primary URL” gained meaningful traction.
Audit scope expansion: the most concrete change for working auditors. Before 2023, “the registrar account” was rarely in scope for a “Web3 security audit”. By 2024, infrastructure-aware audit firms (Trail of Bits, OpenZeppelin, ChainSecurity, ConsenSys Diligence in their full-stack engagements) explicitly include registrar/DNS/CDN as scope items.

7. Lessons — the auditor’s takeaway checklist

This is the part of the case study you should be able to recite from memory by Week 13.

7.1 The five core lessons

Lesson 1 — The registrar account is in scope of the audit

The single biggest reframe. If your scope document for a “Web3 frontend security audit” does not list:

The registrar (provider, account-protection posture, registry-lock status, audit-log access)
The DNS provider (if separate from registrar)
The CDN (Cloudflare/Vercel/Netlify/Fastly account posture, worker/edge function audit)
The hosting service (S3/GCS/Vercel/Netlify deploy permissions)

… then you are not auditing the actual attack surface. The contract is rarely the weak point in a modern Web3 stack.

Lesson 2 — Registry-lock is the single highest-ROI control

RFC 5731 (tools.ietf.org/html/rfc5731) defines the Extensible Provisioning Protocol (EPP) for domain registration. It includes a set of status codes that domains can carry:

Status	Effect	Who can set/remove
`clientTransferProhibited`	Registrar will refuse transfer requests	Registrar account holder (or compromised support)
`clientUpdateProhibited`	Registrar will refuse update requests	Registrar account holder (or compromised support)
`clientDeleteProhibited`	Registrar will refuse delete requests	Registrar account holder (or compromised support)
`serverTransferProhibited`	Registry refuses transfer (registrar cannot override)	Registry (or registrar-via-registry workflow with out-of-band confirmation)
`serverUpdateProhibited`	Registry refuses updates (registrar cannot override)	Registry (or registrar-via-registry workflow with out-of-band confirmation)
`serverDeleteProhibited`	Registry refuses delete (registrar cannot override)	Registry (or registrar-via-registry workflow with out-of-band confirmation)

The “server” set is registry-lock*. The “client*” set is not registry-lock — it can be removed by anyone with registrar-account access (or anyone who can convince registrar support).

Registry-lock is supported by:

.com, .net, .org, .io (and most modern TLDs)
Premium registrars (MarkMonitor, CSC Corporate Domains, SafeNames) — often default-on
Some retail registrars only by special request and sometimes with a per-year fee

Audit checklist item: whois <protocol-domain> and confirm serverTransferProhibited + serverUpdateProhibited + serverDeleteProhibited. If absent → finding.

Lesson 3 — Hardware-MFA on the registrar account, with a dedicated key per role

The principle: the registrar account is at least as sensitive as the deployer EOA. Treat it that way.

No SMS 2FA — SIM swap is a one-phone-call attack on many carriers.
No software TOTP only — phishable in real time via reverse-proxy phishing kits (Evilginx2).
FIDO2 hardware key (YubiKey, SoloKey, Nitrokey) required — webauthn-bound to the domain; a phishing site cannot relay it.
Dedicated key per privileged role: the registrar key is not the same as the GitHub key, is not the same as the Cloudflare key, is not the same as the dev’s email key.
Cold-stored backup keys: in a safe, with documented recovery procedure that itself requires multi-person attestation.

Lesson 4 — Continuous DNS change monitoring with low-noise alerts

Two flavours of monitoring are needed:

Authoritative side: log into your DNS provider’s dashboard (Cloudflare, Route53, AWS, etc.) and confirm what records you have. Many providers offer audit-log webhooks.
Resolver side (external vantage): cron jobs from multiple external IPs (a Hetzner box in EU, a Linode box in US, a residential proxy in APAC) that resolve your domain via dig / nslookup and compare against a known-good snapshot. Alert on any divergence.

The external vantage is necessary because a malicious registrar account modification might not appear in the DNS provider’s audit log (the attacker bypassed it). The external resolution is what actually tells you what users are seeing.

Tools that automate this in 2026:

Cloudflare DNS Firewall (only useful if records flow through Cloudflare DNS)
DNSCheck (open source, periodic external resolution + Slack alerts)
RIPE Atlas measurements (free for non-commercial; thousands of external probes)
Forta community detectors for nameserver changes on protocol domains [verify exact detector ID]
Custom: 20-line bash + dig + Slack webhook (see §5.1)

Lesson 5 — Out-of-band canonical UI distribution

Even with all the above, the registrar surface is eventually compromisable. Build escape valves:

Publish the canonical UI to IPFS, pinned via at least two providers (Pinata + Cloudflare Web3 + your own node).
Publish the IPFS contenthash to ENS (protocol.eth contenthash = ipfs://Qm…).
Market the .eth domain alongside the .com — users with MetaMask, Brave, Opera, or browsers with built-in ENS support can navigate to protocol.eth and bypass DNS entirely.
Out-of-band domain attestation: maintain a known endpoint (status.protocol.com is not sufficient since it’s the same DNS), better — publish current canonical domain + content hash to a known on-chain registry (a ProtocolDomainRegistry contract with multi-sig-gated update authority) so wallet extensions can verify.

The user-side adoption of this is still patchy in 2026. The architecture is sound but the UX work to make protocol.eth discoverable is uneven.

7.2 The auditor’s checklist — operationalised

Print this and use it on engagements. Each item is a finding if missing.

8. What you would have caught — as an infra auditor in September 2023

Hypothetical scenario: you are engaged by Galxe in September 2023 for an “infrastructure & frontend” audit. Your scope is explicitly NOT the smart contracts. You have one week. What do you write in the report that would have prevented or significantly mitigated the October 6 incident?

8.1 The findings you would have raised

FINDING 1 — Critical — Registrar account does not have registry-lock applied to high-value domain

Severity: Critical
Evidence: whois galxe.com shows clientTransferProhibited only; no server* status codes present.
Impact: A successful social-engineering attack against Dynadot customer support, or a credential compromise of the registrar account, would allow an attacker to change NS records and divert all galxe.com traffic. Given Galxe’s monthly active wallet count and habitual signing flow, the financial exposure of such a redirect is in the high six to low seven figures per hour of attacker access.
Remediation: Apply registry-lock to galxe.com and all related production domains. Negotiate with Dynadot for the lock (may require fee). Consider migrating to a corporate registrar (MarkMonitor, CSC) that defaults to registry-lock for high-value brands.
Acknowledgement timeline: Critical findings should be acknowledged within 24 hours of report delivery; remediation tracked against 7-day SLA.

FINDING 2 — High — No out-of-band DNS-change monitoring

Severity: High
Evidence: No DNS monitoring service is configured for galxe.com; no internal cron / alerting against external DNS resolution; reliance on Dynadot’s own dashboard (which would be compromised in a registrar-account hijack).
Impact: An NS-record change could go undetected for hours. The window between change and detection is the attacker’s revenue window.
Remediation: Deploy DNS-change monitoring from at least two external vantages (e.g., a Cloudflare Worker that resolves galxe.com via 1.1.1.1 and 8.8.8.8, compares to baseline, alerts on divergence). Alerts route to PagerDuty + security-team Slack. Test the alert quarterly.

FINDING 3 — High — Registrar customer-support process is not understood by the team

Severity: High
Evidence: The team has not characterised what documentation Dynadot accepts as proof of ownership in a lost-access flow. There is no testing of the support process; no “red team” attempt against the registrar.
Impact: The team cannot assess the actual risk because they don’t know the actual process. Standard customer-service processes at consumer-tier registrars are well known to be vulnerable to social engineering (see Twitter VIP-account hijack 2020, multiple registrar-based incidents).
Remediation: Engage with the registrar’s enterprise-support tier; document the exact process they use for NS changes; require out-of-band confirmation (phone callback to a registered number, signed message from the registered email key, multi-person approval). If the registrar will not support this, migrate.

FINDING 4 — Medium — No canonical IPFS-backed UI distribution

Severity: Medium
Evidence: galxe.com is the only canonical address; no galxe.eth ENS record points to a contenthash; no IPFS publication of the UI.
Impact: Users have no out-of-band way to verify they are at the legitimate UI; reliance on a single DNS resolution path concentrates risk in the registrar.
Remediation: Publish UI to IPFS; pin via Pinata + Cloudflare Web3; set galxe.eth contenthash; communicate to users that galxe.eth is a verifiable alternative.

FINDING 5 — Medium — Wallet-prompt rendering of Permit2 / setApprovalForAll is not verified across major wallets

Severity: Medium
Evidence: The Galxe frontend issues eth_signTypedData_v4 requests for credentials; the team has not characterised what major wallets show users when these prompts arrive, nor what a malicious permit prompt would look like in the same wallets. Users cannot reliably distinguish.
Impact: Even if the DNS / hosting layer is hardened, downstream phishing (separate from a DNS hijack — e.g., typosquats, malicious Discord links) reaching the user with a permit prompt will succeed if wallets render the prompt opaquely.
Remediation: Build a “wallet rendering matrix” — screenshots of every Galxe prompt in MetaMask, Rabby, Frame, Phantom, Coinbase Wallet, Trust Wallet. Identify which wallets render opaque blobs; raise with wallet vendors; consider in-dApp warnings (“we are about to ask you to sign a permit; review carefully”) for high-risk flows.

FINDING 6 — Medium — Incident-response runbook absent for “DNS hijack” scenario

Severity: Medium
Evidence: The team’s incident-response documentation covers smart-contract incidents but does not cover domain hijack. No pre-rehearsed escalation contacts at Dynadot; no pre-drafted public statement; no pre-approved compensation policy.
Impact: In an actual incident, time-to-recovery is dominated by uncertainty and ad-hoc coordination. Each hour of attacker access is users’ funds.
Remediation: Write the runbook. Rehearse it. Include: pre-established Dynadot escalation contact, pre-approved compensation framework, pre-drafted Twitter/X warning template, pre-identified industry contacts (SlowMist, PeckShield, ScamSniffer) for community amplification.

8.2 The findings you would NOT have raised — and why this is the lesson

A traditional Solidity-only audit would have found none of these. The contracts were fine. The deployer keys were fine. The proxy admin was fine. There was nothing wrong at the contract layer.

This is the case study’s central thesis: the audit scope that doesn’t include the registrar, the DNS provider, the CDN, the customer-support process, and the wallet-rendering matrix is auditing the wrong layer for any 2023+ Web3 protocol where the realistic attack vector is at the human + infrastructure boundary.

If you are an auditor: this case justifies — to clients, in scope negotiations — why your engagement should include these layers, and why charging more for the broader scope is in the client’s interest. Galxe’s $160 k -$ 269k direct loss, plus indirect reputation cost, would have been a multiple of any reasonable infrastructure-audit fee.

9. Comparison table — Galxe vs. the other 2021–2023 frontend incidents

Property	BadgerDAO (Nov 2021)	Curve (Aug 2022)	Galxe (Oct 2023)	Ledger Connect Kit (Dec 2023)
Attack surface	Cloudflare account / Worker	DNS provider (`iwantmyname`)	Domain registrar (Dynadot, via support)	npm publishing (former-employee API key)
Vector	CDN compromise → script injection	DNS provider account compromise → NS change	Registrar customer-support social engineering → NS change	npm package compromise → drainer payload in transitive dep
Duration	~5 weeks (intermittent)	Hours	~4 hours	~5 hours
Direct loss	~$120M	~$575k	~$160-269k	~$600k (direct); much higher downstream
User reach	High-value Badger users	Curve power users	Mass-market quest users (high count, low avg)	Anywhere `@ledgerhq/connect-kit` was transitively loaded
Drainer kit	Custom approval-collector	Custom	Inferno [verify]	Angel Drainer
Defence that would have stopped it	API-key inventory + integrity monitoring	DNS provider hardware-MFA + change monitoring	Registry-lock + registrar hardware-MFA + change monitoring	npm 2FA on tokens (not just login) + offboarding includes npm
Compensated victims?	Partially (long process)	Partially	Yes, full programme	Yes, partially
Lesson the industry took	CDN audit logs + integrity monitoring	DNS provider in scope	Registrar in scope; registry-lock	npm + offboarding hygiene

The pattern is unmistakable: each incident shifted upstream in the trust chain. By 2024, “the registrar is in scope” was settled — but the lesson generalises: any actor with the privilege to redirect traffic is part of the protocol’s attack surface, whether or not the protocol team thinks of them as such.

10. Connections back to the course

Tuan-13-Frontend-dApp-Infrastructure §3.1 (DNS hijack) — uses Galxe as the worked example; this case study is the long-form companion.
Tuan-13-Frontend-dApp-Infrastructure §3.7 (Incident response) — the four-hour-window framing comes from this case.
Tuan-12-Wallet-AA-Key-Management §5 (signed-bytes vs. shown-bytes) — the reason a DNS hijack converts into a $160k drain is that wallets blind-sign permits; this case is the field-evidence link between the wallet-UX problem and an actual loss.
Tuan-05-Vulnerability-Classes-Part-1 (anti-pattern of trusting human-decisioned processes for high-privilege operations) — same root anti-pattern as Parity multisig (initialize() trustingly accessible), just at a different layer.
Case-BadgerDAO-Frontend-2021 — same outcome (drainer prompt on the legitimate-looking dApp), different surface (CDN vs. registrar). Read together to triangulate the “upstream attack surface” concept.
Case-Curve-Frontend-2022 — same surface family (DNS), different access path (provider account vs. registrar support). Read together to understand that the DNS surface has multiple compromise paths.
Case-Ledger-Connect-Kit-2023 — same drainer-kit family (December 2023, two months later), different supply-chain access. Read together to understand the drainer-as-a-service economy that monetises these compromises.
Case-Radiant-Capital-2024 — the signer-display-vs-signed-bytes anti-pattern at its purest, but with workstation compromise rather than DNS as the access path. Reinforces that the contract layer was always fine; the loss is in the bytes-to-the-user pipeline.

11. References

11.1 Primary sources

Galxe Help Centre — “October 6th DNS Security Incident Statement & Guide”: https://help.galxe.com/en/articles/8452958-october-6th-dns-security-incident-statement-guide — Galxe’s official incident statement, including the description of the Dynadot social-engineering vector and the compensation programme.
Galxe Twitter/X official announcements: real-time updates during and after the incident; pinned thread from @Galxe on October 6, 2023 [verify URL stability — Twitter/X content is volatile]
Dynadot official response: [verify — Dynadot acknowledged the support-channel process failure; specifics may have been redacted]

11.2 Security-firm post-mortems

SlowMist (Oct 2023 incident report): https://slowmist.medium.com/ — search for “Galxe DNS” in their October 2023 publications; SlowMist’s MistTrack tagged the attacker addresses and traced laundering paths.
PeckShield (Oct 2023 alerts): @PeckShieldAlert on Twitter/X published real-time observations of the drain; their incident retrospective followed within days.
ScamSniffer: tracked the drainer kit attribution; their dashboard listed Galxe-linked drain transactions.
CertiK Skynet: live monitoring picked up the anomaly via behavioural signals.

[verify exact URLs for each of the above; security-firm Medium URLs and Twitter threads from 2023 are sometimes archived or restructured]

11.3 RFCs and protocol standards

RFC 5731 — Extensible Provisioning Protocol (EPP) Domain Name Mapping: https://datatracker.ietf.org/doc/html/rfc5731 — defines the serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited statuses commonly referred to as “registry lock”; mandatory background reading for anyone auditing a domain’s posture.
RFC 5910 — DNSSEC Mapping for EPP: https://datatracker.ietf.org/doc/html/rfc5910 — related, for DNSSEC + registry interactions.
ICANN guidance on domain registrar security: https://www.icann.org/resources/pages/security-and-stability — general references; ICANN’s own materials on registrar transfer security.

11.4 Wallet-drainer kit research

ScamSniffer 2023 annual report: drainer-kit landscape and attribution.
SlowMist “Web3 Phishing Report” (annual): drainer market analysis with revenue estimates.
Chainalysis Crypto Crime Report (annual): phishing-as-a-service section.
Web3 Antivirus / Pocket Universe blogs: incident-by-incident drainer attribution.

[verify URLs — these resources move; check the latest versions for any post-2023 updates]

Cloudflare Registrar: https://www.cloudflare.com/products/registrar/ — FIDO2-only registrar; relevant alternative to consumer-tier registrars.
MarkMonitor / CSC Corporate Domains: enterprise-tier registrars with default registry-lock and out-of-band confirmation for changes. Used by most Fortune 500 brands.
CertStream: https://certstream.calidog.io/ — live CT log feed; foundation of CT-based phishing-domain detection.
Forta Network: https://forta.org/ — community-operated detection network; includes detectors for protocol-domain-related anomalies [verify which detectors specifically].
DNSCheck: open-source DNS-change monitoring; reference implementation for §5.1.
EFF SSL Observatory / Censys: certificate-transparency search; useful for incident triage.

11.6 Comparable historical incidents (non-Web3) that inform the pattern

Naoki Hiroshima @N Twitter handle hijack (2014): classic registrar/customer-support social engineering, pre-Web3.
Twitter VIP-account hijack (July 2020): customer-support social engineering at scale.
KlaySwap BGP hijack (Feb 2022): network-layer (not registrar) hijack of Korean dApp; same outcome shape [verify].
MyEtherWallet BGP hijack (April 2018): route hijack rerouted DNS for MEW; ~$150k drained; canonical “DNS surface multiple ways” reference.

These are not Galxe-specific but they reinforce that registrar/DNS-layer hijacks have been an industry concern for over a decade. The Web3 layer added a particularly direct monetisation path (sign one approval, lose all your assets); the underlying network/registrar vulnerabilities are old.

12. Appendix — sample audit-engagement language for clients

Practical takeaway for auditors. The following language is reusable in audit-scope discussions and engagement letters to ensure the registrar/DNS/CDN layers are explicitly within scope.

“The engagement scope includes the protocol’s smart contracts AND the supporting Web infrastructure: (a) the domain registrar account, its access controls, customer-support process, and registry-lock status; (b) the DNS provider, its account controls and audit-log monitoring; (c) the CDN / hosting provider, its account controls, edge-function audit, and integrity monitoring of the deployed bundle; (d) the build pipeline, its CI secrets management, and dependency-supply-chain posture; (e) the wallet-integration layer, including representative wallet rendering of EIP-712 / Permit / Permit2 signing prompts. The October 2023 Galxe DNS hijack, the December 2023 Ledger Connect Kit npm supply-chain compromise, the November 2021 BadgerDAO Cloudflare incident, and the August 2022 Curve DNS incident are illustrative of attack patterns within scope and inform the engagement methodology.”

If a client pushes back on scope expansion, the Galxe case is the most efficient single-paragraph argument: a top-50 Web3 brand with audited contracts lost user funds in four hours via a customer-support phone call. The cost of including the broader scope in audit is a fraction of the cost of the loss.

lthieu's notes

Explorer

Case-Galxe-Frontend-Hijack-2023