Coincheck exchange hot-wallet theft — NEM / XEM — 2018-01-26

Summary

On January 26, 2018, the Tokyo-based exchange Coincheck detected an unauthorised outflow of approximately 523 million XEM (~$530M at the incident-time market rate) from its NEM hot wallet. The hot wallet was the single storage surface for Coincheck's customer XEM holdings: the exchange did not segregate balances into cold storage and did not use NEM-native multisignature protection, despite both controls being available on the NEM protocol at the time. Per Coincheck's public statements and Japanese press reporting, the proximate vector was compromise of the hot-wallet private key after a Coincheck employee opened a phishing email that delivered malware onto a workstation with key-handling access. A single attacker-controlled XEM address received the entire stolen balance.

The event has three characteristics that make it the canonical pre-T11-era Japanese-jurisdiction worked example:

1. The structural failure is operator-side custody design, not a clever on-chain exploit. NEM's multisig and the option to hold the bulk of customer XEM in cold storage were both available; Coincheck used neither. Defenders reading this case should treat the absence-of-multisig and absence-of-cold-storage as the load-bearing failures, with the phishing-and-malware vector as the proximate trigger that any sufficiently determined attacker would have eventually found.
2. The on-chain manifestation was a single-cluster extraction with no laundering hop available at speed. XEM had limited DEX / cross-chain liquidity in 2018; the attacker held the funds and laundered them slowly over years through OTC venues and dark-web marketplaces, while the NEM Foundation's auto-tagging system marked the stolen tokens on-chain. This is materially different from the post-2022 Lazarus laundering pattern (THORChain / cross-chain bridges at Bybit-scale speed).
3. The off-chain regulatory consequences shaped the entire Japanese exchange-licensing regime. The case directly produced FSA on-site inspections, business-improvement orders against multiple exchanges, and the formalisation of Japan's exchange-registration regime under the Payment Services Act — the most consequential exchange-hack-driven regulatory shift on the public record at the time.

Timeline (UTC unless noted)

When	Event	OAK ref
Pre-event	Coincheck stores all customer XEM in a single internet-connected hot wallet without NEM-native multisig and without cold-storage segregation	(operator-side custody design)
Pre-event (likely weeks before)	Phishing email delivered to Coincheck staff; malware lands on a workstation with NEM hot-wallet key-handling access	(off-chain entry vector — no exact OAK v0.1 match)
2018-01-26 ~02:57 JST	Anomalous outbound transactions from Coincheck's NEM hot wallet to attacker-controlled XEM address; ~523M XEM extracted	T5-equivalent (extraction event)
2018-01-26 ~12:07 JST	Coincheck detects the unauthorised outflow	(defender detection — ~9 hours after extraction)
2018-01-26 evening	Coincheck halts NEM trading and announces the loss in a press conference at ~23:30 JST	(operator response and disclosure)
2018-01-26 same day	Japanese Finance Bureau orders Coincheck to submit a report	(regulatory response)
2018-01-27	NEM Foundation deploys an automated tagging system marking stolen XEM on-chain to support exchange-side blocking	Mitigation — issuer-side on-chain tagging response (not a TAXONOMY-GAPS candidate; an attack-Technique gap, not a Mitigation gap)
2018-01-29	Japan FSA issues business-improvement order to Coincheck	(regulatory)
2018-02-02	FSA conducts on-site inspection ("raid") of Coincheck offices	(regulatory)
2018-03-02	FSA on-site inspection of Coincheck — second wave	(regulatory)
2018-03-08	Local Finance Bureaus issue business-improvement orders to seven exchanges including Coincheck	(regulatory)
2018-03-12	Coincheck begins JPY reimbursements at 88.549 yen per XEM (~$0.83) to ~260,000 affected users; resumes partial trading	(recovery — corporate-funded, off-chain)
2018-04 onward	Attacker fragments and launders XEM through OTC venues and dark-web marketplaces over a multi-year window	(laundering — no OAK v0.1 Technique cleanly captures the OTC / dark-web rail used at this scale)
2021-03	Japanese police arrest individuals in Japan who had knowingly received laundered XEM at a discount	(downstream law-enforcement)
Various	Industry forensic providers (Chainalysis, Group-IB, others) attribute the Coincheck cluster to DPRK / Lazarus over subsequent years	G01 attribution (inferred-strong)

What defenders observed and learned

• Multisig and cold-storage segregation are non-optional for exchange-scale balances of any single asset. The structural lesson is bluntly simple: holding hundreds of millions of dollars of a single token in one internet-connected wallet, on a protocol that natively supports multisig, with no cold-storage segregation, is a custody-design failure independent of whatever phishing-and-malware vector ultimately triggered the loss. The Coincheck case is the canonical OAK reference for this lesson at exchange scale.
• Issuer-side on-chain tagging works at protocol level but does not stop OTC / dark-web laundering at long horizons. The NEM Foundation's auto-tagging system was a fast and impressive issuer-side response — by the next day, every exchange running a NEM node could see which incoming deposits were tagged. This drove most centralised-exchange laundering paths to closure within days. It did not stop the attacker from fragmenting the holdings through OTC / dark-web venues over years. Defenders writing issuer-side incident-response runbooks should treat tagging as necessary but insufficient at long laundering horizons; this is the canonical pre-DEX-era reference point for the limit.
• Detection lag at the 9-hour scale is a structural problem at exchange-scale hot wallets. Coincheck's detection lag (~9 hours between extraction and operator awareness) was driven by absence of real-time hot-wallet egress alerting tied to balance thresholds. The post-2020 industry baseline for such alerting is minutes, not hours; the Coincheck case is the canonical reference for why exchange operations runbooks must include real-time hot-wallet-egress alerting as a non-optional control.
• Off-chain regulatory consequence is part of the defender model. The FSA inspections, business-improvement orders, and the formalisation of Japan's exchange-registration regime under the Payment Services Act all flowed from this single event. Defenders writing exchange-ops or risk-management runbooks in Japanese-jurisdiction or Japanese-customer contexts should treat the post-Coincheck FSA regime as the operating environment; the case shaped it.

What this example tells contributors writing future Technique pages

• Operator-internal hot-wallet key compromise remains a real entry-vector class that OAK v0.1 does not have a Technique for. Coincheck and KuCoin sit in the same gap. Both involve compromise of the operator's own internal-IT environment to extract operator-held hot-wallet keys; neither is captured by T11.001 (third-party signing vendor), T11.002 (wallet-software distribution), or T11.003 (in-use multisig manipulation). Contributors should not stretch T11.001 to cover internal-IT compromise. The OAK convention from the KuCoin and Bybit examples applies here: document the off-chain / non-on-chain entry vector in the worked example; do not invent an on-chain Technique. A future v0.x update should consider adding a T11.x sub-technique covering operator-internal hot-wallet key compromise — Coincheck and KuCoin would be the two canonical anchor cases.
• inferred-strong is the right attribution marker for Coincheck. No FBI / Treasury / DOJ public statement names Coincheck as a Lazarus-attributed event at the OAK v0.1 cutoff. Industry forensic providers and Japanese authorities have published attributions; the OFAC SDN designation of Tian Yinyin and Li Jiadong on March 2, 2020 ([treasuryofac2020], Treasury press release SM924) sanctioned two Chinese-national financial facilitators of Lazarus-laundered cryptocurrency proceeds across the 2017–2019 window without naming Coincheck specifically. By OAK convention the case is inferred-strong, not confirmed. Contributors writing other 2017–2019 OAK-G01 cases should expect this — the FBI / Treasury attribution surface for crypto-specific events accelerated post-2022, and many earlier incidents remain industry-forensic-attributed only.
• Recovery accounting in the worked example must distinguish on-chain recovery from corporate-funded reimbursement. Coincheck reimbursed users from corporate funds in JPY; this is a customer-protection outcome but it is not on-chain recovery and it is not a recoverability signal that generalises (it depended on Coincheck having corporate balance-sheet capacity to absorb the loss). Contributors writing future exchange-hack examples should call out the funding source of any reimbursement explicitly; conflating "users made whole" with "funds recovered" mis-prices recoverability as an industry property.

Public references

• [coincheckpostmortem2018] — Coincheck official disclosure timeline and reimbursement accounting.
• [japanfsa2018coincheck] — Japan FSA business-improvement orders and on-site-inspection record (Jan–Mar 2018).
• [nemfoundationtagging2018] — NEM Foundation post on the auto-tagging system deployed against the stolen XEM cluster.
• [chainalysiscoincheck2018] — Chainalysis primary attribution / wallet-cluster work on the Coincheck theft.
• [chainalysis2024dprk] for cumulative OAK-G01 / DPRK-attributed totals context (Coincheck included in cumulative figures).
• [treasuryofac2020] — U.S. Treasury OFAC SDN designation of Tian Yinyin and Li Jiadong, March 2, 2020 (Treasury press release SM924, https://home.treasury.gov/news/press-releases/sm924). The designation sanctions two Chinese-national financial facilitators of Lazarus-laundered cryptocurrency proceeds across the 2017–2019 window; the press release does not name Coincheck. Cited for OAK-G01 laundering-network context; the absence of a Coincheck-by-name reference is why this example remains inferred-strong rather than confirmed.

Discussion

Coincheck is the canonical OAK example of a regulator-shaping exchange hack — the case that drove the formalisation of Japan's exchange-licensing regime under the Payment Services Act and set the post-2018 FSA on-site-inspection cadence for Japanese-jurisdiction exchanges. The KuCoin case (2020) is OAK's canonical example of a high-recovery industry-coordinated response; Bybit (2025) is OAK's canonical example of a third-party-vendor supply-chain compromise; Coincheck (2018) is OAK's canonical example of what happens when a single-asset hot-wallet design failure interacts with the regulatory environment of a major exchange jurisdiction at a moment when that regulatory environment is still being defined. Contributors writing future jurisdiction-specific worked examples (Japan, Korea, US, Singapore, EU) should treat Coincheck as the model for how a single event can shape the operating environment for an entire jurisdiction's exchange industry for years afterward.

The multi-year recovery / laundering timeline is also instructive. Unlike KuCoin (~7 weeks to ~84% recovery) or Bybit (laundering visibly tracked at days-to-weeks scale through THORChain), the Coincheck stolen XEM was laundered slowly over years through OTC and dark-web venues, with Japanese law-enforcement actions only producing arrests in 2021 — three years after the event. The slow horizon reflects (1) NEM's limited DEX / cross-chain liquidity in 2018, which forced attackers off the centralised-exchange rails the NEM Foundation's tagging system had effectively closed, and (2) the pre-DeFi-era absence of cross-chain bridges at the scale that now anchors Lazarus laundering. Contributors writing OAK-G01 historical-pattern pages should treat Coincheck as the defining case of the pre-cross-chain-bridge laundering era: the slow-horizon, OTC-and-dark-web-rail pattern that dominated DPRK crypto laundering before THORChain-class bridges and post-2022 DeFi mixers became the dominant rails. The shift from the Coincheck-era pattern to the Bybit-era pattern is one of the clearest temporal arcs in the OAK-G01 record, and Coincheck is the anchor at the early end of that arc.

Finally, the case illustrates the same OAK v0.1 Technique-taxonomy limit that KuCoin illustrates: there is no clean Technique surface for operator-internal hot-wallet key compromise in the T11 custody-and-signing family. A future v0.x update should consider adding a T11.x sub-technique covering this entry-vector class; Coincheck and KuCoin would be the two canonical anchor cases, separated by 32 months and roughly two orders of magnitude of industry-response maturity, both showing the same structural gap.