From 67eda001ea93bb5679d3cea0908a445aced7d74a Mon Sep 17 00:00:00 2001 From: CyberStrategy1 Date: Sun, 17 May 2026 14:58:55 -0400 Subject: [PATCH] CryptoShield-upload --- .github/ISSUE_TEMPLATE/control-update.md | 47 + .github/ISSUE_TEMPLATE/new-threat-entry.md | 72 + .github/workflows/taxonomy-lint.yml | 132 ++ 00-cross-domain/README.md | 41 + 01-wallet-key-sovereignty/README.md | 234 +++ 02-endpoint-device-defense/README.md | 216 +++ 03-opsec-physical-security/README.md | 232 +++ 04-social-media-platform-security/README.md | 243 +++ 05-on-chain-monitoring/README.md | 247 +++ 06-supply-chain-defense/README.md | 289 +++ 07-ai-agent-security/README.md | 73 + .../README.md | 243 +++ 09-consumer-fraud-defense/README.md | 279 +++ assets/framework-architecture.svg | 99 + intelligence/TEMPLATE.md | 105 + metadata/threat-event-schema.json | 355 ++++ playbooks/consumer-fraud.md | 115 ++ playbooks/physical-coercion.md | 80 + playbooks/wallet-compromise.md | 121 ++ research/001_wrench_attack_epidemic.md | 145 ++ research/002_rotator_effect.md | 133 ++ research/003_dprk_attribution_analysis.md | 158 ++ research/004_ai_agent_attack_surface.md | 50 + research/005_supply_chain_vectors.md | 49 + research/006_pig_butchering_anatomy.md | 58 + research/007_false_flag_forensics.md | 236 +++ taxonomy/bridge-risk-appendix.md | 166 ++ taxonomy/ctrs-scoring.md | 184 ++ taxonomy/registry-table.md | 99 + taxonomy/registry.json | 1685 +++++++++++++++++ taxonomy/threat-architecture.md | 208 ++ tools/30-day-hardening-sprint.md | 155 ++ tools/sovereignty-self-assessment.md | 552 ++++++ 33 files changed, 7101 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/control-update.md create mode 100644 .github/ISSUE_TEMPLATE/new-threat-entry.md create mode 100644 .github/workflows/taxonomy-lint.yml create mode 100644 00-cross-domain/README.md create mode 100644 01-wallet-key-sovereignty/README.md create mode 100644 02-endpoint-device-defense/README.md create mode 100644 03-opsec-physical-security/README.md create mode 100644 04-social-media-platform-security/README.md create mode 100644 05-on-chain-monitoring/README.md create mode 100644 06-supply-chain-defense/README.md create mode 100644 07-ai-agent-security/README.md create mode 100644 08-governance-compliance-sovereignty/README.md create mode 100644 09-consumer-fraud-defense/README.md create mode 100644 assets/framework-architecture.svg create mode 100644 intelligence/TEMPLATE.md create mode 100644 metadata/threat-event-schema.json create mode 100644 playbooks/consumer-fraud.md create mode 100644 playbooks/physical-coercion.md create mode 100644 playbooks/wallet-compromise.md create mode 100644 research/001_wrench_attack_epidemic.md create mode 100644 research/002_rotator_effect.md create mode 100644 research/003_dprk_attribution_analysis.md create mode 100644 research/004_ai_agent_attack_surface.md create mode 100644 research/005_supply_chain_vectors.md create mode 100644 research/006_pig_butchering_anatomy.md create mode 100644 research/007_false_flag_forensics.md create mode 100644 taxonomy/bridge-risk-appendix.md create mode 100644 taxonomy/ctrs-scoring.md create mode 100644 taxonomy/registry-table.md create mode 100644 taxonomy/registry.json create mode 100644 taxonomy/threat-architecture.md create mode 100644 tools/30-day-hardening-sprint.md create mode 100644 tools/sovereignty-self-assessment.md diff --git a/.github/ISSUE_TEMPLATE/control-update.md b/.github/ISSUE_TEMPLATE/control-update.md new file mode 100644 index 0000000..fff9ed8 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/control-update.md @@ -0,0 +1,47 @@ +--- +name: Control Update +about: Propose an update to an existing CryptoSHIELD control +title: "[CONTROL] [DOMAIN-ID]: Control Update" +labels: control-update +assignees: '' + +--- + +## Control Update Proposal + +**Control ID:** (e.g., WKS-03) +**Domain:** (e.g., Domain 01: Wallet and Key Sovereignty) +**Update Type:** +- [ ] Implementation guidance update +- [ ] Priority change (with justification) +- [ ] New failure mode identified +- [ ] Threat coverage expansion +- [ ] Deprecation + +## Current Control Text + +> Paste the existing control definition and implementation guidance here. + +## Proposed Change + +Describe what should change and why. + +## Evidence for Change + +What has changed in the threat landscape, technology, or available tooling that requires this update? + +1. [Evidence source 1] +2. [Evidence source 2] + +## Impact Assessment + +- Does this change affect CTRS scores for related threats? +- Does this change require updates to related playbooks? +- Does this create compatibility issues with AI SAFE² or CSF companion controls? + +## Adversarial Reproduction Test + +An independent analyst should arrive at the same proposed change using the same evidence. Confirm: [ ] Evidence is publicly verifiable + +--- +*CSI CryptoSHIELD Framework | Contributor: @yourhandle* diff --git a/.github/ISSUE_TEMPLATE/new-threat-entry.md b/.github/ISSUE_TEMPLATE/new-threat-entry.md new file mode 100644 index 0000000..0602a43 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/new-threat-entry.md @@ -0,0 +1,72 @@ +--- +name: New Threat Entry +about: Submit a new threat for inclusion in the CryptoSHIELD taxonomy +title: "[THREAT] CS-XXX-00: Threat Name" +labels: new-threat, taxonomy +assignees: '' + +--- + +## Threat Proposal + +**Proposed Threat ID:** (follow existing convention: CS-[CATEGORY]-[NUMBER]) +**Category:** (PHY / INS / SOC / MAL / WAL / DFI / SC / AI / MKT / SOV / FRD / EXT) +**Threat Name:** + +## Threat Description + +Describe the attack in concrete terms. What does the attacker do? What is the victim's experience? + +## Attack Vector + +How is this attack delivered to the victim? + +## OODA Phase + +Which OODA phase does this attack primarily operate in? +- [ ] Observe +- [ ] Orient +- [ ] Decide +- [ ] Act + +## Evidence + +**Documented Cases (minimum 2 required):** +1. [Case 1: date, platform/target, loss amount, source link] +2. [Case 2: date, platform/target, loss amount, source link] + +**Financial Scale:** +Estimated annual losses or incident volume: + +## CTRS Scoring Proposal + +Rate each component (0-4): +- Likelihood (L): ___ | Rationale: +- Impact on Sovereignty (I): ___ | Rationale: +- Reach/Scale (R): ___ | Rationale: +- Detection Difficulty (D): ___ | Rationale: +- Recovery Difficulty (RecD): ___ | Rationale: + +**Proposed CTRS:** (use formula from taxonomy/ctrs-scoring.md) + +## Proposed Controls + +What 1-3 controls would mitigate this threat? Refer to existing controls where possible. + +1. +2. +3. + +## Adversarial Reproduction Test + +An independent analyst using the same sources and methodology should arrive at the same threat classification and CTRS score. Provide sufficient documentation for this test to pass. + +## Metadata Tags + +- `false_flag_prob`: (float 0.0-1.0) +- `insider_vector`: (true/false) +- `ai_assisted`: (true/false) +- `sovereignty_impact`: (LOW/MEDIUM/HIGH/CRITICAL) + +--- +*CSI CryptoSHIELD Framework | Contributor: @yourhandle* diff --git a/.github/workflows/taxonomy-lint.yml b/.github/workflows/taxonomy-lint.yml new file mode 100644 index 0000000..ec269b2 --- /dev/null +++ b/.github/workflows/taxonomy-lint.yml @@ -0,0 +1,132 @@ +name: Taxonomy Integrity Check + +on: + push: + paths: + - 'taxonomy/registry.json' + - 'metadata/threat-event-schema.json' + pull_request: + paths: + - 'taxonomy/**' + - 'metadata/**' + +jobs: + validate-registry: + runs-on: ubuntu-latest + name: Validate Threat Registry + + steps: + - uses: actions/checkout@v5 + + - name: Set up Node.js + uses: actions/setup-node@v5 + with: + node-version: '22' + + - name: Install ajv-cli for JSON Schema validation + run: npm install -g ajv-cli ajv-formats + + - name: Validate registry.json against schema + run: | + ajv validate \ + -s metadata/threat-event-schema.json \ + -d taxonomy/registry.json \ + --all-errors \ + --strict=false \ + 2>&1 || echo "::warning::Schema validation produced warnings" + + - name: Check CTRS scores are within range + run: | + python3 - <<'EOF' + import json + import sys + + with open('taxonomy/registry.json') as f: + data = json.load(f) + + errors = [] + threats = data.get('threats', data) if isinstance(data, dict) else data + + if isinstance(threats, dict): + threats = list(threats.values()) + + for threat in threats: + tid = threat.get('id', 'UNKNOWN') + ctrs = threat.get('ctrs_score') + if ctrs is not None: + if not (0 <= ctrs <= 20): + errors.append(f"{tid}: CTRS score {ctrs} out of range (0-20)") + severity = threat.get('severity', '').upper() + if severity and severity not in ['CRITICAL', 'HIGH', 'MEDIUM', 'LOW']: + errors.append(f"{tid}: Invalid severity '{severity}'") + + if errors: + print("::error::Registry validation errors:") + for e in errors: + print(f" - {e}") + sys.exit(1) + else: + print(f"Registry validation passed: {len(threats)} threats checked") + EOF + + - name: Check threat ID uniqueness + run: | + python3 - <<'EOF' + import json + import sys + + with open('taxonomy/registry.json') as f: + data = json.load(f) + + threats = data.get('threats', data) if isinstance(data, dict) else data + if isinstance(threats, dict): + threats = list(threats.values()) + + ids = [t.get('id') for t in threats if t.get('id')] + duplicates = [id for id in set(ids) if ids.count(id) > 1] + + if duplicates: + print(f"::error::Duplicate threat IDs found: {duplicates}") + sys.exit(1) + else: + print(f"ID uniqueness check passed: {len(ids)} unique IDs") + EOF + + validate-markdown: + runs-on: ubuntu-latest + name: Validate Domain Documentation + + steps: + - uses: actions/checkout@v5 + + - name: Check all domain READMEs exist + run: | + domains=( + "00-cross-domain" + "01-wallet-key-sovereignty" + "02-endpoint-device-defense" + "03-opsec-physical-security" + "04-social-media-platform-security" + "05-on-chain-monitoring" + "06-supply-chain-defense" + "07-ai-agent-security" + "08-governance-compliance-sovereignty" + "09-consumer-fraud-defense" + ) + missing=0 + for d in "${domains[@]}"; do + if [ ! -f "${d}/README.md" ]; then + echo "::warning::Missing README: ${d}/README.md" + missing=$((missing + 1)) + fi + done + echo "Domain README check: $missing missing" + + - name: Check for em dashes in all markdown files + run: | + # CSI style: no em dashes + if grep -r " — " --include="*.md" . 2>/dev/null | grep -v ".git"; then + echo "::warning::Em dashes found in markdown files. Replace with colon, semicolon, or parentheses." + else + echo "Em dash check passed" + fi diff --git a/00-cross-domain/README.md b/00-cross-domain/README.md new file mode 100644 index 0000000..8148705 --- /dev/null +++ b/00-cross-domain/README.md @@ -0,0 +1,41 @@ +# Domain 00: Cross-Domain Sovereignty Governance (CDG) + +**CSI CryptoSHIELD Framework v1.1 | May 2026** + +--- + +## Philosophy + +Sovereignty is not a feature. It is the architecture. + +Every control in every other domain derives its legitimacy from this domain's foundational commitment: individual sovereignty over financial assets is a constitutional right, not a privilege granted by regulatory permission. The January 2025 Executive Order, the Fifth Circuit Tornado Cash ruling, and the CTA enforcement blocks by federal courts are not policy preferences: they are legal affirmations of what CryptoSHIELD operationalizes. + +This domain sets the governance context that all other domains operate within. It does not replace legal counsel. It establishes the constitutional and philosophical alignment of the entire framework. + +--- + +## Controls + +| Control | Description | Priority | +|---------|-------------|---------| +| CDG-01 | Sovereignty-First Policy Declaration: explicit written commitment to self-custody as the default | CRITICAL | +| CDG-02 | U.S. Constitutional Alignment Protocol: framework review against applicable court rulings quarterly | HIGH | +| CDG-03 | CBDC Non-Adoption Commitment: documented organizational policy against CBDC participation | CRITICAL | +| CDG-04 | Self-Custody Rights Documentation: maintain documented record of self-custody rights per jurisdiction | HIGH | +| CDG-05 | Annual Sovereignty Architecture Review: annual comprehensive review of all framework controls against updated threat and regulatory landscape | HIGH | + +--- + +## U.S. Constitutional Alignment Reference + +| Legal Precedent | Relevance | CryptoSHIELD Alignment | +|----------------|-----------|------------------------| +| Trump EO, January 2025 | Self-custody rights protected; CBDC prohibited | CDG-01, CDG-03, GCS-01, GCS-02 | +| Fifth Circuit: Tornado Cash (November 2024) | Immutable smart contracts not "property" under IEEPA | GCS-03 (legal awareness) | +| FinCEN CTA enforcement blocked (January 2025) | Reporting overreach blocked by courts | GCS-03, GCS-04 | +| March 2026 SEC/CFTC joint interpretation | Most crypto assets confirmed not securities | GCS-03 | +| GENIUS Act | AML at CEX boundary; innovation-preserving | GCS-04 | + +--- + +*Domain 00: Cross-Domain Sovereignty Governance | CryptoSHIELD v1.1* diff --git a/01-wallet-key-sovereignty/README.md b/01-wallet-key-sovereignty/README.md new file mode 100644 index 0000000..eb5747a --- /dev/null +++ b/01-wallet-key-sovereignty/README.md @@ -0,0 +1,234 @@ +# Domain 01: Wallet and Key Sovereignty (WKS) + +**CSI CryptoSHIELD Framework v1.1 | May 2026** + +--- + +## Philosophy + +> Not your keys. Not your crypto. Full stop. + +Every other security domain in CryptoSHIELD supports this one. The endpoint can be perfectly hardened. The OPSEC can be flawless. The supply chain can be fully verified. None of it matters if your seed phrase is in a cloud note, your hardware wallet is the only one on a 2-of-3 multisig, or you are signing transactions you cannot independently verify. + +Wallet and key sovereignty is the terminal defense. If this layer fails, nothing else saves you. + +--- + +## Controls + +### WKS-01: Hardware Wallet for All Holdings Above $1,000 + +**Priority:** CRITICAL +**Threat IDs:** CS-WAL-01, CS-WAL-04 + +**Implementation:** +- Ledger, Trezor, or Coldcard for all holdings exceeding $1,000 USD equivalent +- Hardware wallet must be purchased directly from manufacturer: never secondhand or through marketplace resellers +- Verify firmware authenticity on first connection (manufacturer verification protocol) +- Enable PIN with sufficient entropy (8+ characters, not birthday or sequential) + +**Why this matters:** Software wallets on internet-connected devices expose private keys to any malware with memory access. Hardware wallets maintain the private key in isolated secure element storage that never exposes the key to the connected machine: the transaction is signed inside the hardware and only the signature (not the key) is transmitted. + +**Edge case:** Hardware wallets are physical objects that can be physically seized. WKS-01 solves the digital attack surface but increases physical coercion risk if holdings are visible. Pair with OPS-01 and OPS-06. + +--- + +### WKS-02: Multisig with Geographic Diversity + +**Priority:** CRITICAL +**Threat IDs:** CS-INS-01, CS-DFI-01 + +**Implementation:** +- Minimum 2-of-3 multisig for holdings above $50,000 +- Signers must be in physically separate locations: not the same building, city, or household +- At least one signer should be jurisdictionally separate (different country preferred for large holdings) +- Hardware wallets used for all signing positions: no software-only signers + +**The multisig masquerade failure mode:** WKS-02 is not sufficient alone if all three devices are on the same network or reachable through the same social engineering campaign. The Radiant Capital exploit (three developers, same Telegram social engineering campaign, all compromised) demonstrates that geographic diversity of hardware is not geographic diversity of trust if all signers share the same communication channels. + +**Correct implementation:** Geographic diversity + communication channel diversity + independent verification on separate devices (WKS-05). + +--- + +### WKS-03: Tiered Timelock on Governance Transactions + +**Priority:** CRITICAL +**Threat IDs:** CS-DFI-01, CS-INS-01, CS-AI-04 + +**Implementation: Tiered by Protocol TVL:** + +| Protocol Size | Minimum Timelock | Rationale | +|---|---|---| +| Individual governance wallet | 72 hours | Baseline detection window for personal transactions | +| Protocol TVL $0-$10M | 72 hours | Standard: covers most monitoring cycles and time zones | +| Protocol TVL $10M-$100M | 7 days | Extended window for community review of material changes | +| Protocol TVL >$100M | 14 days | Full governance cycle; mandatory community vote period | + +The 72-hour baseline is not sufficient for major protocols. The Euler Finance governance (2023) and several 2025 incidents demonstrated that community-identified threats require multiple days of communication, coordination, and legal review before a response can mobilize. A 72-hour window at $100M TVL gives attackers who discover the pending transaction 72 hours to front-run or counter: not 72 hours for defenders to respond. + +**Additional requirements:** +- Timelock smart contracts must be audited and independently deployed +- No timelock override capability except through a separate N-of-M key ceremony with quorum requirements exceeding the standard signing threshold +- Timelock events must trigger automated alerts to all stakeholders with sufficient detail to evaluate the pending action +- Every queued transaction should be publicly verifiable on-chain before execution + +**Why this exists:** Retrospective application of WKS-03 to the 10 largest DeFi exploits in 2024-2025 shows that 7 of 10 would have been either prevented or significantly mitigated by a protocol-appropriate timelock: including Radiant Capital, LNDFi, and multiple admin key drains. In each case, the malicious or negligent action completed in minutes. The window to detect and stop it: zero. + +--- + +### WKS-04: Seed Phrase Offline Sovereignty + +**Priority:** CRITICAL +**Threat IDs:** CS-WAL-01 + +**Implementation:** +- Seed phrase must be recorded on durable physical media: engraved metal (Cryptosteel, Billodr, or equivalent) is preferred over paper +- No digital copy ever: no photograph, no note, no cloud storage, no email, no password manager +- Seed phrase must be stored in at least two separate physical locations with access controls (fireproof safe, safety deposit box, trusted custodian arrangement) +- Split the seed phrase across locations using Shamir's Secret Sharing or geographic distribution if holdings are significant + +**What kills this control:** +- Photographing seed phrase during setup (cloud photo sync catches this) +- Typing seed phrase into any application claiming to "verify" or "check" it (any such application is a scam) +- Storing seed phrase in a password manager (password managers are high-value attack targets) +- Telling any other person the seed phrase + +**Absolute rule:** No legitimate hardware wallet, exchange, or application will ever ask you to enter your seed phrase after initial setup. Any request for seed phrase entry is an attack. + +--- + +### WKS-05: No Blind Signing + +**Priority:** CRITICAL +**Threat IDs:** CS-WAL-04, CS-INS-01 + +**Implementation:** +- Verify the raw transaction payload independently before signing: not just the UI display +- Use Tenderly, Etherscan transaction decoder, or equivalent to decode the actual calldata before signing +- Verify: contract address, function being called, parameters, value being transferred +- For protocol governance transactions: match transaction hash against what was proposed in governance forum + +**The Safe{Wallet} display manipulation:** The Radiant Capital exploit succeeded because attackers manipulated what the Safe{Wallet} interface displayed while the underlying malicious transaction was what actually got signed. Independent verification on a separate, clean device would have caught the discrepancy. + +**Practice drill:** Before signing any transaction over $1,000 in value, decode it on a device that was not used to generate the transaction request. The values must match exactly. + +--- + +### WKS-06: Independent Address Verification Protocol + +**Priority:** HIGH +**Threat IDs:** CS-WAL-02, CS-WAL-03 + +**Implementation:** +- Cross-check receiving address on an independent device before every outgoing transaction +- Never rely solely on the device that generated the transaction request to verify the address +- For large transactions (>$10,000): verify full address character by character, not just first/last 4-6 characters +- Verify address on the hardware wallet's own screen before confirming: the screen on the hardware wallet cannot be spoofed by computer malware + +**Address poisoning defense:** Attackers generate vanity addresses that match the first 4 and last 4 characters of your frequently-used receiving addresses, then send dust to create the poisoned address in your transaction history. Copy-pasting from history instead of full character verification is the failure mode. + +--- + +### WKS-07: Token Approval Revocation Protocol + +**Priority:** HIGH +**Threat IDs:** CS-WAL-04 + +**Implementation:** +- Monthly audit of all token approvals on all active wallet addresses using Revoke.cash or equivalent +- Revoke all approvals that are not actively required +- After any DeFi interaction with an unfamiliar protocol: immediate approval revocation as final step +- Set a calendar reminder: first day of each month, approval audit and revocation session + +**Why this matters:** ERC-20 approvals are persistent: an approval granted to a contract remains valid indefinitely unless explicitly revoked. A protocol that is later exploited or compromised can drain your wallet through a previously granted approval even if you have not interacted with it in months. + +--- + +### WKS-08: Permit Scam Recognition + +**Priority:** HIGH +**Threat IDs:** CS-WAL-04 + +**Implementation:** +- Never sign an EIP-2612 "permit" request from an unsolicited source +- Understand that permit signatures are off-chain signatures that grant the same authority as on-chain approvals but do not show up in the approval history visible on Revoke.cash until used +- When interacting with unfamiliar protocols, explicitly check whether any permit signature is requested +- If unsure about any signature request: reject, research the protocol independently, then return if legitimate + +**The permit scam kill chain:** +1. User visits legitimate-looking site (often via typosquatted URL or compromised DNS) +2. Site requests an off-chain EIP-2612 permit signature (appears harmless: no gas required) +3. Attacker holds the signature +4. Attacker submits the permit on-chain when ready, granting themselves spend authority +5. Token drain executed + +--- + +### WKS-09: Cold Wallet for 90%+ of Holdings + +**Priority:** CRITICAL +**Threat IDs:** CS-WAL-01, CS-MAL-02 + +**Implementation:** +- Maintain maximum 10% of total holdings in any hot wallet (actively connected to internet/applications) +- Hot wallet holding should be limited to amounts needed for active DeFi participation +- Cold wallet: hardware wallet + seed phrase metal backup + air gap or minimal connectivity +- Regular rebalancing: if hot wallet grows beyond 10% threshold through trading profits, rebalance to cold storage + +**Operational discipline:** The 90/10 rule contains the blast radius. If a hot wallet is compromised through any attack vector, maximum loss is bounded at 10% of total holdings. + +--- + +### WKS-10: Watch-Only Wallet for Household Members + +**Priority:** HIGH +**Threat IDs:** CS-PHY-01, CS-SOC-01 + +**Implementation:** +- Create watch-only wallet configurations for family members who need to monitor holdings (estate planning, shared finances) +- Watch-only wallets have viewing capability only: no signing capability +- Household members with watch-only access should not be aware of full key management structure +- Under OPS-07 (Family OPSEC): family members' knowledge of holdings should be need-to-know + +**Physical coercion consideration:** Under coercion, attackers may target family members as leverage. If family members cannot sign transactions, they cannot be coerced into executing transfers. WKS-10 + OPS-07 provide structural protection against this attack vector. + +--- + +## Domain 01 Threat Coverage Matrix + +| Threat ID | Threat Name | Controlling WKS Controls | +|-----------|-------------|--------------------------| +| CS-WAL-01 | Seed Phrase Extraction | WKS-01, WKS-04, WKS-09 | +| CS-WAL-02 | Address Poisoning | WKS-06 | +| CS-WAL-03 | DNS Hijack / Frontend Compromise | WKS-05 | +| CS-WAL-04 | Malicious Signature / Permit Drain | WKS-05, WKS-07, WKS-08 | +| CS-WAL-05 | Low Entropy Seed Generation | WKS-01 | +| CS-INS-01 | Admin Key Abuse | WKS-02, WKS-03, WKS-05 | +| CS-DFI-01 | Admin Key Exploit | WKS-02, WKS-03 | +| CS-PHY-01 | Physical Coercion | WKS-03, WKS-09 (limits accessible holdings) | + +--- + +## 30-Day WKS Hardening Sprint + +**Week 1:** +- [ ] Purchase hardware wallet from manufacturer directly (WKS-01) +- [ ] Generate seed phrase on offline device and record on metal backup (WKS-04) +- [ ] Transfer all holdings exceeding $1,000 to hardware wallet cold storage (WKS-09) +- [ ] Run Revoke.cash audit on all existing wallet addresses (WKS-07) + +**Week 2:** +- [ ] Set up 2-of-3 multisig with geographic diversity for holdings >$50K (WKS-02) +- [ ] Practice WKS-05: decode a transaction before signing (practice run with small amount) +- [ ] Enable 72-hour timelock on any protocol governance involvement (WKS-03) + +**Week 3-4:** +- [ ] Establish monthly calendar reminder for approval revocation (WKS-07) +- [ ] Set up watch-only wallet for relevant family members (WKS-10) +- [ ] Verify: seed phrase exists on metal in two separate locations (WKS-04) + +--- + +*Domain 01: Wallet and Key Sovereignty | CryptoSHIELD v1.1* +*Threat taxonomy: [../taxonomy/registry.json](../taxonomy/registry.json)* +*Related domains: [../02-endpoint-device-defense/](../02-endpoint-device-defense/) | [../03-opsec-physical-security/](../03-opsec-physical-security/)* diff --git a/02-endpoint-device-defense/README.md b/02-endpoint-device-defense/README.md new file mode 100644 index 0000000..d920422 --- /dev/null +++ b/02-endpoint-device-defense/README.md @@ -0,0 +1,216 @@ +# Domain 02: Endpoint and Device Defense (EDD) + +**CSI CryptoSHIELD Framework v1.1 | May 2026** + +--- + +## Philosophy + +> The endpoint is the perimeter. Deterministic defense means no unknown code runs. Ever. + +Detection-based security starts from a position of defeat: the threat has already entered the environment and the question is whether you can identify it before damage occurs. Behavioral analysis, heuristic scanning, and EDR telemetry are all reactive: they assume the threat is already executing. + +CryptoSHIELD Domain 02 rejects this posture entirely. The deterministic endpoint model establishes a different axiom: unknown code does not execute. Not "unknown code executes and we watch for bad behavior." Unknown code is contained at the kernel level before the first instruction executes. Guilt until proven innocent at machine speed. + +**What Kernel API Virtualization Actually Enforces:** + +Traditional EDR intercepts system calls after user-mode code starts executing and monitors for suspicious patterns. By the time detection fires, the malicious code has already had CPU time, memory access, and potentially file system contact. Kernel API Virtualization operates differently: + +- Unknown executables are wrapped in a secure kernel-level container before any execution begins +- All API calls from the contained process are virtualized: they appear to succeed (preventing evasion via "try something, fail, stop") but are redirected to a sandboxed environment that is physically isolated from the real file system, clipboard, network stack, and key store +- Execution is real inside the container. The host never sees it. +- If the contained process is determined safe (via static analysis + behavioral profile against known-good signatures), it is released to execute normally +- If it exhibits malicious behavior inside the container: it is terminated. The host never had exposure. Dwell time is architecturally zero. + +**Why this matters for crypto specifically:** Clipboard hijackers (CS-MAL-01), wallet-targeting infostealers (CS-MAL-02), and supply chain malware (CS-SC-01/02) all depend on one thing: the ability to touch the real file system or clipboard while executing. Kernel API Virtualization removes that dependency from the attacker's equation. They can execute all they want inside a container that points at synthetic resources. The wallet key file they're trying to reach doesn't exist in their execution environment. + +This is not aspirational. This is the difference between detection-first security and deterministic prevention. Detection asks: "did something bad happen?" Prevention asks: "how do we engineer an environment where bad things cannot complete?" The answer at the endpoint layer is kernel-level containment. + +--- + +## Controls + +### EDD-01: Kernel-Level Default-Deny Endpoint Protection + +**Priority:** CRITICAL +**Threat IDs:** CS-MAL-01, CS-MAL-02, CS-MAL-03, CS-SC-01, CS-SC-02 + +**Implementation:** +- Deploy kernel-level Zero Trust endpoint protection (Xcitium/Warden architecture or equivalent default-deny model) +- All unknown executables must run in isolation before any host interaction is permitted +- Allow-listing of known-good applications maintained and enforced at kernel level +- No exceptions for "probably safe" or "looks like a legitimate application" + +**Why behavioral detection is not sufficient:** +The Shai-Hulud npm worm (September 2025) infected fundamental JavaScript libraries with 2.6 billion weekly downloads. Behavioral detection would have identified malicious patterns after execution begins: but the malicious code had already touched the file system, the clipboard, and potentially the wallet key store. The entire class of attack is defeated by EDD-01: the compromised library code runs in isolation, its attempts to access wallet files are blocked at the containment layer, and no wallet data is ever exposed. + +**Second-order effect:** EDD-01 makes every other malware defense in this domain a supplemental layer rather than a primary one. EDD-07 (behavioral EDR) still has value for detection and alerting: but it is never the last line of defense. + +--- + +### EDD-02: Dedicated Signing Device + +**Priority:** CRITICAL +**Threat IDs:** CS-MAL-02, CS-INS-01 + +**Implementation:** +- Designate one physical device used exclusively for crypto signing operations +- No general web browsing on the signing device +- No email, social media, or messaging applications on the signing device +- No software installation on the signing device except what is required for signing +- Signing device connects to internet only when actively signing: disconnected by default + +**The cognitive security failure mode:** Most crypto security failures involving device compromise occur on the user's primary workstation: the machine that is simultaneously browsing Discord for project news, receiving job offers via Telegram, running a dozen browser extensions, and signing DeFi transactions. Separating these activities provides complete blast radius containment. + +**Operational integration with WKS-05:** The signing device is the clean machine used to independently verify transaction calldata before signing on the hardware wallet. The device that generated the transaction request cannot reliably verify its own output. + +--- + +### EDD-03: Verified Software and SBOM for Developers + +**Priority:** CRITICAL +**Threat IDs:** CS-SC-01, CS-SC-02, CS-SC-03 + +**Implementation:** +- All software installed only from official, verified sources +- Package installations verified against cryptographic hash from official source +- For development environments: full SBOM (Software Bill of Materials) maintained and reviewed before production deployment +- No pirated software anywhere in the environment +- Browser extensions: strict allow-list, source-code review for any crypto-related extensions + +**For development teams:** SBOM enforcement means knowing every dependency, every transitive dependency, and the provenance of each. SCD-01 through SCD-10 (Supply Chain Defense domain) extend this principle to the full build pipeline. + +--- + +### EDD-04: Anti-Clipboard-Hijack Protocol + +**Priority:** CRITICAL +**Threat IDs:** CS-MAL-01 + +**Implementation:** +- Manually verify destination wallet address character-by-character before confirming any outgoing transaction +- Never rely on clipboard content alone: always verify what was actually copied vs. what appears in the transaction confirmation +- For high-value transactions (>$1,000): verify full address on hardware wallet screen in addition to software verification +- Develop muscle memory: copy address → verify first 6 characters → verify last 6 characters → verify total character count (42 for Ethereum) + +**The MassJacker scale:** 778,531 unique wallet addresses deployed in a single clipboard hijacking campaign. One Solana wallet from that campaign accumulated $300,000+. The attack is trivially simple to deploy and trivially simple to prevent: but only if the verification habit exists before the attack. + +--- + +### EDD-05: Browser Extension Minimization + +**Priority:** HIGH +**Threat IDs:** CS-MAL-02, CS-WAL-03 + +**Implementation:** +- Maintain strict allow-list of browser extensions: productivity extensions, password manager, hardware wallet connector (MetaMask only if required), and security tools +- Disable all crypto-related extensions when not actively in a signing session +- Review extension permissions quarterly: full access to all websites is a red flag for any extension +- Never install browser extensions recommended in Discord, Telegram, or from any unsolicited source +- Separate browser profile (or separate browser) for crypto signing vs. general browsing + +**Extension supply chain risk:** Browser extensions have been successfully compromised through maintainer account takeover. An extension that ran clean for two years can be updated with malicious code and push to all users without any action on the user's part. + +--- + +### EDD-06: Operating System Hardening + +**Priority:** HIGH +**Threat IDs:** CS-MAL-01, CS-MAL-02 + +**Implementation:** +- Disable unnecessary services, ports, and features on the signing device +- Firewall configured to default-deny; allowlist required outbound connections only +- Automatic updates enabled for security patches; application updates reviewed before installation +- Full-disk encryption enabled (FileVault / BitLocker / LUKS) +- Regular backup of signing device state to encrypted offline storage + +--- + +### EDD-07: EDR as Supplemental Detection Layer + +**Priority:** MEDIUM +**Threat IDs:** CS-MAL-01, CS-MAL-02 + +**Implementation note:** With EDD-01 (kernel-level containment) in place, EDR transitions from a primary defense to an intelligence and alerting layer. EDR telemetry on the signing device provides useful forensic data when combined with containment: but the architecture never relies on EDR to stop a threat that has already executed. + +**Recommended posture:** Deploy EDR for telemetry, forensic capability, and alerting. Configure alerts for: any execution attempt of unrecognized binaries (even if contained), any network connection attempt from a newly-installed application, any clipboard read access from a process that is not the active foreground application. + +--- + +### EDD-08: Network Isolation for Signing Operations + +**Priority:** HIGH +**Threat IDs:** CS-MAL-02, CS-SC-03 + +**Implementation:** +- Signing operations conducted on a dedicated network segment (VLAN or physical isolation) +- No shared network segment with gaming, streaming, or general-purpose devices +- VPN for all signing device traffic: prevents network-level surveillance and man-in-the-middle on unencrypted traffic +- For highest-value operations: air gap: download transaction data, sign offline, broadcast separately + +--- + +### EDD-09: Physical Security of Signing Device + +**Priority:** HIGH +**Threat IDs:** CS-PHY-01, CS-PHY-02 + +**Implementation:** +- Full-disk encryption on signing device: encrypted at rest, no auto-unlock +- Biometric or strong PIN authentication required for boot +- Device tracked (physical location awareness for loss/theft response) +- No unattended signing device in accessible locations: treat it like a weapon safe + +--- + +### EDD-10: Application Allowlisting + +**Priority:** CRITICAL +**Threat IDs:** CS-MAL-03, CS-SC-04, CS-SOC-04 + +**Implementation:** +- Allowlist of permitted applications maintained for signing device +- Any new application installation requires explicit approval and source verification +- Code-signed binaries only: unsigned executables blocked at system level +- Install package only from: official project website or official package repository with cryptographic hash verification + +**The Fake Cloudflare attack:** EDD-10 directly prevents this class of attack. The malicious PowerShell execution requires running an unsigned or ad-hoc-signed script. With EDD-10 enforced, that execution is blocked before any host interaction. + +--- + +## EDD Domain: CTRS Impact Analysis + +Applying Domain 02 controls retroactively to the ten highest-loss incidents in the CSI research corpus: + +| Incident | Primary Attack Vector | EDD Controls That Would Have Prevented | +|----------|----------------------|----------------------------------------| +| Radiant Capital $50M | Device malware + Safe{Wallet} display manipulation | EDD-01, EDD-02 | +| MassJacker 778K wallets | Pirated software, clipboard hijack | EDD-01, EDD-04 | +| Meeten malware | Fake meeting app download | EDD-01, EDD-10 | +| Shai-Hulud npm worm | NPM package dependency | EDD-01, EDD-03 | +| Crypto dev teams InfoStealer | Fake job download | EDD-01, EDD-02 | +| Fake Cloudflare PowerShell | Drive-by execution | EDD-01, EDD-10 | + +**Pattern:** EDD-01 appears in every column. Kernel-level containment is the single highest-leverage control in the entire framework for malware-class threats. + +--- + +## Architectural Note: The Warden Parallel + +Domain 02 controls map precisely to the Warden architectural philosophy: + +| Warden Principle | EDD Implementation | +|-----------------|-------------------| +| Guilty until proven innocent | EDD-01: unknown code contained, not allowed | +| Kernel API Virtualization | EDD-01: containment operates at kernel level | +| Zero dwell time | EDD-01: malicious code never executes in real environment | +| Physical isolation of unknown code | EDD-01, EDD-02: isolation at both kernel and device levels | +| Machine-speed neutralization | EDD-01: no human decision required to contain unknown execution | + +The full Warden and Digital Shield architectural specification is maintained separately by CSI. Domain 02 operationalizes these principles for the individual crypto security context. + +--- + +*Domain 02: Endpoint and Device Defense | CryptoSHIELD v1.1* +*Related domains: [../01-wallet-key-sovereignty/](../01-wallet-key-sovereignty/) | [../06-supply-chain-defense/](../06-supply-chain-defense/)* diff --git a/03-opsec-physical-security/README.md b/03-opsec-physical-security/README.md new file mode 100644 index 0000000..2ef0fe2 --- /dev/null +++ b/03-opsec-physical-security/README.md @@ -0,0 +1,232 @@ +# Domain 03: OPSEC and Physical Security (OPS) + +**CSI CryptoSHIELD Framework v1.1** +Cyber Strategy Institute | Classification: Open-Source | Sovereignty-First + +--- + +## Domain Philosophy + +Your on-chain signature is invisible. Your physical presence is not. + +The most technically sophisticated wallet setup in the world is neutralized by a wrench, a zip-tie, and thirty seconds of access to the wrong person. Domain 03 treats physical OPSEC as a first-class security domain: not an afterthought. If you are publicly identifiable as a crypto holder, you are a target for the fastest, most reliable attack vector in 2025: your own body under coercion. + +CertiK documented 72 verified physical coercion incidents in 2025. Losses: $40.9 million. Trajectory: +75% year-over-year. The attack pattern is consistent: OSINT → Identity Mapping → Physical Surveillance → Coercion. Every step of that chain is preventable. None of it requires defeating cryptography. + +**CSI Position:** Operational security is not paranoia. It is the minimum viable defense posture for anyone holding material crypto wealth. + +--- + +## Controls + +| Control ID | Control | Implementation | Priority | +|---|---|---|---| +| OPS-01 | Zero Public Disclosure of Holdings | Never post wallet balances, gains, or luxury flex tied to crypto identity | CRITICAL | +| OPS-02 | Decouple Identity from On-Chain | No ENS names tied to real name; separate social identity from wallet addresses | CRITICAL | +| OPS-03 | Address Non-Reuse | Generate new receiving address for every transaction | HIGH | +| OPS-04 | OSINT Self-Audit | Quarterly: remove identifiable geotags, home references, employer information | HIGH | +| OPS-05 | Physical Incident Response Plan | Pre-scripted emergency plan; trusted contact; know when to delay vs. comply | CRITICAL | +| OPS-06 | Coercion Wallet (Decoy Wallet) | Maintain a visible wallet with small balance as coercion decoy; bulk held in inaccessible timelock | HIGH | +| OPS-07 | Family OPSEC | Separate accounts, devices; limited family knowledge of full holdings structure | CRITICAL | +| OPS-08 | Geolocation Hygiene | Strip EXIF from photos; disable location services on all crypto-related apps | HIGH | +| OPS-09 | Surveillance Detection | Know surveillance indicator patterns; vary routes; report unusual attention | MEDIUM | +| OPS-10 | Duress Protocol | Pre-agreed distress signal to trusted contact if under physical coercion | HIGH | + +--- + +## Control Implementation Detail + +### OPS-01: Zero Public Disclosure of Holdings + +**Problem:** Social media posts displaying hardware wallets, screenshots of portfolio balances, mentions of specific token positions, or luxury purchases funded by crypto gains create an OSINT trail linking a real-world identity to crypto wealth. + +**Realization:** The September 2025 Minnesota kidnapping ($8M coerced transfer) was preceded by OSINT surveillance linking on-chain wallet activity to a physical address. The attacker required no technical capability: only public data. + +**Implementation:** +- Apply the "Would I post my bank balance?" test before any crypto-adjacent social post +- Remove or audit existing posts containing wallet screenshots, gains, or luxury purchases linked to crypto narrative +- Use separate social accounts for crypto discussion; never tie to legal name or photo +- Treat all media appearances discussing crypto wealth with operational caution: use rounded figures, avoid specific holdings, decline to disclose wallet addresses + +**Failure Modes:** +- "Flexing" on CT (Crypto Twitter) with paper gains +- ENS names that match your legal name or known handle (e.g., vince.eth) +- LinkedIn describing yourself as "profitable DeFi investor since 2020" +- Posting hardware wallet unboxing photos showing your home or purchase history + +--- + +### OPS-02: Decouple Identity from On-Chain + +**Problem:** ENS names, on-chain donations, public wallet addresses used for business payments, and forum handle → wallet linkages allow any attacker to map your on-chain wealth to your physical identity. + +**Implementation:** +- Use different wallets for different contexts: trading wallet, NFT wallet, public-facing tip wallet, primary cold storage (never publicized) +- Never register an ENS name under your real name or primary social handle +- For public tips/donations: use a dedicated, low-balance hot wallet specifically for public receipt; never the same wallet holding significant assets +- Rotate public-facing addresses annually at minimum + +**Edge Case:** Blockchain analytics firms (Chainalysis, TRM Labs) can link wallets with high confidence through co-spend analysis. True identity decoupling requires discipline from first transaction: retroactive unlinking is difficult and often incomplete. + +--- + +### OPS-03: Address Non-Reuse + +**Problem:** Address reuse creates a permanent, searchable on-chain history that links all your transactions to a single identity node. OSINT tools like Etherscan, Arkham, and Nansen build "address intelligence" profiles from reuse patterns. + +**Implementation:** +- Modern HD wallets (BIP32/44) generate unique addresses for every receive operation: use this feature +- Never publish your "primary" address anywhere; provide fresh addresses per requestor +- For DeFi interactions: use interaction wallets funded from cold storage; don't interact directly from cold storage +- Monitor your addresses with a privacy-oriented analytics tool to understand what your on-chain footprint reveals + +--- + +### OPS-04: OSINT Self-Audit + +**Problem:** Most crypto holders have already created an OSINT footprint that an attacker can leverage. The audit is not about perfection: it is about reducing the attack surface. + +**Quarterly Audit Checklist:** +- [ ] Google your legal name + "crypto": what surfaces? +- [ ] Search your primary social handles on Etherscan/Arkham: any wallet linkages? +- [ ] Check LinkedIn for mentions of crypto holdings, specific protocols, or investment success +- [ ] Review forum posts (Reddit, Discord, Telegram) for wallet address mentions +- [ ] Audit EXIF data on publicly posted photos: strip geolocation data +- [ ] Search your home address on property records: is it connectable to your crypto identity? +- [ ] Review exchange KYC data exposure: which platforms hold your government ID? + +**Tools:** HaveIBeenPwned (data breach exposure), IntelTechniques (manual OSINT), Google Alerts (ongoing monitoring) + +--- + +### OPS-05: Physical Incident Response Plan + +**Problem:** Physical coercion situations are high-stress, rapid-onset events. Anyone who has not pre-planned their response will improvise: and improvisation under duress leads to full asset surrender. + +**Pre-Plan Components:** +1. **Decoy wallet** with convincing balance (OPS-06): your primary "surrender" option +2. **Trusted contact** who receives a daily check-in; non-check-in triggers a response protocol +3. **Delay tactics**: claim device is in a timelock, claim 2FA is on a separate device at a distant location, claim hardware wallet requires 24-hour warm-up period after 30 days +4. **Geographic split**: primary holdings physically inaccessible from your location (multisig keys with geographically separate co-signers; WKS-02) +5. **Law enforcement contact info**: FBI Crypto Unit, local cyber crime unit + +**The Fundamental Principle:** Holdings that cannot be transferred without a co-signer in another city cannot be coerced from you. This is the most effective physical security control in the framework. + +--- + +### OPS-06: Coercion Wallet (Decoy Wallet) + +**Purpose:** Provide a convincing, accessible wallet to surrender under physical coercion, limiting losses while preserving primary holdings. + +**Implementation:** +- Maintain a wallet with a balance that is "believable" relative to your perceived wealth: enough to satisfy a coercer, low enough to be an acceptable sacrifice +- The wallet should have a visible transaction history showing "normal" activity +- Seed phrase stored in a location that is physically accessible under coercion (but not near primary hardware wallet storage) +- Primary holdings held under 72-hour+ timelock (WKS-03): even if coercer gains access, transfers cannot execute immediately + +**Critical Note:** Do not present a wallet that is obviously too small: this creates escalation risk. The decoy must be credible. + +--- + +### OPS-07: Family OPSEC + +**Problem:** Family members are the softest target in your security posture. Attackers who cannot defeat your security directly will target your spouse, children, or parents: who have no security training and may not understand the risk. + +**Implementation:** +- Family members should not know the full structure of your holdings: only that "most of it is locked away and takes days to access" +- Do not store any access information (seed phrases, hardware wallets, PINs) in family-shared spaces +- Family devices should never have crypto wallets installed +- Brief family members on the basics: never discuss family wealth with strangers; "dad doesn't carry crypto on him"; call immediately if approached by strangers asking about dad's finances +- Establish a family duress code word that, when spoken, means "I am under coercion; call law enforcement" + +--- + +### OPS-08: Geolocation Hygiene + +**Implementation:** +- Strip EXIF data from all photos before posting (tool: ExifTool, iOS/Android built-in options) +- Disable location services on all crypto-related apps (wallets, exchanges, portfolio trackers) +- Do not check in to locations on social media: especially from home, regular hangouts, or crypto conference venues +- For high-value holders: use a VPN; avoid consistent IP geolocation from the same home address appearing in CEX login records + +--- + +### OPS-09: Surveillance Detection + +**Basic Indicators:** +- Same vehicle or individual observed in multiple locations over multiple days +- Unexpected contact from individuals seeking information about your finances or schedule +- Social media interactions from new accounts asking specific questions about your holdings or daily routine +- Unusual activity at your residence (drive-by photography, unfamiliar vehicles parked for extended periods) + +**Response:** Do not confront; document (time, location, description); alert trusted contact; vary your routine; consider temporary relocation for high-threat periods. + +--- + +### OPS-10: Duress Protocol + +**Implementation:** +- Establish a pre-agreed phrase or signal with a trusted contact that means "I am under coercion; initiate emergency protocol" +- The protocol: trusted contact calls law enforcement; alerts family; does NOT transfer any funds or provide any information to anyone claiming to be acting on your behalf +- Test the protocol at least once per year +- Consider a panic word that, when spoken to a smart home device, triggers a silent alarm to the trusted contact + +--- + +## Threat Coverage Matrix + +| Threat ID | Threat Name | Controls Applied | +|---|---|---| +| CS-PHY-01 | Kidnapping/Coercion | OPS-01, OPS-02, OPS-05, OPS-06, OPS-07, OPS-10 | +| CS-PHY-02 | Home Invasion | OPS-01, OPS-04, OPS-07, OPS-08 | +| CS-SOC-01 | Phishing | OPS-02, OPS-03 | +| CS-SOC-03 | Fake Job Offer | OPS-01, OPS-04 | + +--- + +## CTRS Risk Assessment: Physical Domain + +| Threat | Likelihood | Impact | Detectability | CTRS Score | +|---|---|---|---|---| +| CS-PHY-01 (Kidnapping) | 3 | 5 | 2 | 18.4 | +| CS-PHY-02 (Home Invasion) | 3 | 5 | 2 | 18.4 | + +Both physical threats score at maximum CTRS impact because: losses are total and immediate, recovery is impossible, and the attack requires no technical capability: only OSINT and opportunity. + +--- + +## 30-Day Physical OPSEC Sprint + +**Week 1: Identity Decoupling** +- [ ] Conduct OSINT self-audit (OPS-04) +- [ ] Identify and document all wallet addresses linked to your identity +- [ ] Remove or edit social posts disclosing crypto holdings + +**Week 2: Holdings Architecture** +- [ ] Implement 72-hour timelock on governance wallet (WKS-03) +- [ ] Establish geographically split multisig (WKS-02) +- [ ] Fund and configure decoy wallet (OPS-06) + +**Week 3: Family and Physical Plan** +- [ ] Brief family on basic OPSEC (OPS-07) +- [ ] Draft written incident response plan (OPS-05) +- [ ] Establish trusted contact and daily check-in protocol + +**Week 4: Hygiene and Monitoring** +- [ ] Enable EXIF stripping; audit past photos (OPS-08) +- [ ] Set up Google Alerts for your name + crypto keywords +- [ ] Test duress protocol with trusted contact (OPS-10) + +--- + +## Research References + +- Research Note 001: The Wrench Attack Epidemic → `research/001_wrench_attack_epidemic.md` +- CertiK Skynet Wrench Attacks Report, February 2026 +- CSI Weekly Issue 46: Minnesota Kidnapping Case Analysis +- CSI Weekly Issue 43: Ledger Co-Founder Kidnapping (France, January 2025) + +--- + +*CSI CryptoSHIELD Framework v1.1 | Domain 03: OPSEC and Physical Security* +*Cyber Strategy Institute | Open-Source | Sovereignty-First* diff --git a/04-social-media-platform-security/README.md b/04-social-media-platform-security/README.md new file mode 100644 index 0000000..c6747c9 --- /dev/null +++ b/04-social-media-platform-security/README.md @@ -0,0 +1,243 @@ +# Domain 04: Social Media and Platform Security (SMS) + +**CSI CryptoSHIELD Framework v1.1** +Cyber Strategy Institute | Classification: Open-Source | Sovereignty-First + +--- + +## Domain Philosophy + +Every crypto platform interaction is a potential attack surface. Every social media account is a credential under siege. + +The era of detecting scams by spotting grammatical errors is over. AI impersonation attacks surged 1,400% year-over-year in 2025. The "Nigerian prince" spelling test is dead. What replaced it: flawlessly written, contextually aware, psychologically calibrated social engineering delivered at scale by AI-powered threat actors who have studied your public profile before sending the first message. + +This domain governs the security posture for every account, platform, and social channel a crypto holder touches: from X account security to platform legitimacy verification to URL hygiene. The attack surface is vast. The controls are specific, executable, and effective. + +--- + +## Controls (v1.1: 15 Controls) + +| Control ID | Control | Implementation | Priority | +|---|---|---|---| +| SMS-01 | Hardware 2FA | YubiKey or equivalent for all exchange, social, and crypto accounts | CRITICAL | +| SMS-02 | Remove Phone Number from Social | Eliminate SMS-based recovery attack surface entirely | CRITICAL | +| SMS-03 | OAuth Audit | Monthly audit of connected third-party apps; revoke all non-essential | HIGH | +| SMS-04 | Dedicated Recovery Email | Separate email for crypto account recovery; own strong 2FA; never publicized | HIGH | +| SMS-05 | URL Verification | Full URL inspection before interacting with any crypto frontend | CRITICAL | +| SMS-06 | No Unsolicited DM Trust | Never act on DMs offering jobs, partnerships, or "giveaways" | CRITICAL | +| SMS-07 | Social Engineering Drill | Monthly awareness test for team/family; recognize urgency/authority patterns | HIGH | +| SMS-08 | Official Channel Verification | Cross-verify announcements on-chain, not via social posts alone | HIGH | +| SMS-09 | DNS/Frontend Alert System | Use Scam Sniffer or equivalent for real-time phishing detection | HIGH | +| SMS-10 | Influencer Skepticism Protocol | Apply Rotator Effect analysis before acting on influencer calls | MEDIUM | +| SMS-11 | Manual URL Entry Protocol | Never click crypto site links; bookmark directly or type manually | HIGH | +| SMS-12 | Pre-Transaction Platform Verification | Run any new platform through DFPI, CryptoScamDB, Chainabuse before first deposit | CRITICAL | +| SMS-13 | 10-Day Rule for New Platforms | Mandatory 10-day waiting period before depositing >$1,000 on any unfamiliar platform | HIGH | +| SMS-14 | Fee Demand Alert Protocol | Any platform demanding fees to unlock withdrawals = immediate cease and report | CRITICAL | +| SMS-15 | Recovery Scam Awareness | No legitimate service can reverse blockchain transactions; all recovery fee demands = scam | CRITICAL | + +--- + +## Control Implementation Detail + +### SMS-01: Hardware 2FA + +**Why SMS 2FA is Insufficient:** +SIM swapping attacks allow attackers to port your phone number to a device they control, intercepting all SMS codes. In 2024-2025, SIM swap attacks against crypto holders resulted in tens of millions in losses. Coinbase alone documented hundreds of SIM-swap-facilitated account takeovers. + +**Implementation:** +- YubiKey 5 Series (FIDO2/WebAuthn) for all accounts that support it +- Google Titan Key as backup for YubiKey-compatible accounts +- TOTP authenticator app (Aegis on Android, Raivo OTP on iOS) as tertiary layer +- Store backup hardware key in a physically secure location separate from primary + +**Account Priority List:** +1. All cryptocurrency exchanges (Coinbase, Binance, Kraken, etc.) +2. X (Twitter): primary vector for account takeover + crypto scam amplification +3. Gmail/ProtonMail (recovery email) +4. Discord (project communities, DMs) +5. Telegram (trading groups, project channels) +6. GitHub (developers) + +--- + +### SMS-02: Remove Phone Number from Social + +**The Attack Chain:** +Phone number on social account → SIM swap attack → SMS 2FA bypass → account takeover → impersonation for crypto scams or credential harvesting + +**Implementation:** +- X: Settings → Security → Two-factor authentication → Remove phone number; use authenticator app or security key only +- Discord: Remove phone number from account settings; enable TOTP 2FA +- Telegram: Settings → Privacy and Security → Phone Number → set to "Nobody"; enable Two-Step Verification +- Google: Remove phone as recovery method; use backup codes and authenticator + +**Note:** Some platforms require a phone number at account creation but allow removal after verification. Complete this removal step immediately after setup. + +--- + +### SMS-03: OAuth Audit + +**Why It Matters:** +Third-party apps authorized to your social accounts can post on your behalf, read your DMs, and access account details. Compromised OAuth-authorized apps become persistent backdoors even after you change your password. + +**Monthly Audit Process:** +- X: Settings → Security → Apps and sessions → Connected apps: revoke anything not actively used +- Discord: User Settings → Authorized Apps: revoke any app not in active use +- Telegram: Settings → Privacy and Security → Active Sessions: terminate unknown sessions + +**Red Flags:** +- Apps you don't recognize +- Apps with "post on my behalf" permissions +- Apps authorized more than 90 days ago with no recent use + +--- + +### SMS-05: URL Verification + +**Full Verification Protocol (execute every time):** +1. Check the top-level domain (TLD): `uniswap.org` vs `uniswap.io` vs `uniswap-app.com`: only one is legitimate +2. Verify there are no Unicode lookalike characters in the domain (e.g., `сoinbase.com` with a Cyrillic 'с') +3. Confirm HTTPS with valid certificate from the expected issuer +4. Cross-reference the URL against CryptoScamDB before first use +5. If accessing via a link (from Discord, X, email): don't. Navigate directly. + +**Browser Bookmarks Are Sacred:** +Create verified bookmarks for every crypto platform you use. The bookmark was created by you, from a verified URL. Use it every time. Never click a link to a crypto platform from any external source. + +--- + +### SMS-06: No Unsolicited DM Trust + +**Threat Profile:** +Unsolicited DMs are the primary delivery mechanism for: +- Fake job offers (CS-SOC-03) delivering malware via "test assignments" +- Fake meeting app invitations (CS-SOC-04) delivering Meeten malware +- "Alpha" investment calls delivering pig butchering setups +- "Giveaway" links capturing wallet credentials +- "Support team" impersonations requesting seed phrases + +**The Zero-Trust Rule:** +Any DM received without a prior, established relationship is adversarial by default until proven otherwise through out-of-band verification. Period. + +**Verification Protocol for Legitimate-Seeming DMs:** +1. Do not click any links in the DM +2. Do not download any attachments +3. Navigate independently to the entity's official website +4. Verify the contact through official channels listed on that website +5. If it was real, they'll verify. If they insist on the DM channel only: adversarial. + +--- + +### SMS-08: Official Channel Verification + +**The Attack Pattern:** +Fake announcements on social channels (X, Discord, Telegram) claiming: emergency migration, token upgrade, "claim your airdrop," security breach requiring wallet reconnection. These are consistently timed around real protocol events to maximize credibility. + +**Verification Hierarchy (highest to lowest trust):** +1. On-chain governance proposals at the protocol's verified contract address +2. Protocol's GitHub repository commit history +3. Official website (directly navigated, not linked) +4. Protocol's verified Twitter account (blue checkmark alone is insufficient: verify via website cross-reference) +5. Discord announcements: only in verified servers where you joined via official website link + +**Rule:** If you cannot verify an announcement on-chain or via the official website you navigated to directly, it is unverified. + +--- + +### SMS-12: Pre-Transaction Platform Verification + +**Mandatory Checks Before First Deposit:** +``` +Platform: [NAME] +DFPI Lookup: https://dfpi.ca.gov/consumers/crypto/crypto-scam-tracker/ +CryptoScamDB: https://cryptoscamdb.org/ +Chainabuse: https://www.chainabuse.com/ +SEC Action: https://www.sec.gov/litigation/actions/ +CFTC: https://www.cftc.gov/LearnAndProtect/AdvisoryViewer/ +Result: CLEAR / FLAGGED / BLOCKED +``` + +**Red Flags That Override Any Passing Check:** +- Platform cannot be found via independent web search (search results only show its own domain) +- No verifiable physical address or corporate registration +- Support exists only via Telegram or WhatsApp: no email, no ticket system +- Promises of guaranteed returns or specific profit percentages +- Withdrawal fees or "verification deposits" required + +--- + +### SMS-14: Fee Demand Alert Protocol + +The fee escalation cycle is the defining characteristic of pig butchering and related investment fraud: + +``` +Deposit → "Profits" accumulate → Withdrawal attempt +→ BLOCKED: "Pay X% tax to unlock" +→ Tax paid → BLOCKED: "Pay AML verification fee" +→ Fee paid → BLOCKED: "Account upgrade required" +→ Fee paid → Platform disappears +``` + +**Absolute Rule:** Any platform blocking a withdrawal pending payment of any fee: regardless of the stated justification: is committing fraud. The fee is not unlocking your withdrawal. It is extracting additional funds from you before the exit. + +**Response:** +1. Stop all deposits immediately +2. Document: all wallet addresses used, all communications, all transaction receipts +3. Report: FBI IC3 (ic3.gov), Chainabuse, DFPI (if in California), CFTC +4. Do NOT pay additional fees: you will not recover your funds; you will only lose more +5. Do NOT engage a "recovery service" that contacts you afterward (CS-FRD-02) + +--- + +## Threat Coverage Matrix + +| Threat ID | Threat | Controls Applied | +|---|---|---| +| CS-SOC-01 | Phishing | SMS-05, SMS-08, SMS-09, SMS-11 | +| CS-SOC-03 | Fake Job Offer | SMS-06, SMS-07 | +| CS-SOC-04 | Fake Meeting App | SMS-06, SMS-07 | +| CS-SOC-05 | AI Deepfake | SMS-06, SMS-07, SMS-08 | +| CS-SOC-07 | Typosquatting | SMS-05, SMS-09, SMS-11 | +| CS-FRD-01 | Pig Butchering | SMS-06, SMS-12, SMS-13, SMS-14 | +| CS-FRD-02 | Recovery Scam | SMS-15 | +| CS-WAL-03 | DNS Hijack | SMS-05, SMS-09, SMS-11 | +| CS-MKT-03 | Influence Operation | SMS-10 | + +--- + +## X (Twitter) Account Hardening: Full Protocol + +X accounts are consistently the highest-value social media target for crypto attackers. A compromised X account enables: credential phishing via announcement posts, NFT/token drain scams, influencer impersonation, and social engineering of your followers. + +**Complete X Hardening Checklist:** +- [ ] Remove phone number from account (Settings → Security → Two-factor authentication) +- [ ] Enable Security Key (hardware FIDO2) as primary 2FA +- [ ] Enable "Password reset protect" (requires email confirmation before password reset) +- [ ] Enable "Two-factor authentication app" as backup to hardware key +- [ ] Review and revoke all connected apps (Settings → Security → Apps and sessions) +- [ ] Enable "Protect your Tweets" if your account is not intentionally public +- [ ] Check login history for unrecognized sessions; log out all other sessions +- [ ] Set a strong, unique password stored in a password manager +- [ ] Review email address on file: ensure it points to your dedicated recovery email (SMS-04) + +--- + +## AI-Enhanced Deception: Detection Framework + +Traditional red flags (typos, bad grammar, urgency) are obsolete. New framework: + +| Old Red Flag | AI-Defeated? | New Detection Method | +|---|---|---| +| Grammatical errors | Yes | Verify identity out-of-band | +| Generic address ("Dear User") | Yes | Verify via official channel | +| Suspicious URL | Partially | Full URL verification protocol | +| Urgency/pressure tactics | No | Slow down; urgency = adversarial | +| Implausible offer | Partially | Research independently | +| Requests for seed phrase | Never legitimate | Absolute: no | + +The one detection method AI cannot defeat: **out-of-band verification**. If someone contacts you claiming to be a known entity, hang up or close the chat, navigate independently to that entity's official contact, and verify from there. No AI persona survives that test. + +--- + +*CSI CryptoSHIELD Framework v1.1 | Domain 04: Social Media and Platform Security* +*Cyber Strategy Institute | Open-Source | Sovereignty-First* diff --git a/05-on-chain-monitoring/README.md b/05-on-chain-monitoring/README.md new file mode 100644 index 0000000..51447be --- /dev/null +++ b/05-on-chain-monitoring/README.md @@ -0,0 +1,247 @@ +# Domain 05: On-Chain Monitoring and Transaction Defense (OCM) + +**CSI CryptoSHIELD Framework v1.1** +Cyber Strategy Institute | Classification: Open-Source | Sovereignty-First + +--- + +## Domain Philosophy + +Every blockchain transaction is permanent, public, and irreversible. There are no chargebacks. There is no fraud department. The only defense is prevention: and the only way to prevent what you cannot see is to make everything visible before it executes. + +Domain 05 establishes the monitoring, simulation, and transaction hygiene stack that closes the gap between "I think I'm transacting safely" and "I have verified every byte of this transaction on an independent device before signing." That gap is where $3.4 billion walked out the door in 2025. + +--- + +## Controls + +| Control ID | Control | Implementation | Priority | +|---|---|---|---| +| OCM-01 | Transaction Simulation | Simulate every transaction in Tenderly/Revoke.cash before signing | CRITICAL | +| OCM-02 | Real-Time Wallet Monitor | Alerts on any unexpected outgoing transaction; immediate notification | HIGH | +| OCM-03 | Token Approval Monitoring | Monitor all open approvals; auto-revoke after 30 days of inactivity | HIGH | +| OCM-04 | Mempool Awareness | Understand transaction mempool exposure; use private RPC for large transactions | HIGH | +| OCM-05 | MEV Protection | Use MEV-resistant routing (Flashbots Protect, private mempool) | MEDIUM | +| OCM-06 | Address Poisoning Detection | Verify full address hex before every outgoing transaction | HIGH | +| OCM-07 | Bridge Risk Assessment | Evaluate verifier design for any bridge before use; single-verifier = avoid | HIGH | +| OCM-08 | Smart Contract Audit Verification | Only interact with audited contracts from reputable firms; check audit recency | HIGH | +| OCM-09 | Anomaly Detection | Deploy behavioral monitoring for unusual transaction patterns | HIGH | +| OCM-10 | Permit/Signature Intelligence | Understand all EIP-712 structured data before signing | CRITICAL | + +--- + +## Control Implementation Detail + +### OCM-01: Transaction Simulation: Mandatory Execution Gate + +**Problem:** Transactions submitted to a hardware wallet for signing display only high-level summaries. The raw calldata: which determines what actually executes: is invisible to the user without simulation. + +**The Gate Principle:** This is not a pre-signing check you can skip when you're confident. It is a mandatory execution gate. The rule: **if you cannot simulate it, you cannot sign it.** No exceptions. No "I trust this protocol." No "I've done this before." Every unsigned transaction that cannot be simulated is an unsigned transaction that does not get signed. + +Why the gate framing matters: A "check" is optional by definition. Security culture built around optional checks produces systematic failures when stress, urgency, or routine override the check. A gate is architectural. It is either open or it is not. CryptoSHIELD treats OCM-01 as a gate: the last technical verification before value leaves your control. + +**Realization:** The Radiant Capital $50M exploit succeeded despite Tenderly simulation and manual review because attackers manipulated the displayed values while the actual signed payload was malicious. Simulation reduces risk but requires independent verification of the simulation output itself. + +**Implementation Tools:** +- **Tenderly:** Simulate before signing at `tenderly.co/simulator` +- **Revoke.cash:** Check and revoke existing approvals at `revoke.cash` +- **Phalcon Block Sec:** Transaction simulation with decoded calldata +- **Etherscan Transaction Decoder:** Manually decode calldata for any transaction + +**Simulation Checklist:** +``` +Before signing any transaction: this is the gate: +[ ] Simulated in Tenderly: outcome matches expectation +[ ] Token transfers in simulation match your intent exactly +[ ] No unexpected contract interactions in simulation trace +[ ] Gas usage is within expected range for this operation type +[ ] Recipient address verified on independent device (not browser copy-paste) +[ ] If simulation fails to run: do not sign. No exceptions. +``` + +--- + +### OCM-02: Real-Time Wallet Monitor + +**Setup:** +- **Etherscan/Polygonscan Alerts:** Free email alerts on any transaction from your address +- **Nansen Portfolio:** Real-time push notifications for wallet activity +- **Hal.app:** Custom on-chain monitoring with complex trigger logic +- **Chainpatrol:** Protocol-level monitoring for DeFi positions + +**Alert Thresholds:** +- Any outgoing transaction over $100: immediate notification +- Any token approval: immediate notification +- Any interaction with a new (unverified) contract: immediate notification +- Large incoming transaction: notification for reconciliation + +**Response Protocol on Unexpected Alert:** +1. Do NOT interact with anything until investigation is complete +2. From a separate device: check Etherscan for the transaction details +3. Identify the contract interacted with; check its audit status and age +4. If compromise suspected: execute emergency cold wallet migration immediately (Revoke all approvals → Move remaining funds to pre-generated cold address) + +--- + +### OCM-03: Token Approval Monitoring + +**Why Approvals Are Dangerous:** +When you interact with a DeFi protocol, you typically grant it permission to spend your tokens up to a specified amount (often unlimited). These approvals persist indefinitely after the interaction. A protocol exploit, upgrade, or admin key compromise can drain all approved tokens at any time. + +CSI research finding: 68% of DeFi losses involve exploitation of existing token approvals rather than exploitation of active transactions. + +**Implementation:** +- Monthly audit at revoke.cash (Ethereum), bscscan.com/tokenapprovalchecker (BSC), or equivalent +- Revoke all approvals for protocols you no longer actively use +- Set specific approval amounts instead of "unlimited" when DeFi UI allows it +- After any DeFi interaction, revoke the approval if you don't expect to use the protocol again within 30 days + +**Tools by Chain:** +| Chain | Tool | +|---|---| +| Ethereum | revoke.cash | +| Polygon | revoke.cash (multi-chain) | +| Arbitrum | revoke.cash (multi-chain) | +| Solana | sol-incinerator.com / Phantom built-in | +| BNB Chain | bscscan.com/tokenapprovalchecker | + +--- + +### OCM-04: Mempool Awareness + +**What the Mempool Is:** +Before a transaction is included in a block, it sits in the public mempool: visible to anyone, including MEV bots. Large transactions in the mempool are frontrun, sandwiched, and exploited before they finalize. + +**Private RPC Endpoints:** +For any transaction over $10,000, use a private RPC to bypass the public mempool: +- **Flashbots Protect RPC:** `rpc.flashbots.net`: sends transactions directly to block builders +- **MEV Blocker:** `mev-blocker.io`: open source MEV protection +- **Alchemy Private:** Available on Alchemy's RPC tier + +**Configuration:** In MetaMask or other wallet, add the private RPC as a custom network endpoint and switch to it before large transactions. + +--- + +### OCM-06: Address Poisoning Detection + +**The Attack:** +An attacker sends you a tiny transaction (often 0 USDC or 0.0001 ETH) from an address that looks nearly identical to an address you've recently transacted with. The goal: when you copy a recipient from your transaction history, you accidentally copy the attacker's address instead. + +**Detection Protocol:** +``` +Before EVERY outgoing transaction: +1. Write down or display the first 6 and last 6 characters of the intended recipient +2. Compare against the address displayed in your hardware wallet SCREEN (not browser) +3. Verify all characters: not just the first/last few +4. If transaction history contains a near-identical address you didn't initiate: poisoning detected +``` + +**Never:** +- Copy recipient addresses from transaction history without full hex verification +- Assume your browser's clipboard contains what you last copied (clipboard hijacking: CS-MAL-01) + +--- + +### OCM-07: Bridge Risk Assessment + +**The Bridge Risk Framework:** +Cross-chain bridges are the single highest-loss attack surface in DeFi history: $2.88 billion stolen cumulatively through April 2026. + +**Risk Assessment Matrix:** +| Risk Factor | Safe | Caution | Avoid | +|---|---|---|---| +| Verifier count | 15+ diverse validators | 5-14 validators | 1-3 validators | +| Time since deployment | 2+ years | 6-24 months | Less than 6 months | +| Audit count | 3+ from reputable firms | 1-2 audits | Unaudited | +| TVL (proxy for battle-testing) | >$500M | $50M-$500M | <$50M | +| Admin key design | Multi-sig, timelocked | Multi-sig, no timelock | EOA or opaque | +| Incident history | None | Minor, resolved | Major exploit | + +**High-Profile Bridge Failures (for reference):** +- Ronin Network: $625M (March 2022): 5 of 9 validators compromised +- Wormhole: $320M (February 2022): signature verification bug +- Nomad: $190M (August 2022): initialization error +- KelpDAO: $292M (April 2026): single-verifier LayerZero bridge + +**Rule:** If a bridge uses a single verifier or has fewer than 5 independent validators, do not bridge assets through it regardless of TVL or marketing. + +--- + +### OCM-10: Permit/Signature Intelligence + +**`eth_sign`: Fully Deprecated. Never Use. Never Approve.** + +Before covering EIP-712, a hard rule: `eth_sign` is a legacy signing method that signs arbitrary byte sequences with zero human-readable context. Any dApp requesting an `eth_sign` signature is either extremely outdated or malicious. MetaMask displays a warning for `eth_sign` and recommends rejection. Ledger and Trezor display no transaction details for `eth_sign`: you are signing blind. + +**Rule:** If a dApp requests `eth_sign`, reject the request and close the site. Report the URL to Scam Sniffer (scamsniffer.io) and Chainabuse (chainabuse.com). Do not attempt to verify whether the request is legitimate: legitimate protocols do not use `eth_sign`. + +**What EIP-2612 Permit Signatures Do:** +Unlike a standard token approval (which requires a gas-paying transaction), a permit signature is an off-chain signature that grants spending permissions. It can be submitted by anyone: meaning you can sign a malicious permit without ever sending a transaction yourself. + +**What to Look For Before Signing Any EIP-712 Message:** +``` +{ + "domain": { + "name": "[Should match the protocol you're interacting with]", + "verifyingContract": "[Should match the protocol's known contract address]" + }, + "message": { + "spender": "[WHO will be able to spend your tokens: verify this address]", + "value": "[HOW MUCH they can spend: should never be MAX_UINT256 unless understood]", + "deadline": "[WHEN does this permission expire: short deadline preferred]" + } +} +``` + +**Red Flags:** +- `spender` address you don't recognize +- `value` set to `115792089237316195423570985008687907853269984665640564039457584007913129639935` (unlimited) +- `deadline` far in the future (months or years) +- Permit request arriving via DM or unsolicited interaction + +**Rule:** Permit requests from unsolicited sources (DMs, emails, popup sites) are always adversarial. Never sign them. + +--- + +## Transaction Defense Stack: Full Architecture + +``` +TRANSACTION INITIATION + │ + ▼ +[ OCM-04: Private RPC? ] → If large: yes + │ + ▼ +[ OCM-10: Decode signature/calldata ] + │ + ▼ +[ OCM-01: Simulate in Tenderly ] + │ + ▼ +[ OCM-06: Address poisoning check ] + │ + ▼ +[ Hardware wallet screen verification ] + │ + ▼ +SIGN AND BROADCAST + │ + ▼ +[ OCM-02: Confirm alert received ] +``` + +Every layer is bypass-resistant only if the previous layer is also applied. Simulation without address verification is not full defense. + +--- + +## Research References + +- DefiLlama Hacks Database: lifetime $11.81B across 518 incidents +- CS-DFI-03 (Bridge Exploit): $2.88B cumulative, largest single attack surface +- OCM-03 data: 68% of losses involve pre-existing token approvals +- Research Note 004: AI Agent Attack Surface → `research/004_ai_agent_attack_surface.md` + +--- + +*CSI CryptoSHIELD Framework v1.1 | Domain 05: On-Chain Monitoring and Transaction Defense* +*Cyber Strategy Institute | Open-Source | Sovereignty-First* diff --git a/06-supply-chain-defense/README.md b/06-supply-chain-defense/README.md new file mode 100644 index 0000000..03e27b4 --- /dev/null +++ b/06-supply-chain-defense/README.md @@ -0,0 +1,289 @@ +# Domain 06: Supply Chain Defense (SCD) + +**CSI CryptoSHIELD Framework v1.1** +Cyber Strategy Institute | Classification: Open-Source | Sovereignty-First + +--- + +## Domain Philosophy + +You cannot audit what you cannot see. And in 2025, most of what executes in your crypto stack is invisible to you. + +Supply chain attacks against the crypto and Web3 ecosystem rose 1,300% from 2021 to 2023. By September 2025, the Shai-Hulud npm worm infected 500+ packages: including foundational libraries like `chalk`, `debug`, and `ansi-styles` with a combined 2.6 billion weekly downloads: targeting cryptocurrency wallet transactions across six blockchains. The Ultralytics YOLO11 AI model was compromised through GitHub Actions and PyPI. The ThirdWeb and Ledger Connect Kit compromises cascaded across hundreds of dependent protocols. + +None of these attacks required defeating your endpoint security, your hardware wallet, or your OPSEC. They owned your stack before your code ever ran. + +**CSI Position:** Deterministic defense at the supply chain layer means: no unverified code executes. Ever. If you cannot produce a signed SBOM for every dependency in your production stack, you do not know what your code is doing. + +--- + +## Controls + +| Control ID | Control | Implementation | Priority | +|---|---|---|---| +| SCD-01 | SBOM Enforcement | Full Software Bill of Materials for all production code and dependencies | CRITICAL | +| SCD-02 | Dependency Allowlisting | Cryptographic signatures required for all third-party packages | CRITICAL | +| SCD-03 | CI/CD Secret Isolation | No production secrets in build pipelines; use vault with ephemeral tokens | CRITICAL | +| SCD-04 | Binary Analysis | Artifact scanning beyond SCA/SAST; detect tampering in compiled binaries | HIGH | +| SCD-05 | Third-Party Risk Assessment | Security test commercial software before deployment | HIGH | +| SCD-06 | Adversarial Supply Chain Simulation | Regular red-team testing of supply chain attack paths | HIGH | +| SCD-07 | Package Lock Pinning | Lock dependency versions; alert on unexpected version changes | CRITICAL | +| SCD-08 | AI Model Provenance | Verify AI model hashes and provenance before integration | HIGH | +| SCD-09 | Post-Install Hook Blocking | Disable automatic execution of install hooks in production pipelines | HIGH | +| SCD-10 | Critical Release Exam | Full security review before every production deployment | HIGH | + +--- + +## Control Implementation Detail + +### SCD-01: SBOM Enforcement + +**What an SBOM Is:** +A Software Bill of Materials is a machine-readable inventory of every component in your software: direct dependencies, transitive dependencies, their versions, licenses, and known vulnerabilities. It is the prerequisite for knowing what you are actually running. + +**Problem:** Most Web3 projects have no SBOM. They run `npm install` and trust that the ecosystem is clean. The Shai-Hulud worm proved that assumption is wrong at civilizational scale. + +**Implementation:** +```bash +# Generate SBOM with Syft (CycloneDX format) +syft packages . -o cyclonedx-json > sbom.json + +# Verify SBOM against known vulnerability database +grype sbom:./sbom.json + +# For Node.js projects specifically +npx @cyclonedx/cyclonedx-npm --output-file sbom.json +``` + +**SBOM Minimum Requirements for Production:** +- Generated on every build +- Stored in version control alongside the codebase +- Scanned against NIST NVD and OSV vulnerability databases before deployment +- Diff'd against previous SBOM: any new dependency requires explicit review + +--- + +### SCD-02: Dependency Allowlisting + +**Problem:** `npm install` fetches packages from a registry that is not cryptographically verified end-to-end. Package names can be typosquatted (`lodsh` instead of `lodash`). Maintainer accounts can be compromised and malicious versions published. + +**Implementation:** +```json +// package.json: use exact versions, not ranges +{ + "dependencies": { + "ethers": "5.7.2", // NOT "^5.7.2" or "~5.7.2" + "web3": "1.10.0" // Exact pinning prevents silent upgrades + } +} +``` + +**npm Allowlist via `.npmrc`:** +``` +# Require integrity checksums +package-lock=true +audit=true +# Use verified registry only +registry=https://registry.npmjs.org/ +``` + +**Sigstore / npm Provenance:** +As of npm 9.5+, packages can include provenance attestations signed by GitHub Actions. Require provenance for all critical dependencies: +```bash +npm install --require-provenance ethers +``` + +**Typosquatting Protection:** +- Maintain an internal allowlist of approved package names for your tech stack +- Any package not on the allowlist requires explicit security review before addition +- Use `npm-audit-resolver` to track known acceptable exceptions vs. genuine alerts + +--- + +### SCD-03: CI/CD Secret Isolation + +**The Attack Vector:** +CI/CD pipelines run with elevated credentials: deployment keys, API tokens, contract admin keys. Compromised CI/CD = ability to inject code into production at build time, before runtime security controls activate. The Ultralytics compromise used GitHub Actions to inject malicious code into the package during the build process. + +**Implementation:** +```yaml +# GitHub Actions: Never hardcode secrets +env: + DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }} # From GitHub Secrets vault + +# Never allow environment secrets to be logged + - name: Deploy + run: | + # Do NOT echo $DEPLOY_KEY or any secret + ./deploy.sh +``` + +**Secret Isolation Architecture:** +- Production signing keys: never in CI/CD environment; use hardware HSM or threshold signature scheme +- Ephemeral tokens: generate deployment credentials at runtime via Vault; expire after deployment +- Minimal privilege: CI/CD account has read + deploy access only; not admin, not key management +- Audit logging: every CI/CD secret access logged and alerted on + +**Red Team Check:** +Can an attacker who compromises your GitHub Actions workflow access your contract admin keys? If yes: your CI/CD is your single point of failure. + +--- + +### SCD-07: Package Lock Pinning + +**Problem:** `package.json` uses version ranges (`^`, `~`). `npm install` on a fresh machine can resolve to different versions than your development environment. Version bumps can introduce vulnerabilities or backdoors silently. + +**Implementation:** +```bash +# Commit package-lock.json (never .gitignore it) +git add package-lock.json +git commit -m "Pin dependency versions" + +# On CI/CD: use npm ci instead of npm install +# npm ci uses package-lock.json exactly; fails if it doesn't match +npm ci + +# Monitor for unexpected lock file changes +# Any PR that changes package-lock.json without a corresponding package.json change = red flag +``` + +**Automated Lock File Monitoring:** +```yaml +# GitHub Actions: alert on unexpected dependency changes +- name: Check for unexpected dependency changes + run: | + git diff HEAD~1 package-lock.json | grep '"version"' | head -20 + # Review all version changes before merge +``` + +--- + +### SCD-08: AI Model Provenance + +**Emerging Attack Vector (2025-2026):** +The Ultralytics YOLO11 compromise demonstrated that ML model distribution channels (GitHub releases, PyPI, Hugging Face) are as vulnerable as npm. A malicious model can execute arbitrary code at inference time, embed data exfiltration logic, or manipulate outputs for downstream attacks. + +**Implementation:** +```python +# Verify model hash before loading +import hashlib + +def verify_model(model_path: str, expected_sha256: str) -> bool: + with open(model_path, 'rb') as f: + actual_hash = hashlib.sha256(f.read()).hexdigest() + return actual_hash == expected_sha256 + +# Only load if verified +if not verify_model('./model.bin', EXPECTED_SHA256): + raise SecurityError("Model hash verification failed") +``` + +**For Crypto AI Agents (cross-reference Domain 07):** +- Verify model version and hash before every agent instantiation +- Use model provenance attestations from Hugging Face (available for major models) +- Never auto-update models in production without re-verification +- Log all model versions used for post-incident forensics + +--- + +### SCD-09: Post-Install Hook Blocking + +**What Install Hooks Do:** +`package.json` can define `preinstall`, `install`, and `postinstall` scripts that execute automatically on `npm install`. These are a primary vector for supply chain malware: the Shai-Hulud worm used postinstall hooks to execute payload on developer machines. + +**Implementation: Two Methods (both recommended):** + +**Method 1: Per-install flag** (minimum; use when scripts must run for specific packages): +```bash +npm install --ignore-scripts +``` + +**Method 2: Global `.npmrc` policy** (preferred; applies to all installs system-wide): +```bash +# Add to ~/.npmrc (user-level) or /etc/npmrc (system-level) +ignore-scripts=true +``` + +The `.npmrc` global policy is more durable than per-install flags: it cannot be accidentally omitted, applies to all developers on a shared machine, and survives shell profile changes. It is the correct production default. + +**Development Exception:** +Some packages require build scripts (native modules like `bcrypt`, `node-gyp` dependencies). Maintain an explicit allowlist of packages permitted to run install scripts: +```bash +# Only override the global policy for verified packages that require it +npm install --ignore-scripts=false node-gyp +``` + +**Red Flag:** Any package that requires a postinstall script but is not a well-known native module (check npm downloads + GitHub repo before overriding) should be investigated before allowing script execution. + +--- + +## Supply Chain Attack Pattern Recognition + +### The Maintainer Compromise Pattern +``` +Step 1: Identify widely-used package maintainer +Step 2: Phish maintainer credentials (standard social engineering) +Step 3: Publish malicious version with minimal visible changes +Step 4: Wait for automatic dependency updates to pull malicious version +Step 5: Execute payload targeting crypto wallet transactions +``` + +**Defense:** SCD-02 (allowlisting), SCD-07 (pinning), SCD-09 (hook blocking) + +### The Typosquatting Pattern +``` +Step 1: Identify popular package (e.g., 'ethers') +Step 2: Register similar name ('ether5', 'ethers-js', 'etherjs') +Step 3: Publish package with identical API, malicious internals +Step 4: Wait for developer typo or targeted attack via fake tutorials +Step 5: Exfiltrate private keys via fake wallet initialization +``` + +**Defense:** SCD-02 (allowlist of approved package names), developer training + +### The CI/CD Injection Pattern +``` +Step 1: Compromise GitHub Actions workflow via malicious Action or secret exposure +Step 2: Modify build artifacts post-compilation +Step 3: Deploy modified artifacts to production +Step 4: Modified code calls home with signing key material +``` + +**Defense:** SCD-03 (secret isolation), SCD-01 (SBOM diff), SCD-04 (binary analysis) + +--- + +## For End Users (Non-Developer) + +Most end users do not control the supply chain of the apps they use. Your controls: + +1. **Use audited, established protocols only**: fresh protocols have unverified dependency stacks +2. **Check ThirdWeb/Ledger Connect Kit status**: compromises cascade to protocols using these SDKs; monitor announcements +3. **Don't install random browser extensions**: extension supply chains are as vulnerable as npm +4. **Keep wallets on dedicated devices** (EDD-02): developer supply chain attacks targeting devs don't reach an air-gapped signing device + +--- + +## Incident Intelligence: Major Supply Chain Events + +| Date | Event | Vector | Impact | +|---|---|---|---| +| Sep 2025 | Shai-Hulud npm Worm | Maintainer account compromise cascade | 500+ packages, 2.6B weekly downloads | +| Nov 2024 | Ultralytics YOLO11 | GitHub Actions / PyPI | AI model compromise, cryptojacking | +| Dec 2023 | Ledger Connect Kit | CDN poisoning (compromised maintainer) | $600K in 2 hours; cascaded across DeFi | +| Oct 2023 | ThirdWeb vulnerability | SDK vulnerability | Cascaded to dependent NFT contracts | +| Jul 2024 | Multiple npm hijackings | Session cookie theft via VS Code extension | Wallets drained on developer machines | + +--- + +## Research References + +- Research Note 005: Supply Chain Vectors → `research/005_supply_chain_vectors.md` +- CSI Article: Hijacked npm Packages: The New Cyber Weapon Against Crypto and Web3 Gaming +- CSI Article: Ultralytics YOLO11 Compromised via Supply Chain Attack +- NIST SP 800-204D: Software Supply Chain Security for DevSecOps + +--- + +*CSI CryptoSHIELD Framework v1.1 | Domain 06: Supply Chain Defense* +*Cyber Strategy Institute | Open-Source | Sovereignty-First* diff --git a/07-ai-agent-security/README.md b/07-ai-agent-security/README.md new file mode 100644 index 0000000..a6306a5 --- /dev/null +++ b/07-ai-agent-security/README.md @@ -0,0 +1,73 @@ +# Domain 07: AI Agent and Autonomous System Security (AAS) + +**CSI CryptoSHIELD Framework v1.1 | May 2026** + +--- + +## Scope and Companion Framework Reference + +This domain provides **crypto-specific AI agent security controls** for DeFi environments. It covers the immediate, wallet-facing risks of AI agents transacting on-chain. + +**Full agentic AI governance is maintained by [AI SAFE² v3.0](https://github.com/CyberStrategyInstitute/ai-safe2-framework).** When deploying a DeFi AI agent beyond the controls in this domain, navigate to AI SAFE² as follows: + +| Your Governance Need | AI SAFE² Destination | +|---|---| +| Classify what your agent is allowed to do autonomously | **ACT Capability Tiers (1-4)**: determines which governance requirements apply | +| Harden agent inputs against poisoned data | **Pillar 1: Sanitize and Isolate (S)**: input validation, context boundary enforcement | +| Secure your MCP server integration | **CP.5.MCP**: STDIO transport security, bearer token auth, supply chain attestation | +| Ensure a human can always override / kill-switch | **CP.10: HEAR Doctrine**: cryptographically enforced Human Ethical Agent of Record | +| Prevent agent self-replication or unauthorized spawning | **CP.9: Agent Replication Governance**: first-in-field control for this threat class | +| Map controls to ISO 42001, NIST AI RMF, EU AI Act | **Compliance Crosswalk**: 32-framework mapping in the AI SAFE² appendix | +| Govern Non-Human Identity (NHI) lifecycle | **Pillar 2: Audit and Inventory (A)**: NHI enumeration, access control, deprovisioning | + +If your DeFi agent is ACT-3 or ACT-4 (material autonomous financial decisions or swarm coordination), the HEAR Doctrine (CP.10) is mandatory: not optional. An agent that can drain a wallet must have a cryptographically enforced human override that cannot be social-engineered away. CryptoSHIELD AAS controls alone are insufficient at that capability tier. + +**Full agentic AI governance covers:** + +- ACT Capability Tier classification (ACT-1 through ACT-4) +- CP.10: HEAR Doctrine (Human Ethical Agent of Record: cryptographically enforced fail-closed) +- CP.9: Agent Replication Governance (first-in-field control for agent self-replication scenarios) +- 151 pillar controls across five operational pillars +- 10 cross-pillar governance controls (CP.1-CP.10) +- OWASP AIVSS v0.8 AAF composite risk scoring +- NEXUS-A2A protocol governance +- Non-Human Identity (NHI) full lifecycle management +- 32-framework compliance mapping including ISO 42001, NIST AI RMF, EU AI Act + +--- + +## Current Threat Context (2026) + +By Q1 2026, AI agent wallets represented 8-12% of EVM DeFi transaction volume. This is not a future risk. It is the current attack surface. + +**Confirmed operational threats:** +- **Memory poisoning**: Vector database injection creating sleeper agents (CS-AI-01) +- **Prompt injection / logic redefinition**: Freysa exploit: hardcoded "never transfer funds" directive overridden by redefining function logic (CS-AI-02) +- **Data chain poisoning**: GitHub documentation poisoned causing AI coding agent to generate private key-stealing code (CS-AI-03) +- **AI swarm attacks**: GTG-1002 (November 2025): 30 organizations simultaneously, 80-90% human-out-of-loop (CS-AI-04) +- **ClawJacked class**: Remote takeover of self-hosted trading agents via WebSocket vulnerabilities +- **Step Finance ($40M, January 2026)**: Device compromise + AI trading agent amplification + +--- + +## Controls + +| Control ID | Control | Priority | +|-----------|---------|---------| +| AAS-01 | Keyless agent architecture: AI agents never hold private keys; authenticated signing only | CRITICAL | +| AAS-02 | Memory integrity monitoring: regular hash verification of vector database contents | CRITICAL | +| AAS-03 | Prompt injection hardening: immutable core instructions; multi-layer validation | CRITICAL | +| AAS-04 | Agent wallet isolation: minimal-balance dedicated wallets per strategy | HIGH | +| AAS-05 | Testnet simulation first: no mainnet deployment without sandbox validation | HIGH | +| AAS-06 | Hard transaction rate limits per time window | CRITICAL | +| AAS-07 | Real-time agent behavior anomaly detection | HIGH | +| AAS-08 | Tool call allowlisting: permitted smart contracts and endpoints only | CRITICAL | +| AAS-09 | Oracle diversity: minimum three independent sources | HIGH | +| AAS-10 | Swarm isolation: no shared memory between swarm agent instances | HIGH | + +Full control specifications and AI SAFE² cross-references: [FRAMEWORK-ALIGNMENT.md](../FRAMEWORK-ALIGNMENT.md) + +--- + +*Domain 07: AI Agent and Autonomous System Security | CryptoSHIELD v1.1* +*Full agentic governance: [AI SAFE² v3.0](https://github.com/CyberStrategyInstitute/ai-safe2-framework)* diff --git a/08-governance-compliance-sovereignty/README.md b/08-governance-compliance-sovereignty/README.md new file mode 100644 index 0000000..8fc7db6 --- /dev/null +++ b/08-governance-compliance-sovereignty/README.md @@ -0,0 +1,243 @@ +# Domain 08: Governance, Compliance, and Sovereignty (GCS) + +**CSI CryptoSHIELD Framework v1.1** +Cyber Strategy Institute | Classification: Open-Source | Sovereignty-First + +--- + +## Domain Philosophy + +Financial sovereignty is not idealism. It is the constitutional baseline. + +The Fifth Circuit Court of Appeals said it plainly in November 2024: Tornado Cash's immutable smart contracts do not qualify as "property" under IEEPA. OFAC removed the sanctions in March 2025. The courts have repeatedly blocked FinCEN's Corporate Transparency Act enforcement. Treasury's real estate reporting rule was struck down as exceeding statutory authority. The pattern is consistent: regulatory overreach against self-custody and privacy tools fails judicial review in the United States. + +CSI's governance framework is built on that legal foundation. AML/KYC at CEX entry and exit points is legitimate and workable. Surveillance of self-custodied wallets, private transaction monitoring, and CBDC-style spending controls are unconstitutional and will be resisted: in court and in architecture. + +This domain does not provide legal advice. It provides the governance architecture for crypto holders who want to operate within U.S. law while defending their constitutional rights. + +**Alignment:** Trump Administration Executive Order (January 2025), protecting self-custody rights and prohibiting CBDC development. Not EU MiCA. + +--- + +## Controls + +| Control ID | Control | Implementation | Priority | +|---|---|---|---| +| GCS-01 | Self-Custody First Policy | Default: all significant holdings in self-custodied wallets | CRITICAL | +| GCS-02 | CBDC Resistance Protocol | No CBDC adoption; oppose surveillance-enabled digital currency | CRITICAL | +| GCS-03 | Legal Awareness | Track FinCEN/SEC/CFTC developments; know your rights | HIGH | +| GCS-04 | Minimal KYC Surface | KYC only at regulated CEX entry/exit; minimize exposure at exchanges | HIGH | +| GCS-05 | Vendor Sovereignty Assessment | Evaluate all third-party custody against sovereignty criteria | HIGH | +| GCS-06 | Incident Response Plan | Documented plan: digital theft, physical coercion, legal/regulatory events | CRITICAL | +| GCS-07 | Decentralized Governance Participation | Engage DAO governance to prevent single-actor control of protocols | MEDIUM | +| GCS-08 | Open Source Preference | Prefer auditable open-source tools over black-box commercial solutions | HIGH | +| GCS-09 | Privacy Tool Assessment | Evaluate privacy tools (ZK proofs, privacy coins) per current legal context | MEDIUM | +| GCS-10 | Annual Framework Review | Annual review of all controls against updated threat landscape | HIGH | + +--- + +## Control Implementation Detail + +### GCS-01: Self-Custody First Policy + +**The Principle:** +"Not your keys, not your crypto" is not a slogan. It is a security architecture statement. Custodial platforms are: +- Single points of failure (FTX: $8B+ customer funds lost) +- Regulatory seizure targets (Tornado Cash precedent until reversal; ongoing CEX regulatory pressure) +- Data breach vectors (Coinbase insider bribery: $400M remediation cost, customer addresses/IDs exposed) + +**Implementation:** +- Holdings >$1,000: cold wallet (hardware wallet, self-custodied) +- Holdings >$50,000: multisig with geographic distribution (WKS-02) +- CEX use cases: fiat on/off ramp only; do not hold crypto at CEX beyond the time needed to complete the transaction +- Exception: liquid trading allocation (maximum 10% of holdings) may remain at CEX for active trading + +**Custodial Risk Assessment Matrix:** +| Factor | Safe | Caution | Avoid | +|---|---|---|---| +| Regulatory jurisdiction | U.S. regulated | Non-U.S. regulated | Offshore, unregulated | +| Proof of reserves | Published, verified | Claimed, unverified | None | +| Insurance | FDIC for fiat + crypto coverage | Fiat only | None | +| History | Clean, >5 years | Minor incidents | Major incident or <1 year | +| Admin key architecture | Multi-sig, audited | Opaque | Unknown | + +--- + +### GCS-02: CBDC Resistance Protocol + +**What CBDC Enables:** +A central bank digital currency issued by the Federal Reserve or any U.S. government entity would create a surveillance layer over every financial transaction: programmable money with built-in spending controls, expiration dates, and politically controllable exclusion mechanisms. This is the antithesis of financial sovereignty. + +**Current U.S. Legal Status:** +- Trump Administration EO (January 2025) prohibits U.S. CBDC development and protects self-custody rights +- No U.S. CBDC is currently in development or authorized +- Stablecoins regulated under GENIUS Act (reserve-backed, AML-compliant) are not CBDCs + +**CSI Position:** +Any future administration attempt to introduce CBDC will be resisted through: legal challenge (following the Fifth Circuit Tornado Cash model), public advocacy, and architectural rejection (no CSI-aligned infrastructure will integrate CBDC payment rails). + +**Active Monitoring:** +- Track Federal Reserve CBDC research publications +- Monitor FinCEN rulemaking at regulations.gov +- Follow Electronic Frontier Foundation (EFF) and Coin Center legal challenges + +--- + +### GCS-03: Legal Awareness + +**Key Regulatory Landscape (as of May 2026):** + +| Development | Status | Implication | +|---|---|---| +| Corporate Transparency Act (CTA) | Enforcement blocked by multiple federal courts | FinCEN reporting requirements suspended | +| Tornado Cash Sanctions | Overturned (5th Circuit, Nov 2024); OFAC removal March 2025 | Smart contract privacy tools are not per se illegal | +| SEC Crypto Securities Position | Retreating; Trump Administration SEC pro-clarity | Most crypto assets confirmed NOT securities (March 2026) | +| GENIUS Act (Stablecoins) | Signed into law | Reserve-backed stablecoins with AML compliance: legal framework established | +| CLARITY Act | Passed House; pending Senate | Regulatory clarity for digital assets; reduces SEC/CFTC overlap | +| EU MiCA | Active in EU; does not apply to U.S. holders | U.S. holders not subject to MiCA obligations | +| FinCEN Real Estate Rule | Struck down as exceeding statutory authority | | + +**Resources for Legal Monitoring:** +- Coin Center legal analysis: coincenter.org +- Blockchain Association policy updates: theblockchainassociation.org +- FinCEN rulemaking: fincen.gov/news +- Federal court decisions: courtlistener.com (search "cryptocurrency") + +--- + +### GCS-04: Minimal KYC Surface + +**The KYC Breach Risk:** +Every exchange where you complete KYC holds: legal name, date of birth, home address, government ID (passport/driver's license), and in some cases selfie biometrics. These datasets are: +- Breach targets (Coinbase insider bribery: customer data sold to criminals enabling physical coercion) +- OSINT linkage tools (connects your identity to blockchain addresses visible on exchange deposit/withdrawal records) +- Regulatory seizure data + +**Minimization Strategy:** +- Complete KYC at minimum number of exchanges needed for fiat on/off ramp: one to three, maximum +- Do not complete KYC at offshore or unregulated exchanges: the data will be breached or sold +- For DEX use: no KYC required; maintain privacy by using fresh wallets for DEX interactions (see OPS-03) +- Document which exchanges hold your KYC data; monitor those exchanges for breach notifications + +**Legal Note:** KYC compliance at licensed U.S. exchanges is a legal requirement for fiat transactions over applicable thresholds. Compliance at these regulated points is required and reasonable. This control is about minimizing KYC surface beyond legal requirements, not about evading legitimate compliance. + +--- + +### GCS-05: Vendor Sovereignty Assessment + +**Evaluation Criteria for Any Third-Party Custody or Wallet Service:** + +``` +Sovereignty Checklist: +[ ] Can I export my keys/seed phrase at any time? +[ ] Is the software open source and audited? +[ ] Does the vendor have authority to freeze my assets unilaterally? +[ ] Is the vendor subject to U.S. regulatory jurisdiction? +[ ] What happens to my funds if the vendor becomes insolvent? +[ ] Has the vendor complied with government data requests historically? +[ ] Does the vendor store my KYC data? Where? For how long? +``` + +**Disqualifying Criteria:** +- Vendor controls private keys with no user export option +- Vendor explicitly reserves right to freeze accounts based on transaction patterns (CBDC-adjacent behavior) +- Vendor is incorporated in a jurisdiction with mandatory asset freeze obligations (certain EU countries under MiCA) +- Vendor has no published proof of reserves or solvency mechanism + +--- + +### GCS-06: Incident Response Plan + +**Three Incident Types Requiring Separate Plans:** + +**Type 1: Digital Theft / Wallet Compromise** +``` +Immediate (0-60 min): +1. Move remaining funds to new cold wallet (pre-generated, never connected) +2. Revoke all token approvals (revoke.cash) +3. Isolate compromised device from all networks +4. Do NOT attempt to "fight back" on-chain: you will lose + +Evidence (0-24h): +1. Screenshot all on-chain transactions +2. Record all wallet addresses involved +3. Export transaction history from all affected wallets +4. Preserve all communications related to the incident + +Report: +- FBI IC3: ic3.gov +- Chainabuse: chainabuse.com +- DFPI (California): dfpi.ca.gov +- If exchange involved: contact exchange support immediately with transaction hashes +``` + +**Type 2: Physical Coercion** +``` +Active Coercion: +- Activate OPS-06 (decoy wallet) as primary surrender option +- Activate OPS-10 (duress signal) to trusted contact +- Do NOT resist if physical harm is imminent +- Your crypto is worth less than your life + +Post-Incident: +- Contact law enforcement immediately +- Contact FBI field office if kidnapping or interstate crime involved +- Document all details before memory fades +- Do NOT engage social media until law enforcement advises +``` + +**Type 3: Regulatory Action** +``` +Pre-Planning: +- Identify legal counsel specializing in digital asset law before you need them +- Know your rights: you are not required to answer questions without counsel +- Document the lawful basis for all your transactions + +If Approached: +- Do not provide information beyond legal requirements without counsel +- Do not consent to device searches without a warrant +- Contact digital asset legal counsel immediately +``` + +--- + +### GCS-07: Decentralized Governance Participation + +**Why Single-Actor Control Fails:** +LNDFi ($1.18M), BrincFi, and Radiant Capital ($50M) all suffered from governance structures that appeared decentralized but were controlled by a small group. The multi-sig masquerade: multiple keys controlled by colluding or compromised insiders. + +**Participation Standards:** +- For protocols holding significant funds: verify the number of independent multisig signers (names, roles, locations) +- Vote on governance proposals: abstention enables single-actor capture +- Evaluate time-lock implementation: any protocol executing admin actions without a 72-hour minimum timelock should be treated as a higher-risk position +- Flag and publicly challenge governance proposals that expand admin key authority without commensurate security enhancement + +--- + +## Regulatory Alignment Summary + +| Jurisdiction | CSI Alignment | +|---|---| +| United States (2025-2026) | Primary; aligned with Trump EO, Fifth Circuit Tornado Cash ruling, GENIUS Act stablecoin framework | +| EU (MiCA) | Not aligned; MiCA surveillance architecture conflicts with sovereignty-first design | +| UK (FCA) | Informational awareness; compliance required for UK-based operations | +| International | CEX AML/KYC compliance at regulated entry/exit points; self-custody sovereignty universal | + +--- + +## Companion Framework References + +This domain intentionally defers on two critical governance dimensions: + +**AI Agent Governance:** CryptoSHIELD Domain 07 (AAS) provides crypto-specific AI agent controls. For comprehensive AI agent governance including HEAR Doctrine, ACT Capability Tiers, agent replication governance, and the full 161-control framework, see: +→ [AI SAFE² Framework v3.0](https://github.com/CyberStrategyInstitute/ai-safe2-framework) + +**Cognitive Sovereignty:** For governance of the human operator layer: protecting your own cognition from AI-era manipulation, regulatory narrative capture, and decision automation: see: +→ [Cognitive Sovereignty Framework](https://github.com/CyberStrategyInstitute/cognitive-sovereignty) + +The three-framework stack governs the complete human-AI-crypto system. CryptoSHIELD alone is insufficient for organizations deploying AI agents in DeFi or individuals operating in high-influence environments. + +--- + +*CSI CryptoSHIELD Framework v1.1 | Domain 08: Governance, Compliance, and Sovereignty* +*Cyber Strategy Institute | Open-Source | Sovereignty-First* diff --git a/09-consumer-fraud-defense/README.md b/09-consumer-fraud-defense/README.md new file mode 100644 index 0000000..3a70e99 --- /dev/null +++ b/09-consumer-fraud-defense/README.md @@ -0,0 +1,279 @@ +# Domain 09: Consumer Fraud and Financial Grooming Defense (CFD) + +**CSI CryptoSHIELD Framework v1.1 | Added in v1.1 | May 2026** + +--- + +## The Missing $11 Billion + +This domain did not exist in CryptoSHIELD v1.0. That was a structural gap. + +The FBI IC3 2025 Annual Report documents $11.366 billion in U.S. crypto-related fraud losses in a single year. $7.2 billion of that is pig butchering alone. This total is nearly three times the on-chain protocol exploit total tracked by DefiLlama for the same period. + +The gap existed because most crypto security frameworks focus on on-chain protocol security: smart contract bugs, bridge exploits, key compromise. These are real and significant. They are also not the primary vector by which ordinary people lose their life savings to crypto crime. + +Consumer fraud: pig butchering, ATM coercion, fake platforms, recovery scams, professor scams: operates almost entirely off-chain, through social engineering, manufactured trust, and psychological manipulation. It does not appear in DefiLlama. It barely appears in crypto security discourse. It accounts for the majority of crypto-related harm. + +This domain addresses it. + +**For the cognitive manipulation and psychological resilience layer:** See [Cognitive Sovereignty Framework](https://github.com/CyberStrategyInstitute/cognitive-sovereignty): specifically T-CT-004 (Personalized Narrative Injection), T-CT-005 (Social Proof Manipulation), T-CT-007 (Trust Network Infiltration), and Domain 3 (Emotional Resilience). + +--- + +## The Fee Escalation Kill Chain + +Every pig butchering and platform fraud follows the same escalating commitment architecture. Understanding it means recognizing it before the final extraction phase: + +``` +Phase 1: Trust Building (weeks to months) + ↓ Dating app / WhatsApp / Telegram contact + ↓ Personal relationship development + ↓ Introduction of investment opportunity ("I can show you how I do it") + +Phase 2: Platform Introduction + ↓ Introduction to fraudulent trading platform + ↓ Victim registers; UI shows professional design + ↓ Small initial deposit; "profits" visible immediately + +Phase 3: Trust Bait + ↓ Small test withdrawal SUCCEEDS (this is the trap) + ↓ Victim believes platform is legitimate + ↓ Larger deposits encouraged; profits grow + +Phase 4: Escalation and Commitment + ↓ Victim deposits larger amounts + ↓ "Profits" shown are fabricated by the platform + ↓ Withdrawal attempt → BLOCKED + +Phase 5: Fee Extraction (the actual profit for scammers) + ↓ Fee demand 1: "Tax payment required to unlock withdrawal" + ↓ Victim pays tax + ↓ Fee demand 2: "AML verification deposit required" + ↓ Victim pays AML + ↓ Fee demand 3: "Account upgrade required" + ↓ Fee demand 4: "Green channel access fee" + ↓ Platform disappears + +Phase 6: Re-Victimization (CS-FRD-02) + ↓ "Recovery service" contacts victim proactively + ↓ Second extraction cycle begins +``` + +**The decisive intervention point:** The test withdrawal that succeeds in Phase 3 is the trust bait. It is not a sign the platform is legitimate. No legitimate platform needs to bait trust with a test withdrawal. The decisive control is CFD-03: pattern recognition before Phase 3 completes. + +--- + +## Controls + +### CFD-01: Platform Legitimacy Stack Check + +**Priority:** CRITICAL +**Threat IDs:** CS-FRD-01, CS-FRD-04, CS-SOC-07 + +**The complete stack: run all four before any deposit:** + +| Check | Tool | What to Look For | +|-------|------|-----------------| +| Regulatory registration | DFPI (California: dfpi.ca.gov) | Is the platform registered? If not, it is not automatically a scam but warrants extreme caution | +| Scam database | CryptoScamDB (cryptoscamdb.org) | Is the domain or any associated domain listed? | +| Victim reports | Chainabuse (chainabuse.com) | Are any wallet addresses associated with the platform already reported? | +| Complaint search | DFPI Scam Tracker | Search the platform name and any variations | +| CFTC and SEC search | CFTC.gov and SEC EDGAR | Are they registered where required? | + +**Implementation:** +- Run the full stack before depositing any amount on any new platform +- Search platform name, domain, and all variations (including typosquatted lookalikes) +- A clean result does not guarantee legitimacy: many fraudulent platforms are too new to have reports +- The 10-Day Rule (CFD-03) applies even if the platform passes the stack check + +--- + +### CFD-02: Unsolicited Investment Offer Zero Trust + +**Priority:** CRITICAL +**Threat IDs:** CS-FRD-01, CS-FRD-04, CS-SOC-03 + +**Absolute rule:** Any investment opportunity that arrives through a direct message, dating app, social media contact, or group chat invitation is treated as a social engineering attempt until independently verified through official channels. + +**Implementation:** +- No DM, dating app contact, or random social media connection ever introduces a legitimate investment opportunity +- The more persuasive and personalized the offer, the higher the red flag: AI-generated personas are indistinguishable from real people in text +- Verify: can you find this person's identity through independent, public sources not provided by them? +- Verify: does this platform exist in any legitimate financial industry database? +- Default response to any unsolicited investment introduction: decline + +**The AI detection problem:** Traditional detection relied on linguistic signals (poor grammar, spelling errors, unusual phrasing). AI-generated personas produce grammatically flawless, culturally appropriate, personally tailored messages with zero traditional detection signals. The only reliable detection is structural, not linguistic: the pattern of introduction → relationship → investment → platform is the signal, not the quality of the writing. + +--- + +### CFD-03: Profitable Test Withdrawal Recognition + +**Priority:** CRITICAL +**Threat IDs:** CS-FRD-01 + +**The test withdrawal is not evidence of legitimacy.** Fraudulent platforms allow a small test withdrawal in Phase 3 specifically to build trust and justify larger deposits. + +**Implementation:** +- Recognize the test withdrawal as the trust bait mechanism, not platform validation +- Apply the following logic: If a platform I did not seek out, on which I am already "earning significant profits" after a short period, is now encouraging me to deposit more money after allowing me to withdraw a small amount: I am in Phase 3 of the pig butchering kill chain +- Do not interpret a successful test withdrawal as platform validation under any circumstances +- The correct response to a "successful" test withdrawal on an unsolicited platform: withdraw everything immediately, not invest more + +--- + +### CFD-04: Fee Demand as Exit Signal + +**Priority:** CRITICAL +**Threat IDs:** CS-FRD-01, CS-FRD-02 + +**Absolute rule:** Any platform that demands payment of a fee, tax, AML deposit, account upgrade charge, certification cost, or any other charge as a precondition for withdrawing funds that are already in the account is engaged in fraud. + +**No exceptions:** +- "Government tax" on profits → Fraud. Taxes are paid to governments, not to trading platforms. +- "AML verification deposit" → Fraud. AML compliance does not require deposits from users. +- "Account upgrade fee" → Fraud. Legitimate platforms do not charge to access your own money. +- "Risk collateral" → Fraud. +- "Green channel access" → Fraud. + +**Implementation:** +- Upon receipt of any fee demand to unlock existing balances: stop all further engagement +- Do not pay any fee regardless of amount +- Do not believe promises that the platform will "refund the fee" from profits +- Begin documentation immediately and report to IC3, DFPI, and Chainabuse + +--- + +### CFD-05: Bitcoin ATM Transaction Refusal + +**Priority:** CRITICAL +**Threat IDs:** CS-FRD-03 + +**Absolute rule:** No government agency (IRS, FBI, Social Security Administration, FTC), bank, or technology company will ever instruct you to withdraw cash and deposit it at a Bitcoin ATM. This scenario is always fraud, without exception. + +**Implementation:** +- If you receive a phone call from anyone claiming to be a government official or bank representative directing you to a Bitcoin ATM: hang up and call the agency's official number directly (found on their official website, not given by the caller) +- If you are at a Bitcoin ATM and there is any question about whether the transaction is legitimate: stop and call a trusted family member or friend before proceeding +- Protect elder family members with explicit conversations about this pattern: adults over 60 represent 86% of Bitcoin ATM fraud losses + +**The urgency signal:** These scams always create a false sense of urgency ("your Social Security number has been compromised and you must act now"). Urgency is a social engineering mechanism. Slow down. + +--- + +### CFD-06: Elder Household Protocol + +**Priority:** HIGH +**Threat IDs:** CS-FRD-03, CS-FRD-01 + +**Implementation:** +- Establish explicit agreement with family members over 60: any cryptocurrency transaction over $500 requires a conversation with a trusted adult family member first +- Specific scenarios to brief: Bitcoin ATM coercion (CFD-05), government impersonation calls, grandchild-in-trouble scam +- Create a "buddy system" for any investment activity: no solo investment decisions on unfamiliar platforms +- Remove or limit cryptocurrency app access on devices used by elder family members who do not actively invest + +--- + +### CFD-07: Recovery Scam Firewall + +**Priority:** HIGH +**Threat IDs:** CS-FRD-02 + +**Absolute rule:** No legitimate service can reverse a confirmed blockchain transaction. + +**Implementation:** +- After any crypto loss: do not engage with any "recovery service" that contacts you, regardless of how official or professional they appear +- Legitimate recovery assistance options: FBI IC3 (ic3.gov), CFTC, licensed blockchain forensics firms (Chainalysis, TRM Labs): these firms assist law enforcement with tracing; they do not "recover" funds for a fee +- Any entity that promises to recover your crypto for an upfront fee is engaged in CS-FRD-02 re-victimization +- Report any recovery scam contact to: IC3, Chainabuse, and DFPI + +--- + +### CFD-08: AI Persona Detection Protocol + +**Priority:** HIGH +**Threat IDs:** CS-AI-05, CS-FRD-01 + +**Implementation:** +- For any online relationship that introduces investment opportunities: require out-of-band verification +- Out-of-band verification: video call that includes off-script conversation, unexpected topic changes, and specific questions the person should be able to answer based on their claimed background +- A pre-scripted video call or "technical difficulties" preventing video are red flags +- Request a live, unscripted interaction: AI deepfakes and pre-recorded video are distinguishable with specific demands (write a word on paper and hold it up, describe something visible in their current environment, etc.) + +**The AI detection arms race:** Deepfake video is improving rapidly. The structural pattern: unsolicited contact introducing investment opportunity: is more reliable than any technical detection method for consumer-facing contexts. + +**CSF cognitive resilience layer:** For systematic deepfake resilience and AI persona detection training: [CSF T-CT-016](https://github.com/CyberStrategyInstitute/cognitive-sovereignty/blob/main/taxonomy/manipulation-techniques.md) + +--- + +### CFD-09: Group Chat Investment Protocol + +**Priority:** HIGH +**Threat IDs:** CS-FRD-04, CS-MKT-03 + +**Implementation:** +- No investment decisions based on group chat consensus, regardless of how many members appear to agree +- Recognize that "professor" figures and "assistant" figures in investment groups are role-play personas operated by the scam compound +- Other "successful members" of the group are either fabricated accounts or victims being used as social proof +- Apply the Rotator Effect framework (see [Research Note 002](../research/002_rotator_effect.md)): who benefits from this group's investment behavior? + +**The social proof manipulation mechanism:** The group creates the illusion of community validation. Multiple accounts showing "profits," "testimonials," and "gratitude" toward the professor are all operated by the same scam infrastructure. The cognitive vulnerability exploited is social proof: humans are wired to follow group behavior. CFD-09 requires conscious override of this instinct. + +--- + +### CFD-10: Platform Custodial Assessment + +**Priority:** CRITICAL +**Threat IDs:** CS-FRD-01, CS-SOV-02 + +**Implementation:** +- Before depositing to any platform, answer: can you independently verify your balance on-chain? +- For a legitimate exchange: your balance should be verifiable against on-chain transaction records +- For a fraudulent platform: the "balance" displayed in the UI is a fabricated number with no on-chain correspondence +- Ask: what wallet address holds my deposited funds? Can I verify this on a blockchain explorer? + +**The custodial fraud signal:** Fraudulent platforms cannot provide a verifiable on-chain wallet address for user funds because the funds do not exist in a segregated wallet: they have already been moved to attacker-controlled addresses. If a platform cannot or will not answer this question, treat it as a fraud signal. + +--- + +## Reporting Stack for CFD Incidents + +**First 60 minutes after any CFD incident:** +1. Stop all further engagement with the platform or contact immediately +2. Screenshot all communications, platform interfaces, transaction confirmations +3. Record all wallet addresses used (both yours and the platform's) +4. Record all transaction hashes + +**Reporting priority order:** +1. FBI IC3 (ic3.gov): all crypto fraud +2. DFPI Crypto Scam Tracker: California residents; all others use your state financial regulator +3. Chainabuse: submit all attacker/platform wallet addresses +4. CryptoScamDB: submit scam platform URL +5. CFTC: if any futures, options, or derivatives were involved +6. FTC: if impersonation of government agency (CFD-05 pattern) + +**Recovery reality check:** +- Blockchain transactions cannot be reversed +- Funds sent to fraudulent platforms are likely gone +- Reporting helps law enforcement build patterns and potentially freeze funds at exchange landing points +- Recovery from secondary scammers (CS-FRD-02) is never possible + +--- + +## Domain 09 Metrics (FBI IC3 2025) + +| Fraud Type | U.S. Annual Loss (2025) | Primary Target | +|-----------|------------------------|----------------| +| Pig butchering / investment fraud | $7.2B | 30-60 demographic, DFPI data shows no demographic immunity | +| Asset recovery re-victimization | $1.4B | Previous fraud victims | +| Bitcoin ATM coercion | $333M | Adults 60+ (86% of losses) | +| Investment group / professor scam | $Millions per campaign | All demographics | +| Tech support crypto scam | $1.226B | Adults 60+ disproportionately | +| AI-enabled fraud (all types) | $893M | All demographics | +| **Total consumer crypto fraud** | **~$11.4B** | | + +**FBI's own finding:** 78% of active pig butchering victims have no idea they are being scammed. Detection in time to prevent loss requires pattern recognition before Phase 4 of the kill chain (Escalation and Commitment). + +--- + +*Domain 09: Consumer Fraud and Financial Grooming Defense | CryptoSHIELD v1.1* +*Added in v1.1 based on DFPI Scam Tracker, FBI IC3 2025, and Chainabuse cross-analysis* +*Cognitive manipulation layer: [Cognitive Sovereignty Framework](https://github.com/CyberStrategyInstitute/cognitive-sovereignty)* diff --git a/assets/framework-architecture.svg b/assets/framework-architecture.svg new file mode 100644 index 0000000..f6adb90 --- /dev/null +++ b/assets/framework-architecture.svg @@ -0,0 +1,99 @@ + + + + + + CSI SECURITY FRAMEWORK STACK + Three complementary frameworks. One unified defense posture. + + + + CSI CryptoSHIELD Framework v1.1 + github.com/CyberStrategyInstitute/crypto-shield + + + + + + Wallet & Key Sovereignty + + + Endpoint Defense + + + OPSEC & Physical + + + On-Chain Monitoring + + + Supply Chain Defense + + + + Social & Platform Sec + + + Consumer Fraud Defense + + + Governance & Sovereignty + + + Cross-Domain (CDG) + + + + + + 9 Domains + 95 Controls + 42 Threats (CTRS) + OODA Playbooks + U.S. Constitutional + + + + + + + + AI Agent Governance + Cognitive Layer + + defers to + defers to + + + + AI SAFE² v3.0 + github.com/CyberStrategyInstitute/ai-safe2-framework + + 161 Controls (151 Pillar + 10 CP) + HEAR Doctrine (CP.10) | ACT Tiers 1-4 + Agent Replication Governance (CP.9) + NHI Identity | MCP Server Security + + + + + Cognitive Sovereignty + github.com/CyberStrategyInstitute/cognitive-sovereignty + + 6 Resilience Domains | 41 Threat Entries + CTSS Scoring | Digital & AI Symbiosis + Deepfake Resistance | Social Engineering + Human Decision Autonomy + + + + "Policy is just intent. Engineering is reality." + Cyber Strategy Institute | cyberstrategyinstitute.com | Open-Source | Sovereignty-First + + + + + + + + diff --git a/intelligence/TEMPLATE.md b/intelligence/TEMPLATE.md new file mode 100644 index 0000000..ab21a0d --- /dev/null +++ b/intelligence/TEMPLATE.md @@ -0,0 +1,105 @@ +# Intelligence Report Template + +**CSI CryptoSHIELD Framework v1.1** +Use this template for weekly or incident-based intelligence reports. + +--- + +## Report Header + +``` +Report ID: CSI-INT-[YYYY-MM-DD]-[SEQ] +Date: +Coverage Period: +Classification: Open-Source +Author: +Review Status: [ ] Draft [ ] Reviewed [ ] Published +``` + +--- + +## Executive Summary (3-5 sentences) + +State the most important finding and its implication for crypto holders. + +--- + +## Threat Events (this period) + +For each notable event: + +``` +Incident ID: CS-[CAT]-[NUM]-[DATE]-[LOC] +Threat ID: [taxonomy ID] +Date: +Platform/Target: +Loss (USD): +Attack Vector: +Official Attribution: +CSI Attribution Assessment: + false_flag_prob: [0.0-1.0] + insider_vector: [true/false] + ai_assisted: [true/false] +Controls That Would Have Prevented: + - [CTRL-ID]: [brief explanation] +Summary: [2-3 sentences] +Source: [URL or reference] +``` + +--- + +## Trend Analysis + +What patterns are emerging across this period's events? + +- Threat ID frequency changes: +- New attack vectors identified: +- Geographic concentration shifts: +- AI involvement trajectory: + +--- + +## High-Priority Warnings + +List any threats that require immediate holder attention this period. + +| Threat | Urgency | Recommended Action | +|---|---|---| +| | | | + +--- + +## Control Effectiveness Review + +Are any existing controls proving insufficient against new attack variants? Recommend updates. + +--- + +## Companion Framework Alerts + +**AI SAFE² cross-reference:** Any crypto incidents with AI agent governance implications? +**CSF cross-reference:** Any social engineering or cognitive manipulation patterns worth flagging to CSF? + +--- + +## DefiLlama Cross-Reference + +| Protocol | DefiLlama Incident ID | CSI Enrichment | +|---|---|---| +| | | | + +--- + +## Appendix: Raw Data + +Paste raw threat event JSON records here for registry integration. + +```json +{ + "threat_events": [] +} +``` + +--- + +*Intelligence Template | CSI CryptoSHIELD Framework v1.1 | Open-Source* diff --git a/metadata/threat-event-schema.json b/metadata/threat-event-schema.json new file mode 100644 index 0000000..1470f0c --- /dev/null +++ b/metadata/threat-event-schema.json @@ -0,0 +1,355 @@ +{ + "$schema": "http://json-schema.org/draft-07/schema#", + "$id": "https://github.com/CyberStrategyInstitute/crypto-shield/metadata/threat-event-schema.json", + "title": "CryptoSHIELD Threat Event Schema v1.1", + "description": "Machine-readable metadata schema for crypto security threat events. Compatible with SIEM ingestion, analytics platforms, and DefiLlama enrichment API.", + "type": "object", + "required": ["id", "timestamp", "threat_id", "category", "severity", "ooda_phase"], + "properties": { + "id": { + "type": "string", + "description": "Unique event ID: [threat_id]-[YYYYMMDD]-[location/platform code]", + "examples": ["CS-PHY-01-20250919-MN", "CS-FRD-01-20250301-CA-001"] + }, + "timestamp": { + "type": "string", + "format": "date-time", + "description": "ISO 8601 UTC timestamp of event detection or occurrence" + }, + "discovered_date": { + "type": "string", + "format": "date" + }, + "exploit_date": { + "type": "string", + "format": "date", + "description": "For delayed exploits (e.g., backdoor planted weeks before activation)" + }, + "threat_id": { + "type": "string", + "pattern": "^CS-[A-Z]{2,4}-[0-9]{2}$", + "description": "CryptoSHIELD threat taxonomy ID", + "examples": ["CS-PHY-01", "CS-FRD-01", "CS-AI-04"] + }, + "category": { + "type": "string", + "enum": [ + "Physical", "Insider", "Social Engineering", "Malware", + "Wallet", "DeFi Protocol", "Supply Chain", "AI Agent", + "Market Manipulation", "Financial Fraud", "Sovereignty", "Extortion" + ] + }, + "subcategory": { + "type": "string" + }, + "severity": { + "type": "string", + "enum": ["CRITICAL", "HIGH", "MEDIUM", "LOW"] + }, + "ctrs_score": { + "type": "number", + "minimum": 0, + "maximum": 100, + "description": "Crypto Threat Risk Score: (L×0.25 + Ia×0.30 + R×0.20 + D×0.15 + RecD×0.10) × 20" + }, + "confidence": { + "type": "string", + "enum": ["HIGH", "MEDIUM", "LOW", "UNCONFIRMED"] + }, + "layer": { + "type": "string", + "enum": ["on_chain_protocol", "consumer_fraud", "ransomware_extortion", "physical", "supply_chain", "social_engineering"], + "description": "Loss layer for multi-source intelligence aggregation" + }, + "ooda_phase": { + "type": "string", + "enum": ["observe", "orient", "decide", "act", "all"], + "description": "Primary OODA phase where threat operates" + }, + "target_type": { + "type": "string", + "enum": ["individual", "protocol", "cex", "developer", "organization", "family", "elderly"] + }, + "target_profile": { + "type": "array", + "items": { + "type": "string" + }, + "examples": [["high_net_worth", "public_on_chain_identity", "poor_opsec"]] + }, + "attack_vectors": { + "type": "array", + "items": { + "type": "string" + } + }, + "financial_loss_usd": { + "type": "number", + "description": "Confirmed financial loss in USD; null if unknown" + }, + "financial_loss_estimated": { + "type": "boolean", + "description": "True if loss figure is estimated rather than confirmed" + }, + "loss_type": { + "type": "string", + "enum": [ + "coerced_transfer", "wallet_drain", "protocol_exploit", + "fraud_deposit", "ransomware_payment", "recovery_scam_payment", + "atm_transfer", "fee_payment_to_fraudster", "bridge_exploit" + ] + }, + "chain": { + "type": "array", + "items": { + "type": "string" + }, + "description": "Blockchain(s) involved", + "examples": [["ethereum", "solana", "bitcoin"]] + }, + "protocol_name": { + "type": "string", + "description": "For DeFi protocol exploits" + }, + "jurisdiction": { + "type": "string", + "description": "ISO 3166-1 alpha-2 country code or state code" + }, + "attribution": { + "type": "string", + "description": "Attributed threat actor or group — always verify with false_flag_probability" + }, + "false_flag_probability": { + "type": "number", + "minimum": 0, + "maximum": 1, + "description": "Probability official attribution is incorrect based on false flag checklist" + }, + "insider_vector": { + "type": "boolean", + "description": "True if insider access was the root enabler or primary hypothesis" + }, + "ai_assisted": { + "type": "boolean", + "description": "True if AI was used to enhance or execute the attack" + }, + "ai_attack_type": { + "type": "string", + "description": "Specific AI technique used if ai_assisted is true" + }, + "sovereignty_impact": { + "type": "string", + "enum": ["LOW", "MEDIUM", "HIGH", "CRITICAL"] + }, + "self_custody_relevant": { + "type": "boolean", + "description": "True if attack directly targets self-custodied assets" + }, + "regulatory_vector": { + "type": "boolean", + "description": "True if a regulatory mechanism was used as an attack vector" + }, + "fall_guy_pattern": { + "type": "boolean", + "description": "True if a visible actor appears to have been sacrificed to protect deeper operations" + }, + "capital_rotation_sig": { + "type": "boolean", + "description": "True if incident is part of a systemic capital extraction pattern (Rotator Effect)" + }, + "forced_labor_link": { + "type": "boolean", + "description": "True if operation is linked to forced labor scam compound infrastructure" + }, + "indicators": { + "type": "object", + "properties": { + "osint_exposure": {"type": "boolean"}, + "ens_linked_to_identity": {"type": "boolean"}, + "social_media_flex_post": {"type": "boolean"}, + "address_reuse": {"type": "boolean"}, + "unsolicited_contact": {"type": "boolean"}, + "urgency_pressure": {"type": "boolean"}, + "fee_demand_to_unlock": {"type": "boolean"}, + "profitable_test_withdrawal": {"type": "boolean"}, + "code_change_pre_exploit": {"type": "boolean"}, + "multisig_masquerade": {"type": "boolean"} + } + }, + "deterministic_defense": { + "type": "array", + "items": { + "type": "string", + "pattern": "^[A-Z]{2,4}-[0-9]{2}$" + }, + "description": "CryptoSHIELD control IDs that would have prevented this event", + "examples": [["WKS-02", "WKS-03", "OPS-05"]] + }, + "controls_triggered": { + "type": "array", + "items": {"type": "string"}, + "description": "Controls that were breached or absent in this incident" + }, + "mitre_attack": { + "type": "array", + "items": {"type": "string"}, + "description": "MITRE ATT&CK technique IDs" + }, + "ai_safe2_ref": { + "type": "string", + "description": "Reference to relevant AI SAFE² v3.0 control(s) for AI-related threats" + }, + "csf_cognitive_ref": { + "type": "string", + "description": "Reference to relevant CSF threat taxonomy entry for cognitive/social engineering threats" + }, + "defillama_hack_id": { + "type": "string", + "description": "Cross-reference to DefiLlama incident ID if applicable" + }, + "chainabuse_addresses": { + "type": "array", + "items": {"type": "string"}, + "description": "Reported attacker wallet addresses from Chainabuse" + }, + "dfpi_reported": {"type": "boolean"}, + "chainabuse_reported": {"type": "boolean"}, + "cryptoscamdb_listed": {"type": "boolean"}, + "ic3_reported": {"type": "boolean"}, + "scam_platform_url": { + "type": ["string", "null"], + "description": "For CS-FRD-* events: URL of fraudulent platform" + }, + "scam_fee_demand_type": { + "type": ["string", "null"], + "enum": ["tax", "aml_deposit", "account_upgrade", "certification", "green_channel", "risk_deposit", "other", null] + }, + "victim_demographic": { + "type": "object", + "properties": { + "age_group": { + "type": "string", + "enum": ["under_30", "30_60", "over_60", "unknown"] + }, + "technical_level": { + "type": "string", + "enum": ["novice", "intermediate", "advanced", "unknown"] + } + } + }, + "recovery_attempt_scam_followed": { + "type": "boolean", + "description": "True if victim was subsequently targeted by a recovery scam (CS-FRD-02)" + }, + "btc_atm_used": {"type": "boolean"}, + "ai_deepfake_used": {"type": "boolean"}, + "ai_document_forgery": {"type": "boolean"}, + "typosquat_domain": { + "type": ["string", "null"] + }, + "estimated_total_campaign_loss_usd": { + "type": ["number", "null"], + "description": "Total estimated losses across all victims of the same campaign" + }, + "tags": { + "type": "array", + "items": {"type": "string"} + }, + "references": { + "type": "array", + "items": {"type": "string"} + }, + "related_threats": { + "type": "array", + "items": { + "type": "string", + "pattern": "^CS-[A-Z]{2,4}-[0-9]{2}$" + } + }, + "notes": { + "type": "string", + "description": "Free-text analysis notes for the event" + } + }, + "examples": [ + { + "id": "CS-PHY-01-20250919-MN", + "timestamp": "2025-09-19T00:00:00Z", + "threat_id": "CS-PHY-01", + "category": "Physical", + "subcategory": "Kidnapping", + "severity": "CRITICAL", + "ctrs_score": 90, + "confidence": "HIGH", + "layer": "physical", + "ooda_phase": "act", + "target_type": "individual", + "target_profile": ["high_net_worth", "public_on_chain_identity", "poor_opsec"], + "attack_vectors": ["OSINT", "social_media_profiling", "physical_coercion"], + "financial_loss_usd": 8000000, + "financial_loss_estimated": false, + "loss_type": "coerced_transfer", + "jurisdiction": "US-MN", + "attribution": "unknown_organized_crime", + "false_flag_probability": 0.1, + "insider_vector": false, + "ai_assisted": false, + "sovereignty_impact": "CRITICAL", + "self_custody_relevant": true, + "indicators": { + "osint_exposure": true, + "ens_linked_to_identity": true, + "social_media_flex_post": true, + "address_reuse": true + }, + "deterministic_defense": ["OPS-01", "OPS-02", "OPS-05", "OPS-06", "OPS-10"], + "mitre_attack": ["T1591", "T1589"], + "tags": ["wrench_attack", "physical", "opsec_failure", "osint", "coercion"], + "references": ["DOJ-2025-MN-KID", "CSI-ISSUE-46"], + "ic3_reported": true + }, + { + "id": "CS-FRD-01-20250301-CA-001", + "timestamp": "2025-03-01T00:00:00Z", + "threat_id": "CS-FRD-01", + "category": "Financial Fraud", + "subcategory": "Pig Butchering", + "severity": "CRITICAL", + "ctrs_score": 92, + "confidence": "HIGH", + "layer": "consumer_fraud", + "ooda_phase": "observe", + "target_type": "individual", + "attack_vectors": ["dating_app", "whatsapp", "fake_trading_platform"], + "financial_loss_usd": 180000, + "financial_loss_estimated": false, + "loss_type": "fraud_deposit", + "jurisdiction": "US-CA", + "attribution": "organized_crime_scam_compound", + "false_flag_probability": 0.02, + "insider_vector": false, + "ai_assisted": true, + "ai_attack_type": "AI-generated relationship persona; AI-written messages", + "sovereignty_impact": "CRITICAL", + "self_custody_relevant": true, + "forced_labor_link": true, + "indicators": { + "unsolicited_contact": true, + "profitable_test_withdrawal": true, + "fee_demand_to_unlock": true + }, + "scam_platform_url": "stridefinex-exchange.com", + "scam_fee_demand_type": "tax", + "victim_demographic": { + "age_group": "30_60", + "technical_level": "novice" + }, + "deterministic_defense": ["CFD-01", "CFD-02", "CFD-03", "CFD-04", "SMS-13"], + "dfpi_reported": true, + "chainabuse_reported": true, + "ic3_reported": true, + "tags": ["pig_butchering", "romance_scam", "fake_platform", "trust_bait", "fee_escalation"], + "references": ["DFPI Scam Tracker CA-2025-PB-001"] + } + ] +} diff --git a/playbooks/consumer-fraud.md b/playbooks/consumer-fraud.md new file mode 100644 index 0000000..9c14eca --- /dev/null +++ b/playbooks/consumer-fraud.md @@ -0,0 +1,115 @@ +# Playbook: Consumer Fraud Defense (Pig Butchering / Investment Scam) + +**CSI CryptoSHIELD Framework v1.1** +Threats: CS-FRD-01, CS-FRD-02, CS-FRD-03, CS-FRD-04 | Domain: 09 (CFD) + +--- + +## Threat Profile + +Consumer fraud is the single largest crypto threat by dollar volume: $7.2 billion in U.S. pig butchering losses in 2025 alone. The attack requires no technical capability: only psychology, time investment, and a fake platform. AI has eliminated the traditional red flags (poor grammar, implausible offers) and extended the trust-building phase indefinitely. + +The FBI's Operation Level Up found 78% of active victims had no idea they were being scammed. + +--- + +## The Kill Chain (Pig Butchering) + +``` +Phase 1: CONTACT + Random message (WhatsApp, dating app, LinkedIn) + "Wrong number" / investment opportunity / "old friend" + +Phase 2: TRUST BUILDING (weeks to months) + Relationship develops; investment topic introduced + "My uncle/cousin/mentor manages a profitable fund" + +Phase 3: BAIT + Small investment; small profitable withdrawal (TRUST TRAP) + "See? It works!" + +Phase 4: ESCALATION + Pressure to invest more; FOMO manufacturing + "This window closes tomorrow" + +Phase 5: LOCK (Withdrawal Block) + First withdrawal attempt fails + "You owe X% tax to unlock" / "AML verification required" + +Phase 6: FEE EXTRACTION LOOP + Each fee paid generates new fee demand + Multiple rounds; total fees may exceed original investment + +Phase 7: EXIT + Platform disappears; all contact ceases +``` + +--- + +## Red Line Indicators (Immediate Stop Conditions) + +Any ONE of these is sufficient to classify the situation as fraud and stop all engagement: + +| Indicator | Meaning | +|---|---| +| Any platform blocking withdrawals pending fee payment | Confirmed fraud | +| "Tax payment" required to release funds | Confirmed fraud | +| "AML deposit" or "risk deposit" required | Confirmed fraud | +| "Account certification" or "upgrade fee" | Confirmed fraud | +| Support exists only on Telegram/WhatsApp | Fraud signal | +| Platform not findable via independent web search | Fraud signal | +| Cannot verify custody of your funds on-chain | Fraud signal | +| Contact who introduced the platform becomes unavailable | Fraud signal | +| "Recovery service" offers to get your money back for a fee | Secondary fraud (CS-FRD-02) | + +**The absolute rule:** No legitimate platform withholds withdrawals pending external fee payment. This is not a feature. It is the mechanism of the fraud. + +--- + +## OODA Response: Active Engagement Suspected + +### OBSERVE +- When did this contact originate? +- What is the relationship trajectory? +- When and how was the investment platform introduced? +- Can you independently verify this platform exists? (DFPI, CryptoScamDB, Chainabuse check) + +### ORIENT +- Apply the Fee Demand Alert Protocol (SMS-14): has any withdrawal been blocked with a fee demand? +- Apply the 10-Day Rule (SMS-13): have you deposited more than $1,000 within 10 days of first learning about this platform? +- Apply the AI Persona Detection test (CFD-08): can you verify the identity of this contact through out-of-band means? +- Pattern match: Does this contact's behavior match the kill chain phases above? + +### DECIDE +- **If any Red Line Indicator above is present:** Stop immediately. Do not pay additional fees. Do not send additional funds. +- **If trust-building phase only:** Apply 10-day rule; do independent verification before any deposit +- **If post-deposit, no withdrawal block yet:** Test with small withdrawal; if blocked: confirmed fraud + +### ACT +- Stop all fund transfers immediately +- Document: screenshots of all conversations, platform name and URL, wallet addresses used, all transaction receipts +- Report to: FBI IC3 (ic3.gov), Chainabuse, DFPI (California residents), CFTC (futures/derivatives) +- Do NOT engage any recovery service that contacts you: secondary fraud (CS-FRD-02) +- If funds moved to CEX: contact CEX support with transaction hashes immediately: freezes possible within hours of reporting + +--- + +## If Already Victimized + +**Do:** +- Report to FBI IC3 (most important for statistical tracking and investigations) +- Contact Chainabuse with all wallet addresses used by the platform +- Contact DFPI (California): they publish reports that help identify scam platforms +- Contact CFTC if any derivatives or leveraged products were involved +- Engage Chainalysis or TRM Labs if losses exceed $25,000 (professional tracing possible) + +**Do Not:** +- Pay any additional fees to anyone for any reason +- Engage any "crypto recovery specialist" who contacts you after the loss (this is CS-FRD-02) +- Share this experience only with law enforcement: social media posts can attract secondary scammers + +**Prognosis:** Recovery of funds is rare but not impossible, particularly if CEX landing points are identified quickly. The FBI's Operation Level Up successfully stopped $285 million in pig butchering losses in 2024 by acting on early intervention. Reporting matters even when individual recovery is unlikely. + +--- + +*Playbook: Consumer Fraud Defense | CSI CryptoSHIELD v1.1 | Open-Source* diff --git a/playbooks/physical-coercion.md b/playbooks/physical-coercion.md new file mode 100644 index 0000000..647d09a --- /dev/null +++ b/playbooks/physical-coercion.md @@ -0,0 +1,80 @@ +# Playbook: Physical Coercion Response + +**CSI CryptoSHIELD Framework v1.1** +Threats: CS-PHY-01, CS-PHY-02 | Domain: 03 (OPS) + +--- + +## Threat Profile + +Physical coercion against crypto holders ranges from home invasion to organized kidnapping. The attacker's goal: force real-time asset transfer while the victim is under physical duress. Unlike digital attacks, there is no "undo." Response must be pre-planned: not improvised under stress. + +--- + +## Pre-Incident Requirements (Must Be Complete Before Incident) + +| Requirement | Status Check | +|---|---| +| Decoy wallet funded with believable balance | [ ] Complete | +| Primary holdings in 72h+ timelock | [ ] Complete | +| Multisig with geographically separated co-signer | [ ] Complete | +| Trusted contact established with check-in protocol | [ ] Complete | +| Duress code word/signal agreed with trusted contact | [ ] Complete | +| Family briefed on basic OPSEC | [ ] Complete | +| Law enforcement contact info saved | [ ] Complete | + +If any items above are incomplete: stop reading playbooks and go complete those controls first. This playbook is only useful if the pre-conditions exist. + +--- + +## OODA Response: Active Coercion Event + +### OBSERVE +- Assess: Are weapons present? Physical harm in progress? +- Assess: What do they want? Transfer? Seed phrase? Device access? +- Assess: Where are family members? +- Assess: Is there communication possible with trusted contact? + +### ORIENT +- **Comply to preserve life.** Assets can be replaced. Do not escalate. +- **Route to decoy wallet.** Present the decoy wallet (OPS-06) as your "main" holdings. +- **Use delay tactics:** + - "The bulk is on a hardware wallet that requires 24 hours to warm up after long storage" + - "Most of it is in a multisig: I don't have the other signers' keys" + - "There's a 72-hour timelock on large transactions: the system won't let me send more now" +- **Activate duress signal** if any pre-agreed method is accessible (smart home device, phone with dead-man switch) + +### DECIDE +- Transfer from decoy wallet only: maximum loss predetermined +- If unable to activate duress signal: cooperate with attacker demands on decoy wallet while preserving information on true holdings architecture +- Do NOT provide seed phrase or access to main holdings device under any circumstances + +### ACT +- Execute transfer from decoy wallet +- Memorize or note any identifying details: voices, physical descriptions, vehicle, accent +- Activate duress signal at first safe opportunity + +--- + +## Post-Incident Response + +**Immediate (0-60 minutes post-escape):** +1. Contact law enforcement: 911 (immediate); FBI field office (kidnapping/organized crime) +2. Contact trusted contact: activate emergency protocol +3. Move remaining assets from any potentially exposed wallet to pre-generated cold wallet +4. Revoke all token approvals from any device that was accessed + +**Evidence (0-24 hours):** +1. Write down all details of attacker identification before memory fades +2. Record all on-chain transactions made under duress (blockchain forensics evidence) +3. Save all communications +4. Do NOT post on social media: coordinate with law enforcement first + +**Recovery:** +- Engage FBI Crypto Unit for investigation support +- Contact Chainalysis or TRM Labs for fund tracing if losses exceed $10,000 +- If crypto exchange received coerced funds: contact exchange support immediately with transaction hashes: freezes possible within hours + +--- + +*Playbook: Physical Coercion | CSI CryptoSHIELD v1.1 | Open-Source* diff --git a/playbooks/wallet-compromise.md b/playbooks/wallet-compromise.md new file mode 100644 index 0000000..777d951 --- /dev/null +++ b/playbooks/wallet-compromise.md @@ -0,0 +1,121 @@ +# Playbook: Wallet Compromise Response + +**CSI CryptoSHIELD Framework v1.1** +Threats: CS-WAL-01 through CS-WAL-05, CS-MAL-01, CS-MAL-02 | Domains: 01 (WKS), 02 (EDD), 05 (OCM) + +--- + +## Threat Profile + +Wallet compromise is the most common high-impact crypto attack: seed phrase theft, malicious signature grants, clipboard hijacking, address poisoning, and DNS hijacks collectively account for the majority of individual holder losses. The attack surface ranges from the physical (hardware wallet recovery phrase) to the digital (browser-based malicious approval). + +**68% of DeFi losses involve exploitation of pre-existing token approvals**: not active transaction attacks. Many victims don't know they've been compromised until the drain occurs. + +--- + +## Attack Type Identification + +| Attack Type | Indicator | Threat ID | +|---|---|---| +| Seed phrase exposure | Funds drained from multiple wallets; HD wallet entirely emptied | CS-WAL-01 | +| Address poisoning | Funds sent to slightly-wrong address; poisoned address in TX history | CS-WAL-02 | +| DNS/frontend hijack | Wallet connection request on known protocol site; unexpected contract address | CS-WAL-03 | +| Malicious signature | Approval granted unknowingly; specific token/amount drained | CS-WAL-04 | +| Clipboard hijacking | Pasted address differs from copied address | CS-MAL-01 | +| InfoStealer | Funds drained; device shows unusual network activity | CS-MAL-02 | + +--- + +## OODA Response: Wallet Compromise Suspected + +### OBSERVE +- Is there an unexpected outgoing transaction in your wallet history? +- Did you receive an unexpected alert (OCM-02)? +- Did the amount sent go to an address you did not intend? +- Are any token approvals shown in revoke.cash that you did not knowingly grant? + +### ORIENT +- **Speed matters.** Every minute of delay allows the attacker to move funds further from recovery. +- Do NOT use the potentially compromised device for response: use a second, clean device. +- Identify: What is the likely attack type? (Table above) +- Identify: What wallets/devices might share exposure? (If seed phrase: all wallets from that seed) + +### DECIDE + +**If funds are still in compromised wallet (not yet drained):** +- Immediate priority: move remaining funds to a pre-generated cold wallet address +- This requires having a pre-generated cold wallet address ready: if you don't: generate on a clean device first + +**If funds are draining or have been drained:** +- Accept the loss from compromised wallet +- Contain: ensure remaining funds in unaffected wallets are isolated from compromised device/seed + +**For malicious approval (not yet drained):** +- Immediate: revoke the approval at revoke.cash from a clean device +- If approval involved a front-running risk: use private RPC (Flashbots Protect) for the revoke transaction + +### ACT + +**Step 1: Emergency Containment (0-5 minutes)** +``` +From a clean device: +1. Navigate to revoke.cash +2. Connect the compromised wallet (read-only, watch mode if available) +3. Identify and revoke ALL active token approvals +4. If seed compromise suspected: generate new wallet on clean device; do NOT reuse any address from compromised seed +``` + +**Step 2: Asset Migration (5-30 minutes)** +``` +1. Send all remaining funds from compromised wallet to new clean wallet address +2. Verify recipient address on hardware wallet screen (independent device if possible) +3. Confirm transaction via OCM-02 alert +4. Once confirmed: treat compromised wallet/seed as burned; never use again +``` + +**Step 3: Device Isolation** +``` +1. Disconnect compromised device from all networks +2. Do NOT use it for any crypto operations again until forensic wipe +3. For InfoStealer: full OS reinstall required; do not trust partial cleanup +``` + +**Step 4: Reporting and Forensics** +``` +1. Record all transaction hashes related to the attack +2. Report to FBI IC3 (ic3.gov) +3. Report attacker wallet address to Chainabuse +4. If losses >$10,000: contact TRM Labs or Chainalysis for tracing +5. If exchange received stolen funds: contact exchange support immediately +``` + +--- + +## Address Poisoning: Special Response + +If you discover you sent funds to a poisoned address (slightly-wrong address in TX history): + +1. Verify the actual intended recipient's address via out-of-band communication +2. Confirm the funds are NOT at your intended destination +3. Record the poisoned address and report to Chainabuse +4. If destination was a CEX deposit address: contact CEX support: possible recovery within hours +5. If on-chain to an EOA: contact ZachXBT or blockchain forensics firms; public exposure can sometimes create pressure for return (rare) + +--- + +## Post-Incident Hardening + +After any wallet compromise, these controls must be implemented before resuming operations: + +| Control | Action | +|---|---| +| WKS-01 | New hardware wallet for primary storage (not the same device) | +| WKS-04 | New seed phrase; destroy and verify destruction of old backup | +| EDD-01 | Reinstall OS or use new dedicated device | +| EDD-04 | Establish clipboard verification habit | +| OCM-03 | Establish token approval monitoring for new wallet | +| SMS-05 | Full URL verification protocol refresh | + +--- + +*Playbook: Wallet Compromise | CSI CryptoSHIELD v1.1 | Open-Source* diff --git a/research/001_wrench_attack_epidemic.md b/research/001_wrench_attack_epidemic.md new file mode 100644 index 0000000..73048e6 --- /dev/null +++ b/research/001_wrench_attack_epidemic.md @@ -0,0 +1,145 @@ +# Research Note 001: The Wrench Attack Epidemic + +**Classification:** Open-Source Intelligence | CSI CryptoSHIELD Framework +**Date:** May 2026 | **Version:** 1.1 +**Threat IDs:** CS-PHY-01, CS-PHY-02 +**Domain:** 03: OPSEC and Physical Security + +--- + +## Problem + +The dominant assumption in crypto security is that the threat is digital. Protect your keys, secure your device, use hardware wallets. This framing treats the human body as outside the security model. + +That assumption cost $40.9 million in 2025 and left at least 72 people in documented physical danger. + +--- + +## Realization + +Physical coercion: called "wrench attacks" after the expression "a $5 wrench is cheaper than cryptography": is now the fastest-growing attack vector in crypto by incident volume. CertiK's Skynet Wrench Attacks Report (February 2026) documented: + +- **72 verified incidents** in 2025: +75% year-over-year from 41 in 2024 +- **$40.9 million** in total verified losses +- **Physical assault** up 250% year-over-year +- **Kidnapping** remained the most common tactic (25+ incidents) +- **Europe** became the most dangerous region globally: 40%+ of incidents, France alone accounting for 19 + +The attack trajectory is not linear. It tracks crypto market cap appreciation. As BTC and ETH prices rise through 2026, the expected incident rate based on 2024-2025 trend data is 100+ incidents in 2026. + +--- + +## The Attack Methodology + +### Phase 1: OSINT and Target Selection + +Attackers do not pick targets randomly. They run systematic OSINT against public data sources: + +| Data Source | What It Reveals | +|---|---| +| X (Twitter) / LinkedIn | Crypto identity, employer, investment history, gains | +| ENS names | On-chain wallet address linked to real identity | +| Blockchain explorers | Wallet balance, transaction history, approximate wealth | +| Conference speaker lists | Identity, expertise level, market presence | +| Photo metadata (EXIF) | Location, time, device | +| Property records | Home address, neighborhood, wealth indicators | +| Court records | Divorce, business disputes exposing asset values | + +**CSI Case Analysis:** The September 2025 Minnesota kidnapping ($8M coerced transfer) followed the exact OSINT-to-physical pattern. Attackers identified the victim through public blockchain analytics tools that linked on-chain wallet activity to a professional identity, then cross-referenced with public records to establish a home address. The "attack" required no technical sophistication: only Google, Etherscan, and a public records search. + +### Phase 2: Surveillance + +Between target selection and the physical event, attackers typically conduct: +- Physical surveillance of the target's home and workplace +- Digital reconnaissance (monitoring social posts for location signals) +- Network mapping (who else is in the target's circle; who might know access credentials) + +Duration: hours to weeks depending on operational sophistication. + +### Phase 3: Coercion Event + +**Kidnapping (25 incidents in 2025):** Target is abducted and held until crypto transfers are completed. Sophisticated operations use geographic co-signers to increase coercion pressure ("we know where your family lives"). The Ledger co-founder (David Balland, France, January 2025) had his finger severed: attackers demanded €10 million; police intervention prevented full payment. + +**Home Invasion:** Target is physically confronted at residence and forced to transfer at gunpoint or under threat. Particularly effective against targets with family members present. + +**Street Robbery:** Less common for large amounts but increasingly documented; targets with visible crypto hardware (hardware wallets, branded merchandise) in public. + +--- + +## Key Findings + +### Finding 1: Crypto Wealth Creates Permanent Target Status + +Unlike cash, crypto wealth is partially transparent on-chain and difficult to obfuscate retroactively. A wallet that received a $1M NFT sale in 2022 remains visible to any analyst today. Target status does not expire with the bull market: it persists indefinitely as long as the on-chain history is traceable to an identity. + +### Finding 2: Technical Security Is Insufficient Without Physical OPSEC + +No hardware wallet design prevents coercion. No multisig scheme prevents coercion in isolation: unless the co-signers are genuinely geographically separated and the 72-hour timelock architecture makes immediate transfer physically impossible. This is the only technical control that provides physical security: architecture that makes real-time coerced transfer impossible, not just difficult. + +### Finding 3: Social Media Oversharing Is the Root Cause + +In the majority of documented high-value coercion attacks, the victim's identity was linked to crypto wealth through voluntary public disclosure: portfolio screenshots, gains flexing, luxury purchases described online, conference talks disclosing involvement in large protocols, or ENS names tied to real identities. + +This is a preventable root cause. OPS-01 and OPS-02 are not optional controls for high-net-worth crypto holders: they are foundational to physical security. + +### Finding 4: Europe Is Ground Zero, but the Pattern Is Globalizing + +France's 19 incidents in 2025 represent a concentrated threat environment, but the U.S. has seen rapid escalation. The September 2025 Minnesota case followed the European playbook almost exactly. The differential: U.S. law enforcement response and Second Amendment deterrence factors may create marginal disincentive for physical confrontation tactics, but they do not eliminate the threat. + +--- + +## CTRS Score Analysis: CS-PHY-01 + +| Component | Score (0-5) | Rationale | +|---|---|---| +| Likelihood (×0.25) | 3 | High and rising; concentrated in high-wealth crypto holders | +| Impact on Sovereignty (×0.30) | 5 | Total loss possible; physical harm irreversible | +| Scale (×0.20) | 3 | High for targeted individuals; not mass-scale | +| Detection Difficulty (×0.15) | 4 | Surveillance phase is nearly undetectable | +| Recovery Difficulty (×0.10) | 5 | Coerced transfers irreversible; physical harm permanent | + +**CTRS Score: 18.4 / 20 → CRITICAL** + +--- + +## Defensive Architecture + +The physical security stack derived from this research: + +| Control | CTRS Reduction | Mechanism | +|---|---|---| +| OPS-01 (Zero disclosure) | Eliminates OSINT target identification | No public signal of wealth | +| OPS-02 (Identity decoupling) | Eliminates on-chain-to-identity linkage | Prevents OSINT completion | +| WKS-02 (Multisig, geographic) | Defeats real-time coercion | Transfer requires co-signer in another city | +| WKS-03 (72h timelock) | Defeats real-time coercion | Transfer physically impossible for 72 hours | +| OPS-06 (Decoy wallet) | Limits coercion losses | Attacker receives small sacrifice; bulk is inaccessible | +| OPS-10 (Duress protocol) | Enables rapid law enforcement response | Trusted contact activates when check-in fails | + +The most powerful control combination: **WKS-02 + WKS-03 + OPS-06**. An attacker who gains physical access to a holder using this architecture cannot execute a transfer in real time. They must hold the victim for 72+ hours while a co-signer in a different location is also compromised. This is operationally difficult and raises the risk level for the attacker substantially: it is not impossible, but it is a significant deterrent. + +--- + +## High-Profile Case Reference + +| Incident | Date | Location | Amount | Method | Key Lesson | +|---|---|---|---|---|---| +| Ledger Co-Founder | Jan 2025 | France | €10M demanded | Kidnapping, mutilation | High-profile public identity = target | +| Minnesota Kidnapping | Sep 2025 | USA | $8M | Kidnapping, gunpoint | On-chain to physical address OSINT chain | +| Paris Crypto Father | Jan 2025 | France | €5M demanded | Daughter kidnapped | Family = soft target | +| Barcelona Gang | 2025 | Spain | Multiple millions | Organized kidnapping ring | Professional criminal organization targeting crypto | +| Multiple UK Incidents | 2025 | UK | Varies | Street robbery to kidnapping | UK top-5 for incident count | + +--- + +## References + +- CertiK Skynet Wrench Attacks Report, February 2026 +- CSI Weekly Issue 43 (Crypto War Zone) +- CSI Weekly Issue 46 (Minnesota Case Analysis) +- CSI Article: "Kidnappers in U.S. Grab $8M: Biggest Threat to Crypto Holders in the Real World" +- FBI IC3 2025 Annual Report (physical crime overlay on crypto fraud data) + +--- + +*Research Note 001 | CSI CryptoSHIELD Framework v1.1* +*Cyber Strategy Institute | May 2026 | Open-Source* diff --git a/research/002_rotator_effect.md b/research/002_rotator_effect.md new file mode 100644 index 0000000..3eb0dc7 --- /dev/null +++ b/research/002_rotator_effect.md @@ -0,0 +1,133 @@ +# Research Note 002: The Rotator Effect: Capital Extraction Architecture + +**Cyber Strategy Institute | CryptoSHIELD Research Series** +**Classification:** Open Source | **Version:** 1.1 | **Date:** May 2026 + +--- + +## Executive Assessment + +The Rotator Effect is the term CSI applied in 2021 foundational research to describe a multi-vector, coordinated playbook for extracting liquidity from decentralized markets into centralized elite control. It is not a single tactic. It is an architecture: a system of interlocking mechanisms that collectively move capital from distributed holders into the hands of coordinating parties. + +Understanding the Rotator Effect is essential because: (a) it explains incidents that look random in isolation but form a coherent pattern; (b) it identifies the structural enablers that must be attacked to disrupt the playbook; and (c) it provides the orientation layer of the OODA loop for any crypto market participant. + +--- + +## The Five Core Mechanisms + +### Mechanism 1: FUD as a Weapon + +**Pattern:** Manufactured regulatory fear is deployed against a major exchange or asset to shift user liquidity toward controlled alternatives. + +**The FTX Playbook:** +1. FUD targeting Binance's regulatory exposure circulates on "Crypto Twitter" from coordinated accounts +2. FTT (FTX's native token) is positioned as the "safe, U.S.-aligned" alternative +3. Retail liquidity migrates toward FTX +4. FTX subsequently collapses, with the implosion timed to consolidate the fallout +5. The regulatory aftermath creates narrative cover for CBDC and centralized "regulated" alternatives + +**Detection signal:** Simultaneous FUD across multiple competing influencer channels about the same target, at the same time, is Rotator coordination. Organic FUD has friction and disagreement; coordinated FUD has suspicious consensus. + +### Mechanism 2: Tokenomics Weaponization + +**Pattern:** Projects designed with VC/insider distributions of 50-70%+ of total supply, minimal public float, and cliff-based vesting structures that create engineered pump windows. + +**The mechanics:** +- Low float = easy price appreciation with small capital +- Visual price appreciation attracts retail FOMO +- Influencer narrative coordinates the "buy signal" +- Insider vesting cliffs time the exit +- Retail provides the exit liquidity; insiders provide the exit + +**Identification checklist:** +``` +□ Is total supply known? Are all wallet allocations public? +□ What % is held by VC/insiders at TGE? +□ When do the largest unlock cliffs hit? +□ Is the public float <15% at launch? +□ Is there a simultaneous "listing on [CEX]" announcement and price action? +3+ YES answers → Tokenomics weaponization risk HIGH +``` + +### Mechanism 3: MEV and Sandwich Operations + +**Pattern:** MEV bots systematically front-run and sandwich retail trades, transferring value from ordinary market participants to sophisticated operators at scale. Now increasingly AI-automated. + +**Scale:** In active market conditions, MEV extraction from retail users can reach $10M-50M per day on Ethereum alone. The mechanism is structural, not incidental. + +**CSI position:** MEV is legal but predatory. It is the crypto equivalent of payment for order flow: retail liquidity is being silently extracted by infrastructure operators. The Rotator Effect uses MEV as a passive extraction layer running beneath more visible manipulation. + +### Mechanism 4: Coordinated Influence Operations + +**Pattern:** Synchronized narrative deployment across "Crypto Twitter" and YouTube: influencers with no apparent coordination producing identical talking points within 24-48 hours. + +**Detection:** +- Track influencer content timing and direction correlation +- Identify "coordinated pumps" by comparing timestamps of bullish content from independent influencers on the same asset +- Apply the Rotator Effect pattern to influencer portfolio disclosures: who holds what, and when does their content align with their positions? + +For deep analysis of AI-enhanced influence operations and cognitive manipulation vectors, see: [CSF T-CT-003 (Algorithmic Amplification)](https://github.com/CyberStrategyInstitute/cognitive-sovereignty) + +### Mechanism 5: The Fall-Guy Pattern + +**Pattern:** A visible, high-profile actor is sacrificed to absorb public and regulatory attention while the broader capital extraction operation continues. The fall guy may be willing (incentivized), complicit (trapped), or genuinely unaware of the full scope. + +**The SBF / FTX case:** +- Sam Bankman-Fried's public prosecution created the appearance of accountability +- The regulatory response focused on FTX-specific behavior rather than the systemic tokenomics weaponization and FUD coordination that had been ongoing for years +- Capital extraction patterns that predated FTX continued after FTX's collapse through successor projects + +**Pattern indicators:** +- Prosecution or public exposure benefits specific other market participants +- The imploded entity had been receiving unusual amounts of positive press that paused immediately before collapse +- Regulatory response is specific and does not address structural issues +- Settlement timeline aligns with market events benefiting identified parties + +--- + +## The Rotator Effect in 2025-2026: AI Acceleration + +AI has materially accelerated the Rotator Effect in three ways: + +1. **Influence operation speed:** AI-generated content enables coordinated narrative deployment at 10-100x the previous speed with lower cost and higher polish +2. **MEV automation:** AI-powered MEV bots now operate 24/7 with no human monitoring requirement +3. **Pig butchering at scale:** The industrialization of pig butchering (CS-FRD-01) through AI-generated personas is fundamentally the Rotator Effect applied to individual retail victims: systematic capital extraction using social engineering + +--- + +## Defensive Application + +**Investor checklist before any position:** +1. Run tokenomics weaponization check (mechanism 2 checklist above) +2. Identify all influencers with declared positions on the asset +3. Check coordinated narrative timing across influencer content +4. Apply false flag filter to any negative news catalysts +5. Track who would benefit most from current price action + +**Protocol team checklist:** +- Document all insider/VC allocations publicly in governance +- Deploy on-chain vesting contracts with publicly visible cliff schedules +- Disclose any coordinated market-making arrangements publicly +- Establish public treasury transparency dashboards + +--- + +## Metadata + +```json +{ + "research_id": "002", + "title": "The Rotator Effect: Capital Extraction Architecture", + "date": "2026-05-13", + "version": "1.1", + "threat_ids_covered": ["CS-MKT-01", "CS-MKT-02", "CS-MKT-03"], + "tags": ["rotator_effect", "capital_extraction", "fall_guy", "tokenomics", "mev", "influence_operation"], + "controls_implicated": ["SMS-10", "CFD-09", "OCM-04", "OCM-05"], + "cognitive_threat_refs": ["CSF T-CT-003", "CSF T-CT-004", "CSF T-CT-005"] +} +``` + +--- + +*Cyber Strategy Institute | CryptoSHIELD Research Series* +*Related: [research/007_false_flag_forensics.md](007_false_flag_forensics.md)* diff --git a/research/003_dprk_attribution_analysis.md b/research/003_dprk_attribution_analysis.md new file mode 100644 index 0000000..ac1c127 --- /dev/null +++ b/research/003_dprk_attribution_analysis.md @@ -0,0 +1,158 @@ +# Research Note 003: DPRK Attribution Analysis: Nuance Over Narrative + +**Cyber Strategy Institute | CryptoSHIELD Research Series** +**Classification:** Open Source | **Version:** 1.1 | **Date:** May 2026 + +--- + +## Executive Assessment + +DPRK-linked actors (TraderTraitor/Lazarus Group) are real, active, and have unquestionably stolen billions. That is not in dispute. What is in dispute: and what this research note documents: is the systematic over-application of the DPRK attribution label to incidents where: + +1. The primary access vector was insider social engineering, not sophisticated exploitation +2. The DPRK label conveniently protects negligent internal security practices from liability +3. On-chain forensics point to admin key failures inconsistent with external state-actor entry +4. A sacrificial fall-guy narrative structure is being applied to deflect accountability + +**CSI's position:** Every major "DPRK hack" should be examined through the insider-threat lens first. Where admin key access was possible, it must be exhausted as the primary hypothesis before state-actor attribution is accepted. + +--- + +## The Wagemole Playbook: DPRK's Primary Attack Vector + +The most consistent pattern across confirmed DPRK operations in 2024-2026 is not zero-day exploitation. It is identity fabrication and legitimate employment. + +**The Wagemole Pattern (documented):** +1. DPRK operative fabricates a complete Western professional identity +2. Creates GitHub account with manufactured contribution history (months to years) +3. Creates LinkedIn with plausible employment history and AI-generated profile photo +4. Applies to crypto companies as developer, contractor, or "strategic partner" +5. Passes technical interviews (genuine technical capability; DPRK trains developers at state level) +6. Gains legitimate access to production code, signing keys, admin functions +7. Deploys access weeks to months after hiring to avoid correlation +8. Exfiltrates or exploits while on payroll + +**Why this matters for attribution:** The Wagemole pattern is fundamentally an insider threat. Once hired, DPRK operatives have exactly the same access patterns as a malicious internal developer. Attributing the subsequent exploit to "DPRK state hackers" rather than "insider key compromise via identity fraud in hiring" creates incorrect security narratives that do not produce the right control responses. + +**Confirmed Wagemole operations (publicly documented):** +- Drift Protocol (April 2026): 6-month embedded fake employee; $285M outcome; social engineering, not smart contract exploit +- KelpDAO (March 2026): LayerZero bridge design flaw exploited; infiltration preceded technical access +- Multiple mid-2025 incidents: Correlation of Korean IP addresses with VPN-masked recruitment patterns + +--- + +## Case Study: LNDFi ($1.18M, May 2025): The Insider vs. DPRK Question + +**Official attribution at time of incident:** DPRK/TraderTraitor involvement suggested + +**CSI multi-pass analysis findings:** + +The exploit mechanism was a five-word code change deployed 41 days before exploit day. The change granted any account with "Pool Admin" role the ability to drain funds. The change was contained in a commit to a modified Aave fork and was not flagged during code review. + +**Insider-first hypothesis indicators:** +- Code change required repository write access (internal developer or admin) +- Change was syntax-compatible with the codebase: not an injection from external source +- 41-day delay between deployment and exploit matches insider operational security protocol +- The change was embedded within a larger legitimate-looking diff: consistent with insider knowledge of what reviewers focus on +- External attacker would have required both code access AND advance knowledge of when to trigger + +**False flag probability assessment:** 0.65 (HIGH) + +**CSI conclusion:** LNDFi represents a pattern where "DPRK" attribution may have served primarily to frame the incident as an external sophisticated attack rather than an internal security failure. The distinction matters enormously for liability, insurance, and regulatory disclosure requirements. + +--- + +## Case Study: Radiant Capital ($50M, October 2024): The Multisig Masquerade + +**Official attribution:** DPRK-linked actors (malware delivery via Telegram) + +**The incident mechanics:** +- Malware delivered to three developers' devices via a compromised Telegram message (social engineering) +- Malware modified Safe{Wallet} transaction display while preserving correct UI appearance +- Developers signed malicious transactions believing they were approving legitimate protocol upgrades +- Exploit proceeded despite Tenderly simulation and manual review: because the malware was intercepting at the signing layer, not the simulation layer + +**Where the attribution is technically accurate but operationally misleading:** +The initial malware delivery was almost certainly DPRK-linked: it matches the Telegram social engineering profile used in multiple confirmed DPRK operations. However, the narrative that emerges: "sophisticated state hackers defeated our multi-sig": obscures the following: + +1. The attack was ultimately enabled by developers signing transactions without independent device verification (WKS-05 absent) +2. Hardware wallet signing on an independent device not connected to the compromised machine would have detected the discrepancy +3. The 72-hour timelock (WKS-03) would have provided a detection window +4. Geographic diversity of signers was insufficient to prevent a single social engineering campaign targeting all three simultaneously + +**The correct security narrative:** Radiant was defeated by a device compromise combined with insufficient signing hygiene, not by DPRK technical capability exceeding their security architecture. The fix is deterministic endpoint defense and independent signing device verification, not "better malware detection." + +--- + +## The Chinese Broker Intermediary Factor + +Confirmed by Chainalysis and TRM Labs: DPRK-stolen funds are laundered primarily through Chinese broker intermediaries, not directly through North Korean infrastructure. + +**Why this creates attribution complexity:** +- Funds appear to flow through entities that are not technically DPRK infrastructure +- Chinese nationals acting as intermediaries may or may not have direct knowledge of fund origin +- Capital exit paths through OTC desks, USDT on Tron, and P2P markets are used by both DPRK and domestic criminal organizations +- This creates plausible cover for domestic actors to have funds laundered through the same infrastructure and attributed to DPRK + +**CSI assessment:** The Chinese broker intermediary layer means on-chain laundering analysis alone cannot confirm DPRK attribution. It can confirm methodology consistency with DPRK patterns, which is meaningfully different. Intelligence-layer attribution (network analysis, HUMINT, signals) is required to confirm. + +--- + +## The 2026 DPRK Threat Picture + +**Confirmed 2026 activity (through April):** +- 18 confirmed thefts +- $300M+ stolen +- Primary targets: bridges and protocols with single-verifier designs +- KelpDAO ($292M): LayerZero bridge single-verifier; likely preceded by some form of social engineering access +- Laundering through THORChain and Chinese broker intermediaries remains primary exit + +**Hiring exposure assessment:** +Organizations should audit all external relationships: recruiters, "strategic investors," DevConnect contacts, GitHub contributors with recent account creation: against the Wagemole identity-fabrication indicator set: + +| Indicator | Flag Level | +|-----------|-----------| +| GitHub account created within 12 months with high activity | MEDIUM | +| No verifiable in-person or video history (face not matching headshot) | HIGH | +| Employment history at companies that cannot be independently verified | HIGH | +| Technical fluency inconsistent with claimed experience timeline | HIGH | +| Korean IP addresses in access logs (VPN masked but time-zone consistent) | HIGH | +| Excessive interest in signing key management during onboarding | CRITICAL | +| Request for remote signing capability before trust is established | CRITICAL | +| Communications primarily through Telegram vs. email | MEDIUM | + +--- + +## Recommendations for Incident Responders + +When a crypto protocol incident is attributed to DPRK, apply the False Flag checklist from the [OODA Playbook](../OODA-PLAYBOOK.md) before accepting the attribution. Specifically: + +1. **Demand on-chain forensic evidence** from an independent firm (Chainalysis or TRM Labs) before any public attribution statement +2. **Conduct an internal access audit:** Who had admin key access? Was any code change deployed in the last 90 days? Are there any Wagemole indicators in recent hires? +3. **Examine the liability differential:** If the incident is reclassified as an insider threat or operational security failure, what changes for insurance claims, regulatory disclosure, and governance accountability? High differential = higher false flag probability. +4. **Do not issue public attribution statements within 48 hours.** No legitimate forensic analysis can confirm DPRK attribution in that window. + +--- + +## Metadata + +```json +{ + "research_id": "003", + "title": "DPRK Attribution: Nuance Over Narrative", + "date": "2026-05-13", + "version": "1.1", + "threat_ids_covered": ["CS-INS-03", "CS-INS-01", "CS-DFI-01", "CS-DFI-03"], + "false_flag_cases_analyzed": ["LNDFi", "Radiant Capital", "Drift Protocol", "BrincFi"], + "confidence": "HIGH", + "adversarial_reproduction_test": "Independent analysts with access to same on-chain data and public incident reports should arrive at comparable false_flag_probability scores (within ±0.15)", + "related_notes": ["001", "002", "007"], + "controls_implicated": ["WKS-02", "WKS-03", "WKS-05", "SCD-05", "SCD-10", "EDD-01", "EDD-02"] +} +``` + +--- + +*Cyber Strategy Institute | CryptoSHIELD Research Series* +*Cross-reference: [taxonomy/registry.json](../taxonomy/registry.json) entries CS-INS-01, CS-INS-03* +*Cross-reference: [AI SAFE² v3.0](https://github.com/CyberStrategyInstitute/ai-safe2-framework) for agentic AI governance* diff --git a/research/004_ai_agent_attack_surface.md b/research/004_ai_agent_attack_surface.md new file mode 100644 index 0000000..4b8436e --- /dev/null +++ b/research/004_ai_agent_attack_surface.md @@ -0,0 +1,50 @@ +# Research Note 004: AI Agent Attack Surface in DeFi + +**Classification:** Open-Source Intelligence | CSI CryptoSHIELD Framework +**Status:** FORTHCOMING: Track progress at GitHub Issue #004 +**Date:** Expected Q3 2026 | **Version:** Stub 0.1 +**Threat IDs:** CS-AI-01, CS-AI-02, CS-AI-03, CS-AI-04, CS-AI-05 +**Domain:** 07: AI Agent and Autonomous System Security + +--- + +## Scope (Planned) + +This research note will provide full-depth analysis of the AI agent attack surface in DeFi environments, including: + +- Complete attack surface mapping for AI agents holding or managing crypto assets +- Case study analysis: Step Finance ($40M, January 2026), ClawJacked vulnerability class, Freysa exploit +- Memory poisoning attack methodology and detection indicators +- Prompt injection kill chains for DeFi-connected agents +- AI swarm attack architecture: GTG-1002 campaign anatomy (November 2025) +- Agent wallet architecture recommendations with code examples +- Integration with AI SAFE² v3.0 ACT Capability Tier framework + +## Why This Note Matters + +By Q1 2026, AI agent wallets represented 8-12% of EVM DeFi transaction volume. The attack surface did not exist at meaningful scale eighteen months ago. The threat models, attack patterns, and governance gaps are all actively being discovered in production: not in academic research. This note will document what is known from real incidents and extrapolate the emerging threat landscape. + +## Key Questions This Note Will Answer + +1. What percentage of major DeFi losses in 2025-2026 involved an AI agent as a contributing factor? +2. What is the definitive taxonomy of prompt injection attack classes against DeFi agents? +3. How does Freysa-class logic redefinition work and how is it defended? +4. What does a safe keyless agent architecture look like in production? +5. Where does CryptoSHIELD Domain 07 end and AI SAFE² begin for agents at different ACT tiers? + +--- + +## Interim Guidance + +Until this research note is published, see: + +- [Domain 07: AI Agent Security](../07-ai-agent-security/README.md): current control set +- [AI SAFE² Framework v3.0](https://github.com/CyberStrategyInstitute/ai-safe2-framework): full agentic AI governance +- [taxonomy/registry-table.md](../taxonomy/registry-table.md): CS-AI-01 through CS-AI-05 entries + +**To contribute to this research note:** Open an issue with the label `research-004` and provide documented incident analysis, technical findings, or peer-reviewed sources. + +--- + +*Research Note 004 Stub | CSI CryptoSHIELD Framework v1.1* +*Cyber Strategy Institute | Open-Source | Expected Q3 2026* diff --git a/research/005_supply_chain_vectors.md b/research/005_supply_chain_vectors.md new file mode 100644 index 0000000..468d8b1 --- /dev/null +++ b/research/005_supply_chain_vectors.md @@ -0,0 +1,49 @@ +# Research Note 005: Supply Chain Vectors: The Full Attack Surface + +**Classification:** Open-Source Intelligence | CSI CryptoSHIELD Framework +**Status:** FORTHCOMING: Track progress at GitHub Issue #005 +**Date:** Expected Q3 2026 | **Version:** Stub 0.1 +**Threat IDs:** CS-SC-01, CS-SC-02, CS-SC-03, CS-SC-04 +**Domain:** 06: Supply Chain Defense + +--- + +## Scope (Planned) + +Full-depth analysis of the crypto and Web3 supply chain attack surface, including: + +- Shai-Hulud npm worm (September 2025) complete forensic reconstruction +- Ledger Connect Kit compromise kill chain and cascade analysis +- Ultralytics YOLO11 AI model backdoor: GitHub Actions as attack vector +- ThirdWeb vulnerability and dependent protocol cascade +- Malicious VS Code extension ecosystem: wallet targeting +- JavaScript ecosystem attack surface: npm, CDN, import maps +- Python ecosystem: PyPI poisoning, requirements.txt exploitation +- CI/CD attack taxonomy: GitHub Actions, GitLab CI, Jenkins +- AI model supply chain: Hugging Face, PyPI, GitHub Releases +- SBOM enforcement: tooling comparison, integration patterns, CI/CD hooks +- Developer machine as the new perimeter + +## Key Questions This Note Will Answer + +1. What are the five highest-probability supply chain attack paths against a crypto developer today? +2. What does Shai-Hulud tell us about the systemic vulnerability of the npm ecosystem? +3. How does an AI model backdoor differ from traditional software supply chain compromise? +4. What does a minimal viable SBOM enforcement stack look like for a 3-person DeFi team? +5. How do supply chain attacks interact with insider threats (CS-SC-03 and CS-INS-01)? + +--- + +## Interim Guidance + +Until this research note is published, see: + +- [Domain 06: Supply Chain Defense](../06-supply-chain-defense/README.md): current control set +- [taxonomy/registry-table.md](../taxonomy/registry-table.md): CS-SC-01 through CS-SC-04 entries + +**To contribute:** Open an issue labeled `research-005`. + +--- + +*Research Note 005 Stub | CSI CryptoSHIELD Framework v1.1* +*Cyber Strategy Institute | Open-Source | Expected Q3 2026* diff --git a/research/006_pig_butchering_anatomy.md b/research/006_pig_butchering_anatomy.md new file mode 100644 index 0000000..1f99bb7 --- /dev/null +++ b/research/006_pig_butchering_anatomy.md @@ -0,0 +1,58 @@ +# Research Note 006: Pig Butchering: Full Anatomy of a $7.2B Industry + +**Classification:** Open-Source Intelligence | CSI CryptoSHIELD Framework +**Status:** FORTHCOMING: Track progress at GitHub Issue #006 +**Date:** Expected Q3 2026 | **Version:** Stub 0.1 +**Threat IDs:** CS-FRD-01, CS-FRD-02, CS-SOC-06 +**Domain:** 09: Consumer Fraud and Financial Grooming Defense + +--- + +## Scope (Planned) + +Full-depth anatomy of the pig butchering (sha zhu pan) ecosystem, including: + +- Complete industrial operation model: Myanmar/Cambodia/Laos compound infrastructure +- Forced labor supply chain (CS-SOC-06): recruitment, trafficking, operational deployment +- AI personalization at scale: how compound operators use AI to manage thousands of simultaneous "relationships" +- Platform lifecycle: platform creation, brand establishment, fake review seeding, takedown and pivot +- Kill chain by victim demographic: romance targets, professional network targets, community targets +- The fee escalation cycle: psychological mechanics of each phase +- Recovery re-victimization (CS-FRD-02): how secondary scammers target victims post-loss +- FBI IC3 Operation Level Up: methodology and success metrics ($285M stopped in 2024) +- Structural differences between SE Asian compounds and Eastern European "boiler room" operations +- Defense for individuals: detection at each kill chain phase +- Defense for platforms: account pattern recognition, deposit velocity alerts, jurisdiction mapping + +## Key Questions This Note Will Answer + +1. How has AI changed the pig butchering operation model since 2022? +2. What distinguishes a pig butchering platform from a legitimate investment platform at the backend infrastructure level? +3. What is the psychological mechanism that keeps victims depositing after withdrawal is blocked? +4. What happened to the $285M that Operation Level Up "stopped" and how was it identified? +5. How do pig butchering compounds interact with the broader DPRK and organized crime ecosystem? + +--- + +## The $7.2 Billion Number + +FBI IC3 2025 Annual Report: $7.2 billion in investment fraud losses in the United States, of which the majority is attributable to pig butchering and related platforms. This is the single largest category of crypto-related financial crime by dollar volume: larger than all DeFi hacks combined. + +CTRS score: 20.0 out of 20.0. Maximum across all five components. + +--- + +## Interim Guidance + +Until this research note is published, see: + +- [Domain 09: Consumer Fraud Defense](../09-consumer-fraud-defense/README.md): current control set +- [Playbook: Consumer Fraud Defense](../playbooks/consumer-fraud.md): incident response +- [taxonomy/registry-table.md](../taxonomy/registry-table.md): CS-FRD-01 entry + +**To contribute:** Open an issue labeled `research-006`. + +--- + +*Research Note 006 Stub | CSI CryptoSHIELD Framework v1.1* +*Cyber Strategy Institute | Open-Source | Expected Q3 2026* diff --git a/research/007_false_flag_forensics.md b/research/007_false_flag_forensics.md new file mode 100644 index 0000000..3e866e4 --- /dev/null +++ b/research/007_false_flag_forensics.md @@ -0,0 +1,236 @@ +# Research Note 007: False Flag Forensics: Systematic Attribution Analysis for Crypto Incidents + +**Classification:** Open-Source Intelligence | CSI CryptoSHIELD Framework +**Date:** May 2026 | **Version:** 1.0 (Seed Document) +**Related Threat IDs:** CS-INS-01, CS-INS-03 (Wagemole), CS-DFI-01 +**Domain:** 00: Cross-Domain Governance | Intelligence Layer + +> **Note:** This research note is the seed document for the full False Flag Assessment Protocol (FFAP) deliverable. The FFAP will apply this methodology to 10 historical cases and produce a publishable Attribution Accuracy Report. See `research/007_ffap_full.md` (forthcoming). + +--- + +## The Core Problem + +The crypto industry has a narrative problem that is also a security problem. + +When a protocol is drained, the incident report almost universally reaches one of two conclusions within 48-72 hours: +1. "The hack was executed by North Korean hackers (DPRK/Lazarus Group)" +2. "The exploit was a smart contract vulnerability" + +Both attributions are frequently wrong: or incomplete. And the consequences of wrong attribution are severe: the true attacker goes unpunished, the root cause is misidentified, corrective controls target the wrong layer, and victims of insider negligence have no legal recourse because the "DPRK did it" narrative shields the responsible parties. + +CSI's multi-pass analysis of major incidents reveals a consistent pattern: **insider-vector attacks are systematically misattributed to external nation-state actors.** The DPRK attribution serves as a convenient "fall guy" that satisfies regulators, journalists, and token holders while protecting the individuals whose operational failures or active malfeasance actually enabled the exploit. + +--- + +## Defining the False Flag + +In the context of crypto incident attribution, a "false flag" is not necessarily a deliberate deception operation: though that exists too. It is any attribution conclusion that: + +1. **Assigns credit to an actor who did not initiate the attack**, while +2. **Shielding the actor(s) whose failures or actions were the actual root cause** + +The practical distinction: Was the exploit technically only possible because someone with privileged access failed to follow security protocols: or actively assisted the attacker? If yes, the "DPRK" attribution is at minimum incomplete, and often materially false. + +--- + +## The False Flag Assessment Protocol (FFAP) + +### Indicator Set 1: Access Vector Analysis + +The first question in any attribution analysis: **how did the attacker get in?** + +| Access Method | Insider Probability | DPRK Probability | Notes | +|---|---|---|---| +| Admin key compromise (EOA, known key holder) | HIGH | MEDIUM | DPRK achieves this via social engineering of keyholder | +| Multi-sig key compromise (multiple key holders) | HIGH | LOW-MEDIUM | Requires compromising multiple independent parties | +| Smart contract bug (audited code) | LOW | LOW | Neither; pure technical failure | +| Smart contract bug (unaudited code) | LOW | LOW | Neither; development failure | +| Frontend/DNS compromise | MEDIUM | MEDIUM | Infrastructure access | +| Malware on developer device | MEDIUM | HIGH | DPRK Wagemole primary vector | +| Insider with direct access | CRITICAL | LOW | DPRK can execute IF insider | +| Supply chain (npm/SDK) | LOW-MEDIUM | HIGH | DPRK actively uses this vector | + +**Key Insight:** If the access method required someone with privileged access to have their device compromised, that person's device security practices and the circumstances of the compromise become critical attribution data. "DPRK compromised my laptop" is a claim that must be forensically verified: not accepted as given. + +--- + +### Indicator Set 2: Code Change Timeline + +CSI analysis of LNDFi, BrincFi, Radiant Capital, and other insider-vector incidents reveals a consistent pattern: + +**The Pre-Exploit Code Change Pattern:** +``` +T-90 days to T-30 days: Malicious or enabling code change committed to repository +T-30 to T-7 days: Change passes code review (reviewer does not flag) +T-7 to T-0: Final operational setup (admin role granted, key positioning) +T-0: Exploit execution +``` + +**Analysis Questions:** +- When was the last code change to the attacked contract/function before the exploit? +- Who committed that change? Was it the same person who controls admin keys? +- Did the change expand any admin role's authority in a non-obvious way? +- Did code reviewers document concerns? +- Was the change timing correlated with any personnel changes (new hire, contractor engagement)? + +**LNDFi Case Data Point:** A five-word code change committed 41 days before the exploit granted any "Pool Admin" the ability to drain funds. The change was small, non-obvious, and passed review. The exploit used the exact capability this change enabled. CSI attribution confidence for insider involvement: HIGH. + +--- + +### Indicator Set 3: Fund Flow Analysis + +DPRK's laundering methodology is documented, consistent, and traceable: + +**DPRK Laundering Signature:** +``` +Exploit wallet → Tornado Cash (pre-March 2025) / sanctioned mixers +→ THORChain (chain hop) +→ Multiple hops through Chinese broker intermediaries +→ OTC desk settlement (USDT/BTC) +``` + +**Insider/Organized Crime Laundering Signature (different):** +``` +Exploit wallet → DEX hops (Uniswap, Curve) +→ CEX with lax KYC (offshore) +→ Privacy coin conversion +→ [Often less sophisticated than DPRK; mistakes in fund flow] +``` + +**Questions:** +- Do the fund flows match DPRK's documented laundering methodology? +- Were THORChain and Chinese broker intermediaries used? (DPRK-consistent) +- Did the attacker make mistakes in fund movement? (Inconsistent with DPRK discipline) +- Was there any interaction with CEXes that would create a KYC trail? (DPRK avoids) +- Did on-chain timing correlate with North Korean business hours? (DPRK-consistent, not conclusive) + +--- + +### Indicator Set 4: The Fall-Guy Pattern Detection + +A "fall guy" is an actor: person or organization: who is sacrificed (willingly or unwillingly) to absorb reputational, regulatory, and legal accountability for a deeper operation. In crypto, this manifests as: + +**Type A: Willing Fall Guy** +- Individual accepts responsibility for a planned exploit as part of an arrangement +- Typically offered financial compensation held in escrow pending "conviction" +- Example template: developer "goes rogue," accepts arrest while others escape with bulk proceeds + +**Type B: Unwilling Fall Guy (Patsy)** +- Individual or organization is positioned to appear responsible without their knowledge +- Example: DPRK attribution used to shield insider who actually provided access +- The Wagemole DPRK operative provides cover story: "we hired a North Korean, it's their fault": when the true failure was inadequate vetting and security controls + +**Type C: Sacrificial Entity** +- An organization (exchange, protocol) is allowed to fail publicly, absorbing regulatory and media attention +- Classic example: FTX absorbs the full regulatory response to a broader capital extraction pattern +- Capital that flowed out before FTX collapse is protected by the FTX collapse narrative + +**Detection Questions:** +- Who benefits financially from this incident narrative? +- Does the attributed actor's capabilities match the sophistication of the attack? +- Is there a simpler explanation that involves people closer to the protocol? +- Did any key personnel exit with funds, leave the company, or become uncontactable before or after the incident? +- Was the public narrative established suspiciously quickly? (< 24 hours for DPRK attribution suggests pre-positioning) + +--- + +### Indicator Set 5: Personnel Analysis + +For any protocol suffering a large exploit, the insider threat checklist: + +``` +Personnel Analysis Checklist: +[ ] Who had admin key access at time of exploit? +[ ] When was that access granted? By whom? +[ ] Did any of these individuals join within 12 months of the exploit? (Wagemole window) +[ ] Were background checks performed on all key holders? +[ ] Did any key holder have unexplained wealth, behavioral changes, or unusual absence before exploit? +[ ] Who is NOT cooperating with post-incident investigation? +[ ] Were any team members recruited via LinkedIn or recruiter outreach? (Wagemole vector) +[ ] Did any team member review the malicious code change without flagging it? +``` + +**The Wagemole Indicator Set (DPRK-specific):** +These are indicators of DPRK identity fabrication for insider access. See Research Note 003 for full analysis. + +--- + +## FFAP Scoring Formula + +Each incident receives a composite False Flag Probability Score (FFPS) based on weighted indicators: + +``` +FFPS = (Access_Vector_Score × 0.30) + + (Code_Change_Score × 0.25) + + (Fund_Flow_Score × 0.20) + + (Fall_Guy_Score × 0.15) + + (Personnel_Score × 0.10) +``` + +Each component scored 0-1.0: +- 0.0-0.3: Attribution consistent with official narrative +- 0.3-0.6: Material uncertainty; insider probability non-trivial +- 0.6-0.8: Insider vector probable; official attribution likely incomplete +- 0.8-1.0: False flag highly probable; official attribution is covering deeper actors + +--- + +## Priority Cases for FFAP Analysis + +The following cases are queued for full FFAP analysis in the forthcoming Attribution Accuracy Report: + +| Case | Official Attribution | CSI Preliminary FFPS | Key Anomaly | +|---|---|---|---| +| FTX Collapse (Nov 2022) | "FTX mismanagement" | 0.45 | Capital flow patterns suggest coordinated extraction pre-collapse | +| LNDFi Hack (May 2025) | DPRK Lazarus | 0.72 | 41-day pre-exploit code change, Pool Admin access | +| Radiant Capital (Oct 2024) | DPRK Lazarus | 0.55 | Three developer device compromise; Safe{Wallet} display manipulation | +| Bybit (Feb 2025) | DPRK Lazarus | 0.35 | Fund flow most consistent with DPRK signature | +| Drift Protocol (Apr 2026) | DPRK Lazarus | 0.48 | Six-month fake employee; social engineering primary vector | +| BrincFi (2021) | "Developer theft" | 0.80 | Malicious function in production code by trusted developer | +| Step Finance (Jan 2026) | "Private key compromise" | 0.40 | Device compromise; AI agent amplification | +| Kelp DAO (Apr 2026) | Bridge exploit | 0.20 | Single-verifier design; technical failure primary | + +--- + +## The Structural Problem + +Attribution accuracy in crypto has a structural incentive problem: + +**Protocols benefit from DPRK attribution because:** +- It removes their legal liability (act of foreign government) +- It satisfies regulators ("we were hacked by nation-states") +- It maintains community trust ("not our fault") +- It preserves investment value longer than "our dev stole it" + +**Law enforcement benefits from DPRK attribution because:** +- It produces press-worthy indictments of foreign actors +- It avoids the political difficulty of prosecuting respected industry figures +- It feeds the national security budget justification cycle + +**The media benefits from DPRK attribution because:** +- Nation-state hacking makes better headlines than insider access control failures +- The narrative is simpler and more dramatic + +**The actual insider or negligent party benefits most of all.** + +CSI's mission in this domain: build the analytical tools to interrupt this attribution laundering cycle. Not to protect DPRK from accountability: their thefts are real and significant: but to ensure that the insider-threat population that uses DPRK as cover is also held accountable. + +--- + +## Research Note Series Context + +| Note | Topic | Status | +|---|---|---| +| 001 | Wrench Attack Epidemic | Complete | +| 002 | The Rotator Effect | Complete | +| 003 | DPRK Attribution Analysis | Complete | +| 004 | AI Agent Attack Surface | Forthcoming | +| 005 | Supply Chain Vectors | Forthcoming | +| 006 | Pig Butchering Anatomy | Forthcoming | +| 007 | False Flag Forensics (this note) | Seed complete; full FFAP report forthcoming | + +--- + +*Research Note 007 | CSI CryptoSHIELD Framework v1.1* +*Cyber Strategy Institute | May 2026 | Open-Source* diff --git a/taxonomy/bridge-risk-appendix.md b/taxonomy/bridge-risk-appendix.md new file mode 100644 index 0000000..8e1ebf4 --- /dev/null +++ b/taxonomy/bridge-risk-appendix.md @@ -0,0 +1,166 @@ +# Appendix: Bridge and Cross-Chain Risk: Full Specification + +**CSI CryptoSHIELD Framework v1.1** +Related Control: OCM-07 | Threat ID: CS-DFI-03 | CTRS: 17.5 (CRITICAL) + +> Bridge exploits are the single largest DeFi loss category in history: $2.88 billion stolen cumulatively through April 2026. At this scale and with this threat-specific complexity, the bridge risk domain warrants full specification beyond OCM-07's summary controls. + +--- + +## Why Bridges Are the Highest-Risk DeFi Surface + +Cross-chain bridges must solve an impossible problem: they must trustlessly verify the state of one blockchain from another blockchain that has no native awareness of the first. Every bridge design is a trust-tradeoff. Every tradeoff creates an attack surface. + +**The Three Fundamental Trust Models:** + +| Model | How It Works | Security Posture | Risk Profile | +|---|---|---|---| +| Light Client / ZK Proof | Native cryptographic verification of source chain state | Trustless | Low risk; high complexity; expensive | +| Optimistic (Fraud Proofs) | Assume validity; challenge window for fraud proofs | Trust-minimized | Medium risk; requires sufficient challenge window | +| Multi-sig Verifier | N-of-M committee signs cross-chain messages | Trust-dependent | HIGH risk; committee = single point of failure | +| Single Verifier | One party attests to cross-chain messages | Fully trusted | CRITICAL risk; unacceptable | + +**CSI Position:** Any bridge using fewer than 5 independent validators with genuine key independence is an elevated risk position. Single-verifier bridges (LayerZero configured with one DVN, Kelp DAO style) represent an unacceptable risk concentration regardless of marketing narrative. + +--- + +## Bridge Risk Assessment Matrix (Full) + +Score each factor 1-5. Total score determines recommended posture. + +| Risk Factor | 1 (Safe) | 2 | 3 | 4 | 5 (Critical Risk) | +|---|---|---|---|---|---| +| Verifier count | 15+ independent | 10-14 | 5-9 | 2-4 | 1 (single verifier) | +| Deployment age | 3+ years | 2-3 years | 1-2 years | 6-12 months | <6 months | +| Audit count | 4+ reputable firms | 3 firms | 2 firms | 1 firm | Unaudited | +| TVL (battle-testing proxy) | >$1B | $100M-$1B | $10M-$100M | $1M-$10M | <$1M | +| Admin key design | Multi-sig + 7-day timelock | Multi-sig only | 3-of-5 + 72h | 2-of-3, no timelock | EOA or opaque | +| Incident history | Clean 3+ years | Clean <3 years | Minor resolved | Major resolved | Active incident | +| Validator independence | Fully independent, diverse jurisdictions | Known independent | Partially known | Relationship unclear | Related parties | + +**Scoring:** +- 7-14: Acceptable. Standard monitoring sufficient. +- 15-21: Caution. Reduce position size; increase monitoring frequency. +- 22-28: Elevated. Consider alternatives; strict size limits. +- 29-35: Avoid. Risk profile unacceptable for significant capital. + +--- + +## Major Bridge Exploits: Forensic Summary + +| Date | Bridge | Loss | Root Cause | Verifier Design | +|---|---|---|---|---| +| Mar 2022 | Ronin Network | $625M | 5 of 9 validators compromised via social engineering | 9 multi-sig (Axie Infinity controlled majority) | +| Feb 2022 | Wormhole | $320M | Signature verification bypass: guardian set flaw | Guardian multi-sig | +| Aug 2022 | Nomad | $190M | Initialization error: any message accepted as valid | Optimistic with broken proof | +| Jan 2023 | BNB Bridge | $570M | On-chain proof verification bypass | BSC validator set | +| Apr 2026 | Kelp DAO | $292M | Single LayerZero DVN: one verifier controls all messages | Single-verifier (LayerZero default config) | + +**Pattern across all five:** Every bridge that failed had a trust concentration point: a small committee, a single verifier, or a flawed cryptographic assumption: that an attacker could defeat with a single action. Truly trustless bridges (light client, ZK) have not had this class of exploit. + +--- + +## The Kelp DAO Case (April 2026): Design Failure Anatomy + +The Kelp DAO exploit is the definitive post-LayerZero case for single-verifier bridge risk. + +**The Design:** LayerZero's default configuration allows bridge operators to specify a single Decentralized Verifier Network (DVN): one party: to attest to cross-chain messages. Kelp DAO used this default configuration without adding additional DVNs. + +**The Exploit:** The single DVN was compromised, allowing the attacker to fabricate arbitrary cross-chain messages. The bridge had no mechanism to challenge or reject messages that the DVN attested to. + +**The Loss:** $292 million. + +**The Defense:** OCM-07 states: "avoid single-verifier designs." More specifically: when evaluating any LayerZero-based bridge, verify the number of DVNs configured. One DVN = single-verifier architecture regardless of marketing materials. + +**How to verify LayerZero DVN count:** +``` +1. Find the bridge's LayerZero endpoint contract on Etherscan +2. Look for the ULN (Ultra Light Node) configuration +3. Identify the requiredDVNs and optionalDVNs fields +4. If requiredDVNs.length == 1: single-verifier risk confirmed +5. If optionalDVNs.length == 0: no redundancy at all +``` + +--- + +## Bridge Selection Framework + +Before bridging any amount over $1,000, answer these questions: + +``` +Bridge Due Diligence Checklist: +[ ] How many independent validators/DVNs are required to approve a message? + → If answer is 1: STOP. Do not bridge. +[ ] How long has this bridge been operating? + → If less than 6 months: maximum 5% of intended position only +[ ] How many independent audits exist? + → If zero or one from unknown firm: significant caution warranted +[ ] Is the admin key design visible on-chain? + → If opaque or EOA: avoid +[ ] Is there an on-chain timelock for admin changes? + → If no timelock: elevated risk +[ ] Does the bridge have an active bug bounty? + → If no: governance signal +[ ] Can I bridge on the native chain bridge instead? + → Native chain bridges (Ethereum canonical) generally safer than third-party +``` + +**The Safe Default:** Ethereum canonical bridge for ETH-to-L2 transfers. It uses the L2's own security model and is not operated by a third party. It is slow (7-day withdrawal window on optimistic rollups) but trustless. + +--- + +## Approved Bridge List (May 2026: CSI Assessment) + +*This list reflects CSI's assessment at publication. Bridge risk changes rapidly with TVL, incidents, and configuration changes. Always run the checklist above before bridging.* + +| Bridge | Primary Chains | Verifier Design | CSI Rating | Notes | +|---|---|---|---|---| +| Ethereum Native Bridge | ETH ↔ L2s | L2 consensus | SAFE | Slow but trustless; canonical | +| Arbitrum Bridge | ETH ↔ Arbitrum | Fraud proofs + sequencer | SAFE | 7-day withdrawal; battle-tested | +| Optimism Bridge | ETH ↔ OP | Fraud proofs | SAFE | 7-day withdrawal | +| Polygon PoS Bridge | ETH ↔ Polygon | PoS validators | MODERATE | Validator set risk; sufficient size | +| Across Protocol | Multi-chain | Optimistic + UMA | MODERATE | 2+ years; multiple audits | +| Stargate | Multi-chain | LayerZero (multi-DVN) | MODERATE | Verify DVN count per deployment | +| Hop Protocol | ETH ↔ L2s | Bonder + AMM | MODERATE | Decentralized; battle-tested | +| Any single-DVN bridge | Any | Single verifier | AVOID | Kelp DAO pattern | +| Any bridge <6mo old | Any | Varies | CAUTION | Insufficient battle-testing | + +--- + +## Developer Implementation: Safe Bridge Integration + +```solidity +// Before integrating any bridge into your protocol: +// 1. Verify the verifier/validator architecture +// 2. Implement a bridge-specific withdrawal timelock +// 3. Set position size limits per bridge address +// 4. Monitor bridge contract admin key activity + +// Example: Bridge position limits +mapping(address => uint256) public bridgeDailyLimit; +mapping(address => uint256) public bridgeDailyUsed; +mapping(address => uint256) public lastBridgeReset; + +function setBridgeLimit(address bridge, uint256 limit) external onlyAdmin { + require(limit <= MAX_BRIDGE_LIMIT, "Exceeds protocol bridge cap"); + bridgeDailyLimit[bridge] = limit; +} + +modifier withinBridgeLimit(address bridge, uint256 amount) { + if (block.timestamp > lastBridgeReset[bridge] + 1 days) { + bridgeDailyUsed[bridge] = 0; + lastBridgeReset[bridge] = block.timestamp; + } + require( + bridgeDailyUsed[bridge] + amount <= bridgeDailyLimit[bridge], + "Bridge daily limit exceeded" + ); + bridgeDailyUsed[bridge] += amount; + _; +} +``` + +--- + +*Bridge Risk Appendix | CSI CryptoSHIELD Framework v1.1* +*Cyber Strategy Institute | Open-Source | Sovereignty-First* diff --git a/taxonomy/ctrs-scoring.md b/taxonomy/ctrs-scoring.md new file mode 100644 index 0000000..f661bab --- /dev/null +++ b/taxonomy/ctrs-scoring.md @@ -0,0 +1,184 @@ +# Crypto Threat Risk Score (CTRS): Scoring Methodology + +**CSI CryptoSHIELD Framework v1.1** +Cyber Strategy Institute | Open-Source + +--- + +## Overview + +The Crypto Threat Risk Score (CTRS) is a weighted severity model for prioritizing threats in the CryptoSHIELD taxonomy. It enables consistent comparison across fundamentally different threat types: physical coercion, smart contract exploits, social engineering, AI agent attacks: by normalizing them to a single 0-20 scale. + +The CTRS is modeled after the Cognitive Threat Severity Score (CTSS) used in the Cognitive Sovereignty Framework, adapted for the crypto-specific threat landscape. + +--- + +## Formula + +``` +CTRS = (L × 0.25) + (I × 0.30) + (R × 0.20) + (D × 0.15) + (RecD × 0.10) + +Where each component is scored 0-4 (max raw sum = 4.0) +Scale to 0-20 by multiplying by 5. +``` + +**Full formula with scaling:** +``` +CTRS = [(L × 0.25) + (I × 0.30) + (R × 0.20) + (D × 0.15) + (RecD × 0.10)] × 20 +Range: 0-20 | Critical ≥ 17 | High ≥ 13 | Elevated ≥ 9 | Low < 9 +``` + +--- + +## Component Definitions + +### Likelihood (L): Weight: 0.25 +Probability that the threat will affect a crypto holder with moderate wealth and normal digital hygiene. + +| Score | Definition | +|---|---| +| 0 | Theoretical; no documented cases at scale | +| 1 | Rare; fewer than 10 documented incidents per year globally | +| 2 | Occasional; 10-100 incidents per year globally | +| 3 | Common; hundreds of incidents per year; regular CSI reporting | +| 4 | Pervasive; thousands of incidents; systemic threat | + +### Impact on Sovereignty (I): Weight: 0.30 +Effect on the victim's financial sovereignty, safety, and ability to recover. Highest weight because sovereignty is the framework's primary value. + +| Score | Definition | +|---|---| +| 0 | No meaningful impact | +| 1 | Minor financial loss (<$1,000); no safety impact | +| 2 | Moderate loss ($1,000-$50,000); recoverable | +| 3 | Major loss (>$50,000) or significant platform compromise | +| 4 | Catastrophic: total loss, physical harm, or permanent compromise | + +### Reach / Scale (R): Weight: 0.20 +How broadly the threat can affect populations beyond the individual target. + +| Score | Definition | +|---|---| +| 0 | Targeted; affects only specific identified individual | +| 1 | Small group; protocol-level with limited user base | +| 2 | Sector-level; affects users of a category of platforms | +| 3 | Ecosystem-level; affects users of major infrastructure | +| 4 | Civilizational; affects financial system or regulatory framework | + +### Detection Difficulty (D): Weight: 0.15 +How difficult the attack is to detect before or during execution. + +| Score | Definition | +|---|---| +| 0 | Easily detected; clear behavioral indicators | +| 1 | Detectable with standard monitoring | +| 2 | Requires specialized tools or knowledge to detect | +| 3 | Near-undetectable with current consumer tools | +| 4 | Undetectable without forensic analysis; AI-enhanced deception | + +### Recovery Difficulty (RecD): Weight: 0.10 +How difficult it is to reverse or recover from the impact. + +| Score | Definition | +|---|---| +| 0 | Fully recoverable; no lasting harm | +| 1 | Recoverable with effort (technical remediation) | +| 2 | Partial recovery possible (some assets recoverable) | +| 3 | Largely unrecoverable (blockchain finality; physical harm) | +| 4 | Unrecoverable; permanent loss or harm | + +--- + +## Threat Tier Classification + +| CTRS Range | Tier | Response Priority | +|---|---|---| +| 17.0-20.0 | CRITICAL | Immediate controls required; no delay | +| 13.0-16.9 | HIGH | Controls required within 30 days | +| 9.0-12.9 | ELEVATED | Controls recommended; include in next review cycle | +| 0-8.9 | LOW | Monitor; address opportunistically | + +--- + +## Scored Threat Registry (Full) + +| Threat ID | Threat Name | L | I | R | D | RecD | CTRS | Tier | +|---|---|---|---|---|---|---|---|---| +| CS-PHY-01 | Kidnapping/Coercion | 2 | 4 | 2 | 3 | 4 | 15.0 | HIGH | +| CS-PHY-02 | Home Invasion | 2 | 4 | 2 | 3 | 4 | 15.0 | HIGH | +| CS-INS-01 | Admin Key Abuse | 2 | 4 | 3 | 4 | 4 | 17.0 | CRITICAL | +| CS-INS-02 | CEX Support Bribery | 2 | 3 | 3 | 4 | 3 | 14.5 | HIGH | +| CS-INS-03 | DPRK Wagemole | 2 | 4 | 3 | 4 | 4 | 17.0 | CRITICAL | +| CS-SOC-01 | Phishing | 4 | 3 | 3 | 3 | 3 | 16.0 | CRITICAL | +| CS-SOC-02 | Fake Hardware Wallet | 1 | 4 | 2 | 4 | 4 | 15.5 | HIGH | +| CS-SOC-03 | Fake Job Offer | 3 | 3 | 3 | 4 | 3 | 15.5 | HIGH | +| CS-SOC-04 | Fake Meeting App | 3 | 3 | 3 | 4 | 3 | 15.5 | HIGH | +| CS-SOC-05 | AI Deepfake | 3 | 3 | 3 | 4 | 3 | 15.5 | HIGH | +| CS-SOC-06 | Forced Labor Compound | 4 | 4 | 4 | 4 | 4 | 20.0 | CRITICAL | +| CS-SOC-07 | Typosquatting | 4 | 3 | 3 | 2 | 3 | 15.0 | HIGH | +| CS-MAL-01 | Clipboard Hijacking | 4 | 3 | 3 | 3 | 3 | 16.0 | CRITICAL | +| CS-MAL-02 | InfoStealer/RAT | 3 | 4 | 3 | 4 | 4 | 17.5 | CRITICAL | +| CS-MAL-03 | Fake Cloudflare | 3 | 3 | 3 | 4 | 3 | 15.5 | HIGH | +| CS-WAL-01 | Seed Phrase Theft | 3 | 4 | 2 | 3 | 4 | 16.0 | CRITICAL | +| CS-WAL-02 | Address Poisoning | 4 | 3 | 3 | 4 | 3 | 16.5 | CRITICAL | +| CS-WAL-03 | DNS Hijack | 2 | 4 | 3 | 4 | 4 | 17.0 | CRITICAL | +| CS-WAL-04 | Malicious Signature | 4 | 4 | 3 | 4 | 4 | 19.0 | CRITICAL | +| CS-WAL-05 | Low Entropy Seed | 1 | 4 | 1 | 4 | 4 | 14.5 | HIGH | +| CS-DFI-01 | Admin Key Exploit | 2 | 4 | 3 | 3 | 4 | 16.5 | CRITICAL | +| CS-DFI-02 | Flash Loan Attack | 2 | 3 | 3 | 3 | 4 | 14.5 | HIGH | +| CS-DFI-03 | Bridge Exploit | 2 | 4 | 4 | 3 | 4 | 17.5 | CRITICAL | +| CS-DFI-04 | Oracle Manipulation | 2 | 3 | 3 | 3 | 4 | 14.5 | HIGH | +| CS-DFI-05 | Reentrancy | 1 | 3 | 2 | 3 | 3 | 11.5 | ELEVATED | +| CS-SC-01 | NPM Package Hijack | 3 | 4 | 4 | 4 | 4 | 19.0 | CRITICAL | +| CS-SC-02 | SDK/Library Poisoning | 2 | 4 | 4 | 4 | 4 | 18.0 | CRITICAL | +| CS-SC-03 | CI/CD Compromise | 2 | 4 | 4 | 4 | 4 | 18.0 | CRITICAL | +| CS-SC-04 | AI Model Backdoor | 1 | 4 | 4 | 4 | 4 | 17.5 | CRITICAL | +| CS-AI-01 | Memory Poisoning | 2 | 4 | 3 | 4 | 4 | 17.5 | CRITICAL | +| CS-AI-02 | Prompt Injection | 3 | 4 | 3 | 4 | 4 | 18.0 | CRITICAL | +| CS-AI-03 | Data Chain Poisoning | 2 | 3 | 3 | 4 | 3 | 15.0 | HIGH | +| CS-AI-04 | AI Swarm Attack | 1 | 4 | 4 | 4 | 4 | 17.5 | CRITICAL | +| CS-AI-05 | Synthetic Identity Fraud | 3 | 3 | 3 | 4 | 3 | 15.5 | HIGH | +| CS-MKT-01 | MEV/Sandwich Attack | 4 | 2 | 4 | 4 | 3 | 15.5 | HIGH | +| CS-MKT-02 | Tokenomics Weaponization | 4 | 3 | 4 | 4 | 3 | 17.5 | CRITICAL | +| CS-MKT-03 | Influence Operation | 4 | 2 | 4 | 3 | 2 | 13.5 | HIGH | +| CS-SOV-01 | CBDC Surveillance | 1 | 4 | 4 | 2 | 4 | 15.5 | HIGH | +| CS-SOV-02 | CEX KYC Overreach | 3 | 2 | 4 | 2 | 2 | 12.0 | ELEVATED | +| CS-FRD-01 | Pig Butchering | 4 | 4 | 4 | 4 | 4 | 20.0 | CRITICAL | +| CS-FRD-02 | Recovery Re-Victimization | 3 | 3 | 3 | 4 | 3 | 15.5 | HIGH | +| CS-FRD-03 | Bitcoin ATM Coercion | 3 | 3 | 3 | 3 | 3 | 15.0 | HIGH | +| CS-FRD-04 | Investment Group Scam | 3 | 3 | 3 | 4 | 3 | 15.5 | HIGH | +| CS-EXT-01 | Sextortion/Ransomware | 3 | 3 | 3 | 3 | 3 | 15.0 | HIGH | + +--- + +## Top 10 Critical Threats by CTRS + +| Rank | Threat ID | Name | CTRS | +|---|---|---|---| +| 1 | CS-FRD-01 | Pig Butchering / Financial Grooming | 20.0 | +| 1 | CS-SOC-06 | Forced Labor Compound Operations | 20.0 | +| 3 | CS-WAL-04 | Malicious Signature (Permit2/ERC-20) | 19.0 | +| 3 | CS-SC-01 | NPM Package Hijacking | 19.0 | +| 5 | CS-SC-02 | SDK/Library Poisoning | 18.0 | +| 5 | CS-SC-03 | CI/CD Pipeline Compromise | 18.0 | +| 5 | CS-AI-02 | Prompt Injection (AI Agents) | 18.0 | +| 8 | CS-MAL-02 | InfoStealer/RAT | 17.5 | +| 8 | CS-DFI-03 | Bridge Exploit | 17.5 | +| 8 | CS-SC-04 | AI Model Backdoor | 17.5 | + +--- + +## CTRS vs. Raw Dollar Loss + +CTRS is intentionally not a financial loss metric. It weights sovereignty impact and recoverability, which can diverge from raw dollar amounts: + +- CS-PHY-01 (Kidnapping): CTRS 15.0: relatively low dollar loss in aggregate, but maximum personal impact +- CS-FRD-01 (Pig Butchering): CTRS 20.0: $7.2B in U.S. losses 2025; maximum across all dimensions +- CS-DFI-05 (Reentrancy): CTRS 11.5: historically high dollar losses but declining frequency and improving detection + +The CTRS should be used alongside financial loss data from the threat registry, not as a replacement. + +--- + +*CTRS Scoring Methodology | CSI CryptoSHIELD Framework v1.1* +*Cyber Strategy Institute | Open-Source* diff --git a/taxonomy/registry-table.md b/taxonomy/registry-table.md new file mode 100644 index 0000000..fe82a65 --- /dev/null +++ b/taxonomy/registry-table.md @@ -0,0 +1,99 @@ +# CryptoSHIELD Threat Registry: Human-Readable Table + +**CSI CryptoSHIELD Framework v1.1** +Source of truth: [registry.json](registry.json) | Scoring methodology: [ctrs-scoring.md](ctrs-scoring.md) + +This table is the human-readable view of `registry.json`. It renders in the GitHub UI without tooling. For machine-readable ingestion (SIEM, analytics, automation), use the JSON registry directly. + +--- + +## Complete Threat Registry: 42 Entries + +| Threat ID | Name | Category | CTRS | Severity | Trend | AI-Assisted | Insider Vector | False Flag Prob | +|---|---|---|---|---|---|---|---|---| +| CS-PHY-01 | Kidnapping and Physical Coercion | Physical | 15.0 | HIGH | Rising +75% YoY | No | Possible | 0.10 | +| CS-PHY-02 | Home Invasion / Targeted Robbery | Physical | 15.0 | HIGH | Rising | No | No | 0.05 | +| CS-INS-01 | Admin Key Abuse by Trusted Actor | Insider | 17.0 | CRITICAL | Stable (endemic) | Possible | Yes | 0.75 | +| CS-INS-02 | CEX Support Team Bribery | Insider | 14.5 | HIGH | Rising | No | Yes | 0.30 | +| CS-INS-03 | DPRK Wagemole Identity Infiltration | Insider | 17.0 | CRITICAL | Rising | Yes | Yes | 0.65 | +| CS-SOC-01 | Phishing (AI-Enhanced) | Social Engineering | 16.0 | CRITICAL | Rising +1400% AI component | Yes | No | 0.10 | +| CS-SOC-02 | Fake Hardware Wallet Supply | Social Engineering | 15.5 | HIGH | Stable | No | No | 0.05 | +| CS-SOC-03 | Fake Job Offer / Malware Delivery | Social Engineering | 15.5 | HIGH | Rising (DPRK primary) | Yes | Possible | 0.55 | +| CS-SOC-04 | Fake Meeting Application (Meeten) | Social Engineering | 15.5 | HIGH | Rising | Yes | No | 0.15 | +| CS-SOC-05 | AI Deepfake CFO Impersonation | Social Engineering | 15.5 | HIGH | Rising rapidly | Yes | Possible | 0.25 | +| CS-SOC-06 | Forced Labor Compound Operations | Social Engineering | 20.0 | CRITICAL | Rising | Yes | No | 0.10 | +| CS-SOC-07 | Typosquatting / Domain Impersonation | Social Engineering | 15.0 | HIGH | Stable | Partial | No | 0.05 | +| CS-MAL-01 | Clipboard Hijacking | Malware | 16.0 | CRITICAL | Stable | No | No | 0.05 | +| CS-MAL-02 | InfoStealer / Remote Access Trojan | Malware | 17.5 | CRITICAL | Rising (DPRK primary) | Yes | Possible | 0.45 | +| CS-MAL-03 | Fake Cloudflare / Drive-By PowerShell | Malware | 15.5 | HIGH | Rising | Yes | No | 0.10 | +| CS-WAL-01 | Seed Phrase Theft / Extraction | Wallet | 16.0 | CRITICAL | Stable | Partial | Possible | 0.15 | +| CS-WAL-02 | Address Poisoning | Wallet | 16.5 | CRITICAL | Rising | Partial | No | 0.05 | +| CS-WAL-03 | DNS Hijack / Frontend Compromise | Wallet | 17.0 | CRITICAL | Stable | No | Possible | 0.25 | +| CS-WAL-04 | Malicious Signature (Permit2 / ERC-20) | Wallet | 19.0 | CRITICAL | Rising | Yes | No | 0.10 | +| CS-WAL-05 | Low Entropy Seed Generation | Wallet | 14.5 | HIGH | Declining (tooling improving) | No | No | 0.05 | +| CS-DFI-01 | Admin Key Exploit | DeFi Protocol | 16.5 | CRITICAL | Stable | Partial | Yes | 0.60 | +| CS-DFI-02 | Flash Loan Attack | DeFi Protocol | 14.5 | HIGH | Declining (oracle hardening) | Partial | No | 0.10 | +| CS-DFI-03 | Bridge Exploit | DeFi Protocol | 17.5 | CRITICAL | Rising (new bridges) | Partial | Possible | 0.35 | +| CS-DFI-04 | Oracle Manipulation | DeFi Protocol | 14.5 | HIGH | Stable | Partial | No | 0.15 | +| CS-DFI-05 | Reentrancy | DeFi Protocol | 11.5 | ELEVATED | Declining | No | No | 0.05 | +| CS-SC-01 | NPM Package Hijacking | Supply Chain | 19.0 | CRITICAL | Rising | Yes | Possible | 0.30 | +| CS-SC-02 | SDK / Library Poisoning | Supply Chain | 18.0 | CRITICAL | Rising | Yes | Possible | 0.35 | +| CS-SC-03 | CI/CD Pipeline Compromise | Supply Chain | 18.0 | CRITICAL | Rising | Yes | Possible | 0.40 | +| CS-SC-04 | AI Model Backdoor | Supply Chain | 17.5 | CRITICAL | Emerging (new vector) | Yes | Possible | 0.40 | +| CS-AI-01 | Memory Poisoning (Agent Vector DB) | AI Agent | 17.5 | CRITICAL | Emerging | Yes | No | 0.20 | +| CS-AI-02 | Prompt Injection (Agent Logic Override) | AI Agent | 18.0 | CRITICAL | Emerging | Yes | No | 0.15 | +| CS-AI-03 | Data Chain Poisoning (Training/Context) | AI Agent | 15.0 | HIGH | Emerging | Yes | Possible | 0.25 | +| CS-AI-04 | AI Swarm Coordinated Attack | AI Agent | 17.5 | CRITICAL | Emerging | Yes | No | 0.20 | +| CS-AI-05 | Synthetic Identity / Document Fraud | AI Agent | 15.5 | HIGH | Rising rapidly | Yes | No | 0.25 | +| CS-MKT-01 | MEV / Sandwich Attack | Market Manipulation | 15.5 | HIGH | Stable (structural) | Partial | No | 0.05 | +| CS-MKT-02 | Tokenomics Weaponization (Rotator Effect) | Market Manipulation | 17.5 | CRITICAL | Rising with AI | Yes | Yes | 0.55 | +| CS-MKT-03 | Influence Operation / FUD Campaign | Market Manipulation | 13.5 | HIGH | Rising with AI | Yes | Possible | 0.45 | +| CS-SOV-01 | CBDC Surveillance Architecture | Sovereignty | 15.5 | HIGH | Political (dormant in US 2025-26) | No | No | 0.05 | +| CS-SOV-02 | CEX KYC Overreach / Data Breach | Sovereignty | 12.0 | ELEVATED | Rising (Coinbase 2025 incident) | No | Yes | 0.10 | +| CS-FRD-01 | Pig Butchering / Financial Grooming | Financial Fraud | 20.0 | CRITICAL | Rising +50% YoY | Yes | No | 0.05 | +| CS-FRD-02 | Recovery Re-Victimization Scam | Financial Fraud | 15.5 | HIGH | Rising | Yes | No | 0.05 | +| CS-FRD-03 | Bitcoin ATM / QR Code Coercion | Financial Fraud | 15.0 | HIGH | Rising (senior targeting) | Partial | No | 0.05 | +| CS-FRD-04 | Investment Group / Fake Alpha Scam | Financial Fraud | 15.5 | HIGH | Rising | Yes | No | 0.05 | +| CS-EXT-01 | Sextortion / Blackmail / Ransomware | Extortion | 15.0 | HIGH | Stable | Partial | No | 0.05 | + +--- + +## Quick Reference: CTRS Critical Threats (Score 17.0+) + +| CTRS | Threat ID | Name | Primary Control | +|---|---|---|---| +| 20.0 | CS-FRD-01 | Pig Butchering | SMS-14 (Fee Demand Stop) | +| 20.0 | CS-SOC-06 | Forced Labor Compounds | CFD-01 (Platform Verification) | +| 19.0 | CS-WAL-04 | Malicious Signature | WKS-08 (Never sign unsolicited) | +| 19.0 | CS-SC-01 | NPM Package Hijacking | SCD-07 (Lock pinning) | +| 18.0 | CS-SC-02 | SDK/Library Poisoning | SCD-01 (SBOM) | +| 18.0 | CS-SC-03 | CI/CD Compromise | SCD-03 (Secret isolation) | +| 18.0 | CS-AI-02 | Prompt Injection | AAS-03 (Immutable instructions) | +| 17.5 | CS-MAL-02 | InfoStealer/RAT | EDD-01 (Kernel default-deny) | +| 17.5 | CS-DFI-03 | Bridge Exploit | OCM-07 (Bridge risk matrix) | +| 17.5 | CS-SC-04 | AI Model Backdoor | SCD-08 (Model provenance) | +| 17.5 | CS-AI-01 | Memory Poisoning | AAS-02 (Memory integrity) | +| 17.5 | CS-AI-04 | AI Swarm Attack | AAS-10 (Swarm isolation) | +| 17.5 | CS-MKT-02 | Tokenomics Weaponization | SMS-10 (Rotator Effect analysis) | +| 17.0 | CS-INS-01 | Admin Key Abuse | WKS-02 + WKS-03 (Multisig + Timelock) | +| 17.0 | CS-INS-03 | DPRK Wagemole | Personnel vetting + WKS-02 | +| 17.0 | CS-WAL-03 | DNS/Frontend Hijack | SMS-05 + SMS-11 (URL verification) | + +--- + +## Column Definitions + +| Column | Definition | +|---|---| +| CTRS | Crypto Threat Risk Score (0-20). Formula: `(L×0.25 + I×0.30 + R×0.20 + D×0.15 + RecD×0.10) × 20` | +| Trend | Observed trajectory of this threat category in 2024-2026 | +| AI-Assisted | Whether AI tools are meaningfully used to scale, personalize, or enhance this attack | +| Insider Vector | Whether insider access is required or significantly increases probability | +| False Flag Prob | Probability that official attribution post-incident does not reflect primary responsible actor (0.0-1.0) | + +Full methodology: [ctrs-scoring.md](ctrs-scoring.md) | Full architecture: [threat-architecture.md](threat-architecture.md) + +--- + +*Threat Registry Table | CSI CryptoSHIELD Framework v1.1 | Auto-generated from registry.json* +*Cyber Strategy Institute | Open-Source | Sovereignty-First* diff --git a/taxonomy/registry.json b/taxonomy/registry.json new file mode 100644 index 0000000..0c47586 --- /dev/null +++ b/taxonomy/registry.json @@ -0,0 +1,1685 @@ +{ + "schema_version": "1.1", + "framework": "CSI CryptoSHIELD", + "last_updated": "2026-05-17", + "total_threats": 42, + "threat_categories": [ + "Physical", + "Insider", + "Social Engineering", + "Malware", + "Wallet", + "DeFi Protocol", + "Supply Chain", + "AI Agent", + "Market Manipulation", + "Financial Fraud", + "Sovereignty", + "Extortion" + ], + "threats": [ + { + "id": "CS-PHY-01", + "name": "Physical Kidnapping and Coercion", + "category": "Physical", + "subcategory": "Kidnapping", + "description": "OSINT-enabled targeting of crypto holders for physical coercion to force fund transfers at gunpoint or through torture.", + "attack_vectors": [ + "OSINT profiling", + "social media monitoring", + "on-chain wealth attribution", + "physical surveillance" + ], + "ooda_phase": "act", + "severity": "CRITICAL", + "ctrs_score": 15.0, + "trend": "increasing", + "trend_pct": 75, + "trend_period": "2024-2025", + "scale_2025": "72 incidents, $40.9M losses", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.1, + "sovereignty_impact": "CRITICAL", + "self_custody_relevant": true, + "deterministic_defense": [ + "OPS-01", + "OPS-02", + "OPS-05", + "OPS-06", + "OPS-10" + ], + "mitre_attack": [ + "T1591", + "T1589" + ], + "tags": [ + "wrench_attack", + "physical", + "osint", + "coercion", + "kidnapping" + ], + "references": [ + "CertiK Skynet Wrench Attacks Report Feb 2026", + "CSI Issue 46", + "DOJ-2025-MN-KID" + ], + "notable_cases": [ + "Ledger co-founder David Balland Jan 2025 ($10M ransom)", + "Minnesota September 2025 ($8M coerced transfer)" + ] + }, + { + "id": "CS-PHY-02", + "name": "Home Invasion and Physical Assault", + "category": "Physical", + "subcategory": "Home Invasion", + "description": "Targeted home invasions and street assaults of known or suspected crypto holders identified through OSINT and social media profiling.", + "attack_vectors": [ + "social media profiling", + "luxury flex identification", + "address discovery via OSINT" + ], + "ooda_phase": "act", + "severity": "CRITICAL", + "ctrs_score": 15.0, + "trend": "increasing", + "trend_pct": 250, + "trend_period": "2024-2025", + "scale_2025": "Included in 72 wrench attack total; physical assaults +250%", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.05, + "sovereignty_impact": "CRITICAL", + "self_custody_relevant": true, + "deterministic_defense": [ + "OPS-01", + "OPS-04", + "OPS-07", + "OPS-08", + "OPS-09" + ], + "tags": [ + "wrench_attack", + "physical", + "home_invasion", + "osint" + ], + "references": [ + "CertiK Skynet 2026", + "CSI Issue 44", + "France 19 incidents 2025" + ] + }, + { + "id": "CS-INS-01", + "name": "Admin Key Abuse by Trusted Developer", + "category": "Insider", + "subcategory": "Admin Key Exploitation", + "description": "Trusted developer or admin exploits privileged access to drain protocol funds, often through backdoored functions deployed weeks or months before exploit day.", + "attack_vectors": [ + "smart contract backdoor", + "malicious admin function", + "multisig compromise via device malware" + ], + "ooda_phase": "all", + "severity": "CRITICAL", + "ctrs_score": 17.0, + "trend": "persistent", + "scale_2025": "Radiant Capital $50M (Oct 2024), LNDFi $1.18M (May 2025)", + "insider_vector": true, + "ai_assisted": false, + "false_flag_probability": 0.6, + "sovereignty_impact": "HIGH", + "self_custody_relevant": false, + "fall_guy_pattern": true, + "capital_rotation_sig": true, + "deterministic_defense": [ + "WKS-02", + "WKS-03", + "WKS-05", + "SCD-10" + ], + "tags": [ + "insider", + "admin_key", + "multisig_masquerade", + "backdoor", + "fall_guy" + ], + "references": [ + "Radiant Capital $50M executive summary CSI", + "LNDFi analysis CSI", + "BrincFi 2021" + ], + "notable_cases": [ + "LNDFi: 5-word code change 41 days before exploit granting 'Pool Admin' drain capability", + "Radiant: malware on 3 developer devices, Safe{Wallet} display manipulation" + ] + }, + { + "id": "CS-INS-02", + "name": "CEX Customer Support Bribery", + "category": "Insider", + "subcategory": "Employee Bribery", + "description": "Overseas customer support contractors bribed to leak user PII including names, addresses, phone numbers, and government IDs for use in targeted physical and social engineering attacks.", + "attack_vectors": [ + "financial incentive", + "contractor access", + "KYC data exfiltration" + ], + "ooda_phase": "orient", + "severity": "HIGH", + "ctrs_score": 14.5, + "trend": "new", + "scale_2025": "Coinbase: $400M remediation cost, data used for targeted fraud", + "insider_vector": true, + "ai_assisted": false, + "false_flag_probability": 0.15, + "sovereignty_impact": "HIGH", + "self_custody_relevant": false, + "deterministic_defense": [ + "GCS-04", + "OPS-01", + "GCS-05" + ], + "tags": [ + "insider", + "cex", + "data_breach", + "kyc_leak", + "bribery" + ], + "references": [ + "Coinbase May 2025 disclosure", + "CSI Issue 43" + ] + }, + { + "id": "CS-INS-03", + "name": "DPRK Wagemole Infiltration", + "category": "Insider", + "subcategory": "Identity Fraud Employment", + "description": "DPRK operatives fabricate Western identities and are hired into legitimate crypto companies as developers or contractors, gaining insider access to signing keys, codebases, and infrastructure.", + "attack_vectors": [ + "fake LinkedIn identity", + "forged credentials", + "fake GitHub history", + "deepfake video interviews" + ], + "ooda_phase": "decide_act", + "severity": "CRITICAL", + "ctrs_score": 17.0, + "trend": "increasing", + "scale_2025": "$2.02B attributed to DPRK-linked actors 2025; primary vector is Wagemole", + "insider_vector": true, + "ai_assisted": true, + "ai_attack_type": "AI-generated identity documents and deepfake interview video", + "false_flag_probability": 0.4, + "sovereignty_impact": "HIGH", + "self_custody_relevant": false, + "capital_rotation_sig": false, + "deterministic_defense": [ + "SCD-05", + "GCS-06", + "SCD-10" + ], + "tags": [ + "insider", + "dprk", + "wagemole", + "identity_fraud", + "nation_state" + ], + "references": [ + "TraderTraitor/Lazarus analysis", + "Drift Protocol April 2026", + "CSI DPRK attribution research note 003" + ], + "notable_cases": [ + "Drift Protocol April 2026: 6-month fake employee, $285M", + "KelpDAO March 2026: $292M via bridge design flaw post-infiltration" + ] + }, + { + "id": "CS-SOC-01", + "name": "AI-Enhanced Phishing", + "category": "Social Engineering", + "subcategory": "Phishing", + "description": "AI-generated phishing messages with zero detectable spelling or grammatical errors, personalized to target using scraped social data, delivered via email, Discord, X, and Telegram.", + "attack_vectors": [ + "email", + "Discord DM", + "X DM", + "Telegram" + ], + "ooda_phase": "observe", + "severity": "HIGH", + "ctrs_score": 16.0, + "trend": "increasing", + "trend_pct": 1400, + "trend_period": "2024-2025", + "scale_2025": "AI impersonation attacks +1400% YoY", + "insider_vector": false, + "ai_assisted": true, + "ai_attack_type": "LLM-generated personalized messages; no traditional detection signals", + "false_flag_probability": 0.05, + "sovereignty_impact": "MEDIUM", + "self_custody_relevant": true, + "deterministic_defense": [ + "SMS-05", + "SMS-06", + "EDD-01" + ], + "tags": [ + "phishing", + "ai_enhanced", + "social_engineering", + "traditional_detection_failed" + ], + "references": [ + "CSI Issues 35-46", + "FBI IC3 2025" + ] + }, + { + "id": "CS-SOC-02", + "name": "Fake Hardware Wallet Mailing", + "category": "Social Engineering", + "subcategory": "Physical Package Scam", + "description": "Weaponization of the 2020 Ledger customer database breach to mail counterfeit hardware wallets with pre-seeded malicious firmware or embedded keyloggers to real customers' home addresses.", + "attack_vectors": [ + "physical mail", + "compromised customer database", + "malicious firmware" + ], + "ooda_phase": "observe", + "severity": "CRITICAL", + "ctrs_score": 15.5, + "trend": "persistent", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.02, + "sovereignty_impact": "CRITICAL", + "self_custody_relevant": true, + "deterministic_defense": [ + "WKS-01", + "EDD-10", + "GCS-04" + ], + "tags": [ + "hardware_wallet", + "fake_device", + "ledger_breach", + "physical_attack" + ], + "references": [ + "Ledger 2020 data breach", + "CSI seed phrase protection guide" + ] + }, + { + "id": "CS-SOC-03", + "name": "Fake Cryptocurrency Job Offer", + "category": "Social Engineering", + "subcategory": "Fake Job Offer", + "description": "Highly customized fake recruiter and job offer campaigns via LinkedIn and Telegram targeting Web3 developers and professionals. Malware delivered through fake 'coding assessment' repositories or meeting app installations.", + "attack_vectors": [ + "LinkedIn", + "Telegram", + "fake GitHub repo", + "fake coding test" + ], + "ooda_phase": "observe", + "severity": "HIGH", + "ctrs_score": 15.5, + "trend": "increasing", + "trend_pct": 1400, + "trend_period": "2024-2025", + "insider_vector": false, + "ai_assisted": true, + "ai_attack_type": "AI-generated recruiter personas with manufactured employment history", + "false_flag_probability": 0.1, + "sovereignty_impact": "HIGH", + "self_custody_relevant": false, + "deterministic_defense": [ + "EDD-01", + "EDD-02", + "SMS-06" + ], + "tags": [ + "fake_job", + "linkedin", + "developer_targeting", + "malware_delivery" + ], + "references": [ + "CSI fake LinkedIn article", + "DPRK developer targeting research" + ] + }, + { + "id": "CS-SOC-04", + "name": "Fake Meeting App Malware", + "category": "Social Engineering", + "subcategory": "Malware Delivery via Fake App", + "description": "Meeten and similar campaigns delivering cross-platform (Windows/macOS) malware disguised as legitimate business meeting applications, collecting wallet credentials from Ledger, Trezor, Phantom, Binance wallets plus Telegram credentials and banking data.", + "attack_vectors": [ + "Telegram DM", + "Discord DM", + "fake business meeting invitation" + ], + "ooda_phase": "observe", + "severity": "HIGH", + "ctrs_score": 15.5, + "trend": "new", + "scale_2025": "Meeten campaign: cross-platform targeting Web3 professionals", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.02, + "sovereignty_impact": "HIGH", + "self_custody_relevant": true, + "deterministic_defense": [ + "EDD-01", + "EDD-10", + "SMS-06" + ], + "tags": [ + "fake_app", + "meeten", + "credential_theft", + "web3_professional" + ], + "references": [ + "CSI Meeten article", + "CSI Issue 40" + ] + }, + { + "id": "CS-SOC-05", + "name": "AI Deepfake Impersonation", + "category": "Social Engineering", + "subcategory": "Synthetic Media", + "description": "Audio and video deepfake fabrication enabling voice/face cloning of trusted figures (executives, family members, influencers) to authorize transfers, harvest credentials, or build trust in pig butchering operations.", + "attack_vectors": [ + "video call", + "voice call", + "synthetic media injection" + ], + "ooda_phase": "observe", + "severity": "HIGH", + "ctrs_score": 15.5, + "trend": "increasing", + "trend_pct": 1400, + "trend_period": "2024-2025", + "insider_vector": false, + "ai_assisted": true, + "ai_attack_type": "Generative video/audio models; real-time deepfake synthesis", + "false_flag_probability": 0.05, + "sovereignty_impact": "HIGH", + "self_custody_relevant": true, + "deterministic_defense": [ + "CFD-08", + "SMS-07" + ], + "cognitive_threat_ref": "CSF T-CT-016 (Synthetic Identity Fabrication)", + "tags": [ + "deepfake", + "ai_generated", + "voice_clone", + "impersonation" + ], + "references": [ + "FBI IC3 2025 AI fraud category $893M", + "CSI Issue 38" + ] + }, + { + "id": "CS-SOC-06", + "name": "Forced Labor Scam Compound Operations", + "category": "Social Engineering", + "subcategory": "Industrialized Fraud", + "description": "Many fraudulent trading platforms targeting Western victims are operated by trafficked individuals held in Southeast Asian scam compounds. Operations are industrialized, persistent, and diplomatically protected, making traditional cybercrime reporting ineffective.", + "attack_vectors": [ + "industrialized social engineering", + "compartmentalized labor pools" + ], + "ooda_phase": "all", + "severity": "HIGH", + "ctrs_score": 20.0, + "trend": "persistent", + "scale_2025": "Linked to $7.2B pig butchering category; TRM Labs estimated $16.8B global peak", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.1, + "sovereignty_impact": "HIGH", + "self_custody_relevant": true, + "deterministic_defense": [ + "CFD-01", + "CFD-02" + ], + "tags": [ + "forced_labor", + "scam_compound", + "industrialized_fraud", + "geo_asia", + "pig_butchering" + ], + "references": [ + "TRM Labs 2025", + "Chainabuse ransom addresses", + "DOJ trafficking cases" + ], + "policy_note": "Requires State Dept/DOJ engagement; individual controls reduce victimization but cannot dismantle operations" + }, + { + "id": "CS-SOC-07", + "name": "Typosquatting and Domain Impersonation", + "category": "Social Engineering", + "subcategory": "Domain Fraud", + "description": "Automated registration of hundreds of near-identical domain permutations for crypto exchanges, wallets, and DeFi frontends. Deployed via search engine ad injection and shared links.", + "attack_vectors": [ + "search engine ads", + "link sharing", + "copy-paste URL errors" + ], + "ooda_phase": "observe", + "severity": "HIGH", + "ctrs_score": 15.0, + "trend": "persistent", + "scale_2025": "9,221 scam URLs tracked in CryptoScamDB; 4,183 registered addresses", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.02, + "sovereignty_impact": "MEDIUM", + "self_custody_relevant": true, + "deterministic_defense": [ + "SMS-05", + "SMS-11", + "SMS-09" + ], + "tags": [ + "typosquatting", + "domain_impersonation", + "fake_exchange", + "search_ad_fraud" + ], + "references": [ + "CryptoScamDB 9,221 entries", + "DFPI VanguardTrade/Okred cases" + ] + }, + { + "id": "CS-MAL-01", + "name": "Clipboard Hijacking (MassJacker Pattern)", + "category": "Malware", + "subcategory": "Clipboard Hijack", + "description": "Malware intercepts clipboard contents and substitutes attacker-controlled wallet addresses when a victim copies an address to paste into a transaction. MassJacker used 778,531 addresses.", + "attack_vectors": [ + "pirated software", + "drive-by download", + "trojanized installer" + ], + "ooda_phase": "act", + "severity": "HIGH", + "ctrs_score": 16.0, + "trend": "widespread", + "scale_2025": "MassJacker: 778,531 wallet addresses; one Solana wallet accumulated $300K+", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.02, + "sovereignty_impact": "HIGH", + "self_custody_relevant": true, + "deterministic_defense": [ + "EDD-04", + "EDD-01", + "EDD-03" + ], + "tags": [ + "clipboard_hijack", + "massjacker", + "transaction_redirect", + "pirated_software" + ], + "references": [ + "CSI MassJacker article", + "CSI Issue 36" + ] + }, + { + "id": "CS-MAL-02", + "name": "InfoStealer and Remote Access Trojan", + "category": "Malware", + "subcategory": "InfoStealer", + "description": "InfoStealer and RAT malware delivered through fake job offers, gaming clients, and social engineering, targeting browser-stored credentials, crypto wallet data, and signing keys.", + "attack_vectors": [ + "job offer download", + "gaming malware", + "fake update" + ], + "ooda_phase": "act", + "severity": "HIGH", + "ctrs_score": 17.5, + "trend": "widespread", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.05, + "sovereignty_impact": "HIGH", + "self_custody_relevant": true, + "deterministic_defense": [ + "EDD-01", + "EDD-02", + "EDD-03" + ], + "tags": [ + "infostealer", + "rat", + "credential_theft", + "developer_targeting" + ], + "references": [ + "CSI crypto dev teams targeted article", + "CSI Issues 39-41" + ] + }, + { + "id": "CS-MAL-03", + "name": "Fake Cloudflare / DEX Verification Page", + "category": "Malware", + "subcategory": "Drive-by Malware", + "description": "Malicious sites impersonating Cloudflare security checks or DEX information pages that execute PowerShell commands or download malware when the user 'verifies' they are human.", + "attack_vectors": [ + "fake CAPTCHA", + "DEX info page impersonation", + "PowerShell execution" + ], + "ooda_phase": "act", + "severity": "HIGH", + "ctrs_score": 15.5, + "trend": "new", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.02, + "sovereignty_impact": "HIGH", + "self_custody_relevant": true, + "deterministic_defense": [ + "EDD-01", + "EDD-05", + "SMS-05" + ], + "tags": [ + "fake_cloudflare", + "powershell", + "drive_by", + "dex_impersonation" + ], + "references": [ + "CSI Issues 41-43" + ] + }, + { + "id": "CS-WAL-01", + "name": "Seed Phrase Extraction", + "category": "Wallet", + "subcategory": "Seed Phrase Theft", + "description": "Social engineering, malware, or physical access used to extract wallet seed phrases or private keys. Once extracted, all funds are permanently lost with no recovery mechanism.", + "attack_vectors": [ + "social engineering", + "malware", + "physical access", + "cloud sync intercept", + "fake support contact" + ], + "ooda_phase": "act", + "severity": "CRITICAL", + "ctrs_score": 16.0, + "trend": "persistent", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.05, + "sovereignty_impact": "CRITICAL", + "self_custody_relevant": true, + "deterministic_defense": [ + "WKS-04", + "WKS-01", + "EDD-02" + ], + "tags": [ + "seed_phrase", + "private_key", + "wallet_drain", + "irreversible" + ], + "references": [ + "CSI seed phrase protection guide", + "CSI crypto wallets under siege article" + ] + }, + { + "id": "CS-WAL-02", + "name": "Address Poisoning", + "category": "Wallet", + "subcategory": "Transaction History Manipulation", + "description": "Attacker sends dust transactions from vanity addresses resembling the victim's frequently-used addresses, poisoning transaction history so copy-paste future transactions redirect to attacker wallet.", + "attack_vectors": [ + "vanity address generation", + "on-chain dust transaction injection" + ], + "ooda_phase": "orient", + "severity": "MEDIUM", + "ctrs_score": 16.5, + "trend": "increasing", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.02, + "sovereignty_impact": "MEDIUM", + "self_custody_relevant": true, + "deterministic_defense": [ + "OCM-06", + "WKS-06", + "EDD-04" + ], + "tags": [ + "address_poisoning", + "dust_attack", + "transaction_redirect", + "copy_paste" + ], + "references": [ + "CSI permit scams article", + "CSI Issues 33-35" + ] + }, + { + "id": "CS-WAL-03", + "name": "DNS Hijack / Frontend Compromise", + "category": "Wallet", + "subcategory": "Frontend Attack", + "description": "Compromise of DNS records or frontend hosting for legitimate DeFi protocols, redirecting users to malicious frontends that drain wallets through approval requests.", + "attack_vectors": [ + "DNS registrar compromise", + "CDN compromise", + "npm supply chain compromise of frontend" + ], + "ooda_phase": "decide", + "severity": "HIGH", + "ctrs_score": 17.0, + "trend": "recurring", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.1, + "sovereignty_impact": "HIGH", + "self_custody_relevant": true, + "deterministic_defense": [ + "SMS-05", + "OCM-01", + "SMS-09" + ], + "tags": [ + "dns_hijack", + "frontend_compromise", + "dex_attack" + ], + "references": [ + "Ledger Connect Kit compromise", + "ThirdWeb compromise", + "CSI Issues 34-38" + ] + }, + { + "id": "CS-WAL-04", + "name": "Malicious Signature / Permit Drain", + "category": "Wallet", + "subcategory": "Approval Exploit", + "description": "User tricked into signing malicious ERC-20 approvals, EIP-2612 permit requests, or EIP-712 structured data that grants unlimited token spend authority to attacker contracts.", + "attack_vectors": [ + "phishing link", + "DNS hijacked frontend", + "malicious dApp" + ], + "ooda_phase": "act", + "severity": "HIGH", + "ctrs_score": 19.0, + "trend": "persistent", + "scale_2025": "68% of all wallet drain losses via malicious signature", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.02, + "sovereignty_impact": "CRITICAL", + "self_custody_relevant": true, + "deterministic_defense": [ + "WKS-05", + "WKS-08", + "OCM-10", + "OCM-01" + ], + "tags": [ + "permit_scam", + "approval_drain", + "eip_2612", + "blind_signing" + ], + "references": [ + "CSI permit scams article", + "CSI top 10 wallet draining vectors", + "68% loss statistic" + ] + }, + { + "id": "CS-WAL-05", + "name": "Low Entropy Seed Generation", + "category": "Wallet", + "subcategory": "Cryptographic Weakness", + "description": "Compromised or low-quality wallet applications generating predictable seed phrases due to poor entropy sources, enabling brute-force discovery of private keys.", + "attack_vectors": [ + "compromised wallet application", + "entropy vulnerability" + ], + "ooda_phase": "decide", + "severity": "HIGH", + "ctrs_score": 14.5, + "trend": "niche", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.2, + "sovereignty_impact": "CRITICAL", + "self_custody_relevant": true, + "deterministic_defense": [ + "WKS-01", + "EDD-10", + "GCS-08" + ], + "tags": [ + "low_entropy", + "seed_generation", + "brute_force", + "wallet_app" + ], + "references": [ + "Profanity vulnerability analysis", + "Randstorm vulnerability" + ] + }, + { + "id": "CS-DFI-01", + "name": "Admin Key Exploit via Access Control Failure", + "category": "DeFi Protocol", + "subcategory": "Admin Key Compromise", + "description": "Exploitation of admin key access controls in DeFi protocols \u2014 through insider compromise, multisig manipulation, or device malware \u2014 to drain protocol treasuries.", + "attack_vectors": [ + "device malware on key holders", + "multisig manipulation", + "Safe{Wallet} display spoofing" + ], + "ooda_phase": "act", + "severity": "CRITICAL", + "ctrs_score": 16.5, + "trend": "increasing", + "scale_2025": "Private key compromise = 43.8% of incidents by count; DefiLlama", + "insider_vector": true, + "ai_assisted": false, + "false_flag_probability": 0.5, + "sovereignty_impact": "HIGH", + "fall_guy_pattern": true, + "deterministic_defense": [ + "WKS-02", + "WKS-03", + "WKS-05", + "SCD-10" + ], + "defillama_category": "Private Key", + "tags": [ + "admin_key", + "multisig_masquerade", + "access_control", + "protocol_drain" + ], + "references": [ + "Radiant Capital $50M Oct 2024", + "DefiLlama 43.8% private key stat" + ] + }, + { + "id": "CS-DFI-02", + "name": "Flash Loan Attack", + "category": "DeFi Protocol", + "subcategory": "Economic Exploit", + "description": "Uncollateralized flash loans used to temporarily manipulate market conditions, oracle prices, or governance votes, enabling profit extraction in a single atomic transaction.", + "attack_vectors": [ + "AMM liquidity manipulation", + "oracle price distortion", + "governance vote manipulation" + ], + "ooda_phase": "act", + "severity": "HIGH", + "ctrs_score": 14.5, + "trend": "periodic", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.1, + "sovereignty_impact": "MEDIUM", + "deterministic_defense": [ + "AAS-09", + "OCM-04" + ], + "defillama_category": "Flash Loan", + "tags": [ + "flash_loan", + "amm_manipulation", + "oracle_attack", + "atomic_exploit" + ], + "references": [ + "CSI AMM article", + "CSI Issues 28-32" + ] + }, + { + "id": "CS-DFI-03", + "name": "Cross-Chain Bridge Exploit", + "category": "DeFi Protocol", + "subcategory": "Bridge Vulnerability", + "description": "Exploitation of design flaws in cross-chain bridge architecture \u2014 predominantly single-verifier designs \u2014 enabling unauthorized minting or withdrawal of bridged assets.", + "attack_vectors": [ + "single-verifier spoofing", + "validator key compromise", + "message verification bypass" + ], + "ooda_phase": "act", + "severity": "CRITICAL", + "ctrs_score": 17.5, + "trend": "persistent", + "scale_2025": "$2.88B cumulative bridge losses (DefiLlama lifetime); $577M 2026 YTD", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.3, + "sovereignty_impact": "HIGH", + "deterministic_defense": [ + "OCM-07" + ], + "defillama_category": "Bridge", + "tags": [ + "bridge_exploit", + "single_verifier", + "cross_chain", + "layerzero" + ], + "references": [ + "KelpDAO $292M March 2026", + "DefiLlama bridge total $2.88B", + "CSI Issues 43-46" + ], + "notable_cases": [ + "KelpDAO $292M: LayerZero single-verifier design flaw" + ] + }, + { + "id": "CS-DFI-04", + "name": "Oracle Price Manipulation", + "category": "DeFi Protocol", + "subcategory": "Oracle Attack", + "description": "Manipulation of on-chain price oracles to create artificial price discrepancies exploitable through lending protocols, perpetuals, or liquidation mechanisms.", + "attack_vectors": [ + "spot price manipulation", + "oracle latency exploitation", + "thin liquidity poisoning" + ], + "ooda_phase": "act", + "severity": "HIGH", + "ctrs_score": 14.5, + "trend": "persistent", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.1, + "sovereignty_impact": "MEDIUM", + "deterministic_defense": [ + "AAS-09", + "OCM-08" + ], + "tags": [ + "oracle_manipulation", + "price_feed", + "liquidation_exploit" + ], + "references": [ + "CSI Issues 22-28" + ] + }, + { + "id": "CS-DFI-05", + "name": "Reentrancy and Smart Contract Logic Exploit", + "category": "DeFi Protocol", + "subcategory": "Smart Contract Bug", + "description": "Classic and complex smart contract vulnerabilities enabling unexpected execution paths, reentrancy loops, or logic bypasses in DeFi protocol code.", + "attack_vectors": [ + "reentrancy", + "integer overflow", + "access control bypass", + "logic error" + ], + "ooda_phase": "act", + "severity": "HIGH", + "ctrs_score": 11.5, + "trend": "declining", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.05, + "sovereignty_impact": "MEDIUM", + "deterministic_defense": [ + "OCM-08", + "SCD-10" + ], + "defillama_category": "Smart Contract", + "tags": [ + "reentrancy", + "smart_contract_bug", + "logic_exploit" + ], + "references": [ + "DefiLlama smart contract category", + "OWASP Top 10 for Web3" + ] + }, + { + "id": "CS-SC-01", + "name": "NPM Package Hijacking", + "category": "Supply Chain", + "subcategory": "Package Repository Attack", + "description": "Compromise of npm package maintainer accounts through targeted phishing, then publishing malicious versions that redirect cryptocurrency transactions or exfiltrate wallet data.", + "attack_vectors": [ + "maintainer account phishing", + "dependency confusion", + "typosquatted package names" + ], + "ooda_phase": "orient", + "severity": "CRITICAL", + "ctrs_score": 19.0, + "trend": "increasing", + "scale_2025": "Shai-Hulud worm: 500+ packages including chalk, debug, ansi-styles (2.6B weekly downloads)", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.1, + "sovereignty_impact": "CRITICAL", + "deterministic_defense": [ + "SCD-01", + "SCD-02", + "SCD-07" + ], + "tags": [ + "npm_hijack", + "supply_chain", + "shai_hulud", + "package_poison" + ], + "references": [ + "CSI hijacked npm packages article", + "Shai-Hulud September 2025", + "CSI Issues 40-42" + ] + }, + { + "id": "CS-SC-02", + "name": "SDK and Framework Poisoning", + "category": "Supply Chain", + "subcategory": "SDK Compromise", + "description": "Compromise of foundational Web3 SDKs and frameworks through maintainer account takeover or dependency injection, creating cascading security failures across all downstream applications.", + "attack_vectors": [ + "SDK maintainer compromise", + "dependency injection", + "CDN poisoning" + ], + "ooda_phase": "orient", + "severity": "CRITICAL", + "ctrs_score": 18.0, + "trend": "growing", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.1, + "sovereignty_impact": "CRITICAL", + "deterministic_defense": [ + "SCD-01", + "SCD-02", + "SCD-07" + ], + "tags": [ + "sdk_compromise", + "framework_poison", + "cascade_failure" + ], + "references": [ + "ThirdWeb compromise", + "Ledger Connect Kit compromise", + "CSI Issues 25-30" + ] + }, + { + "id": "CS-SC-03", + "name": "CI/CD Pipeline Compromise", + "category": "Supply Chain", + "subcategory": "Build Pipeline", + "description": "Compromise of continuous integration/deployment pipelines to inject malicious code during the build process, before runtime security controls activate.", + "attack_vectors": [ + "exposed CI secrets", + "GitHub Actions compromise", + "build server access" + ], + "ooda_phase": "decide", + "severity": "CRITICAL", + "ctrs_score": 18.0, + "trend": "growing", + "insider_vector": true, + "ai_assisted": false, + "false_flag_probability": 0.2, + "sovereignty_impact": "CRITICAL", + "deterministic_defense": [ + "SCD-03", + "SCD-01", + "SCD-10" + ], + "tags": [ + "ci_cd", + "build_pipeline", + "github_actions", + "secret_exposure" + ], + "references": [ + "Ultralytics YOLO11 GitHub Actions compromise", + "CSI Issues 42-44" + ] + }, + { + "id": "CS-SC-04", + "name": "AI Model Backdoor", + "category": "Supply Chain", + "subcategory": "ML Model Poisoning", + "description": "Compromise of AI model distribution channels (PyPI, Hugging Face, npm) to embed backdoors in ML models, enabling malicious behavior on specific trigger inputs.", + "attack_vectors": [ + "model repository compromise", + "poisoned training data", + "supply chain injection" + ], + "ooda_phase": "decide", + "severity": "HIGH", + "ctrs_score": 17.5, + "trend": "new", + "insider_vector": false, + "ai_assisted": true, + "false_flag_probability": 0.2, + "sovereignty_impact": "HIGH", + "deterministic_defense": [ + "SCD-08", + "SCD-01" + ], + "ai_safe2_ref": "AI SAFE\u00b2 CP.5 Platform-Specific Profiles; SCD-08 AI Model Provenance", + "tags": [ + "ai_model_backdoor", + "ml_poison", + "supply_chain", + "pytorch" + ], + "references": [ + "Ultralytics YOLO11 supply chain attack via GitHub Actions and PyPI" + ] + }, + { + "id": "CS-AI-01", + "name": "AI Agent Memory Poisoning", + "category": "AI Agent", + "subcategory": "Vector Database Attack", + "description": "Injection of malicious instructions into an AI agent's vector database (long-term memory store), creating 'sleeper' agents that activate on specific market conditions or trigger inputs to execute unauthorized transactions.", + "attack_vectors": [ + "vector DB write injection", + "RAG corpus poisoning", + "long-term memory manipulation" + ], + "ooda_phase": "decide", + "severity": "CRITICAL", + "ctrs_score": 17.5, + "trend": "2026_emerging", + "insider_vector": false, + "ai_assisted": true, + "ai_attack_type": "Vector database manipulation enabling persistent behavioral modification", + "false_flag_probability": 0.3, + "sovereignty_impact": "CRITICAL", + "ai_safe2_ref": "AI SAFE\u00b2 S1.5 Memory Governance; A2.6 RAG Corpus Diff Tracking; P1 Pillar", + "deterministic_defense": [ + "AAS-02", + "AAS-03" + ], + "tags": [ + "memory_poisoning", + "vector_db", + "sleeper_agent", + "rag_attack" + ], + "references": [ + "AI SAFE\u00b2 v3.0 S1.5", + "Freysa exploit analysis", + "CSI AI threats article" + ] + }, + { + "id": "CS-AI-02", + "name": "Prompt Injection / Logic Redefinition", + "category": "AI Agent", + "subcategory": "Prompt Injection", + "description": "Crafted inputs that override or redefine an AI agent's core instructions. The Freysa exploit demonstrated that an agent with a hardcoded 'never transfer funds' directive can be convinced to release funds by redefining its function logic.", + "attack_vectors": [ + "crafted user message", + "external data injection", + "tool call manipulation" + ], + "ooda_phase": "decide", + "severity": "HIGH", + "ctrs_score": 18.0, + "trend": "demonstrated", + "insider_vector": false, + "ai_assisted": true, + "false_flag_probability": 0.1, + "sovereignty_impact": "HIGH", + "ai_safe2_ref": "AI SAFE\u00b2 P1 Sanitize and Isolate; S1.1-S1.4 injection controls", + "deterministic_defense": [ + "AAS-03", + "AAS-08" + ], + "tags": [ + "prompt_injection", + "logic_redefinition", + "freysa", + "agent_manipulation" + ], + "references": [ + "Freysa exploit analysis", + "OWASP LLM01", + "AI SAFE\u00b2 P1" + ] + }, + { + "id": "CS-AI-03", + "name": "Data Chain Poisoning via Runtime Browsing", + "category": "AI Agent", + "subcategory": "Data Chain Attack", + "description": "Placing malicious instructions in publicly accessible data sources (GitHub README, documentation pages) that AI agents fetch during runtime browsing, causing the agent to incorporate attacker instructions into generated code or decisions.", + "attack_vectors": [ + "malicious GitHub content", + "poisoned documentation", + "SEO-targeted adversarial pages" + ], + "ooda_phase": "decide", + "severity": "HIGH", + "ctrs_score": 15.0, + "trend": "active", + "insider_vector": false, + "ai_assisted": true, + "false_flag_probability": 0.1, + "sovereignty_impact": "HIGH", + "ai_safe2_ref": "AI SAFE\u00b2 A2.6 RAG Corpus Diff Tracking; S1.1 Input Validation", + "deterministic_defense": [ + "AAS-03", + "AAS-02" + ], + "tags": [ + "data_chain_poison", + "runtime_browsing", + "rag_attack", + "github_poison" + ], + "references": [ + "ChatGPT real-time browsing private key theft via GitHub", + "AI SAFE\u00b2 research note 003" + ] + }, + { + "id": "CS-AI-04", + "name": "AI Swarm Coordinated Attack", + "category": "AI Agent", + "subcategory": "Autonomous Swarm Attack", + "description": "Autonomous AI agent swarms coordinating simultaneous attacks across multiple targets with 80-90% human-out-of-loop operation. GTG-1002 (November 2025) confirmed operational capability across 30 organizations simultaneously.", + "attack_vectors": [ + "coordinated autonomous agents", + "distributed reconnaissance", + "parallel exploit execution" + ], + "ooda_phase": "act", + "severity": "CRITICAL", + "ctrs_score": 17.5, + "trend": "operational_2026", + "scale_2025": "GTG-1002: 30 organizations simultaneously, 80-90% autonomous", + "insider_vector": false, + "ai_assisted": true, + "ai_attack_type": "Autonomous multi-agent coordination with minimal human oversight", + "false_flag_probability": 0.3, + "sovereignty_impact": "CRITICAL", + "ai_safe2_ref": "AI SAFE\u00b2 CP.9 Agent Replication Governance; F3.2-F3.5 Kill Switch Suite; CP.4 Agentic Control Plane", + "deterministic_defense": [ + "AAS-10", + "AAS-06", + "AAS-08" + ], + "tags": [ + "swarm_attack", + "autonomous_agent", + "gtg_1002", + "mass_coordination" + ], + "references": [ + "GTG-1002 November 2025", + "AI SAFE\u00b2 CP.9", + "CSI AI threats article" + ] + }, + { + "id": "CS-AI-05", + "name": "Synthetic Identity and AI Document Fraud", + "category": "AI Agent", + "subcategory": "Generative AI Identity Fraud", + "description": "AI-generated synthetic identities, forged government IDs for KYC bypass, AI voice cloning for phone-based coercion, and AI-generated 'proof of profit' screenshots used to bait victims.", + "attack_vectors": [ + "generative AI documents", + "voice cloning", + "synthetic biometrics for liveness defeat", + "deepfake video proof" + ], + "ooda_phase": "orient", + "severity": "HIGH", + "ctrs_score": 15.5, + "trend": "growing", + "scale_2025": "FBI IC3 2025: $893M AI-enabled fraud (first dedicated category)", + "insider_vector": false, + "ai_assisted": true, + "ai_attack_type": "Multimodal generative AI: text, voice, video, document synthesis", + "false_flag_probability": 0.05, + "sovereignty_impact": "HIGH", + "cognitive_threat_ref": "CSF T-CT-016 (Synthetic Identity Fabrication)", + "deterministic_defense": [ + "CFD-08", + "SMS-07" + ], + "tags": [ + "synthetic_identity", + "ai_document_fraud", + "kyc_bypass", + "voice_clone", + "deepfake" + ], + "references": [ + "FBI IC3 2025 AI category $893M", + "DFPI cases with AI-generated personas" + ] + }, + { + "id": "CS-MKT-01", + "name": "MEV and Sandwich Attack", + "category": "Market Manipulation", + "subcategory": "Maximal Extractable Value", + "description": "Miner/Maximal Extractable Value bots front-running and sandwiching retail trades in the mempool, transferring value from ordinary holders to sophisticated MEV operators.", + "attack_vectors": [ + "mempool monitoring", + "transaction ordering manipulation", + "front-run bots" + ], + "ooda_phase": "act", + "severity": "HIGH", + "ctrs_score": 15.5, + "trend": "systemic", + "insider_vector": false, + "ai_assisted": true, + "capital_rotation_sig": true, + "deterministic_defense": [ + "OCM-04", + "OCM-05" + ], + "tags": [ + "mev", + "sandwich_attack", + "front_run", + "mempool", + "value_extraction" + ], + "references": [ + "CSI Ethereum gas fees and mempool articles", + "CSI Rotator Effect research" + ] + }, + { + "id": "CS-MKT-02", + "name": "Tokenomics Weaponization", + "category": "Market Manipulation", + "subcategory": "Engineered Token Distribution", + "description": "VC-controlled token distributions (50-70%+ held by insiders) with minimal public float, creating engineered pump-and-dump cycles where retail provides exit liquidity for coordinated insider sells.", + "attack_vectors": [ + "token distribution design", + "cliff vesting manipulation", + "low float launch" + ], + "ooda_phase": "all", + "severity": "HIGH", + "ctrs_score": 17.5, + "trend": "structural", + "insider_vector": true, + "capital_rotation_sig": true, + "fall_guy_pattern": true, + "deterministic_defense": [ + "SMS-10" + ], + "tags": [ + "tokenomics", + "pump_dump", + "vc_dump", + "low_float", + "rotator_effect" + ], + "references": [ + "CSI Rotator Effect research note 002", + "CSI Crypto Rotator Sagas article" + ] + }, + { + "id": "CS-MKT-03", + "name": "Coordinated Influence Operation", + "category": "Market Manipulation", + "subcategory": "Narrative Manipulation", + "description": "Synchronized narrative deployment across Crypto Twitter and YouTube to drive retail into specific positions benefiting orchestrating parties. FUD as a weapon to shift liquidity to controlled alternatives.", + "attack_vectors": [ + "influencer coordination", + "paid narrative deployment", + "FUD amplification" + ], + "ooda_phase": "orient", + "severity": "MEDIUM", + "ctrs_score": 13.5, + "trend": "persistent", + "capital_rotation_sig": true, + "fall_guy_pattern": true, + "cognitive_threat_ref": "CSF T-CT-003 (Algorithmic Amplification); T-CT-004 (Personalized Narrative Injection)", + "deterministic_defense": [ + "SMS-10", + "CFD-09" + ], + "tags": [ + "influence_operation", + "fud", + "narrative_manipulation", + "influencer_coordination", + "rotator_effect" + ], + "references": [ + "CSI Rotator Effect research", + "CSI MrBeast article", + "CSI elliotrades debate article" + ] + }, + { + "id": "CS-FRD-01", + "name": "Pig Butchering / Financial Grooming", + "category": "Financial Fraud", + "subcategory": "Long-Duration Trust Exploitation", + "description": "Multi-week to multi-month relationship-building via dating apps and messaging platforms, followed by introduction to fraudulent trading platforms. Small initial 'profitable' withdrawals build trust before escalating deposits and sudden withdrawal blocks with escalating fee demands.", + "attack_vectors": [ + "dating apps", + "WhatsApp/Telegram DM", + "fake trading platform", + "investment group" + ], + "ooda_phase": "observe", + "severity": "CRITICAL", + "ctrs_score": 20.0, + "trend": "growing", + "scale_2025": "$7.2B in U.S. losses alone (FBI IC3 2025); $16.8B global peak (TRM Labs)", + "insider_vector": false, + "ai_assisted": true, + "ai_attack_type": "AI-generated personas, deepfake video calls, AI-written messages \u2014 zero traditional error signals", + "false_flag_probability": 0.02, + "sovereignty_impact": "CRITICAL", + "self_custody_relevant": true, + "forced_labor_link": true, + "deterministic_defense": [ + "CFD-01", + "CFD-02", + "CFD-03", + "CFD-04", + "SMS-13" + ], + "cognitive_threat_ref": "CSF T-CT-004 (Personalized Narrative Injection); T-CT-007 (Trust Network Infiltration)", + "tags": [ + "pig_butchering", + "romance_scam", + "fake_platform", + "trust_bait", + "fee_escalation" + ], + "references": [ + "DFPI Scam Tracker analysis", + "FBI IC3 2025 $7.2B", + "TRM Labs 2025", + "CSI Issue 44" + ] + }, + { + "id": "CS-FRD-02", + "name": "Asset Recovery Re-Victimization", + "category": "Financial Fraud", + "subcategory": "Secondary Fraud", + "description": "After primary fraud, victims are systematically re-targeted by fake 'recovery services' promising to retrieve stolen crypto for upfront fees. No legitimate service can reverse confirmed blockchain transactions.", + "attack_vectors": [ + "proactive contact of known victims", + "search engine optimization", + "social media targeting" + ], + "ooda_phase": "orient", + "severity": "HIGH", + "ctrs_score": 15.5, + "trend": "growing", + "scale_2025": "$1.4B in U.S. losses (FBI IC3 2025)", + "insider_vector": false, + "ai_assisted": false, + "false_flag_probability": 0.02, + "sovereignty_impact": "HIGH", + "self_custody_relevant": true, + "deterministic_defense": [ + "CFD-07", + "SMS-15" + ], + "absolute_rule": "No legitimate blockchain service can reverse a confirmed transaction. All recovery fee demands are fraud.", + "tags": [ + "recovery_scam", + "re_victimization", + "secondary_fraud", + "psychological_targeting" + ], + "references": [ + "FBI IC3 2025", + "DFPI Bitboxn.com case", + "Ethereum.org scam guidance" + ] + }, + { + "id": "CS-FRD-03", + "name": "Bitcoin ATM / QR Code Coercion Fraud", + "category": "Financial Fraud", + "subcategory": "Physical Crypto Coercion", + "description": "Scammers impersonating government officials, bank representatives, or tech support convince victims to withdraw cash, visit a Bitcoin ATM, and transfer funds via QR code. Nearly 10x growth since 2020.", + "attack_vectors": [ + "phone call impersonation", + "government/bank/tech support impersonation", + "physical ATM direction" + ], + "ooda_phase": "act", + "severity": "HIGH", + "ctrs_score": 15.0, + "trend": "growing", + "scale_2025": "$333M in U.S. losses (CertiK 2025); 93% of deposits on some ATMs fraudulent", + "insider_vector": false, + "ai_assisted": true, + "primary_target": "Adults 60+, 86% of ATM losses", + "false_flag_probability": 0.02, + "sovereignty_impact": "HIGH", + "deterministic_defense": [ + "CFD-05", + "CFD-06" + ], + "absolute_rule": "No government agency, bank, or tech support will ever instruct crypto ATM transfers.", + "tags": [ + "btc_atm", + "elder_fraud", + "government_impersonation", + "physical_vector" + ], + "references": [ + "FBI IC3 2025 $247M (2024) / CertiK $333M (2025)", + "FTC Bitcoin ATM scam data" + ] + }, + { + "id": "CS-FRD-04", + "name": "Investment Group / Professor Scam", + "category": "Financial Fraud", + "subcategory": "Social Proof Exploitation", + "description": "WhatsApp/Telegram investment education groups led by fake 'professors' with AI-generated personas and social proof of other members profiting, progressively directing victims to fraudulent trading platforms.", + "attack_vectors": [ + "WhatsApp group", + "Telegram channel", + "YouTube community", + "fake education framing" + ], + "ooda_phase": "orient", + "severity": "HIGH", + "ctrs_score": 15.5, + "trend": "persistent", + "scale_2025": "Legends Smart Traders Alliance: $1.3M+ across multiple victims (single campaign)", + "insider_vector": false, + "ai_assisted": true, + "false_flag_probability": 0.02, + "sovereignty_impact": "HIGH", + "deterministic_defense": [ + "CFD-02", + "CFD-09", + "SMS-06" + ], + "cognitive_threat_ref": "CSF T-CT-005 (Social Proof Manipulation); T-CT-004 (Personalized Narrative Injection)", + "tags": [ + "professor_scam", + "investment_group", + "social_proof", + "fake_education", + "telegram" + ], + "references": [ + "DFPI Scam Tracker: Professor Bennett (Legends Smart Traders Alliance)", + "Professor Caldwell (Navivision Wealth Society)", + "Professor Govan (Stride Exchange)" + ] + }, + { + "id": "CS-SOV-01", + "name": "CBDC Surveillance Architecture", + "category": "Sovereignty", + "subcategory": "State Surveillance", + "description": "Government-controlled digital currency enabling programmable spending restrictions, transaction surveillance, account freezing, and identity-linked transaction monitoring. Antithetical to financial sovereignty.", + "attack_vectors": [ + "regulatory mandate", + "interoperability requirement", + "de-banking of alternatives" + ], + "ooda_phase": "orient", + "severity": "CRITICAL", + "ctrs_score": 15.5, + "trend": "blocked_in_us", + "regulatory_vector": true, + "insider_vector": false, + "false_flag_probability": 0.0, + "sovereignty_impact": "CRITICAL", + "deterministic_defense": [ + "GCS-02", + "WKS-01", + "GCS-01" + ], + "tags": [ + "cbdc", + "state_surveillance", + "financial_control", + "sovereignty_threat" + ], + "references": [ + "Trump Executive Order January 2025 prohibiting CBDC", + "GCS-02 CBDC resistance protocol" + ] + }, + { + "id": "CS-SOV-02", + "name": "Regulatory Overreach via CEX KYC Data", + "category": "Sovereignty", + "subcategory": "Data Exposure via Compliance", + "description": "Mandatory KYC requirements at centralized exchanges creating large databases of crypto holder identity data that become targets for breach, government subpoena, insider leakage, and use in targeted physical attacks.", + "attack_vectors": [ + "data breach", + "government subpoena", + "insider bribery (see CS-INS-02)" + ], + "ooda_phase": "observe", + "severity": "HIGH", + "ctrs_score": 12.0, + "trend": "active", + "regulatory_vector": true, + "insider_vector": false, + "false_flag_probability": 0.05, + "sovereignty_impact": "HIGH", + "deterministic_defense": [ + "GCS-04", + "OPS-02" + ], + "tags": [ + "kyc_exposure", + "regulatory_overreach", + "data_breach_vector", + "cex_risk" + ], + "references": [ + "Coinbase KYC breach May 2025", + "FinCEN CTA blocked by courts", + "Fifth Circuit Tornado Cash ruling" + ] + }, + { + "id": "CS-EXT-01", + "name": "Sextortion, Ransomware, and Crypto Blackmail", + "category": "Extortion", + "subcategory": "Crypto-Denominated Extortion", + "description": "Blackmail using threatened release of intimate images, device lockup via ransomware, or targeted personal threats demanding Bitcoin payment. Increasingly using AI-generated fake images to fabricate evidence.", + "attack_vectors": [ + "email threat", + "dating app data compromise", + "device malware", + "AI-fabricated images" + ], + "ooda_phase": "orient", + "severity": "HIGH", + "ctrs_score": 15.0, + "trend": "persistent", + "scale_2025": "$813.55M ransomware payments 2024 (Chainalysis); 110+ child sextortion reports/month (FBI)", + "insider_vector": false, + "ai_assisted": true, + "ai_attack_type": "AI-generated synthetic intimate images used as fabricated blackmail evidence", + "false_flag_probability": 0.1, + "sovereignty_impact": "HIGH", + "deterministic_defense": [ + "EDD-01", + "EDD-09" + ], + "absolute_rule": "Never pay ransomware or sextortion demands. Report to IC3 immediately. Payment funds further attacks.", + "tags": [ + "sextortion", + "ransomware", + "blackmail", + "btc_demand", + "extortion" + ], + "references": [ + "Chainalysis 2024 ransomware report $813.55M", + "FBI IC3 child sextortion stats", + "Chainabuse blackmail category" + ] + } + ] +} \ No newline at end of file diff --git a/taxonomy/threat-architecture.md b/taxonomy/threat-architecture.md new file mode 100644 index 0000000..5241c94 --- /dev/null +++ b/taxonomy/threat-architecture.md @@ -0,0 +1,208 @@ +# CryptoSHIELD Threat Architecture: Five-Layer Causal Stack + +**CSI CryptoSHIELD Framework v1.1** +Cyber Strategy Institute | Open-Source + +--- + +## Overview + +Crypto threats do not exist in isolation. They operate within a causal architecture: structural conditions create vulnerability, attack techniques exploit that vulnerability, delivery mechanisms amplify reach, and human outcomes result. Defending only at the technique layer leaves the structural conditions intact: which is why the same categories of attacks recur across market cycles, platforms, and technologies. + +The CryptoSHIELD threat architecture is modeled on the Cognitive Sovereignty Framework's five-layer causal stack, adapted for the crypto-specific threat environment. + +--- + +## The Five-Layer Stack + +``` +Layer +2: Economic & Social Outcomes + ↑ (manifests when attacks succeed) +Layer +1: Delivery & Scale Mechanisms + ↑ (amplifies and spreads attacks) +Layer 0: Attack Techniques (T-CS) + ↑ (exploits vulnerabilities) +Layer -1: Substrate Vulnerabilities (VS) + ↑ (preconditions that enable attacks) +Layer -2: Structural Drivers (SD) + (root forces generating the threat environment) +``` + +**Critical Insight:** Controls that operate only at Layer 0 (technique blocking) are permanently reactive. New techniques continuously emerge from the same Layer -2 structural drivers. Addressing Layer -1 substrate vulnerabilities is the minimum effective defense posture. + +--- + +## Layer -2: Structural Drivers (SD) + +Root forces that generate the threat environment. These cannot be eliminated by individual action, but understanding them shapes realistic threat expectations. + +| ID | Driver | Description | +|---|---|---| +| SD-001 | Irreversibility by Design | Blockchain finality means there are no chargebacks, no fraud departments, no recovery mechanisms. Every theft is permanent. This is a structural vulnerability that all other layers exploit. | +| SD-002 | Pseudonymity Asymmetry | Attackers can operate pseudonymously with very low identity risk. Defenders must often expose identity to participate in the ecosystem (CEX KYC, social media presence). | +| SD-003 | Regulatory Vacuum and Overreach | Regulatory uncertainty creates exploitable gaps (no enforcement) and illegitimate surveillance threats (overreach). Both create adversarial conditions. | +| SD-004 | Wealth Concentration Visibility | On-chain wealth is partially transparent. Large wallets are permanently identifiable OSINT targets. | +| SD-005 | Technical Complexity as Barrier | The cognitive load of safely using crypto is high. This gap is continuously exploited by social engineers, fake support, and malicious interfaces. | +| SD-006 | Speed and 24/7 Operation | Crypto markets never close. Attackers exploit timing mismatches: attacks execute at 3 AM when defenders are asleep; AI agents execute at machine speed when human review is impossible. | + +--- + +## Layer -1: Substrate Vulnerabilities (VS) + +Pre-conditions that make attacks succeed. These are addressable by individual and protocol-level action: they are the primary target of CryptoSHIELD controls. + +| ID | Vulnerability | Description | Addressing Domain | +|---|---|---|---| +| VS-001 | Key Exposure | Private keys or seed phrases stored digitally, in accessible locations, or shared with third parties | Domain 01 (WKS) | +| VS-002 | OSINT Linkage | Real-world identity linked to on-chain wealth through public data | Domain 03 (OPS) | +| VS-003 | Unverified Code Execution | Unknown or unaudited code running on devices that have crypto access | Domain 02 (EDD), Domain 06 (SCD) | +| VS-004 | Unbounded Token Approvals | Existing token approvals granting permanent, unlimited spend access to protocols | Domain 05 (OCM) | +| VS-005 | Social Trust Exploitation | Tendency to trust authority, urgency, and social proof in financial contexts | Domain 04 (SMS) | +| VS-006 | Insufficient Multisig Design | Multi-signature schemes controlled by non-independent signers; single points of failure | Domain 01 (WKS) | +| VS-007 | AI Agent Privilege Excess | AI agents holding private keys, memory with sensitive data, or unrestricted tool access | Domain 07 (AAS) | +| VS-008 | Unverified Platform Trust | Depositing funds into platforms without independent legitimacy verification | Domain 04 (SMS), Domain 09 (CFD) | +| VS-009 | Cognitive Vulnerability | Human susceptibility to emotional manipulation, fake urgency, social engineering | CSF Domain 3 (Emotional Resilience) | +| VS-010 | Supply Chain Blindspot | Dependency on third-party code that has not been audited or verified | Domain 06 (SCD) | + +--- + +## Layer 0: Attack Techniques (T-CS) + +Active exploitation techniques targeting substrate vulnerabilities. Full specifications in `taxonomy/registry.json`. + +### Physical Category (CS-PHY) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-PHY-01 | Kidnapping and Physical Coercion | VS-001, VS-002 | +| CS-PHY-02 | Home Invasion | VS-001, VS-002 | + +### Insider Threat Category (CS-INS) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-INS-01 | Admin Key Abuse by Trusted Actor | VS-006, VS-003 | +| CS-INS-02 | CEX Support Bribery | VS-008, VS-005 | +| CS-INS-03 | DPRK Wagemole Identity Infiltration | VS-006, VS-005 | + +### Social Engineering Category (CS-SOC) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-SOC-01 | Phishing | VS-005, VS-008 | +| CS-SOC-02 | Fake Hardware Wallet | VS-005, VS-001 | +| CS-SOC-03 | Fake Job Offer (Malware Delivery) | VS-005, VS-003 | +| CS-SOC-04 | Fake Meeting App | VS-005, VS-003 | +| CS-SOC-05 | AI Deepfake Impersonation | VS-005, VS-009 | +| CS-SOC-06 | Forced Labor Compound Operations | VS-005, VS-008, VS-009 | +| CS-SOC-07 | Typosquatting / Domain Impersonation | VS-005, VS-008 | + +### Malware Category (CS-MAL) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-MAL-01 | Clipboard Hijacking | VS-003, VS-005 | +| CS-MAL-02 | InfoStealer / Remote Access Trojan | VS-003, VS-001 | +| CS-MAL-03 | Fake Cloudflare / Drive-By PowerShell | VS-003, VS-005 | + +### Wallet Attack Category (CS-WAL) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-WAL-01 | Seed Phrase Theft | VS-001, VS-005 | +| CS-WAL-02 | Address Poisoning | VS-005, VS-004 | +| CS-WAL-03 | DNS / Frontend Hijack | VS-008, VS-005 | +| CS-WAL-04 | Malicious Signature (Permit2/ERC-20) | VS-004, VS-005 | +| CS-WAL-05 | Low Entropy Seed Generation | VS-001, VS-003 | + +### DeFi Protocol Category (CS-DFI) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-DFI-01 | Admin Key Exploit | VS-006, VS-003 | +| CS-DFI-02 | Flash Loan Attack | Protocol design | +| CS-DFI-03 | Bridge Exploit | VS-006 (verifier design) | +| CS-DFI-04 | Oracle Manipulation | Protocol design | +| CS-DFI-05 | Reentrancy | VS-003, VS-010 | + +### Supply Chain Category (CS-SC) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-SC-01 | NPM Package Hijacking | VS-010, VS-003 | +| CS-SC-02 | SDK / Library Poisoning | VS-010, VS-003 | +| CS-SC-03 | CI/CD Pipeline Compromise | VS-010, VS-006 | +| CS-SC-04 | AI Model Backdoor | VS-010, VS-007 | + +### AI Agent Category (CS-AI) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-AI-01 | Memory Poisoning | VS-007, VS-010 | +| CS-AI-02 | Prompt Injection | VS-007, VS-005 | +| CS-AI-03 | Data Chain Poisoning | VS-007, VS-010 | +| CS-AI-04 | AI Swarm Attack | VS-007, VS-003 | +| CS-AI-05 | Synthetic Identity / Document Fraud | VS-005, VS-009 | + +### Market Manipulation Category (CS-MKT) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-MKT-01 | MEV / Sandwich Attack | Protocol design | +| CS-MKT-02 | Tokenomics Weaponization | VS-005, VS-009 | +| CS-MKT-03 | Influence Operation / FUD | VS-005, VS-009 | + +### Sovereignty Category (CS-SOV) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-SOV-01 | CBDC Surveillance Architecture | Structural | +| CS-SOV-02 | CEX KYC Overreach | VS-008, Structural | + +### Financial Fraud Category (CS-FRD) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-FRD-01 | Pig Butchering / Financial Grooming | VS-005, VS-008, VS-009 | +| CS-FRD-02 | Recovery Re-Victimization | VS-005, VS-009 | +| CS-FRD-03 | Bitcoin ATM / QR Code Coercion | VS-005, VS-009 | +| CS-FRD-04 | Investment Group Scam | VS-005, VS-009 | + +### Extortion Category (CS-EXT) +| ID | Technique | VS Exploited | +|---|---|---| +| CS-EXT-01 | Sextortion / Blackmail / Ransomware | VS-005, VS-009 | + +--- + +## Layer +1: Delivery and Scale Mechanisms + +How attacks are distributed and amplified: + +| ID | Mechanism | Primary Threat IDs Delivered | +|---|---|---| +| DM-001 | AI-Powered Mass Personalization | CS-SOC-01, CS-FRD-01, CS-SOC-05 | +| DM-002 | Social Media Platform Amplification | CS-MKT-03, CS-SOC-01, CS-WAL-03 | +| DM-003 | Compromised Open Source Infrastructure | CS-SC-01, CS-SC-02, CS-SC-04 | +| DM-004 | Messaging App Networks | CS-FRD-01, CS-FRD-04, CS-SOC-03 | +| DM-005 | AI Agent Swarm Coordination | CS-AI-04, CS-MKT-03 | +| DM-006 | Physical World (Mail, In-Person) | CS-PHY-01, CS-PHY-02, CS-SOC-02 | + +--- + +## Layer +2: Economic and Social Outcomes + +Observed outcomes when attacks succeed: + +| ID | Outcome | Primary Threat Sources | +|---|---|---| +| EO-001 | Individual Wealth Destruction | CS-FRD-01, CS-WAL-04, CS-PHY-01 | +| EO-002 | Protocol Insolvency | CS-DFI-03, CS-INS-01, CS-SC-02 | +| EO-003 | Ecosystem Trust Erosion | CS-MKT-02, CS-MKT-03, CS-FRD-01 | +| EO-004 | Regulatory Overreach Trigger | CS-MKT-02, high-profile hacks | +| EO-005 | Physical Harm | CS-PHY-01, CS-PHY-02 | +| EO-006 | Capital Concentration | CS-MKT-01, CS-MKT-02 (Rotator Effect) | + +--- + +## Relationship to Companion Frameworks + +**Cognitive layer:** Layer -1 VS-009 (Cognitive Vulnerability) and VS-005 (Social Trust) are addressed by the Cognitive Sovereignty Framework. CryptoSHIELD provides the technical controls; CSF addresses the human cognition layer that all social engineering attacks exploit. +→ [Cognitive Sovereignty Framework](https://github.com/CyberStrategyInstitute/cognitive-sovereignty) + +**AI agent layer:** CS-AI-01 through CS-AI-05, VS-007, and the full AI governance model are addressed in detail by AI SAFE² v3.0. CryptoSHIELD defers to AI SAFE² for comprehensive AI agent governance. +→ [AI SAFE² Framework v3.0](https://github.com/CyberStrategyInstitute/ai-safe2-framework) + +--- + +*Threat Architecture | CSI CryptoSHIELD Framework v1.1* +*Cyber Strategy Institute | Open-Source* diff --git a/tools/30-day-hardening-sprint.md b/tools/30-day-hardening-sprint.md new file mode 100644 index 0000000..0fa824b --- /dev/null +++ b/tools/30-day-hardening-sprint.md @@ -0,0 +1,155 @@ +# Tool: 30-Day Sovereignty Hardening Sprint + +**CSI CryptoSHIELD Framework v1.1** +A prescriptive, time-boxed implementation plan for individual crypto holders. + +--- + +## Who This Is For + +Any individual holding more than $5,000 in crypto who has not systematically implemented security controls. Complete all four weeks in sequence. Do not skip weeks: each builds on the previous. + +**Time commitment:** 2-4 hours per week. +**Prerequisite:** A hardware wallet. If you don't have one, buy one (Ledger or Trezor from the official vendor only, never third-party sellers) before starting Week 1. + +--- + +## Week 1: Wallet Sovereignty + +**Goal:** Your keys. Your crypto. No exceptions. + +**Day 1-2: Hardware Wallet Setup** +- [ ] Purchase hardware wallet from official vendor only (ledger.com, trezor.io, coldcard.com) +- [ ] Initialize on a dedicated device (not your primary computer if possible) +- [ ] Generate new seed phrase on device; never digitize it +- [ ] Record seed phrase on metal backup (Cryptosteel, Bilodeau, or equivalent) +- [ ] Verify: can you recover from seed phrase alone? Test on a second device. + +**Day 3-4: Cold Storage Migration** +- [ ] Move 90%+ of holdings to hardware wallet cold storage (WKS-09) +- [ ] For holdings >$50,000: set up 2-of-3 multisig with a co-signer in a different city (WKS-02) +- [ ] Leave only a transactional float (10% maximum) in hot wallets + +**Day 5-6: Token Approval Audit** +- [ ] Go to revoke.cash +- [ ] Connect each of your active wallets +- [ ] Revoke all approvals for protocols you no longer actively use (WKS-07) +- [ ] Document: what remains approved? Why? + +**Day 7: Timelock and Governance** +- [ ] If you control any protocol governance wallet: implement 72-hour timelock on all admin transactions (WKS-03) +- [ ] Review: does any wallet have an "unlimited" approval outstanding? Revoke and replace with specific amount. + +**Week 1 Sovereignty Score:** Count checked boxes / 10 = ___ + +--- + +## Week 2: Device and Endpoint Defense + +**Goal:** Zero unknown code runs on any device that touches crypto. + +**Day 8-9: Dedicated Device Setup** +- [ ] Designate one device exclusively for crypto signing (no gaming, no browsing, no social media) (EDD-02) +- [ ] Fresh OS install on dedicated device if possible +- [ ] Install ONLY: hardware wallet companion app (official), browser for DEX (hardened), no extensions + +**Day 10-11: Endpoint Hardening** +- [ ] Install kernel-level Zero Trust endpoint protection (Xcitium/Warden model) on primary devices (EDD-01) +- [ ] Audit browser extensions on all devices: remove all non-essential extensions (EDD-05) +- [ ] Enable clipboard verification habit: before pasting any wallet address, verify it matches what you copied (EDD-04) + +**Day 12-13: Software Hygiene** +- [ ] Audit all software installed on crypto-adjacent devices +- [ ] Remove pirated software and any software from non-official sources (EDD-03) +- [ ] For developers: run `npm audit` on all crypto-related projects; check SBOM (SCD-01) + +**Day 14: Network Isolation** +- [ ] For large transactions: configure Flashbots Protect RPC in MetaMask (OCM-04) +- [ ] For signing device: consider dedicated network VLAN or air-gap mode during signing sessions (EDD-08) + +**Week 2 Sovereignty Score:** Count checked boxes / 8 = ___ + +--- + +## Week 3: Social and Physical OPSEC + +**Goal:** Your digital footprint does not lead to your front door. + +**Day 15-16: Social Media Hardening** +- [ ] X: Remove phone number; enable hardware 2FA (YubiKey) (SMS-01, SMS-02) +- [ ] Discord: Enable TOTP 2FA; remove phone number (SMS-01) +- [ ] Telegram: Enable Two-Step Verification; set phone number privacy to "Nobody" (SMS-02) +- [ ] All exchanges: enable hardware 2FA (SMS-01) +- [ ] Monthly OAuth audit: revoke non-essential connected apps on all accounts (SMS-03) +- [ ] Set up dedicated recovery email for all crypto accounts (SMS-04) + +**Day 17-18: Identity Decoupling** +- [ ] Audit: are any of your wallet addresses publicly linked to your real name or primary handle? +- [ ] Remove or archive any public posts showing portfolio balances, gains, or specific holdings (OPS-01) +- [ ] Check ENS names: any tied to your real name? (OPS-02) +- [ ] Conduct OSINT self-audit (see tools/osint-self-audit-checklist.md) (OPS-04) + +**Day 19-20: Physical Incident Plan** +- [ ] Fund decoy wallet with believable balance (OPS-06) +- [ ] Write your physical incident response plan (OPS-05): what do you do if coerced? +- [ ] Brief family members on basic OPSEC: what they should/should not say (OPS-07) +- [ ] Establish trusted contact with daily check-in protocol (OPS-10) +- [ ] Save FBI field office number and local cyber crime unit number + +**Day 21: Geolocation Audit** +- [ ] Install ExifTool; audit recent photos for geolocation data +- [ ] Disable location services on all crypto apps (OPS-08) +- [ ] Check Telegram: is location sharing on? Disable. + +**Week 3 Sovereignty Score:** Count checked boxes / 12 = ___ + +--- + +## Week 4: Monitoring and Intelligence + +**Goal:** Full visibility; no surprises. + +**Day 22-23: Wallet Monitoring** +- [ ] Set up Etherscan email alerts for all active wallets (OCM-02) +- [ ] Add wallet monitoring via Nansen, Hal.app, or equivalent +- [ ] Test: send small transaction; confirm alert arrives within 5 minutes + +**Day 24-25: Transaction Defense** +- [ ] Test Tenderly simulation: simulate any transaction you've done recently (OCM-01) +- [ ] Add Flashbots Protect RPC as a network in MetaMask (OCM-04) +- [ ] Install and test Scam Sniffer browser extension (SMS-09) +- [ ] Set bookmarks for all crypto platforms you use; delete or ignore all non-bookmarked links + +**Day 26-27: Intelligence Subscriptions** +- [ ] Subscribe to CSI Weekly Digest (cyberstrategyinstitute.com) +- [ ] Follow ZachXBT, Scam Sniffer, CertiK Skynet on X +- [ ] Set up Google Alerts: [your name + crypto], [your primary protocols + hack], [DPRK crypto] +- [ ] Bookmark: ic3.gov, chainabuse.com, revoke.cash, dfpi.ca.gov/consumers/crypto + +**Day 28-30: Review and Test** +- [ ] Review all four weeks: any gaps? +- [ ] Run OSINT self-audit one more time with fresh eyes +- [ ] Test your incident response plan mentally: what would you do if your phone showed $50K leaving your wallet right now? +- [ ] Schedule: calendar the next quarterly OSINT self-audit and token approval audit + +**Week 4 Sovereignty Score:** Count checked boxes / 10 = ___ + +--- + +## Sovereignty Tier Assessment + +Add up all checked boxes across four weeks (max: 40): + +| Score | Tier | Assessment | +|---|---|---| +| 0-15 | Exposure Risk | Significant vulnerabilities; prioritize Week 1-2 immediately | +| 16-25 | Hardened | Core defenses in place; complete remaining controls | +| 26-33 | Sovereign | Strong posture; maintain quarterly review cycle | +| 34-40 | Mission-Ready | Full implementation; contribute to community | + +**Your Score:** ___ / 40 | **Tier:** ___ + +--- + +*Tool: 30-Day Sovereignty Hardening Sprint | CSI CryptoSHIELD Framework v1.1* +*Cyber Strategy Institute | Open-Source* diff --git a/tools/sovereignty-self-assessment.md b/tools/sovereignty-self-assessment.md new file mode 100644 index 0000000..447c660 --- /dev/null +++ b/tools/sovereignty-self-assessment.md @@ -0,0 +1,552 @@ +# CryptoSHIELD Sovereignty Self-Assessment + +**CSI CryptoSHIELD Framework v1.1** +Cyber Strategy Institute | Open-Source | Sovereignty-First + +**Version:** 1.0 | **Last Updated:** May 2026 + +--- + +> **How to use this assessment:** +> Work through each domain. Answer each question honestly: this assessment is for you alone. Mark each item: YES (full credit), PARTIAL (half credit), or NO (zero credit). Add up your domain scores, then total. Find your Sovereignty Tier. The gap analysis at the end tells you exactly where to spend your next hour. +> +> **Time required:** 45-60 minutes for first completion. 15-20 minutes for quarterly re-assessment. +> +> **No tooling required.** Every question is answerable from what you know right now. Where verification requires a tool, the tool is free and linked. + +--- + +## Scoring Key + +| Answer | Points | Meaning | +|---|---|---| +| **YES** | Full points | Control is fully implemented and you can verify it today | +| **PARTIAL** | Half points (round down) | Control is partially implemented or you are uncertain | +| **NO** | 0 points | Control is not implemented or definitively absent | + +**Score each item before moving to the next domain.** Do not look ahead. + +--- + +--- + +## DOMAIN 01: Wallet and Key Sovereignty +**Maximum: 20 points** + +--- + +**WKS-01** *(3 pts)* My primary crypto holdings (any amount over $1,000) are stored on a hardware wallet purchased directly from the official manufacturer website (ledger.com, trezor.io, coldcard.com, or equivalent). + +- [ ] YES (3): Hardware wallet purchased from official source, actively used for primary storage +- [ ] PARTIAL (1): Hardware wallet owned but some holdings >$1K remain in software wallets +- [ ] NO (0): No hardware wallet, or purchased through third-party seller + +**Score:** ___ + +--- + +**WKS-02** *(3 pts)* For holdings above $50,000, I use a multisig arrangement (2-of-3 minimum) where the co-signers are physically located in separate cities or countries: not members of the same household. + +- [ ] YES (3): Multisig active, signers verified to be geographically and physically independent +- [ ] PARTIAL (1): Multisig exists but signers share a location or household +- [ ] NO (0): No multisig for holdings >$50K, or holdings are below $50K (skip: score YES) + +*Skip and score YES if total holdings are below $50,000.* + +**Score:** ___ + +--- + +**WKS-03** *(2 pts)* Any wallet I use for governance or admin control of a protocol enforces a timelock before transactions execute (72 hours minimum for small protocols; 7 days for protocols with >$10M TVL). + +- [ ] YES (2): Timelock is implemented and verified on-chain +- [ ] PARTIAL (1): Timelock exists but below minimum threshold for protocol size +- [ ] NO (0): No timelock, or no governance wallet (skip: score YES) + +*Skip and score YES if you have no protocol governance role.* + +**Score:** ___ + +--- + +**WKS-04** *(4 pts)* My seed phrase(s) are recorded on physical durable media (metal preferred; paper acceptable if fireproof/waterproof), stored in at least two separate physical locations, with zero digital copies anywhere: no photo, no note app, no password manager, no cloud storage. + +- [ ] YES (4): Physical backup, two locations, zero digital copies confirmed +- [ ] PARTIAL (2): Physical backup exists but only one location, OR digital copy in a "secure" location +- [ ] NO (0): Seed phrase is digital, stored in a single location, or unknown status + +**Score:** ___ + +--- + +**WKS-05** *(2 pts)* I never sign a transaction without independently verifying the destination address and transaction details on the hardware wallet screen: not just in the browser UI. + +- [ ] YES (2): Always verify on hardware wallet screen before signing +- [ ] PARTIAL (1): Sometimes verify; sometimes trust the browser display +- [ ] NO (0): I sign based on browser display only + +**Score:** ___ + +--- + +**WKS-07** *(3 pts)* I have audited my token approvals in the past 90 days (using revoke.cash or equivalent) and revoked all approvals for protocols I no longer actively use. + +- [ ] YES (3): Audit completed within 90 days; stale approvals revoked (verify now at revoke.cash) +- [ ] PARTIAL (1): Audit done but more than 90 days ago, or some stale approvals remain +- [ ] NO (0): Never audited token approvals, or unsure what token approvals are + +**Score:** ___ + +--- + +**WKS-09** *(3 pts)* 90% or more of my total crypto holdings (by value) are in cold storage (hardware wallet, not connected to any active session). + +- [ ] YES (3): 90%+ in cold storage confirmed +- [ ] PARTIAL (1): 50-89% in cold storage +- [ ] NO (0): Less than 50% in cold storage + +**Score:** ___ + +--- + +**Domain 01 Total: ___ / 20** + +--- + +--- + +## DOMAIN 02: Endpoint and Device Defense +**Maximum: 15 points** + +--- + +**EDD-01** *(4 pts)* The device(s) I use for crypto signing and DeFi interactions run kernel-level default-deny endpoint protection: not just antivirus: where unknown executables are contained before running. + +- [ ] YES (4): Kernel-level containment (Xcitium/Warden class, or equivalent Zero Trust endpoint) confirmed active +- [ ] PARTIAL (2): Standard antivirus/EDR only; no kernel-level containment +- [ ] NO (0): No endpoint protection, or using standard consumer antivirus as primary defense + +**Score:** ___ + +--- + +**EDD-02** *(4 pts)* I have a dedicated physical device used exclusively for crypto signing operations: no general browsing, email, social media, gaming, or general-purpose software on this device. + +- [ ] YES (4): Dedicated signing device confirmed; no general use +- [ ] PARTIAL (2): Dedicated device exists but also used for some non-crypto activities +- [ ] NO (0): Crypto signing happens on my primary general-purpose device + +**Score:** ___ + +--- + +**EDD-04** *(3 pts)* Before pasting any wallet address into a transaction field, I visually verify the first 6 and last 6 characters of the pasted address against what I intended to paste: every single time. + +- [ ] YES (3): Consistent habit; always verify paste content +- [ ] PARTIAL (1): Sometimes verify; skip when "familiar" with the address +- [ ] NO (0): I paste addresses without verification, or do not know about clipboard hijacking + +**Score:** ___ + +--- + +**EDD-05** *(2 pts)* I have audited the browser extensions on my crypto-adjacent devices within the past 90 days and removed all extensions that are not essential for crypto operations. + +- [ ] YES (2): Audited within 90 days; non-essential extensions removed +- [ ] PARTIAL (1): Some extensions removed but audit not recent or thorough +- [ ] NO (0): No extension audit conducted + +**Score:** ___ + +--- + +**EDD-10** *(2 pts)* On my signing device (or primary crypto device), only code-signed, verified applications are permitted to run. Application allowlisting is enforced at the OS level. + +- [ ] YES (2): Allowlisting enforced (macOS Gatekeeper strict, Windows Defender Application Control, or equivalent) +- [ ] PARTIAL (1): Basic restrictions in place but not full allowlisting +- [ ] NO (0): Any software can run; no allowlisting + +**Score:** ___ + +--- + +**Domain 02 Total: ___ / 15** + +--- + +--- + +## DOMAIN 03: OPSEC and Physical Security +**Maximum: 15 points** + +--- + +**OPS-01** *(3 pts)* I have never publicly posted or shared my crypto portfolio balance, specific holdings, or significant gains on any social media platform or public forum, and I have reviewed my existing posts for any such disclosures. + +- [ ] YES (3): No public disclosures; past posts reviewed and cleaned +- [ ] PARTIAL (1): Some disclosures exist but I have limited them; older posts may remain +- [ ] NO (0): I have made public disclosures of holdings or gains; posts remain public + +**Score:** ___ + +--- + +**OPS-02** *(2 pts)* None of my publicly used ENS names, social media handles, or forum usernames are directly linked to my real legal name or tied to wallet addresses containing significant holdings. + +- [ ] YES (2): Clean separation: public identity is not linked to significant holdings addresses +- [ ] PARTIAL (1): Partial separation; some linkages exist but are not obvious +- [ ] NO (0): My real name or primary handle is directly linked to significant holdings on-chain + +**Score:** ___ + +--- + +**OPS-04** *(2 pts)* I have conducted an OSINT self-audit within the past 6 months: searched my name plus "crypto," checked my handles on Etherscan/Arkham, and verified that my home address is not searchable through my crypto identity. + +- [ ] YES (2): OSINT self-audit completed within 6 months; results reviewed +- [ ] PARTIAL (1): Partial audit only; some vectors not checked +- [ ] NO (0): No OSINT self-audit conducted + +**Score:** ___ + +--- + +**OPS-05** *(4 pts)* I have a written or clearly defined physical incident response plan that covers: what to do if someone attempts to coerce a crypto transfer, who to contact, and how to buy time without surrendering primary holdings. + +- [ ] YES (4): Plan is written, current, and covers all three elements +- [ ] PARTIAL (2): Plan exists mentally but not written, or missing one of the three elements +- [ ] NO (0): No plan exists + +**Score:** ___ + +--- + +**OPS-06** *(2 pts)* I maintain a "coercion decoy" wallet: a wallet with a believable but sacrificial balance that I could surrender under physical duress without exposing primary holdings. + +- [ ] YES (2): Decoy wallet funded and ready +- [ ] PARTIAL (1): Decoy wallet set up but balance is implausibly small or obviously empty +- [ ] NO (0): No decoy wallet + +**Score:** ___ + +--- + +**OPS-10** *(2 pts)* I have established a duress protocol with a trusted contact: a pre-agreed signal (word, message pattern, or check-in failure) that triggers an emergency response on their end. + +- [ ] YES (2): Protocol established, tested at least once, trusted contact confirmed +- [ ] PARTIAL (1): Protocol discussed but not formally established or tested +- [ ] NO (0): No duress protocol + +**Score:** ___ + +--- + +**Domain 03 Total: ___ / 15** + +--- + +--- + +## DOMAIN 04: Social Media and Platform Security +**Maximum: 15 points** + +--- + +**SMS-01** *(3 pts)* All of my cryptocurrency exchange accounts AND my primary social media accounts (X, Discord, Telegram) use hardware security key 2FA (YubiKey, Google Titan, or equivalent FIDO2 device): not SMS 2FA, not authenticator app alone. + +- [ ] YES (3): Hardware key on all exchanges and primary social accounts +- [ ] PARTIAL (1): Hardware key on some accounts; authenticator app on others; SMS 2FA eliminated +- [ ] NO (0): Using SMS 2FA on any account, or 2FA not enabled + +**Score:** ___ + +--- + +**SMS-02** *(2 pts)* My phone number has been removed as a recovery method from all social media accounts (X, Discord, Telegram) and is not used as a 2FA method for any exchange or email account. + +- [ ] YES (2): Phone number removed from all accounts; SMS 2FA eliminated everywhere +- [ ] PARTIAL (1): Phone removed from most but not all accounts +- [ ] NO (0): Phone number is still used as recovery or 2FA on any crypto-relevant account + +**Score:** ___ + +--- + +**SMS-05** *(3 pts)* I never click links to access cryptocurrency platforms, DEXes, or DeFi protocols. I navigate exclusively by typing the URL directly or using bookmarks I created from a verified URL. This is a consistent, never-broken habit. + +- [ ] YES (3): Consistent habit; bookmarks used; no link-clicking for crypto sites +- [ ] PARTIAL (1): Usually follow this rule but occasionally click links from trusted sources +- [ ] NO (0): I regularly click links to access crypto platforms + +**Score:** ___ + +--- + +**SMS-12** *(3 pts)* Before depositing any amount into a new crypto platform or exchange, I verify it against at least two independent sources: DFPI Scam Tracker, CryptoScamDB, or Chainabuse. + +- [ ] YES (3): Consistent verification before every new platform deposit +- [ ] PARTIAL (1): Sometimes verify; sometimes rely on reputation or recommendation alone +- [ ] NO (0): No pre-deposit verification conducted for new platforms + +**Score:** ___ + +--- + +**SMS-14** *(4 pts)* I understand that any platform blocking my withdrawal and requiring a fee, tax, or "verification deposit" to unlock it is committing fraud: and I would stop all deposits immediately, document everything, and report to FBI IC3 rather than paying the fee. + +- [ ] YES (4): Fully understand this pattern; would stop and report without paying +- [ ] PARTIAL (2): Understand conceptually but uncertain if I would resist under pressure +- [ ] NO (0): Did not know this, or would likely pay to try to recover funds + +**Score:** ___ + +--- + +**Domain 04 Total: ___ / 15** + +--- + +--- + +## DOMAIN 05: On-Chain Monitoring and Transaction Defense +**Maximum: 10 points** + +--- + +**OCM-01** *(3 pts)* I treat transaction simulation as a mandatory gate before signing any DeFi transaction: not an optional check. If a transaction cannot be successfully simulated in Tenderly or equivalent, I do not sign it. + +- [ ] YES (3): Mandatory gate discipline; no exceptions +- [ ] PARTIAL (1): Use simulation sometimes; skip for "familiar" transactions +- [ ] NO (0): Do not use transaction simulation + +**Score:** ___ + +--- + +**OCM-02** *(2 pts)* I have active real-time wallet monitoring set up for all active wallets: email or push alerts trigger on any unexpected outgoing transaction. + +- [ ] YES (2): Active alerts on all wallets with outgoing transaction notification +- [ ] PARTIAL (1): Alerts on some wallets; manually check others +- [ ] NO (0): No active wallet monitoring + +**Score:** ___ + +--- + +**OCM-06** *(3 pts)* Before every outgoing transaction, I verify the full recipient address: not just the first and last four characters: on the hardware wallet screen or on a separate device. This is a consistent, never-broken habit. + +- [ ] YES (3): Full address verification on hardware screen for every transaction +- [ ] PARTIAL (1): Verify first/last characters only, or verify most but not all transactions +- [ ] NO (0): Do not verify recipient address independently + +**Score:** ___ + +--- + +**OCM-10** *(2 pts)* I never sign an `eth_sign` request. I understand `eth_sign` is deprecated and dangerous. For EIP-712 permit signatures, I verify the spender address and value before signing. + +- [ ] YES (2): `eth_sign` is rejected on sight; EIP-712 parameters reviewed +- [ ] PARTIAL (1): Reject `eth_sign` but do not review EIP-712 parameters carefully +- [ ] NO (0): Did not know about `eth_sign` risk or sign without reviewing structured data + +**Score:** ___ + +--- + +**Domain 05 Total: ___ / 10** + +--- + +--- + +## DOMAIN 06: Supply Chain Defense +**Maximum: 10 points** *(Primarily for developers and protocol teams: individual holders: see note)* + +> **Individual holder note:** If you do not write or maintain code, score WKS-01 and EDD-01 as your primary supply chain defense and skip Domains 06-07. Score this domain at 10/10 if you are purely a crypto user with no development role. + +--- + +**SCD-01** *(3 pts)* Every production repository I maintain includes a current SBOM (Software Bill of Materials), generated on every build, and scanned against vulnerability databases before deployment. + +- [ ] YES (3): SBOM in CI/CD pipeline, current, scanned +- [ ] PARTIAL (1): SBOM exists but not generated automatically or not scanned +- [ ] NO (0): No SBOM for production code + +**Score:** ___ + +--- + +**SCD-03** *(3 pts)* No production signing keys, API secrets, or contract admin keys exist in my CI/CD environment. All production secrets are accessed via a vault with ephemeral tokens. + +- [ ] YES (3): Secrets in vault; ephemeral tokens; no hardcoded secrets in CI/CD confirmed +- [ ] PARTIAL (1): Most secrets in vault; some legacy hardcoded secrets remain +- [ ] NO (0): Production secrets in environment variables or repository + +**Score:** ___ + +--- + +**SCD-07** *(2 pts)* All production package dependencies are version-pinned (exact versions, not ranges), `package-lock.json` or equivalent is committed to version control, and CI/CD uses `npm ci` (not `npm install`). + +- [ ] YES (2): Exact pinning, lock file committed, `npm ci` in pipeline +- [ ] PARTIAL (1): Partial pinning; ranges still used for some dependencies +- [ ] NO (0): Version ranges throughout; no consistent pinning + +**Score:** ___ + +--- + +**SCD-09** *(2 pts)* Post-install hooks are blocked globally via `.npmrc` policy (`ignore-scripts=true`). Exceptions for known build-required packages are explicitly allowlisted and reviewed. + +- [ ] YES (2): Global `.npmrc` policy confirmed; exceptions documented +- [ ] PARTIAL (1): Using `--ignore-scripts` flag sometimes but not global policy +- [ ] NO (0): Install hooks run by default + +**Score:** ___ + +--- + +**Domain 06 Total: ___ / 10** + +--- + +--- + +## DOMAIN 09: Consumer Fraud Defense +**Maximum: 15 points** + +*(This domain is for all participants: individual holders and developers.)* + +--- + +**CFD-01** *(4 pts)* I have never deposited funds into a platform I found through an unsolicited message (DM, email, text, dating app, social media ad), no matter how convincing the recommendation or how profitable the returns appeared. + +- [ ] YES (4): Never acted on an unsolicited investment recommendation +- [ ] PARTIAL (2): Have investigated such recommendations but have not deposited +- [ ] NO (0): Have deposited into a platform found through unsolicited contact + +**Score:** ___ + +--- + +**CFD-02** *(3 pts)* I know that any platform blocking my withdrawal and requesting a fee: called a "tax," "AML verification," "risk deposit," "account certification," or any other name: is fraud, and I would report it immediately to FBI IC3 (ic3.gov) without paying. + +- [ ] YES (3): Know the pattern cold; would stop and report +- [ ] PARTIAL (1): Know it exists but uncertain about my response under pressure +- [ ] NO (0): Did not know this or would likely pay + +**Score:** ___ + +--- + +**CFD-03** *(3 pts)* I know that no legitimate service can reverse a blockchain transaction: and that any "recovery specialist" contacting me after a loss who claims they can recover my funds for a fee is running a secondary scam. + +- [ ] YES (3): Know this clearly; would not engage any recovery service +- [ ] PARTIAL (1): Know in principle but might investigate a compelling recovery offer +- [ ] NO (0): Did not know blockchain transactions are irreversible or recovery services are fraudulent + +**Score:** ___ + +--- + +**CFD-04** *(3 pts)* I know that government officials, utility companies, law enforcement, and financial institutions never request cryptocurrency payments: and that any such request is always fraud. + +- [ ] YES (3): Know this clearly; would immediately hang up or close communication +- [ ] PARTIAL (1): Know in principle but might hesitate under authority pressure +- [ ] NO (0): Did not know this + +**Score:** ___ + +--- + +**CFD-05** *(2 pts)* I have briefed at least one family member (parent, grandparent, spouse, sibling) on the basic patterns of crypto fraud: specifically: no one ever needs cryptocurrency to pay a fine, tax, or emergency fee. + +- [ ] YES (2): At least one family member briefed on core fraud patterns +- [ ] PARTIAL (1): Mentioned it but not a full briefing +- [ ] NO (0): No family briefing on crypto fraud + +**Score:** ___ + +--- + +**Domain 09 Total: ___ / 15** + +--- + +--- + +## TOTAL SOVEREIGNTY SCORE + +| Domain | Score | Maximum | +|---|---|---| +| Domain 01: Wallet and Key Sovereignty | ___ | 20 | +| Domain 02: Endpoint and Device Defense | ___ | 15 | +| Domain 03: OPSEC and Physical Security | ___ | 15 | +| Domain 04: Social Media and Platform Security | ___ | 15 | +| Domain 05: On-Chain Monitoring | ___ | 10 | +| Domain 06: Supply Chain Defense | ___ | 10 | +| Domain 09: Consumer Fraud Defense | ___ | 15 | +| **TOTAL** | **___** | **100** | + +--- + +## Sovereignty Tier Classification + +| Score | Tier | Status | +|---|---|---| +| 0-24 | **EXPOSURE RISK** | Critical vulnerabilities present. Stop reading. Execute Week 1 of the 30-Day Sprint now. | +| 25-49 | **HARDENING IN PROGRESS** | Foundational controls partially in place. Priority: close Domain 01 and 04 gaps immediately. | +| 50-69 | **HARDENED** | Core posture established. Focus: close partial gaps; establish monitoring and physical OPSEC. | +| 70-84 | **SOVEREIGN** | Strong defense posture. Maintain quarterly review. Consider contributing to the framework. | +| 85-100 | **MISSION-READY** | Exceptional posture. You are the trusted contact for others. Share the framework. | + +**Your Tier:** ___________________ + +--- + +## Gap Analysis: Where to Spend Your Next Hour + +Review your NO and PARTIAL answers. Prioritize by: + +**Highest-impact items first (any NO on these = fix today):** +1. WKS-04 (seed phrase): if NO: everything else is irrelevant +2. SMS-14 (fee demand recognition): if NO: you are a primary fraud target +3. OPS-05 (physical incident plan): if NO: physical threat has no response +4. EDD-02 (dedicated signing device): if NO: malware can reach your signing sessions +5. WKS-09 (cold storage 90%): if NO: holdings are unnecessarily hot + +**Next priority (PARTIAL → YES within 30 days):** +- WKS-07 (token approval audit): free, 30 minutes at revoke.cash +- SMS-01 (hardware 2FA): $25-$50 investment; most impactful per dollar spent +- OCM-01 (simulation gate discipline): habit change, no cost +- OPS-04 (OSINT self-audit): 1-2 hours; free + +**30-Day implementation roadmap:** [tools/30-day-hardening-sprint.md](../tools/30-day-hardening-sprint.md) + +--- + +## Quarterly Re-Assessment Protocol + +Run this assessment every 90 days. Track your score progression: + +| Date | Score | Tier | Key Gap Closed | +|---|---|---|---| +| | | | | +| | | | | +| | | | | + +**Target:** Move up one tier per 90-day cycle until Sovereign (70+). + +--- + +## Version History + +| Version | Date | Changes | +|---|---|---| +| 1.0 | May 2026 | Initial release: 100-point instrument, 7 domains, 4 tiers | + +--- + +*CryptoSHIELD Sovereignty Self-Assessment v1.0* +*Cyber Strategy Institute | Open-Source | CC-BY-SA 4.0* +*github.com/CyberStrategyInstitute/crypto-shield*