botnet command and control structure
TRANSCRIPT
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
counterstrategy.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
applicationlayer 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/s1265201301965/fulltext.
html
McCarty, B. (2003). Botnets: Big and bigger. IEEE Security & Privacy Magazine, 1(4),
8790. 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