Preface: I am by no means a "professional" malware analyst, and I'm sure there are easier ways to analyze samples (including just throwing the following sample at a sandbox). This was more of a live-fire exercise.
Besides drive-by downloads, typically in the form of Exploit Kits, one of the most common vectors for delivery of malware is email. Last week I received a typical message promising to contain deposit slips in a .rar file. Instead of trashing it or uploading it to a public sandbox, I decided to take a peak into the sample's functionality using a variety of techniques. Some of these have been covered in previous articles (Malware Analysis 101 Part 1, Malware Analysis 101 Part 2, Malware Analysis 101 Part 3) while others will be somewhat more advanced. First we'll start with static analysis in dependencywalker and Ida Free. Then we'll move onto OllyDbg. Next up will be behavioral analysis within the analysis VM using Brian Baskins' Noriben.py (and fakenet to emulate a "real" internet connection). Finally, I'll share the final report from malwr.com to see what indicators we may have missed throughout the above process.
The File
Originally the sample was attached to an email as a password protected .rar
archive (md5: e5176acddc19b5fc7e561c41648f7eb1). The password was included in the body of the spam message. This is a relatively common evasion method used to fool environments that do not reject unapproved, encrypted archives. Inside of the .rar file is an executable file (md5: 93305ed2d617888501c034b1208e97ba) with a file extension ".scr" (Windows Screensaver), and an icon that appears to be a rip off of Adobe's PDF format (in fact, exploring the .rsrc section of the PE shows that the icon is the same). This mismatch is pretty typical but is jarring enough that it should raise the hackles of anyone paying attention.
Static Analysis
Browsing the imports in Dependency Walker reveals some interesting information. We see some interesting imports from KERNEL32.dll one that shares similarity to CreateMutex; EnterCritcalSection. From this information we can assume that the sample uses a critical section object for mutual-exclusion synchronization (from MSDN). Additionally we see GetCommandLineA indicating that this sample interacts with the command line at some stage. What you can't see in the above image (due to the number of API calls) is the import of IsDebuggerPresent, which may indicate this sample has built in anti-analysis abilities. One additional interesting import is CheckTokenMembership (from ADVAPI32.dll), which attempts to enumerate the security information for a logon session. Unfortunately, I don't see any indication of a networking component, so its time to dig deeper.
Before moving on lets get a better look at the PE Headers using CFF
Explorer. Not a ton more information to glean from this view, but it is interesting to note that the sample doesn't appear to be packed (see OEP at 0x0008857). We can confirm that this is a PE32 file (not a .scr), if the tell-tale MZ (see Hex View above) wasn't confirmation enough. CFF also offered some additional insight into the .rsrc section of the file, which included an unknown section "XZZDO" at offset 0x8000058. I'm not sure what this actually is, but as we will see below, the included resources in this section "LLMPWU" and "MAAYVD" are called as parameters by the malware. Additionally in the .rsrc section we see the PDF icons as well as configuration information defining process privileges "asInvoker".
Start Function
Let's move on to a brief session of Ida Free 5.0. Checking out the graph view
of the start function we can see a call to GetCommandLineA which includes calls to 2 subroutines: one which enumerates environment strings, and the other enumerates the name of the running module. Immediately below that we see a jns operand (jump if not sign) which, if NOT taken would result in the function to the right. This function leads into a number of DecodePointer calls, perhaps as a method of obfuscation. Unfortunately, this doesn't tell me a whole lot, since my experience with disassembly is lacking, at best. I can assume, however, that this is a anti-debugging/analysis technique, and that further static analysis may be fruitless. Continuing to delve deeper into the sample using the handy "Names" window we observe an interesting call to "Sleep" (which takes a hex value as a parameter in milliseconds). We will see during the behavioral analysis why this
is important. For now, I know I'm in over my head, and I need to see the networking component. Lets see if a debugger will help (hint: It won't).
Running the sample in OllyDbg results in a crash (remember that jns I pointed out? thats what leads to the "crash"), but check out the value of ECX: "CreateProcessW". Setting a breakpoint at the push -1 following this crash results in an infinite loop. This tells us that this behavior is likely intentional. In fact, looking at ProcMon (which I generally keep running during debugging) I can see that additional process spawned and that this "crash" appears to be a simple
dropper component which builds a second executable file under C:/Users/Documents and Settings. Lets move on to Behavioral Analysis. Since I suspect the VM is now compromised due to my debugging, I'm going to wipe it before proceeding.
Behavioral Analysis
Now that my analysis VM is back in pre-infection condition, lets prepare the environment prior to running the malware. First off is FakeNet and then its time to fire up Noriben.py. Noriben is a script by Brian Baskins that takes advantage of the excellent Procmon and its filtering capabilities in order to produce a csv timeline and .txt report. Lets see what it turns up when this sample is run. Running the script is simple, simply browse to the location and invoke Noriben.py, then execute the sample. FakeNet will capture any packets in a .pcap which we can review later. Since there was an embedded Sleep function (3000ms), I suspect this sample lays dormant for a little while, so I let Noriben run for a few minutes following execution.
After giving the sample ample time to stew, a quick Ctrl-C stops Noriben and converts the ProcMon log into separate .csv and .txt files. Browsing the .txt files shows some interesting results; First we see that this sample dropped an additional version of itself to %AppData% (md5: 93305ed2d617888501c034b1208e97ba). Also, we see iexplore.exe being called as a child process of the sample as well as a call to svchost.exe. There were also several notepad.exe processes spawned as children of the sample's process. Finally, we see a number of registry modifications for "Adobe Reader Speed Launcher" which point to Ad0be.exe (md5: 93305ed2d617888501c034b1208e97ba) which was observed being dropped; that solves the question of persistence. So that takes care of the networking, dropper, and persistence components, what else did we see?
The network traffic section of the Noriben report is quite telling. We see what looks like the result of a local API call beaconing to FakeNet, and then we see the results of the call to iexplore.exe that was generated when the sample was run. Lets get a better look at the .pcap generated by FakeNet.
Browsing the pcap file there is a DNS query for omcxasm(dot)myftp.org [which was intercepted by FakeNet, w00t]. Since the sample believes it has resolved its' C2 domain (in fact, its being routed to localhost) it begins phoning home over TCP port 1866. Over the course of 5 minutes we see 8 beacons to the C2 domain: the first, second, fourth, sixth, and eigth beacons contain 159 bytes of TCP data which contains: New (Likely a status of the malware), local IP of the host, hostname, logged in user name, Windows version, version of the malware (in this case 1.3), status of the process (perhaps) and some additional encoded data. The third, fifth, and seventh beacons contains 318 bytes of data, which seems to be the same TCP payload observed above repeated twice. We also see a shift in source ports being utilized to generate this traffic; starting with TCP 1472, TCP 1728, TCP 1984, TCP 2240, TCP 2496, TCP 2752, TCP 3008, and finally TCP 3264. The destination port of TCP 1866 stays constant. Pretty interesting behavior!
Malwr Report and Summary
Here's the malwr report: clicky
What did we miss? Besides the mutexes created by the dropped process, and an unusual html file (xxx.html), it looks like static analysis, Noriben.py, and FakeNet did a pretty good job of building a profile of both network and host based indicators!
Below is a summary [Apologies about the quality] of the process flow using ProcDot
Besides drive-by downloads, typically in the form of Exploit Kits, one of the most common vectors for delivery of malware is email. Last week I received a typical message promising to contain deposit slips in a .rar file. Instead of trashing it or uploading it to a public sandbox, I decided to take a peak into the sample's functionality using a variety of techniques. Some of these have been covered in previous articles (Malware Analysis 101 Part 1, Malware Analysis 101 Part 2, Malware Analysis 101 Part 3) while others will be somewhat more advanced. First we'll start with static analysis in dependencywalker and Ida Free. Then we'll move onto OllyDbg. Next up will be behavioral analysis within the analysis VM using Brian Baskins' Noriben.py (and fakenet to emulate a "real" internet connection). Finally, I'll share the final report from malwr.com to see what indicators we may have missed throughout the above process.
The File
Originally the sample was attached to an email as a password protected .rar
Static Analysis
Browsing the imports in Dependency Walker reveals some interesting information. We see some interesting imports from KERNEL32.dll one that shares similarity to CreateMutex; EnterCritcalSection. From this information we can assume that the sample uses a critical section object for mutual-exclusion synchronization (from MSDN). Additionally we see GetCommandLineA indicating that this sample interacts with the command line at some stage. What you can't see in the above image (due to the number of API calls) is the import of IsDebuggerPresent, which may indicate this sample has built in anti-analysis abilities. One additional interesting import is CheckTokenMembership (from ADVAPI32.dll), which attempts to enumerate the security information for a logon session. Unfortunately, I don't see any indication of a networking component, so its time to dig deeper.Before moving on lets get a better look at the PE Headers using CFF
Start Function
Let's move on to a brief session of Ida Free 5.0. Checking out the graph view
Running the sample in OllyDbg results in a crash (remember that jns I pointed out? thats what leads to the "crash"), but check out the value of ECX: "CreateProcessW". Setting a breakpoint at the push -1 following this crash results in an infinite loop. This tells us that this behavior is likely intentional. In fact, looking at ProcMon (which I generally keep running during debugging) I can see that additional process spawned and that this "crash" appears to be a simple
Behavioral Analysis
Now that my analysis VM is back in pre-infection condition, lets prepare the environment prior to running the malware. First off is FakeNet and then its time to fire up Noriben.py. Noriben is a script by Brian Baskins that takes advantage of the excellent Procmon and its filtering capabilities in order to produce a csv timeline and .txt report. Lets see what it turns up when this sample is run. Running the script is simple, simply browse to the location and invoke Noriben.py, then execute the sample. FakeNet will capture any packets in a .pcap which we can review later. Since there was an embedded Sleep function (3000ms), I suspect this sample lays dormant for a little while, so I let Noriben run for a few minutes following execution.
After giving the sample ample time to stew, a quick Ctrl-C stops Noriben and converts the ProcMon log into separate .csv and .txt files. Browsing the .txt files shows some interesting results; First we see that this sample dropped an additional version of itself to %AppData% (md5: 93305ed2d617888501c034b1208e97ba). Also, we see iexplore.exe being called as a child process of the sample as well as a call to svchost.exe. There were also several notepad.exe processes spawned as children of the sample's process. Finally, we see a number of registry modifications for "Adobe Reader Speed Launcher" which point to Ad0be.exe (md5: 93305ed2d617888501c034b1208e97ba) which was observed being dropped; that solves the question of persistence. So that takes care of the networking, dropper, and persistence components, what else did we see?
The network traffic section of the Noriben report is quite telling. We see what looks like the result of a local API call beaconing to FakeNet, and then we see the results of the call to iexplore.exe that was generated when the sample was run. Lets get a better look at the .pcap generated by FakeNet.
Browsing the pcap file there is a DNS query for omcxasm(dot)myftp.org [which was intercepted by FakeNet, w00t]. Since the sample believes it has resolved its' C2 domain (in fact, its being routed to localhost) it begins phoning home over TCP port 1866. Over the course of 5 minutes we see 8 beacons to the C2 domain: the first, second, fourth, sixth, and eigth beacons contain 159 bytes of TCP data which contains: New (Likely a status of the malware), local IP of the host, hostname, logged in user name, Windows version, version of the malware (in this case 1.3), status of the process (perhaps) and some additional encoded data. The third, fifth, and seventh beacons contains 318 bytes of data, which seems to be the same TCP payload observed above repeated twice. We also see a shift in source ports being utilized to generate this traffic; starting with TCP 1472, TCP 1728, TCP 1984, TCP 2240, TCP 2496, TCP 2752, TCP 3008, and finally TCP 3264. The destination port of TCP 1866 stays constant. Pretty interesting behavior!
Malwr Report and Summary
Here's the malwr report: clicky
What did we miss? Besides the mutexes created by the dropped process, and an unusual html file (xxx.html), it looks like static analysis, Noriben.py, and FakeNet did a pretty good job of building a profile of both network and host based indicators!
Below is a summary [Apologies about the quality] of the process flow using ProcDot
No comments:
Post a Comment