Denonia – Guide to Prevention & Detection

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

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.

 

 

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

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

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

Via Threat 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.