Worked example · 2024-03
Munchables — Blast L2 — 2024-03-26
Summary
Munchables was an NFT / GameFi protocol built on Blast (an Ethereum L2 launched by Blur founder "Pacman"). On March 26, 2024 a developer who had been on the Munchables smart-contract team for several months exploited their privileged access to the protocol's proxy-contract upgrade path, assigning themselves an internal balance of 1,000,000 ETH and then withdrawing 17,413.96 ETH ($62.5M at the time). Within hours, blockchain investigator ZachXBT and the Munchables and Blast teams identified the developer as one of four overlapping GitHub identities believed to be a single DPRK-affiliated individual hired into the project under fabricated personas — i.e., a textbook OAK-G04 IT-worker placement.
The case is structurally important to OAK for two reasons. First, it is the cleanest current worked example of OAK-G04 producing an on-chain insider-extraction event at a named crypto firm with a documented dollar loss. Second, the resolution was anomalous: the attacker returned the full ~$62.5M within ~24 hours, transferring private keys to a Blast-team multisig with ZachXBT onboarded as custodian, without receiving a bounty or negotiated payment. The contemporaneous public-record explanation is operational rather than ethical — the attacker had managed to off-ramp only ~$6,220 to a MEXC deposit address before encountering bridge-liquidity limits (third-party Blast bridges capped transfers at ~3 ETH) and the 14-day mandatory withdrawal delay on Blast's native bridge — leaving the proceeds effectively trapped on Blast L2 once Pacman and Blast bridge operators coordinated to freeze further outflows. The defender lesson is that L2 bridge friction can functionally substitute for hot-wallet freeze authority in the narrow window between detection and laundering.
Timeline (UTC)
| When | Event | OAK ref |
|---|---|---|
| Pre-event (months prior) | Munchables hires four developers under separate GitHub identities (NelsonMurua913, Werewolves0493, BrightDragon0719, Super1114); identities mutually recommend each other for the role and share deposit-address / funder-wallet infrastructure |
G04 placement vector (off-chain; not in OAK on-chain Tactic scope at v0.1) |
| Pre-event | Developer(s) participate in legitimate smart-contract development, including review of and contributions to the proxy-contract upgrade path | (legitimate access) |
| 2024-03-26 | Developer uses upgrade authority on the Munchables proxy to assign themselves an internal balance of |
T11 (insider) + adjacent T9.004 |
| 2024-03-26 | Attacker bridges ~$6,220 of ETH off Blast and deposits to a MEXC address; further off-ramp blocked by third-party-bridge per-tx liquidity caps (~3 ETH) and Blast native bridge's 14-day withdrawal delay | T7.002 partial off-ramp |
| 2024-03-26 | ZachXBT publicly identifies the four-identity GitHub cluster and links it to prior salary-remittance and funder-cluster activity consistent with OAK-G04 | G04 attribution surface (T8.001-class linkage) |
| 2024-03-26 to 2024-03-27 | Munchables, Blast (Pacman), ZachXBT, and PeckShield negotiate with the attacker; Blast-team contributors prepare a custodial multisig to receive returned keys | (response) |
| 2024-03-27 (~T+24h) | Attacker transfers private keys for wallets holding the stolen 17,413.96 ETH to the Blast-contributor multisig; ZachXBT onboarded as custodian; full ~$62.5M effectively recovered | (recovery) |
| 2024 onward | Munchables case cited as canonical hire-then-exploit DPRK-IT-worker example in Chainalysis 2024 DPRK report and downstream FBI / OFAC advisories on the IT-worker placement scheme | G04 inferred-strong attribution sustained |
What defenders observed
- Pre-event (the canonical lesson — hiring is the attack surface). The entry vector was the hiring pipeline itself: four GitHub identities, all controlled by the same individual, were each onboarded to the Munchables engineering team, with mutual job-references and shared on-chain infrastructure that was forensically linkable in retrospect but not at the point of hire. The defensive baseline this case establishes is multi-source identity verification for engineering hires with privileged on-chain authority: passport / government-ID checks against issuance databases, video-attestation interviews recorded for retention, GitHub-history-and-IP-address forensics, in-person work-authorization checks where jurisdiction permits, and explicit checks against the public OAK-G04 / DPRK-IT-worker red-flag set (Chinese-bank payment routing, multi-IP logins from disparate countries, requests for crypto settlement, identity inconsistencies across platforms).
- At-event (proxy-upgrade authority as a single-signer kill switch). The on-chain extraction step was a legitimate use of upgrade authority that the developer held — not a key compromise, not a contract bug, not a re-entrancy. Any architecture in which a single engineering hire holds unilateral upgrade authority over funds-bearing contracts collapses to the trustworthiness of that hire. Post-Munchables, the defensive baseline is upgrade authority gated behind multi-signer governance with mandatory delay, mirroring the post-WazirX (T11.003) lesson in a different sub-class.
- Off-ramp friction as residual containment. The attacker's inability to launder more than ~$6,220 before the unwind reflected Blast-specific bridge architecture (third-party bridge per-tx caps, native bridge 14-day delay). On a more liquid L1 / L2 the same exploit would likely have been irreversible within minutes. Defenders should not treat L2 bridge friction as a primary control — Munchables-class cases on Ethereum L1 or on bridged L2s with deeper third-party liquidity will not recover this way — but the friction does meaningfully widen the detection-to-laundering window.
- Post-event (return of funds). The full ~$62.5M was returned within ~24 hours via private-key handover to a Blast-contributor multisig with ZachXBT onboarded as custodian. No ransom or bounty was paid. Contributors writing future T11 / G04 cases should treat this outcome as a data point, not a baseline expectation (see Discussion).
What this example tells contributors writing future Technique pages
- OAK-T11 needs to span insider-compromise sub-types beyond the existing third-party-vendor / wallet-software / in-use-multisig set. The Munchables case is structurally distinct from T11.001 (third-party vendor), T11.002 (wallet-software supply chain), and T11.003 (in-use multisig modification) because the compromised access was granted legitimately by the victim firm to a worker the firm believed it had hired through normal channels. A future T11 sub-type covering "directly-employed-insider compromise via placement-scheme hiring" would have a clean canonical example in Munchables. This is a TAXONOMY-GAPS candidate for OAK v0.x.
- OAK-G04 worked examples should preserve the on-chain / off-chain split explicitly. The G04 entry vector is off-chain (hiring fraud); the on-chain manifestation in Munchables is upgrade-authority abuse. Contributors writing additional G04 cases (Solareum, Injective-class disclosures, future cases) should structure timelines so the off-chain placement and the on-chain extraction are visibly separable, because the defender controls for each are different (hiring pipeline vs. engineering pipeline).
- Recovery via attacker-initiated key handover is jurisdictionally and operationally rare. The Munchables outcome reflects a specific combination of L2 bridge friction, rapid public attribution by ZachXBT, and the coordinated negotiating posture of Blast / Munchables / PeckShield. Contributors should not generalise this recovery path; the WazirX-class restructuring path and the more common no-recovery path are far more representative of T11 outcomes.
inferred-strongis the right attribution level here, even though the case is widely cited as DPRK. No FBI / Treasury press release names Munchables specifically as of OAK v0.1. The attribution evidence is forensic-provider-led (ZachXBT's GitHub-and-funder-cluster linkage, Chainalysis cataloging the case in subsequent G04 reporting, downstream FBI / OFAC advisories that treat the case as part of the broader pattern). OAK contributors should preserve theinferred-stronglabel rather than upgrading toconfirmeduntil and unless a single-source-of-record press release lands.
Public references
[zachxbtmunchables2024]— ZachXBT's public investigation thread linking the four GitHub identities (NelsonMurua913,Werewolves0493,BrightDragon0719,Super1114) to a single DPRK-affiliated developer.[coindeskmunchables2024]— CoinDesk reporting on the exploit and the North-Korea-linked attribution.[cointelegraphmunchablesreturn2024]— Cointelegraph reporting on the return-of-funds resolution and ZachXBT's custodial role.[halbornmunchables2024]— Halborn technical post-mortem of the proxy-upgrade-authority exploit path.[munchablespostmortem2024]— Munchables / Blast contributor public post-incident statement (key handover, multisig recovery).[chainalysismunchables2024]— Chainalysis cataloging of the Munchables case within the broader OAK-G04 / DPRK-IT-worker pattern.[fbidprkitworker2022]— joint U.S. State / Treasury / FBI advisory on the DPRK IT-worker scheme; primary public-record characterisation.[treasurydprkitworker2023]— Treasury press release JY1498 designating Chinyong IT Cooperation Company and Kim Sang Man.[ofac2026dprkitworker]— March 2026 OFAC designation round against six individuals and two entities for IT-worker fraud, citing the broader pattern that Munchables exemplifies.[chainalysis2024dprk]— Chainalysis 2024 DPRK-revenue report, including the ~$800M IT-worker-channel estimate.
Discussion
Munchables is the cleanest current worked example of an OAK-G04 IT-worker placement producing an on-chain insider-extraction event at a named crypto firm with a documented dollar loss. The defender lesson is straightforward and not specific to crypto: hiring is an attack surface, and engineering hires with unilateral upgrade authority over funds-bearing contracts collapse the security model to the trustworthiness of a single individual whose identity may have been verified only through pipelines (LinkedIn, GitHub, freelance platforms) that the OAK-G04 scheme is purpose-built to abuse. The post-Munchables defensive baseline — multi-source identity verification for privileged engineering hires, plus upgrade authority gated behind multi-signer governance with mandatory delay — is the right takeaway regardless of whether any individual hire turns out to be a G04 placement.
The unusual feature of the case is the return of funds. There is no public-record ground truth for why the attacker returned ~$62.5M without ransom. The contemporaneous operational explanation (bridge friction trapped the funds on Blast L2, and the attacker's only off-ramp was a ~$6,220 MEXC deposit before liquidity caps and withdrawal-delay barriers closed) is sufficient to explain the outcome without invoking any actor-side intent. A second hypothesis — speculation, not on the public record — is that public attribution by ZachXBT within hours of the exploit raised the cost of continuing the operation high enough that the placement network preferred to abandon the proceeds rather than risk further forensic exposure of the hiring pipeline; the four-identity GitHub cluster is more valuable to the scheme as ongoing-placement infrastructure than ~$62M is as one-time revenue, and burning it to fight for a partial off-ramp on a frictioned L2 is a poor trade. OAK does not need to adjudicate between these hypotheses — both are consistent with G04's operational logic — but contributors writing future G04 cases should note that neither hypothesis generalises: most G04 placements at firms with deeper laundering off-ramps will not produce a Munchables-class recovery.
Munchables has subsequently been cited in Chainalysis's 2024 DPRK report and in downstream FBI / OFAC advisories as evidence that DPRK IT-worker placement is operationally active in crypto and is producing documented insider-extraction events, not only salary-remittance revenue. The case is the canonical Munchables-class data point for the OAK-G04 entry, and OAK contributors should treat it as the reference baseline for how to structure G04-attributed worked examples — preserving the inferred-strong attribution level, separating the off-chain placement vector from the on-chain extraction step, and refusing to generalise the return-of-funds outcome.