Thursday, October 29, 2015

Infostealer APK Posing as Microsoft Word Document

Recently, we came across a piece of Android malware which was neither a porn app nor a battery status app, but was instead designed to look like a Microsoft Word document. This malicious app portrays itself as a document with an icon resembling Microsoft Word.

Due to the ubiquitous nature of mobile devices, its no wonder that PC based malware techniques are appearing in mobile domains. In early Windows malware attacks, attackers would often name the malicious files with eye-catching titles and use common icons to entice victims to open the file. We're seeing this same practice used for Android based malware.

The malware portrays itself as a data file with an icon similar to that used by Microsoft Word documents and is entitled '资料' (Data). It runs with Administrative access and hence cannot be easily uninstalled. Once installed, the malware scans the device for SMS messages and other personally identifiable information such as the IMEI number, SIM card number, Device ID, victim's contact information,  etc. and sends this to the attacker via email.

Malicious APK posing as Microsoft Word File

Technical Details:
Once the malware is installed, it appears on the Android home screen as shown below:

Microsoft Word Icon

As soon as victim tries to start the app, it shows an explicit error stating "Installation errors, this software is not compatible with the phone" and the icon then disappears from the device screen.

Fake Error Message

When this error is being displayed, the app executes a few major functions as noted below:
  • Sends SMS messages to a hard-coded number.
  • Starts an Android service, named MyService.
  • Starts an asynchronous thread (SmsTask) which runs in background.
  • Starts another thread named MailTask, which also operates in background.
  • Calls phone numbers specified by Attacker.

Sends SMS
Initially malware tries to send the victim's device IMEI code in a message body to a hardcoded number.

Calling SendMsg function

Assets.getInstallFlag gets the IMEI (or ESN number in case of CDMA devices)

IMEI code fetching
And finally sends the message. 

Sending Message

MyService Service:
The main task performed by MyService is to collect all the SMS messages from inbox of the victim's device.  Once that is done, it stores all the messages in its local logs.

Service fetching inbox messages

SmsTask Thread:
Apart from logging SMS messages, MyService was not sending these messages anywhere. This functionality is exhibited in the SmsTask thread.

SmsTask will also read the SMS messages and exfiltrates them.

Fetching inbox messages

Once the messages are collected, the app then sends them to attacker via email.
Calling SendMail method

A username and password for an email id were found hard-coded in the malware.

SendMail functionality

MailTask Thread:
MailTask's main role is to collect contact information from the victim's device and send it to attacker via the same functionality explained in case of SmsTask.

SmsTask Thread

Sending Mail:
The app sets up an SMTP host on port 465 for sending email.

Sending Mail

localMimeMessage contains the necessary data to be sent to attacker via email. In the case of SmsTask as mentioned above, localMimeMessage's body contains an SMS message list and in the MailTask instance, it contains contact numbers from victim's device.

Calling Functionality:
The malware was also designed to call phone numbers provided by an attacker via SMS.
It has a broadcast receiver registered to trigger whenever a new SMS is delivered.
The malware reads the SMS received from the attacker and acts accordingly.

In one instance, malware was trying to fetch phone numbers received in SMS messages and then calling them, as shown in screenshot below:

Broadcast Receiver

We were able to confirm that the campaign was initiated on October 10, 2015 and almost 300+ users had fallen prey to this malware. The attacker was able to successfully retrieve message details and contact lists from the infected users.

The following screenshots shows the list of emails received by the attacker:


Further, each email titled "Message list" consists of full SMS conversations from the victims phones and email with subject "Contact list" contains a list of all the phone numbers fetched from victims contact diaries.

Messages from victim's device

Contacts from victim's phone
There were 300+ such emails found in the C&C admin panel. Such malware creates a significant privacy & financial risk as it obtains contact information and private SMS messages.

It is recommended that users download apps only from official Android stores like the Google Play store. If you are infected with malware, you can follow the steps mentioned in our previous blog for removing the malicious app.

Tuesday, October 27, 2015

Dridex activity continues

Dridex, a banking malware which attempts to steal the victim's banking credentials and system information, continues to remain active in the wild after the recent takedown attempt. Dridex activity went down significantly in September after the takedown operation but we started seeing an uptick in the number of samples in our sandboxes starting early October 2015.

Dridex is distributed via e-mail with a Microsoft Office attachment that leads to the download and installation of the Dridex Trojan executable. The e-mail attachments in these campaigns varied from regular Microsoft Office document files to MHTML files as seen in Figure 1.

Figure 1: Malicious document sent in MHTML format
MHTML, also known as MIME HTML, is a web page archive format used to combine in a single document the HTML code and its companion resources that are otherwise represented by external links (such as images, Flash animations, Java applets, and audio files). The malware authors are known to send the documents containing malicious macro in MHTML format to evade antivirus detection.

The content of the embedded macro was both obfuscated and protected using a basic password that is intended to prevent modification of the macros.  We were able to bypass the password protection and extract the various document components by standard means.

Figure 2 shows an example embedded malicious macro that downloads the Dridex executable from a predetermined server:

Figure 2: Embedded malicious macro to download Dridex
The samples we are seeing in these new campaigns are a mix of unsigned as well as some digitally signed using valid certificates. The format of the URLs hosting the signed Dridex samples changed to 195.37.231[.]2:8080/uniq/load[.]php instead of previously seen URL format 94.250.252[.]13/bt/bt/stata[.]php

The Dridex executable downloaded by above macro (Figure 2) appears to be packaged using a custom packer. This instance of the Dridex Trojan is signed using a certificate with the common name of “Favorite-III” which appears specific to the Dridex malware and which is currently also present in Comodo’s Certificate Revocation List.

Figure 3: Dridex Certificate issued with CN Favorite-III

We also saw following additional certificates used to sign the newer Dridex executables:
  • Promtorg
  • Brand IT 
  • AVTOZVIT Scientific Production Private Company
  • Afet
  • 3 AM CHP
  • Favorite-III
  • Private Person Parobii Yuri Romanovich
  • SWIFT Weather
  • AVTOZVIT Scientific Production Private Company
  • Private Person Parobii Yuri Romanovich
  • Favorite-III [NEW - seen in October 2015]
  • promtorg  [NEW - seen in October 2015]
The following are some recent URLs from which Dridex executables were downloaded:
The following are some MD5 sums of signed and unsigned Dridex executables that we have encountered in past month:





Following are the statistics of Dridex executable downloads that we have seen in past six weeks:

Figure 4: Dridex executable downloads in past six weeks

Figure 5: Dridex executable hosting servers


Dridex infections went down considerably after the global takedown operation but we are starting to see a steady increase in the infections this month, which indicates the malware gang's attempt at resurrecting this highly lucrative Botnet. The authors continue to use the tactic of digitally signed malware executable to evade detection with legitimate certificates created specifically for this purpose.

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

Research by Tarun Dewan and Nirmal Singh

Friday, October 16, 2015

Chinese Backdoor Zegost delivered via Hacking Team exploit


Zscaler ThreatLabZ has been closely monitoring the usage of Hacking Team's leaked exploits in the wild since July, 2015 and recently uncovered the Emissary Panda APT attack leveraging these exploits. In past two months, we've spotted multiple instances of Zegost Backdoor Trojan installation attempts leveraging Hacking Team's Adobe Flash exploit (CVE-2015-5119) payload. These attacks do not appear to be targeted, but the payload involved in the infection cycle has some resemblance to recent APT payloads from HttpBrowser & the PlugX RAT family.

Attack Chain

The infection cycle starts with a legitimate Chinese real estate and shopping site www[.]kongquechang[.]com, which appears to have been compromised by the attackers and contains an injected script. The injected script will cause a series of redirects leading to Hacking Team's exploit payload as seen in Figure 1. The majority of users were led to the original compromised site following a Baidu search.

Figure 1: Compromised Chinese real estate & shopping site
The site www[.]kongquecheng[.]com is still infected but the exploit server appears to be down at the time of writing this blog. Attackers are abusing the Chinese URL shortening service to redirect victims to the attack server and also Baidu's URL shortening service to deliver the Adobe Flash exploit payload as seen below:

Figure 2: Zegost Backdoor Attack Chain
The Flash exploit payload (CVE-2015-5119) involved here is from the Hacking Team's leaked archive with updated shellcode. Upon successful exploitation, the embedded shellcode will trigger the download and execution of the Zegost executable from a predetermined location.

Figure 3: Hacking Team's Adobe Flash Exploit

Figure 4: Embedded shellcode to download & install Zegost

Zegost Payload Iterations

During the course of our monitoring we observed the attackers switch the malware payload multiple times.

Payload Type #1 - APT RAT like Zegost Installer



The Zegost payload was being delivered as part of an installer archive, which is similar in structure to the APT RAT PlugX and HttpBrowser as detailed here. The downloaded installer was svhost.exe, which has following file structure:

Figure 5: APT RAT like Zegost installer archive
The Zegost installer is responsible for dropping the above three files and running the legitimate Ping_Master_Pro utility DATA.exe. The legitimate binary contains the data.dll in the import table, ensuring that the DLL will be loaded before it runs. The data.dll that gets loaded in this case, will be a fake VirtualBox display driver DLL file present in the same directory and it will patch the entry point of the main executable (DATA.exe) file with a jump instruction to run the DLL’s code instead. This technique is also known as DLL Hijacking which ensures that the fake display driver DLL gets loaded by abusing the Windows DLL load order. The DLL’s code is responsible for decrypting and running the Zegost Backdoor payload from the fafentuqiang.png file in the same memory space of the benign executable.

We observed a bug in the persistence module for this payload, which resulted in an incorrect path getting added to the registry entry created by the malware. The result was that upon system reboot the user's machine will no longer be infected with the Backdoor Trojan.

Payload Type #2 - Vanilla Zegost



A modified Zegost payload was being delivered in decrypted form abandoning the installer archive structure. This payload was recently compiled and purports to be a XLLuaRuntime Dynamic Link Library file as seen below:

Figure 6: Recently compiled Zegost payload

Figure 7: Zegost payload file meta data
During our analysis we noticed that the persistence issue that existed in the previous iteration was resolved in this payload and the malware successfully remained active upon system reboot.

Zegost Infection Cycle

  • Zegost Trojan drops a copy of itself in the Windows system directory as %SYSTEMDIR%\Autoexec.exe
  • It creates the following registry key to ensure persistence upon system reboot:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\ Nobug = %SYSTEMDIR%\Autoexec.exe
  • We also saw an alternate code for achieving persistence by registering a new Windows Service:
ServiceName - DirectX dwx
DisplayName - DirectX Remover auy for Windows(R).
ImagePath - %SYSTEMDIR%\Autoexec.exe
  • The Trojan reports the infected system information to a predetermined remote server at the following location:
Domain - www[.]svshot[.]com
Server IP - 123.57.54[.]57
Server Port - 8999
  • The Command & Control server domain used in this attack was recently registered and points to a dedicated server hosted on the shady Chinese autonomous system - AS37963 (CNNIC-ALIBABA-CN-NET-AP) as seen below:
Figure 8: Command & Control server hosted in China
The same server is also used for the initial Adobe Flash exploitation attempt.


Hacking Team's exploit payloads remain a popular choice among cyber criminals for weaponizing their payloads. This is the first instance of the Zegost Backdoor Trojan being delivered using Hacking Team's exploit. The Zegost Backdoor payload iterations we observed in this attack chain indicates that the author is testing out new payloads.

Zscaler’s ThreatLabZ has confirmed coverage for these exploits and for the Zegost variants, ensuring protection for organizations using Zscaler’s Internet security platform.

Research by: Deepen Desai, Amandeep Kumar