Digital Garbage Hits the Cloud Core: Indiscriminate Scanning

On August 19, 2025, Johannes B. Ullrich, Dean of Research at SANS.edu, reported first-hand observation of widespread, untargeted scanning against the IPv4 address 169.254.169.254, the standard endpoint for the Cloud Metadata Service. The detection does not involve a sophisticated exploit but a brute-force, generic approach probing the SSRF attack surface without selecting specific targets. The novelty lies in the method: operators appear to be shifting from the targeted attacks of the past to carpet-bombing reconnaissance that counts on the persistence of weak configurations.

Why 169.254.169.254 Is a Sensitive Target

Cloud providers expose REST metadata APIs at 169.254.169.254. The service can return IAM role credentials and service account tokens, making it a strategic target for post-compromise or privilege escalation. The address falls within the link-local 169.254/16 prefix defined in RFC 3927, assigned for non-routable local communications on IPv4 networks. Non-routability makes it ideal for services that must be accessible only locally to the VM, but it does not immunize against attacks that exploit the server as an unwitting proxy.

Attackers can reach the metadata service via SSRF, inducing the server to forward the request to the link-local address. The technique is not new. The Capital One breach remains the most notable case of metadata service abuse, with consequences including data leaks and legal proceedings. That incident catalyzed Amazon's introduction of IMDSv2, which adds session-based authentication to the simple GET request.

From Precision Strike to Network Spam: The Tactical Shift

What distinguishes Ullrich's detection is not the vulnerability exploited, but the absence of target selection. The scanning does not appear to target a specific vulnerability; it is a more generic attempt to find "some" vulnerability, and the target remains undefined. This shift from targeted SSRF exploits — which presupposed knowledge of the vulnerable application and its cloud stack — to indiscriminate reconnaissance reveals a different maturity in offensive tactics.

The logic is that of spam applied to infrastructure: if a sufficient number of cloud instances remain configured with IMDSv1 or present unmitigated SSRF paths, the cost of generalized scanning pays off with the volume of potential successes. The dossier does not specify whether the scanning is automated or manual, nor its temporal frequency. Quantitative data on requests per minute, source IPs, geographic distribution, or target verticals are missing.

"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." — Johannes B. Ullrich, Dean of Research, SANS.edu

IMDSv2 and the Limit of Distributed Mitigation

Amazon introduced IMDSv2 after the Capital One breach. The protocol requires a sequence of authenticated requests that makes SSRF access via simple GET "highly unlikely," as Ullrich documents. The mitigation is technically sound but depends on its universal adoption: instances with IMDSv1 enforced or hybrid configurations remain exposed to the basic technique. The problem therefore shifts from a technological gap to an operational gap, from a zero-day vulnerability to a legacy configuration.

The dossier does not document specific remedial measures nor the state of IMDSv2 adoption across the instance fleet exposed to the scanning. IPv6 introduces a relevant technical distinction: the equivalent address is fd20:ce::254, a unique local address, not fe80:: as one might assume from the IPv4 link-local model. This architectural detail indicates that scanning operators must adapt their tooling to two separate namespaces.

Why It Matters

The source does not specify the nature of any data potentially exposed by vulnerable instances. The dossier does not document compromises that have occurred, nor does it provide verifiable indicators of compromise. Independent confirmations from other researchers, CERTs, or honeypot datasets are lacking. The exact volume of the scanning, its geographic origin, precise motivation, and target distribution remain unknown.

What emerges clearly is the strategic signal: the IMDS/SSRF attack surface remains actively probed even with generic techniques, not just targeted exploits. The persistence of this scanning — even in its indeterminacy — indicates that offensive operators still consider the bet on weak cloud configurations profitable. The brief does not specify whether cloud providers other than AWS are included in the scanning perimeter.

What We Don't Know and Verification Points

The dossier leaves relevant operational questions open. It does not emerge whether the scanning is associated with a known attack framework, a previous campaign, or a specific actor. Request patterns, user-agents, or other technical fingerprints that would enable recognition are not documented. The year of the event is inferred: the diary publication date is August 19, 2025, but the dossier does not explicitly state whether the scanning occurred on that day or over a broader timeframe.

The lack of published raw logs limits the reproducibility of the observation. Ullrich reports the event as a first-hand detection, but the reader has no access to the raw data supporting it. This is a structural limit of the single source, not a delegitimization: the institutional credibility of SANS and the author's position provide context, but do not replace independent verification.

Sources

• https://isc.sans.edu/diary/rss/33260
• https://www.rfc-editor.org/info/rfc3927/
• https://sans.edu/
• https://jbu.me/164
• https://www.sans.org/blog/cloud-instance-metadata-services-imds-

Information is based on the cited source and current as of publication.

Sources