OAK — OnChain Attack Knowledge

Worked example · 2023-09

Mixin Network — multi-chain — 2023-09-23

Loss
~$200M across multiple chains, drained from Mixin Network hot-wallet infrastructure. Largest single crypto-theft event of 2023 by public accounting.
OAK Techniques observed
OAK-T11.001 (Third-Party Signing / Custody Vendor Compromise) — primary, broadly construed: the entry vector was a generic cloud-database compromise at Mixin's cloud service provider, not a signing-specific vendor (see "What this tells contributors" below — this surfaces a v0.x scope question for T11.001). Downstream OAK-T7.001 (Mixer-Routed Hop) via Tornado Cash, observed initially in late 2023 and again in February 2026 after ~2 years of wallet dormancy.
Attribution
pseudonymous — not publicly attributed at the time of disclosure. SlowMist and Google-owned Mandiant assisted Mixin with incident response; no operator-cluster identification has been publicly released by either firm or by any government agency as of the date of this entry. Initial industry speculation about OAK-G01 (Lazarus / DPRK) involvement was raised in some 2023 reporting but has not been corroborated by any authoritative attribution. Treat as unattributed per OAK conventions until a corroborating authoritative source publishes.
Key teaching point
Mixin is OAK's canonical T11.001-broadly-construed example for the cloud-database-compromise sub-class of third-party-vendor compromise. The case is included because: (1) the dollar loss is the largest single crypto-theft event of 2023, (2) the structural failure mode (storing sufficient-to-withdraw material with a third-party cloud provider) is broadly applicable to any custodial / hot-wallet operator, (3) the incident is unattributed at the operator-cluster level and therefore exercises OAK's unattributed framing honestly, and (4) the long-dwell laundering pattern (~2-year dormancy followed by mixer-routed hops) is a defender signal that contributors writing future T7.001 pages should reflect.

Summary

In the early hours of September 23, 2023 (UTC), the database of Mixin Network's cloud service provider was compromised. Mixin Network is a cross-chain transfer / mesh protocol that routes asset movement between chains via centrally-operated hot-wallet infrastructure; the cloud database held sensitive material (per public reporting, including key-share or credential data) needed to authorise withdrawals from those hot wallets. With access to the database contents, the attacker was able to authorise a coordinated series of outflows draining ~$200M-equivalent across multiple chains (predominantly ETH and BTC) to attacker-controlled addresses.

For OAK's purposes, the incident is predominantly off-chain at the entry vector: the structural failure was that Mixin had stored sensitive infrastructure data with a third-party cloud provider whose database was compromised. OAK v0.1's T11.001 ("Third-Party Signing / Custody Vendor Compromise") is the closest fit because the operational shape — third-party-vendor compromise that translates into authorised-looking withdrawals — matches the T11.001 pattern. But T11.001's name and scope language as currently written suggest a signing-specific vendor (e.g., a multisig signing platform like Safe{Wallet} in the Bybit case), and the Mixin case is a generic cloud-database compromise. Document under T11.001 with the explicit caveat that the entry-vector class is broader than what T11.001's name suggests, and flag the scope-clarification question for v0.x (see ROADMAP suggestion in the contributor section below).

Mixin temporarily suspended deposits and withdrawals after the incident, offered the attacker a $20M bug-bounty-style on-chain message, and subsequently announced a partial-repayment plan for affected users (50% in stablecoins, 50% in tokenised "Mixin Debt Token" claims redeemable through a multi-year schedule). The attacker wallets remained dormant for nearly two years; in February 2026, the primary attacker wallet moved 2,005 ETH (~$3.85M) into Tornado Cash via 20 split transactions, then onward into fresh wallets and centralised-exchange off-ramps. Significant balances (per public reporting, on the order of 57,849 ETH and 891 BTC) remain in the attacker cluster as of this entry.

Timeline (UTC)

When Event OAK ref
Pre-event Mixin stores sensitive hot-wallet infrastructure material (per public reporting, key-share / credential data) with a third-party cloud service provider (off-chain entry-vector substrate — T11.001 broadly construed)
2023-09-23 (early UTC) Cloud service provider's database is compromised; attacker obtains material needed to authorise withdrawals (off-chain entry vector)
2023-09-23 Coordinated outflows drain ~$200M-equivalent from Mixin hot wallets across multiple chains T11.001 extraction (broadly construed)
2023-09-25 Mixin publicly suspends deposits and withdrawals; engages SlowMist and Google / Mandiant for incident response (response)
Late September 2023 Mixin posts on-chain message offering $20M bug-bounty-style return arrangement (negotiation)
2023 onward Mixin announces 50%-stablecoin / 50%-MDT debt-token repayment plan; service resumed under modified architecture (recovery)
2023-Q4 Initial Tornado Cash hops observed for a portion of the stolen ETH T7.001 mixer-routed hop (initial)
2024 – early 2026 Primary attacker wallets dormant for ~2 years (operator dwell)
2026-02-12 Primary attacker wallet sends 2,005 ETH (~$3.85M) into Tornado Cash via 20 split transactions; subsequent fresh-wallet receipts and CEX-deposit pattern observed T7.001 mixer-routed hop (resumed)
As of 2026-04 ~57,849 ETH and ~891 BTC remain in attacker cluster per public on-chain reporting; no authoritative operator-cluster attribution has been published (open)

What defenders observed

  • Pre-event (structural): Mixin's deposit-and-withdrawal infrastructure depended on data stored with a third-party cloud service provider. The cloud vendor's database was the single point of failure. The structural failure mode is therefore: never store key material, key-share material, or credentials sufficient to authorise hot-wallet withdrawals with a third-party cloud provider in a form that the cloud provider's database compromise can disclose. This is the central defender lesson of the Mixin case and is applicable to any custodial / hot-wallet operator at any scale.
  • At-event (entry vector): the compromise occurred at the cloud vendor's database layer, not in Mixin's own code or contracts. From the on-chain perspective, the extraction transactions appeared as authorised withdrawals — Mixin's hot-wallet signing infrastructure, given the disclosed material, produced legitimate-looking signatures. There was no on-chain anomaly until the outflows themselves landed.
  • At-event (on-chain): the extraction was a coordinated multi-chain outflow rather than a single transaction. Detection-by-monitoring at Mixin's own infrastructure was, per public reporting, lagged; the public disclosure came two days after the on-chain extraction. Cross-chain, multi-asset coordinated-outflow patterns are the signature defenders should expect for T11.001-class compromises against multi-chain operators.
  • Post-event (incident response): SlowMist published on-chain analysis and contributed to the initial public technical record. Google's Mandiant assisted with the cloud-vendor-side incident response. Notably, neither firm has publicly identified the cloud service provider in question, and neither has published an operator-cluster attribution. The disclosure constraints (litigation pressure on Mixin, contractual constraints around naming the cloud vendor, and operator-attribution caution given lack of corroborating signals) are the visible defender-side constraints in the public record.
  • Post-event (laundering): the ~2-year dormancy followed by the February 2026 Tornado Cash hops is consistent with a sophisticated operator's laundering pattern — wait until forensic attention has decayed, then begin laundering through mixer-routed hops with split transactions. The laundering-stage signature does not, by itself, confirm any specific operator cluster.

What this tells contributors writing future Technique pages

  • T11.001's scope needs clarifying in v0.x. As currently named ("Third-Party Signing / Custody Vendor Compromise"), T11.001 reads as if it covers signing-specific vendors only (the Bybit / Safe{Wallet} case is the canonical example). The Mixin case is operationally adjacent — third-party-vendor compromise that translates into authorised-looking withdrawals — but the vendor is a generic cloud database provider, not a signing platform. Two reasonable v0.x paths:
    1. Broaden T11.001's stated scope to "Third-Party Vendor Compromise (signing, custody, or infrastructure-data hosting)" and document Mixin and Bybit as two sub-classes within it.
    2. Split T11.001 into two sibling sub-Techniques: T11.001a (signing-vendor / supply-chain compromise — Bybit-class) and T11.001b (cloud-infrastructure-data hosting compromise — Mixin-class). The structural failure modes differ enough that a defender's mitigation map differs (Bybit-class is mitigated by out-of-band signing verification; Mixin-class is mitigated by never co-locating sufficient-to-withdraw material with a generic cloud provider), and a sub-class split would carry that distinction in the taxonomy itself. Either path is defensible; the choice is a TAXONOMY-GAPS question for v0.x.
  • Cloud-vendor compromise as a class deserves explicit framing. Mixin is the canonical example of generic-cloud-database compromise as the entry vector for a major hot-wallet drain. Future T11 examples (or a future T11.001b) should preserve Mixin's framing: the structural failure is what was stored where, not the cryptographic primitives or the smart-contract logic.
  • Unattributed-major-incident handling matters for OAK's credibility. Mixin is the largest single crypto-theft event of 2023 and remains unattributed at the operator-cluster level as of this entry. OAK's unattributed standard should be applied honestly: industry speculation (including initial OAK-G01 / Lazarus speculation in 2023 reporting) does not meet OAK's confirmed or inferred-strong thresholds. Contributors writing future T11 examples for unattributed major incidents should follow this template's caveat structure rather than defaulting to the most-likely-operator guess.
  • Long-dormancy laundering patterns are a defender signal. The ~2-year dormancy followed by mixer-routed hops is consistent with operator patience after a major drain. Detection / monitoring infrastructure should not assume that lack of laundering activity within months of a drain implies recovery / abandonment by the operator. T7.001 contributor pages should reflect this dwell-time reality.

Public references

Discussion

Mixin is OAK's canonical T11.001-broadly-construed example for the cloud-database-compromise sub-class of third-party-vendor compromise. The case is included because: (1) the dollar loss is the largest single crypto-theft event of 2023, (2) the structural failure mode (storing sufficient-to-withdraw material with a third-party cloud provider) is broadly applicable to any custodial / hot-wallet operator, (3) the incident is unattributed at the operator-cluster level and therefore exercises OAK's unattributed framing honestly, and (4) the long-dwell laundering pattern (~2-year dormancy followed by mixer-routed hops) is a defender signal that contributors writing future T7.001 pages should reflect.

The case also surfaces a v0.x scope question for T11.001 that contributors should resolve in the next taxonomy iteration: whether T11.001 should be broadened in name and scope (Bybit and Mixin as two sub-classes), or split into T11.001a (signing-vendor) and T11.001b (infrastructure-data hosting). Either resolution is defensible; the open question itself is a useful signal of where OAK's T11 surface is still maturing.

Finally, Mixin illustrates the disclosure-constraint pattern that recurs in T11 cases: the affected operator and the responding forensic firms typically do not name the upstream vendor, do not publish full technical details, and do not publish operator-cluster attribution unless and until authoritative corroboration arrives. Contributors should expect this and should not stretch the public record beyond what is attested.

Techniques demonstrated (2)