OAK — OnChain Attack Knowledge

Worked example · 2026-06

OpenMonero — server misconfiguration exposes wallet-RPC, hot wallet drained — Monero — 2026-06-08

Loss
~78–200 XMR (~$25K–$63K). On 2026-06-08, an attacker gained root access to a server operated by OpenMonero, a peer-to-peer Monero (XMR) trading marketplace, and drained the platform's hot wallet. Reported figures vary: SlowMist's incident database records ~200 XMR (~$62,900), while the operator's own account puts the loss at ~77.85 XMR (~$25,225) and attributes it to misconfiguration — a permissive ufw firewall rule combined with an exposed monero-wallet-rpc endpoint. The operator stated the breach was "not at the application layer," and that trade chats and the MongoDB database were hosted on separate servers from the monero-wallet-rpc, so the core marketplace infrastructure outside the drained hot wallet was not compromised.
OAK Techniques observed
OAK-T15.003 (Operator-Endpoint Compromise / infrastructure sub-shape — the load-bearing failure was an operator-controlled server in a compromised state: a misconfigured firewall left the monero-wallet-rpc reachable, and the attacker obtained root and used the exposed RPC to move funds out of the hot wallet. The entry was an infrastructure/configuration weakness, not phishing or a contract bug — the opportunistic / drive-by sub-shape of T15.003 where no clear social-engineering pretext exists. See techniques/T15.003-operator-endpoint-compromise.md). OAK-T5.001 (Hard-LP / hot-wallet drain — the extraction primitive: the server-side hot wallet was emptied via the exposed signing/RPC surface, the classic exchange/marketplace server-side hot-wallet-compromise shape (cf. Bitcoinica, Vulcan Forged). See techniques/T5.001-hard-lp-drain.md).
Attribution
unattributed. No named individual or group; the stolen funds are XMR, which is privacy-preserving and untraceable on-chain, frustrating any follow-the-money attribution. The operator disclosed the loss via Telegram and warned users to pause payments.
Key teaching point
An exposed monero-wallet-rpc is a remote hot-wallet-drain primitive; a firewall misconfiguration is enough to reach it. OpenMonero did the harder architectural thing correctly — it segmented trade chats and the MongoDB from the wallet-RPC host — yet a single permissive ufw rule that left monero-wallet-rpc reachable converted a configuration slip directly into a hot-wallet drain, because monero-wallet-rpc exposes transfer capability to anything that can reach it. The defender lessons are operational and unglamorous: bind monero-wallet-rpc to localhost / a private interface only, never expose it to the public internet, require RPC authentication, and audit firewall rules as a custody-critical control. The case is a small but clean restatement of the oldest pattern in OAK's custody record — server-side hot-wallet exposure (Bitcoinica 2011/2012) — in 2026 Monero-marketplace form, and a reminder that infrastructure-config hygiene is part of custody security, not separate from it.

Summary

OpenMonero is a peer-to-peer marketplace for buying and selling Monero (XMR), holding escrow/operational XMR in a server-side hot wallet served by monero-wallet-rpc. On 2026-06-08, an attacker obtained root access to the wallet-RPC server and drained the hot wallet. The operator attributed the breach to misconfiguration — a permissive ufw firewall rule that left monero-wallet-rpc exposed — and stated the attack was not at the application layer. Because trade chats and the MongoDB store ran on separate hosts, the compromise was contained to the hot-wallet/RPC server. Loss estimates range from 77.85 XMR ($25,225) in the operator's account to 200 XMR ($62,900) in SlowMist's incident database. The operator disclosed via Telegram and advised users to stop sending payments.

Timeline (UTC)

When Event OAK ref
Pre-2026-06-08 OpenMonero runs monero-wallet-rpc on a server; a ufw rule leaves the RPC endpoint reachable; trade chats + MongoDB are on separate hosts (standing T15.003 surface)
2026-06-08 Attacker gains root access via the misconfiguration and drains the hot wallet through the exposed wallet-RPC (~78–200 XMR) T15.003 + T5.001
2026-06-08 Operator discloses loss on Telegram; warns users to pause payments; confirms breach was at the infrastructure (not application) layer (operator response)

Public references

Discussion

OpenMonero is a compact 2026 anchor for the infrastructure-configuration sub-shape of T15.003 — no implant, no phishing, no social-engineering pretext, just an exposed monero-wallet-rpc behind a permissive firewall rule. It sits in the same lineage as the earliest entries in OAK's custody record (Bitcoinica's server-side hot-wallet compromises, Vulcan Forged's wallet-server breach): a single server holding signing capability, reachable in a state it should not have been, drained in one window. The Monero dimension is what makes attribution unattributed and recovery effectively impossible — XMR's privacy guarantees mean there is no on-chain trail to follow — which is also why P2P Monero venues are a recurring small-loss target (cf. the May 2026 RetoSwap/Haveno arbitrator-impersonation theft, a different mechanism against the same Monero-P2P ecosystem). The teaching content is deliberately mundane: monero-wallet-rpc should never be internet-reachable, RPC auth should be mandatory, and firewall rules guarding a signing surface are a custody-critical control, not routine ops hygiene.

Techniques demonstrated (2)