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

Why This Matters for Security Teams

Cryptomining with valid cloud credentials is not a malware problem first. It is an authorization problem: once an attacker has a legitimate identity, they can request the exact cloud actions needed to spin up compute, attach storage, widen exposure, and keep the bill climbing. That is why detection alone is too late for prevention. Guidance from OWASP Non-Human Identity Top 10 and NHIMG research on the Secret Sprawl Challenge both point to the same operational risk: exposed or over-permissive credentials become a control-plane abuse path, not just an account compromise.

NHIMG’s 2024 Non-Human Identity Security Report found that only 19.6% of security professionals express strong confidence in securely managing non-human workload identities, which matches what responders see during cloud abuse events. In practice, many security teams encounter the mining workload only after the attacker has already created the compute, rather than through intentional prevention at the permission boundary.

How It Works in Practice

The practical fix is to block the privileged API calls that mining campaigns depend on before the request is allowed to execute. That means identifying the small set of high-risk actions that enable rapid cost and exposure growth, then denying them by default unless a task-scoped approval exists. Common examples include creating large compute instances, modifying network exposure, attaching permissive roles, launching autoscaling groups, or disabling logging.

This aligns with current cloud security guidance and with the broader identity-first approach described in CISA cyber threat advisories: do not wait for a signature when the attacker is already using valid credentials. Instead, evaluate each request at runtime using context such as identity type, resource sensitivity, geo, time, and change ticket status. For non-human identities, the stronger pattern is short-lived access paired with workload identity, not standing privilege. NHIMG’s Ultimate Guide to NHIs, Static vs Dynamic Secrets is consistent with that model: use ephemeral credentials, issue them per task, and revoke them automatically when the task ends.

• Deny rare actions by default, especially anything that can create compute at scale or expose services publicly.
• Use just-in-time approval for exceptions, with explicit task scope and a short TTL.
• Separate read-only telemetry from action permissions so monitoring remains available even when execution is blocked.
• Apply policy at request time, not as a static role assumption, because attacker behavior is dynamic.

Security teams should also narrow the blast radius of any credential by pairing least privilege with workload identity, strong session controls, and rapid revocation. These controls tend to break down in highly automated cloud environments where CI/CD pipelines, infrastructure-as-code, and service accounts all share similar permissions because policy exceptions get copied faster than they are reviewed.

Common Variations and Edge Cases

Tighter permission gating often increases operational overhead, requiring organisations to balance mining prevention against deployment speed and developer autonomy. That tradeoff is real, especially when teams rely on elastic cloud infrastructure or short-lived build systems.

There is no universal standard for this yet, but current guidance suggests the safest pattern is to treat high-risk cloud actions as exceptional. In mature environments, that means separate identities for automation, narrow role boundaries, and policy-as-code checks that evaluate the request, not just the caller. In less mature environments, the immediate win is simply removing broad create-and-escalate permissions from general-purpose credentials. This is where 230 million AWS environment compromise and the broader breach record in 52 NHI Breaches Analysis matter operationally: attackers succeed when access is valid, broad, and hard to expire. For teams using delegated access at scale, the right control is not “trust the role,” but “prove the task, then grant the minimum action set for only that task.”

Related resources from NHI Mgmt Group

• How should security teams stop compromised workloads from using valid credentials?
• How should security teams use secure email gateways without overrelying on them?
• How should security teams build cloud threat detection for short-lived workloads?
• Why are NHIs a critical concern for security teams?