From a defense point of view, websites should suspend and limit false login attempts to confirm authenticity once abnormal usage is detected.

Have you ever tried to login to your favorite website and mistakenly typed the wrong user name and password once, or even twice? I bet you have. And what about submitting a third consecutive false attempt? In most cases, at that point a secure website will start questioning the integrity of your actions.

But what if the threat actor is sending only one login attempt? Or if the threat actor is executing a credentials abuse attack campaign, using an army of compromised computers and internet devices, sending only one login attempt from each device?

In December 2016, Akamai's Threat Research Team conducted research on credential abuse malicious activity as this attack methodology continues to gain momentum. The research examined the techniques that are being used by threat actors in order to explain what makes those campaigns successful, and at the same time difficult to detect despite state of the art security control.

In this article, we will present an overview of our analysis with a proposed solution for improved detection.

Part I: Overview - Credential Abuse Attack Campaign Analysis

Initial Findings

The first step of the analysis was to monitor a credential abuse attack campaign, targeting an ecommerce website with a malicious botnet with nearly 13,000 members over 24 hours. Here are some of the findings:

Nearly 70% of the botnet members belonged to the same three Internet Service Providers (ISP) in Spain, Korea and Taiwan

The botnet included 12,936 members (IP addresses)

Altogether, the botnet sent 167,039 login attempts over 24 hours

123,909 unique accounts were targeted

The entire botnet averaged 6,902 login attempts per hour

Each botnet member averaged one login attempt per two hours

Figure 1 - The aggregated botnet activity over 24 hours

How to Defend Against Credential Abuse Attacks

In most cases, credential abuse attacks use dictionaries of user names and passwords that were leaked as a result of an information breach. As opposed to its sibling "brute force" attack technique where accounts are cracked by sending many login attempts to the same account but with different passwords, credential abuse attacks use credentials that are already leaked, and try a single login attempt per account.

The difference in the usage of accounts reflects on the ability to detect and defend against the attacks. In the case of brute force, accounts can be prevented from being cracked by locking the targeted account after an abnormal amount of login attempts is detected.

In the case of credential abuse attacks, locking accounts based on a single attempt is risky. Therefore, detection should be focused on the attacking resources that are sending an abnormal amount of login attempts by using different accounts, some of which don't exist on the targeted website.

Offline threat intelligence analysis can do a great job of finding malicious activities. However, the limitation of offline analysis is the inability to actively react to the malicious login attempts once knocking on the website's door. In order to mitigate credential abuse attacks, run-time prevention solutions should be in place, which are part of many security control vendors' features list. Many security controls products use a pre-defined limited time frame to monitor login attempts, and once an attacking resource (IP address) reaches the threshold, prevention techniques can be activated.

But What If...

But what if attackers are sending login attempts at a rate that keeps them undetected by security controls? What is the overall impact of such undetected login attempts when using a sliding window of a five-minute detection mechanism? How can we detect attacking resources that send a single login attempt to a website in 24 hours?

In-order to answer these questions and provide a better understanding of the threat landscape, here is a deeper analysis of the campaign mentioned above, including 24 hours of login attempts initiated by a botnet with 12,936 members.

Part II: Security Control Limitations - Botnet Members Activity Analysis

Step 1: - Reviewing Attacking Resources Activity

When looking at the login attempts per IP address distribution, the bar chart (Figure 2) shows us that most IP Addresses are sending less than 20 login attempts in 24 hours.

Figure 2 - Visualizing the botnet: 12,000 members' activity over the monitored 24 hours, total number of IP addresses per number of logins

Another way to look at the same data is to accumulate the percentage of IPs out of the total botnet members by number of login attempts. This bar chart (Figure 3) clearly presents the volume being generated by the increasing fraction of botnet members. We can see that 10% of the botnet members are sending a single login attempt, 65% are sending up to 10 login attempts and 92% are sending up to 20 login attempts. These numbers represent the challenge of detecting low rate credential abuse attackers targeting a single website.

Figure 3 - The cumulative percentage of IPs out of the total botnet members by number of login attempts

Step 2 - Gauging Botnet Members Detection

In-order to evaluate detection coverage for different time intervals, we simulated a sliding window mechanism, validating all time intervals between one and 60 minutes. The analysis was done based on 24 hours of login attempts, using a threshold of five login attempts as a matching criterion for detecting malicious activity.

Figure 4 - Sliding window detection coverage, between one and 60 minutes

The chart (Figure 4) shows us that when using a five-minute sliding window, we will be able to detect 3% of the botnet members. With 30 minutes, we will be able to detect 16% and with 60 minutes we will be able to detect only 27% of the botnet members.

Step 3 - Evaluating the Attack Impact

While in step two we measured the coverage of detected botnet members, in this step of the analysis we measured the detection coverage of login attempts being generated by already matched botnet members (based on five login attempts as a matching criterion). This measurement gives us a better understanding of the impact of missed detection in terms of login attempts.

Figure 5 - Sliding window login attempts detection coverage, between one and 60 minutes

The login attempts chart (Figure 5) shows that when using a five-minute sliding window, we will be able to detect 38% of the botnet login attempts, with 30 minutes we will be able to detect 51% and with 60 minutes we will be able to detect only 64% of the botnet login attempts.

So, What Have We Learned So Far?

Per the results of the steps taken thus far, a conservative threshold of five login attempts will yield poor detection coverage even when being used with a gracious 60 minutes sliding window:

Only 42% of the botnet members will be detected

of the botnet members will be detected 1/3 of the attack campaign login attempts will slip through (only 64% of the login attempts are being detected), leaving the website vulnerable

of the attack campaign login attempts will slip through (only of the login attempts are being detected), leaving the website vulnerable 10% of the botnet members send a single login, making mitigation decisions on those members nearly impossible

Why Do Security Controls Tend to Be Short Sighted?

When monitoring IP addresses, having five login attempts in five minutes is a good indication of malicious activity. However, five login attempts over five hours can also represent a legitimate user's behavior, having the same IP address shared by many users. In addition, run-time monitoring mechanisms consume CPU and memory, limiting security controls in the time frame used to monitor login activity and in most cases, don't exceed a 60-minute time window.

We believe that malicious actors understand these limitations and thus use more elusive attack techniques. Attackers are using large botnets that execute cross-targeted attacks, and at the same time, make sure each botnet member generates a low volume of login attempts to each targeted website. By using this technique, attackers can slip under the detection radar while keeping a sufficient level of attack efficiency over time.

The defensive challenges are clear; it is time to talk about possible solutions.

Part III: A Solution - Cross Sites Analysis

As we just saw, performing an analysis on a single website results in insufficient detection coverage, but by expanding our point-of-view and analyzing cross customers' login attempts through Akamai's Cloud Security Intelligence (CSI) platform, we could see that the botnet is targeting 71 different websites.

By executing the same botnet analysis technique s outlined above with login attempts on all targeted websites, we received more promising results.

Cross Sites Campaign Overview

By comparing botnet activity of login attempts going to a single site vs. login attempts going to all targeted websites (Figure 6), we can see the true magnitude of the malicious botnet activity with an average of 6,902 login attempts per hour for the former, and 203,793 login attempts for the latter.

Figure 6 - The aggregated botnet activity on a single site vs. cross sites over 24 hours

Step 1: - Reviewing Attacking Resources Activity

When looking at the login attempts each IP address is generating (Figure 7), we can see that there are some IP addresses that trigger more than 12,000 login attempts, but the density is still toward the IP addresses with a low rate of login attempts.

Figure 7 - Cross site: Total number of IP addresses per number of logins

On the cross sites cumulative percentage of login attempts by IP addresses (Figure 8), we can see that only 2% of the botnet members are sending a single login attempt, 17% are sending up to 10 login attempts and 31% are sending up to 20 login attempts (92% are sending up to 20 in a single site).

Figure 8 - Cross site: The cumulative percentage of IPs out of the total botnet members by number of login attempts

Step 2 - Gauging Botnet Members Detection

Figure 9 - Cross site: Sliding window detection coverage, between one and 60 minutes

The chart (Figure 9) shows that when a five-minute sliding window is used (with a threshold of five login attempts) we are able to detect 34% of the botnet members. With 30 minutes, we are able to detect 71% and with 60 minutes we are able to detect 81% of the botnet members. These number represent a huge improvement when compared to a single site detection (only 27% detection on a single site).

Step 3 - Evaluating the Attack Impact

Figure 10 - Cross site: Sliding window login attempts detection coverage, between one and 60 minutes

The rectangle shape of the login attempts chart represents nearly perfect detection coverage (Figure 10). We can see that when using a five-minute sliding window, 94% of the botnet login attempts are detected, with 30 minutes 99.14% are detected and with 60 minutes we are able to detect 99.69% of the botnet login attempts.

Summary

A botnet with nearly 13,000 members is not abnormal phenomena in the current threat landscape. Akamai's Threat Research Team monitors hundreds of such campaigns on a weekly basis.

We can see that credential abuse attacks are on the rise and malicious actors are striving to take over more and more compromised accounts. Threat actors' objectives are money driven and related to the financial benefit of selling compromised accounts on the dark market.

As this article shows, we believe it's time to extend the paradigm of on premise security into a multi-layer defensive approach that also utilizes cloud cross-site capability, leading to major improvements in eliminating credential abuse threats.