Hero Card: IAM Users and Roles with Excessive Privilege
© 2025 Sonrai Security. All rights reserved.
Overview
When Identity and Access Management (IAM) users and roles are assigned permissions which ultimately don't get put to use, those permissions can provide an attacker with an easy way to gain intelligence, perform data exfiltration, impersonate users, and more.
Excess privilege can also lead to scenarios where users are unintentionally allowed to complete actions that are not expected, like creating/deleting resources, which can drive up operational costs and cause outages.
Examples
- Example 1: When Outsiders Become Insiders
- Example 2: When Insiders Cause Problems
Example 1: When Outsiders Become Insiders
One day, an attacker managed to gain access to a junior engineer's account through a successful phishing attempt. The engineer's account had been granted excessive privileges due to lax IAM policies. Although the engineer's primary role involved developing software and managing deployment scripts, their account had permissions far beyond what was necessary for their job.
With the engineer's compromised credentials, the attacker explored the company's AWS environment. The broad permissions allowed the attacker to access sensitive databases, alter application configurations, and modify access controls. The attacker used these elevated privileges to create backdoors and install malware on several virtual machines.
The attacker then exfiltrated large volumes of proprietary data and customer information, covering their tracks by modifying logs and disabling monitoring alerts.
Example 2: When Insiders Cause Problems
An enterprise company experiencing rapid growth was hiring new software engineers to aide in quick product development.
Due to an oversight in the onboarding process, their newest hire Tyler was assigned an IAM role with full administrative privileges over the entire AWS account (intended for senior administrators). Tyler was unaware of the level of access they had been granted and set to work developing a new feature!
While working on a deployment script, Tyler accidentally executed a command that deleted an entire S3 bucket containing critical customer data. The error was not immediately noticed because Tyler's elevated permissions allowed the script to execute without any warnings or alerts.
As the day progressed, the missing data caused a cascade of issues across the company's services. Customers experienced disruptions and the company's reputation took a hit.
Protect Your Identities
Deny privileged permissions access for identities which have been afforded it, but don't use it!
Select the scope at which you want to take action and click the button to see the changes you are about to make:
When ready, click the button to review those changes within the Pending Changes page before you deploy them to your cloud:
Unprotect at Scope
If you encounter a situation where you need to unprotect all services at scope, you can leverage the Services page menu:
By using this menu option, a CloudFormation template is generated that will remove all of the service protections you have put into place with the Cloud Permissions Firewall, re-enable all services that were disabled using the Cloud Permissions Firewall, and discard any pending changes.
