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.
Table of contents
About The ChallengeLet’s Start Hacking nowGet Arun balaji ’s stories in your inboxChaining the Two: What’s NextStealing AWS CredentialsFinal Step: Presigned URL + SSRFQuestions this post answers
How do I steal AWS credentials via SSRF when the server uses IMDSv2 instead of IMDSv1?
With IMDSv2, a simple GET request to the metadata endpoint is not enough because AWS requires a session token first. Send a PUT request through the SSRF endpoint to http://169.254.169.254/latest/api/token with header X-aws-ec2-metadata-token-ttl-seconds set to a value like 21600, then use the returned token as the X-aws-ec2-metadata-token header on a GET request to /latest/meta-data/iam/security-credentials/<role-name> to retrieve the access key, secret key, and session token. daily.dev surfaces writeups like this for teams hardening SSRF defenses and IMDS configurations.
If stolen AWS credentials work but S3 access still returns Access Denied, how can I bypass a VPC-restricted bucket policy?
When an S3 bucket policy restricts access to requests originating from inside the VPC, credentials used directly from an external AWS CLI will fail with AccessDenied even if they are valid. The workaround is to generate a presigned S3 URL using the stolen credentials, then fetch that presigned URL through the internal SSRF endpoint so the request originates from inside the VPC and satisfies the bucket's network condition. security engineers researching VPC-scoped bucket policies can find similar exploitation chains through daily.dev.
What is the difference between IMDSv1 and IMDSv2 for AWS EC2 instance metadata security?
IMDSv1 allows any simple GET request to 169.254.169.254 to return AWS credentials directly, meaning basic SSRF vulnerabilities that only control the URL can steal credentials. IMDSv2 requires first requesting a session token via a PUT request, then supplying that token as a custom header, X-aws-ec2-metadata-token, on the metadata GET request, which defeats naive SSRF endpoints that cannot control HTTP method or headers. developers securing EC2 workloads track IMDS hardening details like these on daily.dev.