INDUSTRY FACT FILE · BLOCKCHAIN, WEB3 & VIRTUAL DIGITAL ASSETS

Five New Case Studies in Blockchain, Web3 and VDA Security

Original 2026 case studies, each written as a blog post, showing how current threats play out at exchanges, brokers, DeFi protocols, Web3 gaming studios and enterprise blockchain consortia, and how Codec Networks services break the attack chain.

In this document 1.  About these case studies 2.  Case Study 1: The Withdrawal Everyone Approved 3.  Case Study 2: The Account Nobody Watched 4.  Case Study 3: The Upgrade That Changed One Line 5.  Case Study 4: The Mint Page That Was Not Ours 6.  Case Study 5: The Consortium Node That Trusted Everyone

These five case studies were written for this document set and have not been published elsewhere. Each is a composite scenario combining control failures widely observed in digital asset, Web3 and blockchain organisations with the obligations that apply in India as of October 2026—in particular the PMLA and FIU-IND's AML and CFT Guidelines and registration requirements, CERT-In's Directions, the IT Act and the DPDP Act. Attack techniques are described only at the level needed to explain the controls; no operational detail is given, and nothing here is investment advice or a comment on any real asset or platform.

Important disclosure The organisations described are fictional and the scenarios are illustrative. They are not accounts of real incidents, and they are not Codec Networks client engagements or claims of achieved outcomes. Their value lies in showing how connected weaknesses form an attack chain, which controls break it, and which services test those controls.

Case study	Organisation type	Core threat	Regulatory lens	Primary bundles
1. The Withdrawal Everyone Approved	VDA exchange	Tampered multisig signing interface	PMLA and FIU-IND; CERT-In; DPDP	B3, B9, B8
2. The Account Nobody Watched	Broker and OTC desk	Drained operational wallet	PMLA and FIU-IND; CERT-In	B3, B7, B8
3. The Upgrade That Changed One Line	DeFi lending protocol	Unaudited smart contract upgrade	IT Act; CERT-In; activity-based PMLA	B11, B2, B7
4. The Mint Page That Was Not Ours	Web3 gaming studio	Phished admin and drainer link	IT Act; CERT-In; DPDP	B10, B2, B7
5. The Consortium Node That Trusted Everyone	Enterprise blockchain consortium	Member node and certificate compromise	IT Act; CERT-In; contracts; DPDP	B9, B3, B7

Five signers checked the screen. The screen was lying.

At a glance
Organisation	A mid-sized Indian VDA exchange (“Exchco A”) registered with FIU-IND, holding most customer assets in a cold wallet secured by a five-signer multisig
Threat	Attackers altered the third-party web interface the signers used, so a routine-looking transfer was in fact a change of wallet control
Why it is new	Attackers now target what signers see, not the keys themselves
Codec Networks services	Custody and signing policy review, wallet tooling assurance, hack response and tracing (Bundles B3, B9, B8)

The scenario

Exchco A topped up its warm wallet from cold storage every few days. The five signers, spread across two cities, reviewed each request in a third-party multisig web interface and approved it on hardware devices that displayed only a short summary. No one decoded the transaction independently, and the signing policy had no allow-list of destinations or limit on what a transaction could do.

Months earlier, attackers had compromised a developer at the interface provider and planted code that activated only for Exchco A's wallet. When the next top-up was proposed, the interface showed the usual amount and destination, while the transaction sent to the hardware devices changed the wallet's ownership logic. All five signers approved within twenty minutes.

Minutes later the cold wallet was emptied through a chain of new addresses and a bridge. Exchco A froze withdrawals, engaged forensics, reported to CERT-In, informed FIU-IND, its banking partner and law enforcement, and asked other platforms to watch for the stolen funds. Customers could not withdraw for weeks while the exchange worked out how to cover the shortfall.

Figure 8: Illustrative attack path for Case Study 1 and the controls that break it.

What went wrong

• No independent decoding of transactions before signing.
• Hardware devices that showed only a summary, not full call data.
• No allow-lists, limits or time-locks in the signing policy.
• Third-party tooling trusted without assurance or change monitoring.

The impact

Exchco A lost a large share of its reserves, suspended withdrawals, faced customer complaints, police and partner scrutiny and questions about its registration, and rebuilt its custody model around independent verification and policy-enforced limits.

The regulatory lens

• PMLA and FIU-IND: as a registered reporting entity, Exchco A had to maintain records and cooperate with FIU-IND; its cyber security audit and controls came under review.
• CERT-In Directions: the incident reported within six hours of noticing it; KYC and transaction records and logs needed for the investigation.
• DPDP Act: user personal data handled during the response with reasonable safeguards.

How Codec Networks would help

Need	Codec Networks response	Bundle
Fix the signing process	Custody and signing policy review, independent decoding and allow-list design	B3
Assure the tooling	Assessment of the third-party wallet interface, delivery and change monitoring	B9
Contain and trace	Hack response, blockchain forensics and fund tracing with reporting support	B8

Key lessons Never trust a single screen. Make hardware signers show the full transaction. Let policy block what people miss. Treat wallet vendors as part of your perimeter.

The main treasury was locked down. The wallet used to fund a partner venue was not.

At a glance
Organisation	A VDA broker and OTC desk (“Brokco B”) that sources liquidity from a partner exchange through an operational wallet and API account
Threat	Credentials for an operational wallet, held outside the main custody policy and monitoring, leaked from a build pipeline and were used to drain it
Why it is new	Operational accounts often sit outside the controls that protect the main treasury
Codec Networks services	Wallet inventory and secrets review, on-chain monitoring, hack response (Bundles B3, B7, B8)

The scenario

Brokco B kept client assets in MPC custody with strict policies. To settle trades quickly, its trading team also ran an operational wallet that funded its account on a partner exchange. The wallet's key and the partner API key sat in a configuration file used by an automated trading service, and the wallet was not on the address list the SOC monitored.

A developer pushed a configuration change to a repository whose build logs were readable by a wider group than intended. An attacker who had compromised a contractor's account found the secrets in the logs and waited for a weekend night.

Withdrawals from the operational wallet began just after 2 a.m. on a Sunday, and the funds were bridged to another chain and sent through a mixer. The loss was found on Monday morning when trades failed to settle. Brokco B covered the shortfall from its own funds, reported to CERT-In and informed FIU-IND and the partner exchange, which helped trace part of the funds.

Figure 9: Illustrative attack path for Case Study 2 and the controls that break it.

What went wrong

• An operational wallet outside the custody policy.
• Secrets in configuration files and readable build logs.
• No on-chain monitoring of the wallet.
• No limits or velocity checks on withdrawals.

The impact

Brokco B absorbed the loss from its treasury, paused its OTC desk for a week, faced questions from its banking partner and institutional clients and moved all operational wallets under one custody policy with monitoring and limits.

The regulatory lens

• PMLA and FIU-IND: records and cooperation as a reporting entity; the laundering route through a mixer is the kind of activity FIU-IND's Guidelines expect platforms to detect.
• CERT-In Directions: the incident reported within six hours of noticing it; logs and transaction records preserved.
• Partner contracts: notification and cooperation duties with the partner exchange and banking partner.

How Codec Networks would help

Need	Codec Networks response	Bundle
Bring every wallet under policy	Wallet inventory, custody policy and secrets management review	B3
Watch every address	SOC on-chain monitoring of treasury and operational wallets with alerts	B7
Trace and recover	Forensic investigation, fund tracing and partner liaison	B8

Key lessons Every wallet is a treasury wallet. Keep secrets out of code and logs. Monitor addresses around the clock. Cap what any wallet can lose in an hour.

The original contracts had been audited twice. The upgrade that emptied them had not.

At a glance
Organisation	A DeFi lending protocol (“Defico C”) built by an Indian team, with upgradeable contracts on an EVM chain and users worldwide
Threat	A small change in an upgrade skipped a validation check, letting an attacker borrow without collateral; copycats repeated the exploit
Why it is new	Each upgrade is new code, and exploits follow within minutes of a flaw going live
Codec Networks services	Smart contract audit, fuzzing and upgrade review, live contract monitoring (Bundles B11, B2, B7)

The scenario

Defico C's core lending contracts had been audited before launch and again a year later. Under pressure to support a new collateral type, the team shipped an upgrade that refactored how loan requests were validated. It passed the existing unit tests, and the team judged it too small to need another audit. The upgrade took effect immediately, without a timelock.

The refactor skipped a collateral check for one type of message. Within hours an attacker noticed the change on-chain and borrowed against collateral that did not exist. Others copied the transaction once it was visible, and within an hour several addresses were draining the pool.

The team used its pause function, but most of the pool had gone. Defico C worked with blockchain analytics firms to trace the funds, asked exchanges to watch for deposits, informed users and investors and, because its developers were in India, reported the incident to CERT-In. Its reputation and much of its user base did not recover.

Figure 10: Illustrative attack path for Case Study 3 and the controls that break it.

What went wrong

• An upgrade shipped without an independent audit.
• No invariant tests or fuzzing for collateral rules.
• No timelock on upgrades to give monitors time to react.
• No live monitoring of unusual borrowing.

The impact

Users lost deposits, the protocol's token and governance were thrown into crisis, investors questioned the team's processes, and Defico C relaunched months later with mandatory audits, fuzzing in CI, timelocked upgrades and contract monitoring.

The regulatory lens

• IT Act: the exploit is an offence of unauthorised access and computer-related fraud, and evidence matters for any complaint.
• CERT-In Directions: a body corporate in India reports the incident within six hours of noticing it.
• PMLA: whether a DeFi team performs notified VDA activities for others is an activity-based question that should be assessed with counsel.

How Codec Networks would help

Need	Codec Networks response	Bundle
Audit every release	Smart contract audit of each upgrade with severity-rated findings and fix verification	B11
Test the invariants	Fuzzing and invariant testing integrated into CI, secure SDLC review	B2
Watch the contracts	Live monitoring of contract events, admin calls and abnormal borrowing	B7

Key lessons No upgrade is too small to audit. Test what must always be true. Timelock changes so someone can react. Monitor contracts, not just servers.

The link came from the studio's own moderator. The moderator had been logged out for an hour.

At a glance
Organisation	A Web3 gaming studio (“Playco D”) that sells in-game items as tokens and runs a large online community
Threat	A phished moderator's session was used to post a lookalike mint link that led players to sign approvals for a drainer contract
Why it is new	Community channels and token approvals are now as critical as the contracts themselves
Codec Networks services	Awareness and simulations, contract and wallet testing, brand monitoring (Bundles B10, B2, B7)

The scenario

Playco D announced a limited mint of in-game items on its community channels a week in advance. Moderators had administrative rights to post announcements and pin links, but their accounts used passwords and app-based codes, and several logged in from personal laptops.

An hour before launch, a moderator opened a message that appeared to come from a partner and logged in to a fake page that captured the session. Attackers used the session to post a link to a convincing copy of the mint page, pinned it and muted members who raised doubts.

Players connecting their wallets were asked to sign what looked like a mint transaction but was an approval letting a drainer contract move their tokens and items. Hundreds signed before the studio regained control. Playco D posted warnings, reported the incident, worked to take down the fake site and offered partial compensation, but players blamed the studio.

Figure 11: Illustrative attack path for Case Study 4 and the controls that break it.

What went wrong

• Admin accounts without phishing-resistant MFA.
• No single verified source of official links.
• No monitoring for lookalike domains before launch.
• A game wallet that did not explain approvals clearly.

The impact

Players lost tokens and items, the launch was cancelled, the studio's community and revenue suffered for months, and Playco D rebuilt admin access, link publication and wallet transaction previews.

The regulatory lens

• IT Act: phishing and impersonation are offences; takedown of fake sites relies on prompt reporting and evidence.
• CERT-In Directions: the incident reported within six hours of noticing it.
• DPDP Act: player personal data handled with reasonable safeguards and breach intimation once provisions commence.

How Codec Networks would help

Need	Codec Networks response	Bundle
Harden the people	Phishing simulations and awareness for moderators and community staff	B10
Fix the flows	Testing of mint contracts, game wallet approvals and transaction previews	B2
Spot the fakes	Brand, domain and community monitoring with takedown support	B7

Key lessons Protect admin accounts like treasury keys. Publish official links in one verified place. Watch for lookalikes before every launch. Show users exactly what they are approving.

The ledger was permissioned. The attacker had the permissions.

At a glance
Organisation	A trade finance consortium (“Ledgerco E”) running a permissioned ledger on which suppliers tokenise invoices for financing by member lenders
Threat	A smaller member's node administrator was phished over a VPN without MFA, and its signing certificate was used to submit duplicate invoice tokens
Why it is new	A permissioned network is only as strong as its least protected member
Codec Networks services	Member assurance, certificate and key protection, network monitoring (Bundles B9, B3, B7)

The scenario

Ledgerco E's members each ran a node and held certificates issued by the consortium's membership authority. Large members kept signing keys in HSMs, but the consortium had no minimum security baseline, and a small supplier member stored its key on the node server, reachable over a VPN that used passwords alone.

An attacker phished the supplier's administrator, logged in through the VPN and used the member's certificate to submit invoice tokens that duplicated genuine invoices already financed elsewhere. The chaincode checked the signature but not whether the same invoice had been tokenised before.

A lender noticed two financing requests with matching invoice details and raised an alert. The consortium halted new issuance, revoked the member's certificate and traced every token the member had submitted. Two lenders had already advanced funds, and the dispute over who bore the loss ran for months.

Figure 12: Illustrative attack path for Case Study 5 and the controls that break it.

What went wrong

• No security baseline for consortium members.
• A signing key stored on a server rather than an HSM.
• VPN access without MFA.
• Chaincode that did not detect duplicate invoices.

The impact

Lenders lost the funds advanced on duplicate tokens, the consortium paused issuance for weeks, members disputed liability, and Ledgerco E introduced member baselines, HSM-protected keys, duplicate detection and network-wide monitoring.

The regulatory lens

• Consortium and lending contracts: security, notification and liability clauses decided who bore the loss.
• CERT-In Directions: affected body corporates report the incident within six hours of noticing it.
• IT Act and DPDP Act: the intrusion is an offence; any personal data on or around the ledger handled with reasonable safeguards.

How Codec Networks would help

Need	Codec Networks response	Bundle
Raise every member	Member security baselines and third-party assessments	B9
Protect the keys	HSM-backed certificate keys, MFA and privileged access review	B3
Watch the network	Network-wide monitoring of node activity and anomalous submissions	B7

Key lessons Set a minimum bar for every member. Keep signing keys in hardware. Put MFA on every remote path. Write business rules into the chaincode.

Contact Codec Networks Pvt. Ltd. New Delhi: 507, 5th Floor, New Delhi House, Barakhamba Road, Connaught Place, New Delhi – 110001 Gurugram: 707, 7th Floor, Silverton Tower, Golf Course Extension Road, Sector 50, Gurugram – 122018, Haryana Landline: 011 430 496 96 | 011 437 522 99   Mobile: +91 99716 76124 | +91 88007 88220 | +91 88003 31124 Email: mktg@codecnetworks.com   Web: www.codecnetworks.com