Cyber Threats Unveiled: SSH Scanning and XorDDos Propagation

Executive Summary

While reviewing SSH scanning activity, it was identified that a block of approximately 50 IP addresses were responsible for 42% of scanning activity over a two-month period. These IP addresses were all assigned to ChinaNet Jiangsu Province Network and fall within a /23 CIDR block.

Following further investigation, it was found that this scanning was used to identify SSH servers, which were then subjected to brute-force password attacks against the root account. If the brute-force attack was successful, a XorDDoS bot was installed. The scanning, brute-force attacks, and payload delivery all originated from different sources. However, the timing between each stage indicates that a coordinated automated process is used between all attacking systems.

During the investigation, instructions were sent to the bots to launch DDoS attacks against targets located in both the US and China. This report discusses the apparently automated approach used by the threat actor to identify vulnerable hosts, install the XorDDoS bot, and launch DDoS attacks.

attack overview

Between October 6th and December 7th, 2022, over 1.2 million unauthorized SSH connection attempts were observed across 18 honeypots deployed globally. Of these attempts, 42% were from 49 IP addresses assigned to ChinaNet Jiangsu Province Network. The remaining authentication attempts originated from over 8,000 IP addresses distributed across the rest of the world. Honeypots were deployed to gather additional information on the scanning from these ChinaNet IP addresses.

It was found that once the scanning identified an open port, it would be subject to a brute-force attack against the 'root' account using a list of approximately 17,000 passwords. Once the brute-force attack was successful, a XorDDoS bot was installed, this time from an IP address assigned to a server in Hong Kong. The remainder of this article is broken into three sections: scanning and brute-forcing, installation of malware, and analysis of the XorDDoS bot.

brute forcing

Scanning originating from 49 ChinaNet IPs was observed. The scan attempt completed the TCP handshake on port 22 (SSH) and attempted to establish a session with the SSH server using a single authentication using the 'root' account. The features of these authentication attempts were reviewed to determine if all traffic from these IPs originated from the same tool.

The user agent for the authentication attempts from the ChinaNet IPs was "PUTTY" or "PuTTY". In contrast, the authentication attempts from the non-ChinaNet IPs used 114 different user agents (e.g., libssh, openssh, paramiko, winscp). Another indicator is that the ChinaNet IPs only attempted authentication against the "root" account, while other attacking IPs tried 15,070 usernames. The consistency between the ChinaNet traffic, compared to the differences in the rest of the dataset, suggests one source group.

Image 1: Log Showing "PUTTY" User Agent

While investigating a Microsoft Azure Linux host deployed in the East US region, we observed over 240,000 authentication attempts in under two months. Most of the traffic was from the ChinaNet IPs, with one IP address alone accounting for almost 25% of connection attempts.

Image 2: Distribution of Source IPs for One Host Investigated

For this host, using "PUTTY" as an indicator of the ChinaNet SSH connections shows that over 88% of the traffic was from the same user agent. In this case, the user agent "PUTTY" is the first IoC for this threat group.

Image 3: User Agent of SSH Scanning

The above shows the "PUTTY" user agent from the ChinaNet subnet compared to other user agents observed on the most actively scanned host. When further filtering the traffic to only IPs using the "PUTTY" user agent, the traffic begins to look more consistent, with several consecutive days having nearly the same number of authorization attempts. Please note that the graph below shows the number of connections per day, not the "document count." In this case, "document" refers to a line in the JSON log file.

Image 4: Authentication Attempts Per Day with "PUTTY" User-Agent

BRUTE FORCE TTPs

Several scatter plots, like the one below, revealed two types of activity from the ChinaNet hosts. One group is the low-volume authentication hosts, which have a consistent number of connections over time and use a slow approach to brute-forcing. The second type is the high-volume brute force host. There are many instances in which all the scanning hosts stop connecting, and a brute force host connects. This can be seen in the graph below, where there is a clear break in activity followed by one brute force attack.

The top two IPs in the graph represent high-volume brute force hosts, while the rest are low-volume bots trying to authenticate three times before moving to the next IP. The result is around-the-clock authentication attempts from dozens of IP addresses. It appears to take several days of low-volume authentication attempts before a host is targeted for high-volume brute-forcing.

Image 5: Distribution of Attempts Over Time from ChinaNet IPs

Of the 17 targeted hosts investigated, two saw no authentication attempts from the ChinaNet IP addresses: those deployed in Singapore and Tokyo. However, these hosts did have malicious authentication attempts from other IPs, but none of these had indicators matching the ChinaNet IPs. This indicates that these regions of South-East Asia are not currently being targeted by this specific campaign.

With information from the scatter plots, it becomes possible to identify which IPs are slow authentication and which are used for high-volume brute force attacks based on user agent and SSH cipher. Filtering for these IPs in the rest of the data reveals that the high-volume brute force hosts exclusively use "PUTTY" (as opposed to "PuTTY") with a cipher of "aes128-ctr" and a MAC of "hmac-sha2-256". "PuTTY" uses a cipher of "3des-cbc" and a MAC of "hmac-md5". Based on the available evidence, it is speculated that the high-volume brute force hosts have more robust hardware, and the "PUTTY" software is capable of handling more connection attempts.

To identify other related scanning sources, we filtered all connections for "PUTTY" as the software version and identified 10 additional IPs not included in the initial IP address range but consistent with other observed TTPs (cipher, MAC, and username all match). In total, 48 IPs scanning or brute forcing SSH were identified using identical user agent, cipher, MAC, and username, all of which were assigned to ChinaNet. 

PASSWORDS

During the two-month collection period, 17,425 passwords were collected from the ChinaNet IPs authentication attempts. An additional 70,424 passwords were collected from the rest of the malicious SSH authentication attempts. The efficiency of the system used by this threat actor may be questionable as many targeted hosts saw multiple attempts using the same password. The number of attempts appears to depend on the complexity of the password, with passwords like “toor”, “root”, and “admin” being tried over 100 times on a single host.  

While repeatedly attempting the same password may seem inefficient, this campaign does appear to be targeting cloud infrastructure, where there is a high level of turnover of IP addresses and new machines being created regularly. There does appear to be a cyclical nature to the password attempts. When viewing the tries for the password “australia”, against a host in Azure – the cyclical use of passwords can be seen. It is possible that cycling through common passwords increases the likelihood of compromising poorly configured or newly launched hosts.  

Image 6: Graph Shows Repeated Attempts with the Password "australia"

In one case, an Azure host, deployed in the Eastern US, saw authentication attempts from five ChinaNet IPs using the password “australia”. The attempts occurred 1-2 times per day for 5 days, then would not be used again for four days. Based on data collected from our honeypots, there is a rough sequence of passwords, and the use of passwords is coordinated between all the brute-force hosts.

INSTALLATION OF MALWARE

After a successful brute-force attempt from a ChinaNet IP, an authentication request from a Hong Kong IP using the same password would quickly follow. This second connection lasted approximately 5 minutes, during which a dropper script was copied to the target and executed. No further authentication attempts or connections from that host (located in Hong Kong) were made.

The dropper script creates a copy of curl to “/usr/bin/good” and uses it to download the XorDDoS bot. It is assumed that this is to avoid detection logic that catches unusual uses of curl.

Finally, the initial script cleans up by deleting itself and logs in the /var/log/ directory. This behavior, as well as the behavior of the XorDDoS bot, is consistent with what Microsoft reported in their XorDDoS article.

Image 7: Example of Initial Download Script

Source: Microsoft

the malware: xorddos

Once the XorDDoS malware is installed, it starts communicating with command-and-control servers (C2) in Poland and France, connecting to TCP port 1520. Communication is encrypted using XOR (hence the XOR part of the malware name), and the key is hidden in the source code of the malware. 

Image 8: XOR Key Hidden in the Decompiled Code

The compromised system sends system information to the C2 servers, and malware hides the connections by injecting a different process name when the malware is called by cron. In the screenshot below, the malware has injected the process “su”. 

Image 9: Netstat Output Showing the Fake "su" Process Connected to a C2 Server

PERSISTENCE

The two methods of persistence observed are cron and init.d. Upon installation a malicious script is added to /etc/init.d to ensure the malware is run at startup. The script will have the same file name as the malware, in this case “ygljglkjbfg0”.  

Image 10: "/etc/init.d" Script Which Starts the XorDDos Malware at Startup

This malware also creates persistence in SystemV Linux machines by adding itself to all run levels. The screenshot below shows the single function in which both startup persistence measures are seen.  

Image 11: Decompiled Code Snippet Showing RC and "init.d" Persistence Function

The second persistence function is a “cron.hourly” script that runs every 3 minutes to launch the malware. This script launches a copy of the original downloaded file which has been copied to the “/lib” directory, the original file remains in “/usr/bin”. The cron job makes another copy of the malware and runs that on each execution. The result is multiple copies of the malware that can re-infect the host if they are not all cleaned. 

Image 12: "cron.hourly" Script that Runs the Malware Every Three Minutes

DDOS ACTIVITY

The malware is capable of SYN, DNS, ACK, and HTTP GET flood attacks[1]. One of the main indicators of DDoS activity associated with this campaign is the user-agent “TencentTraveler” in HTTP GET requests. During the time Avertium was monitoring the bots[2] the DDoS attacks were targeting hosts in the United States and China, this is consistent with the behavior observed by Microsoft in June. The relationship between this traffic is not clear, although the frequency of attacks on US-based targets is an indicator that the intent is not random. One potential use of this DDoS activity could be to create a tsunami of connection attempts to cover for an attack from a different location although analysis of targeted hosts would be needed to confirm this hypothesis. 

[1] Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices - Microsoft Security Blog

[2] Note that DDoS traffic from our monitored systems was blocked, and no targets were impacted by systems under Avertium’s  control.

TENCENT TRAVELER

Like much of the world, Chrome has become the most popular internet browser in China. However, there are also several other popular browsers developed in China that are commonly used, one of which is QQ browser. Tencent Explorer was developed by Tencent, a Chinese technology and entertainment conglomerate, in 2000. Tencent Traveler was launched in 2003 and continued under the name "QQ browser". This browser remains one of the more popular browsers in China, despite a history of failing to safeguard user data. It is interesting to note that the QQ browser does not support Linux, which makes the choice of this user agent string interesting for use in Linux malware.

LINKS TO CHINA-BASED ORIGIN

After analysis, we assess that this activity is based in China and is being carried out by a threat group with significant resources. The main indicators that point towards a China-based group are the location of the scanning and malware servers in China and Hong Kong, Chinese language references, and the use of the "TencentTraveler" user-agent in the malware code. Although the C2 servers are located in Europe, this is likely an attempt to reduce the chances of the traffic being blocked geographically. It is worth noting that the compromised host we investigated was in Germany, and the European C2 servers could be regionally configured. However, we still believe that this is a China-based group playing a small part in a much larger campaign.

Image 13: All XorDDos Samples Observed Included 'TencentTraveler" User-Agent String

In addition to the SSH brute force activity originating in Jiangsu, China which is the province north of Shanghai. Two domains have been linked to the C2 server IP addresses. These two domains are owned by a Chinese company based in Zhejiang, the province south of Shanghai.  This evidence suggests that the threat actor(s) are located in the Shanghai area of China. Although it does not establish a motive for the DDoS activity. 

Image 14: "whois" Lookup for a Malware-Related Domain

Image 15: Locations of Jiangsu and Zhejiang Provinces

prevention

The best prevention for this malware is ensuring strong SSH authentication standards. SSH login with the root account should be disabled, and key-based authentication should be enforced. Due to multiple persistence mechanisms, simply deleting the executable will not be enough to clean the host.  

Note: This blog entry was written by Digital Forensics and Incident Response Consultant Bryant Reese, with editorial contributions by Portia Cole.

INDICATORS OF COMPROMISE (IOCs)

Hashes – SHA256

• 2e88f685828251c4208afce35593e2b8a9e6849be94623b468abb22167474c4a 
• 860e2e82d7bd01abeb72afede6db129a5b7d024a3356fa2db0e1626326fca4db 
• 55db2ef3b4b514d196ffe2c47c6ef819207ae51802c474150f9841fcb3a17d3d 
• 495aa89868bb72275a755028c3e0c994bc945cc61512569fc8b5e56234812574 
• 5d7cdb8c06f5e4d8d0bd8f4cccaeee1dcaa2df3b1d88b4128a009e94aa459b7b 
• 6ff672202de36bd7d4e0c6246340f63409ef14499533141f735648407b879ef4 
• 70167bee44cde87b48e132a9abbac66055277cb552f666ca8b7bf5120914e852 
• 2e88f685828251c4208afce35593e2b8a9e6849be94623b468abb22167474c4a 
• d177394d03dfa3e22b79916e45d16fcaf5ff4046d95ac6807bb5544bc4c14fe9 
• 6a2bc04e6116e1dcc2a5491f0ea0a114b8a12752c3ef12432607cf37f5a4eefc 
• f2e7199ac3645f02db993f4cfff30a67556df77126fcbf76e21ab83d0970e646 
• ec2d1c769cd2926e010c736d3129ce0548b1c0d24d9f3ac393862a80237bcaa2 

SSDEEP

• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36Eoj3:/fUywKQ7Fb1pNL/p5gfjQn36Eu3
• 12288:D3P1A0+Kvdnd4Asvhc27/ao+PzENGtkZg0/CedRlZRqR6ysec:Dfm0+KlZsJc27io2zYGtk20/LdF0+z
• 12288:D3P1A0+Kvdnd4Asvhc27/ao+PzENGtkZg0/CedRlZRqR6yseT:Dfm0+KlZsJc27io2zYGtk20/LdF0+A
• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36EojJ:/fUywKQ7Fb1pNL/p5gfjQn36EuJ
• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36Eojg:/fUywKQ7Fb1pNL/p5gfjQn36Eug
• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36Eojj:/fUywKQ7Fb1pNL/p5gfjQn36Euj
• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36EojP:/fUywKQ7Fb1pNL/p5gfjQn36EuP
• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36Eoj:/fUywKQ7Fb1pNL/p5gfjQn36Eu
• 12288:D3P1A0+Kvdnd4Asvhc27/ao+PzENGtkZg0/CedRlZRqR6ysec:Dfm0+KlZsJc27io2zYGtk20/LdF0+z
• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36EojF:/fUywKQ7Fb1pNL/p5gfjQn36EuF
• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36EojL:/fUywKQ7Fb1pNL/p5gfjQn36EuL
• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36EojG:/fUywKQ7Fb1pNL/p5gfjQn36EuG
• 12288:4Ufrcn+vwK5ripVU4tdZ1pNL/pVbzg66ySjQn36Eojh:/fUywKQ7Fb1pNL/p5gfjQn36Euh

SSH Brute Force IPs

• 61[.]177[.]172[.]0/23
• 218[.]92[.]0[.]128/25
• 49[.]88[.]112[.]65
• 49[.]88[.]112[.]115

Malware Server

• 103[.]64[.]12[.]105 

C2 Servers

• 176[.]31[.]91[.]136
• 176[.]31[.]91[.]137
• 176[.]31[.]91[.]138
• 176[.]31[.]91[.]139
• 54[.]36[.]15[.]96
• 54[.]36[.]15[.]97
• 54[.]36[.]15[.]98
• 54[.]36[.]15[.]99
• 54[.]36[.]145[.]104
• 54[.]36[.]145[.]105
• 54[.]36[.]145[.]106
• 54[.]36[.]145[.]107
• 54[.]36[.]145[.]173
• 54[.]36[.]145[.]178
• 46[.]105[.]84[.]188
• 46[.]105[.]84[.]189
• 46[.]105[.]84[.]190
• 46[.]105[.]84[.]191
• 79[.]137[.]1[.]133
• 79[.]137[.]1[.]134
• 79[.]137[.]1[.]135
• 79[.]137[.]1[.]136

Domains

• Xxxatat456[.]com
• Gggatat456[.]com

YARA Rule

APPENDIX II: Disclaimer

This document and its contents do not constitute, and are not a substitute for, legal advice. The outcome of a Security Risk Assessment should be utilized to ensure that diligent measures are taken to lower the risk of potential weaknesses be exploited to compromise data.

Although the Services and this report may provide data that Client can use in its compliance efforts, Client (not Avertium) is ultimately responsible for assessing and meeting Client's own compliance responsibilities. This report does not constitute a guarantee or assurance of Client's compliance with any law, regulation or standard.

COPYRIGHT: Copyright © Avertium, LLC and/or Avertium Tennessee, Inc. | All rights reserved.