Cuckoo Sandbox vs. Reality

Problem

We get several hundred thousand potential malware samples every day, a number that increased when we began to detect even more by developing our Avira Protection Cloud technology. In the Avira Protection Lab, one of our primary tasks is to classify the samples and analyse their behavior, either for inclusion in our virus database or for repair. With this incredible amount of samples, it is of course impossible to do it all manually.

Solution

Our solution was to build a scalable system with detailed information about sample behaviors and functionalities. This system needed to be fully automated and reliable. To achieve that, one of the tools we are now using is Cuckoo Sandbox.

About: Cuckoo Sandbox

Although different types of “Sandbox” tools exist, Cuckoo is uniquely an “analysis sandbox” or “automated malware analysis system” — i.e. a system built to analyse the behavior of malware by running it in a fake Windows OS and monitoring it. If you saw the film “The Matrix” you should have a pretty good idea of it: a fake reality where the protagonists interact with an environment — and each other — isolated from reality (or, in the case of the sandbox, the real computer).

This kind of sandbox is normally sold as an appliance for companies with enhanced security requirements. A local specialist then investigates the results and classifies the analysed samples.

I discovered Cuckoo Sandbox while looking for a tool to automate experiments for the ITES research project. Cuckoo Sandbox is Open Source: https://cuckoosandbox.org/

Cuckoo Features

The malware-monitoring results go into large log files (6 MB on average per sample, but not uncommon to reach 100 MB) containing detailed descriptions of the malware behaviors.

The data we collect using Cuckoo comes from the User Space monitor and includes:

• API logs
• Network logs
• Static data for the sample and dropped files
• Screenshots
• System manipulation:  Files/Registry/Mutexes/Services
• Started processes and their relationship to the sample

With this information, it’s possible to classify the samples by their behavior. It’s also enough information to create a malware description and repair most of the malware infections.

Cuckoo vs. AV reality

We started to interact with Cuckoo two years ago. Even back in the ‘old days’, it was a good tool for sporadic malware analysis. But when it comes to research projects and AV use we have some special needs. This is why I’ve enhanced the following:

• Stability: We have several servers running 24 hours a day, crunching through about 200 samples per hour. If Cuckoo crashes once in 1000 samples, we would have lots of maintenance to do. So bug fixing was one of my main tasks.
• Performance: Reducing the amount of servers needed is essential. Better performance means less hardware running. The more hardware you need, the more expensive it gets, but even worse: It can fail and require maintenance. Reducing servers is reducing failures. By improving the performance, I also reduced latency, which means we get our results faster.
• Classification: The main task of our Virus Lab is to classify samples at least into the categories good/bad. To be able to have that done automatically by Cuckoo, I had do add some features to the signatures (detection rules). The most essential feature was “Meta Signatures” — i.e. signatures that run at the end and combine several “weaker” signatures into a classification.
• Data collection: Cuckoo API logs have a specific view: The commands the sample sends to the Windows API. With some processing, it’s possible to get a new view that is more interesting for us: Which system objects have been manipulated… and how? That is the “enhanced behavior” part of the Cuckoo logs I created. It contains Registry keys, Services, Files, … and the way they got modified. That can be “deleted”, “read”, “stopped” (for services) and more. With that knowledge, repair and automated generation of a description is just one step away.
• Other Monitor: An essential part of the ITES project was to test several different sensors. While Cuckoo normally monitors malware in the User Space, the open source tool Volatility is able to take a memory snapshot of the OS and scan for anomalies. Its speciallity is identifying DKOM (Direct Kernel Object Manipulation https://en.wikipedia.org/wiki/Direct_kernel_object_manipulation), which are normally performed by rootkits. Combining Cuckoo and Volatility adds a rootkit scanning feature to Cuckoo. 

Weaknesses

Malware can detect “Glitches in the Matrix”. When the malware detects it is running in a simulated environment, it can show non-suspicious behavior or just stop running. Detection of this simulated environment is called “Anti-VM” technology (VM = virtual machine) and it’s been common for a few years now (more on that in another post).

Hooking (and it’s weaknesses)

The core part of the Cuckoo system is to monitor the behavior of suspicious processes. To achieve that, a DLL is injected into the memory of the processes to monitor. The DLL changes the entry commands of selected APIs in DLLs called by the process to first log that they have been called and then continue to jump back to their original functionality.

For more information, see:

https://github.com/jbremer/monitor

Some weaknesses:

• A program can inspect it’s own process space and overwrite the hooks with the original commands. Removing the logging and going stealth.
• Or the program can use hooks itself, accidentially overwrite the Cuckoo hooks with own hooks and crash horribly.

Those are core weaknesses of the hooking method. To cover those scenarios, Cuckoo now supports a check if the hooking is still in place and untouched.

Results from the Weaknesses

The impact of these weaknesses can be reduced, but never to zero. So we have to accept:

• It is not possible to flag a software as benign just because we did not see any malicious behavior
• Always combine behavior classification with other classification technology

How we use it

Cuckoo Sandbox has officially been added to our toolset in the Virus Lab. Suspicious and unknown samples will be scanned by Cuckoo and the results used for classification. We also take the logs to create experimental repair routines or descriptions. We are just beginning to use it and find more use cases for it. For Avira engineers, there are interesting times ahead.

My first virus lab

On https://malwr.com you can find a live Cuckoo system. Sometimes it does not accept new samples for classification due to heavy load, but at least the historical reports will give you a good impression of the information Cuckoo provides. Cuckoosandbox being open source, you can install it at home. But my advice: Do not play with malware at home if you don’t know exactly what you’re doing.

And remember: Use the Avira Protection Cloud to benefit from Behavior Detection and other cool tools without needing to install them.

And part of the ITES project:

For Science !

Thorsten Sick