Friday, January 24, 2014

Analysis of a VBScript bot


Introduction:

In the long list of complex threats that we see daily, it is interesting to see malware that is rather simple but effective in terms of the payload that it carries. At Zscaler ThreatLabZ, we recently 
came across one such innocent looking Bot, which targeted our customers. The file arrived as an attachment to a spam email message. The malware was written in VBScript.

Analysis:


Virustotal scan results show 14 out of 50 vendors detecting the malware.




Figure 1: Virus-total Result




The image below shows the malware opened in notepad. We can see that the file is obfuscated. That’s because the file has a “.vbe” extension (a “.vbe” is an encoded VBscript file), which would otherwise have a “.vbs” extension. The encoding support is provided to prevent people from reading the script.



Figure 2: Obfuscated VBScript


To be persistent, the malware copies itself into the startup folder in Windows (Figure 3)


Figure 3: Copy of Malware in the startup folder



Registry entry created by the malware to run itself at the system startup.(Figure 4)


Figure 4: Windows Registry (run entry)


It also adds a copy of itself to the Windows temporary folder (Figure 5).



Figure 5: Copy of Malware in temp folder


Next, the malware attempts to establish a connection to it's server (here wscript.exe is the Script Engine which executes VBScript).




Figure 6: Network communication


To extract more information we need to decode the file and obtain the original malware code in a readable form. Let's have a look at the decoded file.



Figure 7: Malware install code


The image above shows the code that is responsible for adding entry in the registry which 
allows the malware to execute every time the system starts , Also create it's own copy in the startup, temporary folder.

Another interesting part of this malware is it's ability to communicate over the network. The malware can actually receive a set of commands and execute them in an infected machine
At the time of analysis, the server to which the malware communicates seems to be down. Therefore, in order to fully understand how the malware communicates and also to demonstrate how effective and damaging this Bot is, I have decided to create an HTTP server and issue commands to the bot directly.

We can see from the code below, the wide range of commands that can be executed by this Bot. The commands are simple and self explanatory. 


Figure 8: Remote Commands


Let's see the effects of a few of these commands in detail. The “execute” command is capable of executing additional VBScript statements in the infected machine. The “update” command is issued to update the Bot , while “uninstall” removes the Bot entry from the Windows registry and startup folder.

There are also commands such as “send”, ”recv” and “site-send”. Interesting commands include “enum-driver”, “enum-faf”, “enum-process”, “cmd-shell”, “delete”, “exitprocess”.

Let us execute our server and wait for the Bot to connect to us and send information so we can then issue commands.


Figure 9: Malware callback

As seen in the image above, a “POST” request is made with it's path as “/is-ready”, indicating
that the Bot is up and ready. We can also observe information about the infected machine such as “volumeserialnumber”, “computername”, “username”,“operating system type”, installed
“anti-virus name” etc. To retrieve such information, the malware relies on Windows Management Instrumentation (WMI) queries.

Let us issue the command “enum-driver”. This command fetches the drive name and drive type of the infected machine as seen in the image below.

Figure 10: enum-drive


The next command “enum-faf” enumerates and fetches the content of an input directory or drive of the infected machine.


Figure 11: enum files 


The “enum-process” command fetches a list of processes that are running on the infected system.


Figure 12: enum-process

The “cmd-shell” command will allow the attacker to execute all DOS commands on the infected
system.


Figure 13: Execute Dos Command


Those are just a few of the powerful commands that the malware can execute in the infected system. This gives the malware near limitless power to control and steal data from the infected machine. The Bot and all it's communication are blocked by Zscaler.





Thursday, January 9, 2014

The Story of a Trojan Dropper III


Introduction:

In previous posts (story of Trojan dropper part I, II) we performed both static and dynamic analysis on the threat and also developed a broad idea of what the malware was doing in it’s initial stages. We now set out to investigate the reason behind the crash of the dropped file (“Adobe.exe”) and at the same time we want to retrieve the payload from this particular malware sample.

Analysis:

Let’s go ahead and debug the file. This file (“Adobe.exe”) was found to be packed (custom variant) and the unpacking routine is similar to the approach detailed in part II of this post, so let’s skip all the gory details and dive right into it.

After unpacking the entire binary in memory, control is transferred to a newly unpacked region at the address "0x401634". Now the action begins from here and we get our first decryption routine, which is a simple 1-byte XOR with a static key as seen in the image below which reveals more code


Figure 1: Decrypt code

If we carefully look at the new code below, we can observe that it is riddled with JMP instructions and occasionally we find a few garbage values. The code is crafted in such a way that it resists disassemble attempts which makes reverse engineering the sample more difficult and somewhat painful.

Hidden in between these JMP’s in plain sight is an instruction that is familiar to us by now(i.e the instruction to fetch the address of PEB (Process Environment Block)).


Figure 2: Fetch address of PEB

At this point we can only speculate on why the malware needs the PEB address. Moving further in the code, we encounter another decryption point that is exactly same as the first one, which decrypts more code. Now the control is transferred to the newly decrypted code.


Figure 3: NtGlobalFlag (anti-debug)

In the image above, we have an interesting bit of code. Recall that the malware already collected the address of PEB. At this point, using the instruction CMP DWORD PTR DS:[EDI+68], ECX (here EDI holds the address of PEB which is "0x7FFD4000" and ECX holds a constant 0x70 ) a comparison is performed, after which a JNZ instruction decides the fate of the control flow.

Here we get our first glimpse of the anti-debugging technique employed by this malware. The instruction CMP DWORD PTR DS:[EDI+68], ECX compares the value of the ECX register (i.e. 0x70) to the location in the PEB structure known as “NtGlobalFlag”. The field is set to a value of “0x70”, if the process is spawned under a debugger.

In our case, this is true since we are debugging the file. Finally, the JNZ instruction at "0x401511" is not taken, which lands us in an invalid region in memory, thus triggering the anti-debugging. Let’s jump here and continue with our analysis. We now have another layer of decryption, which reveals more code after which, as usual, control is transferred to this region.

We then reach another piece of code, which is revealed only if we keep up with the control flow.


Figure 4: File-path, name identification (anti-debug)
The above code uses “strstr” to look for a string named “sample” anywhere in file path of our currently debugged file. If found, “strstr” returns a pointer to first occurrence of search string(i.e "sample") in file-path, or else it returns zero. The malware then checks the return value in EAX and takes a conditional jump in the form of JE instruction at "0x401135". If the jump is not taken, the code lands in “ExitProcess”, a call which terminates the process.

This is the second anti-debugging technique the malware employs, although not-an effective one in my opinion considering the odds of a file-path or malware name containing the name “sample”.


Figure 5: GetVolumeinformation, Volumeserial (anti-debug)

Again, here we have another anti-debugging technique where the malware retrieves the Volumeserial number using the API GetVolumeinformation and compares it with  “0CD1A40” and “70144646”. If either comparison matches, the code jumps to the ExitProcess call.

Another anti-debugging technique follows immediately thereafter in the form of “EnumSystemLocalesA”. The first argument that "EnumSystemLocalesA" accepts is a pointer to the callback function. Here the malware does a neat trick. If we look at the code below, at address “0x401179” a constant “0x2” is pushed onto the stack, which is followed immediately by a CALL. 

When this CALL is executed, it pushes the return address onto the top of the stack (which is "0x401180") and the EIP (Instruction pointer) now lands at the "EnumSystemLocalesA" call. Now if we observe the stack, the value on top of the stack is the return address, which naturally becomes the callback function address for "EnumSystemLocalesA" . When the "EnumSystemLocalesA" API is executed, control falls to the callback function, which continues the execution of the code. 


Figure 6: EnumSystemLocalesA (anti-debug)

Let's now continue our debugging from the address “0x401180”. Not far from here, yet another anti- debugging technique is uncovered. This time the malware retrieves the ‘Diskname’ from the registry. 


Figure 7: Diskname (anti-debug)

"RegOpenKeyExA" (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Disk\Enum)  and  "RegQueryValueExA" then uses “strstr” and searches for signs of a virtual environment such as “Xen”, “Vmware”, “Qemu” and also looks for string “virtual”.


Figure 8: Search vm strings(anti-debug)
Once the malware detects a virtual environment, it changes the control flow and land us in an invalid memory region. If we play along, we can observe something interesting here.


Figure 9: Adobe.exe crash
There we go. We can finally reproduce the crash that happened during the first stage of our analysis.
Ok, so a through binary analysis is often not so straight forward after all !!!

Figure 10: sandbox identification(anti-debug)
Let’s move on and see what surprises the malware has this time. Below, we can see anotherpiece of code that checks for a DLL name called “sbiedll” . Here, the malware checks whether it is run in a popular sandbox called “sandboxie”. If found, as usual, the malware bails out.


Immediately afterward, the malware performs a decryption routine to reveal compressed data, which is again packed with aplib and below we can observe the aplib unpacking routine which decompresses the data to a PE file.


Figure 11: Aplib decompression routine

Soon after, control is passed to the newly decompressed file. Below, we can see the new file being executed.


Figure 12: New PE-file in memory

Debugging further, we can observe the malware revealing the final trick that it has up it’s sleeve ,which I will explain in the next post in this series.




Want to Spy? Google Play will help you

Spyware or legitimate monitoring application? You decide. In this blog we'll discuss a 'legitimate' app that can be purchased in Google Play known as SMS Tracker. Now it's legitimate as it advertises exactly what it does, but based how this same application is packaged and distributed in other markets, it's clear that the vendor is also targeting another, less altruistic audience with this same application. The app also illustrates the powerful access permissions that an application can gain so long as the end user agrees to it, either explictly or otherwise.
Details about the application:
Installs: 10,000-15,000.
As per the description on the application’s Google Play page, the application is able to do the following:
  • SMS Tracking – Intercepts text messages. Read all inbound and outbound text messages. Details include time and date, phone number, contact name and location of the target phone. Complete Text message tracking and logging.
  • MMS tracking - Intercepts MMS multimedia messages. Read and view all inbound and outbound MMS messages. See what photos are sent to and from the target phone. Details include photo, time and date, phone number, contact name and location of the target phone.
  • Browser Tracking – monitors all web browser activity on the target phone. Know which websites were visited, which pages were viewed and when.
  • GPS Tracking – Logs GPS location information wich can later be viewed on a map. Know when and where the phone was located at all times. Breadcrumbs to record location information allowing parents to locate their children at frequent intervals. GPS logging occurs at a user defined rate (default interval is 5 minutes). Remote GPS logging and viewing give you the ability to see the location of your child’s phone, from any web browser. The breadcumb trail offers powerful GPS Tracking.
  • Call Logging – Monitors all inbound, outbound and missed calls. Identifies the phone number, contact name, call duration, and location of the phone for every call.
  • If you want to know where your kids are, just send them a text message. The location of the phone is
  • recorded every time it sends or receives a text message.
  • Tracking of System Events, including Device Powered On/Off, Device Attached / Removed to/from the charger, Apps installed/removed/updated.
  • Silently monitor all inbound and outbound SMS messages.

How the app can be used?
First you need to download the application and install it on the device on which you want to spy. After installing an application you need to register it. Next, you need to go to http://smstracker.com, where you will be asked for your login name and password ,which was registered at a time of installing the application.

This screenshot shows the dashboard after login.
This screenshot shows the page where you can see logging from the device. It covers SMS, device information, call logs, network traffic, location details, etc.

Zscaler’s concerns:
In any other context, an application with these capabilities would clearly be labelled as spyware. At the vendor's (http://smstracker.com/download.php) they are selling a repackaged version of this app which has the same functionality but does not leave an icon on the device, thus making it more stealthy and harder to detect following installation. This version also does not contain the notification icon or privacy policy screen. Why the transparency? What audience is this version targeting?

This same application could also serve generic template for other spyware projects by being wrapped with other code to provide the core functionality needed to create another malicious app. 

This type of app clearly shows the powerful level of access that can be granted to Android apps, so long as users grant permission. An app can access SMS, call logs, network traffic, hardware details, screen details etc. Always carefully read the permissions requested by an application before installing it on your device.

The vendor is promoting this application as a tool for monitoring the mobile activities of your children. However, this same app would be a very effective tool for spying on someone once installed on their phone. You just need to install the app on the device which you want to spy and you are done. All the information about the device and all call and SMS logs can then be remotely monitored.

Moreover, all of the user's private data is stored on the vendor's server. What guarantees are in place that the private data will remain private? In the increasingly common enterprise world of “Bring Your Own Device” (BYOD), such applications could be leveraged to expose corporate contact lists, email, browsing information and collect private data from corporate apps in the workplace. Enterprises often block access to 'non-official' app stores to prevent the installation of such apps, but this illustrates that such a restriction is no guaruntee that spyware can't be installed from an official source.

Virustotal scan results:
The application available from the vendor site (smstracker.com):
The Google Play store’s version:

Interestingly, despite virtually the same functionality, far fewer AV vendors flag the Google Play version as malicious.

- Viral

Monday, January 6, 2014

Yahoo Ad Server Compromise Recap

Malware writers had a big week to start off the new year by using Yahoo Advertisement services to peddle their warez.  The talent over at Fox-IT broke the story last week which set Team Z on the hunt.

The primary focus of our attention was on the Magnitude EK (Exploit Kit), which was distributed via a Malvertising campaign designed to infect the maximum number of users in a small amount of time.  These attacks are particularly dangerous to websites who rely on advertising revenue to fund their sites activities.  Protecting Ad servers should be held to a higher scrutiny than other content distribution channels for this very reason.  If user's find themselves at risk more often than they prefer , then they will adopt ad-blocking applications such as AdBlock.

This attack started at precisely Wed Jan 01 23:17:05.  The attack lasted all through Friday the 3rd, until Yahoo and other researchers caught onto this treachery and promptly put a stop to it.  We track the last transaction serving up malware from ads.yahoo.com/* at approximately Fri Jan 03 02:16:48.  In that time, the following domains were seen to host a malicious iFrame from an ads.yahoo.com transaction:

blistartoncom[.]org/
slaptoniktons[.]net/
yagerass[.]org/ 
original-filmsonline[.]com/ 
funnyboobsonline[.]org/

These domains would redirect the user to a Magnitude EK with a randomly generated hostname to attempt hindering researcher's ability to track the threat.  However all these sites were hosted on the same IP address hosted in the Netherlands (193.169.245.78).

201116.pzmu.nsv.ha.ywyh.ya.fmpryuyqoz.crisisreverse[.]net
201111.inrx.itlqojqjton.boxsdiscussing[.]net
201111.jz.ek.al.psx.pfzzypjydv.limitingbeyond[.]net
201111.cd.da.mlx.dupn.sci.rdwxbioveahx.boxsdiscussing[.]net
201111.fef.mma.rdwxbioveahx.boxsdiscussing[.]net
201111.kxox.jgru.oktl.rdwxbioveahx.boxsdiscussing[.]net
201116.yphu.ixrwpvewnkui.limitingbeyond[.]net
201111.ygiv.wdh.ioycntlg.boxsdiscussing[.]net
201116.cx.zq.ixrwpvewnkui.limitingbeyond[.]net
201111.wi.kyk.vm.bq.ioycntlg.boxsdiscussing[.]net
201111.qx.pp.amuq.gp.fz.txlqbyjrlcl.crisisreverse[.]net
201117.lgr.duohlqzrzqw.limitingbeyond[.]net
201311.urho.ru.pis.tf.ixrwpvewnkui.limitingbeyond[.]net
201311.kpxt.twqr.fse.rpcq.ixrwpvewnkui.limitingbeyond[.]net
201117.sy.mp.kc.qd.loty.duohlqzrzqw.limitingbeyond[.]net
201116.md.jpij.ezj.pdu.cinmvjurxop.boxsdiscussing[.]net
201117.zmb.pshi.ldf.xqk.duohlqzrzqw.limitingbeyond[.]net
201311.fex.qhpz.pje.gfu.xvroferresd.liechecks[.]net
201111.qhh.orit.tka.bwqvkvvaithe.suggestsfilm[.]net
201111.txz.rrjh.wdx.uvh.uqgz.paftwtdqc.limitingbeyond[.]net

Other root domains include:

chapterwild[.]net
elsecommenting[.]net
farmtrains[.]net
federalpoet[.]net
irritatedpound[.]net
layfriend[.]net
suggestsfilm[.]net

In the time that this threat was active, an approx total of 21,000 transactions occurred.  This speaks to the effectiveness of malvertising campaigns.  A single site compromise yields only victim's who frequent that site, a ad server compromise not only affects that site, but also all sites which use advertisements from the site.  Malware writers will continue to find methods to cast the largest possible net to rope in more victim's to their dubious activities.

At this time, we are still investigating all aspects of the threat in a postmortem process.  It's been reported that the compromise propagated the following malware families:

  • Zbot
  • Andromeda
  • Dorkbot
  • Various Adware
  • Tinba
  • Necurs

ThreatLabZ will continue to monitor this threat.