Botnets: A study of the command and control structure

Name: Zakarie Ziobron

University: Edinburgh Napier

Requirement Analysis:

“Botnets and DDOS are a small percentage of the attacks that are committed on a daily

basis but they are one of the more dangerous effects on a network.”(Abdullah, Abu &

Noh, 2014) Viruses are the most prevalent attacks, but they can easily be rectified by

most antivirus solutions today. There is still not one single agreed method on getting rid

of the effects of a botnet. Load balancing is one of the ways to even out the traffic, but

your website will eventually go down.Since botnets are rising in their effectiveness, it is

important for us to find out how they work so that we can come up with a good

counter­strategy.Botnets are common ways of performing DDOS attacks or distributed

denial of service attacks. This study will help to determine how a botnet and it’s

controller communicate across a network which will us to prevent and rectify any

oversaturation of the network.The main requirements of this study are to download a

sample botnet and analyze how it communicates with its controller. In order to test

botnet functionality, I created a virtual network to test a sample botnet and identify the

1

way it communicates with its controller. The test setup consists of one firewall with a

LAN interface and a DMZ interface as well as a Kali virtual machine inside the DMZ

which serves as the machine that acts as the controller and a Ubuntu machine that is

held in the private range which serves as the bot. Below you can find the configuration

for the hosts and the router.

Host and Firewall configuration

Kali:

In this scenario, Kali is serving as the host inside the DMZ that holds the controller.

Since we are using a DMZ as well as a LAN, firewall is needed to facilitate

communication. We have chosen to use Pfsense as the firewall. The configuration of

2

Pfsense is as follows:

This is the basic interface configuration, but now we have to configure the rules of the

interfaces on the firewall.

LAN: For this ruleset, I just used the default rules. Everything in the lan can

automatically

communicate with everything in the LAN.

DMZ:

Once the firewall and controller have been set up, we must setup the machine that

3

holds the bot. We are using Ubuntu to host the bot. The configuration is as follows:

Once the hosts have been configured, and the firewall has run through the default

setup, it is necessary to configure the firewall rules on the interfaces to ensure that the

bot and the controller are able to communicate effectively. This is my final setup of my

rules. There has been a revision or two to the rules which I will discuss later on when I

conclude what I have learned.

LAN rules: For the LAN rules, I have left the rules as default. By default All traffic is

allowed inside the lan, so no changes needed to be made. The DMZ is where the main

configuration of the firewall took place. The current ruleset is Allow all IPV6 and IPV4

4

TCP and UDP traffic coming from the DMZ network and Allow all IPV6 and IPV4 TCP

and UDP traffic coming from the LAN network to the DMZ network.

There has been a striking departure from the malicious threats of the late 90s

and early 2000’s. Botnets or computers connected to malicious networks now make up

a big percentage of the new attacks being conducted. “Experts believe that

approximately 16–25% of the computers connected to the Internet are members of

botnets.”(Silva, Silva, Pinto & Salles, 2013) Botnets are most commonly used to disrupt

service to websites or to send mass amounts of spam email.”Some reports indicate that

approximately 80% of all email traffic is spam and that most of these messages are sent

via botnets, such as the so called Grum, Cutwail and Rustock botnets.”(Sperotto et al.,

2010)” As a result of the rise in attacks, it is more important than ever for information

security professionals to be able to identify when botnet activity is occurring on their

network.

In order to detect the botnet on our network, we used Wireshark and Snort.

First we started by running Wireshark while running the botnet and the controller. Once

we did this, we were able to derive our snort rules to detect the bot.

Botnet Analysis:

Once the botnet has been detected, It is important that we analyze it and figure

out how it works. Most botnets have the same underlying command structure but that

doesn't mean that all botnets are detectable in the same way. The most popular

protocols that botnets uses to communicate are IRC and HTTP. One important thing to

5

note is that one controller can handle multiple bots. Since this is the case all you have

to do to stop the botnet is interrupt communications between the controller and the bot.

The IRC botnet controller is centralized, maintains a constant connection and it is

encrypted(Gu, Zhang & Lee, 2008). This is the harder of the two methods to lockdown. .

The botnet traffic is hard to detect because it has the same behavior as the protocols it

uses, the traffic volume is low, so it is hard to detect that there is anything out of the

ordinary, and there may be very few bots monitored inside the network. If the traffic is

encrypted, this also presents a challenge(Gu, Zhang & Lee, 2008).

We can see that our bot in question is using the IRC method of communication. We

found this out by analyzing our Wireshark traffic. I was able to determine my destination

port and my source port. Here is a screenshot of the traffic I was able to capture.

As you can see from the traffic, the source port is 50975 and the destination port is

5001. Without analyzing the packet, the traffic looks pretty normal, and you wouldn't

think to analyze the traffic even further, but when you analyze the stream deeper, you

notice that something is not quite right.

6

From this portion of the stream, I can discern that look first tries to identify the botnet

controller that it is communicating with, and exchanges an encryption cipher. It then

captures instructions from the bot, the will then inform the operating system it is running

from and the current directory and write permissions that the bot is running on. It will

then set a keepalive parameter to inform the controller to keep the same connection for

each request. It will then get information that it has requested from the controller.

It will then attempt to connect to facebook, then it will send a hello, and the

controller will send back I am fine. A failover value will then be created. It is created by

analyzing network traffic and determining how busy the connection is. After this is

determined, a random timestamp will be created letting the bot know how long to wait to

7

retry the connection if it fails. A loop of Okay is established and sent as long as the bot

can reach the controller. Our botnet that we are using has encrypted communication as

you can see from the traffic above. I have already explained to the best of my ability

what I believe the flags are.

Now I will attempt to explain the encryption that is being used in our test botnet.

While analyzing the traffic I noticed that TLS was showing up in the trace. The code

inside the packet looks to be using a few different cyphers to hide their traffic. Looking in

the first flag of the packet that is noted as look, It is my belief that the first connection

exchange is using MD5. I think this is the case because of how similar it looks to when

we were decrypting passwords. It is my opinion that the next flag capture is using

scrambled alphabet because of the way the code is spaced in the packet. It is

reminiscent of the cypher exercises we did earlier in the semester. I think that the keep

alive is a caesar cipher. I decrypted the keepalive string and came up with grapefruit as

the word. The keep alive key is randomly generated each time the botnet connection is

restarted.

It is possible to identify a botnet by capturing and analyzing DNS traffic. The

problem with current detection techniques is that they can easily be evaded and some

techniques use large amounts of bandwidth. “Since a botnet acts like a group, It was

easy to determine that a better way of detecting the traffic was by monitoring the DNS

traffic for foreign communication. This makes monitoring less resource intensive, and

more effective(Choi & Lee, 2012).” This method of detection is not perfect however. It

8

has three primary limitations: “The mechanism may generate false negatives, when a

set of infected hosts in a botnet is changed frequently. The previous mechanism is too

sensitive against detection parameters.The mechanism cannot detect recently

introduced invasive botnets that utilize a domain generation algorithm for

C&C”(Beitollahi & Deconinck, 2013).

Our botnet had a lot of website requests. After the connection was established, It first

tried to resolve the local hostname as a domain. After that, it tried to lookup the acess to

bill’s site and facebook.com If this was a real botnet we could have attemptted to search

for the infection by looking for a device that was constntly requesting access to the DNS

server. “Botnet activities are shown in a group life cycle. They always retain their

communication with their command and control server.”(Choi & Lee, 2012) This is my

entry level overview on how a botnet works. Now I will discuss how I implemented my

detection system.

Implementation:

In order to detect the botnet, I used the IDS tool known as Snort. It is run in the

command line with an optional GUI component. I ran it on the same host as my

controller, but you can run it anywhere on the network you are trying to monitor. My

9

setup is listed below.

This rule basically states to alert when traffic using tcp from 172.16.51.7 on any port

when it attempts to connect with 172.16.52.7 on ports 5000 to 5005. By using my snort

rules that I have created from up above, I was able to see when the communication had

been detected. An example of the output from the alert file is shown below.

I will explain what the output means:

“Priority 0 defines the severity of the rules.0 is the lowest level. This is a measure of

how important the rule is.” The date and time of the intercepted traffic is listed. It will

then echo out the packet that has been matched with the current rule. As you can see,

in this example Snort informed the client that the packet from 172.16.51.7 on port 41274

heading to 172.16.52.5000 that the packet has been logged. It has still been allowed to

pass through the network. It is possible for snort to drop the packet entirely on alert, I

just decided to only alert and not drop. Just like Torrents that can be used for

downloading media illegally, you can also use torrents as another way to download

legal programs; Botnets can also be used for good and for evil. “One legitimate purpose

10

is to support the operation of IRC channels by conferring special administrative

privileges on designated users.” They are most known for their illegal actions.” Bots and

botnets serve two principal illegitimate purposes: attacking IRC servers and attacking

Internet sites.”(McCarty, 2003) Botnets are scary for people who don’t understand what

is going on, but I feel like this report has given a good insight in how botnets function.

Conclusion:

This was a very interesting report. I have learned a lot. I not only learned how to

properly set up a network, but I also learned how to run snort and analyze packets. I

have learned that there are multiple ways to do things. For Example, When it came to

my firewall setup, I learned that there were multiple thinks that I can do to make sure my

networks can communicate. I did the simplest of rules that I could think of by just

allowing all ports on IPv4 and IPv6 to pass through as long as they originated from the

DMZ network. This is the easiest of rules, but it is also the least secure. If I would have

done this in a corporate network, this would not have been best practice. I could have

only enabled access from one host to the other. This would have made the network

more secure. I learned that your first option may not always be your best option. It is

important that when planning a network, you think about your options more carefully. It

may take longer to setup, but it will save you countless headaches in the long run.

Using Snort has also taught me this. My first set of rules was to allow any IP on any port

to connect to 172.16.52.7 on ports 5000 to 5005. This was not secure because it

allowed all networks, even outside ones to connect to my address. I decided to tune my

snort rules to alert everything in communication between the two addresses. This

11

worked fine in a lab environment, but in a corporate environment, this would not be

practical. The IP address of the controller will not always stay the same, which means

that when the IP changes the rules will be worthless. I don’t know how you would

implement snort in a corporate environment, but you would probably have to tie it to a

firewall, and then have your rules update when the controller IP changes.This means

that snort will probably not be effective inside a corporate environment because of all

the rules you would have to write. I feel like I have learned a lot during conducting this

project, and I think this will give me tremendous insight once I enter the job market and

start to have to implement services that will protect against similar attacks. “It is a

constant competition between malware authors and security experts and we need to

keep ahead. Otherwise there will be nothing worth protecting.” (Calvet, Davis & Bureau,

2009)

12

References

Konovalov, A., Kotenko, I., & Shorov, A. (2015). SimulationBased Study of Botnets and

Defense Mechanisms against Them (1st ed.). St. Petersburg Institute for Informatics

and Automation. Retrieved from

http://download.springer.com.ezproxy.napier.ac.uk/static/pdf/823/art%253A10.1134%25

2FS1064230712060044.pdf?originUrl=http%3A%2F%2Flink.springer.com%2Farticle%2

F10.1134%2FS1064230712060044&token2=exp=1450112850~acl=%2Fstatic%2Fpdf

%2F823%2Fart%25253A10.1134%25252FS1064230712060044.pdf%3ForiginUrl%3Dh

ttp%253A%252F%252Flink.springer.com%252Farticle%252F10.1134%252FS1064230

712060044*~hmac=7efcbd6ee736de72945e6965578a7825fb2a28f46aca4152b1b07e3

64f95eae9

Silva, S., Silva, R., Pinto, R., & Salles, R. (2013). Botnets: A survey. Sciencedirect.com.

Retrieved 14 December 2015, from

http://www.sciencedirect.com.ezproxy.napier.ac.uk/science/article/pii/S1389128612003

568

Gu, G., Zhang, J., & Lee, W. (2008). "BotSniffer: Detecting Botnet Command and

Control Channels in Network T" by Guofei Gu, Junjie Zhang et al..

Corescholar.libraries.wright.edu. Retrieved 14 December 2015, from

http://corescholar.libraries.wright.edu/cse/7/

13

Choi, H., & Lee, H. (2015). Identifying botnets by capturing group activities in DNS

traffic. Sciencedirect.com. Retrieved 14 December 2015, from

http://www.sciencedirect.com/science/article/pii/S1389128611002787

Beitollahi, H., & Deconinck, G. (2013). ConnectionScore: a statistical technique to resist

application­layer DDoS attacks. Link.springer.com.ezproxy.napier.ac.uk. Retrieved 15

December 2015, from

http://link.springer.com.ezproxy.napier.ac.uk/article/10.1007/s12652­013­0196­5/fulltext.

html

McCarty, B. (2003). Botnets: Big and bigger. IEEE Security & Privacy Magazine, 1(4),

87­90. http://dx.doi.org/10.1109/msecp.2003.1219079

Abdullah, R., Abu, N., & Noh, Z. (2014). Understanding the Threats of Botnets

Detection: A Wide Scale Survey. Scialert.net. Retrieved 11 December 2015, from

http://scialert.net/fulltext/?doi=rjit.2014.135.153&org=10

Sperotto, A., Schaffrath, G., Sardre, R., Morariu, C., Pras, A., & Stiller, B. (2010).

Analysis of a Botnet Takeover. Ieeexplore.ieee.org.ezproxy.napier.ac.uk. Retrieved 2

December 2015, from

http://ieeexplore.ieee.org.ezproxy.napier.ac.uk/stamp/stamp.jsp?tp=&arnumber=556062

7&tag=1

14

Stankovic, S., & Simic, D. (2009). Defense Strategies Against Modern Botnets.

Arxiv.org. Retrieved 7 December 2015, from http://arxiv.org/abs/0906.3768v2

Calvet, J., Davis, C., & Bureau, P. (2009). Malware authors don't learn, and that's good!.

2009 4Th International Conference On Malicious And Unwanted Software (MALWARE).

http://dx.doi.org/10.1109/malware.2009.5403013

15