In many exploit scenarios, an attacker finds a target and, if possible, establishes remote control over the system through known or unknown exploits. Whether the attacker uses a buffer overflow, insecure configuration, phishing for credentials, or cookie-stealing, the goal is clear: get a remote shell and gain complete control. Then what?
It is this post-exploitation environment that has interested me at this year’s Black Hat 2011. Several talks and trainings discuss post-exploitation techniques, and I’d like to share them in the interest of research – and defense.
Read More »
Tags: Black Hat, Exploit, security, security research, vulnerability
In the last few years there has been a major shift in the vulnerability landscape from a focus on attacking network-based server applications to attacking client applications using malicious file formats. Due to this shift there has been a variety of new techniques developed by attackers for more reliable control post-exploitation.
One of the techniques that is commonly used by attackers is the EXE drop. Basically this technique revolves around placing an executable file within the data format in which the vulnerability takes place. Post exploitation, the payload searches for the file descriptor that is associated with the data file, copies the EXE file from it to disk, and executes the EXE file in a new process. Some examples of data formats that are commonly used in an EXE drop exploit are Office documents, Shockwave Flash Files, and image files. The EXE drop technique is useful for several reasons; one reason is because it makes coding the payload easier. The executable can be crafted quickly and compiled for a specific target. Also, by copying an executable file to disk (persistent storage) it’s fairly easy to maintain residency by adding an entry to the autorun registry keys for example.
Read More »
Tags: malware, security, security research
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