Simple Scans for Cloud Metadata Service, (Wed, Aug 19th)

Simple Scans for Cloud Metadata Service

Published: 2026-08-19. Last Updated: 2026-08-19 14:24:58 UTC

by Johannes Ullrich (Version: 1)

0 comment(s)

Cloud providers typically expose a REST API at 169.254.169.254 that allows code running on virtual machines to retrieve machine-specific data. Some of the data is more or less harmless, such as the region the machine is running in or its MAC and IP addresses. However, the service may also be used to retrieve credentials for IAM roles and service account tokens.

Why 169.254.169.254, and not, for example, an RFC1918 address or loopback? RFC 1918 addresses are usually used and routed internally by cloud providers. Interfering with them would be risky and add complexity. The loopback interface is often treated differently from a normal interface, particularly in containers, and is not well-suited for traffic that must be controlled by the operating system's packet-filtering mechanisms. 169.254.169.254 is part of the link local address prefix 169.254/16 [RFC3927]. These addresses are specifically not routable, unlike RFC 1918 addresses, which may be routed locally ("The host MUST NOT send a packet with an IPv4 Link-Local destination address to any router for forwarding.").

This unique property of link-local addresses makes them ideal for addresses used multiple times , and that must never be routed. An attacker will not be able to reach out to this address remotely. But there is a "trick": the virtual machine itself can reach the metadata service, and if an attacker uses server-side request forgery (SSRF) to trick the server into sending the request, the address may be reached. The attacker could now use this SSRF vulnerability to retrieve secrets [1].

Probably the best-known breach assisted by the metadata service was Capital One, which led to a huge data leak and later to the prosecution of the attacker. Since then, we have seen attempts to exploit SSRF vulnerabilities in order to access the metadata service. But what I notied today is a widespread scan that appears to be not targeted at a particular vulnerability:

** `GET /?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1

Host: [redacted]

User-Agent: Go-http-client/1.1

Accept-Encoding: gzip`

This scan does not appear to target a specific vulnerability; it is a more generic attempt to find "some" vulnerability, and it is not clear which one. If you have any insight, please let me know :)

As far as securing the metadata service goes, Amazon used version 2 of the service following the Capital One breach. A simple "GET" request is no longer sufficient, making SSRF access highly unlikely.

Special IPv6 note: IPv6 uses fd20:ce::254, which is a unique local address, more like an RFC 1918 address instead of an IPv6 link-local fe80:: address.

[1] https://www.sans.org/blog/cloud-instance-metadata-services-imds-

--

Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu

Twitter|

Keywords: ids cloud metadata services surf

0 comment(s)