Topic starter
08/01/2026 12:36 pm
TL;DR: Attackers used compromised IAM credentials to provision cryptomining workloads across EC2 and ECS, create new roles, and set termination protection within about 10 minutes of access, according to Apono’s analysis of AWS and Dark Reading reporting. Standing privileges and broad role-creation rights turn valid access into a persistence path, not just an entry point.
Editorial analysis by NHI Mgmt Group, based on content published by Apono: “How Attackers Maintained Persistence in AWS After Stealing Credentials”.
Key questions
Q: What breaks when a stolen AWS identity already has role-creation rights?
A: The breach boundary breaks because the attacker no longer needs to escalate outside the account.
Q: Why do standing AWS permissions increase the impact of stolen credentials?
A: Standing permissions let an attacker do useful work as soon as credentials are accepted.
Q: What are the signs that AWS Systems Manager is being misused for persistence or credential theft?
A: Common warning signs include unusual SSM sessions, unexpected access to hosts that should not be managed, new or altered SSM user accounts, commands that enumerate managed devices, and access patterns that lead to credential harvesting or SSH key extraction.
Practitioner guidance
- Audit role-creation rights Identify every IAM principal that can create roles, service-linked roles, or role attachments, then remove those rights from identities that do not need to shape trust relationships.
- Replace standing cloud access with JIT controls Move high-impact permissions such as infrastructure changes and IAM administration behind just-in-time access so a compromised identity cannot reuse them continuously.
- Block termination-protection abuse Alert on ModifyInstanceAttribute calls that set DisableApiTermination and require separate approval for any identity that can change instance removal behaviour.
Bottom line: The core risk is not exotic exploitation but the abuse of valid AWS identity permissions to create persistence and generate compute spend.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 6 days ago by NHI Mgmt Group
06/10/2026 11:37 pm
Standing privilege turns AWS credential theft into persistence, not just access. The critical failure is not that credentials were stolen, but that the compromised identity already carried enough authority to create roles, launch compute, and harden instances. In cloud IAM, the attacker often inherits the operational ceiling of the victim account, so privilege scope determines whether a compromise becomes transient or durable. Practitioners should treat every broad IAM grant as a potential persistence pathway, not simply a usability convenience.
A question worth separating out:
Q: Should teams compare Zero Standing Privilege and traditional IAM admin access?
A: Yes, because the difference is whether elevated permissions are always available or only issued for a specific task. In incidents like this, permanent access gives a stolen identity enough time and authority to create roles, launch resources, and harden persistence. JIT issuance reduces that window and makes abuse harder to repeat.
👉 Read our full editorial: AWS credential theft shows why standing privilege still fails