Exposed Credentials Guide: Not just in client javascripts || 101 case studies

This guide is NOT about:

A list of recon tools to finding exposed credentialsA list of payload for you to chug into a recon tool that will magically find leaked api keys

This guide IS about:

Where to run your recon toolsWhat are some potential niche areas for less competition and potential future research

Scanning for secrets in client-side JavaScript or suspicious endpoints? By all means, secrets get pushed into production all the time. After digging through 101 reports on exposed credentials, a total of 12 out of the 101 found credentials in JavaScript.

In addition, 17 out of the 101 reports found credentials on the company’s public GitHub page. By this proportion, these two categories account for a third of the reports! So, they must be a great place to mine for credentials, right? Just spin up a tool like Trufflehog, and we’d be set for $10,000 crits —

The good news is that this is indeed a good idea.
The bad news is that, precisely because it’s a good idea, everyone else is already doing it.

Exposed credentials have a high impact and are easy to fix, which means they get resolved much faster than other bugs. However, I still frequently come across multiple duplicates of high-impact findings. Furthermore, credentials pushed to production are often detected within days, if not hours. This clearly indicates that automation is constantly scanning targets for updates. Some reports — even from different hackers — use the same introductions and formats, making me wonder if the “writing report” section is also partially automated. (See this report from Snapchat and this report from Shopify as examples.)

The point is, I actually don’t recommend these areas for beginners. Or at the very least, don’t have unrealistic expectations. In most cases, client-side JavaScript and company GitHub repositories have already been scanned by thousands of other hackers. You’re unlikely to find anything valuable — perhaps just a Google Maps API key marked as informative.

I think the diagram below illustrates my point quite well:

Interestingly, 11 out of the 101 reports found secrets outside the company’s owned GitHub repository.

For example, in this report from Starbucks, an employee pushed files containing potential credentials for an SAP S-user to their personal GitHub repository, along with some StarbucksTest domain credentials. Ironically, because the researcher acted in good faith and refrained from directly accessing the sensitive data, the report was almost dismissed as informative for being “out of scope” and “unable to show impact.”

In another instance, one HackerOne employee accidentally included their personal access token in the build logs while contributing to Ruby, resulting in the credentials being publicly accessible in rubysec/rubysec.github.io. The token had public repo permissions and were able to perform admin actions over any public HackerOne repo.

Sometimes, it doesn't’ even have to be a github repository. If the employee is actively engaging in personal projects/contributions. You may just find an access token to Shopify’s github repository included in the env file of a newly published electron app. It was a never loaded in the app and clearly left accidentally by the developer, thus drawing the researcher’s attention.

Finally, in this report from U.S. Department of Defense, one of their contractor accidentally included the password to their Gitlab EE instance. The instance hosted only a few code commits but included a Jenkins instance, eventually resulting in a high severity.

What is the pattern here? Consider how many things have to go right (or wrong, from the company’s perspective) for a credential to be exposed in company-hosted assets:

A user accidentally commits the credentials.The credentials pass through senior developers’ review.The credentials bypass internal scanners (if any).The credentials are not lost in the build process (i.e., commit bots, automated workflows, or assistance tools that tend to override commit messages, build details, debug information, etc.).The credentials are not detected by GitHub’s built-in credential scanner (if enabled).

However, for a credential to appear in an employee’s personal repository or project, usually only one thing has to go right:

A user accidentally commits the credentials.

This step doesn’t even have to be manual — it could simply be a misconfiguration in the build process, such as improper Git push options, an incorrectly configured .gitignore file, etc.

As for third-party contractors, they may be more security-conscious than an individual working on a personal project. However, it’s difficult to hold them to the same security standards as the Fortune 500 companies they work for.

Attack Advice

We probably need some manual OSINT, for example:

Identify publicly known employees of the target company. Job search platforms like LinkedIn are great for this, as people often list their past and current positions there. General social media platforms can also be helpful. However, I can’t enumerate all OSINT techniques in this blog post — you’re better off learning from someone who actually know what they are talking about ;)Narrow down the employee groups to see whoever has active projects, whether contributing to an open source project or their personal projects, set up automation to listen there.Third party contractors are much more trivial to look for, since they almost always proudly announce the partnership on their company webpage.

14 out of 101 reports found secrets in third-party services. These are services that handle tasks such as building, debugging, analytics, and organizational management. They may also host custom support or communication channels for the target site as a service.

These exposures usually occur because developers are unaware of the trust boundaries of the third-party solutions they use or due to poor configuration. For example, in this report from MobiSystems, the researcher found an open Firebase database that allows arbitrary writes. There is also this report from Udemy, where the researcher found a public Jenkins dashboard under jenkins101.udemy.com, exposing source code and database schemas.

Some more exotic examples includes this report from U.S. Department of Defence, where a researcher found an endpoint hosting a TelePresence SX80, which apparently is an audio and video engine for large meeting rooms..? Regardless, the researcher found the default credential for this device and could have the power to access confidential briefings and room demonstrations.

The impact in this category varies greatly, likely due to differences in the services themselves. For example, discovering services related to staging environments, test data, or abandoned systems often results in lower impact findings. In this report from Unikrn, the researcher found a Rabbitmq instance with default credentials. However, since it’s used for staging, there is no sensitive data and was only awarded as a low. In this report from R3, the researcher found a exposed Prometheus instance. However, Prometheus is a service monitoring tool and only has access to other services’ states and some metrics, not actual data. Therefore it’s only awarded as a medium.

Attack Advice

Don’t be afraid to investigate out-of-scope assets. As we’ve seen, many of these third-party services are hosted under a different domain and may not be explicitly included in the target’s defined assets. However, scope is always negotiable, and sensitive information exposure is the easiest types of bugs to argue for inclusion. Even if you find secrets in a dumpster, as long as the dumpster is public and the secrets belong to the target site, there is a legitimate security impact — and such findings are usually rewarded.Conduct thorough secondary recon on the target. (I.e. not just all the endpoints under the application, but also investigate the contents of the links that point to different services)Also, a lot of poorly configured service seem involve guessable/default password for some reason (around 60% in this category of reports). So it’s good to keep a wordlist for that just in case.

Despite only 8 out of 101 reports falling into this category, I found it necessary to discuss it, as this area still relies almost entirely on manual OSINT. There is room for more research and automation.

In this report from Mozilla, a staff member accidentally shared an admin credential for a staging environment in the #trust-and-safety-eng Slack channel. While their Slack channels are not public, they can be accessed by an application and complying with their NDA requirements. Therefore, it was considered low-privilege attack scenario and received a high severity rating. In another report, Mozilla staff also posted code snippets for testing that contained hardcoded Jira api keys, again in one of their slack channels. There is also another report from Shipt where the developer posted internal-use Webhook urls onto stackoverflow and devtimes, allowing unauthorized writes to Shipt’s slack channels.

HackerOne seems to be prone to this issue as well, likely due to the nature of handling communications involving potential vulnerabilities. In this report, it appears that a HackerOne security analyst was going back and forth with a researcher while attempting to reproduce a vulnerability. During this exchange, requests containing session cookies were shared. This information was later disclosed publicly along with the report without being redacted, leading to a potential account takeover of HackerOne employees. Another report detailed a disclosed vulnerability report that included a proof-of-concept (PoC) video. The video unintentionally revealed undisclosed reports from other programs — likely because the hacker switched tabs and accidentally hit the wrong one while filming the PoC.

Some more exotic examples include the time when HackerOne’s live hacking event wifi password is exposed in a photo shoot. It prompted HackerOne to update their photography OPSEC guidelines. There is also this insane report from Stripo, where the researcher found a “non-revoked API key disclosure in disclosed API key disclosure report”. I have no words.

Attack Advice

It is highly recommended to sign up for developer forums, Discord, Slack channels, etc., as these are the places where technical discussions occur. However, most reports in this category may not be discovered in plain text — they could be hidden in images or videos, making it difficult to build traditional automation.

You would likely need to train an AI model for this task, but sourcing the appropriate training data poses a challenge. Additionally, your automation would need to focus on scanning for secrets related to your target, not the social media platform itself (for ex, scanning into the src )— otherwise, you may end up with numerous false positives.

Overall, I’m not entirely sure how to efficiently approach these cases at the moment. Perhaps one day, someone will develop a reliable scanner for this kind of detection.

Access Control Issues

9 out of 101 reports fall into this category: The classic IDORs, missing access controls on sensitive services, bypass to access admin portals etc. There is nothing too special here. Basically every bug class can find something to do with access control anyway.

Target Demographics

Very few reports are from tech companies in this research. Majority credential leaks seem to be coming from governmental agencies, or one of those large Fortune 500 corporations that you know they have 7 layers of management before getting anything done. They are also especially vulnerable to default credential attacks.

Some summary statistics of the Severity rating based on CVSS provided in reports. Issues missing severity are not counted, unless I felt comfortable in assessing it from the published report.

Source raw csv can be found here https://gist.github.com/Illoy-Scizceneghposter/f0e3a51df5c9f02d0a12288577a746ac