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.
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 http://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.
Hi, can more than 1 sample be analyzed in a single VM at the same time?
I wish if Avira Labs release some analysis tools for students (as cuckoo sand box)
Hi,
I tried setting up a cuckoo server in my company. The results we receive shows the activities that the sample did, but we don’t see any conclusion (such as “Operates on Local fireswall’s policies and settings”) or other clear indications of malware that can be seen in mlwr.com.
Do I need to install anything else in the Cuckoo in order to receive the conclusion?
Conclusions are generated by python scripts that are called signatures. Cuckoo comes with some pre-installed. But there is also a community project with more: https://github.com/cuckoobox/community
Great article!