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

At a glance

What this is: This analysis says Denonia malware targeted AWS Lambda by abusing compromised AWS access and secret keys, then used DNS over HTTPS and XMRig to mine Monero.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern serverless access as an identity problem, not just a workload-security problem, when stolen cloud credentials can become malware entry paths.

Context

AWS Lambda is a serverless compute service, which means code runs in response to events without a managed server for the operator to harden in the usual way. That shifts the security question from host control to identity control, because access to the function environment is gated by cloud credentials, roles, and secrets.

SentinelOne’s source article frames Denonia as a cloud malware case, but the governance issue is broader: if access keys or role credentials are stolen, serverless becomes a deployment surface for attacker code. That is a NHI control problem as much as a cloud runtime problem, because the initial trust boundary sits in the credential estate.

The article’s starting position is typical of cloud incidents that rely on reused or overexposed credentials, not an exotic exception. Once identity is compromised, the attacker can treat serverless infrastructure as just another execution target.

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. That breaks the assumption that serverless is insulated from abuse because no server is owned directly. The real failure is over-privileged identity, which lets stolen credentials become deployment authority and turns ordinary application access into malware delivery.

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. That increases the value of behavioural detection, resolver allowlisting, and outbound policy enforcement, especially for serverless workloads that legitimately use web connectivity.

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. Those signals matter because Lambda abuse often aims for low-friction monetisation, not obvious persistence or lateral movement.

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.

Technical breakdown

How compromised cloud credentials become Lambda execution access

AWS Lambda does not need a traditional shell compromise to be abused. If an attacker has valid AWS access keys or role credentials, they can use normal API operations to deploy code, invoke functions, or alter supporting resources. In this case, the article says the malware was manually deployed into compromised Lambda environments, which implies credentialed control of the cloud account or function deployment path. The key technical point is that serverless runtime isolation does not protect against authenticated control-plane abuse. The identity plane remains the gatekeeper, and once it is breached, the attacker can place code where the platform will execute it for them.

Practical implication: control who can assume deployment roles and treat function-deployment permissions as high-risk NHI privileges.

Why DNS over HTTPS helps malware blend into cloud traffic

DNS over HTTPS, or DoH, wraps name resolution inside encrypted HTTPS requests. That makes the traffic look like ordinary web traffic to many network controls, even though it is being used to resolve attacker-controlled infrastructure. In the Denonia case, the sample queried public DoH resolvers and then communicated with the resolved host from the Lambda environment. The architectural point is not that DoH is inherently malicious. It is that encrypted name resolution can remove one of the easiest detection signals available to defenders, especially when the workload itself is expected to make outbound web requests.

Practical implication: inspect egress patterns and resolver use, not just destination IPs, when monitoring serverless workloads.

Why Lambda makes malicious persistence and mining operationally cheap

Lambda functions have constrained writable storage and short-lived execution patterns, so attackers often adapt their tooling to those limits. The article says Denonia wrote configuration data to /tmp, used XMRig to mine Monero, and communicated with a mining pool on port 3333. That shows how malware can repurpose the ephemeral runtime for opportunistic abuse without needing classic persistence techniques. In serverless environments, the attacker’s goal is often not durable host ownership but repeated execution and monetisation while access lasts. That changes what defenders should expect to observe.

Practical implication: watch for short-lived but repeated invocation patterns, unusual outbound mining traffic, and temporary-file abuse in Lambda.

Threat narrative

Attacker objective: The attacker’s objective was to covertly mine Monero from AWS Lambda using stolen cloud credentials as the execution path.

1. Entry appears to have started with compromised AWS access and secret keys, which gave the attacker authenticated control over the Lambda environment.
2. The attacker then manually deployed Denonia into the compromised serverless runtime and used DNS over HTTPS to reach attacker-controlled infrastructure.
3. The malware wrote configuration data to /tmp, launched XMRig, and connected to a Monero mining pool on port 3333.
4. The impact was covert cryptocurrency mining from a trusted cloud workload while hiding command traffic inside normal HTTPS flows.

Breaches seen in the wild

• Codefinger S3 ransomware 2025: Codefinger used victims' compromised AWS keys to re-encrypt S3 buckets with SSE-C, set 7-day deletion and demanded ransom for the key.
• AI LLM hijack breach: attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

DoH creates an observability gap that weakens cloud runtime assurance: Denonia’s use of DNS over HTTPS shows how attackers can hide control traffic inside ordinary HTTPS flows. That does not make the traffic invisible, but it removes a simple DNS-layer signal many teams still depend on. The implication is that egress governance must look at behaviour, not only destination reputation.

Cloud credentials become malware entry points when standing privilege outlives operational need: The specific failure mode here is credential availability without tight runtime scoping. Once AWS access and secret keys can be reused manually, serverless becomes an attacker-controlled execution layer. The practitioner conclusion is straightforward: identity lifecycle controls, not just workload hardening, determine whether Lambda can be turned into an abuse platform.

Serverless security now depends on identity visibility across the whole cloud estate: The article links deception, identity threat detection, and entitlement visibility because attackers move through the same access paths defenders use. That is why NHI governance and cloud security can no longer be separated in practice. Teams need a single view of who and what can deploy, invoke, and modify serverless functions.

Identity blast radius is the right concept for this class of attack: Once a credential reaches Lambda deployment or invocation scope, the attacker’s usable surface is defined by the permissions attached to that identity, not by the application code itself. That shifts risk management from patch-centric thinking to entitlement-centric thinking. The practical conclusion is to cap the blast radius of every cloud credential that can touch serverless.

What this signals

Cloud credentials now sit on the malware path: The Denonia case shows that serverless compromise is often an identity event first, because stolen AWS credentials can be used to place code directly into Lambda. That makes access governance, not just runtime monitoring, the control boundary practitioners need to defend.

Identity blast radius is the operational metric that matters: If one stolen credential can deploy functions, invoke them, and support outbound abuse, the privilege model is too wide for serverless. Teams should measure how far a single cloud identity can reach across deployment, invocation, and supporting services.

DoH and ephemeral storage are not the core problem, but they change detection priorities: When malicious traffic rides over HTTPS and the payload lives in temporary runtime space, the detector must follow behaviour rather than file artefacts. That pushes cloud monitoring toward egress policy, entitlement review, and workload identity inspection.

For practitioners

• 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.
• Hunt for credential reuse across cloud accounts Check whether the same AWS access key or secret has been used from endpoints, CI pipelines, and serverless deployment paths, then revoke anything that shows cross-environment reuse.
• Use deception to expose credential misuse Place decoy access keys and cloud resources where an attacker who steals credentials is likely to touch them before they reach production Lambda functions.

Key takeaways

• Denonia shows how stolen AWS access and secret keys can turn Lambda into an execution target for malware rather than a protected backend.
• The article’s evidence combines credential abuse, DoH traffic, /tmp configuration writes, and Monero mining, which is enough to treat the incident as an identity-led cloud abuse pattern.
• The control that would have mattered most is tighter entitlement scoping around serverless deployment and invocation rights, backed by short-lived credentials and better identity visibility.

Key terms

• Serverless Runtime API: The serverless runtime API is the interface a function runtime uses to receive the next invocation event and return results. In AWS Lambda, access to this API can expose request data and execution context, so abuse of the runtime endpoint can affect both confidentiality and integrity.
• DoH: DNS over HTTPS, or DoH, is a method of sending DNS queries inside encrypted HTTPS traffic. It can improve privacy, but it also reduces visibility for defenders when threat actors use it to hide command-and-control lookups or blend malicious resolution into normal web traffic.
• Cloud Control Plane Integration: The ability for a security platform to connect directly to cloud provider management interfaces and read operational data without installing software on every workload. This approach improves coverage in cloud environments by using native infrastructure visibility instead of relying only on host-level tooling.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.