Topic starter
12/07/2026 12:24 pm
TL;DR: Denonia is described as the first malware built to target AWS Lambda, with attackers suspected of using compromised AWS access and secret keys to deploy it, then hiding command traffic through DNS over HTTPS while mining Monero, according to SentinelOne. The real lesson is that serverless security still collapses when standing cloud credentials and weak identity visibility meet.
Editorial analysis by NHI Mgmt Group, based on content published by SentinelOne: “Denonia Malware Targets AWS Lambda Environments”.
Key questions
Q: What breaks when AWS access keys can deploy serverless code?
A: When access keys can deploy Lambda code, the cloud control plane becomes the attacker’s execution path.
Q: Why does DNS over HTTPS make cloud malware harder to spot?
A: DNS over HTTPS hides name resolution inside encrypted HTTPS traffic, so defenders lose an easy inspection point and many allow rules see only benign-looking web egress.
Q: What signs suggest a Lambda workload is being abused for mining?
A: Look for repeated short-lived invocations, unexpected writes to temporary storage, outbound connections to mining pools, and resolver activity that does not match the workload’s normal application profile.
Practitioner guidance
- Tighten Lambda deployment roles Separate deployment, invocation, and administration permissions so no single credential can both modify functions and operate them broadly.
- Adopt short-lived AWS credentials Replace reusable access keys with temporary role credentials wherever serverless workflows permit it, and review any exception paths that still rely on long-lived secrets.
- Monitor for DoH and mining traffic Alert on Lambda workloads that resolve through public DoH services, contact unusual resolver domains, or egress to cryptocurrency-mining pools on ports associated with mining.
Bottom line: Denonia shows how stolen AWS access and secret keys can turn Lambda into an execution target for malware rather than a protected backend.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
12/07/2026 12:37 pm
Credentialed Lambda abuse is an identity failure before it is a malware failure: The article shows that serverless compromise begins when cloud access keys or role credentials are exposed, not when malware reaches the function runtime. That means the security boundary sits in the identity plane, where deployment authority and invocation rights live. Practitioners should treat Lambda execution rights as privileged access, not as routine application plumbing.
A question worth separating out:
Q: Should IAM teams treat serverless credentials differently from ordinary app secrets?
A: Yes. Serverless credentials can directly create, modify, or invoke runtime code, so they carry execution authority rather than simple API access. IAM teams should classify them as high-risk identity assets, apply tighter lifecycle controls, and review whether any role can still be reused manually outside an approved deployment path.
👉 Read our full editorial: Denonia on AWS Lambda shows how cloud credentials become malware entry points