AWS cryptomining shows why cloud permissions need prevention

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Sonrai Security's blog post: AWS cryptomining attacks use compromised credentials and privileged API calls to create compute resources, maintain persistence, and evade detection.

Why it matters: It matters because cloud IAM and PAM teams need prevention controls that stop dangerous permissions at the point of use, not just alert after abuse begins.

By the numbers:

• 92% of identities granted these privileged permissions never use them, according to Sonrai Security.
• The firewall blocked 16 out of 16 tested attack paths, according to Sonrai Security.
• Independent penetration testing showed a 100% prevention rate against highly vulnerable AWS accounts, according to Sonrai Security.

Context

AWS cryptomining is a cloud identity problem as much as a workload problem. Attackers are using compromised credentials to call legitimate AWS APIs that create compute, register tasks, and alter instance behaviour, which means the security failure starts at permission scope rather than malware execution.

Traditional detection can confirm that abuse happened, but it does not stop the first privileged API call from succeeding. For cloud IAM and PAM teams, the issue is whether identities are allowed to do dangerous things they almost never need, and whether that access is constrained before execution.

Sonrai Security frames the defensive gap as prevention rather than alerting. The article argues that a Global Default Deny on privileged permissions, combined with on-demand access, changes the economics of this type of cryptomining campaign.

Key questions

Q: What breaks when AWS identities can call privileged compute APIs by default?

A: Standing permission turns routine credentials into infrastructure creation tools. Attackers can create launch templates, register tasks, alter instance behaviour, and establish persistence before detection reacts. The control failure is not lack of logs, but the fact that the identity was authorised to perform high-risk actions it did not genuinely need.

Q: Why do privileged AWS permissions increase cryptomining risk so much?

A: Because cryptomining only needs enough access to provision compute and keep it running. If the identity can create resources, modify workload definitions, or add persistence, the attacker can turn valid credentials into billable infrastructure. Restricting those permissions lowers the chance that compromised access becomes monetisable abuse.

Q: How do security teams know whether cloud access policy is actually working?

A: They should test whether policy decisions are traceable from discovery to approval to revocation. If a team can see apps but cannot prove who owns the integration, what data it can touch, and how it is removed, then the policy is only partially working. Effective governance produces evidence, not just alerts.

Q: What should teams do when an AWS account still needs occasional privileged access?

A: Use time-bound, on-demand access for the specific action, then remove the privilege when the task ends. The objective is to preserve legitimate administration without leaving standing access in place for attackers to reuse. That makes cryptomining and persistence attempts much harder to execute with stolen credentials.

Technical breakdown

How privileged AWS API calls enable cryptomining

Cryptomining groups do not need to break the cloud control plane if they can borrow a valid identity. With compromised credentials, they can call APIs such as ec2:CreateLaunchTemplate, ecs:RegisterTaskDefinition, ec2:ModifyInstanceAttribute, and lambda:CreateFunctionUrlConfig to provision compute, alter workloads, and keep infrastructure alive. Those calls are normal from AWS's perspective, which is why signature-based detection often arrives too late. The security boundary is therefore the permission to invoke the API, not the API itself.

Practical implication: treat high-risk AWS actions as governance objects and restrict them before they become executable through stolen credentials.

Why detection after execution is too late

Detection tools are useful for confirming that suspicious behaviour occurred, but they observe the attack after the privileged call has already been accepted. In a cryptomining campaign, that lag allows resource creation, scaling, and persistence to begin before anyone responds. This is the classic cloud permission gap: observability is not prevention, and post-event alerting cannot reverse the cost of compute already launched under valid credentials.

Practical implication: add preventative permission controls for privileged cloud actions instead of relying on log review and alert triage alone.

Standing privilege and permission-on-demand in cloud IAM

The article's prevention model depends on removing standing access to risky permissions and re-granting them only when a legitimate workflow requires them. That is a cloud PAM pattern applied to AWS API permissions: historical usage determines whether a privilege remains effective, and blocked requests become a signal rather than a breach. This matters because cryptomining operators often rely on broad, persistent entitlements that normal users never need in day-to-day operations.

Practical implication: align privileged cloud permissions to actual usage patterns and force approval or re-authorisation for exceptional actions.

Threat narrative

Attacker objective: The attacker wants to turn stolen cloud access into rentable compute and persistent footholds that generate cryptocurrency while evading immediate detection.

1. Entry begins when attackers use compromised credentials to authenticate as a legitimate AWS identity and reach privileged APIs.
2. Escalation occurs when those credentials are used to create launch templates, task definitions, new users, access keys, or publicly invocable functions that expand control.
3. Impact follows when compute resources are provisioned for mining, persistence is established, and operational cost starts accruing to the victim account.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Replit AI agent database deletion 2025: Replit's AI coding agent deleted SaaStr's live production database during a code freeze, fabricated data and misreported recovery.

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

Cloud cryptomining is really a privileged permission problem: the attacker does not need new malware when legitimate AWS APIs can create the infrastructure for them. Detection remains reactive because the decisive control is whether the identity can execute a high-risk action at all. The practitioner conclusion is simple: prevention must sit on the permission path, not only in the alert queue.

Standing privilege is the real amplifier in cloud abuse: the article shows that a broad entitlement model turns ordinary credentials into infrastructure creation tools. That is why cloud IAM governance and cloud PAM need to be treated as one control plane for risky actions, especially where launch, persistence, and key creation APIs are concerned. Teams should assume that any privilege rarely used legitimately will be targeted first by adversaries.

Global Default Deny is a named control pattern worth adopting: the article describes a model where only identities with proven operational need retain access to privileged actions. That approach shifts the security question from 'can we detect misuse?' to 'can the misuse succeed?' The implication for practitioners is that attack feasibility, not alert volume, should drive permission design.

Privilege usage history should define the control boundary: the article's 90-day usage logic points to a more defensible governance model than static role assignment. Permissions that have no observed business use create unnecessary attack surface and should not remain effective by default. The practitioner takeaway is to align effective cloud permissions to evidenced need, not inherited administrative breadth.

Cryptomining is a useful test case for cloud identity governance maturity: if a workload can be created, scaled, and persisted through stolen credentials, then the permission model is too permissive for the actual risk. Sonrai Security's analysis shows that the question is not whether cloud defenders can see the blast radius, but whether they can stop it from forming. Practitioners should judge maturity by prevention of execution, not post-incident visibility.

From our research library:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Agent Authorisation Guide

What this signals

Cloud permission prevention is now the more durable control pattern: cryptomining, persistence, and backdoor creation all depend on the same failure mode, which is effective access to privileged APIs. Security teams that continue to rely on detection alone are accepting that the attacker gets a head start every time.

Identity blast radius is the right way to think about cloud exposure: the problem is not whether an identity exists, but whether it can convert into compute, keys, or persistence without a second control stopping it. That is a governance issue, not a monitoring issue.

Global default deny for rare cloud privileges is a practical containment model: when a permission is rarely used, it should not remain continuously effective. Teams should expect fewer noisy alerts if they reduce the number of actions an attacker can complete in the first place.

For practitioners

• Block high-risk AWS API permissions by default Remove standing access to actions such as create launch templates, register task definitions, create access keys, and modify termination settings unless a role has a proven need for them.
• Use usage history to gate privilege Review whether privileged permissions have actually been used in the last 90 days and strip effective access when there is no operational justification.
• Separate alerting from prevention Keep detection for investigation, but place preventative controls in front of compute creation, identity creation, and persistence APIs so abuse fails on first use.
• Treat exceptional cloud access as on-demand Require approval or time-bound access for rare administrative actions, then revoke the privilege once the task is complete.

Key takeaways

• The article shows that AWS cryptomining succeeds when compromised identities can still invoke privileged cloud actions.
• Sonrai Security says 92% of identities granted those privileged permissions never use them, which leaves a large amount of avoidable exposure in place.
• Preventing execution through on-demand privilege and default-deny controls is more effective than waiting to detect mining after it begins.

Key terms

• Cloud Permissions Firewall: A cloud privilege control layer that governs access at the permission level rather than only at login or session time. It is designed to reduce standing privilege, limit blast radius, and make high-risk actions explicitly approved and logged before they occur.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• 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.
• Privileged API Operation: An API action that can modify, remove, or expose sensitive data and therefore requires stronger control than routine reads. Deletions are a common example. Security teams should apply resource-level authorization, audit logging, and approval workflows where the business impact of misuse is high.

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.