Security researchers at Cado Security, a cybersecurity forensics company, recently discoveredthe first publicly-known malware targeting Lambda, the serverless computing platform of Amazon Web Services (AWS).
Though Lambda has been around for less than ten years, serverless technology is considered relatively young, according to Matt Muir, one of Cado’s researchers. Because of this, security measures for such a technology is often overlooked.
This lack of oversight has now bore fruit.
The malware in question, dubbed “Denonia,” is a cryptominer, which is software that allows the mining of cryptocurrency on computers and servers. The malware’s name is inspired by the domain the threat actors behind the cryptominer communicate with.
A cryptominer may not be among the ranks of ransomware, worms, and general Trojans. Still, the possibility of them taking advantage of Lambda is already here; a Pandora’s Box that can no longer be sealed.
Denonia is a Go-based wrapper that contains a modified version of the popular, open-sourced cryptomining software, XMRig.
Though not inherently malicious, XMRig came into prominence after an increase in cryptojacking was recorded in mid-2017, most of which was attributed to XMRig activity maliciously mining Monero. Since then, it has gained the reputation of being the miner of choice of cryptojackers.
Denonia uses a unique evasion technique around address resolution to hide its command and control (C2)domain and traffic, making it difficult to detect using typical measures while making communicating with other servers easier. We have yet to find the actors behind Denonia as they left behind little forensic clues.
Because of these, Cado researchers think the actors behind such attacks possess advanced cloud-specific knowledge to take on a complex infrastructure. Thankfully, this cryptominer has limited distribution.
It’s unknown how actors deploy Denonia, but the researchers suspect that they likely used stolen or leaked AWS access and secret keys, which has happened before. AWS confirmed that actors didn’t breach Lambda via a vulnerability, saying in a follow-up statement to VentureBeat: “the software described by the researcher does not exploit any weakness in Lambda or any other AWS service.”
“The software relies entirely on fraudulently obtained account credentials,” the statement continues. It also stresses that Denonia shouldn’t be considered malware “because it lacks the ability to gain unauthorized access to any system by itself.”
“What’s more, the researchers even admit that this software does not access Lambda — and that when run outside of Lambda in a standard Linux server environment, the software performed similarly.”
The researchers explained in their post how this is possible: “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.”
Can organizations protect against Denonia and other Lambda-focused attacks?
Lambda is becoming popular because its cheap to run and easier to maintain. Organizations only have to pay for its runtime, not a full server to run their applications. This is a huge money-saver, allowing organizations to allocate money they saved to other matters that may need more financial support.
When it comes to security, however, serverless environments have some catching up to do.
A good starting point for organizations is to secure root credentials and access keys. This is in accordance with AWS’s shared responsibility model, wherein AWS is responsible for taking care of and securing Lambda, but organizations are responsible for securing their own content and functions (programs or scripts) that run on Lambda.
- Refrain from using root access to perform daily tasks. Instead, use it only to (1) create an AWS IAM (Identity and Access Management) admin user account or (2) carry out access and account management tasks.
- Lock away your root access credentials.
- Use a strong AWS root account password. (We have a podcast about that!)
- Enable multi-factor authentication (MFA)on your AWS root account.
- If you have an access key for your AWS root account, delete it. If you must keep it, change the access key regularly.
- Never share your AWS root credentials or access key with anyone.
- Encrypt your data. AWS has an encryption solutionyou can use.
- Use TLS 1.2 or later to communicate with your AWS resources.