Worked example · 2013-04

Atlas DNS Bitcoin-domain hijack phishing campaign — Bitcoin — April 2013

Loss: ~$200K+ in estimated aggregate losses across victims who entered credentials or wallet information into the phishing replicas served from hijacked Bitcoin-service domains. The figure is a lower-bound consensus estimate from contemporaneous industry reporting; the actual total is inherently uncertain because the phishing scheme harvested credentials rather than executing on-chain extraction that could be traced, and many victims may not have publicly reported individual losses. No recovery is recorded on the public record.
OAK Techniques observed: OAK-T15.004 (Operator-Side Credential Compromise — registrar / DNS sub-shape: the DNS hosting accounts at Atlas DNS were the compromised credential surface; the attacker gained access to the DNS control panel and modified A/AAAA records to redirect traffic from legitimate Bitcoin-service domains to attacker-controlled phishing replicas). OAK-T6.008 (Verified-But-Malicious Frontend Routing — the phishing replicas were served from the legitimate domain names of blockchain.info, BTC Guild, and other Bitcoin services; users who arrived at these domains via bookmarks, search, or direct navigation saw a cloned UI that appeared to be the legitimate service, with a valid SSL certificate path and the correct domain in the browser address bar). OAK-T4.008 (Fake-DEX / Fake-CEX Clone Frontend Phishing — the attacker served near-identical clones of the targeted Bitcoin services' frontends from the hijacked domains; the cloned UIs captured wallet credentials, private keys, and login credentials submitted by unsuspecting users).
Attribution: pseudonymous. The specific operator(s) who compromised Atlas DNS accounts were not publicly identified. The campaign's operational profile — multi-domain DNS hijack via a single registrar/hosting provider, with cloned UIs for multiple high-traffic Bitcoin services — suggested an organised actor with pre-positioned phishing infrastructure, but no authoritative attribution was published. The FBI investigated at the time per contemporaneous press reporting but did not publicly name a suspect or group.
Key teaching point: The Atlas DNS campaign of April 2013 is the earliest cleanly-documented DNS-hijacking-based cryptocurrency phishing campaign on the public record, and it established the structural template — registrar-credential compromise → DNS-record redirection → cloned-UI served from the legitimate domain → credential/phishing harvest — that would recur at Curve Finance (2022), Galxe (2023), and across the broader DeFi frontend-compromise class for the following decade. The campaign is the dated historical anchor for the T15.004 → T6.008 → T4.008 chain, demonstrating that the DNS hijack → cloned-frontend phishing kill chain predates the DeFi era and was fully operationalised against cryptocurrency targets by April 2013.

Summary

In April 2013, an attacker or group compromised DNS hosting accounts at Atlas DNS, a domain-registrar and DNS-hosting provider, and modified the DNS A/AAAA records for several high-traffic Bitcoin services — most prominently blockchain.info (the leading Bitcoin block explorer and web-wallet service at the time), BTC Guild (the largest Bitcoin mining pool by hashrate), and at least two other Bitcoin-service domains. The DNS changes redirected users visiting these services from the legitimate server IP addresses to attacker-controlled servers hosting phishing replicas of the targeted services.

The phishing replicas were near-perfect clones of the legitimate frontends. Users who arrived at blockchain.info — whether by typing the URL, clicking a bookmark, or following a search-engine result — saw a page indistinguishable from the real Blockchain.info login and wallet interface. When users entered their wallet credentials, private keys, or login information, the phishing replica captured this data and transmitted it to the attacker. Because the phishing pages were served from the legitimate domain names (not from a typosquatted domain or a third-party phishing host), browser security indicators showed no warning: the URL bar displayed the correct domain, and SSL certificates were either spoofed or obtained through the compromised DNS control.

The incident window was approximately 24–72 hours (estimates vary across contemporaneous sources). During this period, users of the affected services who logged in or interacted with wallet functions exposed their credentials to the attacker. The aggregate losses were estimated at over $200K — a substantial figure in the April 2013 Bitcoin economy, where BTC traded at approximately $50–130. The primary victims were individual users of Blockchain.info's web-wallet service and BTC Guild mining-pool operators whose pooled-mining payout credentials were harvested.

Atlas DNS acknowledged the account compromises and restored the correct DNS records after being notified by the affected services. Blockchain.info and BTC Guild both published warnings to their user bases, advising affected users to move funds to new wallets and rotate credentials. No criminal charges were publicly filed against a named individual or group.

The campaign is historically significant because it is the earliest case on the public record in which a cryptocurrency service's domain itself was the load-bearing trust surface — users trusted the domain they typed into their browser, and that trust was exploited not by a typo or a fake domain but by a compromise of the DNS infrastructure that resolved the legitimate domain. The structural pattern — "I typed the right URL and still got phished" — would become a defining class of cryptocurrency phishing over the subsequent decade.

Timeline (UTC)

When	Event	OAK ref
Pre-April 2013	Attacker identifies Atlas DNS as a DNS-hosting provider for multiple high-traffic Bitcoin services (blockchain.info, BTC Guild, others) and prepares phishing-replica infrastructure with near-perfect clones of the targeted frontends	(targeting and pre-positioning)
April 2013 (early)	Attacker compromises Atlas DNS hosting accounts — the specific vector (credential phishing of Atlas DNS customers, password reuse, support-channel social engineering, or Atlas DNS internal compromise) was not publicly confirmed	T15.004 (registrar/DNS credential compromise)
April 2013 (T+0)	Attacker modifies DNS A/AAAA records for blockchain.info, BTC Guild, and other targeted Bitcoin-service domains; DNS changes propagate across global resolvers	T15.004 → T6.008 (legitimate-domain routing compromise)
April 2013 (T+0 to T+~72h)	Users visiting blockchain.info, BTC Guild, and the other affected domains are served phishing replicas from attacker-controlled servers; wallet credentials, private keys, and login data harvested	T6.008 → T4.008 (clone-frontend credential harvest)
April 2013 (T+~24–48h)	Affected services detect the DNS hijack (user reports and internal monitoring); Atlas DNS notified; DNS records corrected	(detection and remediation)
April 2013 (T+~48h+)	Blockchain.info, BTC Guild, and other affected services publish user warnings; affected users advised to move funds and rotate credentials	(user notification)
Post-April 2013	FBI investigates per contemporaneous press reporting; no public charges or named attribution published	(investigation — no public resolution)

Realised extraction

The extraction mechanism was credential-based: the attacker harvested wallet credentials, private keys, and login information from users who interacted with the phishing replicas during the active window. The estimated $200K+ in aggregate losses reflects the value of Bitcoin extracted from compromised wallets in the days and weeks following the DNS hijack. Because the extraction was distributed across many individual victim wallets (rather than a single drain event from a pooled hot wallet), and because the Bitcoin blockchain in April 2013 lacked the clustering and attribution tooling available today, the precise extraction total cannot be verified from on-chain data alone. The $200K+ figure is drawn from contemporaneous industry reporting and victim self-reports aggregated in the weeks following the incident.

The campaign's extraction profile differs from later DNS-hijack phishing incidents (Curve 2022, Galxe 2023) in an instructive way: the Curve and Galxe incidents solicited on-chain approval signatures (Permit / approve) whose extraction was immediately visible on-chain, whereas the Atlas DNS campaign harvested credentials off-chain and the subsequent extraction occurred through individual wallet-access events distributed in time and across many UTXOs. This makes the Atlas DNS campaign a cleaner illustration of the off-chain credential harvest sub-shape of T4.008, while the Curve and Galxe cases are the canonical illustrations of the on-chain approval-signature solicitation sub-shape.

What defenders observed

Pre-event: the concentration of multiple high-traffic Bitcoin-service domains at a single DNS-hosting provider (Atlas DNS) was the standing single-point-of-failure that made the campaign possible. A defender analysing the Bitcoin-service domain landscape in early 2013 could have identified the Atlas DNS concentration risk. No public evidence suggests such an analysis was performed or acted upon before the incident.
At-event: user reports of "I typed blockchain.info and got a login page that looks right but something is off" were the primary detection signal. DNS monitoring — either through passive DNS telemetry or Certificate Transparency (which did not exist in its current form in 2013) — would have detected the A/AAAA record changes within minutes of propagation. The operational detection lag (24–48 hours by most accounts) reflected the absence of automated DNS-change monitoring in the Bitcoin-service operator community in April 2013.
Post-event: the attack vector — registrar/DNS-credential compromise — was recognised as a distinct class of cryptocurrency-targeted attack. But the operational lesson (monitor DNS records, harden registrar credentials, use registry-lock) was not systematically adopted across the cryptocurrency service operator community for nearly a decade — the Curve DNS hijack of August 2022 exploited the same structural weakness (compromised registrar credential) against a DeFi protocol with a market capitalisation in the billions, suggesting that the April 2013 lesson was not absorbed as an industry-standard practice.
Long-arc lesson: the eleven-year gap between the Atlas DNS campaign (April 2013) and the era when registrar-lock, DNSSEC, and DNS-change monitoring became table-stakes defensive practices for cryptocurrency frontend operators (roughly post-Curve 2022, with Galxe 2023 reinforcing the standard) is a standing data point on the absorptive capacity of the cryptocurrency industry for infrastructure-layer security lessons. The lesson was demonstrated in production against a live victim population in 2013; it took until 2022–2023 for the defensive response to reach the "expected" level for protocols of comparable value-at-risk.

What this example tells contributors writing future Technique pages

T15.004 has a 2013-era anchor, not just a 2022-era anchor. A contributor who encounters T15.004 only through the Curve DNS hijack (2022) or Galxe DNS (2023) may infer that DNS-hijack-based phishing is a DeFi-era technique. It is not. The Atlas DNS campaign of April 2013 demonstrates that the technique was fully operationalised against cryptocurrency targets — with the same structural kill chain (registrar-credential compromise → DNS-record redirection → cloned UI served from legitimate domain → credential harvest) — a full decade before the DeFi-era cases. Contributors writing or extending T15.004 should treat Atlas DNS (2013) and Curve DNS (2022) as the two historical anchors at opposite ends of the technique's maturity arc.
The credential-harvest sub-shape of T4.008 should be preserved as distinct from the on-chain-approval sub-shape. The Atlas DNS campaign harvested credentials off-chain (wallet credentials, private keys, login data) and the subsequent extraction was distributed across many individual victim wallets over time — structurally distinct from the on-chain approval-signature solicitation pattern seen at Curve (2022) and Galxe (2023). Contributors writing future T4.008 Technique pages should explicitly distinguish between off-chain credential harvest (exemplified by Atlas DNS) and on-chain approval-signature solicitation (exemplified by Curve) as two distinct extraction sub-shapes that share the same upstream DNS-compromise vector.
DNS-hosting-provider concentration risk is a recurring structural lesson. The Atlas DNS campaign was possible because multiple high-traffic Bitcoin-service domains were concentrated at a single DNS-hosting provider. The same lesson recurred at Curve (.fi TLD concentration at iwantmyname) and in the broader DNS-hijack incident class. Contributors writing T15.004 mitigations should include DNS-provider-diversity as a named control — not just per-domain DNS security but the structural risk of multiple operator-critical domains sharing a single DNS-hosting surface.

Public references

Contemporaneous industry reporting (BitcoinTalk forum threads, April 2013) — primary-source victim reports and community discussion of the hijack.
Blockchain.info public statement (April 2013) — user advisory confirming the DNS hijack and advising credential rotation.
BTC Guild public statement (April 2013) — mining-pool operator advisory confirming DNS redirection and warning users.
Atlas DNS public statement — acknowledgment of account compromises and DNS-record restoration.
FBI investigation reporting (contemporaneous press, April–May 2013) — confirmation of federal investigation, no public charges filed.
[curvednshijack2022] — cross-reference: the Curve Finance DNS hijack (August 2022) as the DeFi-era recurrence of the same structural pattern; see examples/2022-08-curve-dns-hijack.md.
[galxedns2023] — cross-reference: the Galxe DNS hijack (December 2023) as the second major DeFi-era recurrence.

Discussion

The Atlas DNS campaign occupies an unusual position in the OAK example set: it is the earliest example of a technique class (T15.004 → T6.008 → T4.008) that would recur at much larger scale in the DeFi era, but its dollar-loss figure (~$200K+) is small by the standards of the 2022–2025 incident record. This creates a contributor-side risk: that the Atlas DNS case will be underweighted because it doesn't anchor a headline loss figure, or dismissed as "pre-history" that doesn't bear on DeFi-era defender questions. Both framings would be mistakes.

The Atlas DNS campaign is the dated proof that the DNS-hijack → cloned-frontend kill chain was fully operationalised against cryptocurrency targets a full decade before the Curve DNS hijack. The operational details are structurally identical: compromise the registrar/DNS credential, redirect the domain's DNS records, serve a cloned UI from the legitimate domain, harvest whatever the user types or signs. The only things that changed between April 2013 and August 2022 are (a) the value-per-victim (Bitcoin web-wallet credentials in 2013; DeFi protocol approval signatures in 2022), (b) the on-chain observability of the extraction (UTXO-level credential drain in 2013; single-transaction Permit/approve drain in 2022), and (c) the forensic tooling available to investigators. The attacker's exploit surface is the same.

The campaign is also an important standing data point on the absorptive capacity of the industry for infrastructure-layer security lessons. The DNS-hijack vector was demonstrated in production against a live cryptocurrency victim population in April 2013. The defensive controls that would have prevented it — registrar-lock, DNSSEC, automated DNS-change monitoring, MFA on DNS-hosting credentials — were well-understood in the broader information-security community at the time. But they were not systematically adopted by cryptocurrency front-end operators until after the Curve DNS hijack of August 2022, nearly a decade later. The meta-lesson for OAK is that documenting a technique and its mitigation in the public record is not sufficient to produce adoption; the absorptive-capacity question — what makes the industry actually adopt a known mitigation for a known technique? — is itself a defender-relevant analytic question, and the Atlas-DNS-to-Curve decade gap is the cleanest data point for it.

Contributors writing the T15.004 Technique page, or any T6.008 technique material, should treat the Atlas DNS campaign as the technique-class origin — the point at which the kill chain went from theoretical to operationalised-against-cryptocurrency-targets. The Curve and Galxe cases are the modern maturations, not the class origins. The structural fix — MFA on registrar credentials, registry-lock, DNSSEC, automated DNS-change alerting — was the same fix in 2013 that it was in 2022 and remains in 2025. The lesson was available; the absorption was slow. The OAK treatment should preserve that arc rather than implying the technique class is a DeFi-era phenomenon.