Cuckoo Round Two

In reality, that title is a bit misleading, as what I’m about to tell you isn’t cuckooreally anything “new.” However, it is new(er) for me. Back in June, I gave a run down of how to set up and use your own dynamic malware analysis system using an open source project called Cuckoo Sandbox. Out of the box, Cuckoo works great on its own; no complaint here. But, out of the box does not always mean everything is going to work as needed all of the time.

A couple of months after my last blog post, I was running lots of samples through the Cuckoo API that were automatically downloaded from a repository where I have some Yara rules that look for some type of specific badness or the other. This was working out fine and dandy, until one day I noticed that my system kept core dumping and going into kernel panic mode. I struggled with this problem for several days, doing everything I could to try and fix the problem: updating and upgrading the system, running fewer samples, reinstalling packages, all to no avail.

After some conversation with other researchers in the security industry, it came to my attention that the specific malware I had been hunting had started to employ a defensive tactic by making lots and lots of useless API calls, in the attempt to break the analysis by filling up the database and thus crashing the system.

This appeared to be a very effective means of making my day harder — obviously the intended result.

Luckily, in the same conversation, I was pointed to a fork of Cuckoo with some modifications to deal with this exact problem, as well as a few others.

Per the README.md, the fixes and additions include:

  • Fully-normalized file and registry names
  • 64-bit analysis
  • Handling of WoW64 filesystem redirection
  • Many additional API hooks
  • Service monitoring
  • Correlates API calls to malware call chains
  • Ability to follow APC injection and stealth explorer injection
  • Pretty-printed API flags
  • Per-analysis Tor support
  • Over 130 new signature modules (over 70 developed solely by Optiv)
  • Anti-anti-sandbox and anti-anti-VM techniques built-in
  • More stable hooking
  • Ability to restore removed hooks
  • Greatly improved behavioral analysis and signature module API
  • Ability to post comments about analyses
  • Deep hooks in IE’s JavaScript and DOM engines usable for Exploit Kit identification
  • Automatic extraction and submission of interesting files from ZIPs, RARs, RFC 2822 emails (.eml), and Outlook .msg files
  • Direct submission of AV quarantine files (Forefront, McAfee, TrendMicro, Kaspersky, MalwareBytes, MSE/SCEP, and SEP12 formats currently supported)
  • Automatic malware classification by Malheur
  • Significant contributions from Jeremy Hedges, William Metcalf, and Kevin Ross
  • Hundreds of other bugfixes

To be completely honest I don’t know which one of these “fixes” actually took care of my database problem, but it did indeed work as I was told it would. Soon after re-installing, I was back up and running and all of my core dump problems went away. Once again, I was a happy little analyst.

One of the cooler aspects to this update I noticed was the ability to change the database to use Elasticsearch, thus allowing the use of the entire ELK stack as a built-in feature. If you have never used ELK before, I highly recommend checking it out. Its versatility goes far beyond just making pretty graphs for dynamic malware analysis, as can be seen in the following example (which is not relevant to information in this blog):

elk_board

(source: http://www.digitalgov.gov/files/2014/05/600-x-333-ELK-dashboard-deck.jpg)

With the addition of more than 100 signatures for detection, TOR for obfuscation, ELK for fancy, pretty graphs, anti-anti-virtual machine capabilities, and much more, I would have to recommend, if nothing else, to at least try this modified Cuckoo fork and decided for yourself.

But I’m pretty sure you will agree its enhancements are well worth it.

This post is categorized in: