Farming Breached Password Data with Dehashed

July 01, 2022  

I originally developed this blog for the Renegade Labs team at risk3sixty, and have cross-posted it here for replication of my personal work.

Password Breach Data

Mitre ATT&CK Technique	ID
Brute Force: Credential Stuffing	T1110.004

Every year countless data breaches occur.

From 700 Million LinkedIn users’ information getting leaked sometime between 2020 and 2021, to at least 500 million Yahoo accounts information being breached in 2014, to the notable 2017 Equifax data breach which impacted millions of individuals, it’s safe to say that breaches are a part of the everyday news cycle in the present day.

These breaches contain a wide variety of data that has a variety of use cases. Social security numbers and credit card information can lead to fraud, age information and phone numbers can lead to targeted phishing attacks, and usernames and passwords can lead to… what exactly?

Have you ever wondered what happens to this data after it’s leaked? What about the private breaches that are not publicized but rather are sold on forums?

This dark world is one that’s extremely interesting and often misunderstood. Unfortunately, risk3sixty is not a threat intelligence company, so large knowledge on the breadth of these attacks an their outcomes is out of our wheelhouse. Our friends at Recorded Future however likely have more information that can help answer some of those questions for you.

With that said, let’s take a step back and look at how penetration testers and adversaries alike take advantage of data breaches during engagements.

Engagement Process

On specific targeted engagements, Renegade Labs operators interact with the internet “underworld” that is password breach information. There are a few requirements for this to make sense:

• An organization’s risk profile has to line up with the tactics in use.
• An organization has to be comfortable with the outcomes of this type of reconaissance
• An organization may need to be open to password spraying attacks with breach data to ensure that the project provides the most real-world value
• Lastly, breaches happen. The organization should not punish users for their information being leaked. Often times it is solely out of their control.

To operationalize this process (and keep it as legitimate as possible), we heavily utilize the Dehashed service for information retrieval.

Dehashed presents a useful and fairly cost effective API for data retrieval. This allows us to quickly and reliably have a source of data for engagements, instead of trying to keep up with forum posts, leaks, and the ethical headaches that coincide with these efforts.

To access the Dehashed API, a vali subscription is needed:

Additionally, one must purchase API credits to use with their account. For reference, 100 API creds costs only $3.

Once your account is setup and loaded with valid API credits, the API reference documentation can be used, from which you find a series of options to meet your needs.

Let’s say we want to query all information Dehashed possesses on a username of bob. We can do this through the following Curl request:

curl 'https://api.dehashed.com/search?query=username:bob' \
-u 'email:api_key' \
-H 'Accept: application/json'

Note: you’ll likely want to write collected output to a file to avoid wasting API credits

Let’s issue the request, and view the output using jq. Unfortunately, we really don’t want to leak any information that is sensitive and technically paywalled, so the image below is heavily redacted. What one can note however are the fields contained within the output:

The parameters that stand out are:

• email
• ip_address
• password
• hashed_password

In our case, the results were limited to 100 entries per the API specification, however there are ways to query more data, which does have pricing implications.

And that is how simple it is to use Dehashed to gather data! You might see why it has quickly become one of our favorite services for engagements. Generic queries with information like a simple username of bob produce much more information than is useful, but on targeted engagements the data acquired from the service can be highly beneficial.

Mitigations

From Mitre

Mitre ID	Mitigation	Description
M1036	Account Use Policies	Set account lockout policies after a certain number of failed login attempts to prevent passwords from being guessed. Too strict a policy may create a denial of service condition and render environments un-usable, with all accounts used in the brute force being locked-out.
M1032	Multi-factor Authentication	Use multi-factor authentication. Where possible, also enable multi-factor authentication on externally facing services.
M1027	Password Policies	Refer to NIST guidelines when creating password policies.
M1018	User Account Management	Proactively reset accounts that are known to be part of breached credentials either immediately, or after detecting bruteforce attempts.