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 of the breadth of these attacks and 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.
On specifically 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 must be comfortable with the outcomes of this type of reconnaissance.
- 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 it is 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 makes having a source of breach data for engagements quite easy, 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 credits only cost $3 at the time we published this blog
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:
-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 for the purposes of this blog, 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:
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.
|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 brute force attempts.|
Leave A Comment