Updated July 23, 2024. risk3sixty offers offensive security services that help combat the kind of breaches you'll read about below. Download our Penetration Testing ROI Calculator to get a clear ROI, payback period, and cost-benefit ratio for your efforts.
| Mitre ATT&CK Technique | ID |
| Brute Force: Credential Stuffing | T1110.004 |
In the last 10 years, there were 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.
More recent breaches include the January 2024 Microsoft breach, the Change Healthcare ransomware attack that may have affected 1/3 of the nation, and the Snowflake incident that may be one of the largest breaches in history.
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, the risk3sixty Offensive Security Team interacts with the internet "underworld" password breach information. There are a few requirements for this to make sense:
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:
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. For the purposes of this blog, we 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.
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 brute force attempts. |