Hunting the Origin IP Behind AWS CloudFront

The moment I see CloudFront, Cloudflare, Fastly, or Akamai, I stop caring about the application.

The application isn't the target anymore

The origin is.

Every request passing through a CDN means I'm only seeing what the edge allows me to see. If I can identify the origin IP, the entire assessment changes. I'm no longer testing a CDN-protected application. I'm talking directly to the infrastructure running it.

This engagement started exactly like that.

Instead of opening Burp and spraying requests everywhere, I started with infrastructure recon. A bit of Censys, Shodan, certificate correlation, historical DNS, and passive fingerprinting later, I had what looked like the production origin.

Finding an IP isn't the win.

The interesting part is proving it's actually the backend.

A few curl requests later, the headers made it obvious. The public domain terminated at CloudFront, while the discovered IP responded straight from the backend. Different headers. Different fingerprint. No CDN in the request path.

At that point, the goal changed.

I wasn't enumerating the application anymore.

I was enumerating the infrastructure.

The next step was replaying identical requests through both paths. One through the CDN. One directly to the origin. That's where things started getting interesting.

Routes returning 404 through the public domain came back with 200 OK on the origin. Response headers changed. Routing changed. Request handling changed.

That's the kind of differential that immediately gets my attention.

Every differential is another pivot.

Different responses usually point to different routing logic, origin-specific handling, unpublished paths, forgotten services, deployment drift, or backend functionality that never reaches the public edge. Whether any of those become exploitable comes later. The important part is knowing the backend and the CDN are exposing different attack surfaces.

Once the origin is in scope, the recon becomes much more interesting.

Now I'm looking for origin-only virtual hosts, backend APIs, unpublished routes, debug interfaces, alternate hostnames, cache inconsistencies, framework fingerprints, response normalization, edge-only filtering, and request transformations performed by the CDN before traffic reaches the backend.

One quick check I always perform at this stage is Host header handling. The backend accepted arbitrary Host values instead of rejecting unexpected requests.

Nothing groundbreaking on its own.

Bug bounty is rarely about a single observation.

Most high-impact findings aren't a single bug. They're a chain of small observations.

It's about collecting primitives.

Origin exposure.

Routing differences.

Host header behaviour.

Infrastructure fingerprints.

Each one tells part of the story.

Stack enough of those observations together, and the attack surface starts mapping itself.

This is where a publicly reachable origin becomes valuable. Once requests no longer pass through the CDN, security controls can be evaluated independently of the edge. Depending on the deployment, that can expose origin-only endpoints, unpublished pages, WAF policy differences, rate-limiting inconsistencies, cache behaviour differences, and direct origin traffic that never benefits from CDN-layer protections. On their own these observations may not be vulnerabilities, but together they provide the kind of infrastructure intelligence that often leads to high-impact findings.

Finding the origin IP was never the objective.

It was the beginning.

Most bug hunters ask,

"What does the application expose?"

I prefer asking,

"What am I not supposed to reach?"

That's usually where the interesting findings begin.