Malware authors are keeping with the times and when it comes to server-oriented malware. Specifically, attackers will adopt the same technologies their target organizations are using. Security researchers have recently come across a cryptocurrency miner that was designed to run inside AWS Lambda, a so-called serverless computing platform designed to execute user-supplied application code on demand.
“Although this first sample is fairly innocuous in that it only runs cryptomining software, it demonstrates how attackers are using advanced cloud-specific knowledge to exploit complex cloud infrastructure, and is indicative of potential future, more nefarious attacks,” researchers from Cado Security who found the malware program, said in their report.
The Denonia malware
The malicious program, which is written in Go, has been dubbed Denonia and is delivered as a 64-bit ELF executable for Linux. The Cado researchers don’t yet have information about how the malware is delivered but suspect that compromised AWS access credentials and Secret Keys could be involved.
Malware written in the Go programming language is not new and has been increasingly prevalent in recent years because it provides attackers with an easy method of making their malware cross-platform and self-contained. The downside is that the binary files are much bigger since they need to contain all the libraries the program needs instead of dynamically linking to libraries already existing on an operating system.
It also makes it easier to deploy their code on serverless computing platforms, which are 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 in charge of managing them and their operating systems, Lambda and other offerings like it allow users to deploy code written in different programming languages that is executed on-demand based on events with no concern about managing the computing infrastructure behind it, like the servers and operating systems.
Denonia was clearly created with Lambda in mind because it includes third-party open-source Go libraries created by AWS itself to interact with the platform: aws-sdk-go and aws-lambda-go. Furthermore, it checks for specific Lambda environment variables when executed, such as LAMBDA_SERVER_PORT and AWS_LAMBDA_RUNTIME_API.
“Despite the presence of this, we discovered during dynamic analysis that the sample will happily continue execution outside a Lambda environment (i.e., on a vanilla Amazon Linux box),” the Cado researchers said. “We suspect this is likely due to Lambda ‘serverless’ environments using Linux under the hood, so the malware believed it was being run in Lambda (after we manually set the required environment variables) despite being run in our sandbox.”
Stealthy communication make Denonia detection difficult
The malware hides command-and-control traffic in DNS requests performed to an attacker-controlled domain and hides those requests using DNS-over-HTTPS (DoH). DoH encrypts the contents of DNS requests, so a traffic inspection mechanism will only see requests going to HTTPS DNS resolvers such as cloudflare-dns.com or dns.google.com and not the actual contents of the queries. This makes detection more difficult and allows attackers to bypass Lambda environment settings that might disallow traditional DNS traffic over port 53.
The malware is basically a wrapper for the XMRig, an open-source cryptocurrency mining program that has often been adopted by malware authors. This is not even the first time when Lambda customers are targeted with XMRig, although via more simple scripts rather than complex malware like Dedonia. The Cado researchers note that while the malware they analyzed dates from February, they found an older one created in January on VirusTotal. So, these attacks have been running for a few months.
Serverless platforms like Lambda are a great resource for smaller organizations who don’t have the staff required to manage and secure cloud VMs, because the server management burden is offloaded to the cloud provider. However, they are still responsible for protecting their credentials and access keys or they can incur large bills of their accounts are abused.
“Short runtime durations, 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 warned. “Under the AWS Shared Responsibility model, AWS secures the underlying Lambda execution environment, but it is up to the customer to secure functions themselves.”
Copyright © 2022 IDG Communications, Inc.
