Worked example · 2011-06

Mt. Gox auditor account compromise — Bitcoin — 2011-06-19

Loss: approximately 2,000 BTC attempted (attacker attempted to withdraw ~2,000 BTC purchased at a manipulated price of $0.01/BTC). Mt. Gox halted trading, rolled back all trades executed during the compromise window, and restored affected user accounts. No material permanent loss to Mt. Gox users; the exchange absorbed the financial impact of the rollback. At the 2011-06 Bitcoin price of approximately $15–$30/BTC, the attempted extraction equated to approximately $30K–$60K at then-prevailing exchange rates. The attacker was able to withdraw at least some BTC to an external address before Mt. Gox halted operations; the precise amount successfully extracted before the rollback is disputed in contemporaneous sources.
OAK Techniques observed: OAK-T15.003 (Operator Endpoint/Infrastructure Compromise — the attacker compromised a privileged Mt. Gox account, specifically the account of a Mt. Gox auditor with exchange-admin capabilities, gaining the ability to manipulate the exchange's internal trading systems and execute a price-manipulation + withdrawal sequence). OAK-T15.004 (Credential Compromise — the entry vector was the compromise of the auditor's account credentials; the specific compromise mechanism — phishing, password reuse, or credential-stuffing — is not definitively established in the public record, but the OAK classification is credential-compromise as the proximate T15.004 enabler for the T15.003 infrastructure-compromise outcome).
Attribution: pseudonymous attacker; no public named-individual attribution. The attacker operated under pseudonymous Bitcoin addresses. No criminal charges, indictment, or law-enforcement disposition independently names any individual in connection with the Mt. Gox auditor-account compromise at the OAK v0.1 cutoff.
Key teaching point: The Mt. Gox auditor account compromise of June 19, 2011, is the ur-T15.003 exchange event — the earliest cleanly-documented case of a privileged exchange account being compromised to manipulate price and extract funds, establishing a pattern that would repeat at scale for the next 15 years. The structural signature — privileged-account compromise, internal-system manipulation, attempted fund extraction, exchange-side trade reversal as the incident-response mechanism — is invariant across the subsequent exchange-compromise record (Bitfinex 2016, Binance 2019, KuCoin 2020, Bybit 2025). Investigators tracing the T15.003 lineage should recognise the Mt. Gox auditor-account compromise as the foundational archetype that established the exchange-operational-compromise template.

Summary

On June 19, 2011, an attacker compromised the Mt. Gox account of a Mt. Gox auditor — a privileged access account with exchange-admin capabilities, including the ability to modify internal account balances and execute trades at arbitrary prices. The attacker used the auditor's account access to manipulate the BTC/USD price on the Mt. Gox order book to $0.01 per Bitcoin, then used other accounts under the attacker's control to place buy orders at the manipulated price, acquiring approximately 2,000 BTC at $0.01/BTC (a ~99.9% discount from the then-prevailing market price of approximately $15–$30/BTC). The attacker subsequently attempted to withdraw the purchased Bitcoin to external addresses.

Mt. Gox operational staff detected the anomalous trading activity — a BTC price of $0.01/BTC was trivially distinguishable from the market price — and halted all exchange trading. The exchange's incident response included:

Trading halt. All trading activity on Mt. Gox was suspended to prevent further price-manipulated trades.
Transaction rollback. All trades executed during the compromise window were reversed, restoring affected user accounts to their pre-compromise balances. Users who had sold BTC at the manipulated $0.01 price had their BTC returned; users who had bought BTC at the manipulated price had the purchased BTC removed from their accounts.
Withdrawal freeze. Bitcoin and fiat-currency withdrawals were suspended to prevent the attacker from extracting the price-manipulated BTC from the exchange.
Account security review. Mt. Gox conducted an internal security audit of privileged-account access controls and administrator-account credential management, the findings of which were not publicly disclosed in full.

The attacker was able to withdraw at least some BTC to external addresses before Mt. Gox halted withdrawals. The precise amount extracted is disputed in contemporaneous sources, ranging from several hundred to approximately 2,000 BTC. Mt. Gox absorbed the financial loss from any successfully-withdrawn BTC and did not pass the loss to affected users.

The incident was the first publicly documented security breach at a major Bitcoin exchange and the first exchange-operational-compromise event in the cryptocurrency record. It established three structural patterns that became the template for exchange-compromise incident response:

Trading halt as first response. Suspending all exchange activity upon detection of anomalous trading is the standard first-response action for exchange-operational compromises. Every subsequent exchange-compromise incident (Bitfinex 2016, Binance 2019, KuCoin 2020, Bybit 2025) follows this pattern: trading halt, then forensic investigation, then selective or full service restoration.
Transaction rollback as remediation. Reversing trades executed during the compromise window is the standard remediation for price-manipulation attacks on centralized exchanges. The rollback is feasible because centralized exchanges maintain an internal ledger that is independent of the on-chain settlement layer — trades can be reversed on the internal ledger without requiring on-chain reversals. This is the structural property that distinguishes centralized-exchange compromises from on-chain protocol compromises (where transaction reversal is not possible without a chain reorganization).
Withdrawal freeze as extraction-prevention. Suspending withdrawals is the standard extraction-prevention measure for exchange-operational compromises. The measure is effective against price-manipulation attacks (where the attacker needs to withdraw manipulated-price assets to realize value) but is less effective against direct wallet-key-compromise attacks (T11.001), where the attacker has already gained access to the wallet private keys and can sign withdrawal transactions directly on-chain, bypassing the exchange's withdrawal processing system.

The Mt. Gox auditor-account compromise was a T15.003 event — an operator-infrastructure compromise (the auditor's privileged account access) that enabled internal-system manipulation (price manipulation on the order book) — rather than a T11.001 event (direct wallet-key compromise). The distinction is load-bearing for the incident-response model: a T15.003 compromise of an exchange's operational systems can be contained by halting exchange operations, reversing internal-ledger transactions, and freezing withdrawals; a T11.001 compromise of the exchange's wallet private keys cannot be contained by halting exchange operations because the attacker can sign on-chain transactions independently. Mt. Gox's ability to contain the June 2011 incident through operational controls (trading halt, rollback, withdrawal freeze) was possible precisely because the compromise was T15.003 rather than T11.001.

The incident also illustrates the privileged-account-as-attack-surface pattern that recurs across exchange-operational compromises. The auditor's account had exchange-admin capabilities — the ability to modify internal account balances and execute trades at arbitrary prices — that were not appropriate for an auditor's functional role. The access-control failure that gave an auditor account exchange-admin privileges is the structural T15.003 surface: the operator's infrastructure granted privileged access to an account whose security posture (the auditor's credential management) was insufficient for the privileges granted. The principle of least privilege — that accounts should have only the minimum access necessary for their functional role — was violated, and the violation created the attack surface.

Timeline (UTC)

When	Event	OAK ref
2011-06-19 (early)	Attacker compromises Mt. Gox auditor's account credentials; gains access to privileged exchange-admin account	T15.004 (credential compromise) + T15.003 (privileged-account access via compromised credentials)
2011-06-19	Attacker uses auditor account to manipulate BTC/USD price on Mt. Gox order book to $0.01/BTC	T15.003 (operator-infrastructure compromise — internal-system manipulation)
2011-06-19	Attacker uses attacker-controlled accounts to buy ~2,000 BTC at manipulated $0.01 price	T15.003 (privileged-access-enabled extraction)
2011-06-19	Attacker initiates withdrawal of price-manipulated BTC to external addresses; at least some BTC successfully withdrawn before exchange response	T15.003 (extraction)
2011-06-19	Mt. Gox operational staff detect anomalous trading activity; halt all exchange trading; suspend all withdrawals	(incident response — trading halt)
2011-06-19 to 2011-06-20	Mt. Gox rolls back all trades executed during compromise window; restores affected user accounts to pre-compromise balances	(incident response — transaction rollback)
2011-06-20+	Mt. Gox conducts internal security audit of privileged-account access controls; findings not fully publicly disclosed	(incident response — security review)
2011-06-20+	Mt. Gox resumes trading and withdrawals after confirming rollback and security-review completion	(service restoration)

What defenders observed

Pre-event (access-control layer): A Mt. Gox auditor account had exchange-admin privileges — the ability to modify internal account balances and execute trades at arbitrary prices — that were not appropriate for an auditor's functional role. The access-control failure (privilege escalation at the role-assignment layer) was the standing T15.003 surface: the operator's infrastructure granted privileged access to an account whose credential security was insufficient for the privileges granted.
At-event: The attacker's activity was distinguishable from normal exchange operations by two signals: (1) the BTC/USD price on the order book diverged from the market price by ~99.9% (a trivially detectable anomaly at the exchange-operations layer), and (2) a single account (the auditor's account) was the source of the price-manipulating trades (a standard anomaly-detection signal for internal-system misuse). Both signals are standard exchange-operations monitoring items that remain relevant for modern centralized exchanges.
Post-event: Mt. Gox's incident response (trading halt, transaction rollback, withdrawal freeze, security review) was effective at containing the incident because the compromise was T15.003 (operational-system compromise) rather than T11.001 (wallet-key compromise). The incident-response model — contain at the operational layer, reverse internal-ledger transactions, freeze extraction paths — is the standard template for T15.003 exchange-operational compromises and was validated by the Mt. Gox 2011-06 response.

Public references

See citations in corresponding technique file.

What this example tells contributors writing future Technique pages

The Mt. Gox auditor-account compromise is the boundary case between T15.003 and T15.004. T15.004 (credential compromise) was the entry vector — the attacker gained access to the auditor's account credentials. T15.003 (operator infrastructure compromise) was the outcome — the compromised credentials granted privileged access to the exchange's internal systems, enabling price manipulation and attempted extraction. The two Techniques co-occur and are sequential: T15.004 is the how (how did the attacker get in?), and T15.003 is the what (what operational surface did the access enable?). Contributors tagging exchange-compromise incidents should tag both Techniques where the entry vector is a credential compromise and the outcome is infrastructure-access.
The distinction between T15.003 and T11.001 exchange compromises is load-bearing for incident response. A T15.003 compromise can be contained by halting exchange operations and reversing internal-ledger transactions; a T11.001 compromise (wallet-key compromise) cannot be contained by these measures because the attacker can sign on-chain transactions independently of the exchange's operational systems. Contributors writing exchange-compromise incident pages should explicitly classify the incident as T15.003 (operational-system compromise), T11.001 (wallet-key compromise), or both, and should describe the incident-response model's dependence on this classification.
The principle of least privilege as a T15.003 mitigation. The Mt. Gox auditor's account had exchange-admin privileges that violated the principle of least privilege — an auditor should have read-only access to exchange data, not the ability to modify internal account balances and execute trades. The access-control failure is the canonical T15.003 surface that the principle of least privilege is designed to eliminate. Contributors writing T15.003 mitigation guidance should reference the Mt. Gox auditor-account case as the canonical worked example of least-privilege violation at the exchange-operations layer.

Realised extraction

Approximately 2,000 BTC attempted at a manipulated price of $0.01/BTC (~$30K–$60K at then-prevailing market prices). The attacker successfully withdrew at least some BTC to external addresses before Mt. Gox halted withdrawals; the precise amount is disputed in contemporaneous sources. Mt. Gox absorbed the financial loss and restored affected user accounts through the trade rollback. No material permanent loss to Mt. Gox users.

References

Mt. Gox operational incident disclosure (June 2011) — primary-source exchange-side communication regarding the auditor-account compromise, trading halt, transaction rollback, and service restoration.
Bitcoin Talk forum community discussion threads on the Mt. Gox June 2011 incident — primary-source community response, user reports of affected account balances, and contemporaneous forensic analysis.
examples/2010-07-mtgox-bitcoin-exchange-launch.md — Mt. Gox Bitcoin exchange launch (2010-07) — the infrastructure-genesis event; the Mt. Gox operational surface that was attacked in June 2011.
examples/2014-02-mt-gox.md — Mt. Gox exchange collapse (2014-02) — the terminal T11.001 + T15.003 event at Mt. Gox; the exchange's ultimate failure following years of progressive operational compromise.
[mtgox2011incident] — contemporaneous press coverage of the Mt. Gox June 2011 security incident (proposed bib key; see below).
[karpeles2019verdict] — Tokyo District Court verdict in the Mark Karpelès criminal case (March 2019); relevant context for Mt. Gox's operational security posture during the exchange's operational period (2010–2014).

Proposed new BibTeX entries

@misc{mtgox2011incident,
  author = {{Mt. Gox}},
  title = {Mt. Gox Security Incident — June 19, 2011 Auditor Account Compromise},
  year = {2011},
  month = jun,
  note = {Earliest documented exchange-access-level compromise in the Bitcoin ecosystem; auditor account credential compromise enabled price manipulation to $0.01/BTC; ~2,000 BTC attempted extraction; incident contained via trading halt, transaction rollback, and withdrawal freeze. Canonical T15.003 + T15.004 exchange-operational-compromise archetype.},
}