[This post](https://portswigger.net/web-security/authentication/other-mechanisms/lab-brute-forcing-a-stay-logged-in-cookie) explores a vulnerable implementation of persistent login ("stay logged in") functionality where user authentication is handled via a **predictable, brute-forceable cookie**. By reversing the logic and exploiting weak hashing, we achieve full access to another user's account without needing their session or password. #### Step 1: Identify the Cookie Structure Log into your own account (`wiener:peter`) using the "Stay logged in" checkbox. Inspect the `stay-logged-in` cookie in Burp Suite. It appears Base64-encoded. Decode it: ``` wiener:51dc30ddc473d43a6011e9ebba6ca770 ``` ![[CleanShot 2025-07-14 at 22.49.29.png]] Analysis: - Username in plaintext - Followed by a 32-character hex string (likely MD5 hash) - Conclusion: The cookie format is: ``` base64(username + ':' + md5(password)) ``` Confirm this by manually computing: ```bash echo -n "peter" | md5sum ``` → Compare the hash with the one in the cookie. ![[CleanShot 2025-07-14 at 22.50.48.png]] --- #### Step 2: Validate the Attack Path Send a `GET /my-account?id=wiener` request and ensure the `stay-logged-in` cookie is present. In Burp Intruder: - Highlight the cookie value - Add your password (`peter`) as the payload - Set up **Payload Processing Rules**: 1. **Hash**: MD5 2. **Add prefix**: `wiener:` 3. **Encode**: Base64 Confirm that this generates a valid cookie and the response contains the phrase `Update email` — indicating successful authentication. Set a Grep Match rule in Burp to match on `Update email`. --- #### Step 3: Launch the Brute Force Against Carlos Modify the Intruder setup: - Payload: Use the **provided list of candidate passwords** - Change URL: From `/my-account?id=wiener` → `/my-account?id=carlos` - Update Payload Processing: 1. **Hash**: MD5 2. **Add prefix**: `carlos:` 3. **Encode**: Base64 ![[CleanShot 2025-07-14 at 22.59.52.png]] ![[CleanShot 2025-07-14 at 23.01.06.png]]