Skip to main content

🗂️PortSwigger Lab Writeup: Brute-forcing a Stay-logged-in Cookie

PortSwigger lab description page for Authentication - Brute-forcing a stay-logged-in cookie

🎯 Objective​

The objective of this lab is to exploit an authentication weakness where the app incorrectly implements stay-logged-in feature which is vulnerable to brute-forcing. The goal is to bypass the authentication of carlos and log in to the account.

  • Lab URL: https://portswigger.net/web-security/authentication/other-mechanisms/lab-brute-forcing-a-stay-logged-in-cookie
  • Category: Authentication
  • Difficulty: Practitioner

🧪 Exploitation Steps​

🕵️Step 1: Observe the Website​

  • Firstly open the lab URL in your browser, and observe what it is about and how it works. Initial inspection of PortSwigger authentication lab with login interface
    Login form for PortSwigger brute-force cookie lab instance
  • At first glance, the website seems to be a blogging website with a login page. In the lab description, it is mentioned that we need to bruteforce the stay-logged-in cookie of user - carlos and log in to account.

📝Step 2: Try Stay-logged-in Feature​

  • Now we will first observe how stay-logged-in feature works by logging in as wiener:peter. PortSwigger lab login with stay-logged-in checkbox option
  • Now, we are being logged-in as wiener where we now have a feature to Update email.
  • Under the HTTP History in Burpsuite, see the /login request and its response. Burpsuite HTTP History showing login request with stay-logged-in cookie response
  • We notice a new cookie - stay-logged-in being set by the application which is used to persist the user session without again asking user credentials for login.
  • Now, In Decoder we Smart decode the stay-logged-in cookie value. Burpsuite Decoder tool decoding base64-encoded stay-logged-in cookie value
  • Hence, we find that the cookie value is base64 encoding of something linked to the user which is being used by app in the backend to know which user is logging again.
  • We now try finding out the actual value of a hash provided with username wiener:. I tried finding out the hash on some websites and got to know the actual value of it. Online MD5 hash lookup showing decoded username and password hash combination
  • Hence, the app sets the stay-logged-in cookie with base64(username:md5(password)) through which it detects in the backend which user is logging again.
  • Now we will bruteforce the stay-logged-in cookie by hashing different passwords with username - carlos and encoding it into base64.
  • First, log out of the test account - wiener
  • Under the HTTP History in Burpsuite, send the GET /my-account?id=wiener request to Intruder Tab through Ctrl + I Burpsuite sending HTTP request to Intruder Tab for brute-force attack configuration
  • Add the marker on the stay-logged-in cookie value and set the attack type to Sniper. Burpsuite Intruder Tab with payload markers placed on stay-logged-in cookie value
  • In the payloads section, set the payload type to Simple list and paste the possible passwords provided by PortSwigger - Candiate Passwords
  • In the payload processing section, add 3 rules :-
    • Hash: MD5
    • Add prefix: wiener:
    • Encode: Base64-encode Burpsuite Intruder payload processing rules for MD5 hashing and base64 encoding
  • In the Grep-Match section, add a simple string - Update email through which we will confirm if we have found the correct password or not.
    Burpsuite Grep-Match configuration with keyword detection for successful login
  • After all configurations, start the attack. Burpsuite Intruder attack results showing brute-force attempts on stay-logged-in cookies
  • In all the payloads, you will see a unique response with a 200 Success which means we have successfully cracked the password for carlos

🧑‍💼Step 4: Log in as carlos​

  • Now, Right-click on the 200 Success request in attack results and select Show response in browser. Copy the URL and load it in the browser. Burpsuite Intruder attack results showing successful authentication with 200 response code
  • And Finally, the Lab is solved.

🧠 Conclusion​

  • This lab showed how weak stay-logged-in cookie implementation can be exploited through brute-force attacks. By reverse-engineering the cookie format (base64-encoded MD5 hash), we systematically tested password combinations and successfully cracked the carlos account.
  • Such vulnerabilities have a critical impact — they enable complete account takeover.
  • Fix: use cryptographically secure session tokens, add rate-limiting / account lockouts, implement MFA, use secure cookie flags (HttpOnly, Secure, SameSite), and monitor for suspicious login patterns.