New! Sandbox Model for Maldocs

Co-author: Adair Collins

We have conducted extensive research for the past couple of years after we published the article on maldocs, which has led us to come up with a new model that could be utilized by sandbox vendors to enhance their products. The following workflow shows the logical flow on how maldocs should be handled inside a sandbox.

In order to analyze all exploitation vectors, such as the macro execution to exploit, user click to exploit and credential stealing including the ones we have considered below, we need a logical flow on how to view and analyze the file. Most sandboxes till date deploy the file and run it directly on virtual environments to determine the nature of the file. At times, this may work if the maldocs use macros for auto-execution. In the past couple of years, maldocs have evolved to encompass click-to-exploit, OLEs, linked-objects and source-files. In here, we will look at few examples with the flow defined above.

Macro execution to exploit

Maldocs within this category come with AutoOpen and AutoClose. For maldocs with AutoOpen send the file to the sandboxed VM environment, and open it as Microsoft Office Document or any other supporting application. If the maldoc contains AutoClose macro, then perform same steps as AutoOpen followed by simulation of click-to-close in X seconds. In either case, follow through with a standard sandbox analysis once the above steps are performed.

User click to exploit

Maldocs that fall within this category usually expects the users to read the content and is then baited to click the embedded script or binary contained within as OLE object, or to click on embedded link to direct them to exploit or phishing landing page. In either of these scenarios, macros aren't utilized and hence we would have to further analyze, to detect the usage of OLE objects. If there is an OLE object, extract them and perform a Yara scan for file extensions, types and/or keywords that may be present within maldocs, followed by checking if the file is 32-bit or 64-bit for effective analysis based on the architecture. Once this is performed, the file with extracted OLE objects can be sent for standard analysis.

Credential stealing

In scenarios where maldocs are utilized as credential stealers, the bad guy expect users to open the document with remote content request being sent via SMB or WebDAV, in order to capture net-NTLM authentication hash (challenge/response). In this case, the sandbox would have to extract the URL, linked-object or source-file and then download the external resource. The downloaded resource is then sent to multi-browser sandboxed environment to see how the malware reacts and taken screenshots for later review. PCAPs of the request-response traffic, beacons and the SMB or WebDAV for credential stealing are then captured and processed by Suricata/Bro for malicious packet analysis and archived in Moloch for future research. If this external resource is a secondary maldoc or an external file, then we would have to analyze it once again from the beginning of this process.

This article is shared with the intent of sandbox vendors extending their current maldoc analysis process to incorporate the above scenarios. In further articles, we will be discussing why sandboxes should be providing visibility into Microsoft Windows Event logs and WMI and Registry based persistence.

If you find this article to be interesting, please share your comments on what you have observed and your personal experience.

“If freedom of speech is taken away, then dumb and silent we may be led, like sheep to the slaughter.”  ―   George Washington

Disclaimer: Please note that these posts and what is described in them are for educational purposes only. Opinions expressed are solely my own and do not express the views or opinions of my employer.