So I had a closer look at the http ddos module of the minerbot (microtrend calls it BKDR_BTMINE.DDOS, but I guess I'll continue to call it minerbot or pizzabot :) )
If you execute the file it installs itself as a service called "ddservice" (woot.. creative ^^) and starts that service. The new process is then trying to connect every now and then to youtube in order to check if there's an Internet Connection available. Now it's time for searching another bot in the p2p network, after finding one it will download a file containing a list of websites to attack.
The hosts in the lists are filtered (for example, if a hostname resolves to 127.0.0.1 that host is skipped) and then the attacking threads are started.
Each Thread is trying to fetch the indexpage of the assigned target. This is always splitted in 2 parts: first open a socket to the target to check if the host is still up, if yes, open another socket and do the actual GET Request. Because of this, you might see incomplete requests in your access log. In my nginx it looks like this (shortened):
192.168.5.124 - - "-" 400 0 "-" "-" 192.168.5.124 - - "GET / HTTP/1.1" 200 141 "-" "Opera/9.80..."
After a while the bot starts at the bootstrap phase again to get an updated target list
While the module itself isn't really protected and can be run without the bot, it still heavily relies on the infrastructure that the bot is providing for fetching the target list. I'm wondering if the bot could maybe be crashed with an buffer overflow, I have put that on the todo list for the next debugging session :)
Possible User Agents (may be incomplete):
- Mozilla/4.0 (compatible; MSIE 7.0; Win32)
- Mozilla/4.0 (compatible; MSIE 8.0; Win32; Trident/4.0)
- Opera/9.80 (Windows NT 5.1; U; ru) Presto/2.2.15 Version/10.10
- Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:184.108.40.206) Gecko/20091221 Firefox/3.5.7
- Opera/9.80 (Windows NT 5.1; U; ru) Presto/2.2.15 Version/10.00
- Opera/9.64 (Windows NT 5.1; U; ru) Presto/2.1.1
- Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:220.127.116.11) Gecko/2009122116 Firefox/3.0.17
And as I've mentioned already in the other posts, the Accept-Language header is hardcoded to "ru"