Tuesday, March 22, 2016

A look at Locky ransomware

Introduction

The Locky ransomware was first spotted in the wild in February 2016. Locky came into the limelight when it hit the Hollywood Hospital last month causing the hospital to pay Bitcoins worth $17,000 in ransom.  Locky is known to arrive via spam e-mails containing malicious attachments.

Zscaler has blocked over 75 unique & new payloads from this ransomware family, targeting our customers, in the last month as shown below:

Locky ransomware unique payloads blocked

The Locky payload delivery mechanism

The initial wave of Locky ransomware spam involved malicious Microsoft Office documents containing VBA macro to download and execute binary payload on the victim machine. Locky authors have since switched to spamming a Zip archive containing malicious JavaScript to download and execute the Locky payload

A sample malicious document from a Locky spam campaign that contains VBA macro designed to download the Locky payload from a predetermined remote location can be seen below:

Malicious Document

A second delivery mechanism involves a heavily obfuscated JavaScript files in a Zip attachment. These JavaScript payloads are highly obfuscated and leverages UTF-16 encoding to hide the download URL. The authors are also changing the obfuscated payload regularly in order to evade AV detection, a technique commonly used by Exploit Kit (EK) authors to protect the EK landing pages. A sample malicious JavaScript code delivering Locky ransomware can be seen below:

Obfuscated JavaScript to deliver Locky
The JavaScript uses ActiveX objects to download Locky ransomware on victim's machine. The decoded JavaScript is shown below:


Decoded JavaScript

Payload Analysis

We have seen a large uptick in the delivery of Locky payloads during the month of March 2016.

Uptick in Locky payloads getting blocked
We looked at one of the newer Locky variant that was seen in the wild recently. The analyzed Locky payload is a 32-bit Microsoft Visual C++ compiled Windows executable packed using custom packer routine.

Upon execution, the malware first checks for the user & system default language preferences of the infected system and terminates itself if the language is Russian. Locky creates a copy of itself as "%TEMP%/svchost.exe" and an auto start registry key entry to ensure persistence upon system reboot. In order to mark a successful infection on the system, Locky creates the following registry keys with value name "pubkey" and "paytext" as seen below:

Locky registry key
"pubkey" is used to store the RSA key used for encryption
"paytext" is used to store the payment related information

Upon successful infection, Locky will encrypt the following file types on the victim machine:

File types encrypted
These encrypted files are renamed to unique ID generated for the victim's machine followed by unique file ID and a ".locky" extension. The ransom note is displayed in a bitmap image that is also set as a wallpaper for the infected user's desktop as seen below:

Ransom note
As seen in case of other crypto ransomware families, victim's files are held as hostage for a ransom. The ransom payment instructions for receiving the private RSA key required to decrypt the user files is readily available through the URLs mentioned in the ransom note.

Payment instructions

Command & Control communication

The Locky payload contains a list of hardcoded Command & Control (C&C) server IP addresses that appear in plain text in the unpacked binary as seen below:

Hardcoded C&C IPs
In addition, Locky ransomware also leverages a custom Domain Generation Algorithm (DGA) for hiding its C&C server location. The DGA algorithm used for generating possible C&C domains in the payload that we analyzed can be seen below:

Domain Generation Algorithm

Locky communicates with the C&C server using custom encryption and the following HTTP request format:

POST  http:// [hardcoded IP  or DGA domain]/main.php

Sample encrypted C&C communication


The initial C&C communication typically consists of three HTTP POST requests.

Request #1: Register the infected system's unique ID and request RSA key to be used for encrypting user files. The figure below shows the content of this POST request in plain text:

C&C request #1






The server responds back with a RSA key that is used by Locky to encrypt all the user's files on the victim machine.

Request #2: Request the content of ransom note to be displayed on the infected system asking for payment. Below is the content of this POST request as well as the response from the C&C server in decoded form:
C&C request #2 & response
Request #3: The final request sends the statistics about successfully encrypted files as seen below:
C&C request #3





Conclusion

Locky is the latest addition to Ransomware, one of the most active & lucrative malware strains seen in past three years. This new ransomware family follows the same model of using asymmetric (public key) encryption to lock user documents and demand ransom for the decryption key.  The delivery vector has been primarily spammed e-mail attachments that are responsible for downloading the Locky payload. We also noticed an interesting overlap in the recent campaigns where same URLs were being used to deliver both Dridex & Locky payloads.

Zscaler’s ThreatLabZ has confirmed coverage for the initial downloader and Locky payloads, ensuring protection for organizations using Zscaler’s Internet security platform.

Research by: Deepen Desai, Dhanalakshmi PK

Thursday, March 17, 2016

Adult themed Android SMS Stealer Trojan

During our continued efforts to protect our customers against the latest mobile threats, we came across another malicious app that used pornography to attract users. Noting that 1 in 5 mobile searches are related to porn, it’s no surprise that hackers continue to create fake porn apps to disguise malware. Our researchers analyzed another similar adult themed malware in November last year.
  
App Name: 岛国速播
URL: hxxp://bhltzgs[.]com:81/sebo363[.]apk
MD5: f71f8db8994699299b0bcda31d951c41
Package Name: ugo.jkh.efp
VirusTotal Detection: 15/55

Overview:

The application in question is presented as a porn player. When the user clicks on the application icon, he or she will be presented with thumbnails to many porn videos. When the user tries to play one of these videos, the application will download 3 files in the background and a shortcut will be placed on the main page of the device. The application also requests on-demand videos via SMS - costing the user money without them knowing. The 3 dropped files are also depicted as porn players. When the user clicks on videos shown in these applications, they again drop more files to the device - resulting in a never-ending process. Some of these dropped files have icons that look similar to the Internet Explorer and Angry Birds applications for the sole purpose of scamming the user. However, these dropped applications are actually SMS stealers or fake installers.

Details:


When you try to install the application, it asks for the following permissions:




Permissions


Upon launching the application, you will be able to see a list of obscene videos. When you click on any of those videos, instead of playing them the malware drops 3 additional porn applications on the device.



Different Levels



Technical Analysis:


When the user tries to play a video from the application, a JAR file is downloaded from the link hxxp://link[.]kssgx[.]com/cj[.]jar. This URL is stored in the application in the following fashion:


cj.jar URL formation


Subsequently it fetches another URL from the downloaded cj.jar, which is then used to drop multiple malicious apps to the user's device. The link for downloading the dropper files are stored in an xml file, the link to which is present in cj.jar


URL for XML file


This xml file contains the URL for downloading the dropper files.


XML file contents

All the downloaded files have been flagged malicious by multiple AV vendors. Here are links to 3 malicious APK files dropped on the device by the main application:
  • hxxp://sfgg[.]gpdzj[.]com/download/20160302/mmys1069[.]apk 
  • hxxp://www0127[.]007wr[.]com/a[.]php?aid=1313 - Qvodplayer1001.apk
  • hxxp://csu[.]hsouying[.]com/IJjyMj - this gets redirected to hxxp://appcdn[.]hsouying[.]com/video/appstore1/destapk/1457085498605/avplay02039[.]apk
These files also take the form of porn players, but are actually SMS stealers. When the user tries to launch one of these applications, it again results in dropping of more files into the device, which continues a never-ending chain. Two of the dropped applications have icons similar to Internet Explorer in order to scam the users into using the application.



Downloaded Applications
This application downloads yet another file from the link hxxp://cdn2[.]upay360[.]cn/pack[.]dat. This is a jar file, which shows some really shady behavior. This jar file uses 3 broadcast receivers:
  • SMSReceiver 
  • SendBroadcastReceiver
  • DeliverBroadcastReceiver
The application uses the concept of pending intents, which allows another application to use your application's permissions to execute a predefined piece of code.

SMSReceiver is triggered whenever an SMS is received. Its functionality is to fetch the details of each new SMS. It checks whether the SMS has been sent from China and if so, will abort the notification so that the user has no knowledge of the new SMS.

SMS Receiver

The application also scams the user with premium on-demand videos, which are requested via SMS without the knowledge of users. This application leverages the commonly known 1npay to scam the victims. The application sends out a POST request, in which the method of payment is specified via SMS.

POST request for SMS

SendBroadcastReceiver listens to the order SMS being sent to the number 106566660020, which is hardcoded in the application. On sending the order message, the user will receive a verify code via SMS. SMSReceiver aborts the broadcast of this message so no notifications are shown for the delivery of the new message to the end user.

DeliverBroadcastReceiver retrieves the verify code from the message and sends it in order to verify the order. This whole process causes the user to lose money.

The application also sends device related information. Below is the POST request sent by the application that was captured during our analysis:

Device Details in post request

Removal:

Since the malware does not ask for Administrator privileges, removing it is not a difficult task.

The victim can traverse to Settings option in the Android device.

  • Settings --> Apps
  • Find the app in the list and click on it
  • Then, click on Uninstall option
  • Click Ok
We urge users to not trust any unknown links received via messages or emails. Additionally, disable the option of "Unknown Sources" under Settings of your device. This will not allow installation of apps from unknown sources. 


Conclusion:


The application divides the overall functionality between the various dropped files. This can be a mechanism to evade detection by AVs. If one of the applications is detected by AV, the other applications can continue with their work. It is also interesting to note that each of these dropped applications try to target different sim operators in China.

There has been an increasing tendency of malware in disguise of adult rated applications in order to attract victims. The best way to avoid such applications is to stick to official app stores like Google Play and the Amazon app store.

---
Research Blog by - Lakshmi Devi & Shivang Desai

Thursday, March 10, 2016

Android Marcher now marching via porn sites

Introduction

Android Marcher Trojan was first seen in 2013 scamming users for credit card information by prompting fake Google Play store payment page. In subsequent years, Marcher variants also started targeting banking applications by presenting fake login pages to steal user credentials.

Marcher has continued to stay active and was recently covered by phishlabs. In this blog, we will cover a new wave of Marcher Trojan that is active since past one month where the malware arrives as an adobe flash installer package. We have captured over 50 unique payloads from this campaign. Majority of these Marcher payloads are from pornographic sites serving fake adobe flash player for watching porn. The primary goal of this malware is still the same - display a fake Google Play store payment page and steal financial information from the user.

Technical analysis

The infection cycle starts with the mobile user receiving a malicious URL via e-mail or SMS. Once the user opens this URL, the site will prompt the user to download and install the Adobe Flash Player update as seen below:
Fake Adobe Flash Player outdated warning
The file that gets downloaded as a result of this action is aptly named - AdobeFlashPlayer.apk. Upon installation, malware asks for administrative access in order to perform its functions as seen below:

Requests administrative access

Once installed, Marcher connects to a predetermined Command & Control (C&C) server and sends information about all the installed applications on the infected device as seen here:

Relaying installed package information to C&C
During our analysis, we also observed a unique approach where the C&C server will send a response generating a MMS notification on the infected device saying "You have received MMS" and instructs the user to visit "mms-service[.]info/mms" to see the content of the MMS.

MMS content
This site redirects the user to the X-VIDEO app on official Google Play store. According to several reviews of this app, the users are claiming it to be a fake app that simply crashes after installation. We were able to verify the same crash behavior when installed on the latest Android OS Marshmallow 6.0.1.  We haven't analyzed this app in any further detail but have been in touch with Google's Android team to review these findings. The app in question has been downloaded more than 100,000 times and some of these downloads may have happened from infected devices. (UPDATE: This app has been verified as clean by Google's Android team but they are monitoring it further.)

Official Play store app- X-VIDEO
As part of the infection cycle, Marcher will then display a fake Google Play payment screen asking for payment information to complete the account setup.
Fake Google Play payment screen.

Credit card information.
If the user falls for this screen then the credit card information is logged and relayed to the C&C server as seen below:
Payment information sent to C&C server.

Information being sent to C&C server
Newer variants of the Android marcher will also present a fake online banking login page based on information collected about already installed banking apps on victims device. Here is a sample fake login page that the user will see if the infected device has Commonwealth Bank of Australia mobile app installed.

Fake NetBank login screen

The user banking credential information is relayed back to the C&C server in plain text as seen below:

Stolen information sent in plain text
Following are some of the financial institution mobile apps that are targeted by Marcher:
  • BankSA - Bank of South Australia
  • Commerzbank
  • Commonwealth Bank of Australia - NetBank app
  • Deutsche Postbank
  • DKB - Deutsche Kreditbank
  • DZ Bank
  • Deutsche Bank
  • Fiducia & GAD IT
  • ING Direct
  • La Banque Postale
  • Mendons
  • NAB - National Australia Bank
  • PayPal
  • Santander Bank
  • Westpac
  • WellStar billpay app

Conclusion

Android Marcher has been around since year 2013 and continues to actively target mobile user's financial information. To avoid being  a victim of such malware, it is always best to download apps only from trusted app stores, such as Google Play. This can be enforced by unchecking the "Unknown Sources" option under the "Security" settings of your device.

Zscaler ThreatLabZ is actively monitoring this malware and ensuring that Zscaler customers are protected.

IOCs

C&C URLs
  • hxxp://78[.]46[.]123[.]205/111/get[.]php
  • hxxp://78[.]46[.]123[.]205/111/set_card[.]php
  • hxxp[:]//petrporosya[.]com/123/1/01[.]php?id=[UNIQID]

Sample URLs serving the Android Marcher payloads
  • hxxp://lovehomevideo[.]cf/adobeflashplayer[.]apk  
  • hxxp://videolike[.]ga/adobeflashplayer[.]apk  
  • hxxp://lovehomevideo[.]ml/adobeflashplayer[.]apk  
  • hxxp://analsextube[.]ml/adobeflashplayer[.]apk  
  • hxxp://myporno[.]cf/adobeflashplayer[.]apk 
  • hxxp://mymovie-porn[.]ga/adobeflashplayer[.]apk  
  • hxxp://lovehomevideo[.]ga/adobeflashplayer[.]apk  
  • hxxp://adobe-flash-player[.]su/flashplayer[.]apk

Monday, February 29, 2016

A Case of Keitaro (featuring RIG and Nuclear)

Introduction


Zscaler ThreatLabZ closely monitors exploit kit activity and we have seen some interesting trends in RIG Exploit Kit behavior recently, including a significant spike in cases observed in the wild. We specifically saw large upticks in the closing weeks of January.

Fig 1 - RIG Blocks over 2 Months


While trying to replicate some of the cases in our testing VMs, we found an infected site suddenly began serving Nuclear EK, and we noticed it doing so via a Keitaro Traffic Distribution System campaign. We have been monitoring these actors since, and in this blog we will briefly describe the activity seen among these campaigns of Keitaro, RIG, and Nuclear.

Keitaro TDS


Traffic Distribution Systems are software and service packages that do pretty much what the name says: their primary function is to intelligently route web traffic that arrives at the TDS operator controlled server. This is not to say they don't have any other functionality, major TDS packages like Keitaro actually provide a great deal of flexibility and control, and malware and exploit kit operators take significant advantage of these features.

In an industry that generally prefers to keep operational and functional details under wraps, Keitaro is an interesting beast that doesn't shy away from the public eye. Keitaro not only has a readily accessible public website with what appears to be a reasonable cost and easy purchase process, there is also a full online help section and an online demo!

Fig. 2 - Keitaro TDS Dashboard



Overview

Keitaro has many features and options, and we don't want to recreate the online help files, so we will only cover some of the basics with few other interesting highlights. This TDS operates on highly-customizable campaigns which come in three flavors: standard redirects, banner serving, and simple impression tracking. These campaigns can have multiple "streams" chosen by linear or randomized selection, and can identify users by IP and/or cookie and enforce unique hits on them across variable timeframes.

Fig 3 - Keitaro TDS Campaign Creation


Besides identifying users by IP and cookies, Keitaro can make decisions based upon a wide variety of features including:
- browser version
- geographic location
- OS/platform
- Mobile carrier

While we can't say which specific rules have been set up by the operators of this instance of Keitaro, we have seen some behaviors mentioned above (especially blocks on repeat attempts from the same source IPs) in addition to the gate serving both RIG and Nuclear at different times.

Observations


So far, we have described a system that seems perfectly above-board, however Keitaro has some features that appear to be designed specifically for bad-actors such as EK operators. One major feature recently highlighted by Kafeine is the addition of AV checks. This feature allows the TDS operator to make sure none of the payloads being served are detected by AV vendors. Conveniently, they integrate with services that don't share samples with the AV industry. Additionally, there is a section in the help files that specifically details how to break referer chains. This is a feature that directly impacts the ability of researchers to trace activity chains and connect exploit kit instances back to the originating site.

Fig 4 - Keitaro TDS Help Information

While Keitaro appears to be very powerful and highly polished product, we spotted some interesting misconfiguration side effects from this campaign. Early on in our monitoring, the TDS would attempt to direct repeat visitors to "www.yahoo.com" using a 302 redirection. It turned out that, lacking the scheme portion of the URL, the redirect ended up sending users to the login page of the Keitaro admin panel. This is illustrated in the screenshot below, where an infected page has two injections for the Keitaro gate. The first injection yields a RIG cycle and the second improperly attempts to redirect to Yahoo.

Fig 5 - Keitaro TDS Redirecting to Admin Panel

Another misconfiguration case we saw may have been an issue more related to the EK infrastructure than on the TDS itself, but one visit to an infected site yielded a redirect to an invalid RIG URL: hxxp://out%2520of%2520datedate/?apitoken=l3SKfPrFJx_ESYjCJunFSrdObkXRFh-BxoubkOM

Despite the occasional misconfigurations seen in this Keitaro instance, it has proven to be a significant source of traffic for both RIG and Nuclear.

Fig 6 - Keitaro Traffic over 30 days

RIG


The RIG Exploit Kit has been very active in recent weeks, and we have identified multiple campaigns with some varying tactics. We've seen a few cases of malvertising and multiple styles of gates including the occasionally misconfigured Keitaro already discussed..

Gates

In recent behavior, we have seen two primary types of gates being used besides Keitaro. The first was the common gate that has been seen in RIG campaigns for some time. The second was a series of gates that followed a pattern of using the same second level domain across four top level domains, rotating the second level names roughly every 24 hours.

Common RIG Gate

We don't have a clever name for this gate, but it's a familiar pattern, with a number of features at malware-traffic-analysis.net. It uses a host naming scheme similar to the infrastructure that actually delivers RIG landing pages and payloads: a two letter third level domain on top of what appear to be domain-shadowed accounts at Godaddy. The URL path in each case is a randomized .php filename with no parameters.

Quad Power Gate

Due to their use of the same second-level name across four TLD's, we are calling this the Quad Power Gate. This gate utilizes the TLDs .win, .top, .party, and .bid. Though the operators of this gate cycled the hostnames frequently, the path used for the gate's URLs has only changed twice. The first hits seen on the Zscaler network were to domain.tld/persil.php, but we later saw domain.tld/deliner.php. Beginning on the 23rd of February, we the gate began using the filenames "magnum.php" and "puerto.php".

Fig 7 - Quad Power Gate Repeatedly Serving RIG

While a casual glance at the content returned by the gate might lead one to believe it's simply serving a jQuery script, the truth is that a RIG iframe is actually hidden between large blocks of Javascript. This gate also turns out to be a repeat offender, not only because we found its presence in a number of infected sites, but the gate has a tendency to repeatedly refresh itself, generating one RIG impression after the other. Although we could not confirm any specific instances, we believe this gate to have been used in malvertising attacks as well.

Landing Pages


RIG landing pages, much like the URL pattern used, has not changed too much. The landing page basically consists of one large blob, with multiple script objects, and several layers of encoding and obfuscation.

Fig 8 - Exceprt from RIG Landing Page

Payloads

Execution is achieved on victim machines via two primary paths: first the usual IE/VBScript God Mode exploit (CVE-2014-6332), and second a large and highly obfuscated Flash payload. Despite the complexity of the protections employed, they are not using the Diffie Hellman-based protection for triggers and shellcode stages. The Flash payload appears to focus on CVE-2015-5122

As for malware, we have recently seen Tofsee being delivered by RIG.

Fig 9 - Strings Decoded from Binary Data in RIG Payload

Nuclear

Like RIG, the Nuclear Exploit Kit is a prolific threat to web surfers. However, it maintains its position in the EK hierarchy, being more sophisticated than RIG yet not quite as cutting-edge as Angler. As an illustration of this point, we have not yet seen Nuclear adopt the latest Silverlight exploit that Angler recently debuted.

Fig 10 - Nuclear Blocks over 2 Months

Gates


Besides the Keitaro gates, we have seen one prolific gate pattern over all else. The operators of this campaign seem to use infected sites which then redirect to the Nuclear landing page. We have seen some very interesting cases of this gate, including one site apparently owned by a bicycle shop in the UK. In this instance, the gate injection was served via the shop's Ebay page, in requests for embedded images.

Fig 11 - Nuclear Gate Inject in Image from Ebay Listing


Landing Pages

Nuclear's landing page continues to utilize data stored in various HTML elements, which is then parsed by scripts to identify browser and plugin features and determine the execution flow.

Fig 12 - Nuclear Landing Page Excerpt


Payloads


Nuclear continues the trend of delivering single file Flash payloads, with multiple secondary payloads: one each for Flash versions <18.0.0.203, <19.0.0.207, and higher. We saw an interesting change between the method used to transition to the secondary payloads.

The initial first-stage SWF used a complicated execution flow with the three payloads being constructed across multiple functions. In each case, two separate arrays of bytes are combined before a version-specific XOR key is used for the "final" payload. We use quotes around "final" because Nuclear continues to utilize a Diffie Hellman protocol to protect the actual exploit trigger and shellcode stage.

Fig 13 - Nuclear Stage 1 Payload Obfuscation


The latter first-stage Flash payload dispensed with all of the complicated reconstruction, and simply uses base64-encoded strings to encode the second-stage SWFs. The second-stage payloads, however, were almost identical to those found in the previous iteration as shown below.

Fig 14 - Nuclear Stage 2 Payload Comparison

The second stage exploits appeared to be CVE-2015-5122 for Flash <18.0.0.203, CVE-2015-7645 for <19.0.0.207, and the "default" case of CVE-2015-8651 for anything newer. Besides the Flash exploits, we also saw CVE-2013-2551 for direct exploitation of IE.

Following succesful exploitation, we have seen Dofoil being installed. The screenshot below shows its signature pattern of decoy GET and POST requests to URLs in the browser history with a few actual callbacks mixed in. The command & control server even uses 404 error codes to attempt to mask the nature of the callback activity.

Fig 15 - Nuclear Cycle Including Dofoil Callback and Decoy Traffic

Conclusion

Though Nuclear and RIG both generate a good deal of impressions via other routes, the Keitaro gate has been a significant source of traffic on its own. It's clear that the flexibility in Keitaro's configuration options make it a powerful partner for the criminal operators of these and other exploit kits. As always, Zscaler ThreatLabZ will continue to monitor Nuclear, RIG, and Keitaro for further developments.