AWS ransomware exposes the limits of CNAPP and traditional PAM

At a glance

What this is: This is an analysis of why AWS ransomware is increasingly an identity and privilege abuse problem, not a malware problem.

Why it matters: It matters because IAM, PAM, and cloud security teams need controls that limit standing access, constrain machine identities, and block malicious API use before damage occurs.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems.

👉 Read Sonrai Security's analysis of AWS ransomware and cloud privilege abuse

Context

AWS ransomware is the abuse of cloud identities and permissions to encrypt, delete, or lock data rather than spreading malware through a traditional payload. The security problem is not just detection, but whether IAM and PAM controls can stop valid credentials from being used in ways the business never intended.

Sonrai Security argues that cloud-native environments expand the attack surface because permissions accumulate across human and machine identities, and those entitlements are rarely enforced continuously. That makes least privilege, Just-in-Time access, and default-deny controls central to cloud identity governance, especially where machine identities now carry operational power.

Key questions

Q: What breaks when AWS identities have standing privilege?

A: Standing privilege turns cloud administration into an attacker opportunity because the same rights used for operations can be used to encrypt, delete, or lock data. In practice, a compromised identity does not need malware, only the permissions to act. Organisations should treat destructive cloud permissions as high-risk access that must be time-scoped and continuously enforced.

Q: Why do CNAPP tools not stop cloud ransomware on their own?

A: CNAPP tools are useful for finding misconfigurations and exposing risky entitlements, but they do not usually block active misuse of valid credentials. Cloud ransomware often looks like normal API activity, so the security problem is runtime enforcement, not only postural visibility. Teams need controls that can deny or quarantine destructive actions as they happen.

Q: How should security teams govern privileged machine identities in AWS?

A: They should govern machine identities as active privilege holders, not as background infrastructure. That means scoping permissions to the minimum set of cloud actions needed, revoking unused access quickly, and reviewing any identity that can change encryption, policies, or lifecycle controls. Machine identities should be included in the same access governance model as human admins.

Q: Who is accountable when cloud permissions are abused for ransomware?

A: Accountability sits with the teams that own identity governance, cloud platform policy, and privileged access design. If an identity can still perform destructive actions after the work it supports has ended, the control failure is governance, not just detection. NIST CSF access control and OWASP NHI-style entitlement management both point to that responsibility.

Technical breakdown

How AWS permissions become a ransomware control plane

AWS permissions are not just access markers, they are execution rights over storage, encryption, and lifecycle operations. A single credential with rights such as bucket policy changes, KMS re-encryption, or lifecycle configuration can convert normal administration into destructive abuse. The reason ransomware works here is that the attacker is not breaking the cloud model, but using the cloud model exactly as designed. That is why cloud identity, not endpoint malware, becomes the primary control surface.

Practical implication: audit which AWS permissions can encrypt, delete, rekey, or relabel data, then treat them as high-risk actions, not ordinary access.

Why CNAPP visibility does not stop active permission abuse

CNAPP tools are strong at finding misconfigurations, but the article’s core point is that visibility alone does not prevent abuse. If a compromised identity already has effective rights, a scanner can identify the issue and still fail to interrupt the attack in motion. In cloud ransomware, the malicious act is performed through legitimate APIs, so the control problem is prevention and restriction at runtime, not retrospective insight.

Practical implication: pair posture management with enforcement controls that can block risky API calls or quarantine identities before ransomware actions complete.

Why traditional PAM assumptions break in the cloud

Traditional PAM was built around human admins, vaulted passwords, and session recording. AWS breaks that model because privileged activity is often carried by machine identities, temporary credentials, and role chaining rather than a stable administrator session. That means the old PAM stack can miss the real abuse path, especially when the attacker inherits privileges through cloud-native delegation instead of logging in like a person.

Practical implication: redesign PAM scope for machine identities, temporary credentials, and API-driven privilege, not only for human administrator accounts.

Threat narrative

Attacker objective: The attacker wants to deny the organisation access to cloud data, create operational pressure, and force recovery or ransom decisions on the attacker’s terms.

1. Entry occurs when an attacker obtains or misuses IAM credentials and enters AWS with valid access rather than malware.
2. Escalation happens when the attacker abuses built-in permissions such as bucket policy changes, KMS actions, or lifecycle configuration to expand destructive reach.
3. Impact follows when the attacker encrypts, deletes, or locks data so the organisation loses access to its own cloud assets and recovery options.

Breaches seen in the wild

• Cisco Active Directory credentials breach — Kraken ransomware group leaked Cisco Active Directory credentials.
• 230M AWS environment compromise — 230M AWS environments compromised via exposed .env files with cloud credentials.

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 ransomware is now an identity governance problem before it is a malware problem. The article shows that attackers can use ordinary cloud permissions to encrypt, delete, or lock data, which means the decisive control point is entitlement scope. CNAPP can surface exposure, but the breach condition is created by effective privilege, not by malware presence. Practitioners should treat cloud ransomware as a privilege abuse scenario governed by IAM and PAM design.

Standing privilege is the failure mode this article exposes. Cloud environments accumulate permissions across users, roles, services, and machine identities, and those rights often persist far longer than the business need that justified them. That persistence converts everyday cloud administration into an attacker-ready control plane. The implication is not simply more monitoring. It is rethinking which access should exist at all outside a task window.

Cloud PAM has to be defined around runtime enforcement, not human-admin heritage. Traditional PAM assumes a person, a session, and a stable review surface. AWS ransomware breaks that assumption because privilege is frequently delegated through API-driven workflows and machine identities. The article therefore reinforces the need to align cloud privilege controls to OWASP-NHI and NIST-CSF access governance, not to legacy vault-and-session models.

Default deny becomes the practical boundary for cloud identity security. If a credential can change policies, re-encrypt data, or alter lifecycle settings, the organisation has already accepted a destructive capability as ordinary access. That is a governance error, not a tooling gap. Practitioners should class these permissions as high-impact paths requiring continuous restriction and explicit approval, not as routine entitlements.

Identity blast radius is the named concept this topic crystallises. A single over-scoped AWS credential can extend from data retrieval to encryption, deletion, and recovery suppression in one chain of actions. The blast radius is determined by the breadth of usable privileges, not by the number of systems touched. Security teams should therefore measure cloud risk by what one identity can still do, not by how many identities exist.

From our research:

• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, according to The 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to The 2026 Infrastructure Identity Survey.
• For the wider pattern behind this AWS ransomware analysis, see 52 NHI Breaches Analysis for how privilege exposure repeatedly turns into operational loss.

What this signals

Identity blast radius: cloud teams now need to measure how far one credential can reach across storage, encryption, and lifecycle controls. The shift is from posture reporting to action containment, because visibility alone does not stop destructive API use.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the broader identity pattern is already established: persistent access creates persistent attack options. The lesson carries directly into cloud ransomware governance, where standing privilege remains the easiest path to misuse.

The practical signal for security programmes is that cloud PAM, IAM, and workload identity must converge around runtime restriction. If access can still modify policies or destroy recovery paths after the task should have ended, the programme is treating cloud identity as a record-keeping problem instead of an enforcement problem.

For practitioners

• Map destructive AWS permissions first Inventory identities that can alter bucket policies, rekey data, change lifecycle rules, or otherwise convert access into data loss. Classify those permissions as ransomware-enabling actions and remove them from default roles where possible.
• Enforce task-scoped privilege for cloud admins and machines Replace persistent high-risk access with time-bounded approvals and explicit revocation when the task is complete. Apply the same rule to human operators and machine identities that perform storage, encryption, or policy administration.
• Block abuse at the API layer, not only in dashboards Use controls that can deny risky cloud actions in real time, especially where the action looks legitimate on the surface. Visibility tools remain useful, but they must feed enforcement that can stop destructive API calls before impact.
• Review cloud PAM coverage for machine identities Rebuild PAM assumptions so they include roles, temporary credentials, and role chaining rather than only human administrator accounts. If the control cannot see machine-to-machine privilege paths, it is missing the primary attack surface.

Key takeaways

• AWS ransomware is an identity abuse problem because valid cloud permissions can be used to encrypt, delete, or lock data without malware.
• Visibility tools help identify risk, but CNAPP and legacy PAM do not stop active misuse when the attacker already holds effective privileges.
• The control that matters most is runtime restriction of destructive permissions through least privilege, Just-in-Time access, and default-deny enforcement.

Key terms

• Cloud Ransomware: Cloud ransomware is the use of legitimate cloud permissions to encrypt, delete, or lock data rather than deploying a traditional malware payload. In practice, the attacker abuses identity and access controls to create loss of availability and recovery options inside the cloud control plane.
• Cloud Pam: Cloud PAM is privileged access management adapted for cloud-native identities, temporary credentials, and API-driven administration. It focuses on controlling high-risk actions in runtime, including machine identities and role chaining, rather than only vaulting human administrator passwords.
• Standing Privilege: Standing privilege is access that remains active outside the exact task window for which it was granted. In cloud environments, it becomes dangerous when users, roles, or services retain the ability to change policies, rekey data, or delete recovery paths long after the operational need has passed.
• Identity Blast Radius: Identity blast radius is the maximum damage a single identity can cause if misused or compromised. It is measured by the actions that credential can perform across data, policy, encryption, and recovery, not by the number of systems attached to the account.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: AWS Ransomware: Why CNAPPs & Traditional PAM Miss the Mark. Read the original.