Cloud
Groups Target Alibaba ECS Instances for Cryptojacking
We looked at how some malicious groups disable features in Alibaba Cloud ECS instances for illicit mining of Monero.
Save to Folio
It’s been known that threat actors are actively exploiting misconfigured Linux-powered servers, regardless of whether they run on-premises or in the cloud. The compromised devices are mostly used for cryptojacking purposes with the dominance of mining for the digital currency Monero. One notorious example is TeamTNT, one of the first hacking groups shifting its focus to cloud-oriented services.
The cryptojacking battlefield is shared by multiple threat actors such as Kinsing and TeamTNT, amongst others. Two common characteristics that they share in their code is to remove competing actors who are also mining for cryptocurrency and disable security features found in the victim machine. This provides them an advantage over the hijacked resources, such as the example of an advanced system sanitation that we identified targeting Huawei Cloud.
In this article, we focus on one common functionality that we found amongst multiple payloads: the disabling of features inside the Alibaba cloud service provider (CSP). We also look at possible reasons that multiple threat actors and malware routines focused on Alibaba Cloud (also known as Aliyun) and the implications of these illicit mining activities on Alibaba Cloud users.
We have reached out to the Alibaba Cloud Team through their listed contact information prior to the publication of this blog, and we are waiting for their response with regard to this concern.
Looking into Alibaba ECS
Alibaba Elastic Computing Service (ECS) instances come with a preinstalled security agent. As a result, the threat actors try to uninstall it upon compromise. This is no surprise as we have seen similar payloads in the past. However, this time we found a specific code in the malware creating firewall rules to drop incoming packets from IP ranges belonging to internal Alibaba zones and regions.
In addition, the default Alibaba ECS instance provides root access. While other CSPs provide different options ranging from the least privileged ones — such as not allowing Secure Shell (SSH) authentication over user and password and only allowing asymmetric cryptography authentication — other CSPs do not allow the user to log in via SSH directly by default, so a less privileged user is required.
For instance, if the login secrets are leaked, having low-privilege access would require attackers enhanced effort to escalate the privileges. With Alibaba, however, all users have the option to give a password straight to the root user inside the virtual machine (VM).
Security-wise, this is in contradiction with the principle of least privilege, and it should be emphasised that this is the responsibility of the user for a secure configuration. We highly recommend creating a less privileged user for running applications and services within the ECS instance.
In this situation, the threat actor has the highest possible privilege upon compromise, including vulnerability exploitation, any misconfiguration issue, weak credentials or data leakage. Thus, advanced payloads such as kernel module rootkits and achieving persistence via running system services can be deployed. Given this feature, it comes as no surprise that multiple threat actors target Alibaba Cloud ECS simply by inserting a code snippet for removing software found only in Alibaba ECS.
Cryptojacking Aliyun
When a cryptojacking malware is running inside Alibaba ECS, the security agent installed will send a notification of a malicious script running. It then becomes the responsibility of the user to stop the ongoing infection and malicious activities. Alibaba Cloud Security provides a guide on how to do this. More importantly, it is always the responsibility of the user to prevent this infection from happening in the first place.
Despite detection, the security agent fails to clean the running compromise and gets disabled. Looking at another malware sample shows that the security agent was also uninstalled before it could trigger an alert for compromise. The samples then proceeded to install an XMRig. Examining the samples further shows that the cryptominer can easily be replaced with another malware to execute in the environment.
It is also important to note that Alibaba ECS has an auto scaling feature, wherein users and organisations can enable the service to automatically adjust computing resources based on the volume of user requests. When the demand increases, auto scaling allows the ECS instances to serve the said requests according to the enumerated policies. While the feature is given to subscribers at no extra cost, the increase in resource usage prompts the additional charges. By the time the billing arrives to the unwitting organisation or user, the cryptominer has likely already incurred additional costs. Additionally, the legitimate subscribers have to manually remove the infection to clean the infrastructure of the compromise.
The samples our team acquired can be tied to campaigns targeting Alibaba, and we found these samples sharing common traits, functions, and functionalities with other campaigns that also target CSPs in Asia such as Huawei Cloud. There have also been other reports of these compromise detections.
The samples from both campaigns share common traits, especially when it comes to removing “adversaries” and setting up the environment for next-phase infections, such as making sure to use a public DNS. Although the style in coding is different, the purpose of the functions is similar on both attacks.
Mitigating the impact of threats on Alibaba ECS workloads
A performance penalty is one consequence of leaving a cryptojacking campaign running within the Alibaba cloud infrastructure, as the cryptomining process consumes a lot of resources. Moreover, in situations where users set their instances with the auto scaling feature, they can end up with unexpected costs to their subscriptions.
Seeing how easily the compromise can be scaled, attackers can also easily replace the malicious cryptominer with another piece of malware that can potentially drive them more profit or spread to other workloads and endpoints. Subsequent attacks can be done on the projects or infrastructure as a result of how easy it is to infiltrate the environment with high user privileges. We continue to study the malicious activities that can be deployed in the infrastructure. We also list here some best practices for organisations to follow:
- Practice a shared responsibility model. Both CSPs and users have a responsibility to ensure that security configurations of workloads, projects, and environments are safe. Read through the guides, customise, and enable the security layers of workloads and projects accordingly. Enable policies that can best help secure the cloud environment and ensure that it has more than one layer of malware-scanning and vulnerability-detection tools.
- Customize the security features of cloud projects and workloads. Despite the offered feature of your CSP, avoid running applications under root privilege and using passwords for SSH. Use public key cryptography for access.
- Follow the principle of least privilege. Limit the number of users with the highest access privileges according to their respective levels of involvement in a project or an application.
Indicators of Compromise (IOCs)
You can find the full list of IOCs and Trend Micro detections here.