Webhook-url-http-3a-2f-2f169.254.169.254-2fmetadata-2fidentity-2foauth2-2ftoken Site

By [Your Name/Security Team]

Have you ever been triaging a log file or a webhook payload and seen something like this?

webhook-url-http-3A-2F-2F169.254.169.254-2Fmetadata-2Fidentity-2Foauth2-2Ftoken

At first glance, it looks like gibberish or a corrupted URL. But to a security engineer, this string is a five-alarm fire.

It doesn't look like a normal webhook (e.g., https://slack.com/...). Instead, it is an obfuscated attack trying to steal your cloud keys.

Let's break it down.

  • Check Headers: The request to IMDS requires the header Metadata: true. Check logs for this specific header in outgoing requests.
  • Rotate Credentials: If a successful request is suspected, immediately rotate the Managed Identity keys or certificates for the affected VM.

    • If you are developing a feature: Ensure that your application treats 169.254.169.254 as a protected internal IP. Do not forward responses from this endpoint to external users, as this would leak sensitive identity tokens.

    If you found this in logs:

    The specific URL http://169.254.169.254/metadata/identity/oauth2/token is a sensitive endpoint within the Azure Instance Metadata Service (IMDS). This service allows virtual machines (VMs) to retrieve information about themselves and, more critically, obtain OAuth 2.0 access tokens for managed identities without needing to store hardcoded credentials. The Role of 169.254.169.254 in Azure

    The IP address 169.254.169.254 is a non-routable link-local address used across major cloud providers (including AWS and GCP) to host metadata services. In Azure, this endpoint is strictly accessible only from within the running VM.

    The /metadata/identity/oauth2/token path specifically handles identity: What is this IP address: 169.254.169.254? - Server Fault By [Your Name/Security Team] Have you ever been

    If any system is tricked into making a webhook POST or GET request to this exact URL, and that system is running inside Azure with a Managed Identity enabled, the attacker would receive an access token for that identity. Depending on the role assigned, this could allow:

    This is a well-documented attack vector known as SSRF (Server-Side Request Forgery) leading to cloud metadata theft.

    If you see this string inside a configuration file or a variable named webhook-url, it usually implies one of two scenarios:

  • Verify whether the application follows redirects or leaks response bodies or headers.
  • Check if logs capture returned tokens or metadata.

    • If you need an OAuth2 token from Azure Managed Identity inside a VM or Azure Function, you do not use a webhook. You use the standard IMDS endpoint like this:

    # From inside an Azure VM with Managed Identity enabled
curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://management.azure.com/' -H 'Metadata: true'

    That returns a JSON response with an access_token. Check Headers: The request to IMDS requires the

    You never put this URL into a third-party webhook configuration field.

    If you see strings like this in your ingress logs (incoming webhook requests), you are likely being actively scanned or attacked.

    Here is how to lock it down:

    1. Patch SSRF Vulnerabilities

    2. Harden the Metadata Service

    3. Network Controls