Why do over-privileged cloud identities make cryptomining worse?

Why This Matters for Security Teams

Cloud cryptomining rarely starts with a noisy exploit. It usually starts with an identity that can already create compute, attach storage, read secrets, or change network exposure. When that identity is over-privileged, the attacker can convert access into spend, persistence, and lateral movement without first defeating the cloud platform. The security problem is therefore not only malware removal. It is control-plane abuse through standing privilege, which makes the miner harder to evict and the bill harder to contain.

This is why NHI governance matters as much as infrastructure hardening. The OWASP Non-Human Identity Top 10 frames excessive privilege and secret exposure as primary failure modes for machine identities. NHIMG research shows the same pattern in practice: in the 2024 Non-Human Identity Security Report, only 19.6% of security professionals expressed strong confidence in their organisation’s ability to securely manage non-human workload identities. In practice, many security teams discover cryptomining only after the identity has already been used to launch workloads, not during the approval of the access that made it possible.

How It Works in Practice

Cryptominers thrive on permissions that let them transform one credential into long-running infrastructure abuse. If a cloud identity can create instances, scale containers, modify IAM roles, open security groups, or attach startup scripts, the attacker does not need root on a server. They need a valid control-plane principal. Once inside, miners can be distributed across autoscaling groups, serverless functions, or ephemeral containers to make cleanup appear intermittent and incomplete.

Best practice is to reduce the identity to the minimum workload action set, then issue access only when the task is legitimate and only for the shortest practical time. That means replacing static, reusable secrets with short-lived credentials, workload identity, and policy evaluated at request time. The emerging pattern is consistent with guidance from the OWASP Non-Human Identity Top 10 and with the operational concerns highlighted in NHIMG’s 230M AWS environment compromise research, where broad cloud access magnified downstream impact.

• Use workload identity for the service or agent, not a shared human admin account.
• Issue JIT credentials with tight TTLs and automatic revocation after the task completes.
• Separate build, deploy, and runtime permissions so one compromised identity cannot do all three.
• Monitor for new compute creation, unusual scaling, and public exposure changes as abuse indicators.
• Apply policy-as-code so access decisions reflect context, not only a static role name.

These controls tend to break down in fast-moving Kubernetes, serverless, and multi-cloud environments because identity sprawl makes it difficult to know which principal can still create spend on demand.

Common Variations and Edge Cases

Tighter privilege control often increases operational overhead, requiring organisations to balance faster delivery against reduced blast radius. That tradeoff is real, especially when teams rely on automation, shared pipelines, or legacy service accounts that were never designed for short-lived access. Current guidance suggests that the answer is not to block automation, but to make privilege temporary, narrowly scoped, and measurable.

There is no universal standard for every cloud service yet, so teams should expect uneven support for ephemeral access, workload identity federation, and runtime authorization. Some environments still require a small set of durable bootstrap secrets, but those should be isolated from the main runtime path and rotated aggressively. The Azure Key Vault privilege escalation exposure case illustrates how control-plane permissions around secrets can turn into broader compromise, while the Codefinger AWS S3 ransomware attack shows how cloud access can be abused once privilege is already in place.

For security leaders, the operational test is simple: if a stolen identity can still create compute, expose services, or alter guardrails after the original task is complete, the environment remains attractive to cryptomining. The harder the privilege is to reuse, the less profitable the miner becomes.

Related resources from NHI Mgmt Group

• What are the implications of using over-privileged browser extensions?
• What should teams do first after finding over-privileged cloud identities?
• What breaks when AI-powered ransomware hits over-privileged cloud identities?
• When do non-human identities pose the greatest risk to organizations?