> 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-6/credential-recovery/separate-service/trick-0130.md).

# Email To Password Lookup Service

***

Discover separate services running on the target network using standard techniques like reviewing host configuration files or performing port scans. For instance, an entry in `/etc/hosts` pointing to a specific hostname (like `[REDACTED].grep.thm`) accessible on a non-standard port (e.g., `51337`) indicates such a service. If you have acquired user identifiers like email addresses (e.g., from a database dump), try entering these into the login or password recovery features of the discovered separate service. The application's response might directly reveal the associated password or leak information facilitating further attack. Attackers can often determine if a username or email exists by observing the application's response when initiating a password reset. A response might inadvertently include sensitive details, such as a portion of the reset token, hints about security questions, or even temporary passwords, especially in older or misconfigured systems. Different error messages or timing differences between requests for known versus unknown users can also reveal user existence.

For example, submitting a request like:

```http
POST /forgot_password HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded

email=known_user@example.com
```

might yield a different response structure or status code compared to submitting an unknown email, allowing for user enumeration. Observing the content of the response for valid users is crucial, as it might contain unintended data leakage.

Testing for account enumeration can be performed by observing variations in the response body, HTTP status code, or response timing when requesting a password reset for both existing and non-existing users.

Consider these examples:

Request for a known user:

```http
POST /forgotpassword HTTP/1.1
Host: example.com
...
username=knownuser
```

A successful response for a known user might look like this:

```http
HTTP/1.1 200 OK
...
A password reset link has been sent to your email address.
```

Now, consider a request for a user that does not exist:

```http
POST /forgotpassword HTTP/1.1
Host: example.com
...
username=unknownuser
```

The response for an unknown user might differ significantly from the known user response. It could be:

```http
HTTP/1.1 404 Not Found
...
User not found.
```

Alternatively, the status code might be the same (e.g., 200 OK), but the response body content varies:

```http
HTTP/1.1 200 OK
...
User not found.
```

Or, in an attempt to prevent enumeration, the application might return a generic message for both cases, but subtle differences might still exist:

```http
HTTP/1.1 200 OK
...
If a user with that username exists, a password reset link has been sent to their email address.
```

Even when response bodies and status codes are identical, differences in the time taken to process the request can indicate whether a user exists. For instance, processing a request for a known user might take longer due to database lookups or email sending operations compared to a request for an unknown user which might fail earlier in the process. Measuring these timing differences can be a method for username enumeration.