Loss: approximately 4,736.42 BTC (~$64M at the time of the event; ~$300M+ at 2024 BTC prices). The bulk of NiceHash's hot-wallet float held against pending miner payouts. Recovery: off-chain and operator-funded — NiceHash committed publicly to repaying all affected users in full and, per the company's continuing user-repayment programme, completed customer reimbursement in full by approximately 2020-12 (per CEO Martin Škorjanc's December 2020 announcement that the repayment programme had concluded). On-chain recovery: none directly attributable; the stolen BTC was laundered through chain-hopping and mixer routing in the months and years following the event. Insurance coverage was a partial offset against the corporate cost; the bulk of the repayment was operationally funded from NiceHash's continuing marketplace revenue. OAK Techniques observed: OAK-T15.003 (Operator endpoint compromise — single engineer's workstation with credentials and operational access to NiceHash's wallet-management infrastructure) + OAK-T15.001 (Social-engineering of operator personnel; consistent with OAK-G01 entry-vector pattern) for the off-chain pre-positioning phase. On-chain manifestation: OAK-T11.002 (wallet-software / signing-infrastructure host compromise). Downstream: OAK-T7.001 (mixer-routed laundering), OAK-T8.001 (cluster reuse). Attribution: inferred-strong — South Korean intelligence (NIS) attributed the case to North Korean state-aligned actors in 2018 reporting; subsequent industry-forensic corroboration (Chainalysis, Recorded Future) and the broader OFAC-adjacent activity attributed to the same DPRK cluster across the 2017–2018 wave place NiceHash within the OAK-G01 / Lazarus cohort. No DOJ indictment names the NiceHash 2017 case specifically at the OAK v0.1 cutoff. OAK-Gnn: OAK-G01 Lazarus Group / DPRK-attributed. Key teaching point: single-engineer-workstation compromise → wallet-management-infrastructure access is the canonical 2017-era T11.002 pattern; the operational gap is that a single engineer's endpoint held both credentials and active access to wallet-management infrastructure with no out-of-band approval requirement on hot-wallet movement. The case is the canonical T11 reference for the 2017 cohort and a direct structural antecedent of the post-2020 supply-chain-via-engineer-endpoint compromises (Atomic Wallet 2023, the Safe{Wallet} signing-vendor surface in Bybit 2025) where the load-bearing access surface is, again, an engineer's endpoint with operational reach into custody infrastructure.
NiceHash, headquartered in Maribor, Slovenia, operated (and continues to operate) one of the largest cryptocurrency-mining marketplaces in the world — a hashrate-marketplace platform where miners sell their hashpower to buyers paying in BTC, with NiceHash holding pending-payout BTC balances on behalf of its miner customers. On 2017-12-06 NiceHash suffered a hot-wallet compromise that drained approximately 4,736.42 BTC (~$64M at the time) from its operational wallet — the bulk of pending miner-payout balances at the moment of the event. NiceHash detected the loss the same day, suspended operations, announced the breach publicly, and engaged Slovenian and international law enforcement (FBI cooperation was publicly acknowledged) on incident response.
Per the company's subsequent public statements and per industry-forensic reporting, the proximate entry vector was compromise of a single NiceHash engineer's workstation. The compromised endpoint held credentials and operational access to NiceHash's wallet-management infrastructure; once the attacker reached the engineer's endpoint via spear-phishing-led malware delivery (the candidate vector per contemporaneous reporting; NiceHash did not publish a fully detailed technical post-mortem), lateral movement to the wallet-management infrastructure produced authorised hot-wallet withdrawals consolidating the stolen BTC to attacker-controlled addresses.
For OAK's purposes the NiceHash 2017 case is the canonical T11.002 worked example for the 2017 cohort. The structural pattern — single engineer endpoint with operational access to wallet-management infrastructure → endpoint-side compromise → lateral movement to wallet-management host → authorised-from-the-signing-host withdrawals — is the same structural pattern that surfaces in Bitstamp 2015 (administrator endpoint), KuCoin 2020 (operator endpoint with hot-wallet key access), DMM Bitcoin 2024, and WazirX 2024. The technical specifics differ across the lineage, but the structural failure mode is identical, and contributors writing T11.002 Technique pages should treat the 2015 → 2024 lineage as evidence that the pattern has been an unaddressed exchange-and-marketplace-side risk for nearly a decade.
The case is also operationally distinct from most exchange-hack worked examples in OAK's corpus along the user-recovery axis: NiceHash committed publicly to repaying all affected users in full, established a continuing repayment programme funded from marketplace revenue, and completed full repayment by approximately 2020-12. The operator-funded full-repayment outcome is rare at this loss magnitude and worth documenting as one of the canonical exchange-recovery patterns.
| When | Event | OAK ref |
|---|---|---|
| Pre-event (2017-11 to 2017-12) | Spear-phishing-led malware delivery against a NiceHash engineer's workstation; the affected endpoint held credentials and operational access to wallet-management infrastructure. The exact entry vector was not publicly disclosed in technical detail | T11.002 entry — engineer-endpoint compromise |
| 2017-12-06 | Attacker reaches NiceHash wallet-management infrastructure via lateral movement from the compromised engineer endpoint; issues authorised hot-wallet withdrawals draining |
T11.002 extraction — wallet-management infrastructure access |
| 2017-12-06 | NiceHash detects the loss, suspends operations, announces the breach publicly; CEO Marko Kobal and engineering team brief affected users via livestream and continuing public updates | (operator detection / disclosure) |
| 2017-12-06 onward | Slovenian police investigation initiated; NiceHash publicly acknowledges FBI cooperation on incident response | (law-enforcement engagement) |
| 2017-12 onward | Stolen BTC laundered through chain-hopping and mixer routing in the months following the event | T7-class long-tail laundering |
| 2018 onward | South Korean NIS attribution of the 2017–2018 South-Korea / Slovenia / global crypto-targeting wave to North Korean state-aligned actors covers the NiceHash event in the cohort | G01 attribution — inferred-strong |
| 2018-01 | NiceHash announces user-repayment programme: pending-payout balances at the moment of the breach to be repaid in full from continuing marketplace revenue | (recovery — operator-funded) |
| 2017-12-22 | NiceHash partially resumes operations | (operational recovery) |
| 2018 to 2020 | NiceHash continues incremental user-repayment as a fixed share of marketplace revenue is allocated to the repayment programme | (recovery — sustained) |
| 2020-12 | NiceHash CEO Martin Škorjanc announces that the user-repayment programme has concluded; affected users repaid in full | Recovery — fully completed, operator-funded |
- Pre-event: the load-bearing failure was that a single engineer's endpoint held both credentials and active operational access to wallet-management infrastructure capable of authorising hot-wallet withdrawals at the volumes involved. A defender writing a custody-infrastructure runbook should treat "any single engineer endpoint with operational reach to authorise hot-wallet withdrawals" as a primary control to fix; the post-2020 industry baseline of out-of-band approval workflows for hot-wallet movement, hardware-token-mediated signing access, and just-in-time / break-glass elevation rather than persistent operator access is retro-engineered against precisely this failure shape.
- At-event: detection happened approximately at the moment of the drain, not before. There is no public-record indication that the lateral movement from the engineer endpoint to the wallet-management infrastructure was caught by an internal-network detection capability; the detection signal was the hot-wallet egress itself. The post-2020 industry baseline of internal-network anomaly detection on lateral movement to custody-adjacent infrastructure is, again, retro-fit against this gap.
- Post-event (recovery side): NiceHash's full operator-funded repayment programme is one of the canonical exchange-recovery patterns OAK documents. The mechanics — public commitment to full repayment within days of the event, allocation of a fixed share of continuing marketplace revenue to the repayment programme, public-progress disclosure across the multi-year repayment window, full completion by approximately 2020-12 — produced a complete user-make-whole outcome from operator earnings rather than from on-chain recovery, insurance pay-out, or socialised-loss mechanism. This is the simplest shape of the four canonical exchange-recovery patterns OAK documents (corporate-funded reimbursement; cf. Coincheck 2018 and Bitstamp 2015, where the same model recurs at different loss magnitudes).
- Post-event (attribution side): the South Korean NIS attribution and subsequent industry-forensic corroboration place NiceHash within the OAK-G01 / Lazarus cohort, but no DOJ indictment names the case specifically at the OAK v0.1 cutoff. Defenders writing operator-accountability or law-enforcement-cooperation analyses should treat this attribution surface — South Korean intelligence finding plus industry-forensic corroboration, no DOJ naming — as the typical pattern for pre-2022 G01-attributed events.
- NiceHash 2017 is the canonical T11.002 worked example for the 2017 cohort and should be cross-referenced from the T11.002 Technique page. The structural pattern — single engineer endpoint with operational access to wallet-management infrastructure → endpoint-side compromise → lateral movement to the wallet-management host → authorised-from-the-signing-host withdrawals — is the same structural pattern that surfaces in Bitstamp 2015, KuCoin 2020, DMM Bitcoin 2024, and WazirX 2024. Contributors writing T11.002 pages should treat the 2015 → 2024 lineage as a continuous historical record of the same structural failure mode, and treat NiceHash 2017 as the 2017-era anchor for that lineage.
inferred-strongattribution is the right marker for NiceHash 2017. The same attribution-surface pattern that applies to KuCoin 2020 applies here: South Korean NIS finding plus industry-forensic corroboration (Chainalysis, Recorded Future), no DOJ / Treasury naming. Contributors writing the OAK-G01 actor page or G01-attributed worked examples should expect this surface for pre-2022 cases and should preserve theinferred-strongmarker rather than over-claiming aconfirmedattribution that the public record does not support.- The operator-funded full-repayment recovery mechanism is its own analytic shape. The four canonical exchange-recovery patterns OAK documents — corporate-funded reimbursement (Bitstamp 2015, NiceHash 2017, Coincheck 2018), socialised-loss-with-equity-token instrument (Bitfinex 2016), cold-storage-funded reimbursement-from-reserves (KuCoin 2020 with insurance fund supplementing recovered fraction), creditor-claim civil-rehabilitation with in-kind distribution (Mt. Gox 2014–2025) — are operationally distinct, and contributors writing future exchange-hack worked examples should describe the funding source, instrument, and conversion mechanics with the same care that on-chain extraction mechanics get. NiceHash 2017 is the cleanest available reference for the corporate-funded full-repayment pattern at this loss magnitude.
- The CEO-claim-of-partial-recovery framing is a documentation discipline matter. NiceHash's public communications across 2018–2020 framed the recovery in terms of cumulative-percentage-of-affected-users repaid; this is an accurate and useful framing for the user-side recovery posture, but contributors should distinguish it from on-chain recovery (which did not occur for the stolen BTC). Conflating the two — the documentation gap that the OAK convention from Coincheck 2018 calls out — would mis-price recoverability as an industry property. The NiceHash case should be documented as: full user-side repayment from operator-funded mechanism + zero on-chain recovery of the stolen BTC.
[nicehashpress2017]— NiceHash d.o.o. Statement on the 6 December 2017 security breach. 2017-12-06 onward; primary-source operator disclosure across the breach response, repayment programme rollout, and continuing repayment-progress updates.[nicehashrepayment2020]— NiceHash d.o.o. / Martin Škorjanc. NiceHash Repayment Program — completion announcement. 2020-12; primary-source operator confirmation that the user-repayment programme has concluded.[reutersnicehash2017]— Reuters. Slovenian crypto firm NiceHash hacked, possibly losing tens of millions in bitcoin. 2017-12-06 / 2017-12-07; contemporaneous press coverage of the breach disclosure.[coindesknicehash2017]— CoinDesk. NiceHash CEO Confirms $60+ Million Loss in Hack Attack. 2017-12; contemporaneous press coverage including the hot-wallet-drain magnitude and operator-response posture.[chainalysisnicehash2018]— Chainalysis primary forensic walk-through of the NiceHash laundering cluster; cross-references the OAK-G01-attributed cohort and the chain-hopping / mixer-routing pattern observed in the months following the event.[recordedfuturedprkfinancial2018]— Recorded Future. North Korea Targeting of cryptocurrency exchanges and adjacent infrastructure. 2018; industry-forensic attribution covering the cohort that includes NiceHash 2017.
NiceHash 2017 is the OAK record's canonical T11.002 worked example for the 2017 cohort. The case demonstrates, at exchange-and-marketplace scale and in primary-source detail, the structural failure mode that defines T11.002: a single engineer's endpoint with persistent operational access to wallet-management infrastructure produces authorised hot-wallet withdrawals once the endpoint is compromised, and the technical-control surface downstream of the endpoint compromise (wallet-management software, signing host, withdrawal-authorisation pipeline) is contingent on the endpoint-side compromise that started it. The operational specifics differ across the lineage — Bitstamp 2015 used Word VBA macros delivered via Skype against an administrator; NiceHash 2017's vector was spear-phishing-led malware delivery against an engineer; KuCoin 2020's vector was internal-IT compromise of an operator endpoint with hot-wallet key access; DMM Bitcoin 2024 and WazirX 2024 reached signing infrastructure through similar engineer-endpoint paths — but the structural failure mode is identical. Contributors writing T11.002 pages should treat this lineage as the load-bearing historical record of the technique class.
The South Korean cohort context matters for OAK's attribution discipline. The 2017–2018 OAK-G01-attributed wave includes Bithumb 2017 (chained-operation), Coinrail 2018-06 (hot-wallet drain), Bithumb 2018-06 (hot-wallet drain), and the Slovenia-targeted NiceHash 2017-12 (hot-wallet drain) — the geographic centre of mass is South Korean exchanges but the cluster's tradecraft reaches Slovenia in this case. The attribution is inferred-strong rather than confirmed because the South Korean NIS finding and the industry-forensic corroboration are the load-bearing public-record evidence, with no DOJ indictment naming the case specifically at the OAK v0.1 cutoff. Contributors writing the OAK-G01 actor page should preserve the inferred-strong marker and the cohort framing — the case is operationally part of the cluster's 2017–2018 tradecraft surface, but the public-record attribution does not support the confirmed standard OAK reserves for cases with FBI / DOJ / Treasury naming.
The full operator-funded repayment outcome deserves to be flagged as a structurally distinctive recovery shape. The canonical exchange-recovery patterns OAK documents are: corporate-funded reimbursement at hot-wallet-loss-fully-absorbed scale (Bitstamp 2015 at ~$5M, NiceHash 2017 at ~$64M, Coincheck 2018 at ~$530M with corporate plus owner-funded reimbursement); socialised-loss-with-equity-token instrument (Bitfinex 2016); cold-storage-funded-reimbursement-from-recovered-fraction-plus-insurance (KuCoin 2020); and creditor-claim civil-rehabilitation with in-kind distribution (Mt. Gox 2014–2025). NiceHash 2017 sits at the upper end of the corporate-funded-reimbursement scale before the Coincheck 2018 owner-funded repayment shifts the magnitude axis upward. Contributors writing future exchange-hack worked examples in which the recovery mechanism is operator-funded should reference NiceHash 2017 as the canonical mid-magnitude case for the pattern.
Finally, the partial-recovery-via-insurance framing the original task brief flagged deserves a careful treatment. NiceHash's full repayment programme was funded operationally — from continuing marketplace revenue allocated to the repayment programme — rather than from insurance pay-out as the load-bearing mechanism. Insurance coverage existed and provided some offset against the corporate cost, but the repayment outcome did not depend on the insurance side; the operationally-funded share is the dominant component of the pay-out. Contributors writing the case should not present "partial recovery via insurance" as the headline recovery mechanism; the headline mechanism is operator-funded full repayment, with insurance as a partial corporate-cost offset. This distinction matters because it makes NiceHash 2017 a cleanly operator-earnings-funded case rather than an insurance-mediated one — and the operator-earnings-funded shape is rare at this loss magnitude and worth preserving in the OAK record as the structurally distinctive feature of the recovery.