« Appendix n: Downloadable rule update v8.19.27 GenAI CLI Started with Unsafe Permission Bypass »
Elastic Docs ›Elastic Security [8.19] ›Downloadable rule update v8.19.27

Web Server Cloud Metadata SSRF Request

edit
IMPORTANT: This documentation is no longer updated. Refer to Elastic's version policy and the latest documentation.

Web Server Cloud Metadata SSRF Request

edit

Detects HTTP requests to web servers whose URL or query string references cloud instance metadata endpoints or equivalent encoded variants. Attackers exploit server-side request forgery (SSRF) vulnerabilities in web applications to reach link-local metadata services on AWS, GCP, Azure, and similar cloud providers and harvest temporary credentials, tokens, or instance details.

Rule type: eql

Rule indices:

  • logs-nginx.access-*
  • logs-apache.access-*
  • logs-apache_tomcat.access-*
  • logs-iis.access-*
  • logs-traefik.access-*
  • logs-zeek.http-*

Severity: medium

Risk score: 47

Runs every: 5m

Searches indices from: now-9m (Date Math format, see also Additional look-back time)

Maximum alerts per execution: 100

References:

Tags:

  • Domain: Web
  • Domain: Cloud
  • Domain: Network
  • Use Case: Threat Detection
  • Tactic: Credential Access
  • Tactic: Initial Access
  • Data Source: Nginx
  • Data Source: Apache
  • Data Source: Apache Tomcat
  • Data Source: IIS
  • Data Source: Traefik
  • Data Source: Zeek
  • Resources: Investigation Guide

Version: 1

Rule authors:

  • Elastic

Rule license: Elastic License v2

Investigation guide

edit

Triage and analysis

Investigating Web Server Cloud Metadata SSRF Request

This alert flags inbound HTTP requests to a web server whose url.original or url.query contains cloud instance metadata addresses, hostnames, or credential paths. A common attacker pattern is exploiting an SSRF vulnerability so the application fetches http://169.254.169.254/latest/meta-data/iam/security-credentials/ or equivalent GCP and Azure metadata routes, then reuses the returned role credentials against cloud APIs.

Possible investigation steps

  • Review url.original, url.query, http.request.method, http.response.status_code, and source.ip to identify the injected metadata target, affected route, and whether the server returned a successful response.
  • URL-decode the request repeatedly and inspect parameters for nested encodings, redirect chains, or wrapper URLs that hide the metadata destination.
  • Map the targeted endpoint to the backend handler and determine whether user-controlled input can influence outbound HTTP requests from the application.
  • Correlate with application, proxy, and outbound network logs around @timestamp for connections from the web server process to 169.254.169.254, 100.100.100.200, metadata.google.internal, or Azure metadata hosts.
  • Check cloud audit, sign-in, or token-issuance telemetry for use of instance role or managed identity credentials shortly after the request.
  • Pivot on source.ip and user_agent.original for related SSRF, scanning, or exploitation attempts across other web hosts.

False positive analysis

  • Security scanners, authorized penetration tests, or WAF validation may send metadata URLs in test payloads. Confirm the activity aligns with an approved assessment window and source before closing as benign.
  • Internal documentation, error pages, or security training content that echoes metadata URLs in query strings can trigger the rule without an exploitable SSRF path. Verify the application does not perform outbound fetches based on the matched input.

Response and remediation

  • Block the offending source.ip at the WAF or reverse proxy and add virtual patches to reject requests containing metadata addresses or credential paths.
  • If exploitation is confirmed, isolate the affected application host, preserve access logs, and rotate any cloud role or managed identity credentials that may have been exposed.
  • Patch or remediate the SSRF vulnerability by enforcing strict outbound allowlists, blocking link-local and metadata destinations, and validating user-supplied URLs.
  • Enforce IMDSv2, hop limits, and least-privilege instance roles to reduce impact if metadata access succeeds.

Rule query

edit
web where (
  url.original : (
    "*169.254.169.254*", "*169%2e254%2e169%2e254*", "*0xa9fea9fe*", "*0xa9.0xfe.0xa9.0xfe*",
    "*2852039166*", "*0251.0376.0251.0376*", "*::ffff:169.254.169.254*", "*::ffff:a9fe:a9fe*", "*fd00:ec2::254*",
    "*100.100.100.200*", "*169.254.170.2*", "*metadata.google.internal*", "*metadata.goog*", "*computeMetadata/v1*",
    "*meta-data/iam/security-credentials*", "*meta-data%2Fiam%2Fsecurity-credentials*",
    "*latest/meta-data*", "*latest/api/token*"
  )
  or
  url.query : (
    "*169.254.169.254*", "*169%2e254%2e169%2e254*", "*0xa9fea9fe*", "*0xa9.0xfe.0xa9.0xfe*",
    "*2852039166*", "*0251.0376.0251.0376*", "*::ffff:169.254.169.254*", "*::ffff:a9fe:a9fe*", "*fd00:ec2::254*",
    "*100.100.100.200*", "*169.254.170.2*", "*metadata.google.internal*", "*metadata.goog*", "*computeMetadata/v1*",
    "*meta-data/iam/security-credentials*", "*meta-data%2Fiam%2Fsecurity-credentials*",
    "*latest/meta-data*", "*latest/api/token*"
  )
)

Framework: MITRE ATT&CKTM

« Appendix n: Downloadable rule update v8.19.27 GenAI CLI Started with Unsafe Permission Bypass »