Privilege Escalation

Privilege escalation occurs when a user, application, or service gains capabilities beyond its intended authorization. In cloud systems, this often involves valid API calls rather than an operating-system exploit. A developer who cannot directly read sensitive data might nevertheless be able to modify a workload that runs under an identity authorized to read it. The security question is therefore not only what the developer can access now, but also what permissions the developer can acquire or exercise indirectly.

Evaluate effective authorization across identity policies, resource policies, role trust policies, session restrictions, organizational controls, and relevant conditions. Authentication establishes who is making a request; authorization determines whether that request is allowed. Successful authentication, including multifactor authentication, does not make an excessively permissive authorization policy safe. Likewise, an identity with no administrator policy can still have an escalation path through a small combination of powerful permissions.

For example, an AWS identity allowed to change a managed IAM policy and make a new policy version the default could expand its own access if that policy controls its permissions. Another identity might combine iam:PassRole with permission to create and invoke a function using a more privileged execution role. Passing a role does not itself provide the caller with the role’s credentials, but controlling code that executes under that role can expose its capabilities. Investigate the complete chain, including the role’s trust policy, the caller’s deployment permissions, and the workload’s reachable resources.

Role assumption is another important path. A broadly written trust policy can let an unintended principal obtain a privileged session, subject to the applicable authorization requirements. Cross-account access is not automatically privilege escalation: it may be an intentional delegation. It becomes a security problem when the effective access exceeds the approved scope. Similarly, legitimate, approved temporary elevation is different from unintended elevation, although both require careful restrictions and auditing.

Start an investigation by identifying the principal, the unexpected action, the affected resource, and the authorization changes preceding the event. Review policy attachments, policy versions, group membership, trust relationships, resource policies, permissions boundaries, and organizational policies. Use audit records to reconstruct policy changes, role assumptions, and workload modifications. In AWS, iam:PassRole is a permission check rather than a standalone API call, so investigate the service API operation that received the role instead of expecting a separate PassRole event.

AWS IAM Access Analyzer helps identify resource access outside a configured zone of trust, validate policies, and find unused access through the corresponding analyzer capabilities. Findings require interpretation: an external-access finding can represent approved sharing, while the absence of a finding does not prove that no escalation chain exists. Policy validation checks policy structure and security concerns; it is not a complete assessment of every possible combination of permissions and workload behavior.

Correct the enabling permissions rather than merely removing the final administrator policy. Restrict role passing to approved role ARNs and services, separate workload deployment from privileged identity administration, and protect policy and boundary changes. Permissions boundaries limit identity-based permissions but do not grant access; some direct resource-policy grants have different evaluation behavior, so boundaries are not a universal ceiling. AWS Organizations service control policies establish guardrails for covered principals in member accounts, but they also do not grant permissions and have documented exclusions.

Containment may require disabling compromised credentials, revoking applicable role sessions, removing persistence, and correcting resource policies as well as identity policies. Changing a role’s trust policy prevents newly authorized assumptions but does not automatically invalidate sessions already issued. After remediation, test both prohibited escalation paths and legitimate workflows. Narrow permissions reduce risk but increase policy maintenance and troubleshooting effort; controlled elevation, automated policy checks, and monitored emergency access help balance operational needs with enforceable authorization boundaries.