Actors Target Huawei Cloud Using Upgraded Linux Malware
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.
Save to Folio
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.
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.
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 (126.96.36.199 and 188.8.131.52). 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.
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.
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.
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.
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.
Campaign payloads and upgraded functionalities
The script deploys two executable and linkable format (ELF) binaries — linux64_shell and xlinux.
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.
Upon closer look, we can see that another binary with extra data was 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:
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.
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.
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
2. It copies itself into /tmp/iptablesupdate and drops a persistence script
3. The binary begins with a “security” scan. Once a weakness is found, it exploits it and deploys its payload
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
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
AAAAB3NzaC1yc2EAAAADAQABAAABAQDLVZNrAJ1uzR7d2bm1iUQPAgjuBlyLQQNaEHVmACWtGwwiOKMPiFBfBjuNJIyZFnGkkFgJP5fi8v1eqliaBgqERUDDtW/RZDDIz8DovDrA4/MGlxpCHLeViN+F62W/jgeufiQ7NiPTlPB3Fuh7E7QXXpXqQ6EmVlV0iWdzqRvSiDIB3cIL6E2CrK47pY6Rp6rY2YKYzUhiZRqAMHViMR+2MARL2jERfF3CsG6ZXo/7UVVx+tqoKQDHPmz21mrulOF6RW5hh04dE2q1+/w6xmX8AxUSGmPdpwQa8GuV7NHHZmYO26ndTVi2ES472tJdkXVHmLX8B9Un42JLNVXwPU/H firstname.lastname@example.org" >>/opt/autoupdater/.ssh/authorized_keys