Sometimes it is interesting to take a look at darknet data and see what you come across. If you are not familiar with the term “darknet,” I am using the definition used by some in the service provider community where a darknet is a set of address space which contains no real hosts. That means no client workstations to initiate conversations with servers on the Internet. It also means no advertised services from those ranges, such as a webserver, a DNS server, or a database server. There is really no reason to see any traffic destined for addresses within those ranges. From a network point of view, it should be as desolate and deserted as the town of Pripyat in the Ukraine, within the evacuation zone due to the Chernobyl disaster back in the 1980s. However, in practice, you do see traffic to those address ranges, which is what makes that traffic somewhat interesting. Traffic destined to those ranges could be the result of malware attempting to locate machines to infect, part of a research project or it could be as simple as a misconfiguration or a typographical error. One example of traffic resulting from a typo would come from attempting to ping a host and typing the wrong address in. However, it would be hard to believe that all of the traffic seen in a darknet is the result of a mistake.
Setting up a darknet does not have to be hard to do. If your organization has address space that is not being used, then all that you need to do is advertise a route for those addresses and leave them unused. In our case, we have advertised several ranges and we collect Netflow data for the traffic destined to them from a nearby Cisco router. That Netflow data is exported to a collector, such as nfcapd, where it is aggregated for further analysis.
Read More »
Tags: netflow, security, security research
Before we begin part 3 in this series, let’s review what we’ve covered so far. In the first post we learned how this bot was discovered and some basics about botnets. In the second post we covered botnet fundamentals like command and control (C&C) and various other capabilities. In this post we will examine some of the offensive features incorporated into a botnet designed to launch attacks and maintain control of hosts (aka victims). First we will discuss how botnets spread and then we will look at flooding and how it’s implemented in this bot.
There are two main ways malware spreads. It’s important to note that these two methods are not mutually exclusive. The first method, made famous by the Morris worm, involves targeting a network-based vulnerability; the author designs an exploit to spread his malware. Once the malware takes over a machine it then infects other machines. Every time the binary moves from one machine to another the botnet has the potential to see exponential growth. Most vulnerabilities only affect a specific operating system at a specific range of patch levels. Malware of this nature often hits big and then its growth rate takes a steep dive as patches become available and as malware is removed. Once the vulnerability is patched, the malware must adapt or accept a shrinking attack surface. Two recent examples of this method are Conficker and Slammer. It is important to note the distinction between the growth rate slowing down and the number of compromised machines. There are still countless machines connected to the Internet running both worms. Even as the growth rate approaches zero, many, many computers have already been infected and continue to run the malware. In two days time on a single Intrusion Prevention System (IPS) we saw over 178,000 slammer attacks.
An attacker simply needs to trick an unsuspecting user into running a binary that is under the control of the attacker. This attack vector is known as a trojan horse. A malware author would package his wares as a link from a friend, a new game of interest, or even a program to create keys for pirated software, etc.
Read More »
Tags: botnet, java, malware, security, security research
When I first started this series my goal was to remove any mystery around botnets. In fact, most botnets, like this one, are relatively simple. In this post we will explore the command-and-control (C&C) infrastructure, as well as the bot’s update mechanism.
A C&C interface is the primary user interface between the botmaster and the legion of infected hosts participating in the botnet. Since it is present in every botnet (although there are many different types of interfaces), it is one of the primary things we look for when attempting to determine if any machines have been compromised. From a botmaster’s perspective, it would seem that this is a key feature that must be carefully designed to avoid detection. But surprisingly, a very large percentage we see are very simple, just like this one. That said, at times it can be very much a cat-and-mouse game between botmasters and people in my industry.
Remotely controlling multiple machines is a basic principal that botmasters must address. You need to be able to command your nodes in a fairly efficient manner. If you have 10,000 nodes you do not want to issue a command 10,000 times. You want to issue it once and have all 10,000 nodes respond in a timely manner so that you know if the command was successful.
In this example the author decided to use internet relay chat (IRC). The use of IRC is very common among simple bots since it’s easy to understand and there are lots of implementations publicly available. There is a trade off though: because IRC is a well-documented protocol, it is extremely easy to detect and monitor. Infiltrating a Botnet that is IRC-based is a trivial task. Some botnets try to mitigate this issue by doing things like requiring server and channel passwords or even using SSL encryption, but none of those efforts are really effective. Passwords are easily sniffed off a network and anything being encrypted can be spied on with a debugger.
Read More »
Tags: botnets, security, security research
When news of Conficker surfaced I obtained a traffic sample from our botnet honeynet. I wanted to see what relevant aggregate information I could extract and see if there was any specific indication of Conficker activity. Using some lightweight tools I was able to quickly analyze my traffic sample and focus further research. I find that these high level analysis techniques lead me to ask the more interesting questions and, more importantly, come to my rescue when I’m pressed for time. Below, I share a little about how I deconstructed the traffic sample, briefly discuss visualization and turn to IPS and Global Correlation to get a bigger perspective on what was happening. Some of my colleagues here in Cisco Security Intelligence Operations (SIO) find these techniques useful so I thought I would pass them on in the hopes that others will as well. I’d like to hear from some of you on your favorite tools and tricks for this sort of sleuth work.
There are some things I should point out before delving into my traffic sample:
- I sanitized all IP addresses because the hosts in this traffic sample are Internet facing. That is, I replaced all IP addresses with a fictitious FQDN. Hosts with the domain honeynet.eg are on the honeynet and all other hosts use the network.eg domain. The hostnames are randomly selected three-letter words from CrackLib’s dictionary. My fictitious FQDNs are consistent across this post.
- Some of the xterm windows below may have a scroll bar. It’s easy to miss. Scroll down for more info.
- The honeynet has several hosts which each have multiple IP addresses. We use this to increase attack surface. Because this isn’t relevant, I normalized the traffic such that each host on my network has one and only one IP address.
Read More »
Tags: conficker, emerging threats, security, security research, tshark, wireshark