Bitstamp hot-wallet compromise — Bitcoin — 2015-01-04

Summary

Bitstamp, founded in Slovenia in 2011 and at the time of the event one of the largest Europe-based bitcoin exchanges, suffered a hot-wallet compromise that drained 18,866 BTC over a short window beginning approximately 2015-01-04. The exchange detected the anomalous outflow, suspended deposits and withdrawals on 2015-01-05, and announced the breach publicly the same day. After a four-day suspension during which the hot-wallet keys were rotated onto fresh infrastructure and the cold-wallet float was migrated forward, Bitstamp reopened on 2015-01-09 with customer balances restored from the still-intact cold reserve and the on-chain loss absorbed against the corporate balance sheet.

The internal incident report — drafted for Bitstamp's own forensic record by the firm Stroz Friedberg, leaked to KrebsOnSecurity in mid-2015, and subsequently published in detail — is the canonical primary source for the technical reconstruction. The report documents a spear-phishing campaign that ran from approximately 2014-11 through 2015-01 against six Bitstamp administrators. The campaign delivered hostile Microsoft Word documents through a mix of email and Skype direct messages; the documents, when opened, executed VBA macros that downloaded a second-stage payload providing remote operator access to the targeted endpoint. The successful compromise — the attacker reached the system administrator with operational access to the hot-wallet signing infrastructure — produced lateral movement to the signing host and the issuance of authorised hot-wallet withdrawals over the following days, draining the operational float before the cold-wallet rotation could occur.

The case is a foundational T11 worked example in OAK because it predates virtually the entire post-2017 exchange-custody vocabulary. The structural failure mode — administrator endpoint with persistent operational access to hot-wallet signing infrastructure; no out-of-band approval requirement on hot-wallet withdrawals at the volumes involved; no rotates-on-suspicion discipline that would have invalidated the signing-host's authority the moment the spear-phishing campaign was observed against the same administrator group — is the structural ancestor of nearly every operator-internal hot-wallet compromise that followed. Defenders writing exchange-custody runbooks should treat Bitstamp 2015 as the case that demonstrated, in the open primary record, what spear-phishing-to-hot-wallet looks like end-to-end before any of the post-2017 industry baselines existed.

Timeline (UTC)

When	Event	OAK ref
2014-11	Spear-phishing campaign begins against Bitstamp administrators; hostile Word documents with VBA macros delivered via email and Skype direct messages to six administrators	(pre-event — campaign initiation)
2014-12 to 2015-01	Multiple administrators receive variations of the macro-delivered payload; one administrator (the systems administrator with operational access to hot-wallet signing infrastructure) opens a malicious document and the second-stage remote-access payload is installed	T11 entry — administrator endpoint compromised via spear-phishing
2015-01-04	Attacker has reached the hot-wallet signing host through lateral movement from the compromised administrator endpoint; begins issuing authorised hot-wallet withdrawals	T11 extraction — signing-infrastructure access
2015-01-04 to 2015-01-05	18,866 BTC drained from Bitstamp's hot wallet to attacker-controlled addresses	(extraction continued)
2015-01-05	Bitstamp detects the anomalous outflow, suspends deposits and withdrawals, announces the breach publicly	(operator detection / disclosure)
2015-01-06 to 2015-01-08	Bitstamp engages Stroz Friedberg for forensic incident response; rotates hot-wallet keys onto fresh infrastructure; migrates cold-wallet float forward	(incident response)
2015-01-09	Bitstamp reopens; customer balances restored from the cold-wallet majority; on-chain loss absorbed corporately	(operational recovery — corporate-funded)
2015-07	KrebsOnSecurity publishes the leaked Bitstamp / Stroz Friedberg internal incident report; the macro-delivery / lateral-movement / hot-wallet-drain chain becomes part of the public record	Forensic-reconstruction milestone — primary source

What defenders observed and learned

• Pre-event: the spear-phishing campaign ran for ~2 months against the same administrator cohort before the compromise that produced the hot-wallet drain. The internal report documents multiple administrators receiving variants of the same hostile-macro payload through 2014-11 and 2014-12 — meaning the campaign was visible (multiple administrators, including ones who did not open the document, encountered it) before the successful compromise. A rotates-on-suspicion discipline that treated "spear-phishing campaign observed against administrators with hot-wallet access" as a triggering event for hot-wallet key rotation would have invalidated the signing-host's authority before the extraction landed. This discipline was not operational practice in 2015; the post-2017 industry baseline retro-fits against precisely this gap.
• At-event: the hot-wallet drain ran over a short window (~24–48 hours of active extraction) and was not detected by an automated egress-anomaly system. Detection came from operational-side observation of the hot-wallet balance, not from a signing-side velocity / volume / pattern check that fired in time. The post-2017 industry baseline of "any hot-wallet egress not matched by a customer-withdrawal-or-rebalance event must alert within minutes" is, again, retro-engineered against the failure shape Bitstamp demonstrated.
• Post-event: Bitstamp's recovery turned on the still-uncompromised cold-wallet majority. The cold/hot separation worked in the sense that mattered most — the bulk of customer assets were not reachable from the compromised administrator endpoint — but the operational float size (18,866 BTC) was, in retrospect, larger than a tightly-managed hot-wallet operation would have held. Defenders writing exchange-custody runbooks should treat the hot-wallet float size as a directly-controllable risk parameter and the Bitstamp event as the canonical reference for the cost of holding more than the minimum-operational-liquidity in a hot wallet.
• Post-event: Bitstamp absorbed the loss corporately and made customers whole; no insurance fund, no socialised-loss mechanism, no creditor-claim instrument. The recovery model is the simplest of the four canonical exchange-recovery patterns OAK documents (corporate-funded reimbursement; cf. Coincheck 2018, where the same model recurs at much larger scale).

What this example tells contributors writing future Technique pages

• Bitstamp 2015 is a foundational T11 case and should be cross-referenced from any T11 sub-technique page that documents administrator-endpoint compromise as the entry path. The structural pattern — spear-phishing of an administrator with operational access to hot-wallet signing infrastructure → lateral movement → authorised-from-the-signing-host withdrawals — is the same structural pattern that appears in NiceHash 2017, KuCoin 2020, and DMM Bitcoin 2024. The technical specifics differ (Word VBA macros in 2015; varied tradecraft thereafter), but the structural shape is identical, and contributors writing T11 pages should treat the 2015–2024 lineage as evidence that the pattern has been an unaddressed exchange-side risk for nearly a decade.
• The "rotates-on-suspicion" discipline gap is the load-bearing defender lesson. The fact that the spear-phishing campaign was visible against multiple administrators before the compromise that produced the drain — and that no rotation of hot-wallet signing authority occurred in response — is the clearest available illustration of why operational-discipline mitigations (M22-class rotation discipline, in OAK's mitigation taxonomy) matter at least as much as technical-control mitigations. Contributors writing M-axis pages should treat Bitstamp as a primary reference for the practical content of "rotates-on-disclosure / rotates-on-suspicion" as an operational practice rather than a checkbox.
• pseudonymous-unattributed attribution is the right marker. No public-record indictment, attribution-cluster claim, or law-enforcement disposition has named the Bitstamp 2015 attacker; the case is not OAK-G01-attributed and should not be retro-fit to that cluster. Contributors writing other pre-2017 exchange-hack worked examples should expect a similar attribution surface — the FBI / Treasury attribution surface for crypto-specific events accelerated post-2018, and many earlier incidents remain forensic-only with no actor identification at all.
• The leaked-internal-report-as-primary-source pattern is its own caution. Bitstamp's incident report became part of the public record via the KrebsOnSecurity leak, not via Bitstamp's own disclosure. Contributors citing the technical reconstruction should be explicit that the canonical primary source is the leaked Stroz Friedberg report; secondary sourcing (CoinDesk, contemporaneous press) inherits its detail from the leak rather than independently corroborating it.

Public references

• [krebsbitstamp2015] — Krebs, B. Bitstamp: Recent Hack Cost Us Almost $5 Million. KrebsOnSecurity, 2015-07. The canonical public surface for the leaked Stroz Friedberg incident report; reconstructs the spear-phishing-via-Skype-and-email, hostile-Word-macro, lateral-movement, and hot-wallet-drain chain in detail.
• [strozbitstampreport2015] — Stroz Friedberg. Bitstamp Incident Report (internal). 2015 (drafted post-incident; leaked 2015-07 via KrebsOnSecurity). Primary technical reconstruction of the campaign and compromise.
• [bitstamppress2015] — Bitstamp Ltd. Bitstamp Statement on Operational Pause / Resumption. 2015-01-05 and 2015-01-09 announcements; primary-source operator disclosure of the breach and the recovery posture.
• [coindeskbitstamp2015] — CoinDesk. Bitstamp Suspends Service Following $5 Million Bitcoin Theft. 2015-01-05; contemporaneous press coverage at the moment of disclosure.
• [reutersbitstamp2015] — Reuters. Bitcoin exchange Bitstamp says hackers stole nearly $5 million. 2015-01-06; second-source contemporaneous coverage.

Discussion

Bitstamp 2015 is the OAK record's earliest cleanly-documented spear-phishing-to-hot-wallet exchange compromise. The case has three properties that make it operationally instructive for the broader T11 surface even though the technical specifics are now a decade out of date.

First, the entry vector is human, not technical: the load-bearing failure was that an administrator with hot-wallet operational access opened a hostile document delivered through Skype. Every layer of technical hardening downstream of that opening — VBA-macro execution policy, second-stage payload delivery, lateral movement to the signing host, authorised-from-the-signing-host withdrawal — is contingent on the human-side compromise that started it. Defenders reading the case as a "macro-execution problem" or a "Skype-as-delivery problem" miss the structural point: the administrator endpoint had persistent operational access to hot-wallet signing infrastructure, and any successful endpoint compromise of that administrator would have produced approximately the same outcome. Contributors writing Technique pages should treat the human-side entry vector as the structural fact and the technical specifics (which generation of office macro, which second-stage payload, which delivery channel) as variation around it.

Second, the case is the canonical pre-OAK-G01 T11 anchor. The Bitstamp attacker has never been publicly identified; no DPRK or other state-attribution claim attaches to the case; the actor cluster is genuinely unknown after a decade. This matters for OAK's attribution discipline because it demonstrates that the T11 entry-vector class produces industry-defining losses independently of any G-cluster attribution. Contributors who treat T11 as "the Lazarus exchange-hack pattern" — a framing that the post-2018 record can encourage — should keep Bitstamp 2015 in view as the canonical reminder that T11 predates the G01 attribution scaffolding and exists as a structural pattern regardless of which actor cluster is exercising it in any given period.

Third, the rotates-on-suspicion discipline gap is the most directly actionable defender lesson. The spear-phishing campaign was visible against multiple administrators before the compromise that produced the drain. A defender posture that treats observed spear-phishing against administrators with hot-wallet access as a triggering event for hot-wallet key rotation — independently of whether any individual phish is known to have succeeded — would have invalidated the signing-host's authority before the extraction window. This discipline is now standard at well-run custody operations; the Bitstamp case is the cleanest historical illustration of why the discipline has the operational shape it does. Contributors writing M-axis (mitigation) pages should treat Bitstamp as a primary reference for the practical content of M22-class rotation discipline — not as an abstract control specification, but as a response to the specific failure shape Bitstamp made visible.