Command Injection to EC2 User Data Privilege Escalation

What this lab covers

You enumerate a web application, find a parameter that passes input to an operating system command, and use that foothold to reach the cloud identity attached to the instance behind it.

The interesting part is the transition. Command injection on its own gives you execution in one place. What makes it a cloud incident is what the workload can reach afterwards, which is determined entirely by the role attached to it and by whether the metadata service is protected.

This is the initial access pattern that matters most for defenders to understand, because it does not depend on anyone leaking a credential. The application is the way in, and the credential is issued legitimately once you are there.

How command injection becomes cloud compromise

Command injection occurs when user input reaches an operating system shell without adequate validation. It differs from remote code execution in the language layer involved, but the practical result is the same: the attacker runs commands as the application's user.

On a cloud instance, the immediate next step is the metadata service, an endpoint reachable only from the instance itself that returns configuration and, critically, temporary credentials for the attached IAM role. Nothing needs to be stolen from disk, because the platform issues the credentials on request.

User data is the second prize. It is the script that runs at instance launch, it is retrievable from the same metadata endpoint, and it very frequently contains bootstrap secrets, database connection strings and internal endpoints that were never intended to be readable by the running application.

How to detect this in your own environment

The strongest cloud-side signal is the credential appearing somewhere it should not. Role credentials issued to an instance are expected to be used by that instance, so the same credentials seen from a different source address indicate theft. AWS surfaces this pattern directly, and it is one of the highest-fidelity cloud alerts available.

On the application side, watch for shell metacharacters and command separators in parameters that should never contain them, and for the process tree of a web application spawning a shell. The second is far more reliable than pattern matching on input.

Alert on metadata service access from unusual processes. Legitimate access comes from the SDK or agent. A request to the metadata endpoint originating from a shell or a web request handler is anomalous and worth treating as an incident.

How to prevent it

Require the session-oriented version of the metadata service. It requires a token obtained by a specific request method before credentials can be read, which defeats the common case where a server-side request forgery or a naive injection can only issue simple requests.

Scope the instance role to the minimum. The instance role is what an attacker inherits, so its permissions define the blast radius of every application flaw on that host. An instance that needs to read one bucket should be able to read one bucket.

Keep secrets out of user data. It is readable by anything that can reach the metadata service and it persists for the life of the instance. Use a secrets manager with scoped access so that reaching the metadata endpoint does not also hand over database credentials.

Real-world context

Exploitation of internet-facing applications is now one of the principal ways attackers reach cloud environments, and this chain is the reason why. The application vulnerability is the entry, but the impact is determined by the identity attached to the workload.

The 2019 Capital One breach, prosecuted by the US Department of Justice, followed this shape. A server-side request forgery weakness allowed the metadata service to be reached, credentials for the attached role were obtained, and those credentials were used to access data in S3. The disclosure and the subsequent US Department of Justice indictment describe an intrusion in which nothing was exploited at the AWS layer at all.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application, T1552.005 Cloud Instance Metadata API and T1078.004 Cloud Accounts.

Applying this at work

• Audit whether the session-oriented metadata service is required rather than optional on your instances. Many accounts still allow the older method.
• Review the IAM roles attached to internet-facing workloads and cut them to the minimum. This is the single control that limits the damage of any application flaw.
• Check your user data scripts for embedded secrets, across running instances and launch templates.
• Alert on instance role credentials being used from an address that is not the instance.
• Add detection for web application processes spawning shells.

Frequently asked questions

Why does command injection matter more in the cloud?

Because the compromised host holds credentials for its attached IAM role, retrievable from the metadata service. The attacker gains authenticated access to cloud services without stealing a stored credential, so a web flaw becomes a cloud identity incident.

What is EC2 user data and why is it a target?

It is the script that runs when an instance launches, retrievable from the instance metadata endpoint. It commonly contains bootstrap secrets, connection strings and internal endpoints, and it remains readable for the life of the instance.

Does requiring IMDSv2 actually help?

Substantially. It requires a token obtained via a specific request method before credentials can be read, which blocks the common case where an attacker can only trigger simple requests, such as many server-side request forgery conditions.

Do I need my own AWS account to practice this?

No. The lab runs in a live AWS environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own infrastructure.

Which certification covers this in depth?

The Amazon Cloud Red Team Professional (ACRTP) covers AWS initial access, metadata abuse and privilege escalation in full, and is assessed hands-on in a live AWS account.