System Forensics

All your artifacts are belong to us.

IETab_IE65 Malware Analysis

So I decided to pick another “South Korean” piece of malware to keep things local. I was browsing around and came across one called, IETab_IE65.exe.

To be honest, I forgot where I found it, so I apologize for not giving credit to the site. If you’re reading this, and you hosted the file, please let me know so I can provide a proper reference. I tend to download randomly at times and sometimes forget.

Ok, let’s get started. Here is the lab I will be using. It’s a simple modification of my “Pentesting Lab”. That’s what makes VMWare great! A couple snapshots and a delete or two on Google Draw and you’re good to go with a new lab setup. It’s nothing special, but it works.

I might also add. The physical system I have is a hard drive that I swap when I am doing malware analysis. That way I don’t have to buy two systems. I simply hot swap the SSD OS drives and i’m off and running. It’s a nice way to get up and running pretty quickly. I also have Deep Freeze running on it.

First things first I decided to go ahead and run md5 sum against the exe file and here is the output:

Here it is in txt form so you can copy/paste if you want; aae3ab2c365b91bd494405bed879c2b1

So after I got the md5 hash I went online to take a look and see if I could find something. I did. For a quick over view you can go here:  http://www.threatexpert.com/report.aspx?md5=aae3ab2c365b91bd494405bed879c2b1.
In either case I wanted to look myself so I can learn more about the process of malware analysis.

Static Analysis:

Next I wanted to see if the exe file was packed with some kind of packer. I used PEiD and the output looked like this:

I wasn’t familiar with what, “Nullsoft PiMP Stub -> SFX [Nullsoft PiMP SFX]*” was so I hit up Google and found the following; “NSIS is an open source, script-driven installation system with minimal overhead backed by Nullsoft. SFX Tool is a nice and intuitive frontend that gives you the possibility to generate and compile NSIS scripts. This way you can create installers with no need to write a single line of script code.” [1]. From what I read it doesn’t appear to be any kind of packer so i’ll move on at this point.

I decided to use Dependency Walker so I could take a look at the dynamically linked functions of the program. In the red box you can see what dll’s are being imported by the IETAB_IE65.exe program. These appear to be pretty standard from what I have seen in other samples. With the dlls listed this program can; access and manipulate memory, access to the registry, user-interface, etc. You can google these dll files and get a better idea of what they all do.
The orange box depicts the various functions being called. Lastly, in blue you can see the functions in Ordinal.  You can take the Ordinal number, for instance, 0x001 and then reference it it from the orange box and you see it references GetFileVersionInfoSizeA. It also provides exported function information.
Next I decided to open the program up inside PEview so I could examine the PE file a bit more. I’ve highlighted some compiled date below. It looks like it was complied on 2009/12/05, which appears to be more than likely fake, but it could just as easily be real too. The malware author can fake these dates if they want. Given that I only saw one instance of this file’s md5 online when I started playing with it, it’s quite possibly has been faked and it was compiled recently. Those are simply guesses though.
Although I didn’t highlight it you can see that it was intended to run on an i386 – IMAGE_FILE_MACHINE_i386, which is pretty obvious.
You can see here in the IMAGE_OPTIONAL_HEADER, and then look for the Subsystem Description that this is a GUI program. Also, note that you’re not seeing any packing identification in the PE header. For instance, you will see various UPX0, UPX1 entries if it’s packed via UPX, but we aren’t seeing those here so again I will assume it’s not packed.
Next let’s take a look at the section headers.
You can see here that the the Virtual and Raw size of the .text are pretty similar in size. If you do the conversion from hex into decimal it comes out to a difference of 24064 – 23628 = 436, which supports our findings from before about this program not being packed.
I can’t speak too much about these section headers, but from what I read packed programs tend to vary quite a bit in their size between virtual and raw. I didn’t list it here to conserve space, but this was also the case for .rdata, .data, etc… They were similar in sizes.
I think we pretty much got everything we need from PEView. I am going to move on and check the resource header our (.rsrc) by way of Resource Hacker. In the Optional Header subsystem we noted that it was a GUI program. Let’s see if we can pull out any “images” using resource hacker.
You can see here that there are a lot of dialog folders. The dialog section contains the menus used by the program. I’ve only highlighted on here, which is 111 -> 1033. It appears to be the Setup loading screen as you can tell from the picture. Something also to note is the Language is LANG_ENGLISH. This is was suppose to be a Korean piece of malware so we will have to keep this in mind. Maybe it was authored here, but intended for an English speaking audience? Who knows at this point and let’s not waste anytime tossing out ideas.
Behavioral:At this stage I think I am ready for some behavioral analysis. I was able to obtain some good information about what functions will be imported so I can keep an eye out for system activity that might be affected by such functions.
Well this is interesting. Here is the window popup prior to execution. It also shows our first bit of Korean. The Korean letters spell out, “Nbiz”, which matches “nbiz Ltd.” below the Hangul text.

Prior to execution I had Process Explorer, CaptureBAT, Procmon, and apateDNS running.

Here is what process explorer looked like after executing the file:


You can see some activity from IETab_IE65.exe. It appears to create a couple new process ids (932 and 1912). Possible chain of events: 1056 -> 932 -> 1912.
I want to look at CaptureBAT and see what the output of it looks like. I simply executed CaptureBAT prior to executing the file by doing the following:

This simply takes the output of CaptureBAT and outputs it to out.txt, which is located on my desktop. I also like to pre-create the out.txt file because then I don’t pick up the file creation activity in CaptureBAT. It’s just less noise. That’s always useful/helpful. The less stuff to sift through the better. In either case, let’s look at some of the output.

First, here are a list of processes (created and terminated):
process: created C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\Desktop\IETab_IE65.exe
process: created C:\[snip]\Desktop\IETab_IE65.exe -> C:\Program Files\IETab\IETab.exe
process: terminated C:\Windows\explorer.exe -> C:\[snip]\Desktop\IETab_IE65.exe



We see see some deletions and creations here:

file: Delete C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\AppData\Local\Temp\nsdE33D.tmp
file: Delete C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\AppData\Local\Temp\nsiE35D.tmp
file: Write C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\AppData\Local\Temp\nsiE35D.tmp\nsProcess.dll
file: Write C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\AppData\Local\Temp\nsiE35D.tmp\nsProcess.dll
file: Write C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\AppData\Local\Temp\nsiE35D.tmp\UAC.dll
file: Write C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\AppData\Local\Temp\nsiE35D.tmp\UAC.dll
 
I was able to recover the nsProcess.dll and UAC.dll file in the CaptureBAT log from the Temp Dir. They had some interesting strings in them:

UAC.dll:

nsProcess.dll had a lot of the same stuff. Mostly API call strings and various dll names listed. I’ll save the space and not list them here. I wasn’t able to recover some of the other dlls listed in CaptureBAT. I re-ran the program with no luck so I decided to move on.

The is the Run key. I wont call it persistance considering that it actually installs the program to the system, but it does; however, make sure it starts up.

registry: SetValueKey C:\[snip]\Desktop\IETab_IE65.exe -> HKLM\[snip]\CurrentVersion\Run\IETabYou see here where the installation path that is created, along with these three files.
file: Write C:\[snip]\Desktop\IETab_IE65.exe -> C:\Program Files\IETab\IETab.dll
file: Write C:\[snip]\Desktop\IETab_IE65.exe -> C:\Program Files\IETab\IETab.exe
file: Write C:\[snip]\Desktop\IETab_IE65.exe -> C:\Program Files\IETab\Uninstall.exe
This appears to be some house cleaning:
file: Delete C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\AppData\Local\Temp\inst.xxx
file: Delete C:\[snip]\Desktop\IETab_IE65.exe -> C:[snip]\AppData\Local\Temp\nsdE9F2.tmp\IpConfig.dll
file: Delete C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\AppData\Local\Temp\nsdE9F2.tmp\NSISdl.dll
file: Delete C:\[snip]\Desktop\IETab_IE65.exe -> C;\[snip]\AppData\Local\Temp\nsdE9F2.tmp\nsProcess.dll
file: Delete C:\[snip]\Desktop\IETab_IE65.exe -> C:\[snip]\AppData\Local\Temp\nsdE9F2.tmp\UAC.dll
 
Here were some internet related deletions/modifications:
registry: DeleteValueKey C:\Program Files\IETab\IETab.exe -> HKCU\[snip]\CurrentVersion\Internet Settings\ZoneMap\ProxyBypass
registry: DeleteValueKey C:\Program Files\IETab\IETab.exe -> HKLM\[snip]\CurrentVersion\Internet Settings\ZoneMap\ProxyBypass
registry: DeleteValueKey C:\Program Files\IETab\IETab.exe -> HKCU\[snip]\CurrentVersion\Internet Settings\ZoneMap\IntranetName
registry: DeleteValueKey C:\Program Files\IETab\IETab.exe -> HKLM\[snip]\CurrentVersion\Internet Settings\ZoneMap\IntranetName
registry: SetValueKey C:\Program Files\IETab\IETab.exe -> HKCU\[snip]\CurrentVersion\Internet Settings\ZoneMap\UNCAsIntranet
registry: SetValueKey C:\Program Files\IETab\IETab.exe -> HKCU\[snip]\CurrentVersion\Internet Settings\ZoneMap\AutoDetect
Here you see that the original IETab appears to create another file called, “IEU1002.exe”
file: Write C:\Program Files\IETab\IETab.exe -> C:\[snip]\AppData \Local\Temp\IEU1002.exe
process: created C:\Program Files\IETab\IETab.exe -> C:\[snip]\AppData \Local\Temp\IEU1002.exe
Later down in the CaptureBAT log you see this entry:
file: Write C:\[snip]\AppData\Local\Temp\IEU1002.exe -> C:\[snip]\AppData\Local\Temp\ updini.xxx
file: Delete C:\[snip]\AppData\Local\Temp\IEU1002.exe -> C:\[snip]\AppData\Local\Temp\ updini.xxx
I was also able to recover this updini.xxx. You can see a URL listed in the strings and the

This matches some of the network activity I had picked up on as well. Here is a screen shot from apateDNS:

You can see here that it was attempting to reach out to ietab[dot]sidetab.co[dot]kr

[Ignore the 127.0.0.1 for server ip in ApateDNS – I changed it prior to running Wireshark. I typically run ApateDNS prior to running network stuff just so I can get a quick picture of what’s being requested.]

I executed the malware on a live box, and we will walk through some of the Wireshark traffic now.

Here we see the DNS query in Wireshark:

Let’s follow this…

I also noted the random MAC address I generated on my VMWare NIC. You see it in the GET request. Further down the flow I come across another HTTP GET request:

The User-Agent looks interesting as well… I don’t even have Mozilla installed on my lab box. Maybe something to look at later. In either case I am more interested in this IEU1002.exe file that it appears to go out and grab.

Here is a GET request to a exh.dat file. I was not able to recover the exh.dat file.

Lastly, here an update request.

I connected a live system to the internet and camped out in the following directory: C:\Users\malware_win7x86\AppData\Roaming\IETab. I wasn’t seeing much activity on the wire once everything was installed, so I figured I would fire up Internet Explorer and see what happens when I go out on the web and browse around.

As soon as I fired up IE network connections were made back to 118.219.254.179, and a few files appeared in this directory. Specifically, ex.dat, exh.dat, hoobl.x, and hub.x. Here are the Bintext searches on them:

hoobl.x looks like a bunch of URLs, but when I went out to them nothing “special” happened.

Here is the output from hub.x. Still not sure what its purpose is…Thoughts


So now that I can see that IEU1002.exe was downloaded via the internet I am curious what it is. We saw it multiple times in CaptureBAT as well. It just so happened I was able to retrieve it from the CaptureBAT log.
What’s interesting about this IEU1002.exe file is that when I load it up into PEView I get some interesting stuff.

The md5 hash for this particular file is: 4abae2b952a10dd442eef4ea4fa9015f, which gets multiple hits on ThreatExpert and others. [2]

Here is the PEiD output:

Unpacking:I’ll assume now that this is indeed packed, and i’ll move to unpack it by way of OllyDbg. UPX is pretty easy to unpack in OllyDbg if you’re not feeling like using the built-in UPX unpacking feature (upx -d filename -o unpacked_filename). I am trying to learn more on how to use OllyDbg, so I will be using that.Once you load the packed UPX file into Olly scroll all the way down towards the bottom until you start seeing a bunch of zeros in the opcode section. These are the numbers that the computer reads. Once you locate the zeros, move up a few lines until you see a POPAD command in the assembler mnemonics. That’s
where you see the PUSH, MOV, etc. commands. That’s the mnemonics section within Olly.So now you have located the POPAD. Move down a few lines until you see a JMP command. Once you locate the JMP command this is where you will want to set your breakpoint.

Once your breakpoint is set run the program by clicking the, “Play” button up top, or hitting F9.

Your program should now be paused (note the bottom right corner) because it hit our breakpoint. You will want to hit, F8 (step-over) one time. So you’re taking the jump.

Remember our JMP command was going to take us to, IEU1002.004030FA. If you look at the virtual address on the left had side you will see: 004030FA. That means we made the jump. Note the red box on the right hand right. We are starting to see actual “text” in the comments section. Our program is unpacked at this point and we want to dump the running process. There is a plugin within Olly for that. It’s done by doing the following:

We will simply accept these defaults at this point (can be more complicated that this if the PE header is messed up, but that’s another blog completely).

The next windows after you click, “Dump” will ask you where you want to save the file. I called it IEU1002_Dumped.exe

Let’s quickly compare the packed vs. the unpacked version. The one on the left is packed. The one on the right is unpacked. I’ll let you be the judge.

Now that the file is unpacked I think this is a good stopping point. It’s getting longer than I had expected. I type this stuff as I do it. I don’t pre-plan the post, work it, and then blog it. I’m analyzing/learning as I type.
NOTE: If you want the files to follow along email me and I can send them too you.

Stay tuned for more….

UPDATE: 23APR12
Since I have no life I decided to do Part II: Memory Analysis this evening (Korean time).


I also might try and do some code analysis (possibly – I lack on Assembly Fu) so we will see if I can actually figure anything out.


Tweet

Thanks for reading!

References:

[1] http://www.softpedia.com/progDownload/SFX-Tool-Download-32878.html
[2] http://www.threatexpert.com/report.aspx?md5=4abae2b952a10dd442eef4ea4fa9015f

[3] Practical Malware Analysis
[4] SANS GIAC Reverse Engineering Malware (GREM) FOR610

, , , , , , ,

Comments are currently closed.

9 thoughts on “IETab_IE65 Malware Analysis

  • Vietwow says:

    Great article, Thanks, Could you please to upload sample file (IETab_IE65.exe) ?

    Best Regards,
    VietNC

  • Anharata says:

    I’ll happily second the ‘great article’ – I’m reading up on forensics at the moment. As a matter of interest, has there ever been any documented case of a virus escaping a virtual machine?

  • TShoot says:

    Thanks a lot for this beautifully explained -still easy to comprehend- write up!
    I lack on assembly fu and couldn’t enjoy this kind of stuff until I came across your site!

  • @Anharata – I haven’t come across one, but I do know at one point there was a vulnerability that could have allowed one to “escape”. I think the more immediate issue is self defending malware that knows it’s being analyzed inside a VMWare box so it acts differently. There are ways to mitigate this though.

    @Anharata, @TShoot – Thank you for your feedback. I’m glad you enjoyed it. Please let me know if I could have done something better. The more feedback I get the better I can tailor the material to a larger audience.

    I’ll have Part III up soon.

    @TShoot – Thanks

  • KP says:

    Another excellent article, Patrick. Very enjoyable read and I learned a lot from it, too. I’ll send you an email, as I’d love to get a copy of this one so I can follow along.
    Ken

  • macbookuser says:

    Your blog is so substantial. Great job!!

  • […] back. If you haven’t already read Part I you should do that before you start reading this so you will have an idea what’s going on and […]

  • […] here we are with Part III. If you haven’t already checked out Part I and Part II you […]