A persistent privilege escalation technique in AWS that allows attackers with limited permissions to execute code under higher-privileged execution roles on EC2 instances and SageMaker notebook instances.
First documented by Grzelak in 2016 for EC2, the method exploits modifiable boot-time configurations to inject malicious payloads, bypassing standard IAM controls like PassRole.
Recent analysis from Security researcher Daniel Grzelak confirms the pattern persists across AWS services, highlighting ongoing risks in cloud compute environments.
Attackers with ec2:StartInstances, ec2:StopInstances, and ec2:ModifyInstanceAttribute permissions target existing EC2 instances attached to powerful instance profiles.
SageMaker Privilege Escalation
By stopping the instance, they modify the userData attribute using a #cloud-boothook directive, which triggers script execution on every reboot.
Restarting the instance runs the injected code, such as credential exfiltration, in the context of the instance’s execution role, granting access to its full permissions.
This technique remains viable today, as AWS documentation still permits userData modifications post-launch. CloudTrail logs reveal the attack through sequences like StopInstances → ModifyInstanceAttribute → StartInstances from unexpected principals.
Mitigation demands restricting ec2:ModifyInstanceAttribute to trusted administrators, treating it as equivalent to arbitrary code execution under the target role.
Amazon SageMaker notebook instances, powered by managed Jupyter environments, introduce a parallel vector via lifecycle configurations, shell scripts executed on start or creation.
Permissions for sagemaker:StopNotebookInstance, sagemaker:UpdateNotebookInstance (with lifecycle-config-name), and sagemaker:StartNotebookInstance enable the escalation: halt a notebook, create or attach a malicious lifecycle config with base64-encoded credential-stealing code, then restart.
Daniel Grzelak of Plerion provided proof-of-concept bash code demonstrating the full chain, from config creation to exfiltration via a callback endpoint.
SageMaker’s complexity, spanning notebooks, domains, and studios, amplifies exposure, as execution roles often carry broad data science permissions like S3 access or model deployment.
Rhino Security Labs previously noted similar SageMaker abuses, but lifecycle updates represent a subtler, post-configuration modification.
The core flaw stems from PassRole checks occurring only at resource creation, decoupling role assignment from runtime code changes. Similar patterns affect Lambda (via UpdateFunctionCode), CloudFormation change sets, and potentially SageMaker Studios.
Attackers can systematically hunt for AWS API endpoints with execution role dependencies, enabling widespread exploitation.
Detection relies on CloudTrail monitoring for Stop → Update → Start patterns on compute resources, primarily from non-operational identities.
Prevention involves least-privilege scoping around config-modifying actions, Service Control Policies (SCPs) denying broad execution role passages, and approval workflows for restarts.
AWS classifies these as configuration issues under the shared responsibility model, urging teams to audit execution role assumptions rigorously.
Follow us on Google News, LinkedIn, and X for daily cybersecurity updates. Contact us to feature your stories.
