AWS cryptomining shows why cloud permissions need prevention

At a glance

What this is: This is an analysis of AWS cryptomining attacks that succeed by abusing compromised credentials and privileged API calls to create, modify, and persist compute resources.

Why it matters: It matters because IAM, PAM, and cloud security teams need to stop treating detection as the primary control when identity privilege itself is the execution path.

By the numbers:

• Research shows that 92% of identities granted these privileged permissions never use them.
• Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, meaning organisations failing to scope access properly are 4.5x more likely to experience a security incident.

👉 Read Sonrai Security's analysis of AWS cryptomining attacks and cloud permissions

Context

Cloud cryptomining attacks often look like legitimate administration because they rely on valid credentials and normal API calls. In this case, the issue is not whether the attacker can be detected after the fact, but whether the identity is allowed to perform privileged actions such as launching compute, modifying instances, or creating persistence paths in the first place.

For IAM and cloud platform teams, the core problem is standing permission. When broad rights are attached to identities that rarely exercise them, attackers inherit those rights the moment credentials are compromised. That makes least privilege, JIT access, and permission scoping operational controls rather than policy language.

Key questions

Q: How should security teams stop cryptomining attacks that use valid cloud credentials?

A: Block the privileged API calls that cryptominers need before they can create compute, persistence, or public exposure. Detection still has value, but prevention must happen at the permission layer. The practical goal is to deny rare high-risk actions by default and re-enable them only through a task-scoped approval path.

Q: Why do over-privileged cloud identities make cryptomining worse?

A: Because the attacker does not need to break the platform when the identity already has the rights to create workloads, modify instances, or expose functions publicly. Standing privilege turns one stolen credential into a reusable control-plane foothold. That increases blast radius, cost exposure, and the chance of persistence.

Q: What do teams get wrong about cloud detection in identity attacks?

A: They assume alerts can compensate for excessive access. In reality, once a compromised identity can execute privileged actions, the attacker can often complete part of the kill chain before triage begins. Detection should confirm compromise, but permission scoping should prevent the abuse path.

Q: Who should own prevention for privileged cloud actions?

A: IAM, PAM, and cloud platform teams should own it together because the issue sits at the intersection of identity governance and infrastructure control. The right model is policy-enforced least privilege for the action set, with workload owners receiving blocked-attempt notifications when something unexpected occurs.

Technical breakdown

Why privileged API calls are the real attack surface

Cloud cryptominers do not need to break the platform when they can use valid credentials to call powerful APIs. In AWS, actions such as creating launch templates, registering task definitions, creating functions, and changing instance attributes can provision compute, create persistence, or make removal harder. Detection tools may notice unusual patterns, but the attack has already crossed the authorisation boundary if the identity was permitted to invoke those APIs. The architectural problem is that cloud control planes often treat identity authority as broad unless explicit permission boundaries are enforced.

Practical implication: map the small set of privileged APIs that can create compute, persistence, or billing impact, then constrain them by default.

Why detection fails when permission is already granted

Detection is a response mechanism, not a preventive control. If a compromised credential can already execute privileged calls, the attacker can launch resources, create backdoors, and alter settings before an alert is fully triaged. That is why cloud attack chains often keep moving after anomaly detection fires. The control gap is not alert quality alone, but the assumption that post-execution visibility is enough to stop misuse of identity authority.

Practical implication: pair detection with hard permission boundaries so blocked API calls stop the kill chain before compute or persistence is created.

How permissions-on-demand changes cloud identity governance

Permissions-on-demand is a governance pattern that removes standing access until a task requires it, then restores only the required privilege for a limited period. In cloud environments, that changes the attacker’s economics because compromised credentials no longer inherit broad, durable rights by default. It also creates a clean distinction between routine access and exception-based elevation, which is easier to govern and audit than permanently broad policy attachments.

Practical implication: reserve privileged cloud actions for explicitly approved, time-bound elevation paths instead of broad always-on roles.

Threat narrative

Attacker objective: The attacker wants to monetise stolen cloud capacity by launching cryptomining infrastructure while maintaining access long enough to keep generating compute cost.

1. Entry occurs when an attacker obtains compromised cloud credentials and uses them to make legitimate API calls rather than exploit malware.
2. Escalation happens when those credentials are used to create compute resources, alter instance settings, or establish persistence for mining infrastructure.
3. Impact follows when the environment spins up unauthorised workloads, consumes budget, and gives the attacker durable access to cloud capacity.

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

Standing cloud privilege is the failure mode, not weak detection. The article describes attackers succeeding through legitimate API calls, which means the control boundary was already open before any alert fired. That is a privilege governance problem, not a monitoring problem. In NHI terms, the identity had more authority than its normal work required, and the attacker simply inherited it. Practitioners should treat privileged cloud permissions as an attack path, not a background configuration choice.

Identity blast radius is the right concept for cloud cryptomining defence. The reason these campaigns scale is that one compromised credential can touch compute, persistence, and budget impact from the same control plane. That is a blast-radius problem created by overly broad entitlements. Frameworks such as OWASP-NHI and NIST-CSF both point toward explicit access scoping, but the operational lesson is simpler: the smaller the permission surface, the less useful a stolen identity becomes.

Global default deny for privileged cloud actions is a governance posture, not a tuning option. The article’s own evidence that 92% of identities with privileged permissions never use them shows how much excess access sits idle until an attacker arrives. That is exactly where least privilege should be enforced at the permission layer, not left to detection after misuse. The practitioner conclusion is to redesign cloud access around exception-based elevation, not perpetual entitlement.

Cryptomining abuse shows why JIT access must be measured against the exact control plane actions an identity can perform. The issue is not only whether access exists, but whether it exists long enough and broadly enough for an attacker to launch resources before anyone intervenes. That means access review, permission boundary, and elevation workflow decisions have to be made at the API action level. Teams should assume any standing right to create, modify, or persist compute can be monetised instantly.

The cloud identity problem is now operational resilience, not just security hygiene. The article ties privileged permissions directly to cost, persistence, and incident containment. That widens the remit for IAM, PAM, and cloud platform teams because mis-scoped access now becomes a business loss event as soon as compute is abused. Practitioners should align cloud access governance with blast-radius reduction and recovery speed, not just compliance checklists.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• Another finding from the same survey shows that only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree that governing AI agents is critical to enterprise security.
• For a broader view of identity lifecycle and access scoping across machine and human identities, see Top 10 NHI Issues.

What this signals

Identity blast radius is becoming the decisive cloud risk signal. When a single credential can create compute, alter instances, and maintain persistence, the security programme is no longer dealing with an alerting problem. It is dealing with an entitlement design problem. Teams that want a stronger control posture should anchor cloud permissions to 52 NHI Breaches Analysis and use it to pressure-test where standing privilege still exists.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, the governance lesson extends beyond classic cloud abuse. The same permission and secret-sprawl patterns that enable cryptomining also create broader identity exposure across automation, AI, and workload access. Practitioners should treat every persistent secret as a future abuse path, not just an authentication artifact.

Permission boundaries need to become measurable, not aspirational. If blocked privileged calls are rising while approved exceptions remain low and auditable, the programme is shrinking blast radius rather than preserving developer convenience. That is the signal to watch as cloud identity governance matures.

For practitioners

• Inventory privileged cloud APIs that can create or persist compute Map actions such as launch template creation, task definition registration, instance modification, and public function exposure. These are the calls an attacker needs to turn a compromised identity into a mining workload.
• Enforce default-deny on rare privileged permissions Treat permissions that almost no identity uses as exception-only rights. Use policy boundaries so the identity can only regain access through an explicit approval path when a task genuinely requires it.
• Move elevation to task-scoped access requests Replace always-on admin-style rights with time-bound requests tied to specific cloud work. That keeps legitimate operations moving while preventing stolen credentials from inheriting durable privilege.
• Alert on blocked attempts to use sensitive cloud actions A denied call to a high-risk API is often a stronger compromise signal than an allowed one. Route those events to the teams that own the workload so they can validate whether the identity is behaving unexpectedly.

Key takeaways

• Cryptomining campaigns succeed when cloud identities have standing permission to perform high-risk API actions, not because defenders lack alerts.
• The scale of the problem is clear: privileged access is massively over-assigned, with most identities never using the rights they already hold.
• The practical answer is default-deny for rare privileged permissions, with task-scoped elevation for legitimate work.

Key terms

• Privileged Cloud Permission: A privileged cloud permission is an access right that can change infrastructure, create workloads, or alter security-relevant settings. These rights matter because they sit at the control-plane layer, where one compromised identity can create disproportionate impact if the permission is always available.
• Standing Privilege: Standing privilege is access that remains continuously available instead of being granted only when needed. In cloud identity governance, it creates a persistent attack surface because stolen credentials inherit the same broad rights as legitimate operators, even when those rights are rarely used.
• Permissions-on-Demand: Permissions-on-Demand is a governance pattern that grants sensitive access only for a specific task and only for a limited period. It is especially useful in cloud environments because it reduces the value of compromised credentials while preserving a controlled path for legitimate elevation.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Sonrai Security: Preventing This Week's AWS Cryptomining Attacks and Why Permissions Matter. Read the original.