312-50 Question 444
Single answer▪ Cloud HackingDuring an authorized assessment of a company's AWS environment, you gain code-execution on an EC2 instance running a public web application. The instance uses an IAM role to access other AWS services. Your goal is to determine whether the instance role has overly permissive privileges that could allow lateral movement or data access beyond the web application's intended function. Which action is the MOST appropriate next step?
- A
Query the EC2 Instance Metadata Service (IMDS) from the compromised instance to obtain temporary role credentials, then use those credentials to enumerate allowed AWS API actions and accessible resources within the authorized scope
- B
Run a password-spraying attack against AWS console users because IAM roles cannot be used for API access from EC2 instances
- C
Capture the hypervisor memory of the underlying AWS host to extract long-term AWS root account keys associated with the tenant
- D
Modify the instance's security group to allow inbound SSH from the internet so you can perform deeper privilege testing from your workstation
Show answer and explanation
Correct answer: A
Explanation
In AWS, an EC2 instance with an attached IAM role can obtain temporary security credentials from the EC2 Instance Metadata Service. For a security tester with authorized code execution on that instance, the most direct and realistic next step is to retrieve those temporary credentials and enumerate what the role can do. This is a common cloud post-exploitation technique because overly broad instance roles can enable access to sensitive services such as S3, Secrets Manager, Parameter Store, DynamoDB, or privilege escalation paths through IAM-related permissions. Best practice is to use the credentials only within the approved scope and validate least-privilege issues without making unnecessary configuration changes. Relevant AWS references include the EC2 Instance Metadata documentation, IAM roles for Amazon EC2, and AWS IAM security best practices on using temporary credentials and least privilege.
- A. Correct.
Correct. On EC2, applications commonly obtain temporary credentials for the attached IAM role through the Instance Metadata Service at 169.254.169.254. In an authorized assessment, retrieving those temporary credentials from the instance and using them to enumerate identity details, permissions, and reachable services is the proper way to test whether the role is overprivileged. This reflects a real cloud-hacking workflow: validate role-based access, then assess impact such as access to S3 buckets, Secrets Manager, Systems Manager, or other AWS resources, while staying within scope.
- B. Incorrect.
Incorrect. IAM roles absolutely can be used for API access from EC2 instances through temporary credentials delivered by IMDS. Password spraying against console users is a different attack path, is noisier, and is not the most appropriate next step when you already have code execution on an EC2 instance with an attached role. This option reflects the misconception that only IAM users with long-term keys can access AWS APIs.
- C. Incorrect.
Incorrect. Customers do not have access to the underlying AWS hypervisor, and attempting to extract host-level memory or root account keys is not a realistic or permitted technique in a standard CEH-style cloud assessment. AWS root credentials are not exposed this way, and the action goes far beyond normal tenant-level testing. This distractor represents confusion between cloud customer access boundaries and provider infrastructure.
- D. Incorrect.
Incorrect. Changing security groups to open SSH from the internet alters the target environment and creates unnecessary exposure. It is not required to evaluate the instance role's privileges and may violate rules of engagement. The scenario already states you have code execution on the instance, so the best next step is to assess the IAM role from that foothold rather than weaken network controls.