AWS Execution Roles Enable Subtle Privilege Escalation in SageMaker and EC2

A persistent privilege escalation method has been identified within AWS services, allowing attackers with limited permissions to execute code under higher-privileged execution roles on EC2 and SageMaker notebook instances.

This technique, first documented in 2016, exploits modifiable boot-time configurations to inject malicious payloads, bypassing standard IAM controls such as PassRole. Recent analysis confirms this vulnerability persists across AWS services, posing ongoing risks in cloud computing environments.

Attackers with permissions like ec2:StartInstances , ec2:StopInstances , and ec2:ModifyInstanceAttribute can target EC2 instances attached to powerful instance profiles. By altering the userData attribute using a #cloud-boothook directive, they trigger script execution upon reboot. This results in the execution of the injected code, such as credential exfiltration, under the instance's execution role, granting access to its full permissions.

This method remains viable as AWS documentation permits userData modifications post-launch. CloudTrail logs can detect this attack through sequences like StopInstances → ModifyInstanceAttribute → StartInstances from unexpected principals. Mitigation involves restricting ec2:ModifyInstanceAttribute to trusted administrators.

Amazon SageMaker notebook instances, leveraging managed Jupyter environments, introduce a similar vector via lifecycle configurations, which are shell scripts executed on start or creation. Permissions such as sagemaker:StopNotebookInstance , sagemaker:UpdateNotebookInstance (with lifecycle-config-name), and sagemaker:StartNotebookInstance enable the escalation. A notebook can be halted, a malicious lifecycle configuration attached with credential-stealing code, and then restarted.

SageMaker's complexity, spanning notebooks, domains, and studios, increases exposure since execution roles often have extensive data science permissions, including S3 access and model deployment.

The fundamental issue arises from PassRole checks occurring only at resource creation, decoupling role assignment from runtime code changes. This pattern also affects other AWS services, such as Lambda and CloudFormation, and potentially SageMaker Studios.

Detection relies on CloudTrail monitoring for Stop → Update → Start patterns on compute resources, especially from non-operational identities. Prevention strategies include least-privilege scoping around configuration-modifying actions, Service Control Policies (SCPs) restricting broad execution role assignments, and approval workflows for restarts.

AWS classifies these as configuration issues under the shared responsibility model and advises teams to rigorously audit execution role assumptions.

Based on reporting by Cyber Security News.