Worked example · 2025-07

CoinDCX operational-wallet drain — Solana — 2025-07-19

Loss: approximately $44.2M in USDC and USDT extracted from a CoinDCX operational wallet on the Solana blockchain on 2025-07-19. CoinDCX is one of India's largest cryptocurrency exchanges, headquartered in Mumbai. The compromised wallet was an internal operational liquidity-provisioning wallet used for inter-exchange routing with a partner exchange, not a customer-facing custody surface — customer cold-wallet reserves were not affected, and CoinDCX confirmed that user balances would be made whole from operator reserves.
Recovery: none publicly disclosed at the on-chain layer at the v0.1 reporting horizon; CoinDCX absorbed the loss against operational reserves and committed to user-fund coverage. No public DOJ, CBI (Indian Central Bureau of Investigation), or allied-government civil-forfeiture action has been filed as of the date of this example.
OAK Techniques observed: OAK-T11 broadly construed — the entry vector was operator-side server-infrastructure compromise yielding access to an internal liquidity-provisioning wallet's signing authority. The novel feature relative to the broader 2024–2025 OAK-G01 cohort is that the compromise targeted back-end infrastructure (CoinDCX's server-side systems supporting inter-exchange liquidity routing) rather than (a) operator-internal hot-wallet key-storage co-location (Phemex, Indodax, BingX) or (b) third-party signing-vendor compromise (DMM via Ginco, WazirX via Liminal, Bybit via Safe{Wallet}). Downstream Techniques observed on-chain: OAK-T7.001 (Mixer-Routed Hop — Tornado Cash on Ethereum, used by the attacker for receiving-address gas pre-funding before the extraction) and OAK-T7.003 (Cross-Chain Bridge Laundering — Solana → Ethereum bridging via Wormhole; Jupiter aggregator used for in-Solana asset rotation prior to bridging).
Attribution: inferred-strong — no FBI press release, U.S. Treasury OFAC designation, or Indian / Singaporean government public statement explicitly naming CoinDCX has been published as of the date of this example. Attribution is carried by industry forensic providers and analyst commentary: Merkle Science, ZachXBT, and the broader on-chain analyst community converged on a Lazarus-style attack-shape attribution within days, on the basis of (a) the receiving-address gas pre-funding from Tornado Cash, (b) the Solana → Ethereum cross-chain bridging via Wormhole and Jupiter (TTPs characteristic of the 2024–2025 OAK-G01 laundering rail), and (c) the deep operational understanding of inter-exchange liquidity-routing infrastructure required to identify and target the specific wallet. By OAK convention this clears the inferred-strong bar — multi-firm TTP-pattern concurrence, even without an explicit cluster-overlap reconstruction to a confirmed-grade case at the v0.1 reporting horizon. Should subsequent forensic work produce explicit cluster-overlap evidence to a confirmed OAK-G01 case, this example should be upgraded to fully cluster-confirmed inferred-strong.
OAK-Gnn: OAK-G01 Lazarus Group / TraderTraitor / DPRK-attributed — inferred-strong via TTP-pattern concurrence on Tornado Cash receiving-funding, Solana → Ethereum bridging, and back-end-infrastructure-compromise sophistication.
Key teaching point: back-end infrastructure compromise of liquidity-provisioning wallets is a third distinct entry-vector axis within the OAK-T11 family, alongside (a) operator-internal hot-wallet key-storage co-location and (b) third-party signing-vendor compromise. The CoinDCX July 2025 case is the canonical 2025 worked example for this axis: the compromise targeted neither the customer-custody surface nor the third-party signing-vendor surface, but instead the operator's own server-side infrastructure supporting inter-exchange liquidity-routing operations. Defenders running exchange custody should explicitly enumerate the back-end-liquidity-infrastructure surface as a separate threat-model class, with its own access-control, key-rotation, and monitoring requirements — not as a sub-component of customer-custody monitoring.

Summary

CoinDCX is one of India's largest centralised cryptocurrency exchanges, founded in 2018 and headquartered in Mumbai. The exchange operates under the Indian regulatory regime and serves several million Indian users across spot and derivatives products. As part of normal operations, CoinDCX maintains internal operational wallets for inter-exchange liquidity routing — i.e., wallets that hold operator-controlled balances used to provision liquidity to partner exchanges as needed for cross-venue arbitrage and order-routing. These wallets sit on the exchange's back-end infrastructure and are functionally separate from the customer-facing custody surface.

On 2025-07-19, CoinDCX publicly disclosed a security incident affecting one such operational wallet on the Solana blockchain. Approximately $44.2M in USDC and USDT was siphoned from the affected wallet to attacker-controlled receiving addresses. Per Merkle Science's flow-of-funds analysis, the receiving address had been pre-funded with one ETH from Tornado Cash before the extraction — a forensic signal of coordinated planning. After the extraction, the attacker rotated assets within Solana (using the Jupiter swap aggregator) and then bridged a portion of the proceeds to Ethereum via Wormhole.

The breach was first publicly identified by ZachXBT, who flagged the incident on Telegram approximately 17 hours after the on-chain manifestation, manually identifying the affected wallet as belonging to CoinDCX before the operator's public disclosure. CoinDCX CEO Sumit Gupta subsequently confirmed the breach as a "server breach" — i.e., a back-end-infrastructure compromise rather than a customer-custody-surface compromise. The exchange committed to absorbing the full loss from operator reserves; customer-cold-wallet balances were unaffected.

For OAK's purposes the entry vector is off-chain and operator-internal, but with the novel feature of targeting back-end liquidity-provisioning infrastructure rather than the customer-custody surface. OAK v0.1 does not have an on-chain Technique that captures this entry vector cleanly; the case is documented here in the worked-example layer because the on-chain manifestation, the laundering chain, the back-end-infrastructure root cause, and the OAK-G01 TTP-pattern attribution are all on the public record.

The OAK-G01 attribution rests on TTP-pattern concurrence: (a) receiving-address gas pre-funding from Tornado Cash, (b) Solana → Ethereum cross-chain bridging via Wormhole and Jupiter (TTPs characteristic of the 2024–2025 OAK-G01 laundering rail), and (c) the deep operational understanding of inter-exchange liquidity-routing infrastructure required to identify and target the specific wallet. Industry analysts noted that this third element is not a standard pseudonymous-DeFi-exploit attacker capability — it requires either insider knowledge of CoinDCX's specific infrastructure or extended reconnaissance through compromised credentials.

Timeline (UTC)

When	Event	OAK ref
Pre-event (~2025-07-12 onward)	CoinDCX server-side infrastructure compromise; attacker reconnaissance of inter-exchange liquidity-provisioning wallet	(off-chain entry vector — back-end infrastructure compromise)
Pre-event (early July 2025)	Attacker pre-funds Solana receiving address with 1 ETH bridged from Tornado Cash; address prepared for inflow	(attacker preparation; forensic signal of coordinated planning)
2025-07-19	Compromised liquidity-provisioning wallet drained: ~$44.2M in USDC and USDT directed to attacker-controlled receiving address	T5-equivalent (extraction event)
2025-07-19 onward	Attacker rotates assets within Solana via Jupiter swap aggregator; bridges portion to Ethereum via Wormhole	T7.003 (Cross-Chain Bridge Laundering) → T7.001 (Mixer-Routed Hop)
2025-07-19 (~17 hours post-extraction)	ZachXBT publicly identifies the affected wallet as belonging to CoinDCX; Telegram-channel disclosure precedes operator-side public statement	(external detection — ZachXBT)
2025-07-19 / 2025-07-21	CoinDCX publicly acknowledges incident; CEO Sumit Gupta characterises entry vector as "server breach"; commits to user-fund coverage from operator reserves	(operator response)
2025-07-19 onward	Merkle Science, Halborn, broader industry forensic surface publish post-incident analyses; TTP-pattern Lazarus-style attribution converges	G01 attribution (inferred-strong) via TTP-pattern concurrence
2025-07 onward	Customer-balance restoration coordinated; cold-wallet reserves unaffected	(recovery state)

What defenders observed

Back-end liquidity-provisioning infrastructure is a third distinct entry-vector axis within the OAK-T11 family. The CoinDCX case is structurally distinct from both (a) operator-internal hot-wallet key-storage co-location (Phemex, Indodax, BingX, BtcTurk) and (b) third-party signing-vendor compromise (DMM via Ginco, WazirX via Liminal, Bybit via Safe{Wallet}). The attacker did not target the customer-custody surface and did not target a third-party signing-vendor; the target was CoinDCX's own server-side infrastructure supporting inter-exchange liquidity routing. Defender runbooks for exchange custody should treat back-end liquidity-infrastructure as a separate threat-model class with its own access-control, key-rotation, and monitoring requirements.
Receiving-address gas pre-funding is a recurring forensic signal in 2024–2025 sophisticated theft cases. The CoinDCX receiving address was pre-funded with one ETH from Tornado Cash before the extraction — a pattern broadly consistent with the Infini February 2025 case (insider-credential compromise of stablecoin treasury) and several other 2024–2025 sophisticated theft cases. Defender investigators should treat receiving-address pre-funding patterns as a first-class forensic signal in custody-compromise cases; pre-funding signals deliberation and pre-meditation rather than opportunistic compromise.
External detection by ZachXBT preceded operator-side public disclosure by 17 hours. As with multiple 2024–2025 cases (DEXX, Indodax, BingX, BtcTurk), the load-bearing public-disclosure-timeline event was an external on-chain analyst's identification of the affected operator rather than the operator's own announcement. The defender / risk-team lesson is that operator-side initial-disclosure timelines should not be modelled as primary; the third-party-detection lead-time on 2024–2025 hot-wallet and infrastructure-compromise cases is consistently several hours to a full day ahead of operator acknowledgement.
Customer-custody segregation from operational liquidity wallets is a load-bearing protective control. CoinDCX's customer-cold-wallet balances were unaffected because the compromised wallet was a separate operational liquidity-provisioning surface, not part of the customer-custody flow. The realised loss was bounded above by the operational-wallet balance at the time of the compromise, not by the full exchange custody balance. Defender custody-architecture review should treat customer-custody-from-operational-wallet segregation as a primary control composing with key-storage segregation and access-control segmentation.
TTP-pattern attribution to OAK-G01 is suggestive but distinct from cluster-overlap attribution to a confirmed case. The CoinDCX attribution rests on TTP-pattern concurrence (Tornado Cash receiving-funding, Wormhole-via-Jupiter laundering, infrastructure-compromise sophistication) rather than on a published cluster-overlap reconstruction to a confirmed OAK-G01 case at v0.1's reporting horizon. Per OAK convention, TTP-pattern concurrence across multiple firms clears the inferred-strong bar; cluster-overlap to a confirmed case is a stronger evidentiary surface that may emerge in subsequent forensic work.

What this example tells contributors writing future Technique pages

CoinDCX is the canonical 2025 worked example of back-end-infrastructure-compromise as a third entry-vector axis within OAK-T11. Future T11 sub-Technique structure should distinguish (a) operator-internal hot-wallet key-storage compromise (KuCoin, Coincheck, Stake.com, Phemex, Indodax, BingX, BtcTurk), (b) third-party signing-vendor compromise (DMM, WazirX, Bybit), and (c) back-end-infrastructure compromise of liquidity-provisioning or operational wallets (CoinDCX). The three axes have distinct defender-control surfaces and should not be collapsed.
inferred-strong is the right marker for CoinDCX, with TTP-pattern concurrence as the evidentiary surface. Multiple industry analysts (Merkle Science, ZachXBT, Halborn) converged on Lazarus-style attribution within days. Per OAK convention this clears the inferred-strong bar. A downstream contributor should upgrade CoinDCX to cluster-overlap-confirmed inferred-strong (or to confirmed) if and only if subsequent forensic work produces cluster-overlap evidence to a confirmed OAK-G01 case (or a U.S. / allied government public statement explicitly names CoinDCX).
The Indian regulatory surface produces a different post-incident reporting profile than the U.S. or Singaporean surfaces. CoinDCX's post-incident communications, the absence of an Indian government public attribution at v0.1's reporting horizon, and the operator-side full-loss-coverage commitment (from operator reserves rather than via insurance or restructuring) are characteristic of the Indian regulatory environment. Contributors writing future Indian-exchange examples should expect this profile and not interpret the absence of a U.S.-style FBI / IC3 release as evidence against attribution.
Receiving-address gas pre-funding deserves explicit defender-handbook treatment as a 2024–2025 forensic-signal class. The CoinDCX, Infini, and other 2024–2025 sophisticated-theft cases share this signal. Contributors writing the OAK Mitigations layer should consider a cross-cutting Mitigation entry covering receiving-address pre-funding monitoring — i.e., the discipline of treating fresh-wallet pre-funding patterns from mixer rails as a first-class forensic signal in custody-compromise investigation.

Public references

CoinDesk — Indian Crypto Exchange CoinDCX Suffers $44M Hack — primary industry-press initial-disclosure coverage.
TechCrunch — Indian crypto exchange CoinDCX confirms $44 million stolen during hack — operator-side confirmation and CEO statement coverage.
Merkle Science — Hack Track: Inside the CoinDCX Exploit — primary forensic flow-of-funds analysis covering the receiving-address pre-funding pattern, the Solana → Ethereum bridging chain, and the back-end-infrastructure-compromise root cause.
Halborn — Explained: The CoinDCX Hack (July 2025) — independent post-incident technical write-up.
The Block — CoinDCX CEO blames 'server breach' for $44 million exploit — operator-side characterisation of the entry vector as a server breach.
DL News — CoinDCX hacker routes $46m into Ethereum after Lazarus-style attack — Lazarus-style TTP-pattern attribution coverage.
Cointelegraph — CoinDCX Hack: How Attackers Stole $44M Without Touching User Funds — explainer-format coverage of the operational-wallet-vs-customer-custody distinction.

Discussion

CoinDCX July 2025 is OAK's canonical 2025 worked example of back-end-infrastructure-compromise of an inter-exchange liquidity-provisioning wallet and one of the few 2025 cases that establishes a third distinct entry-vector axis within the OAK-T11 family alongside the established axes of (a) operator-internal hot-wallet key-storage compromise and (b) third-party signing-vendor compromise. The case is structurally important precisely because it sits outside the two established axes — the attacker did not target the customer-custody surface and did not target a third-party signing-vendor; the target was CoinDCX's own server-side infrastructure supporting inter-exchange liquidity routing.

The customer-custody-segregation lesson is the CoinDCX-specific load-bearing analytical contribution. CoinDCX's customer-cold-wallet balances were unaffected because the compromised wallet was a separate operational liquidity-provisioning surface, not part of the customer-custody flow. The realised loss was bounded above by the operational-wallet balance at the time of the compromise (~$44.2M), not by the full exchange custody balance (substantially larger). The defender / Mitigations-layer lesson is that customer-custody-from-operational-wallet segregation is a primary protective control: it bounds the realised loss in any operator-side compromise to the size of the compromised wallet rather than to the size of the full custody surface. Contributors writing future operator-side custody-compromise examples should record explicitly whether the compromised surface was a customer-facing or operational-only wallet, and whether the operator's architecture maintained segregation between the two.

The receiving-address gas pre-funding signal is the second CoinDCX-specific contribution. The pre-funding pattern (one ETH from Tornado Cash to the Solana receiving address before the extraction) is broadly consistent with the Infini February 2025 case (insider-credential compromise of stablecoin treasury) and a small number of other 2024–2025 sophisticated theft cases. The signal indicates coordinated planning rather than opportunistic compromise and may strengthen the case for criminal prosecution under jurisdictions where deliberation is an aggravating factor. Defender investigators should treat receiving-address pre-funding patterns as a first-class forensic signal.

The TTP-pattern attribution is the third CoinDCX-specific contribution. The 2024–2025 OAK-G01 wave is heavily attributed via cluster-overlap evidence to confirmed-grade cases (DMM via FBI/DC3/NPA, Bybit via FBI/IC3, WazirX via U.S.-Japan-ROK trilateral). CoinDCX July 2025 has TTP-pattern concurrence (Tornado Cash receiving-funding, Solana → Ethereum bridging, back-end-infrastructure compromise sophistication) but no published cluster-overlap reconstruction to a confirmed-grade case at v0.1's reporting horizon. The case anchors the proposition that TTP-pattern attribution is suggestive of cohort membership but distinct from the cluster-overlap evidence that the BingX, Phemex, and Bybit examples carry — and that inferred-strong is the right marker in the absence of cluster-overlap evidence, with subsequent forensic work potentially upgrading the attribution profile.

For OAK's broader credibility, including CoinDCX in v0.1 closes a structural gap between the established OAK-T11 sub-axes and adds the back-end-infrastructure-compromise axis as a first-class entry-vector class. Without CoinDCX, the 2024–2025 OAK-T11 corpus reads as a binary between operator-internal-key-compromise and third-party-vendor-compromise; with CoinDCX, the corpus is legible as a three-way axis with distinct defender-control surfaces.