We often get asked how VxStream Sandbox compares to proclaimed malware analysis industry leaders and other competitors. One aspect when comparing e.g. a hardware appliance with VxStream Sandbox is that our system is very configurable and a wide open "virtual appliance" (it is possible to deploy and scale application servers as a VM with embedded analysis VMs). What that means is that a lot of aspects are open and understandable. You can add/edit your own behavior signatures, import your own ISO files (e.g. "golden image"), control what happens during the analysis and so on. that can be configured to run files on any environment. On the other hand, pre-configured and so called "hardened" appliances (marketing term for "black box with voodoo magic") are predictable and easier to detect and evade. The previous points are architectural aspects, but what about the actual engine, the malware analysis and forensics side? We were interested to see how well the "big players" actually match up to some common techniques and decided to make a spot check. We will not disclose what vendor or product we compared against, but it was indeed one of those industry leaders, but more to that later.
The "spot check"
For this blogpost we decided to take a look at a persistence method, because successful persistence of any piece of malware is always quite critical. For a malware analysis system, the very least should be detecting the capability, but in the best case successfully trigger and reveal the methodology involved. To make our small experiment as realistic as possible, we decided not to write our own sample code, but use an exact copy of something you would find in the wild. Preferrably, we would like to use source code from an existing botnet/exploit kit or trojan. Luckily, the source code of Carberp - a botnet creation kit - was leaked back in mid 2013 (by the way: it made over $250,000,000 in damages). Seems like a perfect match to build a poc sample and test it against our own and competitor's system(s).
In the specific case of Carberp, there is an additional explosiveness: one must assume that components of the leaked code will be copycatted into other "projects" of this kind. Thus, one would assume special diligence in respect to detecting crucial parts, e.g. a persistence method that survives a reboot, would be put forward by the industry leaders. As an example, this industry leader spends a whopping $68M in Research and Development.
Back to the technical part: the specific persistence method we were looking at utilizes the Task Scheduler 2.0 interface (Vista and above) and the implementing code from Carberp can be found on github at schtasks.cpp and is publicly available to anyone:
What is the Task Scheduler? To quote Microsoft:
"The Task Scheduler enables you to automatically perform routine tasks on a chosen computer. The Task Scheduler does this by monitoring whatever criteria you choose to initiate the tasks (referred to as triggers) and then executing the tasks when the criteria is met."
More precisely, the Task Scheduler 1.0 was shipped starting with Windows 2000, XP and Server 2003. It is quite old and not that interesting for our test case, because with v1.0 the process adding a task does so in a quite visible and easy-to-detect way for Sandbox systems that monitor specific processes. To be concrete: a *.job file (basically, an XML file that references conditions and actions) is created with the help of mstask.dll. The new Task Scheduler 2.0 interface (which was introduced with Windows Vista) is far more interesting though: it utilizes the taskschd.dll (Task Scheduler COM API) to invoke creation of the task through the Task Scheduler service (svchost.exe). When a sandbox system relies on observing actions of single processes only, it will have issues detecting the exact file creation and/or registry events, because the svchost.exe instance is not part of the process tree and subsequently not included in runtime logging. As VxStream Sandbox observes the entire file system state, it would detect tasks being scheduled, as a file system change happens.
So anyway, we quickly whipped up a proof of concept executable that creates a task to execute C:/malware.exe when a LOGON event is triggered. Should we succeed in setting this task on a Windows machine, we would expect all alarm signals of the analysis system to go off. Well, from all the systems we were able to test the our sample was classified as "benign" and had no malicious alerts of any relevance. Side note: want to try on your own appliance/sandbox? At the end of the blogpost we have a link to the VxStream Sandbox report which contains a download link to the sample we used.
So how did VxStream Sandbox perform? Please do take a look yourself (yes, we did optimize a bit before making this blogpost):
VxStream Sandbox Report: https://www.reverse.it/sample/fd6a9541b1826f5242395f789d341b1478e66e93a7c388d07f51146163494455?environmentId=1
SHA256: fd6a9541b1826f5242395f789d341b1478e66e93a7c388d07f51146163494455
Conclusion
Some may call this blogpost nitpicking, because security always contains multiple layers and a sandbox is not a silver bullet. True, but if you charge premium price, have a big mouth regarding your own technology - then you should at least get your homework done and detect when a scheduled task is registered that runs an arbitrary executable on every reboot.
Something else we noticed: lately
there has been a variety of blogposts around malware utilizing the COM
interface in order to evade analysis and it seems like an uprising
trend, because - as briefly mentioned - the malicious activity is happening at a remote process.
