Detailed Look at a Real-World Credential Stuffing Event

Credential stuffing attack events are becoming increasingly common against organizations of every size in every industry. Just this month, Chick-fil-A revealed it had been the victim of a month’s long credential stuffing campaign. Why are these incidents becoming so popular? Because attackers can abuse a compromised account in a variety of ways to commit fraud and pursue other malicious goals. For instance, financial accounts can be used to steal funds, retail accounts to illegally buy items, or social media accounts can sway opinions or spread malware. Just to name a few. 

Credential Stuffing Attack Definition 

Credential stuffing attacks are defined by attackers attempting to reuse credentials that were compromised in a previous breach in order to log in to another website or application. Knowing that many end users will often reuse the same password on multiple sites, attackers take breached credentials and try them on other high-value applications, such as a bank or online shopping account. 

Since data breaches are a relatively common occurrence, attackers have an almost never-ending trove of credentials that they can try against a virtually endless supply of targets. In fact, a recent study has found that there are approximately 15 billion stolen logins stemming from around 100,000 breaches. This leads to somewhat of a cybersecurity feedback loop in which one breach can fuel downstream impacts to other apps and accounts.  

To shed light on how to identify and thwart these attacks, below we share highlights of a credential stuffing campaign we recently identified and stopped. 

Breaking Down a Credential Stuffing Campaign

One of ThreatX’s customers experienced a credential stuffing campaign that we can use to illustrate a couple of ways you can start investigating anomalous traffic on your network. In this attack, ThreatX first noticed suspicious traffic from various IP addresses using the following user-agent header:  

gfdfgsdfgsgfdDSFSD3223  

Given that this is clearly not a common user agent, we decided to dig a bit deeper into what the requests were trying to accomplish.  

Step one was to identify any metadata we could extract from these events showing up in our platform. Fortunately, they had unique fingerprints. Traffic observed using this user agent:  

• Always used the POST HTTP method.  
• Only targeted a single host/domain.  
• Only made requests against the same login endpoint/URI for the application.  
• Passed arguments as the POST parameters that were the same, user name, password, and client time zone

Analyzing user names 

Over 1.6 million unique user names were seen across all suspicious requests. This points to a credential stuffing event. Figure 1 highlights the top 25 user names.  

Analyzing time zones 

This was the most interesting argument, and the one that prompted us to start investigating other patterns outside the HTTP request data. Our customer had some rules in place already to block time zones that are not allowed to communicate with the host/application. This was done by checking if the provided value is a valid time zone. However, the bot was inserting IP addresses as a time zone. 

This led us to believe that this was a targeted attack trying to bypass the current protections that were in place. Moreover, this behavior was not seen by any other customer; therefore, we have another way to fingerprint the bot. 

Analyzing traffic 

Within hours of the attack starting point, the suspicious user agent showed up in more than 2.5 million requests against the same customer! Figure 2 shows how the bot attacked twice in less than 48 hours, with the second one being shorter due to the protections we developed from the first one. 

That’s a lot of requests in a relatively short amount of time, and why we started classifying this as a bot, but we needed more data to confirm it. Therefore, we started looking at how many IP addresses the bot was using, which location the requests were coming from, and what providers were being used in the bot’s network. 

Analyzing source IPs 

Analyzing the source IPs, we found:

• Total unique IP addresses: 86,266
• Countries: 176
• ASNs/ASOs: 5021 

There were around 86K IPs used in this attack! Figure 3 highlights the top 25 IPs used. 

Those numbers gave us more confidence in our classification. Figure 4 displays the top 25 countries associated with the malicious IPs, and Figure 5 highlights the autonomous system organizations these IPs belong to.  

It seemed like the IP addresses were mostly associated with non-US locations and ASOs, so we can add another protection layer based on where the traffic is coming from. We also checked for known proxy and VPN servers that are hosted on the observed sources, and the results are displayed in Figure 6. 

Since more than half of the IP addresses seemed to be flagged as businesses and less than 1K were flagged as compromised servers, we did not attempt to actively scan and extract more information out of them. 

Takeaways

There will be times when either the data available is not enough to make a definitive conclusion about the real intent or actor behind an attack, but with the right tools in place, a reasonable assumption can be made. There are many ways to approach network traffic analysis and threat hunting, but hopefully this gives you a baseline process to start conducting your own investigations (or improve on existing ones).