Author: Dr. Philip Cao

In November 2016, we observed the reemergence of destructive attacks associated with the 2012 Shamoon attack campaign. We covered this attack in detail in our blog titled Shamoon 2: Return of the Disttrack Wiper, which targeted a single organization in Saudi Arabia and was set to wipe systems on November 17, 2016. Since our previous publication, we have found  another, similar but different payload used to target a second organization in Saudi Arabia that was configured to wipe systems twelve days later on November 29, 2016. This latest attack potentially materially impacts one of the primary countermeasures employed against wiper attacks: Virtual Desktop Interface snapshots.

The payload used in this attack was very similar to the November 17, 2016 payload, but exhibited slightly different behaviors and contained hardcoded account credentials specific to the newly targeted organization. The hardcoded account credentials met Windows password complexity requirements, which suggests that the threat actors obtained the credentials through a previous, separate attack, similar to the November 17, 2016 attack.

The most notable thing about this latest sample is that it contains several usernames and passwords from official Huawei documentation related to their virtual desktop infrastructure (VDI) solutions, such as FusionCloud. VDI solutions can provide some protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems. The fact that the Shamoon attackers had these usernames and passwords may suggest that they intended on gaining access to these technologies at the targeted organization to increase the impact of their destructive attack. If true, this is a major development and organizations should consider adding additional safeguards in protecting the credentials related to their VDI deployment.

At this time, we have no details of the attack we believe preceded this Shamoon attack to obtain credentials. We also have no details on the delivery method used to deliver the new, similar, but different Disttrack payload in this attack.

The Second Shamoon 2 Attack

This second known attack associated with Shamoon 2 also used the Disttrack payload, albeit a new, similar but different one from the original Shamoon 2 attack. Specifically, it used a 64-bit variant that was configured to begin its destructive activities on November 29, 2016. Like the Disttrack sample used in the first reported Shamoon 2 attack, it including a wiper and communications module stored in resources within the executable.

Table 1 below shows that the method the Disttrack payload uses to extract and decrypt the modules from resources is the same; however, the resource names changed from “X509”, “PKCS7” and “PKCS12” to “LANG”, “MENU” and “ICO”.

Our efforts to decrypt the “ICO” resource have thus far been unsuccessful as the Disttrack payload has an associated key but does not contain code that decrypts and extracts this resource.

Propagation Inside Compromised Networks

Similar to the previous attack, the Disttrack payload in this attack spreads to other systems on the local network (/24 network specifically) by logging in using legitimate domain account credentials, copying itself to the system and creating a scheduled task that executes the copied payload. While this method is the same as discussed in our previous blog, the account credentials used in this attack were specific to the targeted organization and the file names used when copying the payload to remote systems were different.

Legitimate User Accounts

There were 16 account credentials found hardcoded within the Disttrack payload, appearing to be a mixture of individual user accounts and broader administrator accounts. All but one of the passwords met Windows complexity requirements, specifically, containing uppercase and lowercase characters, and either a number, symbol, or both. One of the general administrator accounts seen in this payload was also in the Disttrack payload in the first Shamoon 2 attack from November 17, 2016, which may not be specific to the targeted organization and instead used as an attempt to guess the login credentials. Based upon the existence of these credentials, it is highly likely the threat actors had carried out a previous attack to obtain these account credentials, as it is unlikely that these passwords were guessed or brute forced.

As noted earlier, a new development with this latest Disttrack payload is that several of the usernames and passwords are found within official documentation as administrator accounts for Huawei’s virtualized desktop infrastructure (VDI) products, such as FusionCloud. This may suggest that the targeted organization used these credentials when deploying Huawei VDI systems. Shamoon actors may have obtained these credentials from a prior attack; however, it is also possible that the actors included these default usernames and passwords as an attempt to guess the login credentials to the VDI infrastructure.

VDI solutions can provide some protection against a destructive malware like Disttrack through the ability to load snapshots of wiped systems. Also, since FusionCloud systems run a Linux operating system, which would not be susceptible to wiping by the Windows-only Disttrack malware, this could be seen as a reasonable countermeasure against attacks like Shamoon. However, if the attacker was able to log into the VDI management interfaces using the account credentials they could manually carry out destructive activities against the VDI deployment, as well as any snapshots. The targeting of VDI solutions with legitimate, stolen or default credential represents an escalation in tactics that administrators should be aware of and take immediate steps to evaluate and address.

New Disttrack Names

The filenames that the payload copies itself to within the System32 folder of the remote system differs from the previously reported attack, specifically using “ntertmgr32.exe” for 32-bit or “ntertmgr64.exe” for 64-bit systems. The scheduled task executes these files on the remote system, which results in the creation of a Disttrack service named “NtertSrv” compared to the service name “ntssrv” created by the Disttrack payload used in the November 17, 2016 attacks. This can be seen in Figure 1.

Figure 1 Disttrack service created on systems during propagation

Command and Control

The communications module used in this attack is rather hobbled, as it was configured without an operational command and control (C2) server to communicate with. The lack of an operational C2 is much like the November 17, 2016 attack that had the IP address “1.1.1.1” within its configuration to use as a C2 server. Unlike the non-operational C2 of “1.1.1.1” used in the first Shamoon 2 attack, this communications module completely lacked any IP address or domain name for a C2 server within its configuration.

Also, in this sample, Disttrack did not save its communications module to the system using the filename “netinit.exe” like in the original attack, rather it chose a random name from the following list:

• caiaw00e.exe
• sbuvideo.exe
• caiaw00i.exe
• olvume.exe
• usinwb2.exe
• briaw005.exe
• fpwwlwf.exe
• epiaw003.exe
• briaw002.exe
• olvsnap.exe
• dmwaudio.exe
• briaw006.exe
• miWApRpl.exe
• caiaw00b.exe
• lxiaw003.exe

Lastly, the communications module also uses different file names than the original Shamoon 2 attack. Instead of setting a custom “kill time” in a file named “usbvideo324.pnf” within the “%WINDOWS%\inf” folder, it uses a file name of “dcT21x400i.pnf”. It also would send the C2 server the contents of a file named “vsfnp7_6.pnf” from the folder “%WINDOWS%\inf” instead of “netimm173.pnf”.

Destruction

Much like the initial attacks, the lack of an operational C2 server suggests that the threat actor’s sole intention for carrying out this Shamoon 2 attack was to destroy data and systems. Without an operational C2, the actor would be unable to issue a command to set a custom “kill time” when the Disttrack payload would begin wiping systems, which would force the payload to rely on its hardcoded “kill time”. The hardcoded date suggests that this attack was set to begin wiping systems on November 29, 2016 at 1:30 AM local Saudi Arabia time.

Unlike the previous Shamoon attacks that occurred on a holiday and over a weekend, this kill time occurred during the work week, as November 29, 2016 was a Tuesday. However, it appears this attack attempted to maximize its impact by occurring very early in the morning before the majority of the organization’s staff were on site. This aligns with the Shamoon actors conducting their attacks off-hours to increase the efficacy of the attack by increasing the timeframe of detection and response.

When Disttrack observes the system clock exceeding the “kill time”, it will save its wiper component to the system using one of the following randomly chosen filenames:

• pdwmtphw.exe
• caiaw00a.exe
• sdwprint.exe
• caiaw00d.exe
• kyiaw002.exe
• sdwscdrv.exe
• briaw00a.exe
• saiaw002.exe
• _mvscdsc.exe
• hdvmp32.exe
• _s3wcap32.exe
• hpiaw001.exe
• lxiaw004.exe
• cniaw001.exe
• lxiaw006.exe
• caiaw00f.exe
• newtvsc.exe

When executed, the wiper component will extract a kernel driver from its resource section and decrypt it with a 172-byte XOR key. The wiper saves the kernel driver (SHA256: 5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a) to the “Windows\System32\Drivers” folder in a file named “vdsk911.sys”. The wiper then uses this file to create a kernel driver service named “vdsk911”, as seen in Figure 2.

Figure 2 RawDisk kernel driver service created by Disttrack wiper

The kernel driver is the 64-bit version of the commercial RawDisk driver by EldoS Corporation, which is the exact same file as the “drdisk.sys” driver extracted from the Disttrack 64-bit payload in the ‘X509’ resource in the first reported Shamoon 2 attack. The Disttrack payload will use this kernel driver to access the master boot record (MBR), partition tables and files and folders on the system to overwrite them with the same image of the deceased Syrian boy as in the previous Shamoon 2 attack.

During our analysis, we again observed the wiper setting the system time to a random date between August 1 and August 20, 2012, as seen in Figure 3. As mentioned in our previous blog, the reason the wiper sets the system time to this random date in August 2012 is due to a temporary license key needed to use the RawDisk kernel driver. The temporary license key used in this attack is the exact same as the first attack.

Figure 3 Wiper changing the system date to a random date in August 2012

Since our original blog, we’ve successfully decrypted the license key, which can be seen in Figure 4. The expiration date in the temporary license key is an 8-byte field (highlighted by the orange box) that corresponds to Microsoft’s FILETIME structure, which represents the number of 100-nanosecond intervals since January 1, 1601 (UTC). In the temporary license key used in all of the Shamoon related attacks, the expiration date was set to August 30, 2012 at 8:34:29 UTC, which is the reason the wiper sets the system time to a random day between August 1 and August 20, 2012. Also, we found that the temporary license key was registered to “binnatova@bsunanotechnology.com”. We are unsure how this email address is involved with Shamoon, as it was likely compromised back in 2012 and used by the actor to obtain the temporary license for RawDisk.

Figure 4 RawDisk temporary license decrypted showing August 2012 expiration date

After the MBR, partition tables and files are overwritten, the wiper issues the command of “shutdown -r -f -t 2” to reboot the system, which is the same command as used in the first Shamoon 2 attack. Figure 5 shows the dialog box that pops up as a result of this command, which will be followed by a system reboot.

Figure 5 The shutdown dialog box opened just before reboot of a Windows 7 system wiped by Disttrack

The purpose of rebooting the system remains the same, as the portions of the hard disk and filesystem needed to successfully boot the system were overwritten with a JPEG image, the system is no longer able to start up. Figure 6 shows the result of this reboot in an analysis virtual machine, as the operating system could no longer be found.

Figure 6 System unable to find its operating system

The operating system fails to load as the MBR is overwritten with a JPEG image. As seen in Figure 7, sector 0 of the physical hard disk, which normally stores the master boot record now contains the beginning of a JPEG file marked by the “JFIF” magic bytes in the two orange boxes.

Figure 7 Hexdump of sector 0 of the physical showing the MBR overwritten with a JPEG file

Conclusion

We analyzed a second Disttrack payload associated with Shamoon 2, which suggests that the threat actors targeted a second Saudi Arabian organization in this attack campaign. The actors used the Disttrack payload to spread to other systems on the local network using legitimate credentials. The legitimate credentials were specific to the targeted organization and were complex enough to suggest that the threat actors carried out a previous attack to obtain the credentials. Also, the actors hardcoded credentials found in Huawei’s official documentation for its VDI solutions, suggesting that the threat actors may have had access to appliances hosting the infrastructure. The Disttrack wiper was set to begin overwriting systems on November 29, 2016 at 1:30 AM, which aligns with the Shamoon actor’s tactic to maximize its impact by attacking at a time when the targeted organization would have less staff and resources available onsite.

Palo Alto Networks customers are protected from the Disttrack payload used in this attack:

• WildFire properly classifies Disttrack samples as malicious
• Threat protection AV signature of Virus/Win32.WGeneric.ktoto detects the new payload.
• AutoFocus customers can monitor Disttrack activity using the Disttrack tag

Indicators of Compromise

Hashes

010d4517c81bcdc438cb36fdf612274498d08db19bba174462ecbede7d9ce6bb (64-bit Disttrack)
efd2f4c3fe4e9f2c9ac680a9c670cca378cef6b8776f2362ed278317bfb1fca8 (Communication)
113525c6bea55fa2a2c6cf406184092d743f9d099535923a12cdd9b9192009c4 (Wiper)
5a826b4fa10891cf63aae832fc645ce680a483b915c608ca26cedbb173b1b80a (vdsk911.sys)

Filenames

ntertmgr32.exe
ntertmgr64.exe
vdsk911.sys
dcT21x400i.pnf
vsfnp7_6.pnf
caiaw00e.exe
sbuvideo.exe
caiaw00i.exe
olvume.exe
usinwb2.exe
briaw005.exe
fpwwlwf.exe
epiaw003.exe
briaw002.exe
olvsnap.exe
dmwaudio.exe
briaw006.exe
miWApRpl.exe
caiaw00b.exe
lxiaw003.exe
pdwmtphw.exe
caiaw00a.exe
sdwprint.exe
caiaw00d.exe
kyiaw002.exe
sdwscdrv.exe
briaw00a.exe
saiaw002.exe
_mvscdsc.exe
hdvmp32.exe
_s3wcap32.exe
hpiaw001.exe
lxiaw004.exe
cniaw001.exe
lxiaw006.exe
caiaw00f.exe
newtvsc.exe

Service Names

NtertSrv
vdsk911

Robert Falcone

[Palo Alto Networks Research Center]

The use of threat intelligence to defend networks against attacks is on the rise. Threat intelligence consists of evidence-based and actionable knowledge about attacks. As members of the security arena chip in to share threat intelligence, this poses a new challenge: wrangling threat intelligence from multiple sources into a single format that a security platform or infrastructure can readily use to enforce policy. This process requires a significant investment of time and resources.

Enter MineMeld. If you’ve come across MineMeld in the past few months, it’s like stumbling upon hidden treasure. Gone are the days of manually digging through countless indicator feeds for the threat intelligence you need.

Get started with MineMeld in 3 easy steps!

1. Choose miners. A miner is a source of threat intelligence, such as an indicator feed or a subscription-based threat intelligence service like AutoFocus.
2. Choose processors. A processor extracts indicators from miners and performs an action on the indicators—the action depends on the processor you select. For example, MineMeld processors can filter data from miners to extract only indicators of a certain type and remove duplicates of an indicator if the processor receives it from multiple miners. You control which miners a processor will filter and aggregate.
3. Choose your desired output. MineMeld automatically delivers indicators from processors to your desired output, such as a Palo Alto Networks dynamic address group, external dynamic list, or a TAXII feed. You can configure MineMeld to forward indicators from multiple processors to multiple outputs.

http://researchcenter.paloaltonetworks.com/wp-content/uploads/2017/01/PANW_MineMeld.pdf
Download and Unearth a Wealth of Threat Intelligence with MineMeld today!

Happy reading!

Your friendly Technical Documentation team

Have questions? Contact us at documentation@paloaltonetworks.com

Patricia Cruz

[Palo Alto Networks Research Center]

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]