A botnet is a network of compromised computers – known as bots – usually controlled by a command and control computer, that work together in coordination for a malicious purpose.
In this blog post, we’ll discuss how to detect botnets used for account takeover (ATO), an attack used to obtain the valid credentials of an online account. An attacker may steal an innocent user’s login credentials and – depending on the type of account – use them to carry out a variety of criminal acts such as identity theft, credit card validation, or gift card redemption.
Detection
Let’s start by talking about the challenge of detecting ATO botnets.
Protecting a site from ATO attacks demands dedicated detection and mitigation techniques. Identifying ATO botnets is more challenging, however, as they are distributed across several IP addresses and use sophisticated techniques to stay unnoticed. In order to defend against an ATO botnet, we first need to detect an ATO attack and then the botnet operating behind it.
A traditional way of defending against ATO attempts is to use rate limiting on a site’s login endpoints, to prevent a brute-force attack. This kind of defense isn’t useful in the detection of botnets, though, since they tend to go by a low and slow pattern of request rates and stay hidden between the legitimate traffic.
To illustrate this low and slow pattern, the following graph shows the number of requests made by botnets per client used in an attack, per day and hour.
We can see that most of the requests being sent as part of ATO botnets are low in number. To reduce the chance of being detected, an attacker can send requests using different user-agents and with different HTTP header orders. What’s more, when used as a botnet the IP address will also change.
Now let’s talk about how we handle the detection of ATO botnets. Despite an attacker’s efforts to hide his attacks, such as those mentioned above, we first need to detect ATO attempts regardless of whether or not they’re related to a botnet. In order to do that we look at login attempts to sites under our protection using known username fields, password fields, and login paths, combined with login data from our Account Takeover Protection. This uses accurate login information for every site under our protection, and is able to identify suspicious logins using different logics such as identifying stolen credentials.
As well as being able to identify standalone ATO attacks, need to apply some logic to detect whether they operate as part of a botnet. We decided to exploit the fact that botnets will often target many sites using a relatively low number of different IP addresses.
To exploit this botnet behavior, we apply an algorithm that uses the ratio of the number of sites attacked divided by the number of IP addresses used over the course of a week. We also check the number of URLs targeted. Looking at the parameters mentioned above is enough to detect botnets. There’s no need to look at things like the failed login percentage, the number of unique credentials used, the rate of the attacks during a one-week period, specific IP addresses, endpoints targeted, or tools used to perform the attack.
Results
Using the technique described above, we detected nine ATO botnets attacking Imperva’s customers over one month (for a recent example of botnet detection, see: (https://www.imperva.com/blog/how-account-takeover-botnets-outsmart-traditional-security-controls/), with eight of them targeting WordPress login pages.
The following chart shows the number of targeted sites against the number of IP addresses used. This ratio is used as part of the detection algorithm.
Some facts about the botnets we found:
- The botnets targeted up to 4,000 sites and used up to 50 IP addresses
- All the WordPress-targeted botnets impersonated one or several popular browsers, such as Chrome, Firefox, Internet Explorer, Safari, Opera or Sogou (a Chinese web browser based on Google Chrome)
- They each targeted a few login pages per site, for example:
/wp-login.php, /wp/wp-login.php, /wordpress/wp-login.php, /login/ - They usually used no more than a few dozen IP addresses for each attack, and there was always a large ratio between the number of sites attacked and the number of IP addresses used
From the chart above we can see that the ratio between the targeted sites and the IP addresses used ranges from a maximum of 1,400 in the first column to a minimum of around five in the 17th column. Using this fact can help in the detection of botnets by filtering false-positives. The following graph shows this ratio more clearly.
It’s interesting to note that one of the botnets we saw was using a unique technique. By changing their order, it created 24 possible permutations for these four headers: Accept, Accept-Encoding, User-Agent and Connection. All of the 1.2 million requests were evenly distributed among the permutations and generated an average of 50,000 requests for each header’s permutation over the course of a week.
This technique is used by attackers to confuse the detection mechanism and hide the fact that all these requests are connected and originate in the same botnet. But, while it may help against more traditional defense mechanisms that check for typical botnet behavior, these kinds of tricks aren’t much help for an attacker – he can still be detected.
Conclusions
ATO botnets tend to hide among legitimate login attempts, making them difficult to find. They can be detected using dedicated heuristics, regardless of the rate in which requests are made or other details specific to the attacking botnet. This is made possible by looking at data from different sites and correlating it to the login attempts. When you consider the frequency with which ATO botnet attacks take place, this kind of capability is crucial for mitigation.
Try Imperva for Free
Protect your business for 30 days on Imperva.
