Case study / Virtual digital asset exchange, India
CoinDCX: a $44 M recruitment-lure breach and the $16 M aftershock from unretired wallets
A fake freelance job put malware on one engineer's laptop and emptied a $44 M liquidity wallet; 15 months on, compromised addresses CoinDCX had deprecated but kept using lost 15.99 M USDT.
- Attacker (attributed)
- Unattributed; Cyvers noted Lazarus-style hallmarks, police probing foreign actors [8][14]
- Initial access
- Fake freelance job; bugged file on engineer's company laptop; private keys stolen [16]
What happened
In the early hours of Saturday 19 July 2025, an attacker emptied an internal account that CoinDCX used to provide liquidity on a partner exchange, taking roughly $44 million in stablecoins [1][5]. CoinDCX, operated by Bengaluru-based Neblio Technologies Pvt Ltd, is one of India's largest crypto exchanges, with more than 16 million users at the time, and is registered with the Financial Intelligence Unit-India [7][11]. The exchange said the compromised account was a hot wallet used solely for liquidity provisioning, that it was structurally separate from the cold wallets holding customer assets, and that no customer funds were touched [1][2]. It committed to absorbing the loss entirely from its own treasury, which it later described as more than $100 million in reserves [1][2].
The theft was not announced by the exchange first. On-chain investigator ZachXBT flagged the outflows on his Telegram channel roughly 17 hours after they began, estimating the loss at $44.2 million and noting that the attacker's address had been funded with 1 ETH from Tornado Cash before part of the proceeds was bridged from Solana to Ethereum [6][7]. Co-founder and CEO Sumit Gupta confirmed the incident on X within about 10 minutes of that post, describing it as a 'sophisticated server breach' [6]. CoinDCX later said it notified CERT-In on 19 July and engaged two external forensic agencies [1].
Within two weeks the Bengaluru police put forward a different account of the entry point. Officers from the Whitefield Cyber, Economic and Narcotics (CEN) police station arrested a CoinDCX software engineer, Rahul Agarwal, 30, after concluding that criminals posing as recruiters had lured him with a paid part-time job and used that relationship to install malware on his company-issued laptop [11][14]. Police said the attackers then used his access to reach the exchange's systems and move funds, and that early evidence suggested he was a 'mere tool' who was unaware of the theft [13]. The complaint filed by Neblio on 22 July valued the stolen assets at $44 million, or Rs 384 crore; The Hindu reported the figure as Rs 378.9 crore and Deccan Herald as Rs 385 crore [11][12][13].
The story did not end there. On 21 October 2026, fifteen months after the first breach, 15.99 million USDT left Tron addresses linked to CoinDCX [4][21]. The exchange initially said the addresses were old wallets compromised in July 2025 and no longer in use, and Gupta publicly called the reports a 'false alarm' [20][21]. Four days later CoinDCX confirmed the loss, saying its automated sweeping service had failed for a period, allowing user deposits to accumulate in deprecated infrastructure that still had 'unknown vulnerabilities', and that it had absorbed the 15.99 million USDT loss itself [4]. Across the two incidents, CoinDCX's reported losses now approach $60 million [22][23].
How they got in
The clearest public account of initial access comes from Karnataka's Criminal Investigation Department (CID), which took over the case and briefed The Hindu in January 2026 [16]. According to the CID, the engineer, who had worked at the exchange since May 2023, received a message in March 2024 on a professional networking site from a persona calling herself 'Sarah Ferguson', offering a paid freelance assignment to help build a website for a crypto exchange [16]. The conversation moved to another platform, the engineer was given access to a code repository, and he did the work on his employer's laptop [16].
What followed was a long confidence-building operation rather than a quick phish. The CID said the operators gave the engineer genuine development work, held regular online review meetings, sent files with suggested changes and paid him about Rs 15 lakh over more than a year, so that nothing looked suspicious [16]. The earlier police briefings described the same relationship more loosely as a 'job task' scheme involving tasks such as writing online reviews, and noted that he had first used his personal laptop before switching to the office machine at the operators' insistence [11][13]. The engineer told investigators he was unaware of any fraud and explained the money as income from a part-time job, which the company said breached its internal rules [12][13].
The payload arrived in July 2025 [16]. After one review meeting the operators sent a batch of files, one of which was 'bugged'; the engineer opened it, saw what appeared to be a dummy document and closed it, but it had already executed in the background and given the attackers full control of the laptop [16]. From that foothold the attackers learned that the engineer held administrative access to the company's servers and, according to the CID, stole the private keys [16]. Earlier, Cyvers chief executive Deddy Lavid had told DL News the breach likely stemmed from backend misconfigurations and exposed credentials [8]. CoinDCX's own description, that the attacker 'penetrated our liquidity infrastructure' through a server breach, is consistent with but less specific than the police version [1][6].
No security firm has formally attributed the July 2025 attack to a named group [8][14]. Cyvers told DL News the attack bore strong similarities to past exploits attributed to North Korea's Lazarus Group, citing cross-chain bridging, use of Tornado Cash and familiarity with exchange liquidity infrastructure, but stopped short of attribution [8]. Bengaluru police said they were examining the possibility of foreign actors, with responsibility not confirmed [14]. The recruitment-lure pattern is consistent with that assessment, but it remains an assessment.
How it escalated
The attackers rehearsed before they struck. Neblio's police complaint, as summarised by Deccan Herald and The Hindu, records a transfer of 1 USDT from the company's wallet to an unknown address at 2.37 am IST on 19 July (The Hindu gives 2.45 am), and the main transfer of roughly $44 million to six external wallets discovered when the company checked at 9.40 am [12][13]. The CID described the same sequence: a small transfer to confirm access, then the full balance [16]. That seven-hour gap was the window in which a withdrawal alert on a treasury-class account would have mattered most.
The compromised account was a hot wallet on Solana, holding USDC and USDT for liquidity provisioning on a partner venue, and it was not included in the exchange's published proof-of-reserves [9]. Because it was a legitimate operational account with legitimate withdrawal privileges, the attacker's transactions looked like the account's normal business; Lavid's assessment was that exposed credentials 'allowed large-scale transfers to go unnoticed' [8]. CoinDCX said that once its systems detected the anomaly the account was isolated, and that segregation between operational accounts and customer cold wallets limited exposure to that single account [1][2].
The October 2026 aftershock shows that the 2025 intrusion was never fully closed out [4]. CoinDCX said the Tron address 'TQKJQ' belonged to old operational wallet infrastructure that was compromised on 19 July 2025 and deprecated as a result, yet customer deposits were still being credited and swept through those addresses because some users kept sending funds to them [4]. Bitquery, reading the full Tron record, found that CoinDCX's own sweeper moved customer deposits through the drained wallets on the morning of 21 October, that a hot wallet beginning 'TFLx' had sent 276 gas top-ups to those addresses since August, and that only five minutes separated the exchange's last routine move at 12:14 UTC from the thief's first at 12:19 UTC [19]. ZachXBT made the same point more bluntly: the address had been used by a liquidity provider for 10 months after the 2025 incident and had swept deposits to CoinDCX's current hot wallet as recently as April and May 2026 [21].
Bitquery also reported that the thief held keys to two older CoinDCX wallets, one a hot wallet dormant since October 2023 and the other funded by a cold wallet, which it said 'points to access to a whole store of keys' [19]. CoinDCX has not said how the October 2026 attacker obtained signing control, when the sweeper failed, or for how long [4][23]. Whether the 2026 drain used keys taken in 2025 or a fresh compromise therefore remains unconfirmed; what is confirmed is that infrastructure the exchange knew to be compromised remained live, funded with gas and holding customer deposits for well over a year [4][19].
Attack chain
- 01Fake freelance job lure accepted
- 02Bugged file runs on company laptop
- 03Server admin access, keys stolen
- 041 USDT test transfer at 02:37
- 05$44 M liquidity wallet drained
- 06Swapped, bridged, consolidated on Ethereum
The control that failed: A general-purpose employee laptop was allowed to reach the private keys of a live operational wallet, and nothing between that wallet and the chain required a second approval or tripped on an unusual withdrawal.
What the attackers did next
The July 2025 proceeds were laundered quickly and methodically [9]. Merkle Science traced the attacker's preparation to roughly 1 ETH received via Tornado Cash, routed through the instant exchange FixedFloat and bridged to Solana via deBridge before the theft, to pay for gas without exposing a funding source [9]. After the drain, about $44.2 million in USDC and USDT was moved through intermediary wallets, converted to SOL and transferred in batches of 1,000 to 4,000 SOL, swapped to wrapped ETH through the Jupiter aggregator and bridged to Ethereum, with batch sizes rising to 10,000 SOL as the exit accelerated [9]. CoinDCX's incident report described the bridging as going through Wormhole, while Cyvers told DL News the Mayan Bridge was used [1][8].
By 21 July the exchange reported that the funds had consolidated into 4,443 ETH and 155,830 SOL, both dormant at the time [7]. Its bounty page listed balances as of 9.40 am IST on 21 July 2025, with $43,038,946.80 sitting at a single Ethereum address and a further $748,811.21 on Solana [3]. DL News reported the Ethereum consolidation at nearly 11,460 ETH, worth just under $46 million at the time of writing [8]. The Whitefield police told The Hindu there was no way to freeze cryptocurrency inside a wallet and that recovery was only possible once it was converted to fiat; the CID later said it had traced the trail to a single wallet but could not identify its owner [12][16].
The October 2026 outflow went to a single Tron address and was then split; the analyst who first flagged it reported the largest single transfer as 15,819,002 USDT, with the proceeds routed to deposit addresses at Binance, OKX and Gate [21]. BeInCrypto's account of the same tracking put roughly 5.47 million USDT at OKX, 2.02 million at Binance and 1.39 million at Gate, with some funds reaching addresses linked to the Huione and Xinbi marketplaces [18]. Bitquery found that about $9.63 million reached the three exchanges within 18 hours, and that Tether froze 2,212,850 USDT, about 14 per cent of the total, across nine wallets on 22 October [19]. ZachXBT said he had helped freeze a six-figure sum on the exchange's behalf even as he advised users to withdraw [21].
Detection and response
On the first incident, detection was late and disclosure later. The complaint records the test transfer at 2.37 am and the discovery of the main loss at 9.40 am IST on 19 July, and the public first learned of it from ZachXBT about 17 hours after the attack began [6][13]. Asked about the delay at its 21 July open house, Gupta said the company chose 'to be thorough first, then transparent' and would not speak until containment was confirmed [2]. Against that, CoinDCX kept trading and INR withdrawals open, reported to CERT-In the same day, published an incident report with attacker addresses the next afternoon, held a live leadership Q&A and committed in writing to absorb the loss [1][2].
The company's response also included a recovery bounty, announced on 21 July and formalised on 25 July, offering up to 25 per cent of recovered funds, a potential pool of up to $11 million, split 12.5 per cent for the party that freezes the funds and 12.5 per cent for the first reporters who trace them [3][10]. CoinDCX named Sygnia, zeroShadow and Seal911 as forensic partners and thanked the Solana Foundation, Wormhole and deBridge for cooperation [3]. INR withdrawals above Rs 5 lakh were queued for up to 72 hours, and a surge of users checking balances overloaded portfolio APIs until capacity was added [1][10].
The second incident is the harder lesson in response. An external analyst flagged the Tron outflows early on 22 October; within three hours Gupta replied that the report was 'incorrect', that CoinDCX wallets were not breached and that the activity 'sounds like a false alarm', and the official account called the claims 'misleading' four minutes later [21]. A spokesperson gave CoinDesk the same position: the addresses were created in January 2025, compromised in July 2025 and 'have not been used by CoinDCX since' [20]. When ZachXBT showed the address had swept user deposits into 2026, Gupta conceded the team was 'aware of that' and investigating, and by 7.47 am ET the exchange acknowledged a sweeping failure and unquantified 'operational losses' [21]. The figure of 15.99 million USDT appeared only in the 25 October blog post, which also conceded 'we could have been more proactive' [4].
CoinDCX's own account of the second incident notes that it 'noticed unusual activity' on 21 October and that its controls protected active wallets, but that the irregular fund movement was identified only the next day, partly through blockchain data and partly through reports from its own users [4]. Monitoring covered the systems the company considered current, not those it considered retired.
Impact
Direct financial loss is around $44.2 million in July 2025 and 15.99 million USDT in October 2026, both absorbed by the company [1][4]. CoinDCX said its corporate treasury of more than $100 million was sufficient to absorb the first loss without affecting operations, and that its India exchange business was profitable [2]. The Block noted that the exchange's dedicated user-compensation fund held about $7 million against total holdings of $584.2 million and nearly 20 million registered users at the June 2025 proof-of-reserves [6]. The second loss was in customer deposits that the company had already credited to user accounts, so the company rather than users bore it, but only because it chose to honour deposits made to deprecated addresses [4].
Customer-facing impact in July 2025 was indirect but real [2]. Panic selling caused temporary price dislocations in USDT, XRP and Bitcoin on the exchange, 15 spot markets were under maintenance and self-custodial Web3 Mode was restricted for the week [2][10]. In October 2026 the reputational cost came from the sequence of denial and reversal: ZachXBT publicly urged users to 'withdraw all funds from CoinDCX' and accused the founders of having 'lied or are negligently incompetent' [21][22].
Legal consequences have so far fallen on the employee rather than the attackers. The Whitefield CEN police registered a case under sections 66, 43, 66(c) and 66(d) of the Information Technology Act and sections 303, 316(4), 318(4) and 319(2) of the Bharatiya Nyaya Sanhita, and the engineer was taken into custody on 26 July 2025 [11][15]. The Karnataka CID subsequently characterised him as bait rather than a conspirator [16]. The intrusion also sits within a difficult period for the company: Coinbase invested in October 2025 at a reported $2.45 billion valuation, and in March 2026 the co-founders were briefly arrested in Thane over a fraud complaint that CoinDCX attributed to impersonators running a copycat site [17][21].
Root cause
Three controls failed, and the first was the cheapest to get right. A general-purpose company laptop belonging to one engineer was permitted to hold, or reach, administrative access to the servers that controlled a live operational wallet, so that a single malicious file opened from a freelance client gave an external party the keys [16]. Endpoint controls did not stop the file executing in the background, and there was no hard separation between the machine used for day-to-day work and moonlighting and the machine trusted to touch signing material [13][16].
The second failure was at the wallet layer. An account holding roughly $44 million could sign a 1 USDT test transfer at 2.37 am and then a full drain hours later without any velocity limit, second approver or out-of-band confirmation interrupting it [13][16]. Segregation between operational and customer funds worked as designed and is why customers were unaffected, but segregation limits blast radius; it does not stop a theft within the segregated zone [1][2].
The third failure, and the one that produced the 2026 loss, was incomplete remediation [4]. CoinDCX deprecated the compromised wallet infrastructure after July 2025 but kept crediting and sweeping deposits sent to it, kept funding it with gas, and did not monitor it to the standard of its active systems; when the sweeper silently failed, deposits sat exposed in addresses the company already knew an attacker had controlled [4][19]. The company itself said it would now 'strengthen our monitoring and controls around residual systems' [4]. An incident is not over when the attacker's first path is cut; it is over when every key and address the attacker could have touched has been rotated, drained and retired, and that closure has been verified.
Lessons for Indian firms
CoinDCX's reporting obligations ran on two tracks. Under the CERT-In Directions of 28 April 2022, service providers, intermediaries, data centres and body corporates must report the cyber incidents listed in Annexure I to CERT-In within six hours of noticing them [24]. CoinDCX said CERT-In was informed on 19 July, the day of the breach, even though the public disclosure came some 17 hours after the first outflow [1][6]. The two clocks are different: the six-hour regulatory clock starts at notice, not at public statement, and a firm that cannot show when it 'noticed' an incident will struggle to show it met the deadline. Logging and time-synchronisation requirements in the same Directions exist precisely so that the notice time can be evidenced [24].
The second track is anti-money-laundering. Since the Ministry of Finance notification of 7 March 2023, exchange, transfer and safekeeping of virtual digital assets are notified activities under the Prevention of Money-laundering Act, which makes exchanges such as CoinDCX reporting entities under FIU-India [25]. CoinDCX is FIU-registered [7]. For a reporting entity, a theft from its own wallets is a suspicious-transaction event for FIU-IND, and the laundering path, here Tornado Cash funding, cross-chain bridging and deposits at offshore exchanges, is exactly the typology that FIU-IND and partner exchanges need to see quickly if freezes are to work [8][9][19].
On communications, the contrast between the two incidents is the lesson. In 2025 CoinDCX waited until it had facts and then published addresses, a timeline and a Q&A [1][2]. In 2026 its chief executive issued a categorical public denial within three hours, before the team had checked the sweeper logs that would have shown the addresses were still in use [4][21]. Firms facing a claim from an outside researcher should treat 'we are investigating' as the only safe first statement, and assume that on-chain investigators can read the same ledger they can [19].
Finally, treasury and insurance. CoinDCX's ability to absorb two losses totalling almost $60 million from its own reserves is what kept users whole and the platform open; without that buffer the 2025 incident would have looked like WazirX's a year earlier [2][22]. Indian VDA firms should size reserves against the loss of an entire hot-wallet tier rather than a single transaction, document which pool of capital covers operational versus customer losses, and check whether any cyber or crime policy actually responds to a social-engineering intrusion via an employee's device. A deprecated address that still receives customer money remains a liability until it is finally drained and closed [4].
Timeline
| When (UTC) | What happened | Source |
|---|---|---|
| Engineer contacted on a professional networking site with a paid freelance offer; work begins on his company laptop | [16] | |
| Operational Tron deposit addresses later drained in October 2026 are created | [20] | |
| Operators send a batch of project files including a 'bugged' file; laptop compromised in the background | [16] | |
| Test transfer of 1 USDT from the operational wallet to an unknown address | [13] | |
| Company checks and finds roughly $44 million moved to six external wallets | [13] | |
| ZachXBT flags the outflows about 17 hours after they began; Gupta confirms a 'sophisticated server breach' within minutes; CERT-In informed | [6] | |
| CoinDCX publishes incident report with attacker addresses; customer funds and INR withdrawals unaffected | [1] | |
| Leadership open house; recovery bounty of up to 25 per cent / $11 million announced | [10] | |
| Neblio Technologies files police complaint; FIR registered at Whitefield CEN police station | [13] | |
| Software engineer Rahul Agarwal detained by Bengaluru police | [15] | |
| Police say malware was installed via a fake part-time job and the employee was a 'mere tool' | [11] | |
| Karnataka CID briefs The Hindu: year-long freelance lure, private keys stolen from compromised laptop | [16] | |
| Thief's first move on Tron, five minutes after CoinDCX's last routine sweep; 15.99 million USDT drained from 40 wallets | [19] | |
| Outflows flagged publicly; Gupta calls it a 'false alarm'; ZachXBT shows the address swept user deposits into 2026 | [18] | |
| CoinDCX confirms 15.99 million USDT loss from deprecated wallets after sweeper failure; loss absorbed by company | [4] |
What would have stopped it
Block execution of unapproved files on any endpoint with privileged access: application allow-listing plus EDR with script and macro blocking, enforced on wallet-operations and infrastructure-admin laptops
NIST CSF 2.0 PR.PS-05; CIS Controls v8 2.5
The breach began when a 'bugged' project file from a freelance client executed silently on an engineer's company laptop [16].
Dedicated, hardened privileged-access workstations for anyone who can reach wallet servers or signing material, with no email, messaging, personal browsing or third-party code on those devices
NIST CSF 2.0 PR.AA-05; CIS Controls v8 5.4; ISO/IEC 27001:2022 A.8.2
The same laptop used for a year of moonlighting held administrative access to the servers from which the private keys were taken [16].
Policy-enforced withdrawal controls on every hot wallet: per-transaction and daily velocity limits, mandatory second approver above a threshold, and new-destination alerts that page an on-call responder
NIST CSF 2.0 DE.CM-01; ISO/IEC 27001:2022 A.8.16
A 1 USDT test at 02:37 followed by a $44 M drain passed without interruption; Cyvers' assessment was that the credentials allowed large-scale transfers to go unnoticed [8][13].
Mandatory security-awareness content and an acceptable-use policy that specifically covers recruiter and freelance approaches, moonlighting on corporate devices and unsolicited project files, backed by a no-blame reporting channel
NIST CSF 2.0 PR.AT-01; CIS Controls v8 14.2; ISO/IEC 27001:2022 A.6.3
The lure ran for over a year and paid Rs 15 lakh; the engineer had no reason to suspect it and the company only learned of it after the theft [12][16].
Incident eradication checklist that is not closed until every key, address and host the attacker could have reached has been rotated, drained and decommissioned, with residual systems monitored to the same standard as active ones until then
NIST CSF 2.0 RS.MI-02 and ID.AM-08; ISO/IEC 27001:2022 A.5.27
Addresses compromised in July 2025 were still receiving, crediting and sweeping customer deposits in October 2026 when the sweeper failed and 15.99 M USDT was taken [4][19].
Pre-agreed external communications protocol: a single holding statement ('we are investigating') until logs are checked, with CERT-In's six-hour report filed from the time of notice
NIST CSF 2.0 RS.CO-02; ISO/IEC 27001:2022 A.5.24
A categorical 'false alarm' denial issued within three hours had to be reversed within a day, and the loss figure took four days to appear [4][21][24].