I recently began working on a toolset to aid with analyzing binary protocols and I decided to use it as an exercise to get more familiar with the Immunity Debugger. I have been using Windbg for a while now, however, I was constantly reading articles discussing how great Immunity Debugger is for exploit development and I had been meaning to take the time to become more familiar with it.
Debugger Inception – The Scriptable Debugger Within The Debugger
Post-Exploitation Techniques from Black Hat 2011
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.
Tags: Black Hat, Exploit, security, security research, vulnerability
Extracting EXE Drop Malware
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.
Tags: malware, security, security research
Observations from the Darknet
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.
Tags: netflow, security, security research
Exploring a Java Bot: Part 3
January 19, 2010 at 1:18 pm PST
Reputation
This meter represents your reputation at a 100% scale based on your level of participation on the site.
Find out more
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.
Tags: botnet, java, malware, security, security research
