The previous post in this series discussed comment spam, one of the most pervasive forms of 'botnet' web traffic and accordingly, one of the least targeted varieties of attack. Part II will discuss a more serious form of botnet traffic: Targeted attacks that are coordinated centrally and distributed across multiple actors in an attempt to avoid security controls.
Bot Behavior - Distributed Attacks
Distributed Attack Behavior
Botnets enable an attacker to avoid basic volumetric detection of their malicious traffic by spreading the same overall number of malicious requests across multiple bots under their control. To a web server with no capability to aggregate or group these bots (because each reports a unique source IP address), a distributed attack can look very similar to legitimate user traffic.
As a security analyst or site administrator, this simply means you can't ask "Why is this IP address sending us 1000 times the requests of a regular user?" Or, better yet, you can't ask: "This source IP address has failed login 100 times in the past few minutes, can we block it?", leaving your web application open to several classes of distributed attacks illustrated below:
Case #1: Distributed Password Guessing/Brute Force Attack
The following example traffic shows a number of HTTP requests to a WordPress login page. Note that each request comes from a different IP address but sends the same log=Administrator username field.
10.73.140.3 POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=Password1
10.73.140.4 POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=Abcdefg
10.73.140.5 POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=1qwerty
10.74.220.1 POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=@admin@
10.74.220.2 POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=Administrator99
|
Case #2: Distributed Parameter Fuzzing (local file inclusion)
Our second example demonstrates several bot actors attempting to use a debugging script to access sensitive system data using a potential local file inclusion vulnerability.
10.120.10.6 GET https://www.threatxlabs.local/path/to/debug/script.php?path=../../../../../../../etc/passwd
10.120.10.6 GET https://www.threatxlabs.local/path/to/debug/script.php?path=../../../../../../etc/passwd
10.115.70.8 GET https://securecheckout.threatxlabs.local/path/to/debug/script.php?path=../../../../../../etc/passwd
10.115.70.8 GET https://securecheckout.threatxlabs.local/path/to/debug/script.php?path='/system/.restricted'
10.115.70.4 GET https://securecheckout.threatxlabs.local/path/to/debug/script.php?path=/system/.restricted
10.115.70.4 GET https://securecheckout.threatxlabs.local/path/to/debug/script.php?path=../../../etc/passwd
|
Gaining Visibility Into Malicious Traffic
Blocking individual bots or source IP addresses is a losing battle against a distributed attack. If there are any particularly unique characteristics about the attack traffic, it may make sense to block requests matching those (Maybe a User-Agent HTTP header, or the Request URL is very unique). Ultimately, however, we need a more robust approach.
So how can you detect and block a distributed attack?
To detect and block these kinds of distributed attacks we need to instead look for trends in the distribution of traffic among webpages on a given site. Simple traffic baselining allows us to know how much traffic a page typically receives as well as the number of requests a typical client may send to it. A basic heuristic for alerting, then, might be: "We usually receive 10 login requests a minute, suddenly we're seeing 1000."