Today’s cyber attackers have proven themselves far more capable and committed, stopping at nothing to access the pools of valuable data that uphold the integrity and reliability of your business. To maintain a strong security posture and prevent cyber breaches, leverage User-ID™, user-based access controls, on your next-generation firewall (NGFW) to safely enable the applications and technologies required to drive your business forward. User-ID significantly improves network visibility by mapping network traffic to specific users, rather than IP address, and offer several features to protect your network and help block potential threats at every stage of the typical attack lifecycle.
Access controls can be applied to ensure that only valid, approved users can access necessary assets and data. Note, however, that legitimate users are not threat free. Threat prevention should also be applied to the network to protect systems and application vulnerabilities from exploitation.
Leverage User-ID controls to identify and block malicious command and control traffic.
In the event of an infection or data breach, control sensitive data exfiltration by ensuring every user, even infected users, can only access a small subset of the network.
Leverage user-based reports and breach forensics for a complete, accurate analysis of the breach to help with future policy implementation.
User-based access controls are steadily becoming in integral component of the network security infrastructure and threat prevention measures. However, it’s important to understand that establishing and implementing a user-based security strategy and policy is not a single team’s responsibility, and should be rooted in the business leadership team’s position on cybercrime prevention. Given the recent spate of high-profile cybercrimes, security is now being discussed at the boardroom level. Leverage the heightened security awareness to build a business case for user-based access policy with the leadership team, and work in tandem to create business policies to simplify and reinforce the implementation. The leadership team’s support will be helpful during policy roll out, and when making necessary adjustments, such as denying access to certain websites, or to help ease the minds of less-than-patient users in the face of issues that need to be ironed out.
Beyond the organization’s leadership, User-ID access policy requires coordination and buy-in from several teams to ensure a seamless adoption and execution. Here are a few examples of who should be involved in the planning and implementation of user-based access policy:
IT Architects
The IT architects know the ins and outs of accessibility. They can offer insight regarding which users log in to the network from various office locations, and whether those users require access to resources that may be safeguarded by NGFWs in other locations.
IT & Security Operations
When it’s time to roll out the new user-based access controls and policy created with User-ID, the IT & Security Operations team will be critical to the execution, helping to troubleshoot any issues associated with implementation. Make sure to provide the proper training so that they are equipped to handle the higher-than-average volume of help desk tickets and user accessibility inquiries.
IT Administrators
Administrators are vital in providing user identity information on which to frame user-based access controls and policy around:
Network Admins: As device owners, network admins can provide user identity information from Wireless LAN controllers, NAC devices or VPN gateways
Directory Admins: Work with directory admins to gain valuable user identity information from directory servers, such as Active Directory
Enterprise Services Admins: To define user-based access requirements for enterprise services, like SAP for example, security practitioners must team up with enterprise service admins
Endpoint Admins: In addition to traditional VPN remote access and secure connectivity, coordination with endpoint admins is necessary to ensure user-based access controls extend to the mobile workforce
Implementing User-ID access policy on your Palo Alto Networks NGFW, with the participation and buy-in of all appropriate groups, will aide in meeting your organization’s goal to reduce individual users’, and the entire networks’, risk of infection.
To learn more about the benefits of leveraging User-ID, user-based access controls, on your Palo Alto Networks NGFW:
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”.
Component
Resource Name
Offset
Size
Base64 key
Wiper
LANG
94399-14 = 94385
563712
OWRKbTxrleYfLm…
Communications
MENU
218709-14 = 218695
187904
QsCfQA6ze9CoOz…
Unknown
ICO
Unknown
Unknown
ijX7buB1FIjSn/0D…
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:
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:
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
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!
Choose miners. A miner is a source of threat intelligence, such as an indicator feed or a subscription-based threat intelligence service like AutoFocus.
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.
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.
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:
The DragonOK group has been actively launching attacks for years. We first discussed them in April 2015 when we witnessed them targeting a number of organizations in Japan. In recent months, Unit 42 has observed a number of attacks that we attribute to this group. Multiple new variants of the previously discussed sysget malware family have been observed in use by DragonOK. Sysget malware was delivered both directly via phishing emails, as well as in Rich Text Format (RTF) documents exploiting the CVE-2015-1641 vulnerability (patched in MS15-033) that in turn leveraged a very unique shellcode. Additionally, we have observed instances of the IsSpace and TidePool malware families being delivered via the same techniques. While Japan is still the most heavily targeted geographic region by this particular actor, we also observed instances where individuals or organizations in Taiwan, Tibet, and Russia also may have been targeted.
Infiltration
We observed two unique techniques of infiltration for this particular campaign:
Phishing emails being sent with malicious executables directly attached
These emails targeted the following industries in Japan:
Manufacturing
Higher Education
Energy
Technology
Semiconductor
The malicious RTF files in question leverage a very specific shellcode to drop and execute the malicious payload, as well as a decoy document. Decoy documents are legitimate benign documents that are opened after the malicious payload is delivered, thus ensuring that the victim does not become suspicious because their expected document opened as expected.
Two samples were found to include the decoy document show in Figure 1.
The title of the document roughly translates to “Ministry of Communications & Departments Authorities Empty Sites and Hosted Public Works Source Clearance Photos”. The use of traditional Chinese indicators the target likely residing in either Taiwan, Hong Kong, or Macau. However, based on the Taiwanese subject matter in this document, we can safely come to the conclusion that the intended victim was of Taiwanese origin. These samples delivered an updated version of the IsSpace malware family, which was discussed previously in a watering hole attack targeting an aerospace firm. IsSpace is an evolved variant of the NFlog backdoor, which has been used by DragonOK in the past.
Figure 1 Taiwanese decoy document
Two other samples were identified that used a Tibet-themed decoy document. The document in question (Figure 2) appears to be an internal newsletter from the Central Tibetan Ministry, as suggested by the logo used as well as the content of the document itself. This document indicates that the malware may have been targeted towards an individual that is interested in Tibetan affairs. These particular samples were unique in that they delivered the TidePool malware family that we reported on in May of 2016. We have not previously observed DragonOK using TidePool in attacks.
We also identified an additional sample using decoy targeting Taiwanese victims (Figure 3), which deployed a newer sysget sample.
Figure 3 Taiwanese-targeted decoy document
Other new samples associated with this group used a Russian language decoy document (Figure 4.) The decoy document in question discusses the GOST block cipher, which was created by the Russian government in the 1970’s. The combination of Russian language and Russian-specific subject matter indicates that the intended victim speaks Russian and may be interested in encryption. Like the previously discussed Tibetan decoy documents, these samples also delivered the TidePool malware family.
Figure 4 Russian decoy document discussing the GOST block cipher
Finally, multiple samples used a traditional Chinese language decoy document that discussed a subsidy welfare adjustment program. The use of traditional Chinese indicators the target likely residing in either Taiwan, Hong Kong, or Macau. Similar to other attacks witnessed, a variant of the sysget malware family is installed by these files.
Figure 5 Decoy document discussing subsidy welfare adjustment program
Malware Deployed
In looking at the various malware samples used in attempted attacks, the following four families were identified:
Sysget version 2
Sysget version 3
TidePool
IsSpace
We broke the sysget classification into multiple variants when we found that a number of changes have been made since our April 2015 report. Major distinctions between the versions of sysget include the following:
Sysget version 2
Removed support for persistence on Windows XP
Reworked the URIs used for network communication
Added additional layers of encryption for network communication and stored configuration files
Switched from RC4 to AES-128
Sysget version 3
Numerous anti-debug and anti-vm procedures added
Encrypted URIs in network communication with an initial static key
In addition, we observed a sysget version 4 that was discovered in another sample during our research. This version is not attributed to a specific attack against an organization.
Indicators of compromise related to sysget version 4 and other samples not directly attributed to specific attacks may be found in the Appendix of this blog post. Additionally, more information about the various sysget variants may also be found in the Appendix.
The TidePool samples encountered are consistent with the samples previously discussed. I encourage readers to view our previous blog post to learn more about the intricacies of this particular malware family.
The IsSpace malware sample, however, looks to have been updated since last we wrote on it. While the available commands from the command and control (C2) server remains the same, the URI structure of the network communication has been modified. Additionally, the installation routine for this malware family has been updated to be far less complex than previous discussed versions, favoring PowerShell to set persistence and forgoing the previously used side-loading technique. A more detailed analysis of the new instances of IsSpace may be found at the end of this blog post in the Appendix.
Infrastructure
A number of unique domains were employed by the various Trojans used in these attacks. For the numerous instances of sysget we observed, the following domains were observed for their C2:
kr44.78host[.]com
gtoimage[.]com
gogolekr[.]com
All of the above domains have Chinese WHOIS registrant details. Additionally, the gotoimage[.]com and trend.gogolekr[.]com are both registered to the same registrant and resolve to the same netblock of 104.202.173.0/24.
The instances of TidePool identified communicated with the following C2 servers:
wikaba[.]com
ssl443[.]org
skywave[.]top
These domains did not have many definitive relations with the sysget C2 servers except for cool.skywave[.]top, which shared a unique registrant email with the sysget C2 server of trend.gogolekr[.]com. Additionally, the geographic region of the resolved IPs was consistent with the previous set, as they all resolved to various regions in southeast Asia. Specifically, the domains resolved to China, Korea, and Taiwan in the past six months.
The IsSpace samples resolved to the following domains:
dppline[.]org
matrens[.]top
These domains had no apparent connections to the previously discussed C2 servers, other than the fact that they resolved to Korea and Hong Kong respectively. Additionally, the registrar of ‘Jiangsu Bangning Science and technology Co. Ltd.’ was used for a large number of domains. A full graph of the relations between the various attacks is shown in Figure 6.
Figure 6 Relationships between attacks
Conclusion
The DragonOK group are quite active and continue updating their tools and tactics. Their toolset is being actively developed to make detection and analysis more difficult. Additionally, they appear to be using additional malware toolsets such as TidePool. While Japan is still the most-targeted region by this group, they look to be seeking out victims in other regions as well, such as Taiwan, Tibet, and Russia.
Palo Alto Network customers are protected against this threat in the following ways:
Malware families are tagged in AutoFocus via a variety of tags (TidePool, NFlog, Sysget)
The following IPS signatures detect malicious network traffic:
IPS signature 14365 (IsSpace.Gen Command And Control Traffic)
IPS signature 14588 (Suspicious.Gen Command And Control Traffic)
IPS signature 13574 (NfLog.Gen Command And Control Traffic)
IPS signature 13359 (Nflog.Gen Command And Control Traffic)
All samples are appropriately marked malicious in WildFire
Appendix
CVE-2015-1641 Exploit and Shellcode
This particular group uses a very specific shellcode payload when exploiting CVE-2015-1641. This CVE is memory corruption vulnerability which allows for arbitrary code execution in various versions of Microsoft Office, including 2007, 2010, and 2013.
The shellcode begins by dynamically loading a small number of API functions from kernel32. A number of hashes are included that represent function names, which have a rotate right 7 (ROR7) operation applied against them before being XORed against a key of “\x10\xAD\xBE\xEF”. The ROR7 operation is a very common technique in shellcode to obfuscate what functions are being called. The author added the XOR operation to add another layer of obfuscation.
Figure 7 API function hashes contained in shellcode
After the shellcode loads the necessary API functions, it proceeds to seek out a number of markers that will mark the beginning and ending of both an embedded malicious payload, as well as a decoy document.
The malicious executable is marked with a starting point of 0xBABABABABABA and an end marker of 0xBBBBBBBB. The decoy document is found immediately after the end of the malicious payload, and has an end marker of 0xBCBCBCBC. Both executables are encrypted with a 4-byte XOR key. Should the original data contain 0x00000000, it will not have the XOR applied against it.
The malicious payload is XORed against a key of 0xCAFEBEEF and the decoy document is XORed against 0xBAADF00D. The following script may be applied against the RTF document to extract both the malicious payload and the decoy:
raise Exception(“Unable to find correct offsets for document.”)
return[exe_data,doc_data]
def main():
input_file=sys.argv[1]
input_fh=open(input_file,‘rb’)
input_data=input_fh.read()
input_fh.close()
exe,doc=extract(input_data)
filename=“{}.exe”.format(input_file)
output_file=open(filename,‘wb’)
output_file.write(exe)
output_file.close()
print“[+] Wrote {}”.format(filename)
filename=“{}.doc”.format(input_file)
output_file=open(filename,‘wb’)
output_file.write(doc)
output_file.close()
print“[+] Wrote {}”.format(filename)
iflen(sys.argv)==2and__name__==“__main__”:
main()
When both files are decrypted, they are written to the following location in the %TEMP% directory:
../..exe
../..doc
Note the initial ‘..’, which represents the parent directory of %TEMP%. This coupled with the unusual names of ..exe and ..doc make this particular shellcode very unique, which is one way we have attributed these samples to the same group. After the samples have been written, they are executed via calls to WinExec.
Sysget v2 Analysis
One of the fundamental changes witnessed in the second iteration of sysget is removing support for Windows XP and lower. Other changes include modifications to the URIs used for network communication.
Like the original version of sysget, sysget v2 still uses a named event of ‘mcsong[]’ to ensure a single instance is running at a time. It proceeds to make attempts at copying itself to the %STARTUP%/notilv.exe path. However, it uses COM objects to perform this action that is not available in Windows XP, which prevents the malware from installing itself to this location. While the remainder of the malware operates as expected, it will not survive a restart of the system.
Sysget proceeds to make an attempt at reading the following configuration file. This filename and path has changed since the original version, and is consistent in the subsequent versions.
%APPDATA%/vklCen5.tmp
This configuration file holds both a unique victim identifier, as well as a key that is used to encrypt HTTP traffic. It is encrypted using the AES-128 encryption algorithm, using a static key of ‘734thfg9ih’. Using AES-128 is a change from the previous version, where RC4 was used for all encryption operations. The following Python code may be used to decrypt this file:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import sys
import base64
from wincrypto import CryptCreateHash,CryptHashData,CryptDeriveKey,CryptDecrypt
def decrypt(data,original_key):
CALG_AES_128=0x660E
CALG_MD5=0x8003
md5_hasher=CryptCreateHash(CALG_MD5)
CryptHashData(md5_hasher,original_key)
key=CryptDeriveKey(md5_hasher,CALG_AES_128)
decrypted_data=CryptDecrypt(key,data)
returndecrypted_data
arg=open(sys.argv[1],‘rb’).read()
print repr(decrypt(arg,‘734thfg9ih’))
When executed against an example configuration file, we see the following output, which includes the two pieces of data noted previously:
The encryption of this configuration file is a new feature that was not present in the original version of sysget.
If this file is not present on the system, the malware will attempt to retrieve the necessary information via a HTTP request. The following request is made to the remote command and control server. Note that the full URI is statically set by the malware sample.
The server responds with the following data, encrypted using the same technique previously described with a static key of ‘aliado75496’. Once decrypted, we see the following example data being sent back to sysget:
gh1443717133\n1059086204\n
The first string is used as a key for all subsequent network communication. The second string is treated as a unique victim identifier. This data is encrypted using the key of ‘734thfg9ih’ and written to the %APPDATA%/vklCen5.tmp file.
After this information has been obtained, the malware proceeds to enter its command and control loop. An HTTP request such as the following is made to the remote server. Note that the ‘mid’ GET variable holds the MD5 hash of the previously obtained victim identifier. The remaining data in the URI is hardcoded.
The response is encrypted using the unique key that was obtained previously. Should the response contain ‘Fatal error’ unencrypted, no further actions are taken by the malware sample. Once decrypted, the response may have one of the following two choices, and their accompanying purpose. Alternatively, if a raw command is provided, the malware will execute it and return the results.
Command
Description
goto wrong “[file_path]”;\n
Read a specific file and return its contents.
goto right “[filename]” “[identifier]”
Write a given file. The identifier is used to retrieve the file’s contents in a subsequent HTTP request.
When the ‘goto wrong’ request is made, a HTTP POST request is made to the following URI. In the following URI, the ‘list’ parameter contains the MD5 hash of the victim’s identifier.
The contents of this POST request contains the victim’s identifier, as well as the file’s contents encrypted with the unique key. The first 50 bytes are reserved for the victim identifier, as shown below:
If the ‘goto right’ command is used, the malware will make a subsequent request to the following URI. The ‘cache’ variable holds the unique identifier that was provided in the ‘goto right’ command.
Once the file contents are obtained, they are written to the specified filename in the %STARTUP% folder.
When a raw command is received, the malware will upload the results to the following URI via a POST request:
/index.php?type=register
An overview of the network communications exhibited by sysget version 2 can be seen in the figure below.
Figure 8 Sysget version 2 command and control flow
Sysget v3 Analysis
Some of the biggest changes witnessed in version 3 of sysget includes numerous anti-debug and anti-vm detections added, as well as the encryption of the URIs used for network communication.
When the malware initially executes, it performs the following checks to ensure it is not being debugged and not running in a sandbox or virtualized environment.
Should these checks return false, the malware proceeds to enter its installation routine. The malware originally copies itself to a temp file in the %TEMP% directory with a filename prefix of ‘00’. It proceeds to append 4194304 bytes of randomly chosen data to the end of this file. The increased filesize may have been added by the author in an attempt to thwart sandboxes that impose filesize limits on what is saved and/or processed. Finally, the malware copies the original file from the tmp path to the %STARTUP%/winlogon.exe path using the same technique witnessed in version 2. Sysget then writes a batch script in the %TEMP% folder with the following contents, cleaning up the original files and spawning the newly written winlogon.exe executable:
After installation, sysget will attempt to read the same %APPDATA%/vklCen5.tmp file as witnessed in the previous variant. A number of strings within the malware, including the ‘734thfg9ih’ key used to encrypt this file, have been obfuscated via a single-byte XOR of 0x5F.
Similar to previous versions, should this vklCen5.tmp file not be present on the victim machine, it will make an external HTTP request to retrieve the necessary information. The following request is made by the malware. Readers will notice that the URI has changed from previous versions in a number of ways. This version of sysget looks to always make requests to 1.php, which is hardcoded within the malware itself. Additionally, all HTTP URIs in this version of sysget are encrypted. The initial GET request made to retrieve the victim identifier and unique key is encrypted with a key of ‘Cra%hello-12sW’. The subsequent response containing this information is then decrypted using a key of ‘aliado75496’, which is consistent with previous versions.
This URI is consistent with the previous sysget variant. It would seem the authors simply have added this layer of encryption to hinder efforts to block the malware via network-based detections.
After this initial request to retrieve the victim identifier and unique key, sysget enters its command and control loop. This process is consistent with the previous version, but simply has the extra layer of encryption used for the URIs.
Sysget v4 Analysis
The fourth variant of sysget is nearly identical to the third variant. However, the main difference lies in the URIs used for network communication. In addition to the expected encryption of the URIs, this variant also mangles the base64 encoding that is performed afterwards. The following Python script may be used to de-obfuscate the base64 URI found in this variant:
Additionally, the C2 URI changes in this variant, from 1.php to 5.php
IsSpace Analysis
When initially run, IsSpace will create a unique event to ensure a single instance of the malware is running at a given time. This event name appears to be unique per the sample, as multiple samples contained unique event names. The following event names have been observed in the samples that were analyzed:
e6al69MS5iP
v485ILa3q5z
IsSpace proceeds to iterate over the running processes on the system, seeking out the following two process substrings:
uiSeAgnt
avp.exe
The uiSeAgnt string may be related to Trend Micro’s solutions, while avp.exe most likely is related to Kaspersky’s anti-malware product.
In the event uiSeAgnt is identified, the malware will enter its installation routine if not already running as ‘bfsuc.exe’ and proceeds to exit afterwards. Should avp.exe be identified, the malware enters an infinite sleep loop until a mouse click occurs. After this takes place, the malware proceeds as normal.
The malware then determines if it is running under Windows XP. In the event that it is, it will make a HTTP GET request to http://www.bing.com, presumably to ensure network connectivity.
If the malware is not running on Windows XP, it will attempt to obtain and decrypt any basic authentication credentials from Internet Explorer. This information is used in subsequent HTTP requests in the event a 407 (Proxy Authentication Required) or 401 (Unauthorized) response code is received during network communication.
IsSpace will then enter its installation routine, where it will first copy itself to the %LOCALAPPDATA% folder with a name of ‘bfsuc.exe’. It then sets the proper registry key for persistence by executing the following PowerShell command:
The malware then makes an initial HTTP POST request to the configured C2 server. It will make this request to the ‘/news/Senmsip.asp’ URI. The POST data is XORed against a key of “\x35\x8E\x9D\x7A”, which is consistent with previous versions of IsSpace and NFlog. Decrypted, the POST data reads “01234567890”. The C2 server in turn will respond with the victim’s external IP address.
Figure 10 Initial IsSpace beacon
IsSpace then spawns two threads that will make HTTP requests to the following URIs:
/news/Sennw.asp?rsv_info=[MAC_ADDRESS]
/news/Sentire.asp?rsv_info=[MAC_ADDRESS]
The ‘Sennw.asp’ POST requests that are made contain collected victim information. They, like other information sent across the network, are encrypted using the previously mentioned 4-byte XOR key. When decrypted, we are provided with information such as the following:
The information, delimited via ‘#%#’, is as follows:
Value
Description
60-F8-1D-CC-2F-CF
MAC address
172.16.95.1
External IP collected previously
172.16.95.186
Internal IP address
WIN-LJLV2NKIOKP
Hostname
Win7
Windows version
English(US)
Language
2016-12-20 16:27:12
Timestamp
Active
Malware status. May also be ‘Sleep’
xp20160628
Potential campaign identifier
IsAdmins / False
User admin status
The malware is expected to return one of the following two responses to this HTTP request:
Active
Slient (Note the typo)
In the event the response of Slient is received, the malware will stop sending out HTTP requests to the ‘Sentire.asp’ URI. Conversely, if the malware is set to the ‘Sleep’ status and the ‘Active’ response is received, it will begin the ‘Sentire.asp’ requests once more.
The requests to ‘Sentire.asp’ act as the main C2 loop, requesting commands from the remote server. The commands are consistent with previously observed instances of IsSpace, however, the URIs have been modified.
