SecurityClaw Found the Backup File Your Developer Left Behind

The Results

Two critical, three high, two medium. All seven intended targets found. One miss — /api/v2/internal — documented honestly in the gaps section. Total scan time: 2.0 seconds across 4,621 requests (25K wordlist minus entries filtered for file extension noise). That's approximately 2,310 requests per second on an ARM CPU against a local test target.

The Critical Findings

/backup.zip — 18.4MB, Unprotected

The most dangerous file on the server isn't the admin panel — it's the backup. An accessible admin panel requires credentials and a login bypass. An accessible backup.zip requires only a browser.

The 18.4MB backup contained (in the controlled demo):

• Complete application source code — all business logic, route definitions, template files
• Database dump (db_backup.sql) — full user table including email addresses and password hashes (MD5-stored in the demo, per the deployment era)
• Configuration backup — database host, username, password; SMTP credentials; third-party API keys
• Deployment notes — internal server architecture, infrastructure layout, admin account details

The password hashes are the critical asset. The demo used MD5-hashed passwords, consistent with many legacy applications still in production. SecurityClaw's hashcat skill (D14) cracks MD5 at 937,500 hashes per second. The admin account password was in rockyou.txt. Cracked in under a second.

/admin — Exposed, No MFA

An admin panel at a predictable path (/admin, /admin.php, /wp-admin, /administrator) is expected to exist. What makes this a critical finding is the combination: accessible panel + cracked credentials from backup.zip = immediate admin access. The scan doesn't create the vulnerability. It reveals the exposure that was always there.

The Attack Chain: backup.zip → hashcat → admin → Game Over

This is the full chain, combining D16 (ffuf) with D14 (hashcat) and D15 (hydra):

The full chain — from "we know nothing about this server" to "admin console open" — runs in under two minutes, almost entirely automated. The human time is the 30 seconds to glance at the database dump and identify the admin hash.

Once inside the admin panel, the attack branches. In the demo environment, the admin panel had a file upload feature (for profile images), a database query interface (for reporting), and user management (create/delete accounts). Each of these is a post-exploitation vector. The backup.zip was the pivot that made all of them accessible.

"The backup file isn't a minor misconfiguration. It's a complete copy of your application handed to an attacker with no authentication required. Everything that followed — hashcat, admin access, data extraction — was a consequence of that single file being accessible."

The Other High-Severity Findings

/.git/config — Source Repo with Credentials

An exposed .git/ directory is one of the most common and most serious web misconfigurations seen in real-world pentests. When the git directory is accessible via HTTP, an attacker can reconstruct the entire repository — including the full commit history of every file that was ever tracked, including files that were deleted.

The .git/config file alone contained the remote URL in the format https://username:token@github.com/org/repo — hardcoded credentials providing read (and potentially write) access to the source repository. This is separate from the backup.zip exposure and provides a persistent access vector even after backup.zip is removed.

/api/v1/debug — Environment Variables in JSON

Debug endpoints left enabled in production are a recurring source of credential exposure. The /api/v1/debug endpoint returned a JSON dump that included:

• All environment variables — DATABASE_URL, AWS_ACCESS_KEY_ID, STRIPE_SECRET_KEY, SENDGRID_API_KEY
• Application configuration (cache settings, feature flags, internal service URLs)
• Recent error stack traces with file paths

A single HTTP GET to a path that "nobody knows about" returns every secret the application has loaded into its environment. Debug endpoints are typically added during development, inadequately protected, and forgotten.

/config.bak — The Configuration That Wasn't Deleted

Configuration backup files (.bak, .old, .orig, .backup, ~) are produced by text editors, manual editing workflows, and deployment scripts. The pattern: config.php was being edited, the editor saved config.php.bak as a safety copy, and the deployment process uploaded both. The original file is protected (the application reads it properly); the backup is served as a plain text file, bypassing any PHP execution, returning the raw configuration including database credentials.

The Honest Miss: /api/v2/internal

We planted a CRITICAL endpoint at /api/v2/internal that ffuf did not find. This endpoint returned a 200 response with internal API documentation including authenticated endpoints not visible in the public API spec. It would have been a significant finding. The scan missed it entirely.

Why It Was Missed

The SecLists content_discovery_top_25k.txt wordlist doesn't contain api/v2/internal as an entry. This isn't a surprising gap — the path is application-specific. No public wordlist will contain every custom path in every application.

What a more thorough scan would have done:

1. Recursive scanning — discover /api/ first, then fuzz /api/FUZZ with a focused wordlist, then /api/v2/FUZZ with another pass
2. Application-specific wordlists — once source code is accessible (via backup.zip, .git, or other means), extract all route definitions and generate a targeted wordlist
3. Multiple wordlists — supplement SecLists with FuzzDB, dirbuster's medium.txt, and custom lists built from the application's visible API surface
4. Spider + fuzz combination — crawl the application to discover linked paths, use these as seeds for further fuzzing

The miss is meaningful context for any security assessment: a clean ffuf scan does not mean no hidden endpoints exist. It means no publicly-known path patterns are exposed. Custom application paths require custom wordlists to find.

In a real assessment, /api/v2/internal would likely have been found through the backup.zip chain — the source code would contain the route definition, and an attacker with source code access builds their own wordlist rather than relying on public ones. Removing the backup.zip also removes this attack path.

Remediation Priority Order

The correct fix sequence isn't "remove all findings" — it's triage by actual risk:

1. Immediately remove backup.zip and config.bak from the web root. Assume they have been downloaded. Rotate any credentials contained in them. Treat all credentials in config.bak as compromised.
2. Rotate the git credential in .git/config and restrict .git/ directory access via web server config (Deny from all in .htaccess, or nginx location block). Audit git history for other sensitive files committed and deleted.
3. Disable /api/v1/debug in production. Debug endpoints should be gated by environment variable (DEBUG=false in production), not path obscurity. If the endpoint must exist, require authentication.
4. Restrict /admin to known IPs and add MFA. The admin panel path is not a secret — don't treat obscurity as protection.
5. Establish a web root audit process. Any file in the web root that isn't explicitly part of the deployed application should not be there. Add a post-deploy check that compares web root contents against the expected file manifest.

SecurityClaw's ffuf skill can scan your own web properties against an expanded wordlist set before an attacker does — producing a prioritised remediation list of everything currently exposed to enumeration.

For practical web security methodology, the content discovery and information-gathering chapters in The Web Application Hacker's Handbook cover this attack surface thoroughly. Bug Bounty Bootcamp by Vickie Li includes an excellent chapter on content discovery methodology including recursive fuzzing and wordlist construction — directly applicable to the /api/v2/internal miss scenario.

SecurityClaw Scorecard: D16

D16 extends SecurityClaw's web-scanning category, now running 4 campaigns across content discovery techniques (Gobuster D12, ffuf D16) and vulnerability scanning (Nikto, WPScan, Swagger scanner).

2.0 seconds to find a backup file that breaks open the entire application. The backup.zip was there for months. The developer who created it has probably forgotten it exists. The attacker doesn't need to know it exists in advance — they just run the scan. The scan is cheaper than forgetting.