source-intelligence

Source Intelligence

Discover where target data has been leaked, exposed, or sold across search engines, code repositories, paste sites, breach forums, and messaging platforms. The goal is to build a complete map of available intelligence sources before any direct acquisition attempt.

Workflow

Source intelligence follows a structured collection process across five source categories. Work through each category systematically — skipping categories means missed intelligence.

SCOPE → DORK → CODE → PASTE → FORUM → CHAT → LOG → ROUTE
  │       │      │       │       │       │      │      │
  │       │      │       │       │       │      │      ├─ classified source → data-acquisition / cross-plugin-pipeline
  │       │      │       │       │       │      └─ source-tracker.js add + classify
  │       │      │       │       │       └─ Telegram/Discord channel monitoring
  │       │      │       │       └─ BreachForums, Exploit.in, XSS.is, dark web
  │       │      │       └─ Pastebin, paste.ee, Rentry, Ghostbin
  │       │      └─ GitHub/GitLab: hunt-engine.js github + gitleaks/trufflehog
  │       └─ Google/Brave dorks: hunt-engine.js dork
  └─ verify target is in-scope for the active engagement

Phase 1: Scope Verification

Before generating any queries:

1. Check engagement.json or the active campaign scope — confirm the target domain, brand name, and email patterns are authorized
2. Define search identifiers: primary domain (corp.com), brand name (Acme Corp), email pattern (@corp.com), product names, subsidiary domains
3. Check the active hunt profile — it determines which source categories are accessible

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

| Profile | Dorks | Code | Paste | Forums | Chat | |---------|-------|------|-------|--------|------| | surface | Yes | Yes | Yes (via dorks) | No | No | | deep | Yes | Yes | Yes (direct) | Yes (registered accounts) | Yes (joined channels) | | dark | Yes | Yes | Yes (direct + Tor) | Yes (+ .onion forums) | Yes (+ hidden groups) | | ghost | Yes (paced) | Yes (paced) | Yes (Tor only) | Yes (single-threaded, max delays) | Yes (read-only) |

Phase 2: Google/Brave Dork Execution

Generate dork queries targeting the five discovery categories:

node ${CLAUDE_PLUGIN_ROOT}/scripts/hunt-engine.js dork <target> [--category exposed-db|credentials|dumps|configs|admin-panels]

Without --category, generates queries for all categories. Execute each generated query via Brave Search MCP tool.

Dork Categories

| Category | What It Finds | Priority | |----------|---------------|----------| | credentials | SQL dumps with passwords, paste site credential leaks, CSV/TXT with username:password | Highest — direct credential access | | dumps | Directory listings with database dumps, BSON/JSONL data files, breach references | High — raw data files | | configs | .env files with DB passwords, YAML/JSON configs with connection strings, Java properties with JDBC URLs | High — infrastructure credentials | | exposed-db | phpMyAdmin panels, Elasticsearch _cat/indices, Kibana dashboards, CouchDB Futon, Adminer | Medium — routes to exposed-databases skill | | admin-panels | Login panels, Grafana, Jenkins, RabbitMQ management interfaces | Lower — indirect value, may reveal infrastructure |

Execution Strategy

1. Start with credentials and dumps categories — these have the highest ROI for source discovery
2. Execute one dork at a time — search engines rate-limit automated queries
3. For each result page, check pages 2-3 as well — important results are often buried
4. Use after:YYYY-MM-DD date filter to surface recent leaks
5. If a result is deleted, try cache: operator or Wayback Machine to recover content
6. Archive paste/ephemeral content immediately before it disappears

Custom Dork Construction

When the generated dorks are not specific enough, build custom queries by combining operators:

Target-specific credential hunt:

("@DOMAIN" OR "BRAND") ("password" OR "senha" OR "pwd") (filetype:sql OR filetype:csv OR filetype:txt) -site:DOMAIN

Infrastructure exposure sweep:

("BRAND" OR "DOMAIN") (filetype:env OR filetype:conf OR filetype:yml OR filetype:ini) ("password" OR "secret" OR "key")

Broad leak search:

("@DOMAIN" "password") OR ("DOMAIN" "dump" filetype:sql) OR (site:pastebin.com "@DOMAIN")

See references/dork-patterns.md for the complete operator reference, paste site dorks, Brazilian-specific patterns, and advanced combination strategies.

Phase 3: GitHub/GitLab Code Scanning

Scan public code repositories for committed secrets, connection strings, configuration files, and database dumps.

Query Generation

node ${CLAUDE_PLUGIN_ROOT}/scripts/hunt-engine.js github <target> [--type secrets|configs|dumps|env-files]

Without --type, generates queries for all types. Execute via GitHub code search or GitHub MCP tool.

Three-Layer Scanning Approach

Layer 1 — Hunt engine queries (fast, broad) Run the generated queries against GitHub code search. This catches currently-visible secrets in public repositories.

Layer 2 — gitleaks (deep, per-repo) After identifying target repositories from Layer 1 or from the target's GitHub organization, scan each with gitleaks for pattern-matched secrets:

gitleaks detect --source /path/to/cloned/repo --report-format json --report-path gitleaks-report.json

Layer 3 — trufflehog (org-wide, verified) For organization-level scanning with verification of found secrets:

trufflehog github --org target-corp --only-verified --json

What to Look For

| Finding Type | Operational Value | Next Step | |--------------|-------------------|-----------| | MongoDB/Redis/Elasticsearch connection string with credentials | Critical — direct database access | Probe the endpoint, route to data-acquisition | | AWS/GCP/Azure credentials | Critical — cloud infrastructure access | Route to cross-plugin-pipeline (elliot handoff) | | .env file with DB_PASSWORD | High — credential for known infrastructure | Match against discovered exposed databases | | SQL dump file committed to repo | High — data already extracted | Download and register as acquisition | | API keys (Stripe, Twilio, SendGrid) | Medium — secondary access | Log for potential lateral movement | | Hardcoded passwords in application code | Medium — may reveal password patterns | Test against target services |

Commit History Mining

Secrets deleted from current branches remain in git history. After cloning a target repository:

git log --all -S "password" --oneline
git log --all -S "mongodb://" --oneline
git log --all -S "DB_PASSWORD" --oneline

Recover the secret from the specific commit:

git show <commit-hash>:<file-path>

See references/github-scanning.md for the full GitHub/GitLab search operator reference, gitleaks/trufflehog usage, self-hosted GitLab recon, and commit history mining techniques.

Phase 4: Paste Site Surveillance

Paste sites are primary distribution channels for leaked credentials, database samples, and configuration dumps.

Target Paste Sites

| Site | Indexed by Google | Direct Search | Longevity | |------|-------------------|---------------|-----------| | Pastebin | Yes | API (paid) | Varies (can be removed) | | paste.ee | Yes | No API | Usually persistent | | Rentry | Partially | No API | Persistent | | Ghostbin | No longer active | N/A | Defunct — check archives | | dpaste | Yes | No API | Time-limited | | PrivateBin | No (encrypted) | No | Requires link |

Search Approach

Via dorks (surface profile):

site:pastebin.com "@corp.com"
site:pastebin.com "corp.com" "password"
site:paste.ee "@corp.com"
site:rentry.co "corp.com"

Via Pastebin API (deep profile, paid): The Pastebin scraping API (https://psbdmp.ws/api/) enables real-time monitoring of n