> For the complete documentation index, see [llms.txt](https://ganesha-hk.gitbook.io/cybersecurity-writeups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-authentication-labs/lab-10.md).

# lab-10

## Brute-Forcing a Stay-Logged-In Cookie

**Difficulty:** Practitioner

### Lab Description

This lab allows users to stay logged in after closing their browser. The persistent cookie used for this is vulnerable to brute-forcing because its value is constructed from predictable components.

**Your credentials:** `wiener:peter`\
**Victim's username:** `carlos`\
**Wordlist:** [Candidate passwords](https://portswigger.net/web-security/authentication/auth-lab-passwords)

**Objective:** Brute-force Carlos's stay-logged-in cookie and access their account page.

### Solution

**Step 1 — Analyse the stay-logged-in cookie**

Log in as `wiener` with **Stay logged in** checked. Capture the request in Burp. In the proxy history, find the `GET /my-account` request — it carries both a `session` cookie and a `stay-logged-in` cookie.

Copy the `stay-logged-in` value and decode it in Burp's **Decoder**. It decodes from Base64 to a string in the format:

```
wiener:<hash>
```

Run the hash portion through a hash identifier — it's an **MD5** hash. MD5 of `wiener`'s known password (`peter`) confirms the format:

```
stay-logged-in = base64( username + ":" + md5(password) )
```

**Step 2 — Confirm the session cookie is not required**

In Repeater, remove the `session` cookie from the `GET /my-account` request and send it with only the `stay-logged-in` cookie. The server still grants access — the session cookie is not validated for authentication when a valid `stay-logged-in` cookie is present.

**Step 3 — Set up Intruder with payload processing**

Send the `GET /my-account` request to Intruder (with the session cookie removed). Set the `stay-logged-in` cookie value as the payload position.

Load the candidate password wordlist. Then configure **Payload Processing** rules to transform each password into the correct cookie format before sending. Add the following rules in this exact order:

1. **Hash → MD5** — hashes the password
2. **Add prefix → `carlos:`** — prepends the username and colon
3. **Encode → Base64** — encodes the full string

Each password in the wordlist will be automatically processed through this pipeline, producing a valid `stay-logged-in` cookie value for `carlos` for each candidate password.

**Step 4 — Run the attack**

Start the attack. Sort the results by status code — a `200` response (rather than a redirect to login) indicates a successful match. Right-click that response and open it in the browser to access Carlos's account.

### Conclusion

The `stay-logged-in` cookie was constructed from a predictable formula — a Base64-encoded string of the username and an MD5-hashed password. MD5 is fast to compute and unsuitable for password hashing, making brute-forcing the entire password list computationally trivial. Burp's payload processing pipeline automated the full encoding chain for every attempt.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://ganesha-hk.gitbook.io/cybersecurity-writeups/port-swigger-authentication-labs/lab-10.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.