> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-17/ssrf/web-ssrf-enumeration.md).

# Enumeration

## SSRF Localhost Port Scan

Use an SSRF vulnerability to enumerate open ports on the localhost interface (`127.0.0.1`). By controlling a URL parameter that the server fetches internally, you can point it back to the server's local addresses and iterate through ports. The server's response (or lack thereof, or different error messages/sizes) will indicate which ports are open.

Tools like `wfuzz` can automate this process. Configure `wfuzz` to iterate through a wordlist of ports, submitting each port number in the SSRF vulnerable parameter pointing to `127.0.0.1`.

```bash
wfuzz -u 'http://beta.creative.thm/' -X POST -d 'url=http://127.0.0.1:FUZZ/' -w /path/to/port/wordlist --hh <size_to_hide>
```

In this example:

* `-u 'http://beta.creative.thm/'` is the target URL where the SSRF vulnerability exists.
* `-X POST -d 'url=http://127.0.0.1:FUZZ/'` defines the POST request body and the vulnerable `url` parameter, where `FUZZ` is the placeholder for the iterated port numbers.
* `-w /path/to/port/wordlist` specifies a wordlist containing common or target-specific port numbers.
* `--hh <size_to_hide>` is crucial for filtering. You need to identify a response size that corresponds to closed/filtered ports and hide those results to highlight responses from open ports. The value `13` was used in the source example, indicating responses of that size were likely non-indicators of an open port.

Another approach to discovering local ports by fuzzing can be employed, for example, if the SSRF vulnerability is present in a GET parameter. After confirming an SSRF vulnerability, you can scan for ports that are open locally, which could lead to further enumeration and possible sensitive data exposure. `wfuzz` can be used for this:

```bash
wfuzz -c -w /path/ports.txt -u 'http://vulnerable.host/url.php?path=http://localhost:FUZZ'
```

In this command, `-c` enables colored output, `/path/ports.txt` is the wordlist of ports, and the `FUZZ` keyword is placed within the `path` GET parameter targeting `http://localhost:FUZZ`. Successful requests, often indicated by a `200` HTTP status code and distinct variations in response lines, words, or characters, can reveal open ports. The output might look similar to this:

```
=====================================================================  
ID      Response  Lines  Word    Chars    Payload  
=====================================================================  
  
000000022:  200    4 L   4 W    62 Ch    "22"  
000000090:  200    11 L   18 W    156 Ch   "90"  
000000110:  200    17 L   24 W    187 Ch   "110"  
000000200:  200    3 L   2 W    22 Ch    "200"  
000000320:  200    26 L   109 W   1232 Ch   "320"  
000000888:  200    78 L   265 W   3955 Ch   "888"  
000003306:  200    2 L   6 W    123 Ch   "3306"  
000008080:  200    2 L   47 W    994 Ch   "8080"
```

When attempting to target `127.0.0.1` or `localhost`, some applications block input containing such hostnames or sensitive URLs like `/admin`. In this situation, you can often circumvent the filter using the following techniques:

* Use an alternative IP representation of `127.0.0.1`, such as `2130706433` (decimal encoding), `017700000001` (octal encoding), or `127.1`.
* Register your own domain name that resolves to `127.0.0.1`. You can use `spoofed.burpcollaborator.net` for this purpose if it's configured to resolve to `127.0.0.1`, or any domain you control that points to this IP.
* Obfuscate blocked strings using URL encoding (e.g., for `127.0.0.1`, use `%31%32%37%2E%30%2E%30%2E%31`) or case variation (e.g., `LoCaLhOsT`), assuming the server-side parser normalizes these.
* Provide a URL that you control, which then redirects to the target URL (e.g., your controlled URL `http://attacker.com/redirect` issues a 302 redirect to `http://127.0.0.1:FUZZ`).