diff --git a/BACKLOG.md b/BACKLOG.md index 596d596..658552e 100644 --- a/BACKLOG.md +++ b/BACKLOG.md @@ -2,7 +2,7 @@ _Generated by `tools/build_backlog.py` on 2026-06-24. Regenerated on every `npm run site:data`._ -_Scope: 646 worked examples, 146 Techniques, 19 Threat Actors._ +_Scope: 647 worked examples, 146 Techniques, 19 Threat Actors._ This file is a prioritized contributor backlog. **P0** items close hard structural gaps (empty Tactics, placeholder actor cards). **P1** items lift per-Tactic coverage below the documented minimum. **P2** items anchor candidate sub-Techniques from `TAXONOMY-GAPS.md`. diff --git a/STATS.md b/STATS.md index ca64cc3..c854569 100644 --- a/STATS.md +++ b/STATS.md @@ -1,11 +1,11 @@ # OAK — Stats Snapshot -_Auto-generated by `tools/build_stats.py` at 2026-06-24 10:43 UTC._ +_Auto-generated by `tools/build_stats.py` at 2026-06-24 12:47 UTC._ ## Catalogue - **17** Tactics · **146** Techniques · **19** Threat Actors · **43** Mitigations · **41** Software · **12** Data Sources -- **646** Worked Examples · **1555** bibtex entries +- **647** Worked Examples · **1555** bibtex entries ## Examples by Tactic @@ -15,13 +15,13 @@ _Auto-generated by `tools/build_stats.py` at 2026-06-24 10:43 UTC._ | T2 (Liquidity Establishment) | 32 | | T3 (Holder Capture) | 36 | | T4 (Access Acquisition) | 75 | -| T5 (Value Extraction) | 113 | -| T6 (Defense Evasion) | 52 | +| T5 (Value Extraction) | 114 | +| T6 (Defense Evasion) | 53 | | T7 (Laundering) | 152 | | T8 (Operator Continuity / Attribution Signals) | 82 | | T9 (Smart-Contract Exploit) | 203 | | T10 (Bridge / Cross-Chain) | 55 | -| T11 (Custody / Signing) | 144 | +| T11 (Custody / Signing) | 145 | | T12 (NFT-Specific) | 31 | | T13 (Account Abstraction) | 20 | | T14 (Validator / Staking) | 39 | @@ -46,7 +46,7 @@ _Auto-generated by `tools/build_stats.py` at 2026-06-24 10:43 UTC._ | 2023 | 106 | | 2024 | 153 | | 2025 | 76 | -| 2026 | 62 | +| 2026 | 63 | ## Examples by Year-Month (recent dense window) @@ -75,14 +75,14 @@ _Auto-generated by `tools/build_stats.py` at 2026-06-24 10:43 UTC._ | 2026-03 | 5 | | 2026-04 | 11 | | 2026-05 | 16 | -| 2026-06 | 14 | +| 2026-06 | 15 | ## Attribution-strength Distribution | Strength | Count | | --- | ---: | -| pseudonymous | 305 (47.2%) | -| unattributed | 149 (23.1%) | +| pseudonymous | 306 (47.3%) | +| unattributed | 149 (23.0%) | | confirmed | 125 (19.3%) | | inferred-strong | 64 (9.9%) | | inferred-weak | 3 (0.5%) | diff --git a/examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md b/examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md new file mode 100644 index 0000000..ee99591 --- /dev/null +++ b/examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md @@ -0,0 +1,47 @@ +# SecondFi — predictable web-wallet key generation drains Cardano (ADA) wallets — Cardano — 2026-06-23 + +> **Status: developing / partially disputed (as of 2026-06-24).** Figures, the affected-address count, and especially the disposition of the large \~129M ADA flow are operator-self-reported and/or contested by on-chain analysts at the time of writing. This entry documents the *mechanism* (confirmed multi-source) and flags the *disposition* (disputed) as contested metadata, per OAK's neutral-framing convention. Revise as forensic confirmation lands. + +**Loss:** **Confirmed \~16M ADA (\~\$2.4M at \~\$0.15/ADA); total exposure up to \~129M ADA (\~\$19–20M).** Independent reporting puts confirmed theft at **\~16 million ADA across \~178 wallets**; SecondFi's own statement framed it as **\~16M ADA across 374 addresses** from "3 distinct draining events" by external actors. SlowMist (Yu Xian / "Cos") estimated **potential losses exceeding \$20M, possibly involving \~129 million ADA and other tokens**, because the root cause makes **every wallet generated by the affected software iteration potentially compromised, including those not yet drained**. A separate **\~129M ADA flow** that SecondFi described as an emergency "rescue" to a third-party custodian is **disputed** (see Disposition). + +**OAK Techniques observed:** **OAK-T11.004** (Insufficient-Entropy Key Generation — *primary, confirmed mechanism*: SecondFi attributed the breach to its **native Cardano web-wallet generation software**, which produced **private keys with predictable randomness**; this collapses the key search space so an attacker can derive keys for the whole generated cohort and sweep them, independent of which wallet software a user later restores into. This is the same structural class as the Profanity/Wintermute EVM cohort, here in a **non-EVM, wallet-provider-software** form. See [`techniques/T11.004-insufficient-entropy-key-generation.md`](../techniques/T11.004-insufficient-entropy-key-generation.md)). **Disputed-disposition lenses (NOT a confirmed classification):** if the \~129M "rescue" flow proves operator-controlled rather than a verifiable independent custodian, the disposition is adjacent to **OAK-T5.007** (custodial soft-rug / exit-or-rescue-as-single-coordinated-sweep), **OAK-T11.010** (off-chain counterparty / custodian risk), and **OAK-T6.007** (trust-substrate shift — a self-custody product reframed mid-incident as a claim-to-a-custodian); the unverified "qualified third-party custodian" claim is the concern OAK-T11.005.002 (fake-custodian) exists to capture. On-chain, a cohort-wide sweep of predictable-key wallets by an attacker is **indistinguishable** from a sweep of the same wallets to a "rescue" address — which is exactly why the disposition cannot be settled from flow shape alone. + +**Attribution:** **pseudonymous.** No named entity. SlowMist's Cos tracked suspected attacker addresses (transfers cascading from larger to smaller amounts over hours, consistent with a batch of compromised keys); community trackers tagged the \~129M-receiving address (`addr1q8g8c…7vuz99`, created 2026-06-22 17:34 UTC) as an exploiter ("William-qa"), while SecondFi characterised the same flow as a custodial rescue. Entity attribution is unresolved and the rescue-vs-theft question is open as of 2026-06-24. + +**Key teaching point:** **When a wallet provider's own key-generation software is the root cause, the compromised population is the entire generated cohort — and "do nothing, wait for us" is the wrong guidance.** The load-bearing T11.004 lesson applies directly: predictable-RNG keys remain drainable until the funds are moved to a **freshly, properly generated key**, so the only protective action for a holder is **generate a brand-new wallet (new seed) with a different, audited generator and move funds immediately** — which matches the "move assets to new wallets immediately / generate new keys with a different provider" guidance independent outlets reported SecondFi also issued. The narrower public message the maintainer-supplied posts emphasised — *"DO NOT restore your recovery phrase into a new Cardano wallet"* — is **technically correct only in the literal sense** that restoring the *same* predictable phrase elsewhere does not help (the key is still derivable); it is **not** a reason to leave funds in place. The accompanying "do nothing until official steps / submit a claim" framing is the part defenders and users should treat with skepticism: for a weak-entropy cohort, inaction is the failure mode (the half-life-of-known-vulnerability tail), and a "rescue to a custodian" that cannot be independently verified on-chain is not a substitute for the holder controlling a clean key. + +## Summary + +**SecondFi** is a Cardano (ADA) web-wallet/platform (reported by Crypto Briefing to be an April-2026 rebrand of a prior "Yoroi"-branded web wallet — single-source, noted but not relied upon). On **2026-06-23** it disclosed a security incident, suspended services / entered maintenance mode, and traced the root cause to **its native Cardano web-wallet generation software, which generated private keys with insufficient/predictable randomness**. That defect makes every key produced by the affected software iteration derivable by an attacker, so the exposed population is the full generated cohort rather than a handful of phished users. + +Confirmed theft is reported at **\~16M ADA (\~\$2.4M)** across **\~178 wallets** (independent reporting) / **374 addresses** (SecondFi's own count), executed as several draining events by external actor(s). SlowMist placed **total potential exposure above \$20M (up to \~129M ADA)** on the reasoning that un-drained predictable-key wallets remain vulnerable. + +Separately, SecondFi stated it triggered **emergency "rescue" measures securing \~129M ADA to an independent third-party custodian** and engaged an external accounting firm to verify the holdings, directing affected users to submit claims at `support.secondfi.io` and to **not restore their recovery phrase into another Cardano wallet**. On-chain trackers and SlowMist associated the large flows with **attacker-linked addresses**, and community members publicly questioned whether the "custodian" address is in fact an exploiter. The rescue-vs-theft disposition of the \~129M flow is **unresolved** at the time of writing. + +## Timeline (UTC) + +| When | Event | OAK ref | +|---|---|---| +| Pre-2026-06 | SecondFi's native Cardano web-wallet generation software produces user keys with predictable randomness (standing latent cohort) | (standing T11.004 surface) | +| 2026-06-22 17:34 | Address `addr1q8g8c…7vuz99` (later the \~129M-ADA recipient; disputed rescue-custodian vs attacker) is created | — | +| 2026-06-22 → 06-23 | External actor(s) derive keys and drain wallets; transfers cascade from larger to smaller amounts over hours (SlowMist/Cos) | **T11.004** | +| 2026-06-23 | SecondFi discloses the incident, suspends services, attributes root cause to its web-wallet key-generation software; says it rolled out a patch for unaffected wallets | (operator response) | +| 2026-06-23 → 06-24 | SecondFi states \~129M ADA was "rescued" to a third-party custodian; advises users to **not** restore recovery phrases and to submit claims at `support.secondfi.io`; independent outlets report SecondFi also urged moving assets to new wallets / new keys | (disputed disposition) | +| 2026-06-24 | Community trackers + SlowMist link the \~129M flow to attacker-tagged addresses; rescue-vs-theft remains contested; "hacker still actively draining" reports | **T11.004** (active cohort tail) | + +## Public references + +- `[secondfix2026]` — SecondFi (@secondfiapp), incident statements on X (root-cause "at the address level / risk when a transaction is signed"; "DO NOT restore your recovery phrase into a new Cardano wallet"; \~129M ADA "rescue" to a third-party custodian; claims at `support.secondfi.io`): +- `[cryptobriefingsecondfi2026]` — Crypto Briefing, "SecondFi exploit drains over \$20M from Cardano users as wallet key generation flaw exposed" (predictable-randomness key generation; \~178 wallets; "generate new keys using a different wallet provider and transfer your funds"; reported Yoroi rebrand): +- `[cryptonewssecondfi2026]` — crypto.news, "Cardano project SecondFi faces \$20m loss warning after flaw" (native Cardano web-wallet generation software; SlowMist/Cos batch-of-keys analysis; ADA \~\$0.15): +- `[beincryptosecondfi2026]` — BeInCrypto, "Cardano Project SecondFi Hit by Major Exploit, Losses Could Top \$20 Million": +- `[cryptotimessecondfi2026]` — The Crypto Times, "Cardano Project SecondFi Halts Services as Hack Estimates Hit \$20M": +- `[adastatsecondfiaddr2026]` — AdaStat, tracked address `addr1q8g8cgwqw98q2mrzrwgcy3wectdxwem8a8zp9r2mn6wjy7q4x7gcpv39wwurj7n72akw4kd0dgmv72gz4j92fvhn29ss7vuz99` (created 2026-06-22 17:34 UTC; \~129M-ADA recipient; role disputed): + +## Discussion + +SecondFi is OAK's first **non-EVM, wallet-provider-software** anchor for **T11.004 (Insufficient-Entropy Key Generation)**. The existing v0.x anchors are EVM/Profanity vanity-generator cases (Wintermute institutional scale; the Profanity cohort tail); SecondFi extends the class to a **Cardano consumer wallet provider whose own generation software shipped predictable randomness** — the same cryptographic failure mode at the moment of key creation, at population scale, with no on-chain or runtime signal until disclosure. The two load-bearing T11.004 properties recur cleanly here: (1) the **compromised population is computable** from the affected software iteration rather than per-victim, so SlowMist's "every wallet may be compromised, including un-drained ones" framing is the expected cohort-enumeration signal, not alarmism; and (2) the **half-life-of-known-vulnerability-after-disclosure** is the operative risk — un-rotated keys keep getting drained, which is why "do nothing and wait for official steps" is precisely the wrong user-side posture and **immediate rotation to a cleanly generated key** is the only protective action a holder can take unilaterally. + +The element that makes this case worth preserving beyond a routine T11.004 entry is the **disposition dispute**. SecondFi describes a \~129M ADA "emergency rescue" to a "qualified third-party custodian," and instructs affected users to take no self-custody action and instead submit claims. On-chain analysts (SlowMist) and community trackers instead associate the large flows with attacker-linked addresses. OAK's neutral-framing convention is the right tool here: **the mechanism (predictable key generation) is what makes this an attack and is multi-source confirmed; the disposition (rescued / attacker-controlled / laundered) is contested metadata that does not change the classification.** It is worth recording explicitly that, for a weak-entropy cohort, an attacker sweeping every derivable key into one address and a custodian sweeping the same wallets "for safekeeping" are **on-chain indistinguishable by flow shape**; settling rescue-vs-theft requires independent verification of who controls the recipient address (the accounting-firm attestation SecondFi says is underway, corroborated against the addresses SlowMist is tracking), not inference from the sweep pattern alone. Until that lands, the prudent defender reading is that an unverifiable "custodian" claim is not protection, and the maturity-appropriate attribution is **pseudonymous**. + +If forensic confirmation later establishes the \~129M flow as operator-controlled and the "rescue/claim" process as a value-capture mechanism, this example should be re-mapped to add **T5.007 / T11.010** as a co-primary disposition classification (custodial soft-rug / off-chain counterparty), with T11.004 remaining the root-cause mechanism. If it is confirmed as a genuine white-hat-style rescue, the disposition note stands as documented and the example remains a clean T11.004 wallet-provider-software anchor. Either resolution is consistent with the entry as written; the entry's job at v0.x is to record the confirmed mechanism and the open disposition honestly rather than to pre-judge the contested flow. diff --git a/index.html b/index.html index a22b9fa..bb83c60 100644 --- a/index.html +++ b/index.html @@ -16,7 +16,7 @@ - + @@ -26,7 +26,7 @@ - + diff --git a/techniques/T11.004-insufficient-entropy-key-generation.md b/techniques/T11.004-insufficient-entropy-key-generation.md index 4355de3..88cae0c 100644 --- a/techniques/T11.004-insufficient-entropy-key-generation.md +++ b/techniques/T11.004-insufficient-entropy-key-generation.md @@ -41,6 +41,7 @@ T11.004's load-bearing operational property is the **half-life-of-known-vulnerab ### Additional incidents - [`examples/2022-2025-custody-infrastructure-compromise-cohort.md`](../examples/2022-2025-custody-infrastructure-compromise-cohort.md) — Custody infrastructure compromise cohort, 2022–2025; combined T11.003 + T11.004 cohort-level anchor +- [`examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md`](../examples/2026-06-secondfi-cardano-web-wallet-predictable-key-generation-drain.md) — SecondFi Cardano web-wallet predictable key generation drain, 2026-06 (developing; first non-EVM / wallet-provider-software T11.004 anchor — confirmed mechanism, disputed \~129M ADA "custodian rescue" disposition) ## Reference implementations