System Forensics

All your artifacts are belong to us.

Suspected South Korean Malware

Given that I am currently living in Seoul, South Korea I couldn’t pass up on the opportunity to possibly analyze some “Korean malware”. It’s pretty tough to say exactly where a piece of malware came from, or even who was behind it. There were indications of this one at least trying to reach back to Korea.

In either case, let’s get started. First I downloaded the exe file and created an md5 hash of the file.

After grabbing the MD5 hash I created a zip file of the exe just in case the piece of malware deletes upon execution. It’s always a pain when that happens so I find that a simple right click, send to zip works great.

Next I decided to fire up Procmon. Upon firing it up you should hit; Ctrl + E, which will stop it, and then proceed with hitting Ctrl + X, which will clear it. If we let it run it will be too loud and it will mess with our Regshot and Capturebat.

As you can guess the next thing I did was opened Regshot and took a snap shot. After taking the first snapshot I hit Ctrl+E again on Procmon to start its activation, and I also started up Capturebat. Once those were running I decided to execute install_tvcup_type1_t.exe.

After reviewing the compare shot of Regshot here were some of the items of interest.

HKU\S-1-5-{sid}\Software\Microsoft\Windows\ShellNoRoam\MUICache\C:\Documents and Settings\Administrator\Desktop\install_tvcup_type1_t.exe: “install_tvcup_type1_t”

C:\WINDOWS\Prefetch\INSTALL_TVCUP_TYPE1_T.EXE-1D579BCA.pf (prefetch)

There were also some UserAssist Keys that had been added, but to be honest there wasn’t much activity, which can be a sign. Maybe I didn’t let it run long enough, or maybe it goes our to grab the actual payload because all the fun happens. Given that I work in an isolated lab, it could be the main reason as to the lack of behavioral activity. In either case, I paused my VMWare machine and proceeded to copy the Malware_XP-1724d952.vmem file and move it over to my SIFT Workstation where I renamed it xp.vmem and proceeded to do some Volatility checks.

**UPDATE: 12MAR12: Based on some feedback in the comments section below I should clarify this a bit. I’m going through this scenario as if someone would be reviewing this after the fact. So I need to clarify that the UserAssist, MUICache, and Prefetch for that matter are all self inflicted artifacts due to the fact that I (“the user”) clicked the install_tvcup_type1_t.exe file. How I kicked this all off was simply by double clicking the exe file on my desktop. I sort of skipped the whole acquiring the memory image dump and all that and went right into looking at it in volatility. Sorry for the confusion and thank you Harlan for pointing that out.

Before I start issuing commands with Volatility I am going to make it a bit easier by executing the following commands:

I decided to get things started by kicking off a pslist.

I’m going to go ahead and run a psscan and see if something might be hiding from us.

It looks like from the psscan we see a couple more items that appear to have been exited/hidden and didn’t show up on pslist. I’m going to keep digging, but I don’t think these are anything to be concerned about at this time.



I went ahead and reverted back to a “clean” snapshot within my VMWare lab and proceeded to run the malware again. Immediately after running the malware I fired up LordPE and dumped the process to dump.exe.


After dumping the dump.exe file I decided to go ahead and run a strings search against it to see if I could find anything interesting that would provide me with some leads.

I also saw CreateMutexA while running the strings search, and remembered Volatility has a plugin for running mutant scans so I decided to go back into Volatility and put the code analysis on hold for a bit.

And what do you know, there it is, which matches the same PID:Thread combo (3488:3492) from when we ran psscan above.

After I identified the Process ID for the suspect process I decided to run dlllist against it and specified the process id using the -p 3488.

After grabbing a list of dlls I decided to walk the VAD tree. Right off the bat I grepped for a few items and saw EXECUTE_READWRITE and got a hit:

There were a lot more, but I wont paste them all up here. I’m still a bit fuzzy on vadinfo and what not so i’ll more than likely give you the wrong information anyway.

NOTE: I see a lot of tutorials that run through vadinfo, tree, etc., but I have yet to come across one that says, “here is the information, and here is why it is interesting/important, etc.”. If anyone knows of one please let me know in the comments section. I’m still trying to fully understand it and its importance. Thank you…


After that taking a look at vadinfo I decided to run the

UserAssist plugin for Volatility and see what came out.

And here is what I found… At this stage it was already pretty clear that this “program” was run, but in either case now I have some date/time information to go along with it.


[snip]

**UPDATE: 12MAR12: Again, this UserAssist “artifact” was a self inflicted artifact, but i’m reviewing this as if I was a third party of sorts.

I’m not getting any connections back with either connscan or connections, which seems a bit odd, however when I ran sockscan I got a hit.

I went back to a clean snapshot in my VMware lab I ran the malware again, and noticed some traffic. 192.168.2.102 is the XP machine I compromised. The 192.168.2.100 is my SIFT workstation where I have this instance of wireshark running. So basically you’re just seeing a standard DNS query to a site located in Korea.

I went ahead and edited the /etc/hosts file on my windows box to point to my SIFT machine.

When I executed the malware again I got a RST, ACK after the initial SYN, so I figured I would fire up INETSIM and see if I can’t get a solid communication channel.

And here are the wireshark results after I setup INETSIM.

Here is the full GET request: As you can see now it’s going out and trying to download more “stuff”.

It looks like we were right about why this might not have had much activity in the registry upon initially running it. It looks like it reaches back out to pull down some more “stuff”.

Now that I have a good idea what this little guy does I am going to go ahead and move into the code analysis, which I am not very good at, but learning more and more each day.

I’m curious if this is what’s downloaded during that GET request that’s made after execution we saw while I was watching the traffic via wireshark above.

I noticed while looking through IDA that this program calls the ioctlsocket function.

One of the requirements for ioctlsocket is Ws2_32.dll. Looking over the vadinfo output from above I saw the following, which was one of the “suspect vads”.

Ws2_32.dll vadinfo output:

That’s basically it. After reading more and more about this actual program it appears to be some kind of “anti-virus” tool that packs a mean punch. I found some more information about the piece of malware so I decided to call it quits at this stage.

I didn’t let it run in a live environment because I wasn’t in an environment where I felt safe to do so. I did this while on travel. At this stage it appears one could have already configured a rule set to block a potential infection anyhow. At the end of the day it’s about return on investment I guess.

You can find a “professional” write-up here too: http://threatcenter.crdf.fr/?More&ID=66255 – I found this after the fact.

Tweet

Comments are currently closed.

2 thoughts on “Suspected South Korean Malware

  • Keydet89 says:

    The MUICache value that you mention early in your post is a “self-inflicted” artifact…it’s the result of how you executed the malware for testing. The same is true for the UserAssist entries.

  • @Keydet89: I removed my comment and just updated the post instead. Thanks for pointing that out. Also, thanks for all your contributions to the community.