After presenting the wide spectrum of possible usage of bots as an attack tool, we
now want to present several ways to stop this threat. This should help you to get
an overview over possible methods to detect the presence of bots and also to detect
the existence of communication channels used for C&C. If you want to report
the presence of a botnet to other people, it is best to have at least the following
information present:
Information about who you are
What malware is using the botnet -- that is, if you have collected a botnet
binary with the help of a honeypot, send them a copy. In that case, a common
proceeding is to send them an encrypted ZIP archive with password infected
Information about the IP address(es) and port(s) used by the botnet and all
additional information (username, nickname, channel, . . . ) you have
Any proof you have. This can be packet traces, log files, documented
exploitation attempts, or anything else that can back up your claims
Estimated size of the botnet to give them an estimation of the threat level
Information about which steps to mitigate the botnet you have already taken
Any additional information you have collected up to that point
This information then helps the responsible people to get a quick overview of
the situation. In any case, be certain to have information that can back up your
claims. Expect to spend quite a lot of time for each report, and do not overlook the
need to build strong and positive relationships with the support community.
If you observe that the botnet is used to harm other people -- that is, a botnet
that is used to steal personal information or distribute denial of service attacks, the
best approach is to have law enforcement track the botmaster down and haul him
into court. If you decide to take this road, contact your local law enforcement office
and give them all the information you have. They will then initiate all necessary steps
to collect more information and try to track down the botnet controller. After that,
it is of your hands.
If the C&C server is hosted on an exploited server, the best approach is to get in
touch with the server's operators to have them look into the problem. For legitimate
IRC servers that are abused by botnets, this appproach is relatively easy and usually
successful. To get a point of contact, you must be sure who handles such matters.
If you have only the hostname, resolve it to an IP address. Based on the IP, you
can then use the tool whois to retrieve information about the network owner. The
who-is information also contains the network operator's e-mail address, often in the
form of abuse@PROVIDER. Send them all the information you have and hope that
they respond to your report.
 |
| Virtual Honeypots: From Botnet Tracking to Intrusion Detection |
| Download the entire chapter in full as a .pdf file |
|
|
|
|
Presumably, the most effective method to stop bots is to stop the initial establishment
of a connection from a bot to the C&C server. As just explained, most
bots use a central server for C&C, and, in most cases, a dynamical DNS name is
used for this server. This allows us to stop a botnet effectively. Once you know
this DNS name, you can contact the DNS provider and ask for help. Since many
DNS providers do not tolerate the abuse of their service, they are also interested in
stopping the attack. The DNS provider can easily "blackhole" the dynamic DNS
name—that is, set it to an IP address in the private range as defined in RFC 1918.
If an infected machine then tries to contact the C&C server, the DNS name will
resolve to a private IP address, and thus the bot cannot contact the real C&C server.
This method is mostly used by CERTs and similar organizations. It proved to be
quite effective, and many communication channels have been disrupted in this way.
Nevertheless, it requires the cooperation with the DNS provider and this is not
always possible. But if you send them a polite mail with all the information you
have, you might get lucky.
Since we observe the communication flow within the botnet, we are also able
to observe the IP addresses of the individual bots unless this information is obfuscated
— for example, by modifying the C&C server. Thus, one possible way to
stop the botnet is to contact the owner of the compromised system. This is, however,
a tedious and cumbersome job, since many organizations are involved, and
these organizations are spread all over the world. In addition, the large number of
bots make this approach nearly infeasible; only an automated notification system
could help.
There are also several methods to stop a bot within a network that can be
carried out by a network administrator or security engineer. As always, the best way
to stop a threat is to stop its root cause. In this case, this would mean eliminating the
attack vectors and check for signs of intrusions, such as, by patching all machines
and keeping AV signatures up to date. But this is often not easily possible. A 0day
exploit—an exploit that has no available patch—cannot be eliminated in all cases,
and patching needs some testing because it could also break important systems.
In addition, AV scanners often cannot identify targeted attacks. With the recent
malware outbreaks, we have seen that the time between a proof-of-concept exploit
for a new security vulnerability and the integration of it into a bot is only several
hours or days. Thus patching cannot always help, but at least try to keep up to date
as much as possible.
One quite effective method to detect the presence of bots also exploits their
rather noisy nature. Most bots try to spread further by exploiting security flaws on
other systems. To find such a system, they have to extensively scan the network for
other machines. In addition, the communication channel often uses specific, rather
unusual ports. So by looking at the state of your network, you can also detect bots.
Netflow/cflow is an easy-to-use solution for this problem. The collected data often
allows us to spot an infected machine. A typical sign is a spike in the number of
outgoing connections, most often on TCP ports 445, 135, or on ports with recent
security vulnerabilities. This is caused by bots that try to propagate further via
common vulnerabilities. Another sign is a high amount of traffic on rather unusual
ports.We analyzed the information about more than 11,000 botnets and found out
that the vast majority of botnets use TCP port 6667 for C&C. Other common ports
include TCP ports 7000, 3267, 5555, 4367, and 80. TCP port 6667 is commonly
used for IRC, but you should take a look at this port and the others mentioned.
In addition, tools like ngrep or Snort can help to detect the presence of C&C
channels. One example is to search for typical C&C messages with the help of
these tools. This can, for example, be done with the regular expression, shown in
Figure 11.7, as proposed by Fischer [27].
(advscan|asc|xscan|xploit|adv.start|adv5c4n) (webdav|netbios|
ntpass|dcom(2|135|445|1025)|mssql|lsass|optix|upnp|ndcass|imail)
Figure 11.7 Possible regular expression to detect C&C channel.
Of course, such a method requires some human supervision, since it is not
error-free and could lead to false positives. In addition, the C&C commands can
change with time, so regular updates are necessary.
In Section 10.1 we introduced an approach of how to use honeypots to detect
the presence of bots in a given network. That method exploits the fact that bots
try to propagate further by exploiting vulnerabilities on other hosts or other side
effects -- for example, sending out spam e-mails. We detect this, and the honeypot
provides us with additional information related to the botnet -- for example, a bot
binary captured by nepenthes.
Virtual Honeypots: From Botnet Tracking to Intrusion Detection
Home: Virtual honeypots: Tracking botnets
1: Bot and botnet 101
2: Tracking botnets
3: Case studies
4: Defending against bots
5: Summary
