Attackers create malware for serverless computing platforms like AWS Lambda
Malware authors move with the times when it comes to server-facing malware. Specifically, attackers are adopting the same technologies that their target organizations are using. Security researchers recently came across a cryptocurrency miner designed to run on AWS Lambda, a so-called serverless computing platform designed to run user-provided application code on demand.
“Although this first example is fairly benign as it only runs cryptomining software, it shows how attackers are using advanced cloud-specific knowledge to exploit complex cloud infrastructures and points to potential, more nefarious attacks in the future,” the researchers said Cado Security, who found the malware program, said in their report.
The Denonia malware
The malware, written in Go, goes by the name of Denonia and is distributed as a 64-bit ELF executable for Linux. Cado researchers don’t yet have any information on how the malware is delivered, but suspect compromised AWS credentials and secret keys could be involved.
Malware written in the Go programming language is not new and has become more prevalent in recent years as it offers attackers an easy way to make their malware cross-platform and self-contained. The downside is that the binaries are much larger as they must contain all the libraries that the program needs instead of dynamically linking with libraries already present on an operating system.
It also makes it easier to deploy your code to serverless computing platforms designed to support code in multiple programming languages. AWS Lambda natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby.
Compared to traditional cloud computing, where users rent virtual machines and are responsible for managing them and their operating systems, Lambda and other similar offerings allow users to deploy code written in different programming languages and run on-demand based on events without concern is about managing the underlying computing infrastructure such as servers and operating systems.
Denonia was clearly built with Lambda in mind as it includes open source third party Go libraries built by AWS itself to interact with the platform: aws-sdk-go and aws-lambda-go. Additionally, when running, it checks for certain Lambda environment variables, such as: B. LAMBDA_SERVER_PORT and AWS_LAMBDA_RUNTIME_API.
“Nevertheless, during dynamic analysis, we found that the probe will continue to run outside of a Lambda environment (ie, on an Amazon vanilla Linux box) without any problems,” the Cado researchers said. “We suspect this is likely due to ‘serverless’ Lambda environments with Linux under the hood, so the malware thought it was running in Lambda (after we manually set the required environment variables) even though it was running in our sandbox .”
Covert communication complicates Denonia detection
The malware cloaks command-and-control traffic in DNS queries sent to an attacker-controlled domain and obfuscates those queries using DNS-over-HTTPS (DoH). DoH encrypts the content of DNS requests, so a traffic inspection mechanism only sees requests going to HTTPS DNS resolvers like cloudflare-dns.com or dns.google.com, and not the actual content of the queries. This makes detection more difficult and allows attackers to bypass Lambda environment settings that might not allow traditional DNS traffic over port 53.
The malware is basically a wrapper for XMRig, an open-source cryptocurrency mining program that has often been adopted by malware authors. This isn’t even the first time Lambda customers are addressed with XMRig, albeit via simpler scripts rather than complex malware like Dedonia. Cado researchers note that while the malware they analyzed dates back to February, they found an older one that was created on VirusTotal in January. So these attacks have been going on for a few months.
Serverless platforms like Lambda are a great resource for smaller organizations that don’t have the staff needed to manage and secure cloud VMs because the burden of server management is offloaded to the cloud provider. However, they are still responsible for protecting their credentials and access keys, or they may misuse large bills of their accounts.
“Short runtimes, the sheer volume of executions, and the dynamic and ephemeral nature of Lambda functions can make it difficult to detect, investigate, and respond to a potential compromise,” the Cado researchers warn. “As part of the AWS shared responsibility model, AWS secures the underlying Lambda execution environment, but it is up to the customer to secure the features themselves.”
Copyright © 2022 IDG Communications, Inc.