Read the breach story
before it happens to you.

Phase 1 — Exposed secrets surface

Subdomain enum returned git.example-corp.com. A HEAD /.git/config on the apex returns HTTP 200 — the .git/ directory is publicly readable. An attacker would clone the repo via git-dumper and grep for password=, AWS_, DATABASE_URL. Realistic time to first credential: under 4 minutes.

Phase 2 — Login surfaces & default credentials

Found admin.example-corp.com/phpmyadmin/ (HTTP 200). Default creds root:root, admin:admin, root:<empty> would be attempted first; on stale installs success rate is ~12%. Second target: WordPress login on apex — /wp-login.php returned 200, no Cloudflare in front.

Phase 3 — Database exposure paths

Backup file probe: HEAD /backup.sql.gz returned HTTP 200, 14.2 MB. The attacker downloads it directly — no auth needed. Parallel path: SQLi on /search?q= (no WAF detected; X-Powered-By: PHP/7.4 → known SQLMap success on this stack).

Phase 4 — Impact map

backup.sql.gz contains the full customer table (~120K rows incl. hashed passwords + emails). Hashes look like bcrypt cost=10 — ~3 days on a 4× RTX 4090 rig recovers the weakest 30%. Combined with the same emails appearing in breach databases, ~8% of accounts become directly takeoverable on partner services.

Phase 5 — Remediation (priority order)

→ Remove public access to .git/ (nginx location ~ /\.git { deny all; }).
→ Move phpMyAdmin behind VPN or kill it entirely.
→ Delete backup.sql.gz from web root and audit logs for prior downloads.
→ Force password reset on customer table; rotate any service creds in the repo history.
→ Add WAF / Cloudflare in front of /search and /wp-login.