leak-hunting

Leak Hunting

Systematically discover breached credentials, leaked databases, and dumped data related to a target across paste sites, breach forums, dark web markets, Telegram channels, GitHub repos, and breach search APIs. This skill covers already-leaked data — for finding live exposed databases, see the exposed-databases skill.

Workflow

Leak hunting follows five phases. Each phase feeds the next — do not skip triage or you will waste time acquiring junk data.

RECON → HUNT → VALIDATE → TRIAGE → ACQUIRE/HANDOFF
  |        |        |         |           |
  |        |        |         |           +-- open → data-acquisition skill
  |        |        |         |           +-- protected → cross-plugin-pipeline (elliot handoff)
  |        |        |         +-- credibility + freshness + value scoring
  |        |        +-- sample check, domain match, format plausibility
  |        +-- hunt-engine.js (dork, github, forum) + APIs (h8mail, IntelX, HIBP)
  +-- map target surface: domains, emails, brands, subsidiaries

Phase 1: Target Reconnaissance

Before generating any queries, map the target's digital footprint to maximize hunt coverage.

Define the Attack Surface

| Element | How to Find | Example | |---------|------------|---------| | Primary domains | Engagement scope, whois, DNS | corp.com, corp.com.br | | Email patterns | LinkedIn, public org charts, known breach headers | first.last@corp.com, flast@corp.com | | Brand keywords | Company name, products, internal projects, acquisitions | CorpTech, CorpPay, Project Atlas | | Employee emails | TheHarvester, LinkedIn scraping, prior breach samples | jane.doe@corp.com | | Subsidiaries | CNPJ/corporate registries, SEC filings, crunchbase | sub.corp.com, acquired-co.com |

Configure Hunt Profile

node ${CLAUDE_PLUGIN_ROOT}/scripts/hunt-profile.js show
node ${CLAUDE_PLUGIN_ROOT}/scripts/hunt-profile.js set <profile>

The profile controls which source categories are permitted and what timing delays to apply. See OPSEC section below.

Phase 2: Hunt Execution

Execute queries across all source categories, ordered by ROI (signal quality per time invested).

Execution Order

| Priority | Source | Tool / Method | Profile Requirement | |----------|--------|--------------|---------------------| | 1 | Breach search APIs (h8mail, HIBP, IntelX) | CLI / MCP / API | surface+ | | 2 | GitHub secret search | hunt-engine.js github | surface+ | | 3 | Google dorks (paste sites, indexed dumps) | hunt-engine.js dork | surface+ | | 4 | Breach forums (BreachForums, Exploit.in) | hunt-engine.js forum + manual | deep+ | | 5 | Telegram leak channels | Manual channel search | deep+ | | 6 | Dark web markets (.onion) | Tor Browser, manual | dark+ | | 7 | Stealer log markets (Russian Market, Genesis) | Tor Browser, manual | dark+ |

Breach Search APIs

h8mail (aggregated breach search):

h8mail -t target@corp.com -q domain --all
h8mail -t corp.com -q domain --all -o dumps/h8mail-corp.csv

Searches HIBP, LeakCheck, Snusbase, and other APIs. Configure API keys in ~/.h8mail/h8mail_config.ini.

Intelligence X (full-text breach search):

# Via API
curl -s "https://2.intelx.io/intelligent/search" \
  -H "x-key: $INTELX_API_KEY" \
  -d '{"term":"corp.com","maxresults":100,"media":0,"sort":2,"terminate":[]}'

Have I Been Pwned (breach membership check):

# Check single email
curl -s "https://haveibeenpwned.com/api/v3/breachedaccount/user@corp.com" \
  -H "hibp-api-key: $HIBP_API_KEY" \
  -H "user-agent: tyrell-hunter"

Returns list of breaches the email appears in — use to identify which breach databases to hunt for.

Query Generation

node ${CLAUDE_PLUGIN_ROOT}/scripts/hunt-engine.js dork <target> --category leaks
node ${CLAUDE_PLUGIN_ROOT}/scripts/hunt-engine.js github <target> --type secrets
node ${CLAUDE_PLUGIN_ROOT}/scripts/hunt-engine.js forum <target>

Execute generated queries via MCP tools (Brave Search, Shodan MCP, GitHub search). Do not manually construct queries — the engine optimizes them per source type.

GitHub Secret Hunting

Beyond hunt-engine.js, use dedicated tools for deeper coverage:

# gitleaks — scan a cloned repo
gitleaks detect --source /path/to/cloned-repo --report-format json --report-path dumps/gitleaks-report.json

# trufflehog — scan GitHub org
trufflehog github --org=target-org --json > dumps/trufflehog-results.jsonl

Look for: database connection strings (mongodb://, redis://, mysql://, postgres://, JDBC URLs), API keys, AWS credentials, .env files, config.yml with plaintext passwords.

Phase 3: Validation

Every result must be validated before acquisition. This prevents wasting time and storage on fake, synthetic, or irrelevant data.

Quick Validation Checklist

1. Domain match: Do email addresses in the sample match the target's known domains?
2. Format plausibility: Realistic data distributions — mixed names, varied passwords, correct phone/CPF formats
3. Volume consistency: Claimed record count plausible for the target's size (a 50-person startup won't have 10M records)
4. Date plausibility: Breach date consistent with company history and known breach events
5. Cross-reference: Check if this data appears in known public breaches (may be recycled old data)

Red Flags (Fake / Scam Data)

| Signal | Meaning | |--------|---------| | Sequential IDs (1,2,3,4...) with no gaps | Likely generated, not real data | | All records share the same password hash | Test/seed data | | Seller has <10 forum posts, claims exclusive fresh data | Probable scam | | Preview shows only 3-5 records for a "multi-million" dump | Insufficient proof | | Email domains don't match target at all | Wrong target or fabricated | | All passwords are plaintext and suspiciously simple | May be a combo list, not a real breach | | Offered "free" on a known scam channel | Bait for malware or phishing |

Stealer Log Validation

Stealer logs (from Redline, Raccoon, Vidar, etc.) require extra validation:

• URL field: Should contain target's login URL (e.g., https://portal.corp.com/login)
• Timestamp: Recent timestamps (< 6 months) indicate active infection
• Machine info: Hostname, OS, installed software — confirms real infected endpoint
• Cookie data: Session cookies may still be valid for account takeover

Phase 4: Source Logging and Classification

Every discovered source gets logged immediately upon discovery — before full validation. Classification happens after validation.

Log the Source

node ${CLAUDE_PLUGIN_ROOT}/scripts/source-tracker.js add <type> <url-or-identifier> "<description>" \
  --data-types email,password,name \
  --records <estimated-count>

Source types: forum, paste, darkweb, telegram, github, api-result, stealer-log

Classify After Validation

node ${CLAUDE_PLUGIN_ROOT}/scripts/source-tracker.js classify <id> \
  --credibility <high|medium|low|unknown> \
  --freshness <YYYY-MM> \
  --access-method <open|login|purchase|exploit>

Credibility Decision Tree

Sample validated against known real accounts?
  YES → credibility: high
  NO  → Seller has 50+ posts and forum vouches?
          YES → credibility: medium
          NO  → Sample format plausible and domain matches?
                  YES → credibility: low
                  NO  → credibility: unknown (or scam → mark dead)

Phase 5: Triage and Route

After logging and classifying, route each source to the appropriate next step.

| Access Status | Credibility | Route | Action | |--------------|-------------|-------|--------| | Open (direct download) | High/Medium | data-acquisition skill | Download, convert, register in acquisition tracker | | Open (direct download) | Low/Unknown | Validate first | Pull sample, re-assess before full acquisition | | Login required (foru