Analysis of nested archives with Cuckoo Sandbox: SFlock 0.1 release

It has been almost six years since Cuckoo Sandbox started out. Ever since then, it’s had the same, basic file submission capabilities. With the release of the first version of the SFlock library and Cuckoo’s new and upcoming Web Interface (still to be announced) this is about to change.

Those analyzing malicious documents attached to incoming emails with Cuckoo may have noticed the lack of proper .zip support, let alone other popular archive formats such as .rar, .7z, and .ace (an ancient archive format that’s been getting a lot of attention in spamruns in recent months).

Although we are still actively working on the new Web Interface, which has not yet been finished off, we can already show some screenshots regarding the new submission page that represent the functionality the sflock library exposes to Cuckoo Sandbox.

Following we have submitted a couple of files. Namely the following three:

• eml_nested_eml.eml, an email with another email as attachment containing a Microsoft Office Word document as well as a cuckoo.png image, based on a sample by @edwincheese.
• msg_invoice.msg, an email with an embedded Microsoft Outlook Macro object containing a Firefox 43.0.1 installer executable, based on a sample by Kevin Beaumont.
• bup_test.bup, a McAfee quarantine file containing a .zip file with an embedded .scr file, based on a sample by @herrcore.

As-is this looks as follows.

Or for those who work from home at night, the following theme might be of interest.

As may be seen on this pictures, there’s a couple of things going on with regards to the file selection:

• By automatically unpacking any and all archive files sflock and Cuckoo are capable of selecting those embedded files that should be analyzed, and ignoring the rest of the files (i.e., images and files that are not executable on regular Windows machines). In the example shown here you will see that cuckoo.png, image003.emz, and image004.png are not selected, as these are image files and/or other non-executable files.
• With this new technology, Cuckoo is able to make multiple analysis tasks out of a single archive file. Submitting an archive with two javascript files and one executable will from now on create three analysis tasks (rather than one that fails, as it used to be the case).
• Duplicate files are submitted only once. In the screenshot this can be seen as att1 has the exact same file contents as the .doc image with Chinese characters (?) as filename. Therefore the att1 file is not selected to be submitted as an analysis task. (And, yes, with a filesize of 12 bytes, the .doc file with not do much interesting).
• There’s currently still a bug where the Firefox Setup Stub 43.0.1.exe file is selected in the Web Interface representation, but that shouldn’t be the case (simply by analyzing the oledata.mso file the Firefox Setup Stub 43.0.1.exe should be started automatically - as this is the payload - with the correct parent process and, if that’s even possible to define (I’m not sure), the correct command-line arguments, etc).
• Finally the efax_9057733019_pdf.scr file will be submitted as an analysis task as expected, as it is an executable file.

We’d like to stress the fact that even though specific files from these various different archive files will be executed during an analysis, their context, or related files, will be next to the analyzed files during the analysis. As an example, in the case of an oledata.mso analysis Cuckoo will automatically drop the image003.emz and image004.png files in the same directory as the oledata.mso file during the analysis, preventing any anti-analysis tricks based on the presence of related files.

Before finishing off this blogpost we’d like to mention that the sflock library is also perfectly capable of being used by other programs, so please reach out to us if you intend to integrate it with other toolkit(s). Its API has been designed to be as simple as possible and therefore may be fully utilized simply by invoking the following line of code (which dumps a Python dictionary that may be embedded directly as JSON blob):

from sflock import unpack

print unpack("archive.rar").astree()

Naturally there are a couple of configurable options available, but by default these have all been abstracted away by its basic interface.

Last but not least. SFlock has quite some unittests covering more than 90% of the code, making sure we’re capable of implementing new features without breaking current functionality. And naturally, due to the its usage of native tooling, we have implemented a custom usermode Linux sandbox for wrapping rar, 7z, and unace so that (in theory) all potential security vulnerabilities have been mitigated. More can be read about this at the sflock and zipjail GitHub pages. Naturally the zipjail sandbox contains plenty of unittests itself to ensure basic security practices are in-place. I’ll personally hand out beers to whomever is able to break out of the latest version of zipjail. That said, thanks to Jann Horn for reporting a couple of security issues.

We hope you’re as stoked about these upcoming features in Cuckoo Sandbox as we are. We’ll keep you posted as we put out new releases and blogposts. As always, if there are any questions or suggestions, please do reach out to us.