Thursday, June 14, 2012

Digging Inside Tinba Malware - A Walkthrough


Two weeks back, Tinba malware hit the internet. Though our team spent some time in looking at the various artifacts of Tinba malware. Zeus and SpyEye have given birth to new breed of botnets. The upcoming generation of botnets are extensively utilizing the tactics introduced by Zeus and SpyEye. Tinba is a small notorious malware that aimed specifically for stealing information from the browsers. For more details about Man-in-the-Browser (MitB), one can read our paper on FormGrabbing here - http://www.virusbtn.com/virusbulletin/archive/2011/11/vb201111-form-grabbing.

Other researchers have presented details about Tinba which can be found here - http://www.csis.dk/en/csis/news/3566/

We looked specifically at communication patterns of Tinba. As we know, bots are hooking browsers and performing Web Injects to gain control over the browser communication channel. Other interesting facts about Tinba is as follows:

  • The accompanied binary is written in MASM/TASM and having size of 20 KB. Compiling with MASM reduces the size of the binary to great extent.
  • The binary executes as : tinba.exe --- bin.exe --- readme.exe --- winver.exe The dropper actually installs the bin.exe file in the application directory and then deletes the wrapper (binary). File bin.exe resides in the directory permanently.
  • Adds run entry here - HKCU\Software\Microsoft\Window\CurrentVersion\Run
  • Tinba hooks browser processes and make them unstable, so there is a possibility that users might encounter several crashes in browsers while running or surfing internet. The browser works   fine when the system is rebooted.
  • As the tinba injects in explorer.exe, the binding occurs very fast when bot has to send SYN packet and to receive reply from the C&C server. The connection is continuous but TCPView is not fruitful in this case because the connection open and closes readily. TDIMon tools gives you the low level traffic details by inspecting the Transport Driver Interface as presented below:
explorer.exe:168    TDI_CONNECT    TCP:0.0.0.0:2552    82.165.37.127:80    SUCCESS       
explorer.exe:168    TDI_SEND    TCP:0.0.0.0:2552    82.165.37.127:80    SUCCESS-2941    Length:353    
explorer.exe:168    TDI_SEND    TCP:0.0.0.0:2552    82.165.37.127:80    SUCCESS-2942    Length:9    
explorer.exe:168    TDI_EVENT_CHAINED_RECEIVE    TCP:0.0.0.0:2552    82.165.37.127:80    SUCCESS       
explorer.exe:168    TDI_EVENT_DISCONNECT    TCP:0.0.0.0:2552    82.165.37.127:80    SUCCESS    RELEASE
explorer.exe:168    TDI_SEND    TCP:0.0.0.0:2545    82.165.37.127:80    SUCCESS    Length:353    
explorer.exe:168    TDI_SEND    TCP:0.0.0.0:2545    82.165.37.127:80    SUCCESS    Length:9    
explorer.exe:168    TDI_EVENT_RECEIVE    TCP:0.0.0.0:2545    82.165.37.127:80    SUCCESS        
explorer.exe:168    TDI_EVENT_DISCONNECT    TCP:0.0.0.0:2545    82.165.37.127:80    SUCCESS    RELEASE    

   
One can notice that the events are happening very fast. The below presented figure shows the TCP/IP pattern in injected explorer.exe process.

Tinba Hooking Explorer - TCP/IP Pattern

When forms are submitted over HTTP/HTTPS, the Firefox raises an alert box for notifying user about communication protocol in use. Internet explorer uses the concept of Zones. So we looked at this pattern in Tinba. No doubt for Internet Explorer, Tinba modifies the registry entry to disable configuration of Zones.as follows:

\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3

Tinba also manipulates the Firefox behavior by tampering user.js (preferences) file as follows

[C] user_pref("security.warn_submit_insecure",false);
Browser does not raise an alert box when information in sent over HTTP while submitting forms.

[C]
user_pref("security.warn_viewing_mixed",false);
Remove the warning of supporting mixed content over SSL.


The aim behind this modification is to remove the ambiguity in the communication channel used by Tinba. Let's have a look at the traffic communication:


Tinba Sending POST Requests
Tinba Sending GET Requests
Encrypted Reply
The communication is encrypted and well managed in this case. Another interesting thing we noticed during analysis is that, when you reboot your infected system with Tinba, it raises windows integrity check which shows that Tinba has seriously altered the integrity of system32 files such as winver.exe


Window Integrity Check on System Infected with Tinba on Every Reboot
This adds some more information on the Tinba malware.

Some more next time !

Wednesday, June 13, 2012

LinkedIn Phishing Attack - Dissecting Attack and Used Exploit

Recently, after the successful intrusion of linked-in network by attackers, phishers also started exploiting the trust of users by sending phishing emails with embedded malicious links. The linked-in is on bit roll nowadays by attackers but it is always good to analyze the phishing attack. Our team received the phished linked-in emails. Of-course if you are in malware analysis field you are always targeted one or the other way. It happens. Let's discuss the exploit in action in this phishing attack. The users receive following email as presented in the figure below:


The users who received this email are presented below:


The malicious links accompanied with this email are presented as:

The phished email is embedded with more than 2 malicious links.The index.html retrieves 2 JS files from two different domains as presented below


 
On successfully loading of JS files, the webpage redirects to the target pointed by document.location call. The target URL is actually NGINX reverse proxy which communicates back with blacklisted IP serving malware. The attacker is almost using 3-4 hops to retrieve the malicious content. On detecting the hosts, we found that some of the links are now down or giving forbidden access. However, the targets can be accessed by querying directly with the IP address of the host and not the DNS. The exploit used during this campaign might vary with time but we encountered the script that triggered flash/adobe exploit that uses JavaScript heap spraying. The obfuscated script used in this case is bit complex but not a hard target to deobfuscate. The obfuscated script (redacted) looks like as presented below


The script is too big to paste here. So you can find it here - http://pastebin.com/MSpCtZH7
There are several tricks you can use to deobfuscate it, one of the methodology is discussed in our previous blog post on JavaScript Obfuscation -  http://secniche.blogspot.com/2012/04/javascript-obfuscation-manual-armor-1.html.

The deobfuscated script is available here - http://pastebin.com/yDjQRD0u. Some of the interesting code has been shown below, the rest you can scratch on the pastebin.

On successful, deobfuscation, we observed that

1. The script is fingerprinting plugins, OS, User-agent and other information
2. The malicious domain is running BlackHole BEP.
3. We accessed certain set of files on the domain, one of which is shown below


So, the BlackHole is still on fire but attackers now using modular way  of serving exploit. There are other interesting information that we found during analysis but not presenting here. If something more interesting comes up, we will update it here.

Hot to be secure?

1. Update plugins to the latest version.
2. Think twice before your click.

Be secure !


Tuesday, June 12, 2012

For Fun - XSS in ICE IX C&C Panel

Our team is working on ICE IX botnet analysis. We will be releasing a detailed paper about the working of ICE bot in coming time (very soon). However, this post is meant for some fun purposes but the provided information can be used to complete different tasks. We have detected an interesting XSS in main login page of ICE botnet C&C panel. It does not require any authentication as such though. The POC is presented in figure below


 So what exactly you have to do is to hack the below XML construct in order to trigger it
.

The interesting part is to understand the entry point in this as discussed.

Consider this, /adm/index.php?m=login , so usually "m" parameter in this URI is considered as an entry point which is true in certain sense. However, for this XSS, the entry point is present in /adm/index.php/ [Injection Point] ?m=login.

So, the point is, XSS finds its own entry points. :)

Browser Security Talk:
On additional note, the above presented screenshot shows that payload is sent in URL and Google Chrome parses it and then the payload becomes persistent. Seems like a bypass, yes it is. It depends whether Google Chrome team considers it or not.  IE and NoScript triggers an alert.

Enjoy !

Friday, June 8, 2012