The story of a Trojan Dropper I

Introduction:

Recently, Zscaler ThreatlabZ  received a suspicious file from one of our customers, which 

was named “OrderDetails.zip”. After extracting the executable file from the archive I have 
performed a virustotal scan  to get some information about the file. At that time, very 
few antivirus vendors had definitions in place, which flagged the file as malicious.

As such, I decided to take look at the file in greater detail. After completing the analysis,
I've  decided to blog about the threat. Given the amount of information derived during the analysis, I've decided to divide the blog into multiple parts.

Figure 1:  virus total results

Modern day malware generally implements some kind of packing or obfuscation on the binary, in order to evade antivirus detection. Hence, it’s a good idea to determine which packer may have been used while analyzing the file. In order to do this, I implemented a popular tool called PEiD to check for the existence of a known packer.

Figure 2:  PEiD results

As we can see above, PEiD was not able to pick up anything from this file, but that doesn't mean that the file is not packed. Let’s have a closer look at the file.

While going through the file sections, one of the sections (.data) contained an unusually large amount of data, which at first glance gave the impression that it is obfuscated. This is an important clue and something we have to keep in mind while debugging the file.

Figure 3:  obfuscated data

While looking at the resource section, we can see that the file icon resembles that of a PDF file, which adds to our suspicion. Also, the file is not digitally signed.

Figure 4: File icon at resource section

Lets go further and execute the file. When doing so, I was greeted with a crash report where Windows was telling me that “Adobe.exe” had crashed during execution.

Figure 5:  windows error report 

We knew from the beginning that this was not a proper PDF file and would not therefore work with Adobe Reader. Let’s now look to determine where Adobe.exe exists in the file system. A 
Windows file search reveals Adobe.exe inside the temp folder, which when executed, produces exactly the same result as was shown above 

Figure 6: dropped file named adobe.exe

At the same time, a Wireshark capture was not able to output anything that was of interest.At this point we have adequate evidence to proceed with additional debugging, which i will explain in detail in the 2nd part of this blog post. The story of a Trojan dropper II

Figure 7: wireshark packet capture

The story of a Trojan Dropper II

Analysis:

Lets analyze the PE file in detail and see what it’s up to. Like most malware, this sample was packed and in order to properly analyze it, we must begin by unpacking the binary. Keeping this in mind, I began by debugging the file, hoping to find the reference to the data section in order to determine precisely where the encrypted portion of data was to be found.

Fortunately, I was not disappointed and was soon able to find the reference point.

Figure 1: Obfuscated data 

After further debugging, we are able to see the code decrypted in memory. The decryption occurs in multiple iterations, until the data is completely decrypted.

Figure 2: Decryption of obfuscated data

Now we have a full view of the decrypted code in memory. The portion that was decrypted contains position independent code (i.e shellcode).

Figure 3: Decrypted data in memory

Since the code is decrypted in memory, we can assume that at some point, control will be transferred to that region, which in this case happens immediately. We also can see that the VirtualProtectEx API is used to change the protection of the memory region and by doing so the malware will be able to execute and manipulate the memory.

Figure 4: Change memory protection

After this occurs, control is transferred to the region by an instruction of JMP EDI. Here, EDI will hold the address to which EIP (instruction pointer) lands and we can see that it is the same portion of the 

code that was decrypted earlier.

Figure 5: Control transferred to new code

There's an interesting bit of code here if we look at first couple of instructions on the landed region. We can see a NOP instruction, followed by SUB EAX,EAX and a CALL and POP EBX. If we carefully observe the address that is called, it is that of the POP EBX. This is a common technique found in shellcode and file infectors where one needs to get the address of the region that is currently being executed.

When this CALL is executed, it pushes the return address onto the stack (in this case it is the address of POP EBX). Now POP EBX is executed, as that instruction pops the value from the top of the stack to EBX. The address is then added to a constant of 0x33, to point to the region that is then decrypted by the decryption loop. This reveals more code, after which a JMP instruction transfers the control to the newly revealed code.

Further, I was able to identify another interesting piece of code here. The code below retrieves the address of the PEB (process environment block) and navigates to PEB_LDR_DATA->InLoadOrderModuleList, where it retrieves the names of the loaded modules (DLL’s) .

Figure 6: Fetch base address of kernel32.dll

There's another catch here. The malware looks for specific DLL’s (in this case kernel32.dll), but instead of using the string kernel32.dll to compare with retrieved module names from the PEB, it carries the hash of the DLL names and then calculates the hash value for the retrieved module names and compares them. This allows the malware to make minimum noise and avoid some antivirus rules.

Figure 7: Dll name hash 

Once the malware gets kernel32.dll, it then retrieves the base address of the kernel32.dll, which in this case is 0x7c800000. Now, using the PE file format, the malware moves to the export table of kernel32.dll, as illustrated in the code below,

Figure 8:  Finding exportaddresstable of kernel32.dll

Looking at code above the instruction MOV EBX, DWORD PTR DS:[EAX+78], lands us at the datadirectory-->exportaddresstable of the kernel32.dll. The malware then retrieves the value and adds it to the imagebase (ie 0x7c800000) in order to reach the export table, where it retrieves the address of the exported function. Here too, the malware never uses the names of the function, but instead it uses a stored hash.

After further analysis, we stumble onto another piece of code, which copies data again from the data section to a newly allocated memory region.

Figure 9: Copy more data 

Investigating further, we see that this data is decrypted to reveal what looks like some sort of an address table.

Figure 10: Address table 

The table has significance as it is used as an address calculator, To calculate the address of

the region from where it copies bulk data, Which is further decrypted to form what looks like

a compressed file.

Figure 11: Compressed data

And there it is. Moving ahead, we land in the decompression routine, which quickly reveals that

the data is compressed using “aplib”.

Figure 12: Aplib decompression routine

Once the decompression is completed it does some familiar actions by flushing out the bytes of the original EXE file starting from the imagebase 0x400000 and copy the decompressed data to its new imagebase (i.e 0x400000)

Figure 13: Copy decompressed PE -file 

Finally using “LoadlibraryEx” and Getprocaddress the IAT is rebuild in the memory after which the control is transferred to the new code at the address 0x401021

Figure14: Rebuild IAT in memory

The job of this code is limited. It writes a PE-file which is embedded within itself into the temporary folder as “Adobe.exe” using the api “GetTempPathA”.

Figure 15: Transfer control to OEP

In the end, the file (Adobe.exe) is dropped in the temp folder and executed using the API “ShellExecuteA”.

Figure 16: Execute dropped "Adobe.exe"

A dummy PDF file is also written to the current directory named “Bestellung.pdf”. In a subsequent blog post, we will see why the malware dropped this PDF file.

That’s all for now. In the next post, we’ll continue the analysis of the dropped file “Adobe.exe”

Infection found on ‘feedburner.com’

Recently, we have seen the websites of MySQL and PHP.net being compromised. We have also blogged about Google Code being used as a drop site for holding malicious code.  These instances clearly suggest that attackers are targeting popular websites and using them in their attacks as they are less likely to be blocked by URL filters. This time we found that Google acquired ‘FeedBurner’, which provides custom RSS feeds and management tools to users is hosting an infected page. We found that one of the pages on the sub-domain ‘feeds.feedburner.com’ is serving malicious JavaScript.  The JavaScript is obfuscated and contains an iFrame, which after execution, redirects the user to a malicious website. More information about this particular attack can be found in McAfee's description of threat JS/Exploit-Blacole.em.

Let’s look at the infection in detail.

URL: hxxp://feeds.feedburner.com/bileblog

The following shows the redirection trace when visiting the aforementioned URL.

Network Trace:  

The redirection chain above case is as follows:
hxxp://feeds.feedburner.com/bileblog (Drops JavaScript Trojan)
--> hxxp://rsnvlbgcba.ibiz.cc/d/404.php?go=1  (Intermediate Redirection)
--> hxxp://fukbb.com/

Let’s take a look at a beautified version of the obfuscated JavaScript Trojan code which is dropped:

JavaScript Trojan code generally contains two main sections. The first is the decoder routine (i.e JavaScript code which decodes the embedded payload) and the second is the payload itself. Generally attackers keep on tweaking the decoder routine and payload to evade security vendors.

The de-obfuscated version of the code above can be seen here:

The de-obfuscated code loads an iFrame into the victim’s browser, which is redirecting the user to ‘hxxp://rsnvlbgcba.ibiz.cc/d/404.php?go=1’, which in turn redirects it to ‘hxxp://fukbb.com/’.

The source code hosted at ‘hxxp://rsnvlbgcba.ibiz.cc/d/404.php?go=1’ is a simple redirect:

   

 Final re-directed page:

Currently, ‘hxxp://fukbb.com’ is not serving any malicious code but the reputation of this site is found to be suspicious (Refer the VT link below). The page could however be revived at some point in the future. ThreatLabZ informed FeedBurner about this infection on 12/26/2013.

VT Reports:
File scan for JavaScript Trojan code: 24/49
URL scan on ‘hxxp://rsnvlbgcba.ibiz.cc/d/404.php?go=1’ :  2/51
URL scan on ‘hxxp://fukbb.com/’ :  3/51

ZULU Report:
URL Scan on ‘hxxp://feeds.feedburner.com/bileblog’: 100/100

Similar instances of this infection have been found on ‘http://celebrityshowdown.net/?feed=rss2’, which is also an RSS feed management site. The following is the network trace seen when visiting this URL.

The redirection chain observed in this case is as follows:
hxxp://celebrityshowdown.net/?feed=rss2    
--> hxxp://rhtbjgw.ibiz.cc/?go=2
--> hxxp://fukbb.com/

For a detailed report about this infections check the urlQueryreport.

We continue to see similar infections using malicious JavaScript injected into legitimate sites to redirect users to malicious sites on a daily basis. Most of the time the infected sites haven’t specifically been targeted, but have become infected during larger attacks conducted using browser exploit kits designed to automate the infection of as many sites as possible. We advise our readers to use online URL scanning tools such as ZULU to perform scans on URLs when suspicious, regardless of a site’s perceived reputation.

- pradeep

Analysis of ATN Live TV iOS App using ZAP

“As the Mobile Industry is moving so fast, so too do security and Privacy issues”

There has been rapid growth in the prevalence of mobile devices in last few years. Every day a new device is being launched and hence increasing the number of online transactions. BYOD (Bring Your Own Device) has further complicated the security challenges of enterprises as they’re now responsible for protecting data on devices that they don’t own. At the same time, mobile application developers are coding new apps every day, without focusing on security/privacy related issues.

In this Post we will focus on analyzing the ATN Live TV App for iOS using our own free service ZAP (Zscaler Application Profiler). If you aren’t familiar with ZAP, it’s a simple web application which allows anyone to quickly analyze the security/privacy issues of any iOS or Android app by dynamically inspecting the web traffic generated by the app. Please have a look at our previous blog post or video for more information.

Let’s begin.

App Name: ATN Live TV

App Store link: https://itunes.apple.com/in/app/atn-live-tv/id525948724?mt=8

Category: Entertainment

You will need to provide the APP URL and some fake credential to ZAP in order to analyze the traffic for security/privacy leaks.

Once you are done with this, you’ll need to set the proxy setting on your device to point to ZAP. Hit the Proxy Scan button and follow the instructions for setting the proxy on your particular device.

In this analysis, we found that ATN Live TV is leaking passwords and Email IDs.

As you can see, the Email ID and the MD5 hashed password is being transferred to the server via GET request using HTTP. While the password is hashed via MD5, you can see that the data is not transmitted in an encrypted (HTTPS) channel. While MD5 is a one-way hash, an attacker that was able to sniff this traffic, could perform a dictionary attack to retrieve the clear text password.

Here is the Final Risk Score Report of ATN Live TV app from ZAP.

 

Conclusion

With the explosion of mobile app development, we’re seeing an increase in data and privacy leaks. This is occurring for the same reason that we saw so many web application vulnerabilities a decade ago – there are many new developers entering the space but few have access to the tools and knowledge necessary to develop secure apps and apps are often published without an independent security audit.

These issues were reported to the developer on 20/12/2013.

Aurora exploit still floating ...

It's been around two years since Microsoft released a patch for the IE 0day famously known as the Aurora exploit (CVE-2010-0249). We had blogged about this in the past when it was first seen in the wild on the 'GOV.CN' domain. This vulnerability targets IE version 6. Despite the passage of time, we continue to find live exploits for this vulnerability. Recently, we found a new URL which is serving the Aurora exploit code.

Exploit URL: hxxp://www.artbridal.com/bizcodi/gm/news.html

Let's take a look at the exploit code being delivered.

 

The exploit is delivered via obfuscated JavaScript code, although the level of obfuscation is not very high. Some of the strings and JavaScript function names are been obfuscated. The following is a snapshot of the de-obfuscated code.

If you observe the first image, the SPAN tag holds an IMG tag on which the 'onload' event calls an event handler  function 'eve'. This in turn creates an event object called 'e1', using the 'document.createEventObject' method. Then, by using an '.innerHTML' property, it assigns a null string to SPAN object 'sp1', but instead, the 'sp1' object is removed. In the function 'eve', the freed object is referenced, causing memory corruption in the form of an access violation in IE. To exploit this condition, the exploit code uses a typical heap spray technique to load the shellcode into memory for the execution. When the shellcode is executed, it tries to download a malicious file from the URL 'hxxp://fly-tld.ru/w.php?f=47&e=3'.  For a more detailed analysis, you can refer to this blog.

To obtain the aforementioned URL, the PE executable file was formed and extracted from the shell code in the exploit. The EXE was then examined using a debugger to extract the URL as can be seen below.

This URL is down at the moment, so further post exploitation analysis was not possible.

Reports:

VT URL Scan on found URL : 4/51 detections.

VT File Scan on EXE formed from Shellcode: 27/41 detections.

Various other URLs that have been seen in the past with similar patterns - '/w.php?f=(\d){2}&e=(\d){1,2}' include:

hxxp://synergyledlighting.net/w.php?f=56&e=4
hxxp://nicesextubes.co/w.php?f=18&e=6 
hxxp://iplaecrcocee.com/w.php?f=26&e=2
hxxp://iplaecrcocee.com/w.php?f=26&e=2
hxxp://examine.arsb.co.uk/w.php?f=20&e=2
hxxp://exciting.simssocialcheat.com/w.php?f=22&e=2
hxxp://oyacromifh.com/w.php?f=26&e=2
hxxp://eteaescopr.com/w.php?f=26&e=2

The obvious reason behind attacking old CVE's is the belief of attackers, that there are still un-patched and outdated browser's out there on end user machines. Sadly, they're correct. To avoid such attacks we suggest updating browsers with latest patches and migrating to the most recent version of the browser. 

Stay updated, Stay Safe!

Pradeep

Dissection of Android malware MouaBad.P

In Zscaler’s daily scanning for mobile malware, we came across a sample of Android Mouabad.p. Lets see what is inside.

Application static info:

 Package name = com.android.service

Version name = 1.00.11

SDK   version: 7

Size: 40 kb

Permissions:

• android.permission.INTERNET
• android.permission.ACCESS_NETWORK_STATE
• android.permission.READ_PHONE_STATE
• android.permission.SET_WALLPAPER
• android.permission.WRITE_EXTERNAL_STORAGE
• android.permission.MOUNT_UNMOUNT_FILESYSTEMS
• android.permission.RECEIVE_SMS
• android.permission.SEND_SMS
• android.permission.RECEIVE_WAP_PUSH
• android.permission.READ_PHONE_STATE
• android.permission.WRITE_APN_SETTINGS
• android.permission.RECEIVE_BOOT_COMPLETED
• android.permission.WAKE_LOCK
• android.permission.DEVICE_POWER
• android.permission.SEND_SMS
•  android.permission.WRITE_APN_SETTINGS
•  android.permission.CHANGE_NETWORK_STATE
•  android.permission.READ_SMS
•  android.permission.READ_CONTACTS
•  android.permission.WRITE_CONTACTS
•  android.permission.CALL_PHONE
•  android.permission.INTERNE
•  android.permission.MODIFY_PHONE_STATE

Used features:

• android.hardware.telephony
• android.hardware.touchscreen

Services:

• com.android.service.MessagingService
• com.android.service.ListenService

Receivers:

•  com.android.receiver.PlugScreenRecevier
•  com.android.receiver.PlugLockRecevier
•  com.android.receiver.BootReceiver
• com.android.receiver.ScreenReceiver

Virustotal scan:

https://www.virustotal.com/en/file/1b47265eab3752a7d64a64f570e166a2114e41f559fa468547e6fa917cf64256/analysis/

Now Lets dissect the code.

This application is using telephony services as shown in the code as well as in static analysis. You can see the use of premium telephone numbers.

In this particular screenshot, you can see functions which are using phone services for making calls to the premium numbers in order to generate revenue as the numbers would be controlled by the attackers and earn a small payment for each call made.

Here you can see that the application is harvesting SIM card information.

This application also checks for mobile data and the WIFI network status to determine if Internet connectivity is available.

The code includes a hardcoded list of premium telephone numbers, which are all located in China.

                     

In this screenshot you can clearly see that application also keeps watch on the screen and keyguard status (on/off).

This screenshot clearly denotes that the application tries to send SMS to the premium rate numbers previously seen in the code. Forcing Android applications to initiate calls to premium phone numbers controlled by the attackers is a common revenue generation scheme that we see, particularly in Android application distributed in third party Android app stores.

Here you can see various function names which are suspicious such as call, dial, disableDataConnectivity, get call location, etc. These functions suggest that the application is also trying to keep watch on other phone calls too. Function getCallstate, endCall, Call, CancleMissedCallNotification Illustrates that the application tries to control phone call services.

The application installs itself silently. Once installed, no icon is observed for this app. Also shown in the previous screenshot is the fact that the application waits for the screen and keyguard events before triggering its malicious activity. It does all of the activity without user intervention. This allows the malware to function without a suspicious icon on the home screen that just one of  technique used by malware authors to evade its presence to the device owner.

From above screenshots, you can see that the application is using the XML listener service.  Also, in the second screenshot, you can see that the application is trying to create a URL by assembling various strings. This is likely command and control (C&C) communication sent to a master server. The parameter &imei denotes the harvesting of the phone's IMEI number for tracking the device.

In conclusion, this malware will defraud the victim by silently forcing the phone to initiate premium rate SMS billing to generate revenue. The application may give control to the author for monitoring or controlling phone calls.

Reference:

https://blog.lookout.com/blog/2013/12/09/mouabad-p-pocket-dialing-for-profit/

Dissection of Zertsecurity - Banking Trojan.

Zertsecurity is a well known banking Trojan based on phishing schemes targeting German Android users.  Lets see how it works.

After installing the application, it prompts the user for account and PIN numbers.

The application takes the values of the account and PIN numbers via input boxes and saves them to the cfg.txt file. It then sends this file to a remote command and control (C&C) server master.

You can see the hardcoded C&C server in the application.

Also here you can see that the application is also asking for SMS receive permissions. It receives SMS messages from it's C&C server for commands to perform malicious activities. It also checks for the string “&Sign28tepXXX” in order to identify commands from the C&C server.

Here you can see that the application is using AES and BASE64 encoding techniques for encryption.

In this screenshot you can see the C&C messages being assembled.

Zertsecurity is a simple banking Trojan which was constructed for targeting phishing attacks against German Android users. It prompts for an account number and PIN, stores them in the cfg.txt file after encrypting the information using AES and base64 encoding algorithms. It also receives SMS from a hard coded C&C server for additional instructions.

References:

https://blog.lookout.com/blog/2013/05/06/zertsecurity/

http://www.symantec.com/security_response/writeup.jsp?docid=2013-050820-4100-99