Notifications
Clear all
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.
NHIMG editorial — based on content published by SentinelOne: Denonia malware targets AWS Lambda and uses DoH to hide command traffic
By the numbers:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: What breaks when AWS credentials can deploy malware into Lambda functions?
A: When credentials can create or modify Lambda functions, the serverless environment becomes an execution target rather than a protected service.
Q: Why do serverless workloads still need strict NHI governance?
A: Serverless does not remove identity risk because functions still depend on roles, keys, tokens, and permissions to operate.
Q: What do security teams get wrong about ephemeral cloud runtimes?
A: They often assume short-lived execution reduces the need for deep monitoring.
Practitioner guidance
- Map Lambda deployment privileges to NHI owners Identify every service account, IAM role, and secret that can create or modify Lambda functions.
- Rotate and scope cloud access keys used outside human login flows Prioritise keys that can deploy code, invoke functions, or access supporting storage and secrets services.
- Add Lambda-specific detection for encrypted outbound traffic Correlate function execution with outbound HTTPS destinations, DoH resolvers, and uncommon port usage.
What's in the full article
SentinelOne's full article covers the operational detail this post intentionally leaves for the source:
- The specific Lambda and cloud telemetry signals the vendor uses to spot suspicious function activity.
- The described deception and identity threat detection workflow for cloud baits and secret-key lures.
- The recommended containment steps after detecting anomalous AWS service usage.
- The full sequence of Denonia's deployment and Monero mining behaviour inside Lambda.
👉 Read SentinelOne's analysis of Denonia malware targeting AWS Lambda →
AWS Lambda malware and stolen credentials: what IAM teams need to know?
Explore further
12/07/2026 12:37 pm
Cloud function abuse is still an identity problem first. Denonia only became possible because attackers were believed to have valid AWS access and secret keys. That means the trust boundary failed at authentication and entitlement, not at the Lambda runtime itself. For practitioners, the lesson is that serverless security begins with NHI governance over who can deploy, invoke, and modify functions.
A few things that frame the scale:
- The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks.
A question worth separating out:
Q: How should organisations respond when a serverless access key is exposed?
A: Revoke the credential immediately, then identify every Lambda function, secret store, and deployment path it could reach. Check for suspicious function creation, unusual /tmp activity, and outbound DoH or mining traffic before you assume the exposure is contained.
👉 Read our full editorial: Denonia on AWS Lambda shows how cloud credentials become malware entry points
