Just a quick follow-up to yesterday's post, as promised. I decided to do it as a new post rather than an edit/update, figuring it would be easier to track this way. Not much to it, just a little more info to round things out.
First, I got my hands on the infected PC today, pulled the hard drive, and extracted some files. I wasn't able get RAM, but I do have hiberfil and pagefile to work with, along with the user profile and registry hives, but that's not the point here. (I will note, however, that unless I can find evidence of the malware's activities in hiberfil or pagefile, I'm still - to an extent - surmising how it spawned msiexec.exe in the first place.) I found three separate executables under the user profile, as created by msiexec.exe. I copied them off into a separate directory and used md5deep to hash the files, so that I could look for them on VT or Malwr.com as well (there, now this is a post about md5deep too!). Here's what I ended up with (my own formatting):
26e57bde90b43cf6dae6fd5731954c61 | msevaxlgn.exe
26e57bde90b43cf6dae6fd5731954c61 | mssuhin.exe
26e57bde90b43cf6dae6fd5731954c61 | msyaam.exe
26e57bde90b43cf6dae6fd5731954c61 | mssuhin.exe
26e57bde90b43cf6dae6fd5731954c61 | msyaam.exe
Did you notice that? All hashed the same. Okay, maybe that's expected, or not too unexpected at least. But did anyone note the hash value from yesterday, for the initial executable (from inside the zip)? Well, in case not, here it is again (in the same format):
26e57bde90b43cf6dae6fd5731954c61 | order_jd4320480293.exe
See that? Yes, that's right - another md5 match, and I doubt it's due to collisions. :-) So basically, the original malware spawns msiexec.exe, creates a new executable(s) that is (or are) identical to the original (except for the name); the original is deleted, and the show goes on. I don't know about you, but that's not what I commonly see from malware.
Now for a few more tidbits...
A little header info from a network capture:
POST /se/gate.php HTTP/1.1
Cache-Control: no-cache
Connection: close
Pragma: no-cache
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0
Content-Length: 74
Host: finley.su
Cache-Control: no-cache
Connection: close
Pragma: no-cache
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0
Content-Length: 74
Host: finley.su
IP Addresses, as seen by the C2 blocking device:
Now, I mentioned before that there was a .ru TLD involved, and here that is:
Haven't looked at that traffic yet, and it never made it to the device that blocked the C2 traffic, as it had already been blocked for other reasons. And of course, until I examine the pcaps, I won't know what that traffic was (still might not - since it was blocked, it will be a one-side conversation).
Last of all, a screenshot of the offending email (note some inconsistencies outlined in red):
SupportAmazonyu? AmazonStoreIdecoa? I could get it with "Amazon," but what's with the other stuff? And the order numbers don't match up anywhere. And finally, it says, "Well let ..." rather than "We'll let ..."
Well, I guess you can't patch users! At least not without regression testing first. ;-)
I think that's it for now; if I do come up with anything else that looks interesting or useful, I'll post another update. Aside from that, I told a friend I'd post about some specific uses for md5deep; we'll see how that works out, but hopefully it will be coming soon.
Happy Hunting!
No comments:
Post a Comment