Browser Exploitation Expanded – NoScript, Sandboxie

So I got a message asking me to expand on my previous post on browser exploitation. The user wanted to know about how security software such as NoScript and Sandboxie would deal with a browser exploit. I’m going to just go through each one on their own and explain what an attacker would be dealing with in each case.

The scenario is that you’re running Firefox with NoScript and Firefox with Sandboxie (separately, for simplicity) and you’ve visited a malicious website where the attacker controls the entire page of content. The attackers goal is to exploit the browser and monetize the system.


NoScript works in a few ways. For the purposes of this post I’ll be focusing on the scripting whitelist aspect of it, as things like HSTS/XSS won’t make a difference in our scenario.

As an attacker I’m incredibly limited by NoScript. Most exploits are going to be in the Javascript renderer or through some plugin. With NoScript I have none of that attack surface. Instead I have to resort to exploiting some other component, like a font renderer, or find a flaw in NoScript that will allow a bypass.

This limitation is significant. I can’t even start my attack unless it’s a very specific (and less common) type. So NoScript is incredibly effective here.

If, however, I trick the user into whitelisting the site (or I have hacked an already whitelisted site) my options are much better. Now I can run Javascript, and now my exploit should work just about perfectly, as long as it doesn’t rely on XSS/CSRF.

On a whitelisted site the user is partially protected, specifically against XSS/CSRF attacks, but if I control the entire site and it is whitelisted I have enough power to exploit the browser as if it weren’t there.


Sandboxie is a program designed to create a copy-on-write sandbox for programs. It emulates system services and attempts to isolate the browser as best it can. As an attacker Sandboxie doesn’t come into play until I’ve actually taken over the browser.

So, I get you to click a website, I break into your browser (see other post on browser exploitation), and now I’m in a somewhat confined environment. Anything on the system is readable by default, giving me a massive amount of valuable information about the system, like what programs are installed, security policies, personal documents, passwords, databases, etc. Post exploitation becomes much easier when read access is granted so gratuitously, making later steps much easier.

Is an attacker I can probably already make serious money off of this user. I have their browser info, potentially passwords or hashes, I can get personal documents, I can keylog, I can read work documents, etc. But what if I want to get persistence? What if I want this to be part of my new botnet? I have to get out of the sandbox.

Now I have to get out of the sandbox if I want enough rights to hook this machine up to my botnet. How do I go about doing this? Well, thanks to the read access I’ve been given I have a ton of info on the system. This makes local exploitation much easier. I can exploit the kernel in the sandbox (reducing kernel attack surface on Windows is ridiculously difficult read: not a logical approach) and break right out, once I’m kernel level I simply unhook Sandboxie and I own the computer, I can do whatever I want.

Depending on the sandbox configuration things can be much much easier or potentially more difficult (I see more weak policies than strong policies in my experience).


And there you have it. Two security programs that a few people have been asking me to discuss for some time. I’m avoiding talking about the programs themselves and their own attack surface, but if you read my posts you’ll be able to extrapolate.

I would say that NoScript adds a very significant layer of security, and should be on every Firefox users browser. Sandboxie is a good choice if you’re willing to set up powerful policies and start denying read access – a default install is OK though.

13 thoughts on “Browser Exploitation Expanded – NoScript, Sandboxie

  1. Interesting write up. How about blocking all drives from Sandboxie settings(So Firefox can be used for all kinds of sites) and using an entirely different browser for banking and emailing purpose??

    • The more you block with Sandboxie the less information your attacker has at his disposal after he has exploited the browser. Keeping the browsers separated from each other is a good idea.

      • Thanks for the quick reply 🙂 I think blocking maximum stuff from sandboxie settings will be trial and error isnt it ? Do u think something can break if we block too much in windows or system32 folder?

  2. Hi,

    Very interesting as usual.
    So basically the Sandboxed (not to pick on Sandboxie application alone) layer protection relies heavily on a well patched Windows Kernel. All virtual protection will cease and made irrelevant in case of a 0-day against the latter as with the Duqu scenario.

    Speaking of Sandboxie and Kernel flaw exploitation; the latest version for both x86 & x64 platforms seem to address this issue.
    In previous x64 versions of the software, one had to run “the experimental protection feature” because of the Kernel Patch Protection feature that came with 64 bit version of Windows; in an attempt to mitigate those type of exploits.

    Few questions in mind though: 1) Was Duqu able to leverage the 0-day even on x64 versions despite its Kernel Patch Protection feature ? 2) Sandboxie claims to be able to “dynamically enhance the Windows kernel”; in other words (at least to my understanding) to protect it. How realistic is this affirmation.

    Thanks for your input.
    Good day.

    • Yes, sandboxing relies heavily on a secure kernel. In any case where an attacker is able to exploit the kernel there is no way that a sandbox implemented by software at or above the kernel level can contain it.

      Sandboxie does not address this issue (nor could it). All sandboxie does is run as the kernel now, which means that it can contain Administrative processes. Think of it this way:

      If you are kernel than you can contain admin and user.
      If you are admin than you can contain user.
      If you are user you can contain no one.

      Before, Sandboxie could not properly contain admins on 64bit, and that’s why it used Drop Rights.

      Kernel Patch Protection prevents an attacker from going from admin to kernel by just patching the kernel directly. It won’t stop an attacker from using a kernel exploit to get kernel level code execution.

      Sandboxie does not ‘dynamically enhance the windows kernel’ in any meaningful way to this context. It uses the kernel to implement a separate security model, that’s about it.

      • Fascinating, this whole 0-day exploits vs well patched Kernel /Os looks like a never ending hot-pursuit, hehe; great analogy by the way. The picture is now less “hazy”.

        Exciting times ahead, i can’t imagine the era when ~1Billion people will know how to code.

        Has cryopreservation been mastered ? :)))

        Thanks a lot

        • The way attacks are moving is interesting. As more people learn to attack systems I think we’ll see some really bad things happen in the world.

          Always happy to answer questions.

  3. Ok. My email is fake. Thanks for info and sorry for necroposting. But. My Sandboxie is set as this: deny access to folder where i am keeping my word, pdf, audio, video, photos and others documents and a document with my passwords; Sandboxie is set to deny modification in folder C:\Windows. I never keep my passwords in Password Manager(Lost this habit at 2010); I have only Noscript, Adblockplus, VTZilla and Flash player( Flash is set to ask to activate) enabled in my Mozilla Firefox. All other extensions are disabled (Java, vlc player, foxit reader, quick time, silver light et alii). I ditched Acrobat reader about 2 years ago. My protection: Noscript, Adblock Plus, Avast free 2014 and Comodo 6.3 ( without AV). All these buddies are sitting without disturbing my work or/ and pleasure in old XP SP3 with 2.2 GHZ Intel Celeron and 1,256 Gb of Ram. Again, Sorry for necroposting. I was searching for info about vulnerabilities in Noscript(in order to protect my PC) and I had a good reading. Best wishes from Lithuania.)

    • I don’t mind posts on old articles.

      NoScript and Sandboxie can work very nicely together, you seem to have a good setup going.

  4. Sorry, I want to add. Before going to site where I have to enter my loggin name and password, I always close Sandboxie and delete its content. My home page is set to blank page. When I want to log in somewhere I use Sandboxie. After logging out, I am cleaning Sandboxie. Best wishes from Lithuania.

  5. I don’t know if you read these comments anymore, but i’d like to ask something. I’m logged in as a standard user account and i have disabled all plugins expect javascript. If i’m correct you can’t modify my system or install any malware etc. You must have exploit for the browser and you must someway increase your user privileges to modify system and install something into it. So what can you do to my computer if i run sandboxed browser, plugins disabled (expect javascript), standard user account, all windows updates installed, latest browser (firefox), latest plugins.

    If you have some otherways to prevent drive-by downloads please tell me.

    • Yes, I still read all comments.

      ” So what can you do to my computer if i run sandboxed browser, plugins disabled (expect javascript), standard user account, all windows updates installed, latest browser (firefox), latest plugins.”

      So you have a browser running in a sandbox (I’ll assume Sandboxie) and it will run Javasrcipt. So the attack surface of your browser is the Javascript renderer, which runs as a standard user at medium integrity. A compromise of this renderer would require a 0day vulnerability, which are not as commonly exploited in browsers like Firefox, but still certainly exist.

      Once the attacker has used their 0day on your browser they’re now in Sandboxie. As I talk about in the article, once you’re an attacker in Sandboxie you have a few options:

      1) Steal whatever data you can while you’re in the sandbox, whatever files you can read, etc

      2) Use data that you can read to exploit the system further.

      3) Try to gain persistence within the sandbox.

      None of this is super likely on a fully patched system. If you want more security you can try NoScript and/or EMET.

Leave a Reply

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