--- title: AWS Cloud Security Challenge: SSRF, IMDSv2, and Cloud... description: A walkthrough of a Fampay CTF cloud security challenge chaining an SSRF vulnerability in a webhook endpoint with AWS IMDSv2 to steal temporary IAM credentials... canonical: https://daily.dev/posts/aws-cloud-security-challenge-ssrf-imdsv2-and-cloud-takeover-eat7eojpd twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: AWS Cloud Security Challenge: SSRF, IMDSv2, and Cloud Takeover | daily.dev og:description: A walkthrough of a Fampay CTF cloud security challenge chaining an SSRF vulnerability in a webhook endpoint with AWS IMDSv2 to steal temporary IAM credentials... og:url: https://daily.dev/posts/aws-cloud-security-challenge-ssrf-imdsv2-and-cloud-takeover-eat7eojpd og:image: https://api.daily.dev/og/posts/EaT7eOJpD.png og:image:alt: AWS Cloud Security Challenge: SSRF, IMDSv2, and Cloud Takeover og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # AWS Cloud Security Challenge: SSRF, IMDSv2, and Cloud Takeover **[InfoSec Write-ups](https://daily.dev/sources/infosecwriteups)** · 7 min read · 0 upvotes · 0 comments ## Summary A walkthrough of a Fampay CTF cloud security challenge chaining an SSRF vulnerability in a webhook endpoint with AWS IMDSv2 to steal temporary IAM credentials from an EC2 instance. Since the S3 bucket restricted access to VPC-originating requests, the writeup shows how to bypass this by generating a presigned S3 URL with the stolen credentials and fetching it through the same SSRF endpoint, ultimately retrieving the CTF flag stored in the bucket. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### How can an SSRF vulnerability be used to steal AWS credentials when IMDSv2 is enabled? An attacker must first send a PUT request to the metadata service's token endpoint to obtain a session token, then include that token as the X-aws-ec2-metadata-token header on a GET request to /latest/meta-data/iam/security-credentials/. This defeats simple SSRF endpoints that only control the URL, since IMDSv2 requires custom PUT requests and headers before credentials can be retrieved. _daily.dev surfaces writeups like this for anyone hardening cloud apps against SSRF and metadata theft._ ### How do you access an S3 bucket that only allows requests from within a VPC when your stolen AWS credentials only work locally? Generate a presigned S3 URL using the stolen temporary credentials, then fetch that URL through the same SSRF endpoint that already proxies requests from inside the VPC. Because the presigned URL embeds temporary access permissions and the SSRF-triggered request originates from inside the VPC, it satisfies the bucket's aws:SourceVpc restriction and returns the object. _Developers securing S3 bucket policies can track SSRF-based bypass techniques like this on daily.dev._ ### What is the difference between IMDSv1 and IMDSv2 on AWS EC2 instances? IMDSv1 allows anyone to make a simple GET request to 169.254.169.254 and receive AWS credentials directly, making it vulnerable to any basic SSRF. IMDSv2 requires first requesting a session token via a PUT request, then supplying that token in a custom X-aws-ec2-metadata-token header on the metadata GET request, which blocks naive SSRF endpoints that only control the URL. _daily.dev helps engineers comparing IMDSv1 and IMDSv2 stay current on cloud credential protections._ ## Similar posts on daily.dev - [I Found a Critical SSRF Vulnerability That Could Have Exposed an Entire Server Here’s How](https://daily.dev/posts/i-found-a-critical-ssrf-vulnerability-that-could-have-exposed-an-entire-server-here-s-how-xgeshq0eo) · InfoSec Write-ups · 0 upvotes · 0 comments - [Fourth challenge on DevOpsLedger](https://daily.dev/posts/fourth-challenge-on-devopsledger-l6xk0k65f) · Medium · 0 upvotes · 0 comments - [The HTTP 303 SSRF Hack : From Python HTTP Client Defaults to AWS Credential Exfiltration. A Deep Dive Into Escalating a Blind SSRF to Full Read](https://daily.dev/posts/the-http-303-ssrf-hack-from-python-http-client-defaults-to-aws-credential-exfiltration-a-deep-div-m0w7evcrl) · InfoSec Write-ups · 0 upvotes · 1 comments - [Cracks in the Bedrock: Escaping the AWS AgentCore Sandbox](https://daily.dev/posts/cracks-in-the-bedrock-escaping-the-aws-agentcore-sandbox-ojef8o8am) · Unit 42 · 0 upvotes · 0 comments - [From CI/CD to Cloud Data: How Shai Hulud Persistence Leads to Redshift Breach](https://daily.dev/posts/from-ci-cd-to-cloud-data-how-shai-hulud-persistence-leads-to-redshift-breach-jmqfu4sid) · FortiGuard Threat Research · 1 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#aws](https://daily.dev/tags/aws) [View this post on daily.dev](https://daily.dev/posts/aws-cloud-security-challenge-ssrf-imdsv2-and-cloud-takeover-eat7eojpd) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"AWS Cloud Security Challenge: SSRF, IMDSv2, and Cloud Takeover","url":"https://daily.dev/posts/aws-cloud-security-challenge-ssrf-imdsv2-and-cloud-takeover-eat7eojpd","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/aws-cloud-security-challenge-ssrf-imdsv2-and-cloud-takeover-eat7eojpd"},"datePublished":"2026-08-14T17:31:08.422Z","dateModified":"2026-09-14T09:09:12.641Z","description":"A walkthrough of a Fampay CTF cloud security challenge chaining an SSRF vulnerability in a webhook endpoint with AWS IMDSv2 to steal temporary IAM credentials...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3c791b5b336ce99ee57ade0831094fd4?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/3c791b5b336ce99ee57ade0831094fd4?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"InfoSec Write-ups","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"InfoSec Write-ups","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/f0dc21b5bbfd46fda36f7b4b53dd1705","url":"https://daily.dev/sources/infosecwriteups"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/aws-cloud-security-challenge-ssrf-imdsv2-and-cloud-takeover-eat7eojpd","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,aws","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"InfoSec Write-ups","item":"https://daily.dev/sources/infosecwriteups"},{"@type":"ListItem","position":3,"name":"AWS Cloud Security Challenge: SSRF, IMDSv2, and Cloud Takeover"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/aws-cloud-security-challenge-ssrf-imdsv2-and-cloud-takeover-eat7eojpd#faq","mainEntity":[{"@type":"Question","name":"How can an SSRF vulnerability be used to steal AWS credentials when IMDSv2 is enabled?","acceptedAnswer":{"@type":"Answer","text":"An attacker must first send a PUT request to the metadata service's token endpoint to obtain a session token, then include that token as the X-aws-ec2-metadata-token header on a GET request to /latest/meta-data/iam/security-credentials/. This defeats simple SSRF endpoints that only control the URL, since IMDSv2 requires custom PUT requests and headers before credentials can be retrieved. daily.dev surfaces writeups like this for anyone hardening cloud apps against SSRF and metadata theft."}},{"@type":"Question","name":"How do you access an S3 bucket that only allows requests from within a VPC when your stolen AWS credentials only work locally?","acceptedAnswer":{"@type":"Answer","text":"Generate a presigned S3 URL using the stolen temporary credentials, then fetch that URL through the same SSRF endpoint that already proxies requests from inside the VPC. Because the presigned URL embeds temporary access permissions and the SSRF-triggered request originates from inside the VPC, it satisfies the bucket's aws:SourceVpc restriction and returns the object. Developers securing S3 bucket policies can track SSRF-based bypass techniques like this on daily.dev."}},{"@type":"Question","name":"What is the difference between IMDSv1 and IMDSv2 on AWS EC2 instances?","acceptedAnswer":{"@type":"Answer","text":"IMDSv1 allows anyone to make a simple GET request to 169.254.169.254 and receive AWS credentials directly, making it vulnerable to any basic SSRF. IMDSv2 requires first requesting a session token via a PUT request, then supplying that token in a custom X-aws-ec2-metadata-token header on the metadata GET request, which blocks naive SSRF endpoints that only control the URL. daily.dev helps engineers comparing IMDSv1 and IMDSv2 stay current on cloud credential protections."}}]} ```