312-50 Question 333
Single answer▪ Attack Shared EnvironmentsDuring an authorized assessment of a company’s cloud-hosted application, you are given a low-privilege shell inside a Linux virtual machine running in a public IaaS environment. The scope explicitly allows testing for risks unique to shared environments, but it prohibits denial-of-service and any attempt to access other tenants’ data. You want to determine whether the instance is vulnerable to metadata-service abuse that could expose temporary cloud credentials from within the guest OS. Which action is the most appropriate next step?
- A
From the compromised instance, send an HTTP request to the link-local metadata IP and inspect only the instance’s own metadata and attached IAM role credentials
- B
Use ARP spoofing on the virtual subnet to intercept traffic from neighboring tenants and capture their cloud access keys
- C
Run a high-volume packet flood against the hypervisor management interface to test whether isolation fails under load
- D
Exploit speculative execution to dump memory from the physical host and recover credentials belonging to other tenants
Show answer and explanation
Correct answer: A
Explanation
The best answer is to test the instance’s own access to the cloud metadata service from within the guest OS. In shared environments, one of the most practical attack paths is not breaking hypervisor isolation, but abusing cloud instance metadata to obtain temporary credentials assigned to that workload. This is especially relevant when attackers gain code execution on a host or exploit SSRF in an application. Major cloud providers document metadata services and associated protections. For example, AWS documents the Instance Metadata Service (IMDS) at 169.254.169.254 and recommends IMDSv2 to reduce abuse risk; Microsoft Azure and Google Cloud also document metadata endpoints and required headers. Best practice during an assessment is to validate only the current instance’s exposure, avoid attempts to reach other tenants, and avoid disruptive tests such as DoS or host-level escape attempts unless explicitly authorized. This aligns with CEH expectations for ethically testing shared-environment weaknesses while respecting scope and isolation boundaries.
- A. Correct.
Correct. In many cloud platforms, instance metadata is exposed through a link-local address reachable from inside the guest. In AWS, for example, the Instance Metadata Service is accessible at 169.254.169.254. Querying the local instance’s metadata and any attached IAM role credentials is a realistic, in-scope way to assess whether SSRF-style metadata exposure or local credential harvesting is possible. This tests a shared-environment risk without attempting to access data belonging to other tenants.
- B. Incorrect.
Incorrect. ARP spoofing to intercept traffic from neighboring tenants assumes you can directly attack other customers on the same shared infrastructure. In modern public cloud environments, tenant isolation at the virtual networking layer is designed to prevent this, and attempting it would violate the stated scope because it targets other tenants’ traffic and credentials.
- C. Incorrect.
Incorrect. Flooding a hypervisor management interface is a denial-of-service style activity, which the scenario explicitly prohibits. It also does not represent a safe or appropriate validation step for shared-environment risk in a professional assessment.
- D. Incorrect.
Incorrect. Attempting a speculative-execution or host-memory extraction attack against the physical host is both highly disruptive and clearly out of scope because it seeks access to other tenants’ data. While side-channel risks in shared environments are a real research topic, this action would not be the appropriate next step in an authorized CEH-style engagement with explicit tenant-safety restrictions.