What is Shell of the Future?

Shell of the Future is a Reverse Web Shell handler. It can be used to hijack sessions where JavaScript can be injected using Cross-site Scripting or through the browser's address bar. It makes use of HTML5's Cross Origin Requests and can bypass anti-session hijacking measures like Http-Only cookies and IP address-Session ID binding.

It has been designed to be used as a POC to demonstrate the impact of XSS flaws in a Penetration test with the same ease as getting an alert box to pop-up.

Possible Uses:

Shell of the Future can be used for the following purposes:

  • Demonstrate the severity of XSS and JavaScript injection attacks
  • Create POCs for XSS vulnerabilities in Penetration test reports
  • Run automated scans on internal websites from outside by tunneling the traffic through an internal browser.
  • .NET framework 2.0 and above
  • If the proxy or the server component must listen on a port less than 1024 then it must be run with administrator privileges.

Shell of the Future has two main components:

  • Proxy Server:
    The Pentester's browser must be configured to use this as the proxy server. The proxy server listens on port 1337 by default. All requests sent by the Pentester's browser are captured by this proxy which converts them in to JSON messages and sends them to the Shell of the Future web server. It regularly polls the web server to test if responses to those requests are available. If a response is available the proxy processes the response body to make changes like adding a banner etc(if enabled by the user) and sends the response to the pentester's browser.

    If the browser is requesting static files like css or jpg files then these are directly fetched from the server. This feature is also configurable and can be turned off if required.

  • Web Server:
    The web server gets all the requests from the proxy and stores it in a temporary database. When the victim polls the web server, the requests are sent to it. The victim fetches the response for these requests from the server and sends them back to the server which is again stored in the database. When the proxy polls the server looking for responses, this response is sent to it.

    The web server also servers the JavaScript exploits to the victim. The default exploits are e1.js and e2.js and the server dynamically adds its IP address to the exploits when serving them to help them communicate back to it. The victim constantly polls the server to fetch new requests.

Shell of the Future comes with two default exploits:

  • e1.js
    This exploit is the simpler of the two. Once injected in to the browser it polls the Shell of the Future server constantly checking for any new requests that must be fetched. If any requests are available these are sent in JSON format. The exploit fetches individual requests from the JSON object, fetches each of them from the server, encodes the response in hex and then sends it over to the Shell of the Future server.

  • e2.js
    This exploit performs all the functions that e1.js does and in addition has an added feature to increase the lifetime of the injected script. It adds an invisible link to the page and adds a 'onmousemove' event handler so that the link is always under the cursor. When the victim clicks anywhere on the page, this link gets clicks and it opens the same site in a new tab.

    The transition is hardly noticeable and the victim would continue browsing the site in the new tab while the injected exploit would remain active in the other tab.

These exploits have some other special features as well. The exploit needs to know the IP address of the Shell of the Future server inorder to communicate with it. This IP address can differ from user to user and having a hardcoded IP address in the exploit would require the user to change it before running the tool. To avoid this inconvenience, the IP address of the server is added dynamically to these exploits.

The variable 'sotf_server_url' is added by the server when serving e1.js or e2.js. The hostname of the request goes in as the server url. If the file is fetched with the request '' then the value of this variable is ''

Apart from e1.js and e2.js, two more files get similar treatment, e3.js and e4.js. If you want to create your own exploit and want the server url to be added dynamically then save your exploit as either e3.js or e4.js.

Every time the tool starts it checks for updated versions of Shell of the Future and newer versions of e1.js and e2.js. If the Attack and Defense Labs server contains newer versions of these exploits then its overwrites the currnet ones. If you wish to make changes to the default exploits then save them as e3.js or e4.js. Otherwise they can be overwritten.


Shell of the Future is designed to run and give the optimal results in its default configuration. However it does provide the user with ability to tweak it considerably. Let us look at some of the configuration options

Operating Mode:
  • Server + Proxy (default)
    Runs both the web and proxy server. Ideal for internal demos but cannot be used to connect victims from internet unless the system running Shell of the Future has a public IP address.

  • Proxy Only
    Runs only the proxy server. Requires the server component to be run seperately on a web server with a public IP address to enable victims to connect over the internet.

    Note: Currently a separate server component is not available. However it would be made available shortly.
Server settings:
  • Loopback only:
    If enabled the server only accepts connections from the local system. If both the victim and the hijacker are on the same system then this setting can be applied.

  • Server IP and port:
    When operating in the 'Server+Proxy' mode the port number on which the server should listen can be configured here, its 80 by default. If a port less than 1024 is selected then the user requires administrative access.
    When operating in the 'Proxy Only' mode the IP address and the port number of the external server should be provided.
Proxy settings:
  • Loopback only:
    If enabled the proxy server only accepts connections from the local system.

  • Proxy port:
    The port number on which the proxy server should listen can be configured here, its 1337 by default. If a port less than 1024 is selected then the user requires administrative access.
Fetch Content Directly:

Static files can be fetched directly form the actual server rather fetching them through the victim. This saves bandwidth and makes the hijacked session faster. The type of files that can be fetched directly can be configured. If all files must pass through the victim then uncheck this feature.

  • Fetch by file extensions:
    Files can be selected based on extensions. The files with the selected extensions will always be fetched directly.

  • Fetch by Regex:
    A regex can be assigned to denote the files that must be fetched directly. Files for which the URL matches the regex will be fetched directly.

  • Upstream proxy:
    When fetching contents directly if a any internal corporate proxy server must be used then it can be configured here.
Response Rewriting:

The proxy does some processing on the response form the victim like changing the HTTPS links, adding a banner etc. If these changes are not required then this feature can be disabled.

  • Handling HTTPS links:
    Shell of the Future does not listen for SSL connections but it can still handle HTTPS websites. It does this magic by replacing all 'https://' links in to 'http://uptossl.' links. When the proxy sees 'http://uptossl.' in the request URL then it automatically converts it in to 'https://'.

  • Customized Banner:
    This is byfar the most useful feature in demos and POCs. It displays a banner anywhere on the screen of the hijacked session. The position, color, size, text and other properties of the banner can be customized easily. The banner is added as a <div> tag before the body tag of the page. If any changes are made to the banner settings when the tool is running then 'Apply Changes' must be clicked for the changes to take effect.

  • Match and Replace:
    This feature can be used to match and replace any section of the response body. Regex can also be used to perform a match.
  1. Does Shell of the Future work on Linux?
    Not properly. With a few changes however it should be able to run on Mono. Since the source is available, if you have experience developing for Mono then you could port it very easily.

  2. Why do I see strange characters in the hijacked session?
    That is because of encoding issues. The victim fetches the pages using the responseText property of the XMLHttpRequest object and then it is hex encoded before being sent it to the server. Some characters are corrupted either because the reponseText property does not give them in the right format or because of the hex encoding. Sometimes when performing 'response rewriting' in the proxy the wrong character encoding might be used to handle the response.

  3. Can I fetch binary content through the victim?
    No. The responseText property does not handle binary content properly. You could however use the responseBody property on IE and handle binary content, that would require customizing the exploit.

  4. Why is the hijacked session slow?
    Because it is going through three routing points, the proxy, the server and the victim's browser. Having said that, for most websites the speed is good enough in my opinion. Even content heavy sites like Yahoo load pretty quickly.

  5. A particular site is extremly slow, why?
    Sometimes when a request for a binary file goes through the victim it slows down the entire session. Most of the times stopping and reloading the page would solve the issue. If there is a particular file that is clogging up the proxy then write a regex to fetch this file directly.

  6. Can I browser multiple sessions at one time?
    Yes you can. As many as you want.

  7. The banner does not show up on sometimes, why?
    The banner feature is actually a match and replace feature. Its looks for '<body' and replaces it with '<div>-banner text</div><body'. If this particular site does not have a body tag(which is unusual) then the banner is not added.

  8. I made some changes to the banner setting but the banner is still the same, why?
    To view the new banner you must either refresh the page or click on a new link, the changes are applied on the new page. If you made changes when Shell of the Future is already running then you must click on 'Apply Changes' for the changes to take effect.

  9. Can this tool be abused by the bad guys?
    Theoretically yes, but practically the bad guys wouldn't care. They aren't interested in browsing the victim's session from their browser. They prefer using light-weight 'fire and forget' type exploits. Unless the attacker is trying to impress a girl with his exploitation skills, Shell of the Future is not of much use to them.

  10. Can I use Shell of the Future to impress girls?
    Absolutely, it has been proven to have hypnotic powers much stronger than AXE and OldSpice.

  11. How does the update feature work?
    Every time you run Shell of the Future, a request is sent to ‘https://www.andlabs.org/tools/sotf/version.txt‘, to check for newer versions of Shell of the Future and the JavaScript exploits e1.js and e2.js. If a new version of the tool is found then you are shown a message box. If the JavaScript exploits have a new version then its updated silently.

  12. Who do I contact if have (questions | ideas | suggestions | comments | critisicm | feedback)?
    My email ID is here. You can also get me on Twitter.