Probing into the Flash Zero Day Exploit (CVE-2014-0502)

Yesterday, a targeted campaign leveraging a Flash zero day exploit hit the news. Adobe has now released a security bulletin regarding this vulnerability. Based on the attack vector mentioned in prior research, we have concluded that recently observed .SWF exploitation is related to the recent zero-day threat flagged as CVE-2014-0502. Upon successful infection, the exploited victim is served a RAT (Remote Access Trojan). 

While we were doing our daily review of logs, we found a significant number of transactions related to this campaign. We specifically started looking for those compromised servers which have been mentioned in prior research.  We began investigating all suspicious transactions which used a known compromised site as a referral location. 

After some brief inspection of this location, we found not only the malicious .SWF, but also all other connected malicious files detailed in the analysis below. We will cover the dropped Flash file that exploits the vulnerability using an image that contained embedded shell code. This shellcode is then used to download the malware.

The Flash file was found to be encrypted using the DoSWF flash encryptor.

Upon throwing the Flash file into an ActionScript viewer, we immediately see the script shown below. The script tries to make a URL Request to a GIF Image file, which contains the embedded shellcode for an ROP exploit.

The script checks for the presence of a cookie labeled 'XPT2013111'. If this cookie is not already present, it sets the same.

The script then checks the operating system version and in the case of Windows XP, further checks the OS language. Details of the OS language and version are then used to determine the base address for the exploit. In case of Windows 7, the script further probes for unpatched and outdated versions of Java (Web Start 1.6 and 1.7) or Microsoft Office (Sharepoint OpenDocuments 3 or 4).




Here we can see on XP, based on the version and language, the base address for the exploit is determined by the script. Then the ROP sled is built to carry out the exploit.

The GIF image used for embedding the shellcode is shown below, which of course seems innocuous to the victim.

 

When opened in a hex editor, the magic bytes for a GIF image file can be seen.

However, upon careful examination, we further see extra bytes appearing toward the end of the image as shown below.

Using a shellcode emulator like libemu, we can see that this extra data represents the shellcode to be executed.

Here we see that the shellcode makes a call to the LoadLibraryA function and then to VirtualProtect to allocate memory in which to place the shellcode. It then checks for the /temp folder path and makes calls to InternetOpenUrlA to download the malware from a remote location http://[x.x.x.x]/common/update.exe and drops it into the /temp folder.

A sandbox analysis of the final dropped file can be seen here.

Browser plugins continue to be the Achilles heel of enterprise security. While enterprises struggle to ensure that browser plugins are up to date on all end user systems to prevent browser exploit kits from targeting known vulnerabilities, here we see yet another demonstration where even that is not enough. Attackers continue to identify and exploit 0day vulnerabilities in popular web browser plugins such as Adobe Flash, which unfortunately has a long history of dealing with such threats.

New Asprox Variant Goes Above and Beyond to Hijack Victims

[UPDATE] After further analysis, this threat was identified as Asprox botnet and not Zbot

Asprox is an extremely venomous threat, which has strong persistent tactics to ensure that the victim remains infected despite removal attempts. We will get to the overabundance of methods used to keep the victim infected later on. First, I'll share some of the latest download locations for this threat, which researchers should take note of:

• hxxp://king-orbit[.]com/libs11.18/ajax/
• hxxp://message-tvit[.]com/libs17.19/ajax/
• hxxp://bidcos-fact[.]com/libs20.17/ajax/
• hxxp://vespula-grants[.]com/libs31.56/jquery/
• hxxp://bee-smoka[.]com/libs29.89/ajax/

The bulk of these threats are tied to a server found in Russia: 88[.]85[.]215[.]129.

Reminiscent of other malicious infections, the second the threat is run, it deletes itself in order to hinder researchers when conducting a reverse engineering analysis of the attack. The next step is to create a Security Center Task in Windows, to ensure that even if the threat is removed, it will reoccur.

The filename is randomly generated.

Note the filename of the .job file, which is dropped on the victim's machine.  This name is randomly generated.

In addition to ensuring that the threat restarts if the victim were to reboot, it also disables key Windows processes to hinder removal of the threat.  This includes disabling Safe Boot registry keys.

This disables users access to boot into Safe Mode to run standard AV solutions.

Once installed and hooked into the victim's environment, it begins the task of phoning home to its Command & Control (CnC) location for tasks to complete.  Periodically, it will receive a GET request from the CnC to make sure that the victim is still listening.

Hi! to you too.

Given the stealth tactics employed by this threat, you may not be aware of the infection straight away.  You may however become suspicious when you start to feel the drag on your Internet connection. Behind the scenes, the threat is actively reaching out to several different ad servers as a means to promote ad revenue for the attacker.  Below is only a portion of the servers that were contacted in the course of a few minutes.

All transactions do not take place in the browser, but behind the scenes.

Administrators concerned for their user's safety should take note of usage patterns.  It won't be difficult to spot a user sending out absurd amounts of ad traffic.  You can either look through your logs for large amounts of advertisement traffic OR find HTTP POST requests with the string '/b/opt/' in the URI path.

2.254 Mbps!!!

While this threat is persistent, it is easy to spot from a Network Administrator's point of view.  The information provided should be enough to find your infected users to take them off of the network until remediation of the threat can be completed.

You can find open source sandbox analysis of this threat here and here.  There is also a more detailed analysis found here.

Mind Your Clicks.

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.

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:

Name: SMS Tracker.

Installs: 10,000-15,000.

Description: http://smstracker.com/

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):

https://www.virustotal.com/en/file/21aa6c6652287413f07ddfbcadea84441a500ee12816dfe4beed913e4a0fa636/analysis/

The Google Play store’s version:

https://www.virustotal.com/en/file/a3b40fa9fea9600b55d4d07fd4f0358ee74e6924c342c5857c2a5311f7a11ed3/analysis/

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

- Viral

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.