OAK — OnChain Attack Knowledge

Worked example · 2026-05

Superfortune ($GUA) — multisig airdrop-transfer destination tampering to a lookalike address — 2026-05-27

Loss
~$15.18M notional — the value of an airdrop-related transfer whose destination was redirected to an attacker-controlled address during a multisig transaction. The attacker realised ~$5.66M after dumping the diverted $GUA on-market; the token fell >60% intraday (some trackers reported drawdowns up to ~76%). The gap between the ~$15.18M diverted and the ~$5.66M realised is the exit-liquidity discount typical of a single-token theft that must be sold into the token's own thin order book.
OAK Techniques observed
OAK-T11.003 (In-Use Multisig Smart-Contract Manipulation — the canonical anchor. The loss occurred when a live multisig transaction, intended to send an airdrop transfer to 0x70ae7D…5c15, instead executed against the near-identical attacker address 0x70AE67…5C15. The signers' authority was genuine; what was manipulated was the destination the signed transaction actually carried. See techniques/T11.003-multisig-contract-manipulation.md). OAK-T11.001 (Third-Party Signing-Vendor UI / Signing-Flow Compromise — cross-referenced: if the swap occurred between what signers believed they were approving and what was broadcast, the failure is a signing-flow / tooling-integrity compromise of the kind anchored by Bybit-2025). OAK-T4.003 (Address Poisoning — cross-referenced and largely ruled out as the classic form: the lookalike-address substitution resembles address poisoning, but the project stated it had never previously interacted with the attacker address, which is the precondition for classic on-chain poisoning. The lookalike address is therefore better read as a crafted-destination artefact of the multisig/tooling compromise than as a copy-paste poisoning hit).
Attribution
pseudonymous attacker. The attacker address 0x70AE678b457C5E1b3fD7AD9537F234dFc1795C15 is observable on-chain; it shares its first four and last four hex characters with the legitimate destination 0x70ae7D3DECfB4C3aE996fb1c07092566F73D5c15 (both abbreviate to 0x70AE…5C15). SUPERFORTUNE AI initially described a "suspected address poisoning attack"; subsequent analysis pointed variously to a leaked signer private key, compromised tooling, or an operational error in the multisig workflow. No public attribution to a named operator group. The exact root cause was not conclusively established in initial reporting; this entry records the competing hypotheses rather than asserting one.
Key teaching point
Superfortune is the largest single crypto-theft of May 2026 and the month's clearest example of a multisig destination-integrity failure — a category where every signature is valid and every signer is authorised, yet the funds land at the wrong address because the destination the multisig committed to was not the destination the operators intended. The lookalike-address detail makes the case diagnostically rich: it is the visual signature of address poisoning, but the missing precondition (no prior interaction with the attacker address) rules out the classic poisoning mechanism and points instead at the signing pipeline — a leaked key that let the attacker pre-stage the transaction, compromised front-end tooling that displayed one address while encoding another, or a blind-signing workflow where signers approved a destination they did not independently verify. The detection-signal locus is the pre-broadcast verification layer: signers on a high-value multisig transfer must verify the full destination address (not the abbreviated 0x70AE…5C15 form) against an independent source of truth before signing.

Summary

SUPERFORTUNE AI is an "AI metaphysics" project whose token, $GUA, trades on EVM venues. On 2026-05-27, funds earmarked for an airdrop-related transfer were sent, during a multisignature transaction, to an attacker-controlled address instead of the intended recipient. The intended destination was 0x70ae7D3DECfB4C3aE996fb1c07092566F73D5c15; the funds went to 0x70AE678b457C5E1b3fD7AD9537F234dFc1795C15 — an address that begins and ends with the same four hex characters, so both render as 0x70AE…5C15 in any abbreviated display.

The diverted transfer was valued at ~$15.18M; the attacker dumped the proceeds and walked away with ~$5.66M, with $GUA falling more than 60% on the day. SUPERFORTUNE AI's first public statement framed the event as a "suspected address poisoning attack" with "initial findings indicat[ing] an address manipulation through a multisig transaction." Independent commentary quickly noted that the incident did not fit classic address poisoning: poisoning works by seeding a victim's transaction history with a lookalike address so a later copy-paste selects the wrong entry, but SUPERFORTUNE AI had reportedly never interacted with the attacker's address before. With that mechanism excluded, the candidate root causes narrow to the signing pipeline itself: a leaked signer private key, compromised signing/airdrop tooling, or an operational error / blind-signing failure in the multisig workflow.

Why this is structurally significant

The instructive feature of Superfortune is the divergence between a valid signature and an intended outcome. A multisig protects against unilateral action and single-key compromise — but it does not, by itself, guarantee that the transaction the signers approve is the transaction they think they are approving. If the destination address is supplied by tooling the signers trust and do not independently verify, then compromising or corrupting that tooling (or pre-staging a transaction with a leaked key and relying on signers to approve it) defeats the multisig without breaking any cryptography.

This places Superfortune in the same structural family as the Bybit-2025 signing-flow compromise (examples/ Bybit/Safe-UI lineage under T11.001): in both, the signers were legitimate and their signatures were valid, but what they signed was not what they believed they were signing. The difference is the locus of the swap — Bybit's was a compromised Safe front-end that altered the displayed-vs-executed transaction; Superfortune's exact swap locus (front-end, key, or process) was not conclusively pinned, which is itself the lesson: once a destination can diverge from intent inside a trusted multisig workflow, the post-mortem cannot always distinguish a tooling compromise from a key leak from a human error — because all three produce the same on-chain artefact (a valid multisig transaction to the wrong address).

The lookalike address is the second structural point. The abbreviated-display convention (0x70AE…5C15) that wallets and explorers use for readability is precisely what makes a crafted near-collision destination survive a human glance. Whether the address was generated by brute-forcing a vanity prefix/suffix (cheap for 4+4 characters) to support a poisoning campaign, or chosen to disguise a tooling-injected destination, the defence is identical: verify the full 40-hex-character address, not the abbreviation, on any high-value transfer.

Timeline (UTC)

When Event OAK ref
Pre-2026-05-27 SUPERFORTUNE AI prepares an airdrop-related transfer to be executed via its multisig; intended destination 0x70ae7D…5c15 (standing multisig-workflow surface)
2026-05-27 A multisig transaction executes the airdrop transfer to attacker address 0x70AE67…5C15 (shares first/last four chars with the intended destination) instead of 0x70ae7D…5c15; ~$15.18M diverted T11.003 execution (in-use multisig destination tampering)
2026-05-27 Attacker dumps the diverted $GUA, realising ~$5.66M; $GUA falls >60% intraday T5 outflow
2026-05-27 SUPERFORTUNE AI posts that it is investigating a "suspected address poisoning attack … address manipulation through a multisig transaction"; Manta co-founder noted as investigating; $GUA down sharply over 24h (operator response / disclosure)
Post-2026-05-27 Independent analysis disputes the classic-poisoning framing (no prior interaction with attacker address); candidate causes narrow to signer-key leak / compromised tooling / multisig operational error (forensic surface — root cause not conclusively established)

What defenders observed

  • Pre-event (signing-workflow layer): the high-value airdrop transfer was routed through a multisig but the destination address was, on the available evidence, not independently verified by signers against an out-of-band source of truth before signing. Defender lesson: for any transfer above a material threshold, signers must confirm the full destination address (and ideally simulate the transaction) on a device/channel independent of the tool that proposed it — the multisig protects against rogue signers, not against a corrupted or unverified destination.
  • At-event (on-chain signal): funds moved to an address sharing the intended destination's first/last four hex characters — a near-collision that is invisible in abbreviated display. A pre-broadcast check that diffs the full destination against an allowlist of known-good recipients would have flagged the mismatch; a post-broadcast monitor watching for transfers to freshly-seen addresses that visually resemble treasury counterparties would have caught it at execution.
  • At-event (attribution signal): the project reported no prior interaction with the attacker address, which excludes the classic transaction-history-seeding form of address poisoning and redirects suspicion to the signing pipeline (key or tooling).
  • Post-event: the realised loss ($5.66M) was roughly a third of the diverted notional ($15.18M), consistent with selling a single project token into its own order book; the price fell >60%. No conclusive single root cause was published in initial reporting.

What this example tells contributors writing future Technique pages

  • T11.003 should distinguish "destination tampering" from "signer-set / threshold manipulation." Superfortune is a destination-integrity failure: the multisig's parameters (signers, threshold) were intact, but the payload (destination) diverged from intent. This is mechanically different from manipulating the multisig contract's owner set or threshold, and the detection guidance (full-address verification, transaction simulation) is specific to it.
  • Record the lookalike-address artefact without over-committing to address poisoning. When a theft lands at a near-collision address, the visual signature is poisoning, but the mechanism may be key leak or tooling compromise. The discriminating test is whether the victim previously interacted with the attacker address (poisoning precondition). Contributors should record the test and its outcome, not assume the mechanism from the artefact.
  • "Valid signature, wrong destination" is a first-class failure mode. It links T11.003 (multisig manipulation) and T11.001 (signing-flow compromise): both produce a cryptographically valid transaction that does not match operator intent. The shared mitigation is independent, full-address, pre-broadcast verification — a control that sits outside the cryptography entirely.
  • Inconclusive root cause is a recordable outcome. Many 2026 multisig incidents (this one included) end without a definitively pinned vector because tooling-compromise, key-leak, and human-error all leave the same on-chain trace. The taxonomy should support "competing hypotheses, root cause not conclusively established" as a valid attribution/diagnosis state rather than forcing a single label.

Public references

Discussion

Superfortune is the May-2026 anchor for a failure mode that recurs whenever value transfers run through a multisig that signers do not fully verify: a valid, fully-authorised transaction that sends funds to the wrong place. It belongs with the Bybit-2025 signing-flow lineage under T11.001 and with the in-use multisig manipulation pattern under T11.003, and it cross-references T4.003 chiefly to exclude the classic poisoning mechanism — the lookalike address is real, but the poisoning precondition (prior interaction with the attacker address) was absent.

The case is most valuable as a study in diagnostic ambiguity. A leaked signer key, a compromised airdrop/signing tool, and a human operational error all converge on the same on-chain evidence: a correctly-signed multisig transaction to a near-collision destination. Because the artefact does not discriminate among them, the preventive control has to sit upstream of all three — independent, full-address, out-of-band verification of the destination before any high-value multisig transaction is signed, ideally paired with transaction simulation so signers see the effect of what they are approving rather than a human-readable summary supplied by the same tool that might be compromised. That control would have stopped Superfortune regardless of which of the three hypotheses turns out to be correct, which is exactly why it is the right lesson to record.

Techniques demonstrated (3)