Re-imaged machines, local sandboxes, and even process emulation on the user’s device are common tactics researchers use to insulate themselves from the malicious content they need to capture and analyze. But if you step back and think of it, these approaches violate a core tenet of security research: they expose their local resources (e.g. IP address, network gateway, local servers, local machine) to the threat.

What alternatives are available to help with this problem?

Silo is Authentic8’s virtual browser that lives in the cloud. We typically sell to IT teams looking to secure and control their users’ access to web-based services. But we’ve seen a spike in Silo usage for information security researchers, malware analysts, and incident response teams. These users recognize that using a cloud-based virtual browser keeps malicious code at an arm’s length. But the browser isn’t enough. We’ve built an app within Silo called Toolbox that, when launched, spins up a new, isolated browser configured to exit to the Internet from a variety of locations around the world (we wrote about it here).

In addition to the browser, when you launch Toolbox, a temporary file system is created that allows data to be downloaded within the sandbox environment to be analyzed, manipulated, or uploaded to other web-based services. Files residing in the temporary file system are encrypted and held securely in our datacenter for as long as the user keeps the browser session open. Since each instance of Toolbox has its own dedicated file system, all content is isolated when downloaded, preventing cross contamination. If content needs to be shared with other researchers or if copies of the content should persist, data can be uploaded from the virtual file system to a web-based storage service like Dropbox or Google Drive.

When the user closes the browser to end their session, display data on the client is purged, and the browser instance and contents of the virtual file system are deleted. On the next session launch, the researcher starts with a fresh environment.

What challenge led to the development of a virtual file system?

InfoSec researchers were looking for a way to save data without compromising the local file system. They needed to save page headers or payloads for later analysis but any research that exposes local resources carries the risk of letting malware into the environment. We wanted to provide them with a way to save and share data with a layer of insulation between web content and local resources to eliminate that risk.

How are customers using the virtual file system?

When an InfoSec researcher is looking into a potentially malicious website and discovers questionable code that requires deeper investigation, they can save page data and any associated payload to the temporary file system. Then, any browser-based analysis tool (such as Lastline or VirusTotal) can access the file system and analyze the content. Or let’s say an organization has trapped a potentially corrupted PDF file in their DMZ. An incident responder can upload the suspicious file to a web-based storage system, then open a Silo session and download the file into the virtual file system. Then the PDF can be rendered within the browser or cracked open with peepdf running in a browser-based Python environment like Skulpt.

With Toolbox and its temporary file system, you get a fully remote sandbox that allows you to store, manipulate, and execute potential malicious code without the risky step of bringing the content into your network.

No sandbox is perfect. So you need perfect isolation of the sandbox to protect yourself from whatever it is you’re researching.