PowerUserAccess vs. AdministratorAccess from an attacker's perspective

Being a cloud engineer is hard. The security team asks you to not have identities with AdministratorAccess attached to them because compliance and best practices. The developers keep requesting new permissions for day-to-day tasks. To fit all needs, you start attaching the AWS Managed Policy PowerUserAccess to developers. This article will highlight from personal hacking experience how environment complexity makes both policies effectively equivalent from an attacker's perspective.

Policy Comparison: Permissions and Access Levels

AdministratorAccess Policy

The AdministratorAccess policy is an AWS-managed policy that provides full access to all AWS services and resources within an account. This policy allows users to perform any action on any resource, including sensitive administrative tasks such as managing IAM users, groups, roles, and policies. It is the most permissive policy available in AWS. The policy document does not impose any restrictions, making it the ultimate goal for attackers. (AWS AdministratorAccess Policy).

{
  "Version" : "2012-10-17",
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : "*",
      "Resource" : "*"
    }
  ]
}

PowerUserAccess Policy

The PowerUserAccess policy provides broad access to AWS services and resources but explicitly restricts permissions related to IAM, AWS Organizations and Account actions. Users with this policy can create and manage AWS resources but cannot manage IAM users, groups, or roles. This restriction aims to ensure (at least tries to) that users with PowerUserAccess cannot escalate privileges by modifying IAM configurations. (AWS PowerUserAccess Policy).

{
  "Version" : "2012-10-17",
  "Statement" : [
    {
      "Effect" : "Allow",
      "NotAction" : [
        "iam:*",
        "organizations:*",
        "account:*"
      ],
      "Resource" : "*"
    },
    {
      "Effect" : "Allow",
      "Action" : [
        "account:GetAccountInformation",
        "account:GetPrimaryEmail",
        "account:ListRegions",
        "iam:CreateServiceLinkedRole",
        "iam:DeleteServiceLinkedRole",
        "iam:ListRoles",
        "organizations:DescribeOrganization"
      ],
      "Resource" : "*"
    }
  ]
}

From the Attacker's Perspective

Depending on the attacker's goals, having access to an AWS identity with PowerUserAccess attached to it might be sufficient. Even with temporary access, these permissions can be leveraged to launch crypto mining operations, exfiltrate sensitive data, or even execute S3-based ransomware attacks.

In these scenarios, PowerUserAccess can be practically as damaging as AdministratorAccess from an attacker's perspective. However, for more sophisticated goals requiring long-term persistence, having only PowerUserAccess permissions might seem insufficient, since direct IAM manipulation is restricted.

Can attackers achieve persistence or even escalate privileges despite these limitations? In most complex environments, the answer is surprisingly often "yes" - and it all depends on how your infrastructure is configured.

Privilege Escalation

Is it worth it?

A question I frequently encounter is about the impact of escalating privileges from PowerUserAccess to AdministratorAccess. Is it worth the effort? The difference between these two permission sets is comparable to that between a helicopter and an airplane. Both can fly, but for a prolonged two-year espionage campaign, the airplane is indisputably superior.

While I understand the basis of this question, it's important to recognize that for an attacker, establishing reliable persistence across multiple identities over an extended period is incredibly valuable. Consider the scope of data collection an attacker could perform from S3 buckets, EC2 instances, and RDS databases over several months. Not to mention the opportunity to monitor for mistakes that might grant them access to your on-premises network. Sophisticated attackers are patient, and for sustained operations, they strongly prefer AdministratorAccess.

How it happens

I've observed environments in both their early stages and mature states - large organizations implementing automation, environment segregation, and overall good practices that enhance security posture.

However, what worked well initially often proves inadequate years later. New requirements emerge, deadlines force teams to implement temporary fixes that become permanent, and eventually, you're left with vulnerable automated workflows affecting all environments.

It's important to understand that your effective permission level in AWS isn't limited to the policies directly attached to your identity. As long as you can access or modify other resources, your actual access level equals the sum of all accessible permissions.

Authentication flow between Terraform and OIDC in AWS

When PowerUserAccess exists in your environment, all it takes is a Lambda function with inappropriate IAM permissions, an EC2 instance with an overly permissive role, or a CloudFormation template with AdministratorAccess. Through PowerUserAccess, attackers can escalate privileges by modifying and invoking that Lambda function, using SSM SendCommand to exfiltrate access credentials from the EC2 instance, or altering the CloudFormation template to include a privilege escalation vector.

In practice, I've encountered administrator roles directly attached to various resource types. This doesn't even account for all the roles within environments that can be assumed with sts:AssumeRole. When all these factors combine, the supposed "power user" in that environment effectively becomes an administrator.

Remediation and Mitigation

The goal of sound IAM posture is granting the minimum permissions over only the necessary resources without affecting daily operations (easier said than done, I know).

With this goal in mind, we can confidently say that using PowerUserAccess violates the Principle of Least Privilege and will likely enable privilege escalation sooner or later.

The recommendation is to detach this policy from identities in your environment. If you work in a large organization where the power user is integrated into new account provisioning automation, the situation becomes more complex. Start by eliminating PowerUserAccess from this point forward. Ensure you test new automation before deploying to production. Then, analyze the impact of removing this policy from existing environments. Examine the specific permissions required and activities performed by identities currently using this policy. If feasible, remove the policy completely.

Takeaways

False Sense of Security: The gap between PowerUserAccess and AdministratorAccess is often an illusion in complex environments. What appears to be a security boundary may be easily circumvented.

Environment Complexity Increases Risk: As AWS environments grow and evolve, temporary solutions become permanent, creating privilege escalation paths that weren't originally intended.

Think Like an Attacker: Regular security assessments should include testing privilege escalation scenarios - what could an identity with PowerUserAccess potentially access or modify?

Continuous IAM Auditing: Regularly review which identities have broad permission sets like PowerUserAccess and audit what resources those identities are actually using.

Custom Policy Approach: Instead of using broad managed policies, develop custom policies that grant only the specific permissions needed for each role or function.

Defense in Depth: Implement additional security controls beyond IAM, such as resource-based policies, SCPs (Service Control Policies), and permission boundaries.

Least Privilege as Process: Achieving least privilege is an ongoing process, not a one-time implementation. Start restrictive and add permissions as needed rather than starting with broad access.