After a web application compromise, responders see outbound requests from the app tier to the instance metadata service collecting temporary cloud credentials. Which attack path should the city treat this as?
Select an answer to reveal the explanation.
Short Explanation
Instance metadata is like a sticky note on the server that holds short-lived cloud keys—super handy for legitimate apps, super dangerous if an attacker can read it. After a web foothold, grabbing those credentials is a classic cloud move. Lock down metadata hops and keep secrets off the public path.
Full Explanation
After a web application compromise, responders seeing outbound requests from the app tier to the instance metadata service collecting temporary cloud credentials should treat the path as metadata service abuse used to steal temporary credentials from the instance identity. Workloads legitimately retrieve short-lived role credentials from metadata; attackers with code execution or SSRF abuse the same channel to escalate inside the municipal account. Normal health-check traffic from the load balancer does not rewrite security group rules by scraping instance metadata for keys. Provider-initiated inventory sync that always exports long-lived root passwords misstates how cloud instance identity works. DNSSEC validation failures do not automatically grant Owner rights on the subscription. Exam caveat: harden metadata access (for example IMDSv2 and hop limits), keep instance roles least-privilege, and restrict egress where feasible—metadata is a credential source, not just an inventory API. Operational check: inspect app and VPC logs for access to the metadata address, enforce IMDSv2 if available, revoke active temporary credentials, shrink the instance role, patch the web foothold, and document the civic containment steps in the incident record.