Thursday, September 3, 2015

Shifu: A new interesting Banking Trojan

Hello everybody, today I'd like to share some infos on "Shifu" a new incredibly interesting banking trojan. At this point you might think:
"Why are you writing about Shifu among many other new threats (even more discussed)  out there ? "
Well... Shifu is a new banking trojan which actually attacks Japanese banks mostly,  it's actually well geo-localized and probably it will end up on a specific amount of organizations, but what fascinates me is the way it implements many features by copying what have done so far some of the "best in class" known Malware. Shifu implements the following features:
  • Domain Generation Algorithm (DGA): Shifu uses the Shiz Trojan’s DGA. The exposed algorithm itself is easy to find online, and the developers behind Shifu have elected to use it for the generation of random domain names for covert botnet communications. 
  • Theft From Bank Apps: Theft of passwords, authentication token files, user certificate keys and sensitive data from Java applets is one of Shifu’s principal mechanisms. This type of modus operandi is familiar from Corcow’s and Shiz’s codes. Both Trojans used these mechanisms to target the banking applications of Russia- and Ukraine-based banks. Shifu, too, targets Russian banks as part of its target list in addition to Japanese banks.
  •  Anti-Sec: Shifu’s string obfuscation and anti-research techniques were taken from Zeus VM (in its Chtonik/Maple variation), including anti-VM and the disabling of security tools and sandboxes. 
  • Stealth: Part of Shifu’s stealth techniques are unique to the Gozi/ISFB Trojan, and Shifu uses Gozi’s exact same command execution scheme to hide itself in the Windows file system.
  • Config: The Shifu Trojan is operated with a configuration file written in XML format — not a common format for Trojans, and similar to the Dridex Trojan’s configuration (Dridex is a Bugat offspring). 
  • Wipe System Restore: Shifu wipes the local System Restore point on infected machines in a similar way to the Conficker worm, which was popular in 2009. 
  • Commuication protocol: Shifu implements an SSL communication layer based on a Self-signed certificate. The implemented module reminds analysts to the one used on Dyre Trojan campains in Late 2015.
Another interesting feature is about Point Of Sales. To make matters worse, Shifu searches for specific POS memory strings (and processes). If it finds a POS trace it starts a "stealing credit card numbers" procedure.

Last but not least Shifu makes sure none else will own the attacked system. Once it gets installed on the victim machine is starts an "AV" procedure (forgive me, is not actually an AV procedure, but it makes the idea) which locates "suspicious" files and  denies their installation. According to IBM Security Intelligence's report (here) the Malware is likely developed by a Russian group.

Let's get dirty hands on it performing basics Reverse Engineering actions to see what are the real countermeasures it adopts.  From the IBM Report (linked abouve) you may find the Malware signature (NmE5ZDRhMzIzOTg3NDg5YzhlOGI1NTc2ZjY3YjJjOTQ) which can be used into common online SandBox systems to look for samples. As you might observe the sample I've got implemets some anti-debugging techniques as well as some basic SandBox evasion techniques (for more information please have a look to malwarestats):

GetLastError, IsDebuggerPresent, GetVolumeInformations, etc..
 An interesting sequences of API calls were found: GetProcessAddress  (Retrieve the address of of an exported function or variable from the specified dynamic-link library) -- VirtualProtect (stack) (Changes the protection on a region of committed pages in the virtual address space of the calling process.) -- VirtualAlloc (Reserves, commits, or changes the state of a region of pages in the virtual address space of the calling process. Memory allocated by this function is automatically initialized to zero.) -- Sleep (Suspends the execution of the current thread until the time-out interval elapses.) -- VirtualAlloc -- 

Another interesting pattern found during the simple static analysis performed phase (showed on the following image) is the dynamically loaded Library pattern (previous downloaded).  As you may observe on row 2861 the system points out to a specific location and call LoadLibraryA to load it into memory.

Dynamically Loaded DLL
Dynamic Analysis clearly shows Sample's RAT features by spawning a shell (on my machine PID: 1388 within Parent PID: 788 owning to the executed Sample ) and executing commands. Unfortunately the evasion techniques detected the SandBox execution. The following image shows the check of Python presence, which often is one of the detection mechanisms (How many common users have Python on their Windows Machines ? Not much, really).

Python Detection

After a simple de-obfuscation round (Visual C Packer was detected) the analyst could appreciate the command line parser. Probably the one used to communicate through Command and Control (not much further analysis has been performed)

Command Line Parser
Network wise the sample embeds the following addresses:
  • ( Noisy maker
  • ( Much more interesting because geolocalized in China and the domain has changed at least two servers during the last year.
A simple nmap scan on it shows up-and-running a nginx server on both ports 80 and 443, used to comunicate to Malware and a ssh daemon active on standard port and and an interesting port 53 TCP opened. Statically analized behaviour presents the following TimeLine (click on it to enlarge):

Behaviour Time Line
Not really a significant one but the cmd.exe spawned feels like an hero. Concluding my post I wanted to impress on my pages this significant piece of Malware which embeds many different techniques borrowed from many older Malware underlining a new Malware writers skill sets, able to make harder and harder piece of code as their wish (just by adding feature from different Malwares).

No comments: