Munchables (2024)

A $63M attack against Munchables, a Blast-based gamified protocol, in March 2024. The exploit was committed by a malicious insider — a North Korean developer who had been hired through normal recruitment channels, deployed a back-doored contract upgrade, and drained funds. Notable because all funds were returned after negotiation, and because the case made the "malicious insider developer" threat explicit.

Timeline

  • 2023: Munchables hired four developers (later revealed to be a single individual using multiple pseudonyms, or possibly a coordinated group).
  • Early 2024: The developer(s) deployed contracts and upgrades to Munchables, including a back-doored contract.
  • March 26, 2024: The back door was triggered, draining 17,400 ETH (~$63M).
  • March 27, 2024: After public attention and negotiations involving Munchables' team and the Blast team, the attacker returned all funds. No ransom paid.
  • Subsequent investigation: Attributed to a North Korean-aligned actor who had been operating under multiple identities to gain employment at multiple crypto projects.

Root Cause

The developer was hired in good faith. During contract development, they introduced a subtle privilege-escalation back door:

  1. The upgradeable contract's constructor / initializer set the contract's deployer as an admin.
  2. A subsequent upgrade changed the contract logic such that the deployer (i.e., the malicious dev) retained admin privileges in the new logic, even though the user-facing admin was nominally a multisig.

The back door was visible in the bytecode of deployed contracts. The user-facing admin (the Munchables multisig) genuinely believed it had control. The deployer had a parallel privilege path that no one had noticed.

When the time came to exploit, the deployer used their parallel admin path to drain the contract.

Exploit Path

1. Hire — developer joins Munchables, gains commit access.
2. Develop — contracts deployed with subtle dual-admin logic.
3. Upgrade — subsequent upgrades preserve the parallel admin path.
4. Wait — funds accumulate. Multiple months / hundreds of users.
5. Drain — deployer calls admin function (which user-facing admin didn't
   know about), transferring all funds to attacker addresses.

The on-chain action at drain time was a single transaction — the rest of the attack was social and operational, taking place over months of building trust and depositing the back door.

What an Audit Should Have Caught

Whether an audit would have caught this depends on what was audited. The original deployment may or may not have been audited; if it was, the auditor missed the back door. The subsequent upgrades, if not re-audited, would not have surfaced anything.

Findings that should have appeared if the contracts were properly reviewed:

  1. Multiple admin paths. Any contract should have a clearly enumerated admin set. If admin privilege accrues to multiple addresses, every such address must be intentional and documented. An audit should diff the user-facing admin documentation against the on-chain reality.

  2. Deployer privileges retained post-upgrade. Upgradeable contracts often have a deployer privilege during setup that should be relinquished after initialization. An audit should check that all deployer privileges are explicitly relinquished or transferred.

  3. Storage-layout review across upgrades. Subsequent upgrades that introduced or retained the back door touched contract storage. A diff-audit of upgrades (especially proxy implementations) would have shown the persistence of the deployer privilege.

  4. Bytecode-level review. The back door was in deployed bytecode. A reviewer who reviewed only the source code (or only the source code that the developer chose to share) would miss bytecode-only patches. This is one reason to prefer verified, public source for all deployed contracts.

Lessons

  1. Insider threats are a category. Almost all security thinking assumes adversarial external attackers. Munchables shows that adversaries can be internal, hired in good faith, working for months. The threat is uncommon but, when realized, catastrophic.

  2. Background checks matter, but are limited. North Korean operatives using stolen / synthetic identities pass standard background checks. Crypto-industry due diligence at hire is uneven; this is a real recruitment-security problem.

  3. Code review should not trust the author. PRs from any team member, including senior or trusted ones, should be reviewed for security implications. "It's the lead developer's PR, just merge it" is the pattern that enables insider attacks.

  4. Deployer privileges must be relinquished explicitly. The fact that "the deployer is admin during setup" is a common pattern is a known footgun. Every deployment should include an explicit "relinquish deployer admin" step, verified post-deployment.

  5. Multi-stage audits are valuable. Audit at design, audit at deployment, audit at each upgrade. Each is a chance to catch issues that previous stages missed.

  6. Hiring in crypto requires security thinking. Reference checks, video interviews (where the candidate's face is shown), real-world identity verification, gradual privilege escalation rather than immediate admin access — these are all reasonable mitigations.

  7. Recovery is possible when the attacker can be identified. Munchables and Blast successfully pressured the attacker to return funds, in part by identifying the developer behind the pseudonyms. The threat of identification — and potential legal consequences — is one of the few effective deterrents.

The Munchables case is part of a broader pattern: North Korean state-aligned actors infiltrating crypto projects via fake identities, with the goal of long-term funding for the regime. The 2024–2026 disclosures of similar cases (multiple smaller protocols, exchanges, even non-crypto tech companies) suggest this is a recurring threat, not a one-off.