Hi, let me introduce myself — I'm Kanishka Khandelwal , currently working as an Associate Security Engineer, and apart from my day job, I spend most of my time doing bug bounty.

While doing bug bounty, many people ignore recon because it doesn't always give instant results.

But this experience changed my mindset completely.

Recon is not useless — you just haven't connected the dots yet.

This is a story of how a simple response analysis during recon helped me identify a platform, discover an admin panel, and ultimately achieve a full admin panel access.

🎯 Initial Testing

I was testing a target (let's call it example.com).

As usual, I started with:

  • Browsing the application
  • Intercepting requests using Burp Suite
  • Testing common functionalities

My Burp Suite was capturing all HTTP requests and responses in the background.

At first, nothing impactful showed up.

No XSS, no SQLi, no obvious bugs.

🤔 When Nothing Works… Go Back to Recon

Since I couldn't find anything directly exploitable, I decided to do something most people skip:

👉 Carefully review all captured HTTP requests and responses

This step is underrated — but extremely powerful.

🔍 The Turning Point — Interesting Endpoint

While reviewing traffic, I came across an endpoint:

POST /otp-verification

This looked like a normal OTP-related API.

But the response caught my attention.

⚠️ Information Disclosure in Response

The response wasn't just returning OTP status.

It was exposing a lot of internal details like: Site name ,business name, store owner name, address, city, and other configuration data

None

And among all this… one value stood out:

"accessKey": "XXXXXXXXXXXX"

This looked important.

Not just random data — something internal.

🧠 Recon on the accessKey

Now the real recon started.

I asked:

  • What is this accessKey?
  • Where is it used?
  • Is it platform-specific?

After researching and digging deeper, I found something interesting:

This key is used by an e-commerce platform to uniquely identify stores.

The platform was a renowned B2B e-commerce service provider.

💡 Why This Was Important

Without this small piece of information (accessKey), I would never know what backend platform the site was using.

And once you know the platform…You unlock a whole new attack surface.

📚 Deep Dive Into the Platform

I started researching about that B2B e-commerce service provider:

  • Documentation
  • Public repositories
  • Deployment structure

During this, I learned something critical:

👉 Every store has a separate admin panel

Usually hosted on subdomains like:

admin.example.com

🚪 Discovery of Admin Panel

Until now, I hadn't even checked for an admin panel.

But after this insight, I tried:

👉 admin.example.com

And…

💥 It existed.

It was publicly accessible and showed a login panel.

🔑 More Recon —

While analyzing publicly available documentation and repository artifacts, I discovered default administrative credentials used in community/self-hosted deployments.

This was a critical finding.

None

⚡ The Test

Now the question was simple:

What if the target is still using default credentials?

I tried logging in using those default creds.

And…

💥 Login Successful

🚨 Admin Panel Access Achieved

I was able to access the admin panel.

At this point, I immediately stopped further actions to follow responsible disclosure.

None

No data was accessed or modified.

💥 Impact

Since I was able to successfully log in as an admin, I effectively had full administrative privileges over the platform.

This included the ability to:

  • View, update, or delete any user data
  • Access customer account details and purchase history
  • Monitor orders, transactions, and revenue
  • Manage products and store configuration
  • Track orders and user activity
  • Modify admin credentials

👉 In short, complete control over the entire application and its data, leading to a full admin panel access.

Final Result:

👉 Full Administrative Control

🧩 Root Cause

This vulnerability chain existed because of multiple issues:

  1. Excessive information disclosure in API response
  2. Exposure of internal identifier (accessKey)
  3. Publicly accessible admin panel
  4. Use of default credentials
  5. Lack of proper access restrictions

🧠 Key Learning

This is the most important takeaway:

If I had ignored that one response… this bug didn't exist.

👉 Recon helped me identify the platform 👉 Platform knowledge led to admin discovery 👉 Admin discovery + default creds = takeover/admin panel access

🔥 Final Takeaway

Recon is not about finding bugs directly. It's about finding clues.

And those clues, when connected properly, lead to real impact.

🙌 Conclusion

If you're doing bug bounty:

👉 Don't ignore responses 👉 Don't ignore small leaks 👉 Don't skip recon

Because sometimes…

The biggest vulnerabilities are hidden in the smallest details.

🏁 Disclosure & Reward Experience.. ??

The vulnerability was reported responsibly with complete details and proof of concept. However, despite multiple follow-ups and attempts to reach out (including DMs), there was no response or acknowledgment from the team.

After some time, I noticed that the admin panel credentials were changed, which indicates the issue was fixed silently — but without any communication or recognition.

Honestly, that part can be frustrating.

But this is also a reality of bug bounty.

What matters most is:

  • Reporting ethically
  • Not exploiting beyond proof
  • Respecting user data and privacy

I did not modify, access, or extract any sensitive data at any point during testing.

👉 And I strongly suggest the same to everyone: If you discover something like this, do not misuse it. Stay responsible.

🙌 THANK YOU

If you found this helpful, feel free to connect:

🔗 LinkedIn: https://www.linkedin.com/in/kanishka-khandelwal-a49050263/

Or drop your thoughts in the comments 👇