OAK — OnChain Attack Knowledge

Worked example · 2025-02

WEMIX — a developer uploads NFT-platform monitoring keys to a shared repository for convenience, and two months later 13 of 15 withdrawals empty the Play Bridge Vault — WEMIX / Wemade (Play Bridge Vault) — 2025-02-28

Loss
~8.65M WEMIX withdrawn from the Play Bridge Vault, valued at approximately $6.1–6.2M at the time. The attacker attempted 15 withdrawals, of which 13 succeeded. Reporting occasionally dates this incident to March 2025 — that reflects the 2025-03-04 public disclosure, not the event, which Wemade confirmed occurred on 2025-02-28.
OAK Techniques observed
OAK-T15.004 (Operator-Side Credential Compromise — primary, confirmed mechanism as stated by the operator. The compromised material was a set of authentication keys used for monitoring the Nile NFT platform. Wemade's stated hypothesis is that the attacker breached a shared repository into which a developer had uploaded those keys for more convenient access. The credential lived at the operator's code-hosting / collaboration layer rather than on a signer's machine, which is the boundary that separates T15.004 from T15.003. See techniques/T15.004-operator-credential-compromise.md). OAK-T5.001 (Hard LP / Vault Drain — the on-chain manifestation: repeated withdrawals emptying the Play Bridge Vault). OAK-T10.001 is recorded only as a partial, cross-referenced neighbour and not as the mechanism: the affected component was a bridge vault, but the compromised keys were monitoring / authentication keys, not validator signing keys, so the class does not properly hold.
Attribution
unattributed. No named individual or group, no public on-chain identifiers, and no link to a tracked OAK actor. The behavioural detail that is public and is the most useful artefact: the attacker is believed to have held access for roughly two months between obtaining the keys and executing withdrawals, and then attempted 15 withdrawals of which 13 succeeded — a dwell-then-burst pattern indicating deliberate preparation rather than opportunistic use of a found credential.
Key teaching point
The convenience shortcut and the compromise are the same event, separated only by time. A developer put authentication keys into a shared repository so the team could reach them easily; everything after that is mechanical. Two features make this worth studying beyond the ordinary "don't commit secrets" lesson. First, the two-month dwell: the credential was live and usable long before it was used, which means the loss window opened at upload time, not at withdrawal time, and any secret-scanning or credential-rotation regime operating on a shorter cycle than that would have closed it. Second, the key was not what it guarded — these were monitoring keys for the Nile NFT platform, and they reached the Play Bridge Vault. Credential blast radius is almost never scoped to the system a credential was issued for, and the review question that catches this is not "is this key secret?" but "what is the complete set of actions this key can authorise, and does that set match the job it was issued to do?" Third, and separately: 13 of 15 withdrawal attempts succeeded, meaning the vault had no per-window egress cap and no anomaly halt — two failures on the same credential would have been enough to trip either.

Summary

WEMIX is a blockchain network operated by Wemade, a Korean games developer. Its Play Bridge Vault held bridged assets; Nile is an NFT platform in the same ecosystem.

A developer uploaded authentication keys used for monitoring the Nile NFT platform into a shared repository, for more convenient access. Wemade's stated hypothesis is that the attacker breached that shared repository and obtained the keys.

The attacker is believed to have spent approximately two months inside the system before acting. On 2025-02-28, they executed 15 withdrawal attempts against the Play Bridge Vault, of which 13 succeeded, removing approximately 8.65M WEMIX — around $6.1–6.2M at the time.

Wemade recognised the incident on 2025-02-28 but did not disclose it publicly until 2025-03-04, a four-day delay. At a subsequent press conference, WEMIX Foundation CEO Kim Seok-hwan confirmed the 2025-02-28 date, accepted personal responsibility for the decision to delay, and apologised to investors. He denied a cover-up, explaining that because the exact infiltration method had not initially been identified, immediate disclosure could have exposed the platform to further attacks, and that the delay was intended to prevent panic and additional losses while the team assessed the damage.

The disclosure timing drew sustained criticism. In June 2025, WEMIX was delisted from Korean won-denominated domestic exchanges, with the delayed disclosure among the cited concerns.

Timeline (UTC)

When Event OAK ref
(prior, undated) A developer uploads Nile NFT-platform monitoring authentication keys into a shared repository for convenient team access (exposure created)
~2 months prior Attacker breaches the shared repository and obtains the keys; access held without being exercised T15.004 pre-positioning
2025-02-28 15 withdrawal attempts against the Play Bridge Vault; 13 succeed; 8.65M WEMIX ($6.1–6.2M) removed T5.001 extraction
2025-02-28 Wemade recognises the incident (detection)
2025-03-04 Public disclosure — four days after detection (delayed disclosure)
2025-03 CEO Kim Seok-hwan confirms the 2025-02-28 date at a press conference, accepts responsibility for the delay, denies a cover-up, cites unidentified infiltration method and risk of further attacks (operator response)
2025-06 WEMIX delisted from Korean won-denominated domestic exchanges; delayed disclosure among the cited concerns (market / regulatory consequence)
2026-07-26 Second breach: attacker takes administrator privileges over the WEMIX$ stablecoin contract and mints ~5.23M units — a different privilege reached by a different route (see 2026-07 example)

What defenders observed

  • Pre-event (secrets in a shared repository). The single root exposure, and the one with the cheapest control: automated secret scanning on every repository and every commit, with automatic revocation on hit. This is a solved problem with mature free tooling, and it is defeated entirely by a credential that is never scanned because the repository is internal and assumed safe (M22, M23).
  • Pre-event (credential blast radius exceeded the credential's purpose). Keys issued for monitoring an NFT platform reached a bridge vault. Scoping review — enumerating what a credential can actually authorise versus what it was issued to do — is what catches this, and it is a different exercise from protecting the credential. Least-privilege on machine credentials is routinely weaker than on human ones because nobody is inconvenienced by over-provisioning them (M11, M22).
  • Pre-event (rotation cadence versus dwell time). The attacker held usable access for roughly two months. Any rotation interval materially shorter than that would have invalidated the credential before it was ever used. Rotation frequency should be set against plausible dwell time, not against audit-cycle convenience.
  • At-event (13 of 15 attempts succeeded). Two failures on the same credential against the same vault, inside one session, is a textbook alerting condition — and the attacker was allowed to continue through it. Failed-authorisation-rate alerting on vault withdrawals, plus a per-window egress cap, are independent controls and either alone would have truncated this (M04, M05).
  • Response (the four-day delay, and the argument for it). The CEO's stated reasoning is not unreasonable on its face: with the infiltration vector unidentified, public disclosure genuinely can invite follow-on exploitation of a hole nobody has yet located. The counter-argument is that users transacting during those four days did so without information material to their risk. OAK does not adjudicate this, but records the outcome: the delay became the durable reputational and regulatory fact, contributing to a domestic exchange delisting three months later — a consequence larger and longer-lived than the $6.1M loss itself.

Public references

Discussion

This entry exists as a backfill because OAK documented examples/2026-07-wemix-stablecoin-contract-ownership-unauthorized-mint.md without the operator's prior incident in the corpus, and the pair is considerably more instructive than either alone. The important discipline is not to read them as the same failure twice. February 2025 was an off-chain credential compromise — keys in a shared repository, obtained months in advance, used to drain a bridge vault. July 2026 was an on-chain privilege seizure — administrator rights over the WEMIX$ stablecoin contract, used to mint. Different privileges, different surfaces, different remediations; hardening the first would not have constrained the second. "The same hole twice" and "a different hole in the same wall" carry very different implications about an operator's security programme, and only the second is supported here.

What the two do share is a structural property worth naming: in both cases the shortest path into WEMIX ran through a standing authority rather than through any defect in shipped logic. A monitoring key that could reach a bridge vault, and a contract owner that could mint a pegged asset, are both permissions that existed by design and were never scoped against what they could destroy. That is the generalisable lesson across the pair, and it is a lesson about permission inventory rather than about code quality.

The disclosure-timing dimension is the part this case contributes that little else in the corpus does. OAK's convention treats fund disposition and operator conduct as neutral metadata that does not change a mechanism's classification, and that holds here — the delay altered nothing about how the keys were taken. But the case is a clean natural experiment in second-order cost: a $6.1M loss was substantially outlived by a four-day disclosure decision, which fed into a domestic exchange delisting three months later. Contributors documenting incidents at operators with retail exposure or regulated listings should record the detection-to-disclosure interval as a distinct field. It is objective, it is usually knowable, and as this case shows it can predict the operator's eventual outcome better than the loss figure does.

Techniques demonstrated (3)