Worked example · 2023-12

Galxe frontend DNS hijack pair — Ethereum / multi-chain — 2023-10-06 + 2023-12

Loss: approximately $396K aggregate across the October and December 2023 incidents combined. Galxe is a Web3 credentials / on-chain identity platform; the loss-bearing population was the cohort of users who connected wallets to the platform during the active hijack windows and were prompted to sign authorisation flows by an injected drainer contract served from the legitimate Galxe domain.
Recovery: none of material consequence on the on-chain layer. Proceeds for both incidents were laundered through Tornado Cash within the days following each event. Galxe restored DNS control, rotated registrar credentials, and published user-facing revoke-approval guidance.
OAK Techniques observed: OAK-T1.003 broadly construed — compromised front-end / DNS hijack sub-class of "renounced-but-not-really" / front-end-control compromise. The Galxe smart contracts were not compromised; the compromise was at the DNS / registrar layer, with an injected drainer contract solicitation served from the legitimate domain. OAK-T15.004 (Operator-Side Credential Compromise) — registrar / DNS sub-shape; the load-bearing compromise was the operator's domain-registrar credential surface, exactly parallel to the canonical Curve 2022-08 case. OAK-T4.005 (setApprovalForAll NFT Drainer) downstream — the injected drainer page invoked setApprovalForAll and approve-pattern signature flows against connected wallets; the loss vector mirrored the standard wallet-drainer-kit pattern but with the entry vector being a hijacked legitimate domain rather than a phishing site. OAK-T7.001 (Mixer-Routed Hop — proceeds from both incidents were laundered through Tornado Cash).
Attribution: pseudonymous. No public named-individual attribution. Pre-event funding routed through Tornado Cash; post-event laundering routed through Tornado Cash. There is no public OAK-G01 / state-actor attribution; the cohort of registrar-side DNS-hijack incidents through 2022–2023 is generally attributed to commercial / opportunistic clusters rather than state-aligned operators.
Key teaching point: registrar-side DNS hijack as a recurring entry vector against Web3 protocols whose primary user-facing surface is a hosted dApp, with pre-existing wallet approval graphs and setApprovalForAll patterns as the loss-amplifying downstream. Galxe is a clean 2023 companion to the canonical Curve Finance DNS-hijack case at /examples/2022-08-curve-dns-hijack.md. The two cases together — separated by ~16 months and across two structurally different Web3 surfaces (DeFi AMM vs. credentials platform) — establish that registrar-side controls (registry-lock, DNS change-control, registrar-credential 2FA / hardware-token enforcement) are a discrete pre-deployment / operational-hygiene check class that the OAK Mitigations layer needs to address explicitly. The cohort signal across the 2022–2024 corpus (Curve 2022, Balancer 2023 frontend, Galxe Oct + Dec 2023, others) is that the registrar-credential-compromise sub-vector remains operationally under-mitigated across the Web3 ecosystem.

Summary

Galxe is a Web3 credentials / on-chain identity / loyalty-and-quest platform launched 2021-onward. Its primary user-facing surface is a hosted dApp at galxe.com; users connect wallets to participate in protocol-sponsored quests, claim credential NFTs, and interact with the Galxe campaign infrastructure. Like most hosted Web3 dApps, the platform's user-facing dApp is served via DNS resolution from the operator's registrar, with registrar-side credentials gating control of nameserver records.

In the October 6, 2023 incident, an attacker compromised Galxe's registrar account and pointed galxe.com DNS records at a malicious server. The attacker-controlled page presented a cloned Galxe UI to visitors that injected a wallet-drainer payload into the wallet-connect / approval-signing flow. Users who connected wallets during the hijack window — typically expecting to claim a credential or participate in a quest — were prompted to sign setApprovalForAll and approve-pattern transactions against the drainer's contracts. Approximately $150K was extracted across the cohort of users who signed during the active window.

In the December 2023 follow-up, a second registrar-side compromise — described in industry write-ups as having the same operator-pattern fingerprints as the October incident — repeated the attack with another ~$246K extracted. The follow-up suggested that Galxe's October post-incident response had not fully closed the registrar-side surface; whether this was due to incomplete credential-rotation, insufficient hardware-token enforcement on the registrar account, or a separate compromise vector was debated in industry post-mortems but never publicly resolved.

For OAK's purposes the case is a clean T1.003 (front-end / DNS-layer compromise broadly construed) extraction with T4.005 downstream amplification through pre-existing approval graphs and routine NFT-credential-claim flows. The OAK contribution of the worked example is the pair framing — within-protocol repeat-failure across the same registrar-side surface — and the cohort framing alongside Curve 2022 as evidence that registrar-side operational hygiene is a discrete check class that the Mitigations layer should treat explicitly.

Timeline (UTC)

When	Event	OAK ref
Pre-event	Galxe deploys hosted dApp at `galxe.com`; users routinely connect wallets and grant approvals / `setApprovalForAll` permissions to Galxe campaign contracts and quest-integrated protocols; approval graph builds across millions of wallets	(T4.005 surface — pre-existing approval graph)
Pre-event	Galxe registrar credentials gate DNS-record control; specific registrar / 2FA / hardware-token posture latent and not publicly disclosed at this point	T1.003 surface (latent)
2023-10-06 (attack window)	Attacker gains control of Galxe registrar account; modifies DNS records to point `galxe.com` at attacker-controlled server; cloned Galxe UI served with injected drainer payload; ~$150K extracted across the connecting-user cohort	T1.003 + T4.005 extraction (incident 1)
2023-10-06 (within hours)	On-chain monitoring (Scam Sniffer, BlockSec PhalconHQ, others) flags anomalous approval / `setApprovalForAll` patterns originating from Galxe-domain users	(defender response / community detection)
2023-10-06 (within hours)	Galxe operations team detects the hijack; restores DNS records; rotates registrar credentials; publishes user-facing revoke-approval guidance	(operator response)
2023-12 (attack window)	Second registrar-side compromise; same DNS-hijack pattern; ~$246K extracted	T1.003 + T4.005 extraction (incident 2)
2023-12 (within hours)	Galxe restores DNS records again; broader credential-rotation and registrar-posture hardening communicated publicly	(operator response, repeat)
Days following each incident	Attacker laundering routes proceeds through Tornado Cash	T7.001 (off this example's framing)
Continuing	No public recovery; no civil-forfeiture action; pseudonymous attribution unchanged	(recovery state)

What defenders observed

The compromise was registrar-side, not protocol-side. Galxe's smart contracts, off-chain backend services, and content-distribution pipelines were not compromised. The compromise was confined to the registrar account that controls DNS-record modifications for galxe.com. This is the textbook OAK-T1.003 / front-end-compromise sub-pattern: the path between the user's browser and the protocol's intended UI was attacker-controlled, while the protocol's contracts continued to operate normally. Detection of registrar-side compromise from on-chain telemetry alone is structurally limited; the detection signal is a sudden burst of approval-pattern transactions from the protocol's user base going to non-protocol contracts, mirroring the Curve 2022 detection pattern.
The within-protocol repeat-failure across two months is the strongest single signal. The October 2023 incident's post-mortem response should have closed the registrar-side surface; the December 2023 incident demonstrated it had not. Whether the gap was incomplete credential-rotation, weak 2FA on the registrar (shared SMS code, recoverable via SIM-swap), absence of hardware-token enforcement, or a different sub-vector entirely was debated in industry post-mortems. Operationally, the lesson is that the post-incident response after a registrar-side compromise must include a complete registrar-side audit (every credential, every recovery vector, every 2FA factor, every authorised user / API key on the registrar account), not merely password-reset on the compromised account.
The downstream amplification was the pre-existing approval graph and routine NFT-credential-claim flows. Galxe users routinely grant setApprovalForAll permissions to credential-issuance contracts and to Galxe-integrated partner protocols. Once the cloned UI was served from the legitimate domain, the wallet-side prompts to sign setApprovalForAll looked indistinguishable from routine quest interactions. The loss-multiplying surface is the same surface the broader 2022–2024 wallet-drainer corpus has been documenting: any compromise of an approved or trusted UI converts user-side approval graphs into a multi-wallet drainer.
Detection latency was operator-acceptable; recovery latency was effectively infinite. Galxe restored DNS in roughly hours per incident. By that time the funds were already moving toward Tornado Cash. The DNS-restoration primitive protects future visitors but does not unwind completed extraction; once funds reach a public mixer in the same transaction window, on-chain recovery is structurally foreclosed — the same shape as Curve 2022, Onyx 2024, Li.Fi 2024, and most 2022–2024 EVM-mainnet exploit cases.
Registrar-side operational hygiene is the discrete defender practice the case advertises. Registry-lock (registrar-side feature that requires manual operator action to modify DNS records), hardware-token 2FA on the registrar account (FIDO2 / WebAuthn / YubiKey class), DNS change-control with multi-party approval, and DNSSEC are all operationally available and well-documented. The October-and-December 2023 Galxe pair is the canonical 2023 evidence that adoption of these primitives across the Web3 ecosystem was not uniform, even on platforms with sustained material user volume.

What this example tells contributors writing future Technique pages

T1.003 should explicitly enumerate the registrar-side / DNS-hijack sub-class as a recurring 2022–2024 entry vector. The Curve 2022 case at /examples/2022-08-curve-dns-hijack.md is the foundational reference. Galxe Oct + Dec 2023 is the within-protocol repeat-pair extension. Future T1.003 worked examples should preserve the sub-class distinction (front-end-code-injection vs registrar-DNS-hijack vs CDN-compromise vs supply-chain-NPM-package-compromise) rather than collapsing them into a single "compromised front-end" classification. The Mitigations layer for each sub-class is structurally different.
T4.005 amplification activates whenever any approved or trusted UI is compromised, not just under phishing. The standard T4.005 framing is wallet-drainer-kit phishing — fake mints, fake airdrops, fake protocol UIs. Galxe is the canonical OAK example that the same setApprovalForAll amplification mechanism activates when a legitimate UI — to which users routinely grant approvals in good faith — is compromised at the DNS layer. The user's loss exposure is the same: full approved-token / NFT collection balance. The structural parallel with Li.Fi 2024 at /examples/2024-07-li-finance.md (legitimate-contract-compromise sub-pattern of T4.004) is intentional: across both T4.004 and T4.005, the "legitimate-target-compromise" sub-pattern is a distinct entry vector that contributors should not collapse into the phishing-only framing.
Within-protocol repeat-failure on the same surface is a load-bearing OAK signal. The Galxe October-and-December 2023 pair joins Cream Finance's three 2021 incidents (/examples/2021-10-cream-finance.md), Inverse Finance's April + June 2022 pair (/examples/2022-04-inverse-finance.md), Onyx's November 2023 + September 2024 pair (/examples/2024-09-onyx.md), and UwU Lend's June 10 + 13 2024 pair (/examples/2024-06-uwu-lend.md) as worked examples where the post-incident response did not close the operational surface within months. Contributors writing future worked examples should treat within-protocol repeat-failure as a first-class observation, not as incidental detail of one incident.
Pseudonymous attribution is the realistic attribution status for the registrar-side-DNS-hijack class. No FBI / Treasury attribution applies; no industry forensics provider has converted on-chain analysis into a named-individual claim across the 2022–2023 cohort. Contributors should record this class as pseudonymous rather than promoting industry speculation about commercial-cluster operators to inferred-strong without a specific named source.

Public references

[galxepostmortem2023] — Galxe protocol-side post-incident statements covering both the October and December 2023 hijack incidents, the registrar-side root cause, and user-facing revoke-approval guidance.
[scamsnifferGalxe2023] — Scam Sniffer real-time alerts and on-chain analytics for the Galxe drainer activity windows.
[rektgalxe2023] — Rekt News public-facing summary framing the case as a registrar-side DNS hijack.
[blocksecGalxe2023] — BlockSec PhalconHQ on-chain analytics for the Galxe drainer transaction patterns.
[slowmistGalxe2023] — SlowMist incident analysis covering Tornado Cash laundering pattern.
[peckshieldgalxe2023] — PeckShield headline figures for the combined ~$396K aggregate loss across the two incidents.
[rektcurve2022] for the structural-parallel Curve Finance 2022 DNS-hijack case.

Discussion

The Galxe Oct + Dec 2023 pair is the canonical 2023 worked example for the registrar-side / DNS-hijack sub-class of T1.003, paired with Curve Finance 2022 (/examples/2022-08-curve-dns-hijack.md) as the foundational case in the cohort. The two cases together — separated by ~16 months, across structurally different Web3 surfaces (DeFi AMM, credentials platform), with different specific registrars and operational postures — establish the cohort's existence as a recurring entry vector rather than a one-off Curve-specific incident.

The within-protocol repeat-failure dimension at Galxe is the strongest single-protocol signal in the case. The October 2023 incident should have triggered comprehensive registrar-side audit and credential-rotation; the December 2023 incident demonstrated that the operational response was incomplete. Worked examples that capture this dimension explicitly are more useful to defender practice than examples that report only one of the two incidents in isolation; the pair framing is the load-bearing structural feature of the Galxe case in the OAK corpus.

The downstream amplification dimension generalises beyond Galxe. Any Web3 platform whose user base routinely grants setApprovalForAll permissions — credentials platforms, NFT marketplaces, gaming platforms, loyalty programs, and increasingly DeFi aggregators integrating NFT-collateral primitives — accumulates an approval graph that any compromise of the platform's hosted UI will activate as a multi-wallet drainer. The operational mitigations (Revoke.cash for user-side approval-graph hygiene, time-bounded approvals where supported, per-platform approval-budget guidance) are the same as for the broader T4.x corpus; the Galxe case adds the legitimate-platform-DNS-compromise sub-vector to the entry-vector taxonomy.

For OAK's broader credibility, including Galxe in v0.1 closes a gap in the T1.003 sub-class coverage: the corpus had Curve 2022 as the foundational registrar-side-DNS-hijack worked example, but no 2023 follow-on demonstrating the cohort persistence. The Oct + Dec 2023 Galxe pair fills that role and extends the within-protocol repeat-failure pattern set the corpus has been accumulating across the 2021–2024 worked-examples layer.