Skip to content

[examples] SecondFi Cardano predictable key-generation drain (T11.004) #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
iZonex merged 2 commits into from
Jul 3, 2026
Merged

[examples] SecondFi Cardano predictable key-generation drain (T11.004) #1

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fbdd022
[examples] add SecondFi Cardano predictable key-generation drain (646…
iZonex Jun 24, 2026
1ad7636
[examples] add 5 late-June 2026 incidents (647 -> 652)
iZonex Jul 3, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions BACKLOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# OAK Backlog — auto-generated

_Generated by `tools/build_backlog.py` on 2026-06-24. Regenerated on every `npm run site:data`._
_Generated by `tools/build_backlog.py` on 2026-07-03. Regenerated on every `npm run site:data`._

_Scope: 646 worked examples, 146 Techniques, 19 Threat Actors._
_Scope: 652 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`.

Expand Down
30 changes: 15 additions & 15 deletions STATS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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-07-03 15:51 UTC._

## Catalogue

- **17** Tactics · **146** Techniques · **19** Threat Actors · **43** Mitigations · **41** Software · **12** Data Sources
- **646** Worked Examples · **1555** bibtex entries
- **652** Worked Examples · **1555** bibtex entries

## Examples by Tactic

Expand All @@ -14,14 +14,14 @@ _Auto-generated by `tools/build_stats.py` at 2026-06-24 10:43 UTC._
| T1 (Token Genesis) | 40 |
| T2 (Liquidity Establishment) | 32 |
| T3 (Holder Capture) | 36 |
| T4 (Access Acquisition) | 75 |
| T5 (Value Extraction) | 113 |
| T6 (Defense Evasion) | 52 |
| T7 (Laundering) | 152 |
| T4 (Access Acquisition) | 78 |
| T5 (Value Extraction) | 114 |
| T6 (Defense Evasion) | 55 |
| T7 (Laundering) | 156 |
| T8 (Operator Continuity / Attribution Signals) | 82 |
| T9 (Smart-Contract Exploit) | 203 |
| T10 (Bridge / Cross-Chain) | 55 |
| T11 (Custody / Signing) | 144 |
| T9 (Smart-Contract Exploit) | 204 |
| T10 (Bridge / Cross-Chain) | 56 |
| T11 (Custody / Signing) | 146 |
| T12 (NFT-Specific) | 31 |
| T13 (Account Abstraction) | 20 |
| T14 (Validator / Staking) | 39 |
Expand All @@ -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 | 68 |

## Examples by Year-Month (recent dense window)

Expand Down Expand Up @@ -75,16 +75,16 @@ _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 | 20 |

## Attribution-strength Distribution

| Strength | Count |
| --- | ---: |
| pseudonymous | 305 (47.2%) |
| unattributed | 149 (23.1%) |
| confirmed | 125 (19.3%) |
| inferred-strong | 64 (9.9%) |
| pseudonymous | 308 (47.2%) |
| unattributed | 152 (23.3%) |
| confirmed | 125 (19.2%) |
| inferred-strong | 64 (9.8%) |
| inferred-weak | 3 (0.5%) |

## Threat Actors
Expand Down
54 changes: 54 additions & 0 deletions examples/2026-06-eleven-drainer-legit-subdomain-frontend-compromise-cohort.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
# "Eleven drainer" injected into legitimate project subdomains — Gitcoin and Yield Yak — Ethereum / Avalanche — 2026-06 (June 21 and 24)

> **Status: detection-stage cohort (as of 2026-06).** Both incidents were surfaced by Blockaid as front-end compromise alerts, not post-mortems. Neither project nor Blockaid published a confirmed theft total, and the initial-access vector for either subdomain was not disclosed. This entry documents the confirmed mechanism (a legitimate project subdomain serving a wallet-drainer script) and marks losses and access vector as open.

**Loss:** **Undisclosed for both incidents.** On **2026-06-21** Blockaid flagged the **`files.gitcoin.co`** subdomain (Gitcoin, Ethereum) as serving injected "Eleven drainer" code, and on **2026-06-24** it flagged **`vote.yieldyak.com`** (Yield Yak, Avalanche) with the same kit. In both cases a secondary subdomain of the real project was compromised while the main application was not implicated, and the alerts warned users off before any confirmed theft total was published. Because these were detection-stage warnings rather than settled post-mortems, no dollar figure is attached to either; the impact recorded here is user exposure for anyone who connected a wallet to the poisoned page during the window.

**OAK Techniques observed:** **OAK-T6.008** (Verified-but-Malicious Frontend Routing — *primary, confirmed mechanism*. A legitimate, project-owned subdomain served an injected wallet-drainer script, so the malicious code ran behind a trusted domain rather than a look-alike clone. See [`techniques/T6.008-verified-but-malicious-frontend-routing.md`](../techniques/T6.008-verified-but-malicious-frontend-routing.md)). **OAK-T4.004** (Allowance / Approve-Pattern Drainer — the "Eleven drainer" script pushes a connecting wallet to approve or sign hostile transactions, granting the operator permission to move assets; this is the drainer's extraction primitive. See [`techniques/T4.004-allowance-approve-drainer.md`](../techniques/T4.004-allowance-approve-drainer.md)). The **initial-access vector that let the attacker inject code into each subdomain was not disclosed** (candidates in this class include registrar / DNS, hosting or object-storage, and CI or package-registry credential compromise, which is OAK-T15.004); OAK does not assert a specific vector here because none was published.

**Attribution:** **unattributed.** The only attribution is toolkit-level: both incidents used the **"Eleven drainer"** kit, a drainer-as-a-service offering that first surfaced publicly around November 2025 (flagged by SlowMist's Yu Xian) alongside established kits such as Inferno Drainer and Angel Drainer. Because the kit is rented, its presence does not identify the operator behind these specific deployments, and no operator, affiliate roster or wallet cluster was published for either the Gitcoin or Yield Yak instance.

**Key teaching point:** **A wallet-drainer served from a project's own subdomain defeats the defenses built for fake clones, because the domain is genuinely the project's.** Users and allowlist tooling that check for look-alike domains (the fake-clone pattern in [`examples/2023-2026-fake-dex-clone-frontend-cohort.md`](2023-2026-fake-dex-clone-frontend-cohort.md)) do not flag `files.gitcoin.co` or `vote.yieldyak.com`, which really do belong to Gitcoin and Yield Yak. The compromise is at the web-delivery and access-control layer of the real project: a secondary subdomain that is easy to overlook in asset inventories, injected with a drainer that solicits approvals on wallet connect. The controls that apply are hardening every project-owned subdomain and its hosting to the same standard as the main app, subresource integrity and a content-security policy that constrains injected scripts, monitoring project domains for unexpected script changes, and client-side approval-warning tooling that flags a hostile approval regardless of which domain raised it. The recurrence of the same kit against a second legitimate project three days later is the signal that this is a repeatable playbook, not a one-off.

## Summary

In June 2026, the security detection firm **Blockaid** flagged two legitimate DeFi projects whose secondary subdomains had been injected with the **"Eleven drainer"** wallet-draining script. On **2026-06-21** the affected host was **`files.gitcoin.co`** (Gitcoin, on Ethereum); on **2026-06-24** it was **`vote.yieldyak.com`** (Yield Yak, an Avalanche auto-compounding yield-vault and aggregator). In both cases the main application interface was not implicated, and the compromise was scoped to a secondary subdomain.

The injected script is a client-side drainer: when a user connects a wallet to the poisoned page, it pushes them to approve or sign hostile transactions, granting the operator standing permission to move assets. This is a website-layer compromise, not a smart-contract exploit. Neither project nor Blockaid published a confirmed loss figure at the time of the alerts, which were framed as warnings to keep users off the affected subdomains. The way each subdomain was initially compromised was not disclosed.

The two incidents share a detector (Blockaid), a kit (Eleven drainer), and a target pattern (a secondary subdomain of a real project rather than the main app), three days apart. "Eleven drainer" is a rentable drainer-as-a-service; its operators take a cut of stolen funds, and the model relies on rushed user approvals rather than a novel on-chain exploit.

| Incident | Date | Chain | Compromised host | Kit | Confirmed loss |
|---|---|---|---|---|---|
| Gitcoin | 2026-06-21 | Ethereum | `files.gitcoin.co` (secondary subdomain) | Eleven drainer | Undisclosed |
| Yield Yak | 2026-06-24 | Avalanche | `vote.yieldyak.com` (secondary subdomain) | Eleven drainer | Undisclosed |

## Timeline (UTC)

| When | Event | OAK ref |
|---|---|---|
| Pre-2026-06-21 | Attacker gains the ability to inject code into `files.gitcoin.co` (vector not disclosed) | **T15.004** (candidate, undisclosed) |
| 2026-06-21 | Blockaid flags Eleven drainer code on `files.gitcoin.co`; main Gitcoin app not implicated; users warned off | **T6.008 + T4.004** |
| Pre-2026-06-24 | Attacker gains the ability to inject code into `vote.yieldyak.com` (vector not disclosed) | **T15.004** (candidate, undisclosed) |
| 2026-06-24 | Blockaid flags the same Eleven drainer kit on `vote.yieldyak.com`; framed as the same playbook three days after Gitcoin | **T6.008 + T4.004** |

## What defenders observed

- **Pre-event (subdomain and hosting hardening).** Both targets were secondary subdomains, the kind that fall out of asset inventories and change-control. Applying the same hosting, DNS, registrar and CI hardening to every project-owned subdomain as to the main app is the pre-event control. The specific access vector was not published, so the candidate set (DNS/registrar, hosting/object-storage, CI/package-registry credential compromise) is where hardening should concentrate.
- **At-event (trusted domain defeats clone defenses).** The malicious code ran on a real project subdomain, so look-alike-domain checks and clone allowlists did not apply. Subresource integrity, a content-security policy, and monitoring for unexpected script changes on project domains are the delivery-layer controls that do apply.
- **At-event (approval prompt on connect).** The drainer solicits approvals when a wallet connects. Client-side approval-warning and transaction-simulation tooling that flags a hostile approval independent of the originating domain is the user-facing control.
- **Cohort signal (repeatable playbook).** The same kit hit a second legitimate project three days later. Treat a confirmed drainer-on-legitimate-subdomain as a pattern to sweep for across peer projects, not a single-project cleanup.

## Public references

- `[blockaidgitcoin2026]` — Blockaid, detection alert naming "Eleven drainer" code on `files.gitcoin.co` (Gitcoin, 2026-06-21; user warning): <https://x.com/blockaid_/status/2068534795684946308>
- `[cryptoeconomyyieldyak2026]` — Crypto Economy, "Yield Yak Suffers Front-End Breach in Latest Wave of Wallet-Drainer Hacks" (Yield Yak / `vote.yieldyak.com`; losses unconfirmed; same-playbook framing): <https://crypto-economy.com/yield-yak-suffers-front-end-breach/>
- `[cryptorankyieldyak2026]` — CryptoRank, "Yield Yak follows Gitcoin in latest wallet-drainer attack" (links the two incidents three days apart as the same pattern): <https://cryptorank.io/news/feed/4aa0a-yield-yak-gitcoin-in-wallet-drainer-attack>
- `[cryipjune2026]` — cryip, "June 2026 Crypto Hack Report" (both logged as front-end attacks with undisclosed losses; confirms chains: Gitcoin/Ethereum, Yield Yak/Avalanche): <https://cryip.co/june-2026-crypto-hack-report-45-blockchain-security-incidents/>
- `[spaziocryptoeleven2026]` — spaziocrypto, background on "Eleven drainer" as a drainer-as-a-service kit (SlowMist / Yu Xian identification ~2025-11; comparison to Inferno / Angel): <https://en.spaziocrypto.com/hack/new-eleven-drainer-attack-threat-to-crypto-wallets/>

## Discussion

This cohort anchors the case where a wallet drainer is served from a project's own subdomain rather than a look-alike clone. It sits next to OAK's drainer-service coverage (the Inferno Drainer handover and the encrypted-config "Reloaded" cases) on the kit side, and next to the fake-DEX clone-frontend cohort on the delivery side, but it is neither: the domain is authentic, and the compromise is of the real project's web-delivery and access-control surface. That is what makes T6.008 the primary mapping, with T4.004 as the drainer's approval-based extraction.

Two properties give the pair its teaching value. First, trusted-domain delivery defeats the defenses built for clones, so the control set shifts to subdomain and hosting hardening, subresource integrity, content-security policy, and domain script-change monitoring rather than user education about fake URLs. Second, the same rented kit reappearing against a second legitimate project within three days marks a repeatable playbook, which argues for treating one confirmed instance as a prompt to sweep peer projects' subdomains. The entry is deliberately detection-stage: losses and initial-access vectors were not disclosed, so OAK records the confirmed subdomain-plus-drainer mechanism and leaves the theft totals and access vectors open, to be revised if either project publishes a post-mortem.
Loading
Loading