Denonia Malware Shows Evolving Cloud Threats
Cloud security is constantly evolving and consistently different than defending on-premises assets. Denonia, a recently discovered serverless cryptominer, drives home the point.
April 21, 2022
![Cryptocurrency, cryptomining Cryptocurrency, cryptomining](https://eu-images.contentstack.com/v3/assets/blt8eb3cdfc1fce5194/bltff3b5e40ad95ec05/6621124952b3bd0a8d881e02/GettyImages-1226860669.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
One of the more important points to get across when addressing cloud security is to make it clear to all involved that cloud security is not only different, but that it keeps evolving. If security professionals needed a reminder of this, they need to look no further than the recent discovery of Denonia, a cryptominer that operates in serverless environments.
Denonia was found by the Cado Security research team, and it released details a few days ago. Denonia is a Go-based cryptominer malware, and it appears to be the first such malware to specifically exploit AWS Lambda, the well-known serverless function execution service. The researchers indicate that Denonia was not widely disseminated and that it executes the XMRig mining software for stealing CPU cycles for mining Morero, while using techniques such as DNS-over-HTTPS (DoH) for evasion. The initial deployment mechanism is unknown but may be a matter of overprivileged environments.
While small in scope, Denonia is notable for its use of the cloud technology stack as intended —it's a Lambda function executing on a Linux environment like any other. This is interesting, as it means similar malware can execute in other serverless function execution environments from other cloud providers as well.
How the Vulnerabilities Differ
To be clear, this is different than some of the vulnerabilities that have been reported across major providers recently, such as ChaosDB (a flaw in Azure's CosmosDB service found by the Wiz security team last year), AWS CloudFormation and AWS Glue issues found by Orca Security, and some of the Google Cloud GKE vulnerabilities raised by the Palo Alto Networks Unit 42 security research team. In those cases, the cloud providers worked directly with the research teams to address those issues.
When discussing cloud security, too often we hear some confusion about security responsibilities. While cloud providers have worked to clarify some of this via their different "shared responsibility models," end-user organizations retain the overall responsibility for securing their cloud estates. Cloud providers are responsible for the structural security of the cloud environment itself, but customers are responsible for the workloads. This includes both ensuring that environments have been properly configured with the adequate mixture of configurations that yield capabilities and privileges — often the realm of cloud security posture management (CSPM) and cloud permissions management (CPM) offerings — and also ongoing monitoring of the multiple events taking place within those cloud estates, which may fall under cloud workload protection platforms (CWPP) or even cloud detection and response (CDR).
The lesson, then, to be learned from the discovery of Denonia is that cloud security keeps evolving: Runtime threats against an organization are not simply the same malware that would execute on a virtual machine but evolve into containers — indeed, exposed container management interfaces or those with poor authentication are often used to launch unauthorized workloads — and now serverless workloads. Organizations looking to address this dynamic need to have the right elements of people, processes, and technology to properly understand the new threat landscape, to look deeply into their cloud stack, and to work together with their cloud engineering and development teams.
This story was originally published on Dark Reading, a Data Center Knowledge sister publication.
About the Author
You May Also Like