Sunday, December 15, 2013

What's Hash Got To Do With It?

Well, because that's how we're going to kick off this little story.  Without further ado, here ya go:  26E57BDE90B43CF6DAE6FD5731954C61

Before we go too far into that, however, I need to take a step back.  It's been a long time since my last post.  Too long indeed (my job makes it difficult, to say the least), so let's not dwell on that, shall we?  With that out of the way, I'll give just a quick back story on the above-referenced md5 hash value.  Last week, on Wednesday and Thursday, I came across this malicious gem.  Well, I think it was the same both times.  From a network perspective, it was behaving the same - reaching out to the same C2 channels, attempting to post the same type of encrypted data (based on format, appearance of cipher-text, etc.).  However, as it turns out there wasn't an appropriate endpoint sensor on the first box, to be able to pull back more relevant info.

That fact is important as we go on - that unless you have evidence across different DFIR disciplines (host and network, with all their subsets), you really can't say for certain what is occurring.  You can postulate, and may very well be correct, but without RAM, RE, timeline and other host data, and various points of NSM (network security monitoring) such as FW logs, IDS/IPS, netflow, you're left at least somewhat in the dark.  Anyhow, from a network perspective, these two appeared to be the same, and fortunately there was an endpoint sensor on the second box; I got to have some fun, and thought I'd share.

As it turns out, the infections originated not from some stealthy drive-by or infected website, but via an executable inside a zip file sent along with an "Amazon" email to personal email accounts.  In the case of the second one, the user had received two previous ones that were ignored and deleted; the third was just too much and curiosity won out.  User opens zip file.  Oops #1.  User double-clicks executable.  Oops #2.  At that point it's all over but the tears, and the malware has its fun.  The positive side was that - finally - I got to have some fun too!

Now, I didn't know all that at first.  All I knew was that C2 traffic to had been blocked.  That was the same domain as the previous day, so my interest was piqued.  The system that blocked didn't have any info about the malware, just knew that the traffic was bad, so that was no help.  I went in to my sensor logs from that box, and found the application reaching out to was msiexec.exe, from the c:\windows\system32 directory.  Ooh, now that's not right.  The parent process for msiexec.exe was order_jd4320480293.exe.  Now that's not good either.  And it was running from inside a zip under the user's temp directory, with a parent of explorer.exe.  Alright, that's not unexpected, especially at this point.

I was able to pull a copy of the binary for order_jd4320480293.exe that the sensor had pushed to my analysis server, and saw that it had 9 hits by hash on Virus Total, so I went to check that out.  There were indeed 9 engines that detected it; one from the 11th, and eight from the 12th.  Most had generic names as yet; the most relevant one appeared to be from McAfee, which had it as a ZBot variant.  Searching on that lead me to, where the binary had apparently been uploaded and analyzed already.  As a side note, the next morning VT had 14 detections, and is now up to 23 (What's funny is that some of the vendors I submitted a sample to, now say they detected it back then.  Hmm, really?).  Since there's some RE type info on VT and Malwr, I won't try to go into that; I'll give you some reference links to go enjoy that.  I will, however, give a quick rundown of what I saw.  I will probably come back and add some IP addresses for the domain, as well as a .ru TLD I saw from the endpoint, so watch for an update.

So here's the quick high-level rundown:
*  User downloads zip from fake Amazon email, opens, and runs order_jd4320480293.exe
*  Malware executes, and order_jd4320480293.exe spawns (loads) msiexec.exe from c:\windows\system32 as a child process 
*  Child process msiexec.exe creates a new executable under the user profile, named (one example) msyaam.exe or msevaxlgn.exe (another example)
*  Child process msiexec.exe adds a runkey for the new executable, in the user hive, under Software\Microsoft\WindowsNT\Current Version\Load
*  Child process msiexec.exe deletes original executable, order_jd4320480293.exe

Along in there somewhere, msiexec.exe packages up some data (probably credentials), encrypts, and tries to ship it out to remote servers.  Unsuccessfully.  Defense in depth... ;-)

Well, that's it for now.  Given the info available elsewhere about this malware, I probably won't post anything about its actions on the system, unless I see a very different  approach take place.  But I will look to post some IPs and perhaps some other tidbits that might be helpful from an IOC perspective.  Other than that, here are some links:

Happy Hunting!


  1. Great post, very helpful from both an NSM and host-based analysis perspective. It's too bad you don't post more often. ;-) Thanks!

    1. Thanks, Harlan, for the comment and encouragement! I've had ideas, and jotted down notes, but time ... time seems to be my enemy.