IMDS impersonation
Bulletin ID: AWS-2025-021
Scope: AWS
Content Type: Important (requires attention)
Publication Date: 2025/10/08 11:15 AM PDT
Description:
AWS is aware of a potential Instance Metadata Service (IMDS) impersonation issue that would lead to customers interacting with unexpected AWS accounts. IMDS, when running on an EC2 instance, runs on a loopback network interface and vends Instance Metadata Credentials, which customers use to interact with AWS Services. These network calls never leave the EC2 instance, and customers can trust that the IMDS network interface is within the AWS data perimeter.
When using AWS tools (like the AWS CLI/SDK or SSM Agent) from non-EC2 compute nodes, there is a potential for a third party-controlled IMDS to serve unexpected AWS credentials. This requires the compute node to be running on a network where the third party has a privileged network position. AWS recommends that when using AWS Tools outside of the AWS data perimeter, customers follow the installation and configuration guides (AWS CLI/SDK or SSM Agent) to ensure this issue is mitigated. We also recommend that you monitor for IMDS endpoints that may be running in your on-prem environment to proactively prevent such impersonation issues from a third party.
Affected versions: IMDSv1 and IMDSv2
Resolution:
AWS recommends that when using AWS Tools outside of the AWS data perimeter, customers follow the installation and configuration guides (AWS CLI/SDK or SSM Agent) to ensure this issue is mitigated.
Monitoring:
Organizations should monitor for unexpected AWS Instance Metadata Service (IMDS) traffic in on-premises environments, as this indicates potential misconfigurations, cloud applications running locally, or security concerns.
Monitor for connections to 169.254.169.254 (AWS IPv4 link-local metadata endpoint) and fd00:ec2::254 (AWS IPv6 metadata endpoint), HTTP requests to AWS-specific paths like /latest/meta-data or /latest/api/token, and the presence of AWS metadata headers such as X-aws-ec2-metadata-token. These endpoints should never appear in purely on-premises networks since they are reserved for AWS EC2 instances to retrieve configuration data, IAM credentials, and instance information.
Customers are being offered this detection guidance overview in SIGMA, which is a generic rule format that translates to specific SIEM query languages, enabling universal detection deployment. To build this rule, define logsource: category: network to correlate diverse network telemetry, then create multiple selection blocks. ip_aws_dst: dst_ip: 169.254.169.254 captures direct connections, while http_url_paths: url|contains: ['/latest/meta-data', '/latest/api/token'] detects metadata requests using SIGMA’s list syntax. Use field variants like destination.ip, c-ip, and request_url|contains within separate selection blocks to accommodate different log schemas across vendors. Implement the condition logic to match all the selection blocks by their given prefixes (e.g., condition: 1 of ip_* or 1 of http_* where the wildcard * matches all selection blocks starting with those prefixes). The detection can be made precise by using SIGMA’s contains modifier: request_headers|contains: 'X-aws-ec2-metadata-token' for IMDSv2 token requests. When deployed, SIGMA converts this universal syntax into your SIEM’s native query languages—Splunk’s SPL, QRadar’s AQL, Sentinel’s KQL or Elastic’s KQL—maintaining the same detection logic while adapting to platform-specific field names and operators.
To enhance the rule’s fidelity, customers can consider triggering the alert only for the on-premises network traffic by applying suppression logic based on source subnets or VLANs.
Please email aws-security@amazon.com with any security questions or concerns.