312-50 Question 446
Single answer▪ Cloud HackingDuring an authorized assessment of a company's AWS environment, you compromise a web application running on an EC2 instance. While reviewing the instance, you discover that the application stores user-uploaded files in an Amazon S3 bucket. The company wants to know whether an attacker who gains code execution on the EC2 instance could also access other AWS resources without additional credentials. What is the MOST appropriate next step to validate this risk in a safe and realistic way?
- A
Query the EC2 Instance Metadata Service (IMDS) for the attached IAM role credentials, then use those temporary credentials to enumerate allowed AWS API actions such as access to the S3 bucket
- B
Run a password spray against AWS Management Console accounts because EC2 instances usually cache console passwords for service accounts
- C
Capture and crack the TLS private key used by the application server to derive AWS API keys for the environment
- D
Exploit Amazon S3 directly by sending crafted HTTP requests to bypass IAM authorization from the public internet
Show answer and explanation
Correct answer: A
Explanation
This question tests a key cloud-hacking concept: cloud workloads often inherit permissions through attached identities rather than through static credentials stored on disk. In AWS, EC2 instances commonly use instance profiles backed by IAM roles. The EC2 Instance Metadata Service (IMDS) exposes metadata and, when a role is attached, temporary security credentials for that role to processes on the instance. Therefore, after achieving code execution on an EC2 host during an authorized assessment, one of the most realistic next steps is to inspect IMDS and enumerate the effective permissions of the role. This helps determine whether host compromise can lead to privilege escalation into the AWS control plane or data access such as S3. Best practice references include AWS documentation for IAM roles for Amazon EC2 and the EC2 Instance Metadata Service, including IMDSv2 guidance. From a defensive perspective, organizations should apply least privilege to instance roles, restrict outbound access where appropriate, and harden applications against SSRF and host compromise because these can expose metadata-based credentials.
- A. Correct.
Correct. In AWS, EC2 instances can be assigned an IAM role, and temporary credentials for that role are commonly exposed to the instance through the EC2 Instance Metadata Service at 169.254.169.254. If an attacker has code execution on the instance, a realistic and authorized validation step is to query IMDS for the role name and temporary credentials, then use AWS API calls to enumerate what the role can access, such as S3 buckets, objects, or other services. This directly tests whether compromise of the workload can lead to cloud control-plane access through the instance profile.
- B. Incorrect.
Incorrect. Password spraying against AWS console accounts is a different attack path and is not the most appropriate next step in this scenario. EC2 instances do not normally cache AWS Management Console passwords for service accounts. In AWS, machine access is typically performed with IAM roles or access keys, not stored console credentials. This option reflects a common misconception that host compromise automatically yields console credentials.
- C. Incorrect.
Incorrect. TLS private keys used by the application server do not provide AWS API credentials. Even if a private key were captured, it would be used for HTTPS encryption and server identity, not to derive IAM access keys or temporary role credentials. This option confuses transport security material with cloud identity and access management credentials.
- D. Incorrect.
Incorrect. Amazon S3 authorization is enforced by IAM policies, bucket policies, ACLs, and related controls. There is no legitimate testing approach in which crafted public HTTP requests simply bypass IAM authorization. If the bucket were publicly exposed due to misconfiguration, that could be tested separately, but the scenario specifically asks whether compromise of the EC2 instance enables access to AWS resources without additional credentials. The relevant path is the instance's IAM role, not an imagined S3 authorization bypass.