By Matt Muir, with thanks to Chris Doman, Al Carchrie and Paul Scott.
Organisations – both large and small – are increasingly leveraging Lambda serverless functions. From a business agility perspective, serverless has significant benefits. Lambda also brings security benefits - the managed runtime environment reduces the attack surface compared to a more traditional server environment. 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. Under the AWS Shared Responsibility model, AWS secures the underlying Lambda execution environment but it is up to the customer to secure functions themselves.
Cado Labs routinely analyses cloud environments to look for the latest threats. As part of ongoing research, we found the first publicly-known case of malware specifically designed to execute in an AWS Lambda environment. We named this malware Denonia, after the name the attackers gave the domain it communicates with. The malware uses newer address resolution techniques for command and control traffic to evade typical detection measures and virtual network access controls. Although this first sample is fairly innocuous in that it only runs crypto-mining software, it demonstrates how attackers are using advanced cloud-specific knowledge to exploit complex cloud infrastructure, and is indicative of potential future, more nefarious attacks. From the telemetry we have seen, the distribution of Denonia so far has been limited.
Technical Analysis
We initially came across a sample of Denonia with the following SHA-256 hash:
Whilst it has the filename “python” - the malware is actually written in Go and seems to contain a customised variant of the XMRig mining software, along with other unknown functions. We decided to investigate further.
During dynamic analysis, the malware quickly halted execution and logged the following error:
This piqued our interest as these environment variables are specific to Lambda, giving us some hints about the environment in which this malware is expected to execute. Reviewing the binary further, we could see that it was a 64-bit ELF executable targeting the x86-64 architecture and that it uses a number of third-party libraries, including one specifically to enable execution inside AWS Lambda environments.
A Note on Go Malware
Malware written in Google’s Go programming language has become increasingly prevalent in recent years. The language is attractive to malware developers for a number of reasons, including the ease in which it can produce cross-compatible executables and the efficient deployment that statically-linked binaries bring. However, these characteristics of the language can pose some challenges to malware researchers analysing binaries compiled from Go.
Firstly, statically-linked binaries are typically much larger than dynamically-linked equivalents - this makes static analysis slightly more laborious. Go also handles strings in an unusual way. Strings are not null-terminated, as they are in C-like languages, instead they are stored in a large blob and a struct which includes both a pointer to the string in the blob and an integer defining its length is created upon declaration. This can confuse some static analysis tools.
Analysing Lambda Malware
Analysing a binary designed to run in AWS Lambda poses some interesting challenges.
Whilst Denonia is clearly designed to execute inside of Lambda environments - we haven’t yet identified how it is deployed. It may simply be a matter of compromising AWS Access and Secret Keys then manually deploying into compromised Lambda environments, as we’ve seen before with more simple Python scripts.
Using the redress tool we identified some interesting third-party Go libraries that the malware embeds. This gave us some clues about its functionality:
We can see a snippet of the Lambda function handler below, which expects certain data to be set:
Despite the presence of this, we discovered during dynamic analysis that the sample will happily continue execution outside a Lambda environment (i.e. on a vanilla Amazon Linux box). 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.
DNS over HTTPS
Normally when you request a domain name such as google.com, you send out an unencrypted DNS request to find the IP Address the domain resolves to - so your machine can connect to the domain. A relatively modern replacement for traditional DNS is DNS over HTTPS (DoH). DoH encrypts DNS queries, and sends the requests out as regular HTTPS traffic to DoH resolvers.
Using DoH is a fairly unusual choice for the Denonia authors, but provides two advantages here:
We can see the malware sending these requests using the “doh-go” library to URLs such as:
And the DoH server (in this case from Google) responds with the IP the domain resolves to in a JSON format:
Writing this to /tmp/.xmrig.json for XMRig
The attacker controlled domain gw.denonia[.]xyz resolves to 116.203.4[.]0 - which is then written into a config file for xmrig at /tmp/.xmrig.json:
Note that on AWS Lambda, the only directory that you can write to is /tmp. The binary also sets the HOME directory to /tmp with “HOME=/tmp”. XMRig itself is executed from memory.
Communication with the Monero server at 116.203.4[.]0
Denonia then starts XMRig from memory, and communicates with the attacker controlled Mining pool at 116.203.4[.]0:3333:
Which replies with the status of the mining job:
XMRig also writes to the console as it executes:
More Malware Samples
Interestingly - this isn’t the only sample of Denonia. Whilst the first sample we looked at dates from the end of February, we also found a second sample that was uploaded to VirusTotal in January 2022:
Stay tuned for additional blogs on Lambda malware!
Investigating AWS Lambda Environments
This week we added the ability to investigate and remediate both AWS ECS and AWS Lambda environments to Cado Response. You can get a free playbook on how to investigate and respond to compromises in ECS here, and a free trial of the platform itself here.
For more on securing AWS Lambda environments, see the Whitepaper from AWS.
Indicators of Compromise
rule lambda_malware
{
meta:
description = "Detects AWS Lambda Malware"
author = "cdoman@cadosecurity.com"
license = "Apache License 2.0"
date = "2022-04-03"
hash1 = "739fe13697bc55870ceb35003c4ee01a335f9c1f6549acb6472c5c3078417eed"
hash2 = "a31ae5b7968056d8d99b1b720a66a9a1aeee3637b97050d95d96ef3a265cbbca"
strings:
$a = "github.com/likexian/doh-go/provider/"
$b = "Mozilla/5.0 (compatible; Ezooms/1.0; help@moz.com)"
$c = "username:password pair for mining server"
condition:
filesize < 30000KB and all of them
}
IOCs
| SHA256 |
| 739fe13697bc55870ceb35003c4ee01a335f9c1f6549acb6472c5c3078417eed |
| a31ae5b7968056d8d99b1b720a66a9a1aeee3637b97050d95d96ef3a265cbbca |
| Domains |
| denonia[.]xyz |
| ctrl.denonia[.]xyz |
| gw.denonia[.]xyz |
| 1.gw.denonia[.]xyz |
| www.denonia[.]xyz |
| xyz.denonia[.]xyz |
| mlcpugw.denonia[.]xyz |
| IP Addresses |
| 116.203.4[.]0 |
| 162.55.241[.]99 |
| 148.251.77[.]55 |