Denonia on AWS Lambda shows how cloud credentials become malware entry points

At a glance

What this is: This is an analysis of Denonia malware targeting AWS Lambda, where stolen AWS access and secret keys were used to deploy malware into serverless environments and hide command traffic with DNS over HTTPS.

Why it matters: It matters because serverless workloads still depend on NHI controls, and stolen credentials, temporary execution paths, and weak entitlement visibility can turn cloud identity exposure into direct runtime compromise.

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.

👉 Read SentinelOne's analysis of Denonia malware targeting AWS Lambda

Context

Denonia shows how AWS Lambda can become an execution surface when cloud credentials are exposed. In serverless environments, the application owner still controls the identity that can deploy code, invoke functions, and reach supporting services, so compromised access and secret keys can turn ordinary administration into malware placement.

The governance gap is not the function model itself, but the identity model around it. If teams cannot see which credentials can create or modify Lambda workloads, or whether those credentials are still valid, then serverless security becomes an entitlement problem before it becomes a malware problem.

Key questions

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. Attackers do not need to exploit the function code itself if they can authenticate through a valid NHI path. That is why deployment privileges must be treated as high-risk access, not ordinary admin convenience.

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. If those identities are over-privileged or exposed, attackers can deploy code, reach data, and hide activity inside trusted cloud APIs. Governance has to follow the identity, not the runtime model.

Q: What do security teams get wrong about ephemeral cloud runtimes?

A: They often assume short-lived execution reduces the need for deep monitoring. In reality, malware only needs a brief window to run, call out, and stage output. If telemetry is weak, the workload can finish before defenders notice, especially when traffic is encrypted or disguised as normal web activity.

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.

Technical breakdown

How Denonia reached AWS Lambda through compromised cloud credentials

Denonia is described as having been manually deployed after attackers compromised AWS access and secret keys. That matters because Lambda does not need an inbound listener to be abused. If an attacker can authenticate with valid cloud credentials, they can create or modify functions through normal management APIs, which makes identity the initial control plane rather than the network perimeter. In practice, the deployment path looks legitimate from the platform’s point of view even when the intent is malicious.

Practical implication: inventory who can deploy or modify Lambda functions and treat those credentials as privileged NHI access.

Why DNS over HTTPS matters in serverless malware detection

The sample used DNS over HTTPS, or DoH, to send name-resolution traffic inside regular HTTPS requests. That hides command-and-control style lookups from defenders who rely on classic DNS inspection alone. In a serverless context, this is especially awkward because function execution is short-lived and may only expose a small telemetry window. The result is a blend of trusted cloud execution and encrypted outbound lookups that looks like normal web traffic unless detection is tuned for it.

Practical implication: correlate serverless runtime logs with outbound HTTPS destinations, not only DNS logs.

Why writable ephemeral storage becomes an abuse path in Lambda

The malware wrote a config file into /tmp, the writable directory available in Lambda execution environments, and then launched XMRig to mine Monero. Ephemeral storage is intended for transient runtime state, but malware can use the same space for persistence within the lifetime of the container and for staging operational data. That creates a narrow but real abuse window: even if the function is short-lived, the attacker can still run meaningful payloads before the environment is recycled.

Practical implication: monitor /tmp usage patterns and outbound mining-pool connections in Lambda workloads.

Threat narrative

Attacker objective: The attacker objective was to persist long enough inside serverless infrastructure to mine Monero while staying hidden behind legitimate cloud identities and encrypted traffic.

1. Entry occurred when attackers are suspected to have obtained AWS access and secret keys and used them to reach the Lambda control plane.
2. Escalation followed when the attackers manually deployed Denonia into compromised AWS Lambda environments and used DoH traffic to mask command resolution.
3. Impact came from XMRig execution inside the serverless runtime, which converted cloud compute into unauthorized cryptocurrency mining infrastructure.

Breaches seen in the wild

• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Standing cloud credentials create a direct malware deployment path. AWS Lambda does not reduce identity risk if the credentials that manage it remain broadly usable. Once those keys are exposed, an attacker can turn routine provisioning into code execution without needing traditional exploitation. The practical conclusion is that serverless workloads inherit the risk of every long-lived access key behind them.

Ephemeral execution does not eliminate operational abuse. The use of /tmp and short-lived runtime state shows that malware does not need durable persistence to be effective in Lambda. It only needs enough execution time to run payloads, communicate, and generate value. That makes detection on runtime behaviour and egress patterns more important than assumptions about container lifetime.

Identity blast radius, not workload count, is the useful metric here. One compromised cloud principal can affect multiple functions, accounts, and downstream services if its permissions are not tightly scoped. This is why NHI governance has to measure what a credential can reach in practice, not just whether the workload is serverless. Practitioners should re-evaluate the effective blast radius of every Lambda-adjacent identity.

DoH is a reminder that malicious cloud traffic will increasingly look like normal SaaS traffic. When malware hides its lookups inside HTTPS, perimeter controls lose a signal they once relied on. The governance implication is that identity-aware telemetry and cloud-native detection need to carry more of the burden for spotting misuse. Security teams should assume encrypted egress from serverless workloads is not benign by default.

From our research:

• 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.
• That pattern is why the NHI Lifecycle Management Guide matters for serverless access, ownership, and offboarding decisions.

What this signals

Identity blast radius: serverless compromise is increasingly a question of how far one principal can reach, not whether the runtime is ephemeral. Teams should measure Lambda-adjacent credentials by deployment scope, secret access, and downstream service reach, then link those findings to the NIST Cybersecurity Framework 2.0.

With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey, the broader pattern is clear: access decisions are drifting away from human-equivalent restraint. Serverless governance will need to assume the same entitlement inflation unless owners actively constrain it.

The operational next step is to treat cloud identities that can modify functions as high-value assets, not background plumbing. That means tighter ownership, stronger telemetry, and explicit lifecycle controls around every role or key that can touch Lambda deployment paths.

For practitioners

• Map Lambda deployment privileges to NHI owners Identify every service account, IAM role, and secret that can create or modify Lambda functions. Assign an owner, review use frequency, and remove any role that can reach serverless deployment APIs without a clear business need.
• 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. Replace long-lived access keys with temporary role-based access where possible, and revoke dormant credentials that still touch Lambda.
• Add Lambda-specific detection for encrypted outbound traffic Correlate function execution with outbound HTTPS destinations, DoH resolvers, and uncommon port usage. Build alerts for serverless workloads that contact mining pools, resolve new domains, or write unexpected files into /tmp.
• Review shared responsibility assumptions for serverless identities Document which identity controls are owned by the customer and which are inherited from the cloud provider. Use that review to close gaps in entitlement visibility, credential hygiene, and function-level monitoring.

Key takeaways

• Denonia demonstrates that AWS Lambda abuse starts with compromised cloud credentials, not with a traditional exploit chain.
• The scale of the issue is broader than one sample, because serverless platforms still expose standing identity and telemetry gaps.
• Teams that can map and restrict Lambda deployment access reduce the blast radius before malware can execute.

Key terms

• Serverless Identity: The set of roles, keys, tokens, and permissions that allow a serverless function to deploy, invoke, and reach other services. In practice, it is the real control surface for Lambda security because the runtime itself is only as safe as the identity behind it.
• Identity Blast Radius: The amount of damage a single credential or role can cause once it is abused. For serverless workloads, the blast radius is measured by what a principal can deploy, read, modify, or trigger across functions, secrets, and downstream cloud services.
• DNS Over HTTPS: A way to send DNS lookups inside encrypted HTTPS requests instead of standard DNS traffic. It improves privacy in normal use, but it also gives malware a way to hide command resolution and domain lookups from defenders who only inspect classic DNS logs.
• Ephemeral Runtime Abuse: Misuse of a short-lived execution environment to run payloads, stage data, or communicate with an attacker before the container disappears. The short lifetime changes persistence options, but it does not stop malicious code from carrying out meaningful actions.

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.

👉 SentinelOne's full post covers the Denonia execution path, DoH behaviour, and identity-based detection ideas.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.