An IAM privilege escalation is a technique that attacker abuse to gain higher privileges (e.g., access to critical resources) within your account.

Proper IAM permission management is critical to avoid privilege escalations within your account. Modern cloud attacks abuse combinations of critical IAM permissions to do so-called "policy shopping", allowing further unintended access. It is important to mention, that it is not only a single permission that is critical, but a combination of permissions. In the worst case, the attacker may gain the IAM AWS-managed policy AdministratorAccess which grants full control over the account.

Real-world and established cloud attacks have shown that an attacker who has initial access to a user (AWS identity) or compute resource (Lambda, EC2 instance) in your account can gain -- given the IAM permissions for those resources are ill-configured -- additional IAM policies. It's exactly those cases that CodeShield detects as part of its attack scenario feature.

CodeShield automatically detects attacks scenarios, and

1. showcases how an attacker can potential use existing and non-existing resources in your account to perform lateral movement, and
2. categorizes the attack scenarios with respect to their attack goals, and
3. computes which exact resources are impacted by a breach

Entrypoints to the analysis

Every escalation has to start somewhere. As entrypoints, we consider potential start points of an attacker. This means, the attacker has to compromise these entrypoints before an escalation can happen.

Our entrypoint comprise Users, compute resources (e.g., Lambda, EC2, ECS), and cross-account/federate assumable roles. Compute resources can be hacked by exploiting a (0-day) vulnerability, which would give attackers control over the cloud depending on the given IAM permissions and possible privilege escalations. Users should be considered as entry point in the case of insider attacks or when credentials are lost or phised.

Its possible to configure these entrypoints as required on the tool's settings page. E.g., one could configure the analysis to only take directly publicly reachable resources into account, to shrink the ammount of findings to the most critical ones.

info

Note that we suggest to eliminate all privilege escalation vulnerabilities, even of not directly reachable resources. An attacker might be able to gain access to these resources after entering the system from another entrypoint and potentially compromise the whole account with one privilege escalation.