Blog

Overview

Shifu is a Banking Trojan first discovered in 2015. Shifu is based on the Shiz source code which incorporated techniques used by Zeus. Attackers use Shifu to steal credentials for online banking websites around the world, starting in Russia but later including the UK, Italy, and others.

Palo Alto Networks Unit 42 research has found that the Shifu authors have evolved Shifu in 2016. Our research has found that Shifu has incorporated multiple new techniques to infect and evade detection on Microsoft Windows systems. Some of these include:

• Exploitation of CVE-2016-0167 a Microsoft Windows Privilege Escalation vulnerability to gain SYSTEM level privileges. Earlier versions of Shifu exploited CVE-2015-0003 to achieve the same goal
• Use of a Windows atom to identify if the host is already infected with Shifu in addition to the mutex used by previous versions
• Use of “push-calc-ret” API obfuscation to hide function calls from malware analysts
• Use of alternative Namecoin .bit domains

We have also identified new links between Shifu and other tools which suggest Shifu isn’t simply based on the Shiz Trojan, but is probably the latest evolution of Shiz.

The primary goal of this report is to introduce Shifu’s new features to other malware analysts who may encounter this Trojan in the future. The following sections give an overview of the new features, and the appendix at the end includes the technical details on the overall functionality of Shifu.

New Developments and Features in Shifu

The Shifu version discussed in this analysis is comprised of several stages of payloads and was compiled in June 2016. The following image illustrates the different files included in the initial loader which get decrypted after execution:

Figure 1. File structure of Shifu

The initial obfuscated loader (x86 exe) contains the encrypted second stage injector (x86 exe). It uses three layers for decryption by subsequently allocating memory via VirtualAlloc() for the next layer. The second stage injector gets decrypted into memory and the original loader process is then overwritten with it. Next, the section flags are adjusted and the IAT addresses are resolved. The final decryption layer then jumps to the entry point of the second stage injector.

The second stage injector contains two exploits for CVE-2016-0167 (x86/x64) that have a compilation time stamp dated February, 2016. At the time of compilation, patches were not yet available for this vulnerability. However, the malware’s compilation time stamp dates June 2016. This may indicate the people behind this Shifu version had access to the zero-day exploit at that time or gained access to it afterwards. The exploit uses an interesting technique which makes it possible to just copy the raw disk file into memory. To make the file executable in memory, it uses a custom PE loader shellcode appended to both versions of the exploit as an PE overlay. The shellcode takes care of all the adjustments needed to get a proper executable memory image and executes the exploit. By doing so, the file just needs to be copied into a memory buffer and execution needs to be passed to the shellcode.

We have also found multiple other variants of the exploit, standalone versions (x86/64), but also versions which are embedded in an injector like in Shifu. Additionally, we identified a version of Vawtrak which contains an earlier version of the exploit dating back to November 2015, according to the compilation time stamp. The compilation time stamp of this Vawtrak sample itself dates January 2016 and thus is effectively the first malware known to us to use this exploit.

The second stage injector contains several anti-analysis tricks similar to the previous version. It also contains two command line parameters with functionality that indicate the malware is still in development. Further, the second stage injector uses an atom to check if the system is already infected, instead of using a mutex like most of the malware today. The use of atoms is not a new technique, but still not very widespread.

The main payload is encrypted and packed inside the .tls section of the second stage injector. It first gets decrypted and then unpacked with the aPLib compression library. As persistence method, the main payload copies the initial loader to the AppData folder and creates a Jscript file inside the Startup folder which points to it. The second stage injector injects the main payload inside a x86 instance of svchost and patches its API function calls with an obfuscation technique to make static and dynamic analysis of the malware more difficult.

Compared to the previous version, the main payload contains some updates. This includes the strings to search on the victim’s system, the browser target list, and the bot commands. The main payload uses .bit top-level domains to contact its C&C server. The domain names, the user-agent string and the URL parameters are encrypted with a modified RC4 encryption algorithm. The domain names indicate that the attackers may be either located in Ukraine or have a Ukrainian background.

Unfortunately, at the time of the analysis the C&C server didn’t respond with any commands and thus further analysis of the targeted financial institutions wasn’t possible. This information would be normally downloaded into a configuration file on the victim’s disk. For some of its functionality, the main payload hooks some API functions inside the svchost.exe process into which it is injected. Further, it uses the Apache web server for the web injections. If it was successfully downloaded from the C&C server, the malware makes use of a layered service provider to hook into the Winsock API for intercepting and modifying inbound and outbound Internet traffic. It also contains the normally used methods to hook into the browsers networking functions found in many other banking Trojans.

Both the second stage injector and the main payload contain a lot of strings which are never used. This indicates the author(s) were either in a rush to build the malware or the development was done in a sloppy way.

Instead of the string “IntelPowerAgent6” seen in the last version, this sample contains the string “IntelPowerAgent32” which is never used. In addition to the atom created by the second stage injector to check if the system is already infected, the main payload also creates a mutex with a name based on the same procedure to create the name for the atom (see Appendix). However, the mutex uses a hardcoded prefix named “DAN6J0-” before the byte sequence that is also used for the atom string: “{DAN6J0-ae000000d2000000e100}”

Figure 2. Shifu mutex and the associated svchost process

Shifu, Shiz and Other Related Tools

The Shifu banking Trojan is mainly based on the Shiz/iBank source code, which is one of the oldest banking Trojans still in the wild today. Shiz was first discovered in 2006 and has been through several stages of development since that time. It began as a banking Trojan which only focused on Russian financial institutions. Later, it also began targeting an Italian bank which may have set the stage for a more international focus. The internal versions we have tracked over the last five years ranged from generation 2 to 4 (2011) and 5 (2013/2014). The fifth generation of Shiz was the last one we saw in the wild in 2014 (last internal version was 5.6.25) and it differs from the 4th generation in the coding style. It looks like it was developed by another coder, which could indicate the source code was sold or shared. The query string used to contact the C&C server of one of the very first versions of the fifth generation supports our theory:

botid=%s&ver=5.0.1&up=%u&os=%03u&ltime=%s%d&token=%d&cn=reborn&av=%s

We can see that the campaign name (cn) contains the string “reborn”.

Shifu was first discovered in the wild in the middle of 2015 and we believe it’s the evolution of the 5th generation of Shiz with a more international focus.

We have not only tracked the Shiz banking Trojan over the last couple of years, but also found several additional malware tools allegedly from the same author(s). Collected samples indicate the author(s) have developed a whole set of financially related malware. It’s not clear if the author works as part of a group or uses the malware themselves. These tools are mainly based on the source code of the fifth generation of Shiz.

We have connected these tools together because they all contain a PDB path that has the same root folder:

Z:\coding\…

Furthermore, most of the tools are based on the Shiz source code, because the coding style and used API functions are very similar. Also, comparing the code between the tools with BinDiff shows a high degree of similarity. Moreover, those tools with network functionality contain query strings similar to the one in Shiz to contact their C&C server.

As our colleagues from FireEye described last year, the PDB path found in Shifu is as follows:

Z:\coding\project\main\payload\payload.x86.pdb

Other tools we have identified have the following PDB paths and are likely from the same author(s):

Z:\coding\cryptor\Release\crypted.pdb

Z:\coding\malware\tests\Release\cryptoshit.pdb

Z:\coding\malware\RDP\output\Release\rdp_bot.pdb

Z:\coding\malware\ScanBot\Release\bot.pdb

The malware internally named “cryptor” contains an encrypted sample of BifitAgent, the first malware known to attack the financial software from BIFIT. While it’s possible that BifitAgent is developed from the same person, we haven’t found any indications for that. According to the compilation time stamps, most of the samples were created in October/November 2013.

The malware with the name “rdp_bot” is a small bot which uses the RDP protocol to gain full access to a computer. It uses the same modified RC4 encryption algorithm as the Shifu version discussed in this article. This tool was probably used along the Shiz banking Trojan, because the attacker is able to do his fraudulent activities directly from the victim’s computer. By doing so, one could fool bank antifraud systems which check for the IP address, browser footprints or keyboard layouts. The tool is based on the research about RDP performed by Alisa Esage. The samples date from June to November 2013.

The tool which is named “cryptoshit” contains an encrypted sample of rdp_bot and also uses the same modified RC4 algorithm as the Shifu version described here. The samples date September/October 2013 and January 2014 according to the compilation time stamp.

The malware with the internal name “ScanBot” is a small backdoor which uses the Super Light Regular Expression library (SRLE) for scanning a victim’s computer for files via commands from its operator. The samples date June 2013 according to the time stamp.

Protection Against Shifu

Palo Alto Networks customers are protected from Shifu in the following ways:

• Wildfire classifies Shifu files as malicious and signatures are loaded into Threat Prevention
• AutoFocus customers can track malware using the Shifu tag
• Command and Control domains used by Shifu are blocked through Threat Prevention

SHA256 Hashes of Samples Discussed

Initial obfuscated loader

d3f9c4037f8b4d24f2baff1e0940d2bf238032f9343d06478b5034d0981b2cd9
368b23e6d9ec7843e537e9d6547777088cf36581076599d04846287a9162652b
e7e154c65417f5594a8b4602db601ac39156b5758889f708dac7258e415d4a18
f63ec1e5752eb8b9a07104f42392eebf143617708bfdd0fe31cbf00ef12383f9

Second stage injector

003965bd25acb7e8c6e16de4f387ff9518db7bcca845502d23b6505d8d3cec01
1188c5c9f04658bef20162f3001d9b89f69c93bf5343a1f849974daf6284a650

Exploit injector

e7c1523d93154462ed9e15e84d3af01abe827aa6dd0082bc90fc8b58989e9a9a

CVE-2016-0167 exploit (x86)

5124f4fec24acb2c83f26d1e70d7c525daac6c9fb6e2262ed1c1c52c88636bad

CVE-2016-0167 exploit (x64)

f3c2d4090f6f563928e9a9ec86bf0f1c6ee49cdc110b7368db8905781a9a966e

Main payload

e9bd4375f9b0b95f385191895edf81c8eadfb3964204bbbe48f7700fc746e4dc
5ca2a9de65c998b0d0a0a01b4aa103a9410d76ab86c75d7b968984be53e279b6

Appendix – Technical details

Second Stage Injector Analysis

The second stage injector contains an exploit injector (x86 DLL) which in turn has two embedded exploits (x86/64 DLL) for CVE-2016-0167. The second stage injector also contains the encrypted and aPLib packed main payload module (x86 DLL) in its .tls section. For decryption, it uses a modified version of the RC4 encryption algorithm with a salt that is stored in the .rsrc section. Significant strings in the second stage injector’s .data section were XORed with the key 0x8D and get decrypted on-the-fly. Decrypted strings:

Exploit Injector with Embedded CVE-2016-0167 Exploits

The exploit injector is used to gain SYSTEM privileges on the infected host. The injector contains the actual exploits for both x86 and x64 systems. The magic PE bytes (“MZ”) at the beginning of the files are patched will null bytes to prevent them from automatic extraction.

The second stage injector checks for the current process’ integrity level and the OS version. If the integrity level of the process is low and the OS version is 6.1 (Windows 7 / Windows Server 2008 R2), the second stage injector writes the exploit injector file into memory. Then, it searches for the magic value 0x99999999 in the exploit injector which marks the beginning of the PE overlay. When the address was found, 12 bytes are added and the second stage injector jumps to this address which is in fact a custom PE loader shellcode. The call to the shellcode looks as follows:

Custom PE loader shellcode

It first gets the end of the shellcode which is then used to scan the exploit injector file for the magic PE number (“MZ”). The code to get end of the shellcode looks as follows:

Next, a custom GetProcAddress() function is used together with a hashing function to find the address of VirtualAllocEx(). Then, VirtualAllocEx() is called to allocate a memory buffer of with full access rights into which the exploit injectors sections are written with the appropriate memory alignments. The necessary memory addresses are then adjusted with help of the relocation information, the API function addresses are resolved and the IAT is filled. Finally, the shellcode jumps to the DLL entry point of the freshly created exploit injector module.

Exploit injector

At first, the strings “kernel32.dll”, “LoadLibrary” and “GetProcAddress” are created. Next, the image base address for kernel32.dll is searched and the addresses of LoadLibrary() and GetProcAddress() are obtained. With help of these API functions, the IAT addresses of the exploit injector get resolved and the IAT is filled. The purpose of this function is unclear, as it was already done by the second stage injector. Thereafter, a new thread gets created with API function CreateThread().

The thread first calls IsWow64Process() and according to the result either the embedded x86 or x64 version of the exploit file is written into a memory buffer. Next, the PE magic value (“MZ”) is written to the beginning of the exploit file. Then, an event named “WaitEventX” is created which is later used by the exploit. Then, the main exploit loading function is called.

The exploit loading function searches for the following process names and if found also the module names for the following strings which are part of Trend Micro security software:

• “uiSeAgnt.exe”
• “PtSessionAgent.exe”
• “PwmSvc.exe”
• “coreServiceShell.exe”

If one of the processes is found, a suspended process of wuauclt.exe is created. Otherwise, a suspended process of svchost.exe is created. In both cases, the command line argument “-k netsvcs” is passed, but can be only used by svchost.exe. It should be noted that this functionality always fails if the x64 version of Trend Micro Internet Security is installed. The code (x86) calls CreateToolhelp32Snapshot() on a x64 process which results in an error (ERROR_PARTIAL_COPY). Moreover, it also fails because the code tries to access a protected Trend Micro process (ERROR_ACCESS_DENIED).

Next, it maps the x86 or x64 file of the exploit into memory with CreateFileMapping() and MapViewOfFile() and fills in the memory with the exploit bytes. Finally, the section gets mapped into the suspended process of svchost.exe or wuauclt.exe by using ZwMapViewOfSection(). It then checks the OS version if it is 5.2 (Windows Server 2003 / Windows XP 64-Bit Edition) and exits the function if so. Afterwards, two memory buffers are created and a shellcode is written to each of them. The first obfuscated shellcode calls the second shellcode, which is a stager for the mapped exploit file. Next, it calls ResumeThread() to execute the suspended process so the exploit is executed.

The second stage injector verifies that the exploit was successful by checking if the integrity level of itself is still SECURITY_MANDATORY_LOW_RID. If not, the exploit successfully elevated privileges to SECURITY_MANDATORY_SYSTEM_RID and continues with the injection of the main payload. If the exploit failed, it tries to execute itself under the SYSTEM user account with help of the Windows command line (cmd.exe) and runas.exe tool.

Atom String Building

Instead of using a mutex like most of today’s malware, the second stage injector creates an atom and checks the global atom table to see if an instance of Shifu is already running.

At first, it uses the template string “%OS%_%NUMBER_OF_PROCESSORS%” for the API ExpandEnvironmentStrings() to get the Windows version and number of processors. For example, in Windows 7 with one processor the result would be “Windows_NT_1”. This string is then used to calculate four CRC32 hashes with RtlComputeCrc32() and the following initial values:

• 0xFFFFFFFF
• 0xEEEEEEEE
• 0xAAAAAAAA
• 0x77777777

The resulting CRC hashes of the string “Windows_NT_1” are as follows:

• 0x395693AE
• 0xB24495D2
• 0xF39F86E1
• 0xBAE0B5C8

Next, the last byte of each CRC hash is stored as a DWORD value on the stack:

• 0xAE000000 (from 0x395693AE)
• 0xD2000000 (from 0xB24495D2)
• 0xE1000000 (from 0xF39F86E1)
• 0xC8000000 (from 0xBAE0B5C8)

The stack with the hash byte sequence looks as follows:

AE 00 00 00 D2 00 00 00 E1 00 00 00 C8 00 00 00

The atom string is then created by converting first 8 bytes of the hash byte sequence to ASCII characters with snprintf() function. The result in this case would be:

“ae000000d2000000”

At last, it calls GlobalFindAtom() API to check if the atom is present and calls GlobalAddAtom() if not.

Figure 3. Shifu atom in the global atom table

Command Line Arguments

The second stage injector has two command line parameters of which only one has a functionality. They may be used for an upcoming feature or were just forgotten to be removed.

• –crypt-test

Shows just a message box with the text “It work’s!”

• –vm-test

No functionality

Anti-Analysis Tricks

Anti Sandboxie / Avast

Shifu checks if the module snxhk.dll (Avast) or sbiedll.dll (Sandboxie) is present in its own process space by calling GetModuleHandleA() and runs an infinite Sleep() loop if a handle is returned.

All the following anti analysis tricks are only used if Shifu is executed on a 32-bit Windows machine (no Wow64 process).

Process name detection

It enumerates running process names, converts them to lowercase, calculates the CRC32 hashes of those names and compares to the following list:

• 0x99DD4432 – ?
• 0x1F413C1F – vmwaretray.exe
• 0x6D3323D9 – vmusrvc.exe
• 0x3BFFF885 – vmsrvc.exe
• 0x64340DCE – ?
• 0x63C54474 – vboxtray.exe
• 0x2B05B17D – ?
• 0xF725433E – ?
• 0x77AE10F7 – ?
• 0xCE7D304E – dumpcap.exe
• 0xAF2015F2 – ollydbg.exe
• 0x31FD677C – importrec.exe
• 0x6E9AD238 – petools.exe
• 0xE90ACC42 – idag.exe
• 0x4231F0AD – sysanalyzer.exe
• 0xD20981E0 – sniff_hit.exe
• 0xCCEA165E – scktool.exe
• 0xFCA978AC – proc_analyzer.exe
• 0x46FA37FB – hookexplorer.exe
• 0xEEBF618A – multi_pot.exe
• 0x06AAAE60 – idaq.exe
• 0x5BA9B1FE – procmon.exe
• 0x3CE2BEF3 – regmon.exe
• 0xA945E459 – procexp.exe
• 0x877A154B – peid.exe
• 0x33495995 – autoruns.exe
• 0x68684B33 – autorunsc.exe
• 0xB4364A7A – ?
• 0x9305F80D – imul.exe
• 0xC4AAED42 – emul.exe
• 0x14078D5B – apispy.exe
• 0x7E3DF4F6 – ?
• 0xD3B48D5B – hookanaapp.exe
• 0x332FD095 – fortitracer.exe
• 0x2D6A6921 – ?
• 0x2AAA273B – joeboxserver.exe
• 0x777BE06C – joeboxcontrol.exe
• 0x954B35E8 – ?
• 0x870E13A2 – ?

File detection

Shifu checks if the following files or folders exist on the system and runs an infinite Sleep() loop if so:

• c:\sample\pos.exe
• c:\analysis\sandboxstarter.exe
• c:\analysis
• c:\insidetm
• c:\windows\system32\drivers\vmmouse.sys
• c:\windows\system32\drivers\vmhgfs.sys
• c:\windows\system32\drivers\vboxmouse.sys
• c:\iDEFENSE
• c:\popupkiller.exe
• c:\tools\execute.exe
• c:\Perl
• c:\Python27

Debugger detection

It checks if it’s being debugged by calling IsDebuggerPresent(). Also, it calls ZwQueryInformationSystem() with ProcessDebugPort and ProcessDebugObjectHandle to check for a debugger presence. If a debugger is detected it runs an infinite Sleep() loop.

Wireshark detection

Shifu attempts to open \\.\NPF_NdisWanIp with CreateFile() and will enter an infinite Sleep() loop if it is successful.

Self-sanity checks

It checks its own file name length if it is longer than 30 characters and runs an infinite Sleep() loop if so. Also, it checks if its own process name CRC32 hash matches one of the following:

• 0xE84126B8 – sample.exe
• 0x0A84E285 – ?
• 0x3C164BED – ?
• 0xC19DADCE – ?
• 0xA07ACEDD – ?
• 0xD254F323 – ?
• 0xF3C4E556 – ?
• 0xF8782263 – ?
• 0xCA96016D – ?

Furthermore, it checks if one of the following modules from GFI Sandbox is present in its own process address space:

• api_log.dll
• dir_watch.dll
• pstorec.dll

Unknown anti-analysis trick

Shifu uses an anti-analysis trick whose purpose is unknown to us. It retrieves the address of Process32NextW() and compares the first 5 bytes with the sequence 0x33C0C20800 which disassembles to:

This code is only present in 32-bit Windows XP and not in later Windows versions, because the Unicode version of that function probably wasn’t implemented yet. If the code sequence is found meaning that Shifu was executed on 32-bit Windows XP, it runs an infinite Sleep() loop.

Windows domain name check

It checks if the computer workgroup name is either “WORKGROUP” or “HOME” with API functions NetServerGetInfo() and NetWkstaGetInfo() and runs an infinite Sleep() loop otherwise. Next, it checks for the name “ANALYSERS” and runs the infinite loop if found.

Computer and user name check

Shifu gets the computer and user name with GetComputerName() and GetUserName() to check for the following strings:

• SANDBOX
• FORTINET
• VIRUS
• MALWARE
• MALNETVM

If one is found it runs an infinite loop.

Process termination feature

Second stage injector of Shifu enumerates all running processes, converts every name to lower case, calculates the CRC32 hash of it and compares it to the following ones:

• 0xD2EFC6C4 – python.exe
• 0xE185BD8C – pythonw.exe
• 0xDE1BACD2 – perl.exe
• 0xF2EAA55E – autoit3.exe
• 0xB8BED542 – ?

If one matches, it first tries to terminate the process with OpenProcess() and TerminateProcess(). If that fails, it tries to close the main window handle of the process if it is flagged as HANDLE_FLAG_PROTECT_FROM_CLOSE with ZwClose(). Then, it opens the process with full access rights and unmaps it from memory with ZwUnmapViewOfSection(). At last, the main window handle of the unmapped process is closed.

Main Payload Decryption, Unpacking and Injection

To decrypt the main payload, the second stage injector retrieves a salt needed for the decryption algorithm from its .rsrc section. It uses a modified RC4 algorithm where the salt is used to XOR the array of 256 bytes byte after byte at the beginning. The encrypted array is then used to decrypt the main payload located in the .tls section. The decrypted main payload is additionally packed with the aPLib compression library.

If the initial loader runs as a medium or high integrity level process, the routine which calculates the atom string name is called again. This time, only the first 4 bytes are used to build a string, for example “ae000000”. Next, the CRC32 hash of this string is calculated and used to XOR another array of 256 bytes starting from 0x0 to 0xFF. This encrypted array is then used to again encrypt the decrypted main payload. The resulting encrypted data are written to registry for persistence purposes under the key “HKCU\software\microsoft\windows” with a random CRC32 hash name, for example “f4e64d63”. Also, a second value with the string “ae000000” as name is created and filled up with null bytes and the path of the initial loader, for example “C:\ProgramData\7d5d6044.exe”. At last, the temporarily encrypted main payload gets decrypted again.

Figure 4. Encrypted main payload and initial loader path stored in the Windows registry

Next, the main payload gets unpacked into memory. Thereafter, a suspended svchost.exe process (x86) is created with the same integrity level as the parent process. The main payload gets mapped into the process and the magic PE value (MZ) patched. The svchost process gets then resumed so the main payload is executed. At last, a batch file is created and executed in the %TEMP% folder. It overwrites the original executed initial loader with a random number of bytes to cover the tracks. The random bytes are always followed by a space character and the CR LF control characters.

Main Payload Analysis

The main payload module’s IAT function names were XORed with the key 0xFF to make static analysis more difficult. Significant strings in the .data section are also XORed with the key 0x8D and get decrypted on-the-fly. Decrypted strings:

API Obfuscation

The main payload uses an API obfuscation technique known as Push-Calc-Ret obfuscation. The calls to the real API functions are patched by the second stage injector after the main payload gets injected into the svchost process. Whenever a Windows API function should have been called, instead the address of a trampoline function is called which calculates the actual function address. All the trampoline function addresses are stored in an array in memory.

For example, the main payload wants to call CreateFile(), but this call is patched. Now, it calls the trampoline function which could look as follows:

First, a value is pushed to the stack. Next, the EFLAGS register is saved to the stack, because it will be altered by the following XOR instruction (OF, CF flags are cleared and the SF, ZF, and PF flags are set according to the result). Then, the previously pushed value is XORed with another value to calculate the actual API function address. At last, the EFLAGS register gets restored and the real API function address is called via the RETN instruction.

Persistence Method

The main payload copies the initial obfuscated loader file to the %ProgramData% folder with a random file retrieved with GetTickCount(). Then, it creates a JScript file named “Common.js” in the Startup folder of the current user. The file contains the following code which runs the initial loader after the system was rebooted:

Updates of the Main Payload compared to Previous Version

Reports on previous versions of Shifu have been published by FireEye and Fortinet.

In comparison to the previous version, the list of substrings to scan for in the string that gets created with the computer name, user name, install date and system drive volume serial number was expanded:

• TREASURE
• BUH
• BANK
• ACCOUNT
• CASH
• FINAN
• MONEY
• MANAGE
• OPER
• DIRECT
• ROSPIL
• CAPO
• BOSS
• TRADE

Updated command list:

• active_sk
• deactive_sk
• deactivebc
• get_keylog
• get_sols
• inject
• kill_os
• load
• mitm_geterr
• mitm_mod
• mitm_script
• wipe_cookies

Updated list of targeted browsers:

• iexplore.exe
• firefox.exe
• chrome.exe
• opera.exe
• browser.exe
• dragon.exe
• epic.exe
• sbrender.exe
• vivaldi.exe
• maxthon.exe
• ybrowser.exe
• microsoftedgecp.exe

The main payload will download the Apache httpd.exe server file from one of the C&C servers to store it on disk for web injection purposes. Compared to the previous version, the main payload also contains two strings which indicate some functionality for the Zend PHP Framework:

• zend_stream_fixup
• zend_compile_file

Function Hooking in Svchost

Like in the previous version, the malware hooks some API functions to redirect URLs, capture network traffic, the clipboard and to log keystrokes. It uses a technique known as inline function hooking where the first 5 bytes of a function get patched with a jump to the malware’s hook handlers. The following functions get hooked:

• NtDeviceIoControlFile (ntdll.dll)
• ZwDeviceIoControlFile (ntdll.dll)
• GetClipboardData (user32.dll)
• GetMessageA (user32.dll)
• GetMessageW (user32.dll)
• TranslateMessage (user32.dll)
• GetAddrInfoExW (ws2_32.dll)
• gethostbyname (ws2_32.dll)
• getaddrinfo (ws2_32.dll)

Network Functionality

The main payload of Shifu uses .bit top-level domains which is a decentralized DNS system based on the Namecoin infrastructure. The malware requests the IP addresses of the domains by subsequently contacting the following hardcoded Namecoin DNS servers:

• 92.222.80.28
• 78.138.97.93
• 77.66.108.93

The C&C domain names, the user-agent string and the URL parameters are encrypted with a modified RC4 encryption algorithm. Decrypted strings:

• klyatiemoskali.bit
• slavaukraine.bit
• Mozilla/5.0 (Windows; U; Windows NT 5.2 x64; en-US; rv:1.9a1) Gecko/20061007 Minefield/3.0a1
• L9mS3THljZylEx46ymJ2eqIdsEguKC15KnyQdfx4RTcVu8gCT
• https://www.bing.com
• /english/imageupload.php
• /english/userlogin.php
• /english/userpanel.php
• 1brz

The encrypted strings are stored in the following format inside the .data section:

<LengthOfString><EncryptedString>

The domain string “klyatiemoskali“ means roughly translated to wish something bad to Muscovites. The second domain string “slavaukraine” means translated “glory to the Ukraine”. The included RC4 key “L9mS3THljZylEx46ymJ2eqIdsEguKC15KnyQdfx4RTcVu8gCT” is used to encrypt the network traffic.

At the time of analysis, only the following Namecoin DNS server was answering with the IP address of the actual C&C server:

77.66.108.93 (ns1.dk.dns.d0wn.biz)

Figure 5. Namecoin DNS server information of 77.66.108.93

The following screenshot shows the captured network traffic during the dynamic analysis of Shifu:

Figure 6. Shifu network traffic captured with Wireshark

We can see that Shifu subsequently queries the Namecoin DNS servers with the domain name klyatiemoskali.bit to get the IP address. After one name server responds with the IP address of the C&C server, it does a TLS handshake to open an encrypted network channel. Finally, it sends some encrypted data and gets an encrypted answer. However, no further network traffic could have been observed during the time of the analysis. Both domain names, klyatiemoskali.bit and slavaukraine.bit, resolved to the IP address 103.199.16.106 at the time of analysis.

As the .bit top-level domain relies on the Namecoin cryptocurrency which is based on the Bitcoin system, every transaction can be traced back. Thus, we can use a Namecoin block explorer to look when the .bit domains were registered and which IP addresses are connected to it. For example, if we use the web service namecha.in, we can get the following information for klyatiemaskali.bit:

We can see the same information for slavaukraine.bit:

Both domains were registered on 2016-06-03 and only one IP address is assigned to them. This IP address coincides with the response of the Namecoin DNS server we have seen in the captured network traffic. Moreover, we can see the domain seems to be still active.

URL Query String for C&C Server

The main payload contains a query string template used to send information of the victim to the C&C server:

botid=%s&ver=%s.%u&up=%u&os=%u&ltime=%s%d&token=%d&cn=%s&av=%s&dmn=%s&mitm=%u

We can see that some information is dynamically retrieved (bot identifier, uptime, operating system version, local timestamp, token, anti-virus software, domain name of workstation, man in the middle interception detected), while also static values like the bot version and the campaign name are send. An example of the created query string could look as follows:

botid=26C47136!A5A4B18A!F2F924F2&ver=1.759&up=18294&os=6110&ltime=-8&token=0&cn=1brz&av=&dmn=&mitm=0

We can see that the internal Shifu version is “1.759” and the campaign name is stated “1brz”.

If we compare Shifu’s query string with the one of the latest Shiz version we have tracked which dates February 2014 (internal version 5.6.25), we can see the similarity between those two malwares:

botid=%s&ver=5.6.25&up=%u&os=%03u&ltime=%s%d&token=%d&cn=sochi&av=%s

Modified RC4 Encryption Algorithm

Shifu uses a modified version of the RC4 encryption algorithm. We have reconstructed the algorithm in Python and show how the domain name “klyatiemoskali.bit” present in the main payload will be encrypted as an example:

Dominik Reichel

[Palo Alto Networks Research Center]