Leaked Credentials – Where Do They Come From?

In this short article I wanted to take the opportunity to explain the concept of leaked credentials. While it’s perhaps obvious what they are, it’s not entirely obvious how they end up as “leaked.”

In our managed threat intelligence service Attack Prediction Service (APS), we help our customers monitor various darknets (e.g., Tor, ZeroNet, I2P), forums, and marketplaces. We’ll often come across what we define as leaked credentials, and they’re typically derived from one of the following categories:

  1. Username and Password Combinations
  2. Authenticated Session Cookies
  3. API Keys and Other “Secrets”

Username and Password Combinations

The most common occurrence is Category (1), username and password combinations. They are typically found in malware stealer logs, marketplaces, combolists, or from breaches.

Malware Stealer Logs

When found in malware stealer logs, it’s usually possible to exactly identify the infected computer, geographical location, affected user, and all other details related to the malware infection. Matches against stealer logs should be considered very important to investigate and respond to.

Criminal Marketplaces

When leaked credentials are found on marketplaces (e.g., Russian Market, 2Easy), we’ll typically only see the associated domain with the leaked credentials. To find the affected user it’s necessary to purchase the item from the marketplace. Truesec does not purchase items from the market.

However, it’s usually possible to extract meaningful context by looking at other potentially related domains that the user in question has visited. This contextual information and human analysis often mean we can pinpoint a likely timeframe for infection, other domains a user may have visited that can be looked for in proxy logs, etc.


Sometimes, threat actors find a vulnerability in a publicly accessible service that enables extraction/dumps of databases (including usernames and password combinations). While often salted and hashed, passwords can be cracked, and they often are. Cracked passwords usually end up in combolists.

Another situation where you may end up with leaked credentials is through actual intrusions. Threat actors will often dump credentials from breached organizations as this may yield sets of credentials to use in other attacks. Clearly, it’s not as easy to discover this type of leaked credential unless the threat actor decides to sell the accounts or otherwise make them available to the criminal underground.


Combolists are combinations of usernames/passwords and are, unfortunately, quite unreliable when it comes to origin infection. They are, however, often from real incidents but are usually recycled and republished many times. Having access to historical records, as Truesec does, it’s often possible to understand if the combination is unique or recycled.

Hacked computers will yield leaked credentials through malware stealer logs.

Authenticated Session Cookies

From malware stealer logs, authenticated session cookies can be derived. These are usually related to web browsers where a user has authenticated against an application, and the browser has configured and stored a session cookie that validates the user’s requests.

If these are stolen, it’s possible to “become” the user without having to re-authenticate. Even if an account is protected with MFA, a stolen session cookie could allow an attacker to bypass these controls.

Thus, stolen session cookies are very important to quickly remediate and investigate since they may have been used to bypass protective countermeasures.

There are a number of ifs and buts regarding the use of stolen session cookies, and a number of initiatives have been created over the years, such as token binding and, most recently, Device Bound Session Credentials DBCS.

API Keys and Other “Secrets”

Finally, we have API keys and other stored secrets commonly used when integrating services and applications. On their own, it’s usually quite difficult to determine if a string of characters is a key or secret, but here, context can be helpful in identifying real API keys and secrets. It’s not entirely uncommon to find these types of secrets in code repositories meant to be private, but accidentally made public or where a secret was never meant to be included in the code… but still was.

Truesec typically monitors for brand mentions and examines the surrounding context, which could reveal potential keys or secrets when viewed through a “bigger lens.”

The End

That concludes our little exploration of the concept of leaked credentials and how they come into this world of ours. When was the last time you checked for leaked credentials? Have you? If not, perhaps this could move you towards that objective!