We recently worked with a client that had suffered a denial of service on one of their websites. They wondered if we could tell them what had happened and how to stop it from happening again. So, time to start digging through logs to work out what was going on. It turned out that the attack was a Distributed Denial of Service (DDoS) attack using BitTorrent clients to attack the target site. BitTorrent Distributed Denial of Service attacks are a pretty under reported attack vector that I hadn’t come across before in the real world. So the following blog takes a look at the log analysis and investigation that led to this understanding.
DDoS attacks like this are often carried out using bots, infected computers on the Internet, which are all under the control of a malicious individual or group. These bots are then used to perform activities, such as requesting web pages repeatedly. This causes the victim site to be quickly overwhelmed with requests resulting in one of the following events:
- Exceed the available network bandwidth.
- Exceed the application processing capacity.
If successful, either event would result in removing access to legitimate users of the site.
However, in this case, the means of delivery was via BitTorrent clients and not infected machines.
Initial Log Analysis
A quick review of the logs showed that a large volume of traffic had been directed at the site from multiple sources within a very short space of time. We had requests for ‘announce.php’ coming from over 10,000 unique hosts in a specific geo location.
Here is an example of one of the logs captured by Apache (sanitised):
[source_ip] - - [date_time] "GET /announce.php?info_hash=%25B56%25B51u%252DU%2504Eb%2513%25EA%253BVFBu%257E%2512%25BA
&peer_id=%252DSD0100%252D%25127%25F9%25AD%25ABd%252D%25CFN%2593%25FC%2521
&ip=192.168.1.31&port=11706&uploaded=1043070976&downloaded=1043070976&left=0
&numwant=200&key=6511&compact=1 HTTP/1.0" 301 655 "-" "-"
Looking at the announce.php and the parameters (upload, download, and left) in more detail we suspected it was BitTorrent traffic due to the format of the request. With a bit of googling this assumption was confirmed. In discussion with the client it was quickly established that their main corporate site was not acting as part of a peer-to-peer network and that this traffic was the source of the DDoS attack.
BitTorrent Analysis
All of the traffic appeared to be coming from the same geographic region, so we came up with two possible scenarios. One, that DNS cache poisoning was being carried out to send legitimate BitTorrent traffic to our victim server. Or two, that our victim server had been named as the torrent tracker server in the .bittorrent file. Knowing which scenario was in play would then dictate the best mitigation option, so back to the logs.
In their current format, our clients logs were not helping us figure out which of our scenarios were the most likely as they were missing detailed information as to what the ‘Host’ section of the request was. As the attack was ongoing, we quickly updated the apache logging by editing the `apache2.conf` file to add the parameter ‘%Host i\'.
Apache logs are easily configured to provide additional details such as this and for the small additional storage overhead, it is definitely worth while having this pre-configured to save time during later analysis.
With the new log configuration, we can now see the domain that is being requested (marked in grey):
[source_ip] - - [date_time] "GET /announce.php?info_hash=%25B56%25B51u%252DU%2504Eb%2513%25EA%253BVFBu%257E%2512%25BA
&peer_id=%252DSD0100%252D%25127%25F9%25AD%25ABd%252D%25CFN%2593%25FC%2521
&ip=192.168.1.31&port=11706&uploaded=1043070976&downloaded=1043070976&left=0
&numwant=200&key=6511&compact=1 HTTP/1.0" 301 655 "-" "-" "[client.domain]"
We have removed our clients domain name here, but the Host header matched our clients domain name which indicates that this wasn’t DNS poisoning but rather that our clients server had been listed as a BitTorrent tracker in a .bittorrent file. If this was DNS cache poisoning we would have seen the domain name of the site the BitTorrent clients were trying to reach.
Remediation
Defending against the attack was easy enough once we understood what was going on. As our client isn’t actually running a BitTorrent server we simply dropped any requests for announce.php at the firewall and reduced the TCP timeout value on the Apache box to flush inactive connections.
Conclusion
What was especially interesting in our scenario is that the systems involved in the DDoS attack were not ‘bots’, these systems hadn’t been compromised at all. To perform this attack, the malicious actor doesn’t need any technical skills beyond creating a torrent file, and the attack is very low risk as once the .torrent file is created, no further interaction is required. While an attack like this doesn’t generate massive amount of traffic, with enough peers having downloaded the torrent file, the attack can be big enough to cause a denial of service.