The recent discovery of a cryptomining campaign targeting Amazon compute resources highlights a critical gap in traditional cloud defense. Attackers are bypassing perimeter defenses by leveraging compromised credentials to execute legitimate but privileged API calls like ec2:CreateLaunchTemplate, ecs:RegisterTaskDefinition, ec2:ModifyInstanceAttribute, and lambda:CreateFunctionUrlConfig.
While detection tools identify anomalies after they occur, they do not prevent execution, lateral movement, or persistence by the bad actor. The Sonrai Cloud Permissions Firewall neutralizes this kill chain by protecting the privileged permissions that enable the attack, but are rarely needed by most cloud identities. Research shows that 92% of identities granted these privileged permissions never use them. By enforcing a “Global Default Deny” on these privileges and allowing only the 8% of identities that actually require them, the Firewall proactively blocks the API calls required to complete these attacks.
Detection can only observe cryptomining after it starts; the Cloud Permissions Firewall prevents it by design by denying the exact permissions attackers must use to launch and sustain mining infrastructure.
Prevention is the best cure
The cryptomining campaign leverages compromised identity credentials to execute privileged API calls. The Sonrai Cloud Permissions Firewall disrupts this sequence by protecting privileged permissions, causing the attack to fail. The Firewall also sends instant notifications of the attempts to use privileged permissions to the teams responsible for running workloads – the teams that are most likely to recognize the behavior as unexpected.
Specific details from this week’s attack: The adversary uses compromised credentials to spin up compute resources using templates created via ecs:RegisterTaskDefinition and ec2:CreateLaunchProfile. This is where financial damage begins. The attacker can scale up cryptominers within ECS clusters or as part of EC2 AutoScaling groups.
Firewall Countermeasure: Automated Least Privilege
- Mechanism: The Firewall analyzes the identity’s historical usage (typically over 90 days). Even if a user has broad administrative policies attached, the firewall detects that specific privileged permissions, such as ecs:RegisterTaskDefinition or ec2:CreateLaunchProfile, have not been used recently.
- The Block: The firewall protects these permissions from the effective policy using a global policy mechanism like a Service Control Policy (SCP) or Resource Control Policy (RCP). When the attacker attempts to call them using the stolen credentials, the API returns AccessDenied.
- Impact: No compute resources are provisioned, no mining occurs, and no bill is incurred. The team is instantly notified of the compromised identity attempting these API calls, and is granted the opportunity to re-enable access, were the requests legitimate.
Preventing Escalation and Persistence
To maintain access and expand their footprint, attackers used iam:CreateUser, iam:CreateAccessKey, or iam:AttachUserPolicy to generate new backdoor accounts.
Additionally, to maintain external access to the cloud environment, attackers used unauthenticated and publicly invocable Lambda Functions. The functions were created using lambda:CreateFunction, and their publicly accessible invocation URL was created using lambda:CreateFunctionUrlConfig.
Lastly, to persist the EC2 compute resources amid attempts to remove them, attackers used ec2:ModifyInstanceAttribute to complicate terminating the malicious computes by toggling the “disableApiTermination” setting.
Firewall Countermeasure: Toxic Combination Blocking
- Mechanism: Permissions like these are classified as privileged “Risk Amplifiers.” The Firewall restricts these permissions strictly to the specific identities that require them for legitimate orchestration logic.
- The Block: If a compromised credential attempts to escalate privileges, create a new identity, or establish persistence, the action is blocked because the identity is not on the exemption list for that specific sensitive permission.
- Impact: The attacker is contained. They cannot create backdoor access or hard-to-remove resources.
Empirical Evidence
In independent penetration testing, the Cloud Permissions Firewall achieved a 100% prevention rate against highly vulnerable AWS accounts. The testing was commissioned by Sonrai Security and conducted by Software Secured using industry-standard attack simulations such as CloudGoat and IAM Vulnerable.
| Test Scenario | Critical Privileged Permission | Result (Unprotected) | Result (Firewall Protected) |
| Lateral Movement | ssm:StartSession | Success (Pivot Completed) | BLOCKED (Permission Stripped) |
| Privilege Escalation | iam:CreatePolicyVersion | Success (Admin Access Gained) | BLOCKED (Permission Stripped) |
| Persistance | iam:CreateAccessKey | Success (Credentials Created) | BLOCKED (Permission Stripped) |
Bottom Line: The Cloud Permissions Firewall blocked 16 out of 16 tested attack paths, specifically by denying the privileged API calls required to execute the kill chain.
Operationalizing Prevention without Friction
A common concern with locking down privileged permissions is the impact on developer velocity. The Sonrai Cloud Permissions Firewall addresses this through Permissions-on-Demand.
- The Workflow: If a legitimate developer needs to create an EC2 launch template (ec2:CreateLaunchTemplate) for a new project, they are blocked initially if they haven’t used it before.
- The Resolution: They receive an instant notification via Slack or Teams. They request access (e.g., “Need EC2 access for 4 hours”).
- The Outcome: Upon automated or manual approval, the firewall updates the policy in real-time, granting the permission.
- The Security Gain: This ensures that standing privileges—which attackers rely on—are eliminated. Access exists only when needed and approved.
The Early Warning System: Regions and Services
While restricting Privileged Permissions is the primary mechanism for stopping attacks, the Cloud Permissions Firewall also utilizes Region Lockdown and Unused Service protection as a critical safety net.
If an attacker attempts to launch resources in an obscure region (e.g., ap-northeast-3) or access a service the identity has never used before, the Firewall blocks the action immediately. Crucially, this block acts as a high-fidelity early warning alarm. Because legitimate users rarely veer into unused regions or services, a block event here is a strong indicator of a misbehaving identity or a compromised credential, allowing security teams to investigate before the attacker can find a valid path to execution.
Conclusion
This recent campaign serves as a reminder that identity is the new perimeter. While detection is necessary, it is no longer sufficient against automated resource theft. By deploying a Cloud Permissions Firewall to actively manage privileged permissions, organizations move from a reactive posture—cleaning up after a breach—to a preventative one, stopping the cryptomining kill chain at the very first API call.
