AWS API calls indicating EC2 privilege escalation
Description
AlphaSOC detected an IAM policy change that grants a principal permissions enabling one of two known EC2 privilege escalation paths.
The first path combines iam:PassRole with ec2:RunInstances. This allows the
principal to launch a new EC2 instance and attach an IAM role with higher
privileges than they currently hold. Once the attacker accesses the instance via
SSM, SSH, or other means, they inherit the permissions of the attached role.
The second path combines ec2:StartInstances with
ec2:ModifyInstanceAttribute. This allows the principal to modify a stopped EC2
instance's attributes, most critically the IAM role attached to it. An attacker
can change the instance's role to one with higher privileges, then start the
instance and gain access with those elevated permissions. The
ec2:ModifyInstanceAttribute permission can also be used to modify user data,
enabling malicious boot-time scripts. This vector is worth flagging because
ec2:ModifyInstanceAttribute is a high-risk permission rarely needed outside
tightly scoped administrative or automation tasks.
Both paths let an attacker inherit elevated permissions while blending in with normal EC2 activity. These permission combinations are uncommon in well-scoped environments and represent classic escalation vectors when over-provisioned.
This detection triggers on IAM policy creation or modification events (CreatePolicy, CreatePolicyVersion, PutUserPolicy, PutGroupPolicy, PutRolePolicy, AttachUserPolicy, AttachRolePolicy, AttachGroupPolicy) that introduce these dangerous permission combinations.
Impact
If exploited, either path gives the attacker the full permissions of the targeted role from within the instance. This can lead to broad access across AWS services, data exfiltration, persistence, or further lateral movement—all while blending in with normal EC2 activity.
Severity
| Severity | Condition |
|---|---|
Low | AWS API calls indicating EC2 privilege escalation |
Investigation and Remediation
Check CloudTrail for the specific PutUserPolicy, PutGroupPolicy, PutRolePolicy, or Attach*Policy event that added these permissions. Identify the target principal and the source of the change.
Confirm whether the combination is required for legitimate automation. If not, detach or delete the policy immediately.
Review the principal's recent activity for signs of exploitation, such as new instance launches or attribute modifications.
Rotate credentials for the principal and any roles it can now target.