Leaked Creds to Full Data Exfiltration: How One Endpoint Gave Up the Goods

🧠 Quick Context

Imagine uploading your PAN, mobile number, and personal details to apply for a loan — trusting that it’s safe behind OTP verification and firewalls. Now imagine all that data being accessible to anyone with a Burp Suite and a few minutes.

This wasn’t a single-user issue. It was a full-scale exposure of all users’ loan information due to poor authentication design and insecure API logic.

🛣️ The Road to Total Pwnage

This wasn’t luck. It took methodical testing and patient analysis. Let’s walk through the discovery — from login to complete backend compromise.

🧩 Step 1: OTP Auth? More Like Optional-Trouble Protocol

The application used PAN + mobile for login and OTP verification for access. During a login test, I intercepted the flow in Burp Suite and inspected the traffic closely.

Initial login — PAN + mobile number with OTP-based flow.

PAN submission request captured via Burp Proxy.

🫣 Step 2: The Base64 Blunder

While analyzing OTP submission responses, I noticed one endpoint returning a suspicious Base64-encoded string.

Decoding it revealed hardcoded credentials for an internal support account — including a plaintext email and password. This was a direct credential leakage vulnerability.

The request revealing encoded credentials in the response body.

Decoding Base64 revealed hardcoded credentials (never do this).

🔓 Step 3: Turning Credentials into Gold (or PII)

Using those leaked credentials, I logged into the internal admin API and received a valid AuthToken. The token had:

• No session binding
• No scope
• No tenant isolation

By altering user IDs in the requests, I could impersonate any user and access their loan information.

Auth token retrieved using leaked credentials — totally valid.

🔁 Step 4: Brute Forcing Like It’s 1999

The loan retrieval API accepted numeric application IDs. No CAPTCHA. No rate limit. No IP throttling.

Using a simple Python loop, I enumerated IDs and retrieved full records — complete with PAN, phone number, loan amount, and application status.

Burp Intruder results showing successful brute-forced loan IDs.

API response exposing full loan details with personal data.

🎯 Real-World Impact

• Mass PII and financial data exposure
• Unrestricted data exfiltration using public endpoints
• High fraud potential via impersonation and loan manipulation
• Loss of user trust and compliance violations

🧰 Tools Used

• Burp Suite Pro – for interception and replay
• Python Scripts – for ID enumeration & brute-forcing
• Base64 Decoder – for quick inspection of encoded payloads

🛠 Recommendations

🧠 Final Thoughts

This case reinforces a core truth: security failures often hide in plain sight. A single overlooked header, a misplaced token, or a careless Base64 string can compromise an entire ecosystem. Always validate assumptions — and never trust the client.