Cryptocurrency-mining AWS Lambda-specific malware spotted • The Register

Cado Security says it has discovered a strain of malware specifically designed to run in AWS Lambda serverless environments and mine cryptocurrency.

The team admitted it doesn't quite know how the software nasty, dubbed Denonia, is deployed, though you're welcome to take a guess.

"It may simply be a matter of compromising AWS access and secret keys then manually deploying into compromised Lambda environments," Cado's Matt Muir suggested in a technical write-up on Wednesday.

While the security firm has only seen the malware running in AWS Lambda, it can be made to run in other Linux-flavored environments, Cado Security CTO and co-founder Chris Doman told The Register this week.

And although Denonia isn't being used, as far as we know, for anything worse than illicit mining activities, "it demonstrates how attackers are using advanced cloud-specific knowledge to exploit complex cloud infrastructure, and is indicative of potential future, more nefarious attacks," wrote Muir, who thanked Doman, Al Carchrie and Paul Scott for their help in probing the code.

When asked about Denonia, an AWS spokesperson told us it's pretty much on you, the customer, as to what runs in your cloud environment:

Under Amazon, and other cloud providers', shared-responsibility security model, AWS secures the underlying environment — Lambda, in this case — while the customer is responsible for securing their own data and the Lambda functions themselves. In other words, if you get Denonia in your Lamba environment, you probably didn't safeguard or protect it fully.

Muir highlighted Lambda's security benefits. "The managed runtime environment reduces the attack surface compared to a more traditional server environment," he wrote.

"However, short runtime durations, the sheer volume of executions, and the dynamic and ephemeral nature of Lambda functions can make it difficult to detect, investigate and respond to a potential compromise."

Inside the code

Cado said the malware sample it studied had a SHA256 hash of A31a...cbbca.

The code is written in Google's Go programming language, which Muir said is attractive to malware developers because it's easy to use to build cross-platform, self-contained statically linked executables. The resulting code can be a monolithic blob, making reverse-engineering laborious, and also strings aren't stored with C-style null terminators, which again makes studying the binary a little tedious.

In Cado's analysis, it appeared Denonia contained a customized variant of the Monero-mining XMRig "along with other unknown functions." During its dynamic analysis, Denonia stopped executing and logged an error about a Lambda AWS environment variable not being defined. That gave the Cado team a clue as to how this malicious software is supposed to be deployed.

As Muir noted:

Further analysis of Denonia in Cado's sandbox after manually setting the required environment variables showed that the software "will happily" execute outside of Lambda and in a Linux environment. Muir suggested that this is because Lambda is Linux based, "so the malware believed it was being run in Lambda."

The infosec team also noted that the malware includes several third-party Go libraries including tools for writing Lambda functions, helpers for retrieving contextual information from a Lambda invoke request, general AWS software development kits for Go, and DNS-over-HTTPS in Go.

This use of DNS-over-HTTPS (DoH) is interesting, Muir noted. DoH encrypts DNS queries and sends the domain name requests as regular HTTPS traffic, which is a "fairly unusual choice" for malware authors, he wrote. However, this approach provides a few benefits.

First, it prevents AWS from seeing the DNS lookups, which reduces the malware's chances of being detected and stopped from its domain-name queries. Also, depending on their VPC settings, some Lambda environments may not be able to do DNS lookups.

In this particular case, the malware sent a DoH request for gw[.]denonia[.]xyz to Google's DNS service, which returned an IP address for the domain. This information is saved in a configuration file. Denonia then executes XMRig from memory and it communicates with a mining pool, thus enabling the malware author to use the victim's cloud resources to mine for crypto.

Whose responsibility it is?

Third-party security analysts were mixed in their reactions to the Lambda malware research.

"There's nothing in the report to suggest AWS' infrastructure is vulnerable," wrote Casey Bisson, head of product and developer relations at code security company BluBracket, in an email to The Register.

If anything, it suggests that companies' implementation of security automation is lagging, he said, adding that better monitoring and automated secret management can help as it's likely any Lamba environments infected with Denonia were compromised via leaked tokens or keys.

"Lambda instances are plentiful and often poorly monitored, making them ripe for attack and potentially difficult to secure," Bisson said. "It's a similar circumstance to the plentiful, unmonitored, and poorly secured IoT devices that made the Mirai botnet possible."

Orca Security CEO Avi Shua echoed Bisson's call for automated scanning of code to help developers remove secrets that could be misused. He noted his cloud security firm's research on Lambda and the secrets it uses. "Almost 30 percent of Lambda functions contain secrets in their environment variables," Shua said in an email.

"These secrets can be keys, authorization tokens, passwords and everything that should be kept private," he added. "If stolen through malware, these secrets can also be used to access other connected areas like S3 buckets to reach PII and other crown jewel data."

Git

GitHub tackles leaks by scanning for secrets in pushed code

Other security analysts noted that Denonia shows continued confusion about the shared-responsibility security model — especially with newer computing models like serverless functions.

Shared responsibility "sounds great as an abstract notion," noted Oliver Tavakoli, CTO at AI security company Vectra in an email. But, he added, many organizations that use Lambda don't understand the security implications.

"It is the responsibility of the cloud service providers to educate their customers on these implications and to choose defaults that increase the likelihood of secure deployments over those which reduce deployment friction while exposing customers to poorly understood risk," he said.

John Bambenek, principal threat hunter at security operations firm Netenrich, said that while cryptomining is a "low-hanging fruit" for miscreants, this is the first time he's seen them specifically target Lambda environments.

"This incident exposes a blurry DMZ of the shared responsibility model," Bambenek said in an email. "While Amazon secures the Lambda environment and the customer secures their code and account credentials, the question is how are account takeovers handled? Amazon believes that's the customer responsibility, and many organizations believe Amazon should have some checks in place."

"Either way, it's probably a no-brainer for Amazon to simply detect and prevent cryptocurrency mining in their environment (except for those instances specifically designed for it)," he added. ®

Results for “"lambda-specific"”

Cryptocurrency-mining AWS Lambda-specific malware spotted