With our latest release, Push takes TI data with stolen credentials sourced from criminal forums and compares it to the actual credentials still being used across customer environments, alerting on validated true positives only to cut through the noise.
With our latest release, Push takes TI data with stolen credentials sourced from criminal forums and compares it to the actual credentials still being used across customer environments, alerting on validated true positives only to cut through the noise.
While striking gold sure feels good, mining for gold doesn’t. All that sifting for a few grains of value.
If you’ve ever tried to make use of a TI feed on stolen credentials, you’ll know exactly how this feels. Yet the need to identify signal from noise is obvious. When it matters, it really matters.
While there’s an enormous volume of TI data available on stolen creds, data trustworthiness is much harder to establish. Are these creds still in use? Are they in use on company applications? And without trust in the data, it’s harder to take action.
A recent review of TI data by Push researchers found that less than 1% of stolen credentials included in threat intelligence feeds from a multi-vendor data set was actionable.
We set out to solve this problem at Push and ended up flipping the script on conventional approaches to evaluating TI on stolen credentials. (Lay down your shovel, friend.)
With our latest release, Push takes TI on stolen credentials sourced from criminal forums and compares it to the actual credentials still being used across customer environments, alerting on validated true positives only.
Call it the “dirt in, gold out” model for TI feeds.
In this article, we’ll cover some of the challenges with threat intel on stolen credentials, why the rise of infostealers has added urgency to determining the trustworthiness of this category of threat, and how Push’s approach of validating stolen credentials cuts through uncertainty.
Why actionable intel on creds is hard
Both threat actors and security teams have ready access to information on stolen credentials, with obviously opposite goals. There is now a robust economy for this data, driven in part by both the success of attacks using stolen creds, and the SaaS-ification of business software. In the past, security teams could audit their Active Directory passwords. Today, many if not most corporate credentials are stored in apps that do not provide that level of visibility.
So when it comes to stolen credential TI, the challenge is not the availability of data — dozens of vendors already do the hard work of establishing presences in these forums in order to collect and disseminate information on credentials such as usernames, passwords, cookies, and API keys that have been stolen through data breaches, phishing attacks, infostealers, or other methods.
Too much data, not enough context
Rather, the difficulty is determining which information to act on. Finding the gold, in other words.
TI on stolen credentials often suffers from:
Data overload: The double bind of TI is especially evident here — once you know about a potential true positive, you feel obligated to investigate, yet the scale of the information and the high incidence of outdated or incomplete information can pose a risk of desensitizing the SOC or wasting dozens of hours of time investigating what turn out to be false positives, especially when that time could have been better spent on in-depth threat hunting.
Minimal context: Intelligence is often incomplete or out of date. TI feeds may present stolen passwords as new breaches, but the data is actually a recycled combolist (aggregated list of lists) rather than a new incident. In some situations, infostealer threat intel can stem from a personal device that was compromised and once accessed corporate assets, but is no longer active or using that password. Then there are the false negatives, where you get an alert for stolen credentials on a core app following a breach, and the creds are no longer in use there — but they are still being used on a different high-value app.
In evaluating threat intelligence data recently at Push, our researchers analyzed 5,763 username and password combinations that matched domains in use by Push customers. We found that less than 1% of the credentials in the multi-vendor dataset were true positives — meaning that the suspected stolen credentials were still in use by employees at those organizations. In other words, 99.5% of the stolen credentials we checked were false positives at the time of review.
Despite these challenges, there is still a strong case for incorporating TI on stolen creds into your cyber defense practice for one important reason: Attackers are increasingly using stolen credentials to compromise organizations.
The commodification of stolen creds in the age of infostealers
A few headline stats on how ubiquitous stolen credential exploitation has become:
The 2024 Verizon DBIR found that 79% of web application compromises were the result of breached credentials.
Researchers at IBM identified a 71% year-over-year increase in cyberattacks using stolen or compromised credentials. This jump made stolen creds the No. 1 source of initial access for cyberattacks in their study. They also found a 266% uptick in the last year in the use of infostealers — malware designed to capture passwords, cookies, and other credential data.
Researchers at threat intelligence provider Recorded Future found a 135% increase last year in the number of harvested credentials among their data sources, and a 166% increase in credentials that included cookies, providing an easy way for attackers to bypass MFA protections.
Meanwhile, Mandiant’s last two M-Trends reports found that stolen creds were the third and fourth most-used initial intrusion method of the last two years. Cisco Talos researchers found that the use of valid accounts was the second-most common attack technique they observed last year.
Push’s own review of the 25 most notable public identity-related breaches over the last year found that 23 were tied to stolen credentials.
What’s not immediately obvious from these statistics is that not only are credential-based attacks becoming more common, but they’re also becoming easier for attackers to execute.
IBM X-Force researchers have found that credentials for cloud accounts account for 90% of all cloud assets for sale on the dark web, making them readily accessible. Price tags can be as low as $10.
The rise of infostealers has supercharged the stolen credential marketplace
One category of threat — infostealer malware — has emerged as an especially successful avenue of compromise. While infostealers aren’t new, they have developed alongside what is now a robust economy for stolen credentials (think: dedicated Telegram channels advertising stolen data from the most popular infostealers), making them a fruitful option for attackers. For a deeper dive on the rise of infostealers, see our previous article.
Once attackers gain possession of stolen creds, they have plenty of soft targets. For organizations with a large amount of SaaS — a percentage of which will always be unmanaged shadow IT or freemium — the risk is heightened because all attackers need to do is log in to potentially hundreds of services, dump the data they find (including additional creds in some cases), and profit.
In other words, the average attack path for SaaS is shorter and occurs in-app, often using legitimate workflows, making it therefore harder to detect than traditional network exploits. We discuss this phenomenon in our shifting detection left article.
Our take: We haven’t yet seen the peak of identity attacks that leverage compromised credentials. The opportunities for attackers are too numerous, and front-line defenses like MFA are still not widely enough enforced, particularly on unmanaged apps used for work.
Push Security’s own research has found that 37% of corporate identities are using passwords with no MFA. For attackers in possession of stolen creds, these are easy marks.
How Push detects stolen creds with high confidence
Now let’s take a look at how Push’s approach to this problem is different.
If you’re not familiar with the Push platform, a bit of context will be useful here: Push uses a browser agent deployed to employee browsers (we support all major browsers) to prevent, detect, and block identity attacks.
In addition to enforcing security controls in the browser, Push also assesses the strength of end-user passwords by creating and analyzing a truncated, salted SHA256 hash of the password for a given account. This is called a password fingerprint. These k-anonymized fingerprints are never seen by Push’s back-end and exist only in local browser extension storage.
This approach gives Push a directly observable source of truth for corporate credentials, and that data point turns out to be the key to flipping the script on how threat intelligence on stolen credentials is typically evaluated.
In the past, evaluating TI on stolen creds meant performing traditional intelligence assessments, such as confidence level based on factors like the intel source and whether the data was still current. Only after determining whether the information was high-confidence could you take action.
It’s worth noting, too, that the age of TI alone is not enough of an indicator to determine whether to take action. With the Snowflake breach earlier this year, we saw how even older credentials posed a threat of account takeover where these creds were still in use. In the case of Snowflake, the attacker used credentials sourced from historical infostealer campaigns, some dating as far back as 2020.
Forget about time-consuming manual TI validation and get straight to the true positives
With Push, the platform now can analyze threat intelligence on stolen credentials and alert when there’s a validated match among current credentials in use in your environment. This method works regardless of the source of the data or its age. This method also finds the needles in the haystack — situations where threat intel flags a stolen credential on one app, but that credential is also in use on several other apps.
Here’s how it works:
Push receives TI on stolen credentials from vendor feeds.
For each customer environment, Push checks for customer domains in the data set.
When suspected stolen creds for a customer environment are present, Push hashes and salts the passwords and then sends those fingerprints to the relevant browser agents for comparison.
If the stolen credential fingerprint matches a known credential fingerprint observed to be in use by the Push browser agent, the platform returns a validated true positive alert. Note that Push can alert on a validated true positive regardless of which platform the TI source indicated was the source of the stolen cred, allowing you to find those compromised credentials in use across any of your apps.
You can choose to receive alerts for this detection via webhook, ChatOps notification, or in the Push admin console.
From there, security teams can take action to reset passwords, identify potentially compromised devices, or perform other investigations.
By comparing all possible matches to only those credentials that are still in use, Push eliminates time-consuming validation exercises. In essence, the provenance of the intel no longer matters; only the true positives do.
Try Push for yourself
The validated stolen credential detections feature is available at no additional cost for all Push customers. If you’d like to explore the platform yourself, you can sign up or request a demo.
