AWS Lambda sees its first malware attack with Denonia, and we don’t know how it got there

A new malware has infiltrated AWS Lambda services, and investigators still aren’t sure how it happened. Here’s how it works and how to protect your organization.

AWS Lambda is one of the many tools provided by Amazon Web Services. It allows the execution of code using a serverless method. Now, a group of cybercriminals has found a way to exploit it and run malware on it.

SEE: Google Chrome: Security and UI tips you need to know  (TechRepublic Premium)

AWS Lambda is a serverless compute service that allows the execution of code without provisioning or managing servers. Lambda can be triggered from more than 200 AWS services and software-as-a-service applications. Any kind of code in one of the languages that Lambda supports might be run. Lambda provides several benefits to large and small organizations, including security benefits, like reducing the attack surface compared with traditional server environments. AWS secures the underlying Lambda execution environment, yet it is up to the customer to secure the functions.

Cado Labs has exposed the first publicly known case of malware specifically designed to run in an AWS Lambda environment.

Denonia malware discovered

Named after the domain it communicates with (gw.denonia.xyz), Denonia is a 64-bit ELF executable malware written in Go language. It initially caught Cado Labs’ attention because it triggered errors that mentioned AWS Lambda environment variables (Figure A).

Figure A

Since the executable is a 64-bit ELF, Cado Security managed to have it run outside of Lambda, on a vanilla Amazon Linux system, by setting manually the required environment variables to make the malware believe it was running in Lambda.

How Denonia operates

Interestingly, the malware does not find its way from the infected environment to the attacker server using usual DNS request. Instead, it makes use of DNS over HTTPS (DoH). This protocol encrypts DNS requests as HTTPS traffic to DoH resolvers and makes it harder for analysts to discover the malware communications. In addition, this method might help the malware communicate in environments where DNS queries are blocked or unauthorized.

The malware uses the doh-go library to run its DNS queries over HTTPS:

https://dns.google.com/resolve?name=gw.denonia.xyz&type=A

The DoH server from Google answers with the IP address for the domain in a JSON format (Figure B).

Figure B

What is the final payload for Denonia?

Once Denonia is running, it launches XMRig, a software made to mine Monero cryptocurrency. XMRig is started from memory and makes use of the only writable folder in a Lamba environment, /tmp. The malware then communicates with the IP address obtained from the DNS query, on port 3333, which is a Monero mining pool.

There’s probably more malware to come

Cado Security’s Matt Muir said, “Although this first sample is fairly innocuous in that it only runs crypto-mining 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.”

The Denonia deployment is still a mystery

The mystery remains in this case as to how is the malware deployed in the AWS Lamba environments. Cado Security has not identified any method yet but suspects it may be a matter of compromising AWS Access and secret keys then manually deploying the malware into the compromised AWS Lambda environments.

How to protect your organization from Denonia

While the method used to deploy the Denonia remains unknown for the moment, it is important to take appropriate measures to bring more security to avoid it.

The AWS shared responsibility model applies to data protection in AWS Lambda, and it is responsible for protecting the global infrastructure that runs all of the AWS Cloud. But the user is fully responsible for maintaining control over his or her content that is hosted on the Amazon infrastructure. This includes the security configuration and management tasks for the AWS services that the user rents.

• AWS account credentials must be kept securely and not be shared. Individual user accounts with AWS Identity and Access Management (IAM) must be carefully set up, in the sense that every user should only be allowed to access the services he or she needs for their job activities. No extended privileges should be allowed.
• Multi-factor authentication should also be activated for every account.
• SSL/TLS (1.2 or later) protocols should be used to communicate with AWS resources.
• API and user activity logging should be enabled with AWS CloudTrail.

All the hardware used to access AWS Lamba should also always be up to date, and the operating system and software should be patched to lower the risk of being infected by malware while working with AWS.

Disclosure: I work for Trend Micro, but the views expressed in this article are mine.