AWS EC2 User Data Modification on Stopped Instances

Attackers may target Amazon EC2 instances by stopping a running instance and modifying its User Data attribute. By injecting custom shell scripts into this attribute, an attacker ensures that their malicious code executes with root privileges upon the next instance start. This technique is often used to establish persistence or facilitate further lateral movement within a cloud environment. Defenders should monitor for sequential IAM activities where the same principal performs a 'StopInstances' operation followed closely by a 'ModifyInstanceAttribute' call specifically targeting the 'userData' field on the same EC2 instance. This activity is significant as it leverages standard AWS management features to bypass traditional endpoint security controls by subverting the instance boot process.

Attack Chain

1. Attacker obtains valid AWS IAM credentials with sufficient permissions to manage EC2 instances (ec2:StopInstances, ec2:ModifyInstanceAttribute).
2. Attacker enumerates target EC2 instances to identify high-value systems.
3. Attacker executes 'StopInstances' via the AWS API to transition the target instance to a stopped state.
4. Attacker waits for the instance state to change to 'stopped'.
5. Attacker executes 'ModifyInstanceAttribute' targeting the 'userData' attribute of the specific instance.
6. Attacker embeds a malicious payload, such as a reverse shell or script to download secondary malware, into the 'userData' field.
7. Attacker executes 'StartInstances' to restart the instance.
8. Instance executes the modified 'userData' script during the initialization sequence, leading to unauthorized code execution and persistence.

Impact

Successful exploitation allows for persistent unauthorized code execution on EC2 instances. This technique can lead to full system compromise, credential harvesting, or lateral movement into the VPC, impacting organizational cloud security and compliance posture.

Recommendation

• Deploy detection logic to identify the sequence of 'StopInstances' followed by 'ModifyInstanceAttribute' on the same instance ID by the same principal within a one-hour window.
• Implement IAM policies that follow the principle of least privilege, restricting 'ec2:ModifyInstanceAttribute' permissions to only necessary service accounts.
• Audit existing EC2 instances for unusual 'userData' configurations, particularly those that include base64-encoded scripts.
• Establish alerting for high-privileged IAM identities performing instance state management outside of documented maintenance windows.