With the dawn of 2017, ransomware continues to emerge as a top security threat. This form of attack that encrypts and locks computer files and devices until a ransom is paid looms ominously over large companies, SMEs and even individuals.
Ransomware is part of the top 10 security threat predictions by various analysts and security labs across the world. In 2015, businesses paid $24 million to ransomware attackers, a figure that was expected to jump to $850 million in 2016, according to Carbon Black’s 2016 Threat Report. However, I would shudder to place a number on that total, with many organizations choosing to pay the ransom rather than report the incident.
New threats and attack surfaces emerge with every new innovation, such as the Internet of Things (IoT) and self-driving cars. Given the rapid increase of Internet-enabled devices on the market, the security threats associated with such devices also will continue to surge.
The incentive to hack is generally financial. Cybercriminals buy and sell stolen data at underground black markets. Social security numbers, bank account information, credit card data, personal identity information and personal health information are sold. Some experts have predicted that the sheer volume of ransomware attacks and breaches into IoT devices could create a new crime model called Ransomware of Things (RoT).
Enterprise-targeted ransomware attacks have become mainstream and will continue to be a major threat in 2017. New methods of ransomware include exploiting vulnerable web servers as an entry point to gain access into an organization’s network. Refining ransomware attacks to target a specific group, whether high-profile users or SME companies, will greatly increase the success rate of ransomware campaigns. The more cyber criminals know about their potential victims, the more resources they are able to exploit. They can automatically craft compelling, trustworthy spear-phishing messages that will drive record-breaking open rates and, thus, more users will get infected.
Once cyber criminals realize they are dealing with a vulnerable, data-rich company, they can customize ransom messages to ask for larger amounts of money than they typically would. Companies will be more compelled to pay up than ever before. The recent trend of attackers using social engineering and social networks to target sensitive roles or individuals within a company to get to data shows the need for comprehensive security education. In 2017, attackers will continue to exploit humans to install malware, transfer funds, and steal information, with significant changes in techniques and behavior across the three main vectors that target people: email, social media and mobile apps.
A prediction for 2017: “Small will be the new big,” as sophisticated threat attackers return to smaller, more targeted campaigns to deliver their malware payloads. In 2017, ransomware authors will target mission-critical servers and PCs within targeted departments. By holding these sensitive devices hostage, ransomware authors will be applying the right pressure at the right time to quickly receive the ransom.
The ransomware of the future would have the capability to turn off power, shut down communication lines and disrupt production, owing to the increased use of IoT which, as Brian Krebs noted at ISACA’s CSX North America conference in October, poses an enormous concern.
Ransomware attackers will also diversify their targets from large enterprises to SMEs, given that the SMEs are relatively easier picks and the attacks could be perpetrated multiple times spread over multiple targets.
There are several experts, labs and consultants available to provide solutions. However, ransomware is likely to remain among the top 10 security threats in 2017, even for the smallest of companies. Until companies of all sizes—as well as individuals—collaborate well enough to share threats, intelligence and research work, expect ransomware to continue to be a bane.
Sunder Krishnan, CISA, past president of ISACA Mumbai Chapter
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:
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.
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
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:
1
2
3
4
00401EF5pusha
00401EF6add esi,0Ch
00401EF9call esi->PE loader shellcode inoverlay
00401EFBpopa
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:
1
2
3
4
00077174jmp short00077178
00077176pop eax
00077177retn
00077178call00077176
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:
1
2
33C0XOREAX,EAX
C20800RETN8
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:
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:
1
2
3
4
5
00846110PUSH2B464C25
00846115PUSHFD
00846116XORDWORD PTR SS:[ESP+4],5DB5E13F
0084611EPOPFD
0084611FRETN
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:
1
2
varyqvltidpue=newActiveXObject(“WScript.Shell”);
yqvltidpue.Run(“C:\\PROGRA~3\\930d4a6d.exe”)
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
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:
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:
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:
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:
Having worked for most of the “Big Four” as well as several boutique consultancies, I have witnessed a well-marketed shift and the birth of a new industry as it pertains to integrated regulatory content. When I refer to integrated regulatory content, I mean taking statements from individual sources and mapping those to a single control statement. For example, PCI 3.2, Requirement 2.1 states that default account passwords for accounts shipped with a Commercial Off The Shelf (COTS) product should be changed.
Similarly, supplemental guidance from control enhancement 5, of the SA-4 control family of NIST SP 800-53r4, mentions very similar control language. In an integrated framework, one would have a single control named something such as “Access Management – Password Management – Default Accounts,” and both the language from NIST 800-53r4 and PCI would be mapped to that single integrated requirement as opposed to managing similar requirements independently across frameworks. This mapping would ostensibly allow one to create controls and control procedures that could reduce testing and compliance efforts within most organizations.
What used to exist in separate, industry-centric silos has now been ported into frameworks with the promise of “test once and satisfy many.” Every risk consulting firm I worked for had a matrix that we tried to leverage to help our customers consolidate controls and testing efforts. I once worked for a small consultancy that charged tens of thousands of dollars per year for regulatory content subscriptions to their uniquely mapped library of content! Now, we have companies such as the HITRUST Alliance and the Unified Compliance Framework that base their entire business off the integrated content they produce.
We also have consortiums of volunteers such as those that support the Cloud Security Alliance’s Common Controls Matrix. Integrated content is generating tens of millions of dollars a year in content and professional services work, but for 95 percent of the regulatory content out there, it is free to use.
Companies now exist with business based solely upon integrated framework content. As I look at the landscape, there are many attributes of content libraries that one should question before investing in an integrated content library. The list I have generated is as follows:
Who Mapped This?
You want mappings to be done by people that know IT risk, security and controls. Having credible personnel can reduce mismappings and reduce potential doubt as your integrated library further permeates your organization.
Are there proprietary sources in use? If so, do you have the proper licensing with the source bodies?
I have worked for multiple firms that baked ISO, COBIT 5 and other proprietary frameworks into their source content. Companies need to ensure they have more than a single purchased license of documents that are to be purchased on an individual basis. Ask the question so there are no surprises or lawsuits as you move forward.
Are there other integrated source libraries mapped?
HITRUST and the CSA CCM are already integrated , so effectively mapping those frameworks to another integrated framework is not feasible. Be wary of anyone that is mapping already integrated frameworks into a proprietary framework as they likely do not understand the impact of issues to the data model.
How does content get updated?
Will you receive an email? Will you receive the update in XML or CSV? Is it a feed or manually provided? Will you have to have someone take the data and apply it to your GRC environment and then perform testing to ensure it was applied correctly?
How frequent are updates implemented?
Some content providers do not provide updates. Any upkeep is the responsibility of the client. Others provide quarterly updates and some use an ad-hoc schedule. If you have to be PCI compliant and need that mapped into your framework by a specific timeline, you need to have a good understanding of the timing for when the PCI update will hit your framework or you may have to map manually.
What is your QA process?
What tools and techniques are used to ensure that mappings are comprehensive? What personnel do you have who are qualified to perform content-specific mapping quality assurance? Do you look for issues in copy and paste translations, or do you search for syntax errors? Do you embed HTML in your mapping content? All of these are questions to ask about the quality of what you get from a library.
How many customers do you have in my industry?
Many libraries are heavy on financial services content because they are one of the most highly regulated industries. If you are a healthcare entity or industrial power supply organization, ask how many other peer companies use their content and request to speak with representatives of those companies to help reduce headaches down the road.
I do not use 70 percent of the mappings in your library, so why am I paying for them?
Often, I have seen companies paying for a library of 200 sources, but they really only use 30 of those. Ask what the cost is if you just pay for the 30 that you need, as you should not be held to paying for a universe of content that does not apply to your company. Also, I have seen companies using sliding pricing models based upon the company size. A Fortune 50 company may be paying 100 percent more than a smaller entity in some cases. This is another area where speaking with a broad swath of the customer base before you buy can be critical.
Aside from cost, also inquire about how to reduce the noise of the library. Most robust sources have hundreds or thousands of regulatory sources mapped to them. It is likely your organization only needs a percentage of those, so ask how you can ensure that unnecessarily mapped content does not show up in your content universe.
How do new sources get vetted for evaluation into your framework?
Gaining an understanding of the evaluation and mapping process for new sources is important. Often, it’s critical mass that drives a mapping priority, but sometimes it is a high-profile client of the integrated library content provider that gets mapping moved up on the docket. Know the process that applies to your library and get an understanding of what you may need to make your requirements a priority.
What is the data model as it pertains to sources, source sections and control statements?
Understand the relationships that are in place among the decomposed layers of the content library. Some content providers try to differentiate on their library content data model. Getting perspective from a technical resource that understands database relationships can be very useful in this scenario, as they can help to analyze and validate the layout of the content from a relational perspective. This can be important if the data model is overly complex.
What if any subjective work has been performed on the content that is not germane to the content itself?
The question likely does not make sense upon first reading it, but knowing the answer can be impactful. Once you buy content and begin to integrate it, if you learn facts about the content along the way, it may be too difficult to turn back. For example, some content libraries provide subjective key and non-key control delineations for integrated requirements out of the box. If one begins to implement using those delineations without any rationalization for the control based upon the environment or the system at hand, those definitions could impact testing cycles and associated level of effort. Ask your provider if they have subjectively done anything to their library that may impact your organization’s implementation of the content.
How searchable and filterable is the content?
Get clarity on how the content is presented for consumption and analysis. UCF has a very nice front end that they use to create cuts of library content and produce filterable results. Most libraries I have seen in the past exist in large Excel files where filtering and reporting is limited to Excel’s capabilities. To make effective use of the content, you will likely need to port it into a GRC tool or a database. Make sure to gain perspective on searching and filtering as content is extended to the user.
What are the licensing terms?
If you are paying more than US $10,000 a year in content that is largely free, you are getting taken. When feasible, do not sign up for multi-year agreements, especially initially. Take your first year and learn how the content will impact your organization. Ask if you can try the content for a period of time before purchasing. This gives you time to investigate and perform due diligence.
Will the content stand up in a court of law?
I have spoken to peers who believe that integrated regulatory content, especially from those one-off sources, may have trouble being defended in a court of law should due diligence, due care and compliance questions come into play. Many of my peers feel that in a court system, only those well-respected and industry-vetted sources would be resolute enough to endure scrutiny, so ask your content provider if they have perspective to share on that topic.
Mapping can be difficult and time-intensive. Companies are fearful of a mismapping or a missed mapping, which could call their libraries into question from completeness and accuracy perspectives. Before purchasing integrated content, ask to speak with current customers of the content and dig into the details. You may be surprised at what you find.
AJ Armour, CISM, CGEIT, CRISC, CISSP, CEH, Archer Certified Professional, Approva Certified Professional Director of Security Services, The Mako Group LLC
The 2016 Americas ISLA Ceremony and Gala honored the best and brightest in the field of cybersecurity. Held each year at the (ISC)² Security Congress, the dinner and awards presentation took place at Jimmy Buffet’s Margaritaville where Jim Davis, creator of Garfield, was the keynote speaker.
James McQuiggan, CISSP, was the emcee of the evening. A long-time volunteer and advocate for the Center for Cyber Safety and EducationTM’s Safe and Secure Online®program, he kicked off the evening wearing a Safe and Secure t-shirt – later changing into a festive Hawaiian shirt and grass skirt – before embracing the “Florida cocktail” attire. Jokes, costume changes, video skits and engaging the crowd are all par for the course for any emcee, but what James didn’t know is that he was among the honorees receiving an award that evening.
(ISC)² CEO David Shearer presented James with the 2016 President’s Award, which recognizes a volunteer who has made a significant impact on and contribution to the organization through their dedicated volunteer efforts over the past year.
James is a Product and Solutions Security Officer for the Siemens Wind Power America’s division in Orlando, Florida. He has been a member of (ISC)² since 2008 and holds the CISSP® certification. Over the past six years, he has given the Safe and Secure Online presentation to countless groups of children, families and senior citizens. He is a passionate advocate for cyber safety, and (ISC)² is proud to have him represent our organization and the cybersecurity profession.
