Lion Cipher Lab
Enforce IMDSv2 to block metadata credential theft
- Cloud Security
- Intermediate
- ~45 min
- Free · no account required
Why it matters
Almost every serious AWS breach story has the same middle chapter: an attacker who could only make the server fetch a URL (an SSRF bug) pointed it at 169.254.169.254 and walked away with the instance's IAM role credentials. That is essentially the 2019 Capital One breach. The metadata service is a genuinely useful feature — it is how an instance learns its own role's temporary keys without you hard-coding secrets — but the original version (IMDSv1) hands those keys to anyone who can make a plain GET. IMDSv2 closes that door with a design that an SSRF attacker almost never satisfies. Knowing…
What you'll learn
- AWS EC2 instance metadata (IMDS)
- IMDSv1 vs IMDSv2
- defending against SSRF credential theft
- aws ec2 modify-instance-metadata-options
- cloud hardening judgment
Steps in this lab
- What IMDS is, and why it is the crown jewels
- Why IMDSv1 is a gift to SSRF
- Launch a throwaway box (and keep it free)
- See the theft: pull the credentials over IMDSv1
- Enforce IMDSv2 — require the token
- Prove it: the old GET now 401s, the token flow still works
- The hop limit is the control that matters for containers
- Make IMDSv2 the default for every new instance
- Judgment: what IMDSv2 does NOT do — and the teardown