Combatting Botnet Traffic with Behavioral Analysis: Part II

Posted by Will Woodson | Lead Security Engineer on Jun 28, 2018 11:28:17 AM
Will Woodson | Lead Security Engineer
Find me on:

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

Botnet 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. POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=Password1 POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=Abcdefg POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=1qwerty POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=@admin@ POST https://wordpress.threatxlabs.local/wp-login.php log=Administrator&pwd=Administrator99
Common components of a distributed password guessing or brute force attack like this include:
1. Requests don't show clear signs of malicious traffic without viewing in aggregate (no <script> tags or   ../dir/ect/ory/../tra/ver/sal , etc.)
2. No single source IP address is sending high amounts of traffic.
Even in a relatively desirable distributed attack scenario, where each bot sends 2-3x more requests than a "normal" user, you can quickly find that "normal" request volumes are difficult to make blocking decisions around.
3. We could always lock out the Administrator account after too many failed logins to mitigate the attack, but what operational impact might that have?

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. GET https://www.threatxlabs.local/path/to/debug/script.php?path=../../../../../../../etc/passwd GET https://www.threatxlabs.local/path/to/debug/script.php?path=../../../../../../etc/passwd GET https://securecheckout.threatxlabs.local/path/to/debug/script.php?path=../../../../../../etc/passwd GET https://securecheckout.threatxlabs.local/path/to/debug/script.php?path='/system/.restricted' GET https://securecheckout.threatxlabs.local/path/to/debug/script.php?path=/system/.restricted GET https://securecheckout.threatxlabs.local/path/to/debug/script.php?path=../../../etc/passwd
1. This attack is typically easier to identify than one made against /wp-login.php on a WordPress site or a similar login page generally intended to be publicly available; a debugging script is probably not intended to be accessed externally, that is if it's intended to be deployed in production at all.
2. The individual requests do look malicious in and of themselves (../etc/passwd).
3. We still don't have a great way to stop the attack from new bots yet, short of blocking all requests to the debugging script, and certainly not in an automated way.

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." 

ThreatX goes further than visibility into top URLs and average traffic patterns, and can automatically throttle, or "tarpit," the rate of requests to a page. This, combined with our suspicious traffic interrogation capabilities, can detect and stop distributed attacks without adversely affecting legitimate user traffic.
Stay tuned for Part III, which will demonstrate behavioral grouping of botnet attacks.

Topics: Threat Intelligence

Threat X Labs - Blog

Arm yourself with information and insights on the latest cybersecurity trends to defend against today's most advanced cyber criminals with articles from the leader in SaaS-based web application firewall solutions.

Subscribe Here!

Recent Posts

Follow Me