Cross Site Scripting (XSS) to Meterpreter

Hello Guys, Today we are going to learn about how we can exploit Cross Site Scripting (XSS) vulnerability and gain access over client’s system via meterpreter. Sounds weird?? Let’s have a look of it. Before proceeding, we need to learn following topics and tools.

What is Cross Site Scripting (XSS)?

Cross-site scripting (XSS) is a code injection attack that allows an attacker to execute malicious JavaScript in another user’s browser.

The attacker does not directly target his victim. Instead, he exploits a vulnerability in a website that the victim visits, in order to get the website to deliver the malicious JavaScript for him. To the victim’s browser, the malicious JavaScript appears to be a legitimate part of the website, and the website has thus acted as an unintentional accomplice to the attacker.

Types of XSS

While the goal of an XSS attack is always to execute malicious JavaScript in the victim’s browser, there are few fundamentally different ways of achieving that goal. XSS attacks are often divided into three types:

Stored XSS: The most damaging type of XSS is Stored (Persistent) XSS. Stored XSS attacks involves an attacker injecting a script (referred to as the payload) that is permanently stored (persisted) on the target application (for instance within a database). The classic example of stored XSS is a malicious script inserted by an attacker in a comment field on a blog or in a forum post.

When a victim navigates to the affected web page in a browser, the XSS payload will be served as part of the web page (just like a legitimate comment would). This means that victims will inadvertently end-up executing the malicious script once the page is viewed in a browser.

We will be exploiting Stored or persistent XSS for this demo but other two types can be exploited as well.

Reflected XSS: In Reflected XSS, the attacker’s payload script has to be part of the request which is sent to the web server and reflected back in such a way that the HTTP response includes the payload from the HTTP request. Using Phishing emails and other social engineering techniques, the attacker lures the victim to inadvertently make a request to the server which contains the XSS payload and ends-up executing the script that gets reflected and executed inside the browser. Since Reflected XSS isn’t a persistent attack, the attacker needs to deliver the payload to each victim – social networks are often conveniently used for the dissemination of Reflected XSS attacks.

DOM-based XSS: DOM-based XSS is an advanced type of XSS attack which is made possible when the web application’s client side scripts write user provided data to the Document Object Model (DOM). The data is subsequently read from the DOM by the web application and outputted to the browser. If the data is incorrectly handled, an attacker can inject a payload, which will be stored as part of the DOM and executed when the data is read back from the DOM.

Lab Setup:

  • Victim IP:
  • Victim OS: Windows XP
  • Victim Browser: Internet Explorer 6.0
  • Vulnerable Web App: Damn Vulnerable Web Application (DVWA)
  • Attacker IP:
  • Attacker OS: BackBox 4.7 [BeEf and Metasploit installed]


BeEF: Beef is the short form of Browser Exploitation Framework. This is the core of our exploit. BeEF can be used to “safely” exploit Web and browser-based vulnerabilities like cross-site scripting (XSS) using client-side attack vectors. If a user clicks on a link that BeEf put there, it will hook the user’s browser into the BeEF server. Then by using different module within BeEF we can perform various malicious activities like phising, stealing password, detecting browser components, make victim’s browser to download any malicious file etc.

Metasploit: Don’t know really how to describe metasploit, many security researchers, pen testers, many blogs, sites are there to make you understand what is metasploit and what are the functionality of metasploit. So I don’t want to describe metasploit within this small paragraph. In one words, without metasploit its very tough job as penetration tester. It is basically a exploitation framework but we can use metasploit for exploit development, Anti Virus evasion, Malicious file generator and many more. You should know metasploit very well if you want to be in cyber security field.

Damn Vulnerable Web Application (DVWA): This Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is damn vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, help web developers better understand the processes of securing web applications and aid teachers/students to teach/learn web application security in a class room environment. In our demo we use “Stored XSS” segment.


  • Attacker found a site that is having stored cross site scripting vulnerability.
  • Attacker configures BeEF in his system and generate a link that will hook victims browser whenever the link will be clicked.
  • Attacker injects the malicious javascript with that hookable link from BeEF into the site.
  • When victim opens the vulnerable page, the injected link will be triggered and victim’s browser will be hooked by BeEF.
  • Attacker chooses any browser dependent vulnerability within metasploit where a link will be generated and should be clicked by the user for successful exploitation.
  • Via BeEF module, Attacker will create an invisible iFrame with metasploit generated link and execute that within victim’s hooked browser wintout victim’s interaction.
  • if all things go right, we will have access of victim’s system.

NOTE: if you found it complicated then don’t worry. Follow the following steps.


  • DVWA has been installed within machine. From attacker machine it can be accessed via browser. If you installed DVWA for the first time, Default user and password is admin:password.
Fig: DVWA Login Page
  • BeEF has been already installed within BackBox . It resides within the following menu list.
Fig: BackBox Menu
  • While clicking BeEF, it has been started with command line.
Fig: BeEF in Command line


  • There is two options in BeEF. One is Online browser and other one is Offline Browser. Online Browser indicates those hooked browsers which are online and Offline indicates those hooked one which are not active. As our XSS payload has not been built yet so there is no browser listed over here.


  • Now its time to inject malicious javascript with BeEF payload (hook.js). For this, attacker needs to login to dvwa and select “Stored XSS” section. In this segment there is a length issue. Message length should be 50 chars long. So attacker needs to bypass this by changing the value of character length using “Inspect Element”. The xss payload :
Fig: Malicious Javascript Injection with BeEF Payload
  • Now we are done as an attacker. While victim open that page in internet explorer of his/her machine, victim’s hooked browser will be seen in BeEF “Online Browser”. Note that DVWA security should be “Low” at victim’s end.
Fig: Victim’s Browser Hooked
  • Whenever attacker found his target in “Online Browser”, his/her next move will be trigger any exploit which is browser dependent. Browser dependent exploits are those exploits where metasploit gives an URL and attackers have to convince the victim to open the URL in victim’s browser. Instead of convincing victim to open the Malicious URL, BeEF gives option to attacker to execute the URL as iframe. There are lots of exploits available within metasploit regarding browser. Among them Attacker chooses : exploit/windows/browser/ms10_002_aurora
Fig: Exploit started and link is given
Fig: Use Metasploit given link as iframe URL
  • There are lots of modules and submodules in BeEF. Among them “Create Invisible iframe” is the one. But my recommendation is to try different modules as well for testing. Each module has different functionalities. Try to explore them.
  • After successful execution of iframe with our metasploit generated payload, our metasploit terminal shows that attacker has penetrated into the victim’s system.
Fig: Meterpreter Shell



File upload vulnerability to Meterpreter

Vulnerability Name: Arbitrary file upload vulnerability in DVWA frame work in “low” section.

System Specification:

Victim – Windows XP SP2 [IP:]

Attacker – Kali Linux 2.0 [IP: PORT: 4444]

Success Criteria: Following two conditions are mandatory for exploiting file upload vulnerability –

  1. Attacker can upload any file (including .php, .asp, .aspx etc)
  2. Attacker can access uploaded file.

Tools used:

  1. Metasploit
  2. Msfvenom

Prerequisite Knowledge:

  1. What is web shell and how it works? [Please google it]
  2. Metasploit listener payload [exploit/multi/handler]


  1. Generate a web shell using msfvenom. msfvenom comes with metasploit framework.


The given command will generate an Raw script that will be named “prasenjitkantipaul.php” and when this php will be triggered it will sent back the connection to the attacker IP (i.e: in 4444 port)

  1. Location of malicious php


  1. Set DVWA security to “LOW” for this exploitation PoC.


  1. File Upload option


  1. File uploaded successfully without checking its file type.


  1. Set listener in attacker’s side to grab the connection what will be sent from victim.


  1. Accessing the file


  1. Let’s see, after trying to access our malicious shell what is happening to our listener.


We successfully compromise victim’s machine using our php web shell.


OS Command Injection to Meterpreter

Definition: Command injection is an attack in which the goal is execution of arbitrary commands on the host operating system via a vulnerable application. Command injection attacks are possible when an application passes unsafe user supplied data (forms, cookies, HTTP headers etc.) to a system shell. In this attack, the attacker-supplied operating system commands are usually executed with the privileges of the vulnerable application. Command injection attacks are possible largely due to insufficient input validation.


Victim Machine: Here victim is a server (WinXP SP2), hosting DVWA where OS Command Injection is there in “LOW” Security.

OS: Win XP SP2


Web APP: Damn Vulnerable Web Application (DVWA)


Attacker Machine:


OS: BackBox 4.7

Browser: Mozilla Firefox

Tool: Commix ([comm] and [i]njection e[x]ploiter)Tamper Data (Mozilla Add-ons)



  1. First of all we need to find the Injection Point and Cookie for DVWA Command Injection. Tamper Data has been used for this purpose.


  1. After finding Cookie and Injection point, We have to run commix from terminal.


  1. After successful injection by commix it will ask for pseudo shell and we will choose that to interact with the victim.


  1. Before proceed further, we need to create python based reverse tcp listener in metasploit.


  1. Let’s continue with commix’s option. We have to select python based reverse shell at the end and provide LHOST and LPORT.


  1. After selecting Python based Meterpreter payload a reverse tcp connection will be made with our metasploit listener.





SQL Injection to Meterpreter

Goal: By exploiting SQL Injection vulnerability fully compromise the victim server and get reverse shell (Meterpreter) using SQLMap.

Victim System: Damn Vulnerable Web App (DVWA) is installed in Windows XP for creating such virtual lab. IP:

Attacker System: Kali Linux 2.0 [Python 2.7, SQLMap and Metasploit installed by default]. IP:


SQLMap: sqlmap is a python based open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers. It comes with a powerful detection engine, many niche features for the ultimate penetration tester and a broad range of switches lasting from database fingerprinting, over data fetching from the database, to accessing the underlying file system and executing commands on the operating system via out-of-band connections. For any quires:

Meterpreter: Meterpreter is a payload (shell) of Metasploit. After successful exploitation Meterpreter shell will give you command line access to victims system. Using Meterpreter you can do whatever you want to do. For any quires:



FIG 1: Login to DVWA for SQLi [admin:password]


FIG 2: Set Security Update as “Low”


FIG 3: Setting Burp Proxy to analyze the response


FIG 4: Random check by using value “1”


FIG 5: Putting a Single Quote in GET parameter “ID” causing an DB error


FIG 6: Analyze the response and find the session cookie


FIG 7: SQLMap command to exploit SQLi and get the DB


FIG 8: Got the DBs | SQLi Proved


FIG 9: SQLMap Command to gain system level access


FIG 10: Some options that we have to choose


FIG 11: Successfully injecting payload to victim’s server


FIG 12: Bingoooo!!!! We pwned the system with Meterpreter