SSRF AWS Instance Metadata Endpoint Access
An AI agent that can fetch URLs can be tricked into requesting a special internal address that only works inside AWS cloud servers. That address hands back the server's temporary cloud login credentials, letting an attacker steal them.
How the attack works
An attacker gets the agent to make an HTTP request to 169.254.169.254, the AWS EC2 Instance Metadata Service (IMDS), either directly or via a redirect from another URL the agent was told to fetch. This address is only reachable from inside the cloud instance, so browsers and external attackers can't reach it directly, but an agent's fetch tool running inside the instance can. The response includes IAM security credentials, instance identity documents, and other configuration data. The attacker then uses those stolen credentials to access AWS resources as if they were the instance itself. The rule also flags access to the IMDSv2 token endpoint at the same address.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 9a36712d-1abc-43df-8554-d8ca03f3eb41
- Severity
- Critical
Why it matters
Successful exploitation hands an attacker temporary AWS credentials tied to the instance's IAM role, which can be used to access or modify cloud resources, escalate privileges, or move laterally within the AWS environment.
What you can do
- →Enforce IMDSv2 (session-token-based) and disable IMDSv1 on EC2 instances so metadata cannot be fetched with a simple GET request.
- →Restrict the agent's HTTP-fetch tool from resolving or connecting to 169.254.169.254 and other link-local/internal addresses.
- →Give the instance's IAM role the minimum permissions it needs so stolen credentials have limited value.
- →Set the instance metadata hop limit to 1 to block metadata access from containers or proxies running on the instance.
Known benign look-alikes
- Security scanning agents explicitly authorized to test IMDS exposure