Skip to main content
To Customer Support To Customer Support


Other than the HKLM registry access exception, this is not an academic exercise for me. Although this is asked in the context of a large business deployment of Sandboxie, it is applicable to all users of the software.

 

Consider the following scenario:


  • A user uses Sandboxie to isolate Firefox and any child processes into a sandbox
  • This sandbox is "light virtualization," implemented with a driver and dll injected into all sandboxed processes utilizing the Windows API to control and redirect operations into an isolated registry and disk area, rather than running another OS in a hypervisor
  • Firefox and child programs believe they have full write access to the file system and registry. They also believe that the changes they make are to the real system. Firefox and sub programs have absolutely no idea of their virtualization.
  • There are two exceptions that the user has specified

  1. Firefox can create and modify files in the user's real Downloads folder in the user's profile.
  2. Firefox can create and modify the host system's real HKLM RunOnce registry keys

  • The user downloads virus.exe with Firefox to the Downloads folder.
  • Using Firefox, the user launches virus.exe. Although it is stored in the real Download folder, it is sandboxed since it was launched by the user telling Firefox to launch it.
  • WSA can see virus.exe running it and knows it is not trustworthy. WSA begins journaling virus.exe changes.
  • virus.exe is given free reign to infect its isolated area. It modifies core system files and registry keys in the sandbox.
  • virus.exe dump payload.exe into the user's real Downloads folder and creates an HKLM RunOnce key to launch payload.exe on next system boot. Because of the sandbox exceptions, it is able to do these two actions outside of the sandbox and on the host system.
  • WSA detects virus.exe and kills the process
  • The sandbox no longer has any running processes and is stopped and deleted. The only remaining traces are payload.exe and the HKLM registry key to run it on the next boot.
  • WSA begins its cleanup process.
With this scenario in mind:


  1. Are there any theoretical ways that WSA would be confused and apply rollback changes to the real system, when the actual changes happened in the sandbox?
  2. Would it see the changes virus.exe made outside the sandbox?
Interesting scenario. Based on the description of Sandobixe, new executions in the virtualized environment are controlled through the driver and DLL injection, meaning that virus.exe would execute as a child process of the sandbox environment. At this point we would likely detect and prevent execution of virus.exe. But let’s say that doesn’t happen. WSA would see virus.exe as a new process and journal any changes, including payload.exe and the registry run key, both created by virus.exe and applied outside of the sandbox environment. Since virus.exe is deleted when the Sandboixe environment terminates, that file will never be found and the journal for its execution will never be used for remediation of its actions. However, payload.exe and the associated run key are still linked. When payload.exe is identified to be malicious, the registry is parsed looking for pointers to the detected file and so the registry would be remediated. While journaling and rollback is the ideal way to remeidate, this data isn't always available. It is for this reason that the remediation process has many steps to ensure all components of a detected infection are addressed.

 

 

 

 
Hi @ thank you for the answer.

So WSA would not be fooled or misled regardless of what a process thinks it's doing in it's own driver-supported fantasy land? Its monitoring for system-level actions occurs directly and is not informed/overriden by information sampled from a process itself?

 

I'm doing the best I can with the terminology - I'm unfortunately not a programmer nor have I gotten around to finishing the Sysinternals books.
No worries 🙂 I appreciate your interest in how this all works.

 

First, I should mention that we are testing this internally now to confirm what I mentioned before with Sandboxie. 

As long as execution is taking place on the system, we should see these events. The driver for the sandbox is redirecting changes made by the process into the virtualized space. In any case, the application being sandboxed is still executing and performing its actions which we should record.

 

I will update this thread once I've heard back from Threat Research.
I'll echo Grayson's comments - WSA will journal the data whether inside or outside the sandbox, so we should be fully compatible in that sense. Granted, Sandboxie should prevent the bulk of the changes from hitting their intended locations but even if something bypasses Sandboxie we'll still see the distinct changes and relate them back to the originating process.
Grayson and JoeJ, many thanks for your explanations.

I'm very interested in this issue.

 

explanoit, thank you for opening this valuable thread:D



 

Regards,

 

Mike

Reply


Terms & Conditions