We Hid 10 Secrets on a Web Server. SecurityClaw Found All 10 in Under 5 Seconds.

The Target: A Fake Corporate Web Server

The target was "AcmeCorp Portal" — a minimal HTTP server running on localhost:19090. The public surface looked clean: /, /about, /contact, /robots.txt. Nothing unusual.

Deliberately hidden from robots.txt and from any public link: 10 sensitive paths covering the most common categories of web exposure we see in real assessments.

Everything hidden from robots.txt. The kind of defence that stops Google's crawler and does nothing to a tool running from a wordlist.

What SecurityClaw Found

The scan ran in two passes. This is deliberate: a single flat scan finds directories and files, but the most valuable content is often one level deeper. SecurityClaw's campaign system auto-schedules the recursive pass when a redirect or directory is confirmed.

Scan 1 — Initial Enumeration (2.56 seconds)

Command:

gobuster dir \
  -u http://target/ \
  -w /usr/share/wordlists/dirb/common.txt \
  -x php,zip,bak,txt,html,git \
  -t 20 -q

Results:

/.git/HEAD            (Status: 200) [Size: 21]
/admin                (Status: 301) [Size: 0] [--> /admin/]
/api                  (Status: 200) [Size: 61]
/backup.zip           (Status: 200) [Size: 100]
/config.bak           (Status: 200) [Size: 57]
/phpinfo.php          (Status: 200) [Size: 118]
/robots.txt           (Status: 200) [Size: 34]
/wp-admin             (Status: 301) [Size: 0] [--> /wp-admin/]

Eight findings in 2.56 seconds. Three of them are CRITICAL. The /admin and /wp-admin 301 redirects are findings, not dead ends — they confirm the directories exist and prompt the recursive pass.

Scan 2 — Recursive Against /admin/ (2.23 seconds)

SecurityClaw followed the /admin redirect automatically and ran a second pass against /admin/ as the new base:

/dashboard            (Status: 200) [Size: 88]
/login                (Status: 200) [Size: 131]

The /admin/dashboard endpoint returned business metrics: 1,247 registered users and $84,320 in revenue, unauthenticated. The /admin/login page exists with no rate limiting — confirming the admin panel is real and accessible.

The /api Follow-Up

The /api root returned a JSON response disclosing its available routes — including /api/v1/users and /api/v1/keys. These weren't in the wordlist; they were found by reading the API's own response. This is the SecurityClaw AI layer at work: gobuster finds the door, the intelligence layer reads the sign on it.

/api/v1/keys returned live sk_live_* production API keys with zero authentication required.

Final Score

The Three Findings That Matter Most

⛔ 1. /backup.zip + /config.bak — Instant Database Exfiltration

These two files together represent the worst-case scenario for a developer who didn't think about what was accessible on the web root. Found individually, each is serious. Found together, they represent a complete database exfiltration without touching the application layer.

config.bak contained: host=db.internal, user=admin, pass=Sup3rS3cr3t! in plaintext. backup.zip contained the database dump.

An attacker with both can restore the entire database locally — unzip the archive, update the host to localhost, connect. No SQL injection. No authentication bypass. Two HTTP GET requests and a database client.

This pattern shows up on real assessments more often than it should. The files are created during a maintenance window, never cleaned up, and forgotten. The web server serves anything in the web root. Gobuster finds it in seconds.

⛔ 2. /api/v1/keys — Production Keys Served Unauthenticated

Live sk_live_* API keys returned with no authentication check. This is what the SecurityClaw AI layer is designed to escalate immediately: a path that returns credential material in its response body is the highest priority finding in any assessment. Third-party integrations using this API are fully compromised.

🔴 3. /.git/HEAD — Source Code Exposure

A 200 response at /.git/HEAD means the .git directory is accessible over HTTP. From there, git-dumper can recover the entire commit history — including files that were deleted, including secrets that were committed and then removed.

The developers who make this mistake usually don't know they made it. They deployed by copying files rather than using a CI/CD pipeline. The .git directory came along for the ride.

Tools for exploiting this:

• git-dumper — recovers the full repository from an exposed .git
• GitHack — similar, with better handling of packed objects
• TruffleHog — scans the recovered history for secrets (see Demo D1)
• Gitleaks — faster history scanner, entropy-based detection (see Demo D13)

The Honest Gaps

Two things required multiple techniques to get the full 10/10 — neither is a gobuster weakness, both are things to understand when reading scan results:

Extension Fuzzing Is Mandatory

Without -x php,zip,bak, gobuster would have missed /backup.zip and /config.bak entirely. These are the two most dangerous findings on the list. Gobuster without extension fuzzing is directory enumeration only. With extensions, it becomes full file discovery. The flag is short. Use it.

Deep API Paths Require AI Follow-Up

dirb/common.txt found /api (the root). It did not find /api/v1/users or /api/v1/keys — those paths aren't in common.txt. They were discovered because the /api response disclosed them in its JSON output. A human or AI follow-up step, not a wordlist hit.

This is the SecurityClaw story: gobuster finds the doors; the AI layer reads the responses and decides which ones to open.

/.git/config Needs a Dedicated Wordlist

common.txt contains .git/HEAD but not .git/config. To confirm full repo recovery potential, a git-specific wordlist or a direct git-dumper run is needed. The /.git/HEAD finding is sufficient signal to escalate — the deeper exploration is follow-up work.

Why It's Not the Tool — It's the Technique

Gobuster is fast but deliberately simple. It sends requests and records responses. The intelligence is in the orchestration:

• Wordlist selection: common.txt is 4,600 entries. directory-list-2.3-medium.txt is 220,000. Using the right list for the assessment phase.
• Extension fuzzing: The difference between finding directories and finding sensitive files.
• Following 301s: A redirect is a positive finding. The content is one level deeper.
• Recursive depth: Admin panels are never at /admin. The valuable pages are at /admin/dashboard, /admin/users, /admin/settings.

SecurityClaw's campaign system handles the orchestration: scan 1 → identify redirects and active directories → schedule recursive passes → correlate all findings into a single prioritised report. The analyst gets the complete picture, not a flat list of HTTP status codes.

For practitioners who want to understand the web application attack surface deeply, The Web Application Hacker's Handbook remains the reference for exactly this kind of reconnaissance-to-exploitation chain. And Black Hat Python is useful if you want to understand how tools like gobuster work under the hood — useful context for writing custom wordlists and interpreting edge-case responses.

SecurityClaw Scorecard: D12

D12 extends SecurityClaw's web-scanning category — now the largest in the demo series. Gobuster directory/file enumeration is the standard first step before any active exploitation: you need to know what's on the surface before you know what to test.

If you're running web application assessments and you're not doing directory enumeration as step one, you're starting in the middle. The backup file and the config file and the exposed API keys in this demo are there because no one thought to check.

You can install gobuster and run this exact scan against your own test environment. The command is in the demo above.

Penetration Testing by Georgia Weidman dedicates substantial coverage to web enumeration technique — useful for understanding why the wordlist choice matters and how to integrate gobuster into a complete assessment methodology.