From Exposed API Keys to Account Takeovers

Hey Hackers, I am Parth Narula. A penetration tester, bug hunter, red teamer and overall a security researcher. I live for those moments where a bit of out-of-the-box thinking cracks open a critical vulnerability.

A simple Web Archive search revealed active API keys that provided direct access to REDACTED accounts, turning a historical credential leak into a critical account takeover vulnerability.

As many of you know, I have a strong passion for API testing. During my testing of REDACTED, I came across a Swagger UI and started exploring it for potential vulnerabilities. While the implementation appeared well secured, it exposed multiple interesting endpoints related to deployments, logs, and other functionality.

After spending some time with the API, I decided to shift my focus toward the Web Archive :)

While reviewing archived URLs, I searched for common indicators of sensitive information such as tokens, api, api_keys,api, v1, v2, v3, etc.

To my surprise, several archived URLs contained API keys directly inside the api_key= parameter.

At first glance, this looked like another secret exposure issue. However, finding a key in an archive does not automatically mean it is still valid. The next step was determining whether any of these credentials were still active.

I tested multiple exposed keys and noticed that some of them returned errors such as 401 Unauthorized, 403 Missing Permission, Trial Expired, or Invalid API Key. That was expected, since old credentials are often revoked or no longer usable.

However, few keys returned valid responses, and that immediately caught my attention.

I took one of those working keys and supplied it through the API key authorization mechanism available in the Swagger interface. After clicking the Authorize button, I started testing accessible endpoints.

One of the first endpoints I checked was viewing logs: GET /v3/logs?api_key=REDACTED

The response immediately returned data.

At this point, the issue moved from historical information disclosure to active credential compromise. The API key was still valid, had not been revoked, and was providing direct access to account resources. In other words, the Web Archive was effectively exposing working authentication credentials.

To understand the extent of access, I continued testing additional endpoints like creating logs at: POST /v3/logs?api_key=REDACTED

{
"name":"company_test",
"color":"blue",
"environmentName":"corp_test",
"disabled":"true"
}

{
"name":"company_test",
"color":"blue",
"environmentName":"corp_test",
"disabled":"true"
}

I clicked the Try it Out button in Swagger and executed the request. The API returned a 201 Created response, indicating that the operation was successful.

To verify the result, I queried the logs again and could clearly see the newly created entry. This confirmed that the exposed API key was not limited to read access and could also be used to perform actions within the affected account.

This confirm that I was able to abuse those APIs keys and increased the impact.

Lesson Learned

• Always check historical sources like Web Archive during reconnaissance.
• Never assume an exposed API key is invalid without testing it.
• Do not stop at finding a secret, verify what permissions it actually has.
• Simple credential leaks can lead to critical impact when secrets are not rotated or revoked.
• Looking beyond the current attack surface can uncover vulnerabilities that have been publicly exposed for years.

Hope you learn something new. Follow for more amazing articles and give claps if you like this one :)

Need expert pentesting services? visit https://scriptjacker.in or let's collaborate on your next project! 🤝

Want to learn from my experiences? Check out my articles on https://blogs.scriptjacker.in