1. Fuzz subdomain VHOSTS viaFFUF
2. PureDNS for direct DNS enumeration.
3. I also went through passive collection of subdomains by using tools such as subfinder and google dorking (site:Sister-REDACTED.com ).
4. Looked for related sister sites via:

• FOFA
• SHODAN (Via Favicon hash search)
• Fuzzing TLD via PureDNS (ex: REDACTED.FUZZ )

5. Scanning ports via Masscan & RustScan

• I stopped over-relying on one tool and lowered the maximum packet rate as it typically leads to inconsistent results.

6. Scrape endpoints from GAU , WayBackURLS , Dorking

• When dorking I use the URL Extractor extension to parse all the URLs from google searches as I dork.

7. Exposed secrets by searching target-specific keywords on Github , PostMan , etc.

Subdomain Analysis

After cleaning up and collecting the list I realized there weren’t many subdomains this company offered. However there were two that stuck out to me the most:

• staging.Sister-REDACTED.com
• testing-ignore.Sister-REDACTED.com

The testing-ignore subdomain was inaccessible and had no digital footprint as to what its purpose was or how the website looked (was not archived in the Wayback Machine).

I shifted my focus to the staging server, I realized account takeover (ATO) may be possible if I registered an account using an email address that existed in production but not in staging. This would only work if both servers were using the same JWT signing keys. This is a common technique explained more in-depth here: https://sandh0t.medium.com/the-bad-twin-a-peculiar-case-of-jwt-exploitation-scenario-1efa03e891c0.

Black Box Reverse Engineering

Unfortunately, when registering a new account there’s an email verification sent-I could not bypass this. But then I caught myself falling into autopilot. I was just following the same checklist everyone runs through.

Why was I even trying to register with someone else’s email on staging in the first place?

Well, I told myself my goal was to obtain a JWT from staging and replay it against production. But I was getting ahead of myself, I didn’t even examine the decoded JWT, what if there wasn’t even an email field at all?

I decoded a JWT from an authenticated login on staging and it looked like this:

Side Note: If you’re a penetration tester make sure to NEVER put a JWT into a public website, regardless of what their claims are.

All decoding or tedious tasks should be done on your own machine, you can use self-hosted services such as CyberChef.

Okay… so the JWT does have the email field, but what if the server isn’t even using it. If you look closely you’ll notice the id field, what if the server is relying on this over the email field?

I confirmed this by registering multiple accounts on production and noticed it go from 50,612to 50,613, 50,614, etc. For further verification, I logged in, changed my email and noticed my JWT still had my old email address in it even though my account settings displayed my new updated email address.

Okay-that confirms my suspicions, the server isn’t even querying the email claim in the JWT anyway, it’s querying the id claim.

Furthermore, when I did attempt to use the staging JWT on prod it was denied complaining about an invalid signature. Looks like prod and staging used separate signing keys for their JWT tokens.

Poor Isolation Breakthrough

Before I gave up I clicked around on the staging domain and everything pretty much looked the same-until I went to profile settings and realized it displayed someone else’s email !

So we have ATO? Not quite. If I sent a password reset request I would see my account details and the reset would be done on my own account (within staging).

I decided to poke at the tech stack being used by this company, some common techniques use the Wappalyzer chrome extension, reading response headers sent back from the web server, and skimming any specific keywords in the JavaScript files.

Turns out this website’s tech stack was using Kubernetes, Nginx, and Envoy proxies!

Why is this important you may be asking...? Well Kubernetes can get very complex and if you’re not careful, especially when isolating the workflows for prod and staging can lead to mixups.

So to understand what may have caused this vulnerability we need to see a simple example of how user requests are handled.

Envoy runs as a config alongside each pod, meaning every request in and out of the cluster passes through it first. It reads the routing rules defined in its sidecar profile and decides where to send the traffic such as to the staging or prod clusters. It’s great for service mesh control, but one bad route and you’re now leaking traffic across environments.

I think this company’s staging servers had separate envoy proxy configurations for different API routes.

For example, in the staging server when I sent the password reset it may have internally routed my request to an internal endpoint within the correct staging cluster.

However, in the staging server, when I tried to view my user information the envoy proxy handling my request may have routed the request internally to a prod cluster instead of a staging cluster.

Understanding the Internal Tech Stack

I also realized a huge gap many bug bounty hunters have in their methodology: they’re so quick to perform subdomain enumeration, ports, etc they forget to take a step back and look at the dead domains too.

The unreachable subdomains are sometimes scraped from the domain’s SSL certificates and may hint at internal subdomains that are used by the company internally.

When looking through subfinder’s output again of both the main website www.REDACTED.com and the third party (sister site) www.sister-REDACTED.com I noticed something that stuck out:

github.REDACTED.com
bitbucket.REDACTED.com
github-staging.Sister-REDACTED.com

Interesting… this hints at the possibility of the company using their own self-hosted Github servers.

This information came in handy down the road and without it I may have been unable to piece together what could’ve caused this vulnerability.

Theory

Remember earlier when we looked through subfinder’s output and spotted github.REDACTED.com and github-staging.Sister-REDACTED.com? That strongly suggests this company is running self-hosted GitHub instances for their development workflow. This is highly likely because we saw it on both the third party sister site AND the main domain.

This matters because companies that self-host their own Git infrastructure almost always have CI/CD pipelines tied directly to it. These can be Github actions, webhooks, or automated deployments.

For example, when a developer opens a PR and it gets merged into main, these pipelines typically spin up or redeploy staging environments automatically to mirror production.

I think that’s exactly what was happening here. The staging and production servers were being set up through some automated deployment pipeline that triggered whenever the production code changed. For example, let’s say a developer at this company made a simple change to an HTML file, opened a PR that got approved, and merged it into main.

I suspect these automated pipelines were spinning up staging environments correctly but failing to update all of the Envoy routing configurations for certain endpoints. Because of this, my staging user ID was being mapped to a production user ID due to poor isolation between the two environments.

For example, let’s say after a new PR was merged to the main branch a pipeline ran that went through the production sidecar profiles and ran simple .replace() on them but failed to do it correctly for one of the endpoints for some reason.

Impact

We now have leakage of mass PII of all accounts, we can create a script to register accounts on the staging subdomain, and then scrape the account information associated with it.

We also could mass create accounts on staging with an email address we own -> check account details -> check if there are any patterns such as [email protected] and use that JWT to fuzz in hopes of finding any that are admin-restricted to further our attack surface.