Friday, January 3, 2014

Exploring the Ether - or Maybe Just a 0-day

Greetings, Crusaders! Nice to be back to reversimicating (that's a thing) land. :) Tonight's challenge: Tackling a fairly recent 0-day. I was going to write about this sooner, but I wanted to wait until there was a higher number of detections by AV platforms. So, I'm a little late to the party, but at least I showed up. ;) Let's get to it!

We start off with our sample, winword.exe, which looks like a self-extracting archive:

Some basic info
Md5: 97BCB5031D28F55F20E6F3637270751D
VT (38/48):

It's got a great detection ratio now, so I feel better about writing about it. Oddly enough, it doesn't really have a name, most of those detections are generic. Oh well.

Edit: My good friend, @unixfreaxjp, has since informed me that this is known as TrojanSpy/Hanove.F. Thanks for the tip!

Behavior Analysis

Funny thing about that icon up there ^, I don't have WinRAR (or Office, as you'll notice in a moment) installed on this VM, so the icon is clearly faked. That said, it IS an archive and can be opened with 7-zip. Anyway, moving on...

When running the exe, it first pops up WordPad (again, no MS Office on this VM) and throws an error about graphic conversion:

It doesn't do anything except throw the error again when you click 'No'. Clicking 'Yes' gives us some flavor text in WordPad, just to throw off any suspicion that we've just been owned:

As you can see, the file is Shanti.doc - but, it's dropped in under %userprofile%\. I'm unsure if this name has any significance but I presume, given the text, that it's named as such to further aid in diverting any suspicion of malicious activity.

The doc file itself is also malicious, so here's some info:
File: Shanti.doc
Md5: DB8B2802177B38873A9DF8C9AF6E3CF6
VT (7/47):

The notable thing about the .doc file is that it exploits CVE-2013-3906 (seen in the VT results). The original exe also drops a file called updates.exe under the same %userprofile% directory. It's the updates.exe file that performs most of the malicious activity, so I'm going to focus on that.


File: updates.exe
Md5: 920FEFDC36DA03CE9B06FC5267664406
VT (39/48):

The first notable activity that this file performs is setting its persistence method. The file uses xcopy.exe to create a .lnk file under C:\Documents and Settings\All Users\Start Menu\Programs\Startup\HddLink.lnk. The path this .lnk file points to is %userprofile%\updates.exe. Deleting this .lnk file removes the persistence entirely, so it's nothing too complicated. :)

Updates.exe spawns cmd.exe which then uses ipconfig to enumerate hostname and network connection information. The output then gets stored in a file called iconfall.log. The file is stored (along with a copy of HddLink.lnk) under %userprofile%\Local Settings\Temp\. Presumably this file is then uploaded later on...

Here's a snapshot of the file:

4 additional files are also created under %userprofile%\Application Data\WinApp: .25in, he, o, and top, seen here:

You may have noticed that all 4 files have the same size. That's because all 4 files are identical to each other. What's interesting about them is that they all contain metadata (in xml format) about FakeNet - which I had running at the time. Could the malware be behaving differently when FakeNet is running? Maybe we can uncover more on that later. Here's a shot of the first part of the .25in file:

There's also a lot of the typical changes to HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ such as ProxyEnable, AutoConfigURL, etc. I'm not going to list them all here for the sake of brevity. If you would really like a list, get in touch with me and I can get you a regshot report. ;)

The malware also makes repeated GET requests, seen in Wireshark here:

If you look at the 'response' to the GET request, you'll see that it's the same data from the .25in file above. It turns out this malware is actually a downloader, and the .25in (and other) files contain the data that the server responds with. In this case, it's just the data that FakeNet has provided. So, there's that... I'm not going to let this sample hit the internet to pull down the stage 2 components at the moment, but I may revisit that in the future.

The other point of interest is the URI itself. If you look at it, you'll see it contains the hostname and the current username in the URI, so this data would likely be stored by the remote server when it receives a GET request.

The domain that it's attempting to beacon out to is, which is known by VT to be no bueno. :) VT info:

IDA Stuff

I really didn't find much interesting in terms of static analysis, but I spent some time figuring out the purpose of a few functions and thought I'd share a few tidbits.

The malware certainly doesn't waste any time once WinMain starts. It repeatedly calls the same function to execute commands in cmd.exe. Here's where it's using xcopy to establish persistence (HddLink.lnk isn't shown here, but it appears a few lines above the xcopy reference) and then grabs ipconfig info to store it in iconfall.log:

Here we can see the functions that build the GET request that goes to You should recognize "WinInetGet/0.1" as being the User Agent String from the GET request.

This is the part of the hexdump which contains the hostname "", which is pushed to the stack at 4077CA (in the above image):

That's about it, really. Probably one of the more boring pieces of malware I've looked at in a while. Sorry it took me so long to get the blog post out! Cheers.



Filename: winword.exe
MD5: 97BCB5031D28F55F20E6F3637270751D
VT (38/48):

Filename: Shanti.doc
MD5: DB8B2802177B38873A9DF8C9AF6E3CF6
VT (7/47):

Filename: updates.exe
MD5: 920FEFDC36DA03CE9B06FC5267664406
VT (39/48):

C:\Documents and Settings\All Users\Start Menu\Programs\Startup\HddLink.lnk. >> Points to %userprofile%\updates.exe

C2 domain:

No comments:

Post a Comment