Search for a command to run...
Understand how EC2 Instance Metadata Service works, why IMDSv2 was introduced, and how it protects against SSRF attacks.
No comments yet. Be the first to comment.
What is Managed File Transfer (MFT)? Every organization exchanges files. Banks transfer transaction records, retailers exchange inventory updates, hospitals share medical data, and manufacturing compa
Steps to Install Jenkins: Clone the repo https://github.com/mkhansab/install-jenkins-docker and follow the 4 steps present at README.md at this repo Opening http://localhost:8080/ will ask for Admin
Imagine waking up in a world without the internet: No way to instantly message your friends or see what’s trending on social media. No ability to stream music, attend virtual classes, or play online
Overview O(n²) Time Complexity in all cases. Does less “Memory writes” when compared with other algorithms such as Quick sort, Merge sort, Insertion sort and Bubble sort. However, not an optimal algorithm in terms of “Memory writes”. There is othe...
The Instance Metadata Service (IMDS) simplifies credential management on EC2 instances by providing temporary, automatically rotated credentials. This eliminates the need to hardcode or manually distribute sensitive credentials to applications. IMDS runs locally on every EC2 instance and is accessible via the link-local IP address 169.254.169.254. It is also accessible over IPv6 for EC2 instances built on the Nitro System.
The EC2 IMDS provides important information about each individual EC2 instance. This includes several categories of information, such as AMI ID, hostname, associated security groups, instance id, local IPv4, etc
Here's an example of what IAM credentials might look like when retrieved from the EC2 instance metadata:
$ curl http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance
{
"Code" : "Success",
"LastUpdated" : "2026-04-17T18:20:09Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAZYX123M4ABCD567E",
"SecretAccessKey" : "exponentialTHlF2HmgNWsecretRNB2JXexample",
"Token" : "IQoJb3JpluX2VjEBIaC//////wEQABoMMTzMjUyIgw8uDv8CA7wN9Y0wBwqpwSlpN654xzHp7mGsZ9gz5J8uoo2xJqG3Bc7C/1TAFZyEiSz0cN...",
"Expiration" : "2026-04-18T00:45:39Z"
}
Note: The above curl request uses IMDSv1, as it does not include a session token in the request header.
An attacker exploiting a Server-Side Request Forgery (SSRF) vulnerability can trick an application into making requests to the instance metadata endpoint (169.254.169.254). If IMDSv1 is enabled, this can allow the attacker to retrieve IAM credentials associated with the instance.
Recently, Mandiant identified a threat actor using a known vulnerability, CVE-2021-21311, to steal IAM credentials from EC2 instances using the metadata service post-compromise. [1]
IMDSv2 mitigates this risk by requiring a session token in request headers, which typical SSRF vulnerabilities cannot easily provide.
With IMDSv2, access to instance metadata is protected using session-based authentication. A session begins when a client requests a temporary token using a PUT request. This token must then be included in the header of all subsequent requests to access metadata.
This approach ensures that only requests originating from within the instance can successfully retrieve metadata, significantly reducing the risk of SSRF-based attacks.
For example, this curl recipe retrieves a session token that’s valid for the full six hours (21600 seconds) and then uses that token to access the EC2 instance’s profile metadata:
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance
Output:
{
"Code" : "Success",
"LastUpdated" : "2026-04-17T18:42:35Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAZYX123M4ABCD567E",
"SecretAccessKey" : "exponentialC/wmIczuv7CGuOmm8iXPSCexample",
"Token" : "IQoJb3JpZ2luTEiSDBGAiEA9+W761PO/4SOcqcQ3Ty4PsnK4WsSzEZP6WgCIQD4+koxgcjdEPnL9whM0R0TyZdjhFPY5cfBirTBAjc//////////8rxcf1/OykGpvb46+VEIFL+5...",
"Expiration" : "2026-04-18T01:06:48Z"
}
Note: The above curl request uses IMDSv2, as it includes the session token in the request header.
There are two versions of the Instance Metadata Service: IMDSv1 and IMDSv2.
IMDSv1 is a simple request and response protocol. When you make a request to the IMDS from the EC2 instance, you receive the result of your request. There are no additional parameters to be passed. Because of this, IMDSv1 is a perfect candidate for SSRF attacks.
IMDSv2, on the other hand, is session-oriented. This means that, before making a request to the IMDS, you must first create a session token with a PUT request and pass it along in subsequent requests inside a header. This provides an additional security benefit, as an adversary is unlikely to be able to set a request header via SSRF. IMDSv2 can be enforced during instance creation by configuring the Instance Metadata Options to require session tokens.
While creating the instance, In the Advanced Details you can configure Instance metadata options
Two ways:
Console
In the EC2 console, navigate to:
EC2 → Instances → Select your instance id
HttpTokens = required → IMDSv2 is enforced (IMDSv1 disabled)HttpTokens = optional → Both IMDSv1 and IMDSv2 are allowed
CLI
When IMDS v2 is enabled
$ aws ec2 describe-instances --instance-ids i-0f581c1c90fc521c2 --query "Reservations[].Instances[].MetadataOptions.HttpTokens" --output table
-------------------
|DescribeInstances|
+-----------------+
| required |
+-----------------+
When IMDS v1 is enabled
$ aws ec2 describe-instances --instance-ids i-0ef0ce715ba1fc912 --query "Reservations[].Instances[].MetadataOptions.HttpTokens" --output table
-------------------
|DescribeInstances|
+-----------------+
| optional |
+-----------------+
Console
CLI
To transition from IMDSv1 to IMDSv2
$ aws ec2 modify-instance-metadata-options --instance-id i-0ef0ce715ba1fc912 --http-endpoint enabled --http-tokens required
{
"InstanceId": "i-0ef0ce715ba1fc912",
"InstanceMetadataOptions": {
"State": "pending",
"HttpTokens": "required",
"HttpPutResponseHopLimit": 2,
"HttpEndpoint": "enabled",
"HttpProtocolIpv6": "disabled",
"InstanceMetadataTags": "disabled"
}
}
To transition from IMDSv2 to IMDSv1
$ aws ec2 modify-instance-metadata-options --instance-id i-0ef0ce715ba1fc912 --http-endpoint enabled --http-tokens optional
HttpTokens = required → IMDSv2 is enforced (IMDSv1 disabled)HttpTokens = optional → Both IMDSv1 and IMDSv2 are allowed
To disable IMDS
$ aws ec2 modify-instance-metadata-options --instance-id i-0ef0ce715ba1fc912 --http-endpoint disabled
Enforcing IMDSv2 is a simple yet effective step to improve the security posture of your EC2 instances, especially in environments where applications may be exposed to untrusted input.
[1] Google Cloud – Cloud Metadata Abuse (UNC2903 Case Study)
https://cloud.google.com/blog/topics/threat-intelligence/cloud-metadata-abuse-unc2903/
[2] Amazon Web Services – Configure Instance Metadata Service
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html
[3] Amazon Web Services – IMDSv2 on Amazon Linux 2023
https://docs.aws.amazon.com/linux/al2023/ug/imdsv2.html
[4] Amazon Web Services Security Blog – SSRF and IMDS Protection
https://aws.amazon.com/blogs/security/defense-in-depth-open-firewalls-reverse-proxies-ssrf-vulnerabilities-ec2-instance-metadata-service/
[5] Datadog Security Labs – IMDS Misconfiguration Spotlight
https://securitylabs.datadoghq.com/articles/misconfiguration-spotlight-imds/