In the last few months Guardicore Labs has been investigating multiple attack campaigns conducted by an established Chinese crime group that operates worldwide. The campaigns are launched from a large coordinated infrastructure and are mostly targeting servers running database services. By now we were able to identify three attack variants – Hex, Hanako and Taylor – targeting different SQL Servers, each with its own goals, scale and target services. This report covers the attackers’ infrastructure, attack variants and how the victims are used for both profit and further propagation.
Scope of attacks
We started off by investigating a single MS SQL Server attack that made use of an unknown binary against servers monitored by the Guardicore Global Sensor Network (GGSN), a network of deception servers deployed in multiple data centers worldwide. Looking at the attack logs of our sensors, we discovered that this specific attack started nine months ago in March of this year. Over the summer that single attack has grown into thousands of attacks per day targeting MS SQL Server and MySQL services across multiple GGSN sensors. The attackers used compromised machines for cryptocurrency mining, DDoS and for implanting thousands of Remote Access Trojans (RATs).
The compromised machines are mostly based in China but we’ve also detected victims in Thailand, the U.S., Japan, etc. Every source machine attacks only a few IPs, enabling the attacker to easily go under the radar. Similarly to Bondnet, which was discovered by Guardicore Labs in May of this year, victims are re-purposed to help the attackers, making the tracing almost impossible. Compromised machines are nearly all used by the attacker for about a month and then rotated out of use.
So far, we were able to identify three different campaigns launched from this infrastructure. The campaigns differ mostly in target goals. While Hex focuses on installing cryptocurrency miners and remote access trojans and Taylor installs a keylogger and a backdoor, Hanako uses its victims to build a DDoS botnet. So far, we have monitored hundreds of Hex and Hanako attacks and tens of thousands of Taylor attacks each month.
The attackers use compromised victim machines for a variety of infrastructure tasks. Machines are repurposed for scanning, launching attacks, hosting malware executables and acting as C&C servers. In general, we can describe the attacks using three simple steps: scanning, attacking and initial implant.
The scan machines are responsible for scanning lists of subnets and creating ‘hit lists’ of IPs and credentials. The attackers choose a large set of IP ranges and look for machines that run different services, such as HTTP web servers, MS SQL Server, ElasticSearch management nodes, etc.
Once the scanners finish building the “hit list”, the list is sent to the attacker machines that use it to get an initial foothold in the servers by brute forcing MS SQL and MySQL databases. Once inside, they’ll execute a series of predefined SQL commands to gain full control of the victim. For example, create new users for persistent access and evade audit logs.
The attackers host parts of their campaign, such as the RAT, on separate file servers to make sure their infrastructure is modular and to reduce dependence on every server. These servers run either an FTP server or HFS (HTTP File Server) which is a niche web server mainly used to serve hosted files.
The servers are used for downloading additional attack tools after the initial dropper runs. In the Taylor attacks the attacker downloads the files from two domains, down@mys2016@info and js@mys2016@info, both registered in March 2017. With the other two attack variants (Hex and Hanako), each attacking machine uses a unique file server per attack, limiting the malicious traffic sent to each compromised machine.
As seen in multiple examples, brute force and old vulnerabilities can get attackers a long way. Most of the attacks target MS SQL Server, MySQL and other popular services and use brute force password attempts to break in.
Many administrators of the MS SQL Server installs don’t bother hardening the database besides using a password. This means that once the attacker has breached the SQL database, there is a huge variety of methods that they can use for executing code while avoiding auditing. Exhaustively documented back in 2013 and weaponized in 2017, the SQL Servers complex engine allows for code execution in multiple vectors, all used by our attacker. We’ll look at what happens after a successful breach.
After login is successful, the attackers use xp_cmshell, a variety of stored procedures and OLE automation, all documented in this article, to upload their first set of tools.
The attackers use a variety of droppers, which usually establish persistency by creating a backdoor user and opening the Remote Desktop port. In the next stage, a cryptocurrency miner, Remote Access Trojan or a DDoS bot is downloaded from a short lived FTP or HTTP server hosted on other compromised machines.With all variants, to establish persistent access to the victim database, the attacker creates backdoor users in the database.
Later in the attack, the attacker stops or disables a variety of anti-virus and monitoring applications by running shell commands. The anti-virus targeted is a mixture of well known products such as Avira and Panda Security and niche software such as Quick Heal and BullGuard. As a final step, the attackers attempt to cover their tracks by deleting any unnecessary registry, file and folder entries using batch files and VB scripts.
The malware binaries also attempt to hide themselves using a variety of methods. These include using a fake MFC user interface and abnormally sized binaries (a few binaries weighed over 100MB, containing large quantities of junk data).
Hex & Hanako
Both Hex and Hanako variants use the exact same MS SQL Server attack flow with the same order of commands and parameters.
Both Hex and Hanako download unique attack configuration files, creating an identical scheduled task to run the same unique binary. In addition, the exact same antivirus products are targeted and killed and the same users are created.
Hex is named this way because it uses numerous variations on Hex.exe, such as Hex8899.exe, HexServer.exe, etc. Hanako is named after the backdoor user it adds to compromised databases.
The trojan used by Hex is written in C++ and most commonly referred to as netsyst96.dll (with a variety of aliases in different attacks). It uses keylogging, screen and microphone capture to extract information from victim machines and has plugin abilities to download and execute additional modules. To avoid being detected, the netsyst96.dll imitates Kugou Player, a popular Chinese music streaming service and comes bundled with a fully functional GUI.
Taylor uses the same techniques used by Hex and Hanako to breach the server and achieve persistent access to the victim machine but that’s where the similarity ends. This variant made far more noise – since March we’ve detected over 80,000 attack attempts hitting the GGSN. Named after a Taylor Swift image found on the malware servers, this campaign has been reported earlier this year as a standalone attack, unrelated to the other attacks.
The Taylor attack is distinct in multiple ways. After the attackers successfully log in to the SQL database, they use WMI methods to download a list of processes to kill from www@cyg2016@xyz/kill.html. Then using www@cyg2016@xyz/test.html, the script pulls another URL from which it downloads a malware binary. In addition, a backdoor related to the 2016 Mirai attack campaign is downloaded from js@mys2016@info. Last, a keylogger is downloaded from down@mys2016@info, hidden in a Taylor Swift image.
Unlike the Hex and Hanako attacks, Taylor uses the same domain names over time and does not change IP addresses often. Taylor’s attack script is far more cautious, the attackers try to blur their activity by sending most of the queries encoded in hex and storing all references to the servers in HTML pages downloaded during the attack.
Prevention and Mitigation
The attacks target database services on both Windows and Linux machines. From what we’ve seen, the attackers often compromise public and private cloud deployments without chasing any specific domain. This is shown in their frequent scanning of Azure and AWS public IP ranges (which are publicly available) while looking for potential victims.
While defending against this type of attacks may sound easy or trivial – “patch your servers and use strong passwords” – we know that “in real life” things are much more complicated. The best way to minimize your exposure to campaigns targeting databases is to control the machines that have access to the database. Routinely review the list of machines that have access to your databases, keep this list to a minimum and pay special attention to machines that are accessible directly from the internet. Every connection attempt from an IP or domain that does not belong to this list should be blocked and investigated.
Also, assuming that at some point the database will be breached, you are advised to follow the databases hardening guides. Both MySQL and Microsoft provide hardening guides, here (MySQL) and here (SQL Server).
An Ongoing Threat
Working on this campaign felt much like an escape room experience where one clue leads to another. The initial MS SQL Server attack led us to a series of malware binaries from where we uncovered a sprawling attack infrastructure. Next, we discovered multiple attacks targeting different services that have been using the victim’s compute power for mining, DDoS attacks and exfiltrating sensitive data.
Ample evidence suggests that the attack group is based in China. Comments in Chinese are routinely found in the code, the majority of victims are based in Mainland China, the Trojan RAT disguises itself as a popular Chinese program and configuration files list email addresses from popular Chinese providers.
Determining the scope of the campaign was quite a challenge. The group has shown an ability to generate over 300 unique binaries per each attack and to constantly rotate their attacking machines and domains, while manipulating thousands of victims as part of their attack infrastructure.
We intend to keep track of this group and when something interesting comes up, we will share it. Stay tuned.
Appendix – IOCs
File and Log Servers