Drumroll, please… 🥁
After five weeks of countdowns, breakdowns, and some very lively conversations, we’ve finally reached the end of the Top 25 Most Risky AWS Privileged Permissions, plus a special bonus round for AWS Organizations.
These permissions aren’t just “potentially risky.” They’ve been abused in real-world incidents to steal data, bypass controls, and escalate to full-blown admin access.
If your cloud teams are serious about least privilege, identity governance, or just not getting breached, this list is for you.
I’ve compiled every permission from the series, in order of severity, and added quick context on why it matters.
Before we dive in…
💙 Follow Sonrai Security on LinkedIn for more cloud privilege and permissions deep dives
📺 And don’t forget to subscribe on YouTube to learn more about paths to privilege abuse
Countdown #25–#21
| Rank | Permission | Why It’s Risky |
| #25 | ec2:TerminateInstances | Lets attackers shut down EC2 instances, disrupting services or executing ransomware-style destruction. |
| #24 | s3:GetObject | Often over-scoped. Allows retrieval of sensitive files, logs, or customer data from S3 buckets. |
| #23 | ec2:CreateImage | Enables copying of EC2 disk volumes, useful for data exfiltration or lateral movement. |
| #22 | ec2:GetPasswordData | Exposes Windows administrator passwords. Opens the door to identity takeover. |
| #21 | lambda:InvokeFunction | Executes Lambda functions, potentially triggering sensitive logic with minimal oversight. |
🎥 Video Explainer
Here’s why s3:GetObject, a seemingly harmless permission, deserves its spot on the list. It’s one of the most commonly granted permissions in AWS, often over-scoped, and can expose sensitive files, logs, or customer data. Even identities with minimal access often get this permission, making it the “consolation prize” for attackers who compromise lower-privileged accounts.
Countdown #20–#16
| Rank | Permission | Why It’s Risky |
| #20 | cloudformation:CreateStack | Lets attackers spin up full infrastructure templates, building shadow environments quickly. |
| #19 | ec2:ModifySecurityGroupRules | Alters EC2 firewall rules, exposing services or enabling command-and-control traffic. |
| #18 | lambda:CreateFunction | Allows deployment of attacker-controlled code. Can abuse existing IAM roles. |
| #17 | ec2:RunInstances | Starts new EC2 instances for exfiltration, crypto mining, or persistence. |
| #16 | ec2:ModifyInstanceMetadataOptions | Weakens IMDS protections, enabling theft of temporary credentials. |
🎥 Video Explainer
Let’s talk about ec2:ModifySecurityGroupRules. Attackers can use this permission to punch holes in your network defenses. By modifying ingress or egress rules, they can expose internal services or set up command-and-control traffic. AWS itself warns that this permission should be tightly controlled, and I show you why.
Countdown #15–#11
| Rank | Permission | Why It’s Risky |
| #15 | ec2:ModifyInstanceAttribute | Changes IAM roles, security groups, or startup scripts to escalate privileges. |
| #14 | kms:Decrypt | Decrypts sensitive data like secrets, passwords, or config files. |
| #13 | kms:PutKeyPolicy | Grants attackers access to encryption keys, often without alerting owners. |
| #12 | secretsmanager:GetSecretValue | Retrieves stored secrets (e.g. DB passwords, API keys) directly. |
| #11 | organizations:LeaveOrganization | Detaches account from org guardrails (like SCPs), evading governance and logging. |
🎥 Video Explainer
I step outside the IAM service to spotlight a governance threat: organizations:LeaveOrganization. This permission allows an account to break free from centralized controls like SCPs or CloudTrail org trails. It’s particularly dangerous because it works outside the org management account and can let compromised accounts quietly slip away from your security net.
Countdown #10–#6
| Rank | Permission | Why It’s Risky |
| #10 | route53:ChangeResourceRecordSets | Alters DNS records. Useful for phishing, data rerouting, or traffic interception. |
| #9 | iam:CreateAccessKey | Creates new API keys to maintain hidden, durable access. |
| #8 | iam:UpdateLoginProfile | Resets passwords for IAM users. Grants quiet console access to attacker. |
| #7 | iam:PassRole | Assigns powerful roles to services like EC2 or Lambda, key for escalation. |
| #6 | cloudtrail:DeleteTrail | Disables or deletes logging. Useful for anti-forensics and covering tracks. |
🎥 Video Explainer
Let me explain one of the most versatile privilege escalation paths: PassRole. While it doesn’t look dangerous on its own, when combined with the ability to launch or update AWS resources, it becomes a launchpad for escalating access and executing high-privilege actions under the radar. Also, here’s another resource listing 12+ known abuse chains involving this permission.
Countdown #5–#1
| Rank | Permission | Why It’s Risky |
| #5 | sts:AssumeRole | Lets attackers assume roles in other accounts, key to cross-account attacks. |
| #4 | iam:UpdateAssumeRolePolicy | Redefines trust relationships to give attacker access. |
| #3 | iam:CreatePolicyVersion | Swaps policy contents with malicious version. |
| #2 | iam:AttachRolePolicy | Grants managed policy access, reused here due to massive impact. |
| #1 | iam:PutRolePolicy | The most dangerous of all — grants arbitrary permissions through inline policies. |
🎥 Video Explainer
I close the series with a look at what I call the baddest of bad: PutRolePolicy. This allows an attacker to directly inject inline permissions into a role, granting virtually any privilege they want. Because it doesn’t alter policy attachments, it can also be harder to audit than managed policy changes, making it the perfect tool for stealth escalation.
Bonus Countdown: Top 5 AWS Organizations Permissions
Applicable only in multi-account orgs, but devastating if misused.
| Rank | Permission | Why It’s Risky |
| #5 | organizations:CreateAccount | Creates shadow accounts that evade oversight. |
| #4 | organizations:CloseAccount | Can irreversibly shut down accounts. Used for sabotage. |
| #3 | organizations:MoveAccount | Escapes applied SCPs by shifting between OUs. |
| #2 | organizations:UpdatePolicy | Edits SCPs. Removes security controls org-wide. |
| #1 | organizations:DetachPolicy | Removes policies altogether. No more guardrails. |
🎥 Video Explainer
Here I warn about the organizations:DetachPolicy permission, which removes SCPs, RCPs, and other org-wide policies. This is especially dangerous because it only works in the org management account, where SCPs can’t stop it and where access is often assumed to be trustworthy. It’s a point of failure that can dissolve your entire permissions strategy with a single API call.
Final Thoughts
Permissions create privilege, and privilege creates risk. If you’re not actively monitoring and locking down these permissions, you’re leaving wide-open doors in your AWS environment.
Every permission on this list has been:
- Misused in real-world breaches
- Found over-scoped in customer environments
- Linked to stealth, escalation, or full compromise
The good news is that just because these permissions are risky doesn’t mean they can’t be controlled; with the right visibility, automation, and guardrails in place.
Stay Tuned
To get more research, breakdowns, and video content on cloud privilege and permissions:
💙 Follow Sonrai Security on LinkedIn
📺 Subscribe on YouTube
Wish you could automate privilege access management? Check out the Cloud Permissions Firewall, Sonrai’s answer to taming cloud privilege at scale.
