Exposed Database Hunting

Discover internet-facing databases with no authentication, triage them by value, probe safely to confirm access, and route confirmed targets into the acquisition pipeline.

Workflow

The exposed database hunting process follows five phases. Complete each phase before moving to the next — skipping triage leads to wasted probes on low-value or out-of-scope targets.

SCOPE → DISCOVER → TRIAGE → PROBE → ROUTE
  │         │          │        │        │
  │         │          │        │        ├─ open → data-acquisition skill
  │         │          │        │        └─ protected → cross-plugin-pipeline (elliot handoff)
  │         │          │        └─ dumper.js probe + source-tracker.js add
  │         │          └─ prioritize by data value, size, auth certainty
  │         └─ hunt-engine.js (shodan, dork, github) + Censys
  └─ verify target is in-scope for the active engagement

Phase 1: Scope Check

Before generating any queries, verify the target is authorized:

1. Check engagement.json or the active campaign's scope definition
2. Confirm the target domain, IP range, or organization is explicitly in-scope
3. If no engagement is active, ask the operator to confirm authorization before proceeding

Never probe hosts outside the authorized scope, regardless of what Shodan/Censys returns.

Phase 2: Discovery

Generate queries across multiple sources to maximize coverage. The hunt engine produces structured queries — it does not execute them. You execute them via MCP tools (Hexstrike Shodan, Brave Search) or direct API calls.

Shodan Queries

node ${CLAUDE_PLUGIN_ROOT}/scripts/hunt-engine.js shodan <target> [--service mongo|elastic|redis|couch|mysql|postgres|all]

The engine generates queries filtered by service type and scoped to the target (by hostname for domains, by CIDR for IP ranges). Covers MongoDB (27017), Elasticsearch (9200), Redis (6379), CouchDB (5984), MySQL (3306), PostgreSQL (5432), and Kibana (5601).

Execute each generated query via MCP Shodan tool. For each result, extract:

• IP and port — the probe target
• ASN and organization — verify it belongs to the target's infrastructure
• Banner data — version string, auth status indicators, database/index names if visible

Censys Queries

Censys uses a SQL-like search syntax. Generate equivalent queries manually:

Replace "Target Org" with the actual ASN organization name or use ip: for CIDR ranges.

Google Dorks

node ${CLAUDE_PLUGIN_ROOT}/scripts/hunt-engine.js dork <target> --category exposed-db

Generates dorks for phpMyAdmin panels, exposed Elasticsearch _cat/indices endpoints, MongoDB HTTP interfaces, CouchDB Futon/Fauxton UIs, and Adminer. These catch web-facing admin UIs that Shodan might miss.

GitHub Leak Search

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

Finds connection strings (mongodb+srv://, redis://, JDBC URLs) leaked in public repos. A leaked connection string with credentials is a direct path to a database that may not appear on Shodan at all.

Phase 3: Triage

Discovery will produce a list of candidate hosts. Probe them in priority order — not randomly. Each result has signals in the Shodan/Censys banner that help you decide what to probe first.

Priority Matrix

Auth Status from Banners

Read auth status directly from discovery results before probing — this saves time on hosts that are clearly protected:

• MongoDB: "ok": 1.0 in banner = open. "code": 13 or "code": 18 = protected.
• Elasticsearch: Banner contains cluster info JSON with 200 status = open. 401 or security_exception = protected.
• Redis: redis_version:X.Y.Z in banner = open. NOAUTH Authentication required = protected.
• CouchDB: "couchdb":"Welcome" in banner = service running (need to check /_all_dbs to confirm auth).
• MySQL/PostgreSQL: Port open doesn't indicate auth status — these always need a connection attempt.

See references/database-fingerprints.md for complete banner patterns and authentication detection tables.

Phase 4: Probe and Log

For each P1/P2 target, probe using dumper.js and log the result with source-tracker.js. These two steps always happen together — never probe without logging.

Probe

node ${CLAUDE_PLUGIN_ROOT}/scripts/dumper.js probe <host:port> [--service auto|mongo|elastic|redis|couch|mysql|postgres]

The probe is read-only. It detects the service type, attempts a single metadata query (list databases/indices/keys), and reports whether the service is open or requires authentication. Auto-detection works for most services based on port number and banner response.

If dumper.js probe is unavailable or the target requires a non-standard approach, fall back to manual probing — but stick to read-only operations:

Never issue write, update, or delete commands. Read-only enumeration only.

Log Immediately After Probing

Every probed host gets logged, whether open or closed. This prevents re-probing the same host and builds the intelligence picture.

If open:

node ${CLAUDE_PLUGIN_ROOT}/scripts/source-tracker.js add exposed-db <ip:port> "<db-type> vX.Y, databases: [list], ~N records" \
  --service <mongo|elastic|redis|couch|mysql|postgres> \
  --access-method open \
  --data-types email,password,name \
  --records <estimated-count>

Then classify:

node ${CLAUDE_PLUGIN_ROOT}/scripts/source-tracker.js classify <id> \
  --credibility high \
  --freshness <YYYY-MM> \
  --access-method open

If protected:

node ${