Worked example · 2025-08
BtcTurk hot-wallet drain (recurrence) — multi-chain — 2025-08-14
Summary
BtcTurk is one of Turkey's largest centralised cryptocurrency exchanges. On 2025-08-14, BtcTurk's operational hot wallets across multiple EVM-compatible chains were drained in a sequence of large outflows totalling approximately $48M to attacker-controlled addresses. Affected chains included Ethereum, Avalanche, Arbitrum, Base, Optimism, Mantle, and Polygon. The bulk of proceeds consolidated into two recipient addresses — a fan-in pattern characteristic of the post-extraction laundering window.
Per Halborn's post-incident write-up and on-chain analyst commentary, the entry vector was operator-internal hot-wallet private-key compromise across a multi-chain key-storage surface — structurally identical to the BtcTurk June 2024 incident fourteen months earlier. Halborn's analysis explicitly noted that, in both the 2024 and 2025 BtcTurk attacks, the attacker gained access to private keys used to manage the protocol's hot wallets. The repetition of the same root-cause class within fourteen months is the analytically load-bearing feature of the case.
BtcTurk's initial public communications characterised the incident as a "technical issue" with hot wallets but assured users that cold wallets and user funds were safe. The exchange suspended all deposits and withdrawals while the team scoped the breach. The operator-side initial-framing pattern is consistent with the broader 2024–2025 cohort (FixedFloat, Indodax, BingX) and reinforces that operator-side public framing in the first 24–48 hours of a hot-wallet incident is unreliable as a primary signal.
For OAK's purposes the entry vector is off-chain and operator-internal, structurally identical to the June 2024 BtcTurk incident. OAK v0.1 does not have an on-chain Technique that captures this entry vector; the case is documented here in the worked-example layer because the on-chain manifestation, the multi-chain extraction pattern, and the structural lesson on repeated-incidents-on-same-operator are all on the public record.
Timeline (UTC)
| When | Event | OAK ref |
|---|---|---|
| 2024-06-22 | First BtcTurk incident: ~$55M operator-internal multi-chain hot-wallet compromise; ~10% recovery via Binance compliance freeze; CEO subsequently departs; operator-side custody-architecture review follows (see examples/2024-06-btcturk.md) |
(prior incident reference) |
| 2024 Q3 — 2025 Q2 | Operator-side custody-architecture review and remediation; user-side and counterparty-side trust gradually restored | (prior remediation window) |
| Pre-event (early August 2025) | Operator-internal compromise of BtcTurk hot-wallet key material (recurrence); the same root-cause class as the June 2024 incident | (off-chain entry vector — recurrence) |
| 2025-08-14 | Near-simultaneous multi-chain extraction across Ethereum, Avalanche, Arbitrum, Base, Optimism, Mantle, Polygon; cumulative outflow reaches ~$48M; bulk consolidates into two recipient addresses | T5-equivalent (extraction event) |
| 2025-08-14 | BtcTurk publicly acknowledges incident; characterises issue initially as "technical issue" with hot wallets; suspends deposits and withdrawals; confirms cold wallets unaffected | (operator response) |
| 2025-08-14 onward | CoinDesk, Cointelegraph, The Defiant industry-press coverage; Halborn, Beosin publish post-incident technical analyses; on-chain analyst community surfaces multi-chain drain pattern | (industry / community detection) |
| 2025-08 onward | Stage-1 laundering: proceeds routed through standard 2025 mixer rails on Ethereum side; consolidation into two primary recipient addresses | T7.001-equivalent (Mixer-Routed Hop) + T8.001-equivalent (consolidation pattern) |
| 2025-08 onward | BtcTurk completes phased restoration of services across affected chains | (recovery state) |
What defenders observed
- Custody-architecture review after an incident is not by itself sufficient to prevent a recurrence within an 18-month window. The BtcTurk June 2024 → August 2025 pair is the strongest 2024–2025 evidence in the corpus that operator-side post-incident architectural changes must be substantive and verified, not procedural. Both incidents share the operator-internal-multi-chain-hot-wallet-compromise root-cause class; the recurrence within fourteen months indicates the post-2024-incident remediation did not address the underlying architectural risk class. Defender / risk-team practice during the 12–18 months following any operator-internal hot-wallet incident should treat per-chain key-storage segregation, custody-architecture review depth, and personnel-rotation hygiene as continuing rather than one-shot operational requirements.
- Multisig protection again did not protect against key-storage-surface compromise. As with the June 2024 BtcTurk incident, the August 2025 attack proceeded across multiple hot wallets with sufficient signing material to bypass the multisig threshold. The repeated pattern reinforces the BtcTurk-specific analytical contribution: a multisig threshold scheme protects against single-signer compromise but does not protect against a key-storage-surface compromise that yields multiple keys at once. Per-chain (or per-chain-family) key-storage segregation is a primary control composing with the multisig threshold scheme — not redundant with it.
- Two-recipient-address consolidation is a forensic signal of post-extraction laundering preparation. The August 2025 proceeds consolidated into two recipient addresses — a fan-in pattern that simplifies the subsequent laundering chain. Defender forensic investigators should treat post-extraction consolidation patterns as a first-class signal in the immediate post-incident window; the consolidation surface is one of the few pre-mixer windows in which on-chain freeze authorities (cooperating-exchange-account freezes, stablecoin-issuer freezes) can be invoked productively.
- Operator-side initial framing as "technical issue" should not be taken at face value. As with FixedFloat (February 2024), DEXX (September-November 2024), and other 2024–2025 operator-side initial-response patterns, BtcTurk's August 2025 initial communications characterised the incident in cautious and technically-minimal language. The defender / risk-team lesson is that operator-side public framing in the first 24–48 hours of a hot-wallet incident is unreliable as a primary signal; the on-chain pattern is the load-bearing primary signal.
- The Turkish regulatory environment continues to operate without a public attribution surface for OAK-G01 or Group-level cohort attribution. Neither the June 2024 nor the August 2025 BtcTurk incidents have produced Turkish-government public attribution at v0.1's reporting horizon. The Turkish Capital Markets Board (SPK) regulates the crypto-asset trading sector following the 2024 legislation, but the regulator-supervised licensing posture has not produced public attribution analogous to the U.S. FBI/IC3 or Japanese NPA surfaces. Contributors writing future Turkish-exchange examples should expect this profile.
What this example tells contributors writing future Technique pages
- The operator-internal hot-wallet key compromise gap is now seven worked examples deep, with the BtcTurk pair adding the repeated-incidents-on-same-operator dimension. The operator-internal-key-compromise sub-class now contains KuCoin (2020), Coincheck (2018), Stake.com (2023), Indodax (2024-09), BingX (2024-09), Phemex (2025-01), BtcTurk (June 2024 + August 2025) as canonical worked examples. The BtcTurk pair specifically adds the repeated-incidents-on-same-operator dimension — an analytical surface no other 2024–2025 OAK case in the corpus touches.
pseudonymous-unattributedis the right marker for both BtcTurk incidents at v0.1's reporting horizon. No industry-forensic provider has published cluster-overlap evidence tying either BtcTurk incident to OAK-G01 or any other Group-level cluster. Contributors writing the worked-example layer should reserveinferred-strongfor cases where multi-firm concurrence plus cluster-graph evidence to confirmed wallets exists. The BtcTurk pair is the cleanest 2024–2025 illustration that not all operator-internal-key-compromise cases default to OAK-G01 — DPRK-suspicion is not the same as cluster-overlap evidence.- Repeated-incidents-on-same-operator deserves explicit Mitigation-page treatment as a continuing-discipline pattern. The BtcTurk pair is the strongest 2024–2025 case of this pattern in the corpus. Contributors writing the OAK Mitigations layer should consider a cross-cutting Mitigation entry covering post-incident custody-architecture review depth, with explicit thresholds (substantive vs procedural), verification requirements (independent third-party audit), and continuing-discipline windows (12–18 months minimum post-incident).
- The BtcTurk pair anchors a forecasting argument: operator-internal-key-compromise will continue to recur on the same operators absent substantive architectural change. Contributors writing the OAK v0.x update on operator-side custody architecture should treat the BtcTurk pair as the canonical empirical case for the proposition that the operator-internal-key-compromise root-cause class requires architectural rather than procedural remediation. The cohort-level forecast is that, absent substantive change in the operator-internal-key-storage surface across the broader exchange-custody industry, additional repeated-incident pairs are likely on the 12–24 month horizon.
Public references
- Halborn — Explained: The BtcTurk Hack (August 2025) — primary post-incident technical analysis covering the multi-chain drain pattern and the operator-internal key-compromise root-cause hypothesis; explicitly notes the pattern parallels the June 2024 BtcTurk incident.
- Beosin — Fund Flow Analysis of BtcTurk $48 Million Hack — flow-of-funds forensic analysis of the post-extraction consolidation pattern.
- CoinDesk — Crypto Exchange BtcTurk Experiences $48M Worth of Suspicious Outflows Amid Hack Fears — primary industry-press initial-disclosure coverage.
- Cointelegraph — BtcTurk halts withdrawals amid suspected $48M crypto hack — operator-side withdrawal-suspension coverage.
- The Defiant — BtcTurk Suspends Deposits After Suspected $48 Million Multi-Chain Hack — multi-chain extraction coverage.
- CoinCentral — BtcTurk Exchange Halts Withdrawals After $48M Hack Across Multiple Networks — supplementary press coverage with chain-by-chain breakdown.
- Crypto Daily — BtcTurk Faces Second Major Hack in a Year, $48M Missing from Hot Wallets — explicit framing of the recurrence pattern relative to the June 2024 incident.
Discussion
BtcTurk August 2025 is OAK's canonical 2025 worked example of operator-internal hot-wallet key compromise as a recurring incident on the same operator within an 18-month window. The case sits in the same entry-vector class as the June 2024 BtcTurk incident, with the same multi-chain extraction pattern and the same operator-internal-key-compromise root-cause hypothesis. The fourteen-month interval between the two incidents — both with broadly similar shapes — is structurally distinct from the single-event pattern of most operator-side custody compromises in the OAK corpus.
The repeated-incidents-on-same-operator dimension is the BtcTurk-pair-specific load-bearing analytical contribution. Defender / Mitigations-layer practice should treat post-incident custody-architecture review depth, verification requirements, and continuing-discipline windows as primary operational dimensions — not as procedural follow-on activities. The empirical lesson from the BtcTurk pair is that operator-side architectural remediation between incidents was insufficient to prevent the recurrence; the underlying architectural risk class persisted.
The multisig-vs-key-storage-segregation lesson, established in the June 2024 BtcTurk Discussion, is reinforced by the August 2025 incident. Both incidents proceeded across multiple hot wallets with sufficient signing material to bypass the multisig threshold. The repetition is the cleanest 2024–2025 corpus evidence that a multisig threshold scheme is not a substitute for key-storage segregation — and that defender runbooks for multi-chain hot-wallet custody should treat per-chain (or per-chain-family) key-storage segregation as a primary control composing with the multisig threshold scheme.
The pseudonymous-unattributed framing is the third BtcTurk-pair-specific contribution. Neither incident has produced cluster-overlap evidence tying it to OAK-G01 or any other Group-level cluster at v0.1's reporting horizon. The pair anchors the discipline that not all operator-internal-key-compromise cases default to OAK-G01 — the 2024–2025 wave includes both confirmed-grade OAK-G01 cases (Bybit, DMM, WazirX) and pseudonymous-unattributed cases (BtcTurk pair) at the same operator-side custody surface. Contributors writing future cases should preserve this discipline.
The forecast argument is the fourth BtcTurk-pair-specific contribution. The 2024–2025 wave has demonstrated that operator-internal-key-compromise will continue to recur on the same operators absent substantive architectural change — and the BtcTurk pair is the strongest empirical case for this forecast in the OAK corpus at v0.1. Contributors writing the OAK v0.x update on operator-side custody architecture should treat the BtcTurk pair as the canonical empirical anchor for the architectural-vs-procedural-remediation distinction.
For OAK's broader credibility, including the BtcTurk pair (June 2024 + August 2025) in v0.1 closes a structural gap in the corpus: it adds the repeated-incidents-on-same-operator analytical surface to a corpus that otherwise treats operator-side custody compromises as single-event cases with isolated post-incident remediation. The BtcTurk pair establishes that the operator-side custody-architecture review surface is itself a continuing-discipline dimension, not a one-shot remediation event.