Description

Attackers with limited AWS permissions can still gain elevated access by manipulating boot-time or startup configurations on compute services such as EC2 and SageMaker. This issue, originally identified years ago, persists because AWS allows certain launch-time settings like user data or lifecycle scripts to be updated after a resource is created. If an instance or notebook relies on a powerful execution role, changes to these configurations can cause the resource to run attacker-supplied code during its next startup, effectively granting the intruder the permissions associated with that role. Recent research has shown that this pattern extends across multiple AWS services. By stopping a compute resource, modifying its startup configuration, and then restarting it, an attacker can trigger execution of injected scripts with the resource’s high-privilege role. CloudTrail typically records these events as a sequence of halt-modify-start operations performed by unexpected identities, which can help with post-incident detection. SageMaker environments are similarly affected because lifecycle scripts can be swapped or altered, allowing malicious commands to run whenever a notebook instance boots. The underlying risk stems from a long-standing separation between role assignment and runtime configuration changes. Because IAM’s PassRole restrictions apply only during initial resource creation, modifying existing startup scripts becomes a path to privilege escalation if configuration-altering permissions are too broad. Effective mitigation requires tightly controlling who can update instance attributes or notebook settings, enforcing least-privilege principles, and using guardrails such as SCPs and approval workflows for configuration changes and restarts. AWS considers these exposures to fall within customer configuration responsibility, making regular audits of permissions and execution roles essential.