Well it’s not unheard of, that security issues, malware or exploits often follow soon after an emerging technology finds prominence.

Denonia, the first Lambda malware is out.

Originally discovered by Cado Labs a few days ago, Denonia specifically targets Lambda functions with the intent to deploy code that carries out bitcoin mining, hence significantly increasing AWS costs for the impacted organisation.

Let’s break this down a little now.

What is Lambda?

Lambda (or Lambda Functions) is an AWS service that helps it’s customers run applications without using servers. Such a deployment or mechanism of running applications is also called serverless. Organisations can choose from a variety of platforms such as Python, Go, NodeJS to develop their applications and then deploy them on Lambda.

There are various reasons Lambda Functions are considered a tad more secure than traditional VM based or hardware based deployments, here are some:

Reduced Attack Surface

Lambda Functions consist of two key parts – the code, and the underlying infrastructure. Needless to say, the code is the owner’s responsibility. However, owing to the AWS Shared Responsibility Model, AWS is responsible for protecting the infrastructure running its services. 

Fine Grained Permissions

AWS Lambda operates with IAM Roles (much like all AWS services). This gives infrastructure or DevOps teams a chance of permitting access to a very specific set of resources and associated actions as required by the Lambda functions. More on this can be found in AWS documentation here.

Reduced Execution Time

Unlike traditional runtime environments, the maximum execution time of a Lambda function is 15 minutes. Lesser the execution time, lesser are the chances of a malware getting successfully executed and establishing Command & Control. But this has changed with the recent discovery that we’ll talk about a little more in this post.

What is Denonia anyway?

Denonia is a malware written in “Go” and designed to execute on AWS lambda functions to act as Monero cryptocurrency miners. It is as simple as that. 
 
Well, at least on the surface.
 
It’s named after the domain that acts as its C2 (Command & Control) server which is gw[.]denonia[.]xyz
 
Like with any crypto miner program, this is meant to consume significant infrastructure resources. If this hits your infrastructure, you will get charged with unwanted processing time of lambda and moreover, the attackers are going to get rich at your cost!

Technical Details 

Denonia is a 64-bit ELF executable targeting the x86-64 lambda architecture. 
 
For now, it most likely seems that attackers get access to victim’s lambda functions through stolen credentials or keys.
 
It uses DNS over HTTPS (DoH),  via some third-party Go libraries publicly available on Github and a customised variant of the XMRig mining software.
 
What DoH does – it encrypts DNS queries (quite opposite to how DNS operates, which is sending unencrypted queries to DNS resolver). It then sends the requests out as regular HTTPS traffic to DoH resolvers preventing typical IPS / IDS systems to catch malicious domains through DNS lookups. 
 
Here the malware uses doh-go module for the same DNS over HTTPS.
 
After the attacker has deployed the package to the function, the malware sends requests to the google DoH server to resolve gw[.]denonia[.]xyz to an IP address (dynamic) as shown in the image.
 
denonia dns resolution
 
It then writes the IP address to /tmp/.xmrig.json.
 
Then it runs XMRig and communicates with the mining pool at :3333 picking up the IP address resolved earlier.
 
Voila! The malware then begins mining, eating away lambda resources and increasing AWS costs.
 

Preventing Denonia

Denonia runs on Lambda, and an attacker requires elevated access to deploy the malware as a Lambda function.

One of the ways to do this, is by using compromised AWS access credentials (or AWS access keys) and creating a Lambda function with the malware code. 
 
This would not only require a valid set of AWS access keys, but would also permissions to create and deploy Lambda functions.
 
Let’s look at how we can prevent such an exploit in the first place.

Limit Access Keys

Access keys are the keys to your kingdom. Guard these like you would guard your gold.
 
  • Avoid storing these in code.
  • Avoid creating multiple access keys unless absolutely necessary.
  • Use short lived credentials instead.

Fine Grained Permissions

Lambda creation and deployment permissions are permissive in nature and should be granted to infrastructure, DevOps teams; or CI/CD pipelines only.
 
  • Grant permissive access to IAM roles or users in a restrictive manner.
  • Avoid using “FullAccess” policies.
  • Use fine grained IAM policies where possible, restricting access to Actions as well as Resources

Detecting Denonia

Preventive security controls are good, but not always enough. Adversaries find way into organisations by flying under the radar and exploiting available permissions or resources.


It is always a good idea to complement preventive security controls, with ones that can detect compromise or unusual activity.

Let’s see how detective controls can work towards catching Denonia.

For this malware, we are going to analyse VPC flow logs assuming the Lambda function is configured in a VPC and the VPC has flow logs enabled.

After the malware has resolved the gw[.]denonia[.]xyz domain to it’s corresponding ip address and written it in the /tmp directory, it sends a request at port 3333 (XMRig mining pool) of the same IP address which gets logged in VPC Flow logs.

Hence, any request to port 3333 should be a red flag – this is a port that’s not very commonly used. 

A sample VPC flow log for such a communication is as below.

2 123456789010 eni-1235b8ca123456789 172.31.16.139 116[.]203[.]4[.]0 20641 3333 6 20 4249 1418530010 1418530070 ACCEPT OK

Beyond Standard Detection

We looked at some very simple means of detecting Denonia. However, attackers are smart and would evolve to fly under the radar by establishing connections over benign ports such as 443 or 80, which are commonly used for HTTP traffic. This makes the job harder for security analysts to catch malicious communication.

Well, it’s not all bad news.

Detection techniques have also evolved with next generation threat detection systems. Such systems can now flag unusual activity based on past trends and traffic patterns.

For example, in case of Denonia, one could look for the below behavior:

  • Excessive outbound connections to multiple geo locations
  • Unusual number of outbound connections
  • Increase in traffic volume
  • Anomalous increase in AWS Lambda cost (via AWS billing alarms)

Cy5 ion to Detect & Prevent Denonia

ion – Cy5’s flagship cloud security product ships with 200+ security configuration checks and threat detection use cases. Let’s look at how some of these can help prevent or catch Denonia early on in it’s game.

Via Cloud Security Checks

Here are some configuration checks that can alert on overly provisioned IAM policies or excessive access keys usage.

cloud security checks

On drilling down, one can investigate the policies that are being flagged. Apart from others, one can see here that the policy “LambdaFullAccess” is in use. The role(s) or user(s) using this policy would have permissive access on Lambda.
lambda full access policy

Via Threat Detection

There are various ways to detect malware communication, leveraging VPC flow logs. ion’s threat detection modules ships with the below use cases that can help with this:

malware detection

Here is a sample rule to catch outbound communication on port 3333:

Conclusion

Though Denonia is a new malware and a first that targets AWS Lambda, it’s deployment and execution tactic exploits weaknesses that have been known and around for a while. Implementing IAM best practices and leveraging detection technology that can catch standard and advanced threats is key to preventing such malware from making way into a public cloud ecosystem. 

We hope this post was helpful, stay updated with the latest in cloud security by subscribing to our newsletter.