Actors Target Huawei Cloud Using Upgraded Linux Malware Sr. Security Researcher Threat Researcher

Actors Target Huawei Cloud Using Upgraded Linux Malware

Cloud

In this article, we discuss a new Linux malware trend in which malicious actors deploy code that removes applications and services present mainly in Huawei Cloud.

By: Alfredo Oliveira, David Fiser October 08, 2021 Read time: ( words)

We have recently noticed another Linux threat evolution that targets relatively new cloud service providers (CSPs) with cryptocurrency-mining malware and cryptojacking attacks. In this article, we discuss a new Linux malware trend in which malicious actors deploy code that removes applications and services present mainly in Huawei Cloud. Specifically, the malicious code disables the hostguard service, a Huawei Cloud Linux agent process that “detects security issues, protects the system, and monitors the agent.” The malicious code also includes cloudResetPwdUpdateAgent, an open-source plugin agent that allows Huawei Cloud users to reset a password to Elastic Cloud Service (ECS) instance, which is installed by default on public images. As threat actors have these two services present in their shell scripts, we can assume that they are specifically targeting vulnerable ECS instances inside Huawei Cloud.

Figure 1. Malicious code that disables hostguard and resets the password to ECS instance using the includes cloudResetPwdUpdateAgent plugin agent

Campaign evolution

While researching this campaign, we stumbled upon older samples involved in a campaign that was previously discussed in a 2020 Tencent blog. The samples from that campaign were targeting container environments. There were two specific routines supporting this finding: the first one was that one of the payloads of this attack dropped a network scanner to map other hosts with ports commonly used as container APIs. The second was a function that created firewall rules to ensure that those container API ports are going to open. On the newer samples we’ve found, the firewall rule creation is still present as a code that’s left behind. However, it’s been commented on, so no rule is created. We’ve observed that the newer samples are only targeting cloud environments.

Another interesting capability that we haven’t seen before is that in this campaign, malicious actors have been searching for specific public keys that would allow them to kill off their competition from the infected system and update their own keys. More than any other samples and campaigns we’ve seen so far, this campaign performs a comprehensive sanitization of the operation system. It looks for both signs of previous infections and for security tools that could stop its malicious routines. Not only that, but it also uses simple but effective commands to clean up after it performs its infection routine.

Figure 2. Code showing SSH keys sanitization

Most of the sourced samples follow the same routine of declaring several functions in no specific order. At the end of the file calling the functions, it follows a specific order: It performs initial connectivity checking, ensuring that outgoing connections are allowed, and checking if DNS servers are public (8.8.8.8 and 1.1.1.1). Such a routine is commonly done to make sure that when malicious URLs are requested, they will not be detected and that the domain translation denied by a Domain Name System (DNS) Security is implemented.

Following the first connectivity check, the next set of functions are then called to prepare the system. It first removes any traces of infections made by competitors to avoid sharing computational resources. This kind of behavior was previously seen and documented, but this specific campaign goes beyond when it pertains to maintaining access in the infected system.

Figure 3. The specific order of function that the campaign’s routine follows in order to avoid detection

Upon further analysis of this campaign, we came across an interesting observation: the threat actors know their competitors well. They are aware of the users that their competitors use to maintain access. This is why they make sure to check and remove their competitors’ users first before creating their own users.

Figure 4. Malicious actors check for and remove their competitors’ users in the system

After removing unnecessary users from the system, the next step is creating several users of their own. This is another behavior that we have partially seen in other samples targeting cloud environments. The difference of this campaign, however, is that it creates a greater number of users using more generic, inconspicuous names such as “system” and “logger.” Using usernames such as these can fool an inexperienced Linux analyst into thinking that these are legitimate users.

Another unique behavior is that during the creation of the user, the script adds them to the sudoers list to give them administrative powers over the infected system.

Figure 5. The malicious actors create generic users to avoid detection and add them to the sudoers list

The hacking team also adds their own ssh-rsa key to enable them to repeatedly log in to the infected system. After conducting system modifications, they add special permissions to prohibit further modifications from being applied to those files. This ensures that the malicious users that they created cannot be removed or modified.

Figure 6. The malicious actors add their own ssh-rsa key to enable them to repeatedly log in on the infected system

Another interesting aspect of this campaign is that it installs The Onion Router (Tor) proxy service. This will be used later by the payloads to anonymize the malicious connections made by the malware.

The campaign installs and uses the Tor proxy service to anonymize malicious connections

Campaign payloads and upgraded functionalities

The script deploys two executable and linkable format (ELF) binaries — linux64_shell and xlinux.

linux64_shell

The binary itself is packed and obfuscated, the Ultimate Packer for Executables (UPX) packer has been used, but then the binary was tampered with in order to make the analysis harder and fooling some of the automated toolsets.

Figure 9. UPX header present in the binary

Upon closer look, we can see that another binary with extra data was appended to the file.

Figure 10. Another binary appended to the file

The appended binary is a compiled CrossC2 communication library included to be able to interact directly with CobaltStrike’s module using the following functions:

cc2_rebind_http_get_recv
cc2_rebind_http_post_send
cc2_rebind_post_protocol
cc2_rebind_http_get_send

After it is successfully unpacked, the executable continues with its control flow, which is designed to not be easily understood by an analyst and is full of conditional jumps.

Figure 11. Obfuscated control flow full of (conditional) jumps

At this point, the malware tries to connect to the C&C with an IP address of 45[.]76[.]220[.]46 on port 40443. This provides shell access to the attackers.

xlinux

The second binary is a Go-compiled binary implementing several modules from the kunpeng framework. It acts as a vulnerability scanner, exploits weaknesses, and deploys the initial malicious script.

1. The binary notifies malicious actors about the infected machine by sending an HTTP POST request to following URL 103[.]209[.]103[.]16:26800/api/postip

The binary notifies malicious actors about the infected machine by sending an HTTP POST request to following URL 103[.]209[.]103[.]16:26800/api/postip

2. It copies itself into /tmp/iptablesupdate and drops a persistence script

Figure 12. Dropped script makes the Go binary persistent

3. The binary begins with a “security” scan. Once a weakness is found, it exploits it and deploys its payload

Figure 13. An example of an integrated exploit

An infected system is scanned for the following vulnerabilities and security weaknesses:

SSH weak passwords
Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (CVE-2020-14882)
Redis unauthorized access or weak passwords
PostgreSQL unauthorized access or weak password
SQLServer weak password
MongoDB unauthorized access or weak password
File transfer protocol (FTP) weak password

Conclusion

Cryptocurrency miners are one of the most deployed payloads in the Linux threat landscape. In recent years, we have observed malicious actors such as TeamTNT and Kinsing launch cryptojacking campaigns and cryptocurrency mining malware that competes for the computing powers of infected resources.

In 2020 and 2021 we have seen how these cybercriminal groups consistently targeted cloud environments and added cloud-centric features to their campaigns, including credential harvesting and the removal of cloud security services related to Alibaba Cloud and Tencent Cloud.

Cloud service misconfigurations can allow cryptocurrency mining and cryptojacking attacks to happen. Most of the attacks that we’ve monitored occurred because the services running on the cloud had an API or an SSH with weak credentials or had very permissive configurations, which attackers can abuse to enable them to infiltrate a system without needing to exploit any vulnerabilities. Misconfigurations are a common point of entry in such scenarios, and cloud users should give the same thought and attention to misconfigurations as they do to vulnerabilities and malware.

Our team published several blogs and a research paper that shows how malicious actors targeted a specific cloud provider. In this blog, we have seen evidence of cybercriminals targeting other relatively newer CSPs like Huawei Cloud. Since attackers are also migrating to the cloud, the availability and scalability of resources are becoming even more precious since most of their attacks routinely deploy cryptojacking malware among other malicious routines.

We have reached out to Huawei Media Team through their email address listed on their Contact Us page with our findings prior to the publication of this blog, and we are currently awaiting their acknowledgment or reply.

Cloud security recommendations

Malicious actors and hacking groups continue to upgrade their malware’s capabilities to make the most of their attacks. To keep cloud environments secure, organizations must not rely solely on malware scanning and vulnerability checking tools. Checking and studying the responsibility model of their CSPs can help them define the best policies to put into place when publishing their cloud services.

MITRE ATT&CK Tactics and Techniques

Indicators of compromise

SHA-256	File	Detection Names
3e38c51510f95643b04a9ba0f884a445f09372721073601abcbf8f12f663bf90	fczyo	Coinminer.Linux.XANTHE.B
6a5a0bcb60944597d61d5311a4590f1850c2ba7fc44bbcde4a81b2dd1effe57c	fczyo	Coinminer.Linux.XANTHE.A
71f578d122252c7fa67ca343cd29d65ac42d6f7c45bf91f146a1cd04b0446c23	fczyo	Coinminer.Linux.XANTHE.B
9849c66d8b6c444904259cda7f3e34ac2c60b00a945d3d5b911b5e290eb2888d	fczyo	Coinminer.Linux.XANTHE.B
d092b4cbf655d02ad8eae1a66db98e67cf95fa9e0b7c327c4bca33815696bf68	ff.sh	Trojan.SH.CVE20205902.B
e8503d6697c61c2c51ca90742b0634ce93710d6fdfb0965e35977e6cab4d039b	xlinux	Coinminer.Linux.PROCEAN.A
f36d3996245dba06af770d1faf3bc0615e1124fa179ecf2429162abd9df8bbf8	Linux64-shell	Trojan.Linux.COBEACON.A
fc614fb4bda24ae8ca2c44e812d12c0fab6dd7a097472a35dd12ded053ab8474	ff.sh	Trojan.SH.CVE20205902.B

Keys

AAAAB3NzaC1yc2EAAAADAQABAAABAQDLVZNrAJ1uzR7d2bm1iUQPAgjuBlyLQQNaEHVmACWtGwwiOKMPiFBfBjuNJIyZFnGkkFgJP5fi8v1eqliaBgqERUDDtW/RZDDIz8DovDrA4/MGlxpCHLeViN+F62W/jgeufiQ7NiPTlPB3Fuh7E7QXXpXqQ6EmVlV0iWdzqRvSiDIB3cIL6E2CrK47pY6Rp6rY2YKYzUhiZRqAMHViMR+2MARL2jERfF3CsG6ZXo/7UVVx+tqoKQDHPmz21mrulOF6RW5hh04dE2q1+/w6xmX8AxUSGmPdpwQa8GuV7NHHZmYO26ndTVi2ES472tJdkXVHmLX8B9Un42JLNVXwPU/H linux@linux.com” >>/opt/autoupdater/.ssh/authorized_keys

C&C Servers

103[.]209[.]103[.]16
45[.]76[.]220[.]46

You May Also Like

Campaign Abusing Legitimate Remote Administrator Tools Uses Fake Cryptocurrency Websites

An In-Depth Look at ICS Vulnerabilities Part 2

Attackers Use Containers for Profit via TrafficStealer