The Nansh0u Campaign – Hackers Arsenal Grows Stronger

During the past two months, the Guardicore Labs team has been closely following a China-based campaign which aimed to infect Windows MS-SQL and phpMyAdmin servers worldwide. We have taken a deep look into the inner workings of the campaign – the tools in use, the vulnerabilities exploited and the extent of damage caused.

Breached machines include over 50,000 servers belonging to companies in the healthcare, telecommunications, media and IT sectors. Once compromised, the targeted servers were infected with malicious payloads. These, in turn, dropped a crypto-miner and installed a sophisticated kernel-mode rootkit to prevent the malware from being terminated.

Guardicore Labs witnessed the release and deployment of 20 different payload versions throughout the campaign. We contacted the hosting provider of the attack servers as well as the issuer of the rootkit certificate. As a result, the attack servers were taken down and the certificate was revoked.

The Nansh0u campaign is not a typical crypto-miner attack. It uses techniques often seen in APTs such as fake certificates and privilege escalation exploits. While advanced attack tools have normally been the property of highly skilled adversaries, this campaign shows that these tools can now easily fall into the hands of less than top-notch attackers.

In this post, we describe the attacks in detail and provide a complete IoC repository for the campaign, including a script to detect infected machines.

From Unusual Incidents to Full Investigation

In the beginning of April, three attacks detected in the Guardicore Global Sensor Network (GGSN) caught our attention. All three had source IP addresses originating in South-Africa and hosted by VolumeDrive ISP (see IoCs). The incidents shared the same attack process, focusing on the same service and using the same breach method and post-compromise steps.

Looking for more attacks with a similar pattern, we found attacks dating back to February 26, with over seven hundred new victims per day. During our investigation, we found 20 versions of malicious payloads, with new payloads created at least once a week and used immediately after their creation time.

Figure 1: Payloads creation timeline

This timeline, combined with a set of five attack servers and six connect-back servers, suggests an established process of continuous development which was well thought of by the attackers.

Having access to the attacker’s infrastructure, we were able to monitor the relevant file servers and draw insights on the campaign’s size and scope. The following graph shows how the number of successfully-infected machines doubled within a timespan of one month.

Figure 2: Overall number of downloads from the attacker’s file servers. Within one month, hit counts have doubled.

Attack Overview: MS-SQL Command Execution

Each attack started with a series of authentication attempts to a MS-SQL server, eventually leading to a successful login with administrative privileges.

Figure 3: A successful login seen in Guardicore’s Global Sensors Network (GGSN)

Then, a sequence of MS-SQL commands was executed to accomplish the following (numbers in brackets indicate the relevant lines of code):

• Configure server settings to allow a “smooth” and errorless attack flow [1];
• Create a Visual-Basic script file in c:\ProgramData\2.vbs [2];
• Execute this script and download two files to c:\ProgramData over HTTP [3]; and
• Run the two files in one command-line [4].

Attack Infrastructure

The attacker’s servers were all running HFS – HTTP File Server – serving files of different types. One text file included the string Nansh0u, on which we based the campaign’s name.

The attacker’s infrastructure contained all the modules required for a successful, end-to-end attack on MS-SQL servers:

1. Port scanner
2. MS-SQL brute-force tool
3. Remote Code Executor

Figure 4: the attack flow of the Nansh0u campaign

Port Scanner – Find MS-SQL Servers

The port scanner used by the attacker had been known since 2014. Our attacker used it to detect MS-SQL servers by scanning IP addresses and checking whether typical MS-SQL ports were open. Scanning results were then fed to the brute-force module.

Figure 5: List of ports and a log file of the port scanner. The attacker’s logs show scans dating back to early March.

Brute-Force Tool – Compromise Victims

The tool attempts to login to each MS-SQL server using tens of thousands of common credentials. Once authentication succeeds – the server’s address, username and password are saved to a file for future use.

Figure 6: Matching credentials in Guardicore Centra and the attacker’s dictionaries

The dictionaries of common credentials used by the attacker can be found in the campaign’s IoCs repository.

Code Execution Module – Infection Time

By running the port scanner and the bruteforce tool, the attacker gained a list of breached servers – IP addresses, ports, usernames and passwords. The next step was to login to the victims and infect the machines.

On the HFS, in a folder named chuan – Chinese for infect – we found two interesting components. The first was a script named Mssql.log. The script’s commands were the exact ones we saw in the incidents that triggered our research.

The second file was an executable named Usp10.exe. This program receives a server’s address and credentials as well as the contents of Mssql.log. Its functionality is straightforward: it logs into the breached server and executes the Mssql.log script, proceeding with the attack on the victim side.

Usp10.exe is the attack module responsible for writing and executing the downloader script (2.vbs) on the MS-SQL victims. Once the MS-SQL script is done running on the victim machine, the malicious payload is executed.

Exploits and Payloads: The Files Executed on the Victim Machine

In all the attacks we have seen as part of this campaign, the attacker executed a command line with two executables:

This command executes a privilege escalation exploit that runs the malicious payload with SYSTEM privileges. In the attacker’s arsenal are two versions of the PE exploit, apexp.exe and apexp2012.exe, and many payload versions (see Figure 1 and the full list of IoCs).

Privilege Escalation Exploits

apexp.exe and apexp2012.exe are two exploits of a known privilege escalation vulnerability (CVE-2014-4113). Passing any program to these executables will run it with SYSTEM privileges.

apexp.exe is known as Apolmy exploit and it affects both Desktop and Server versions of Windows (XP to 8.1 and 2003 to 2012 R2, respectively). This is a weaponized exploit with production-level code. apexp2012.exe, on the other hand, resembles more of a proof-of-concept than an operational exploit, and is designed to work on Windows 8.1. We found the latter available for download on a Chinese forum seemingly used as a hacker-community platform.

While both versions use the same vulnerability, they execute kernel-mode code for different purposes. The Apolmy version copies the SYSTEM process access token to its own process. With that token, the exploiting process runs the payload with full control over the victim machine.

The second version uses a method popularized by Cesar Cerrudo. Here, the exploit adds the SeDebugPrivilege to the token. Using this Windows privilege, the attacking exploit injects code into the winlogon process. The injected code creates a new process which inherits winlogon’s SYSTEM privileges, providing equivalent permissions as the prior version.

Payloads: Droppers of Rootkits and Miners

We collected 20 payload samples from both the attacker’s servers and Guardicore Global Sensor Network (GGSN). Each payload is in fact a wrapper and has several functionalities:

• Execute the crypto-currency miner;
• Create persistency by writing registry run-keys;
• Protect the miner process from termination using a kernel-mode rootkit;
• Ensure the miner’s continuous execution using a watchdog mechanism.

The payloads spawn one of two processes – dllhot.exe or canlang.exe, depending on the payload – which mine a privacy crypto-currency named TurtleCoin for four different mining pools.

Kernel-Mode Driver

Many of the payloads drop a kernel-mode driver, named randomly and placed in AppData/Local/Temp. Its compile time suggests that it had been created in 2016. Nevertheless, most AV engines do not detect the driver file as malicious.

We found that the driver had a digital signature issued by the top Certificate Authority Verisign. The certificate – which is expired – bears the name of a fake Chinese company – Hangzhou Hootian Network Technology. Guardicore Labs has contacted Verisign and provided them with the relevant details, which resulted in the certificate revocation.

Figure 7: Driver’s digital signature issued by Verisign

Why are signed drivers exceptional?

Kernel-mode drivers are executable files run within the operating system’s kernel. As such, they have high-privileged access to sensitive data structures and resources.

Since Windows 10 and Windows Server 2016, Microsoft only allows Microsoft-signed drivers to run in kernel mode. To receive such a signature, developers must provide Microsoft a version of their driver and pass numerous tests.

The chances of a malicious driver being signed are very low.

This would have been less awkward, had the driver not been packed and obfuscated. Unlike many other malicious drivers, this driver is protected and obfuscated with VMProtect, a software tool that attempts to frustrate reverse engineers and malware researchers.

The driver is designed to protect processes and prevent the user from terminating them. It creates a device named SA6482, allowing processes to communicate with it. The device receives process IDs (PIDs) meant to be protected – in our case, the miner PID.

The driver protects the process by registering a callback on the Process and Thread object types. These callbacks are triggered with every access to the protected process or any of its threads and allows drivers to modify the access rights given in each access attempt.

The driver itself contains additional rootkit functionality such as communicating with physical hardware devices and modifying internal Windows process objects that are unused by this particular malware.

You Don’t Have to Be a Nation-State to Own Top-Level Weapons

The infection process uses advanced technological capabilities. apexp.exe, for instance, takes advantage of a kernel-mode vulnerability to execute code with SYSTEM privileges. It was used in a past Chinese APT by a highly-skilled adversary to target various companies.

Another example is the driver dropped by the different payloads. Obtaining a signed certificate for a packed driver is not at all trivial and requires serious planning and execution. In addition, the driver supports practically every version of Windows from Windows 7 to Windows 10, including beta versions. This exhaustive coverage is not the work of a hacker writing a rootkit for fun.

These advanced elements are opposed to several odd SecOps decisions taken by the attacker. To begin with, attackers usually do not keep their whole infrastructure on a file server with no activated authentication controls. Logs, victims lists, usernames, binary files – we had them all in a mouse click. In addition, all binary files had their original timestamps; an experienced malware author would have tampered with those to complicate the analysis process.

This campaign was clearly engineered from the phase of IPs scan until the infection of victim machines and mining the crypto-coin. However, various typos and mistakes imply that this was not a thoroughly-tested operation. For example, we found a mismatch in two versions of the lcn.exe payload. Both were running the same miner but with swapped command-line arguments, suggesting that the first one was providing the wallet address in an incorrect position.

Last but not least, many of the programs found on the server are written in EPL – Easy Programming Language. EPL is a proprietary, Chinese-based programming language designed for rapid application development. The decision to write a major part of the infrastructure in a relatively esoteric language is unusual.

Advanced vulnerability exploitations are not a common sight in the repertoire of crypto-mining attacks. Similarly, obfuscated kernel code usually does not come bundled in campaigns aiming for altcoin. It appears that tools, which until recently belonged to nation state-level hackers, are today the property of even common criminals.

We can confidently say that this campaign has been operated by Chinese attackers. We base this hypothesis on the following observations:

• The attacker chose to write their tools with EPL, a Chinese-based programming language.
• Some of the file servers deployed for this campaign are HFSs in Chinese.
• Many log files and binaries on the servers included Chinese strings, such as 结果-去重复 (“duplicates removed”) in logs containing breached machines, or 开始 (“start”) in the name of the script initiating port scans.

Detection & Prevention

What enables this attack on Windows MS-SQL servers in the first place, is having weak usernames and passwords for authentication. As trivial as it may sound, having strong credentials is the difference between an infected and a clean machine.

If you expose database servers to the internet, you should minimize the danger of any possible compromise. Database vendors typically provide hardening guides; Microsoft’s guide for SQL server is pretty easy to implement. In addition, you should separate internet-exposed servers from internal servers as much as possible by segmenting your network and limiting the blast radius of vulnerable devices.

We have released an open source PowerShell script to provide defenders with a simple way to detect infected machines. For more details and instructions check our repository.

Conclusion

The Nansh0u campaign is not another run-of-the-mill mining attack. It serves as a case study for a thoroughly-planned attack scheme which incorporates various modules and progressive tools. This suggests that cyber weapons are becoming readily available, and not only to nation-state organizations.

This campaign demonstrates once again that common passwords still comprise the weakest link in today’s attack flows. Seeing tens of thousands of servers compromised by a simple brute force attack, we highly recommend that organizations protect their assets with strong credentials as well as network segmentation solutions.

IoCs

See our repository for the complete list of IoCs.

IPs

Hashes

• 685f1cbd4af30a1d0c25f252d399a666 xfa3BEB.tmp
• c5c99988728c550282ae76270b649ea1 DesktopLayer.exe
• 70857e02d60c66e27a173f8f292774f1 apexp.exe
• 68862438fae4c937107999ff9d8ff709 apexp2012.exe
• 3ccb047b631ed6cab34ef11ccf43e47f sisr8Aj.sys
• 1f9007fbf6a37781f7880c10fc57a277 dllhot.exe
• 5899fde33dc7cf35477b998c714454eb dllhot.exe
• 1ad8d0594f9baffe332ccfefb25475df apexd.exe
• 1873944ee02b9e68af2d4997da5e5426 avast.exe
• e6b9054759e4d2d10fcf42d47d9e9221 avast.exe
• 1770c9bf4a41c5115425d76df052b6a2 killtrtl.exe
• 2d740789efd7f16bff42651ae69b0893 kvast.exe
• 876e504b8ddb231d8eeaefa2b9e38093 kvast.exe
• e27490ae6debe3be25794b4dcbaa8e24 gold.exe
• 1f0606c722693c9307ebf524c53f3375 kvast.exe
• 19594b72fc16539a5122217e6e3bb116 avast.exe
• 6dd0276e1f66f672e8c426c53b3125a5 rock.exe
• 82e55177fa37a34dca1375d542c06ac0 rock.exe
• 7c4b1ebba507bc2d0085278d28a899b2 rocks.exe
• c06c3a79f70bfd5474bab8a13acdb87e rocks.exe
• 8ca92722641c73758e5a762033e09b11 lt.exe
• 9887d95973ac89c802571c2bbd346cbf canlang.exe
• 252d1721335108cdc643d36c40d4eaf6 lolcn.exe
• b9161d07b4954d071ae0f26c81e56807 lolcn.exe
• 3425fc4d60a7401c934c73a12a30742b lcn.exe
• 93610bed2e15e2167a67c0e18fee7e08 lcn.exe
• b79f7a7947cb7e9ea1f0d7648e765cee tl.exe
• df4bacb064a4668e444fd67585ea1d82 tls.exe

File Paths

Attack Script

• C:\ProgramData\2.vbs attack script

Exploits

• C:\ProgramData\apexp.exe
• C:\ProgramData\apexp2012.exe

Files dropped by payloads

• cfg.bat
• canlang.exe
• dllhot.exe