IMDSPOOF is a cyber deception tool that spoofs an AWS IMDS service. One way that attackers are able to escalate privileges or move laterally in a cloud environment is by retrieving AWS Access keys from the IMDS service endpoint located at<user>. This tool spoofs that endpoint and redirects traffic sent to to a local webserver that serves fake data. This can be leveraged for highly tuned detections by inserting honey AWS tokens into the response of the spoofed IMDS response.

Who is this for?

This tool is intended to be used by blue teams on AWS instances that are NOT actively using the IMDS (version 1 or 2).

From an attacker’s perspective, they have no idea if the IMDS is being used on the EC2 instance they’re in. The goal of IMDSPOOF is to trick an attacker who lands in your cloud environment into thinking that they’re interacting with a legitimate IMDS service.

⚠️ Warning ⚠️

Once again, if the applications running on your EC2 instance ARE using the IMDS service, this tool WILL cause issues!

Try it out

To try out IMDSPOOF in a test environment, create an EC2 instance and make sure iptables is installed (yum install iptables-services if using amazon linux)

  • Compile and run IMDS.go (How To Compile Go Code)
  • To test out what the output looks like, run curl
  • You should see the following output:
  "Code": "Success",
  "Message": "The request was successfully processed.",
  "LastUpdated": "2023-11-22T03:33:51Z",
  "Type": "AWS-HMAC",
  "AccessKeyId": "InsertHoneyToken",
  "SecretAccessKey": "InsertHoneyToken",
  "Token": "HoneyToken",
  "Expiration": "2023-11-22T09:33:51Z"
  • To revert changes from the previous IP tables command run the following iptables -t nat -D OUTPUT -p tcp -d --dport 80 -j DNAT --to-destination


In order for this to be useful, you must change the variables at the top of the IMDS.go file to be something more real looking. I highly recommend placing honey tokens in the file. You can leave the token variable alone or change it to a custom one.

  • Change these variables at the top of IMDS.go to whatever you want returned from accessing
var accessKey string = "InsertHoneyToken"
var secretAccessKey string = "InsertHoneyToken"
var token string = "IQoJb3Jpz2cXpQRkpVX3Uf////////////xMdLZHNjb<snip>"

Getting HoneyTokens

The folks over at Thinkst Canary have a wonderful tool that allows you to easily generate AWS credentials that will generate an alert on usage.

  1. Visit CanaryTokens
  2. Select AWS Keys, enter an email for the alert to go to and a note for what the alert is for

Note down the honeytoken provided

aws_access_key_id = AKIA....
aws_secret_access_key = uZF0y/l5X....

Within the IMDS.go source code, replace the accessKey and secretAccessKey variable’s with the aws_access_key_id and aws_secret_access_key values given to you by CanaryTokens.

Compile IMDS.go. IMDS will now return the honey tokens when the IMDS is queried.

Wait for an attacker to attempt to use the credentials

Email alert from Canary Token

Run at startup

Running IMDS spoof at startup can be done easily by create a systemd service and enabling the service.

  • Create a file at service file sudo vim /etc/systemd/system/IMDS.service (You can name this something else more stealthy if you wish but the following systemctl commands expect the service to be named IMDS.service)
  • Add the following to the IMDS.service file just created
# Change this to something else if you wish

# After dependencies are available

# Type of service

# Command to execute the service program

# User to run the service as

# Restart if the service crashes

# Restart delay in seconds

# Enable the service at boot
  • Make sure the IMDS binary is in the /bin/ directory: sudo mv IMDS /bin/
  • Enable the service to start at boot sudo systemctl enable IMDS
  • Start the service now sudo systemctl start IMDS
  • Ensure everything is running correctly with sudo systemctl status IMDS

Does this work with SSRF?

Yes! Because of the way IMDSpoof manipulates the iptables on the ec2 instance, it doesn’t matter where the traffic is coming from. This means that in addition to this working via the curl utilitiy on the EC2 instance, IMDSpoof also works if an SSRF vulnerability is found through a web application hosted on the EC2 instance. Using the following vulnerable application from AlexanderHose’s blog on IMDS pentesting, we can exploit the SSRF vulnerability which will also return the fake credentials from IMDSpoof


  • To stop the systemd service: sudo systemctl stop IMDS
  • To stop the systemd service from running at startup: sudo systemctl disable IMDS
  • To revert changes IMDSPOOF makes to iptables, run the following command: iptables -t nat -D OUTPUT -p tcp -d --dport 80 -j DNAT --to-destination

Published by Tamil S

Tamil has a great interest in the fields of Cyber Security, OSINT, and CTF projects. Currently, he is deeply involved in researching and publishing various security tools with Kali Linux Tutorials, which is quite fascinating.

Leave a comment

Your email address will not be published. Required fields are marked *