exposed-databases

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:

| Database | Censys Query | |----------|-------------| | MongoDB | services.port=27017 AND services.service_name=MONGODB AND autonomous_system.name="Target Org" | | Elasticsearch | services.port=9200 AND services.http.response.body:"You Know, for Search" AND labels="Target" | | Redis | services.port=6379 AND services.banner:"redis_version" AND autonomous_system.name="Target Org" | | CouchDB | services.port=5984 AND services.http.response.body:"couchdb" AND autonomous_system.name="Target Org" | | MySQL | services.port=3306 AND services.service_name=MYSQL AND autonomous_system.name="Target Org" | | PostgreSQL | services.port=5432 AND services.service_name=POSTGRESQL AND autonomous_system.name="Target Org" |

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

| Priority | Signal | Why | |----------|--------|-----| | P1 — Probe immediately | Banner shows database names containing users, customers, accounts, credentials, emails, or PII-related terms. Auth is confirmed disabled (MongoDB ok: 1, Elasticsearch 200, Redis version info without NOAUTH). | High-value data, confirmed open — maximum ROI. | | P2 — Probe soon | Port is open and service is identified, but banner doesn't reveal auth status or data content. Large estimated size. | Needs verification but likely worth it. | | P3 — Probe if time allows | Service detected but port is non-standard, or banner suggests auth is enabled (401, NOAUTH, code: 13). | Low probability of open access. | | Skip | IP/ASN doesn't belong to target. Out-of-scope geography. Banner confirms auth enabled with certainty. | Not in scope or confirmed protected. |

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:

| Service | Manual Probe Command | What It Returns | |---------|---------------------|-----------------| | MongoDB | mongosh --host <ip> --port 27017 --eval 'JSON.stringify(db.adminCommand("listDatabases"))' --quiet | Database names and sizes | | Elasticsearch | curl -s http://<ip>:9200/_cat/indices?v | Index names, doc counts, sizes | | Redis | redis-cli -h <ip> -p 6379 INFO server then DBSIZE | Version, key count | | CouchDB | curl -s http://<ip>:5984/_all_dbs | Database names | | MySQL | mysql -h <ip> -P 3306 --connect-timeout=5 -N -B -e 'SHOW DATABASES' | Database names (blank password) | | PostgreSQL | psql -h <ip> -p 5432 -U postgres -t -A -c 'SELECT datname FROM pg_database WHERE datistemplate = false' | Database names |

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 ${