$XXX Bounty💵, How I Chained a Leaked AWS Secret Key into a Full Subdomain Takeover

Hey, I’m M0n3m👋🏻 — and this is the story of a bug I almost gave up on. Almost.

It all started like any normal recon session… But ended with a Subdomain Takeover, a bounty, and a lesson I’ll never forget.

So grab your coffee ☕, sit back, and let’s dive in.

Phase 1 — Subdomain Enumeration

The first phase was subdomain enumeration. I started by collecting results from several online sources:

• [https://securitytrails.com/](https://securitytrails.com/)
• [https://subdomainfinder.c99.nl/](https://subdomainfinder.c99.nl/)
• [https://shrewdeye.app/](https://shrewdeye.app/)

I gathered everything into a file: old_subs.txt

Next, I used UniDig, which you can download from:

👉 https://github.com/UniShotProject/UNIDIG

I ran the following command to merge all online results with UniDig’s scan output:

./unidig.sh -d example.com -f old_subs.txt

This generated: all_subdomains.txt

Finding the Live Subdomains

To filter out the live hosts, I used httpx from ProjectDiscovery:

cat all_subdomains.txt | httpx >> live_domains.txt

Now I had a large list of alive domains — too many to inspect manually. So I used Nuclei’s headless mode to take screenshots and get a quick overview of what services each domain was running:

nuclei -headless -id screenshot -V dir='screenshots' -list live_domains.txt -silent

And this is where things got interesting.

The Suspicious Login Page

While reviewing the screenshots, one particular login page stood out. I opened it directly:

https://something.example.com

My first attempt was to try default credentials like:

• admin:admin
• test:test
• root:root
• …and so on.

Nothing worked.

So I decided to inspect the page source — and that’s when I found something shocking.

The Surprise: AWS Access Keys in the Page Source

Inside the page source, I discovered:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY

This was extremely unexpected.

I exported the keys to test them:

export AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY>
export AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY>
export AWS_DEFAULT_REGION=us-west-2

Then I checked if the keys were valid:

aws sts get-caller-identity --output json

And yes — the keys worked:

{
    "UserId": "AIDAXXXXXXXXXXXXXXXX",
    "Account": "13XXXXXXXXXXX",
    "Arn": "arn:aws:iam::130XXXXXXXXXXX:user/XXXXXXXXXXXXXXX"
}

But good things don’t last 🥲, The permissions were very limited.

But still, this was a critical leak, so I reported it.

📬 10 Days Later — Report Accepted… or Not?

After 10 days, the report was triaged and marked as valid.

But don’t celebrate yet.

20 days later, I received a second response saying:

The domain where you found the keys does not belong to us. It was actually a stale DNS record.

This was disappointing at first — but then everything clicked.

The Realization: This Is a Subdomain Takeover

If the DNS record is stale, it means:

• The company no longer owns the IP.
• The subdomain points to an abandoned host.
• Anyone could claim that resource.

That’s exactly what defines a Subdomain Takeover.

For clarity, here’s a quick explanation:

What Is Subdomain Takeover?

It happens when:

• A subdomain (hostname) points to an external service
• But the company no longer owns or controls that resource
• Through a CNAME or even an A record, like in my case

This means an attacker could take control of the subdomain.

Final Outcome

After reconsideration, the company responded again:

“I’ve discussed this internally, and you are right — this was basically subdomain takeover. Hence, triaging the report.”

Boooom🔥. The vulnerability was accepted as a Subdomain Takeover and I received a bounty reward.

Final Advice

Always stay sharp. Never stop investigating. Even if a finding seems small at first, always try to understand the bigger picture — it might lead you to a much more impactful vulnerability.

This was my story for today. Maybe the next big one will be your story.

Keep hunting. 🚀