hunt-database-exposure

Validates publicly exposed database backups, logs, and configs through evidence-gated black-box checks.

10|3|Updated Aug 10, 2026
One-click install
npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-database-exposure-baiqigo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hunt-database-exposure
Source: https://github.com/baiqigo/baiqi-redteam-lab/tree/main/.agents/skills/hunt-database-exposure
Command: npx skills add https://github.com/baiqigo/baiqi-redteam-lab --skill hunt-database-exposure-baiqigo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Security testers need a disciplined way to confirm whether database backups, logs, configuration files, or admin consoles are publicly exposed without ever connecting to the database or using credentials, and without producing false positives from stale caches or error pages. ## Core Features & Use Cases - Evidence-Gated Validation: Enforces a fixed baseline → single-variable probe → post-baseline → oracle → evidence workflow so every finding is reproducible and in-scope. - Strict Safety Boundaries: Stops immediately on database connections, credential use, data export, or admin operations; suspected credentials are recorded only as field names and hashes. - False-Positive Filtering: Treats WAF blocks, timeouts, scanner hits, empty files, and historical archives as INCONCLUSIVE rather than confirmed exposure. - Use Case: During an authorized assessment, you discover a URL hinting at a database backup file. Use this Skill to verify ownership, scope, and accessibility of your own canary artifact, then capture URL, hash, ACL, and a minimal redacted excerpt as evidence. ## Quick Start Use $hunt-database-exposure to plan an evidence-gated, authorized validation path for a suspected exposed database backup file.

Frequently Asked Questions about hunt-database-exposure

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify an exposed database backup file without downloading data?

Confirm the file is currently reachable, in scope, and contains your own canary data, then check listing, ACL, or directory indexing behavior. Record only the URL, hash, owner, and a minimal redacted excerpt as evidence.

What counts as proof of database configuration exposure in a pentest?

Valid proof requires a reproducible, in-scope resource that publicly exposes database metadata, config, or backup content that should not be public, or a low-privilege identity reaching an admin console. Error messages, empty files, and historical archives do not qualify.

Does this approach ever connect to the database or use found credentials?

No. Database connections, credential use, data export, and administrative operations are explicit stop conditions. Suspected credentials are recorded only as field names and hashes, never tested.

Why is my database exposure finding marked inconclusive?

WAF blocks, timeouts, single anomalies, scanner hits, search cache results, and filename-only hints are all treated as INCONCLUSIVE. You need a reproducible, currently reachable in-scope resource with verified ownership to confirm exposure.

When should findings be routed to other security testing skills?

Route suspected SQL parameter issues to a SQL injection skill and source code or configuration leaks to a source-leak skill. This skill only handles database metadata, backup, log, and admin console exposure validation.