In previous posts I have discussed the building of Cuckoo as a semi-automated malware analysis environment for the purpose of deliberate analysis of artefacts. The downside of this particular configuration being it was really on capable of single analysis at a time, so how do we expand the functionality to allow for parallel analysis (especially handy if you have lots of artefacts to analysed)?
First of all, you really need to complete the base installation of Cuckoo on an Ubuntu distribution. My guide on that can be found here, as well as my guide on building guest VMs which will be run within VirtualBox for analysis.
Getting the baseline system ready
Before we start on this, make sure you have enough CPU, RAM and drive space allocated to your Cuckoo host. For my example, I will be deploying 5 analysis VMs within Cuckoo, with the intention of having MISP used as an enrichment tool and a reporting tool (reduced requirement to retain analysis afterwards).
System specification in my case will be:
– 6x vCPUs
– 8GB RAM
– 128 GB HDD
Analysis virtual machines in my case will be Windows 7 Test VMs which are available from Microsoft. I have had their configurations deliberately weakened in disabling the host firewall and disabling the windows update mechanism. I have also chosen to not allow a remote connection to the internet for analysis, instead opting to have these machines represent offline assets.
Generating the analysis VMs
Assuming you already have a guest VM (analysis VM) configured and ready to be deployed, we can simply clone the existing VM and create an iteration, or we could take a snapshot of the base image, and then create a linked clone.
In this case I am opting to create a full clone of the VM for simplicity’s sake. This will mean an increased amount of disk space will be required over that of a linked clone.
Once the VM is cloned, they will need to started and then reconfigured to ensure there are no IP conflicts between each other, and the hostnames will need to be changed to prevent confusion or name collisions in the vboxnet0 local switch.
[email protected]:~$ sudo vboxmanage clonevm Windows7_1 --register --name Windows7_2 [email protected]:~$ sudo vboxmanage clonevm Windows7_1 --register --name Windows7_3 [email protected]:~$ sudo vboxmanage clonevm Windows7_1 --register --name Windows7_4 [email protected]:~$ sudo vboxmanage clonevm Windows7_1 --register --name Windows7_5
I should now have 5 virtual machines based on Windows 7 configured within my Cuckoo host. Their addresses and hostname should be configured as follows:
– Windows7_1 (192.168.56.101)
– Windows7_2 (192.168.56.102)
– Windows7_3 (192.168.56.103)
– Windows7_4 (192.168.56.104)
– Windows7_5 (192.168.56.105)
Assuming each VM has been configured correctly, they should all be able to contact the reporting server, which in this instance is the Cuckoo interface shared with the VMs. From each VM ping 192.168.56.1, and if you get a reply the network interface is working between Cuckoo and the VM.
Be sure to test in the other direction, as the python agent script presents a service which allows Cuckoo to interact with the analysis VM.
If you cannot contact the analysis VM there are a couple of potential issues:
1. Check the IP addressing is in the same subnet and not already used by another VM; and
2. Check to ensure the firewall is disabled on the analysis VM (more information is available on that in this post).
Each analysis VM has been built from the base Windows 7 VM provided by Microsoft, and has been additionally furnished with MS Office applications, and Adobe Reader. It is very important that any nag screens are acknowledged or disabled prior to deploying this environment, otherwise the analysis may not complete, and your screenshots will have a recurring element of nag screen without the intelligence.
Assuming the VMs have been configured correctly (see this guide on doing so) they can now be snapshotted, and then restored to current ready for Cuckoo to utilise them.
[email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_1" take "ready-state" --pause [email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_2" take "ready-state" --pause [email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_3" take "ready-state" --pause [email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_4" take "ready-state" --pause [email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_5" take "ready-state" --pause [email protected]:/etc/cuckoo# vboxmanage controlvm "Windows7_1" poweroff [email protected]:/etc/cuckoo# vboxmanage controlvm "Windows7_2" poweroff [email protected]:/etc/cuckoo# vboxmanage controlvm "Windows7_3" poweroff [email protected]:/etc/cuckoo# vboxmanage controlvm "Windows7_4" poweroff [email protected]:/etc/cuckoo# vboxmanage controlvm "Windows7_5" poweroff [email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_1" restorecurrent [email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_2" restorecurrent [email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_3" restorecurrent [email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_4" restorecurrent [email protected]:/etc/cuckoo# vboxmanage snapshot "Windows7_5" restorecurrent
Postgresql for parallel job management
Cuckoo straight of the box will do single analysis just fine, and will even allow you to queue up the analysis – however this default configuration is not compatible with parallel analysis where some jobs may finish much quicker than others. This is where postgresql comes in to assist.
[email protected]uckoo:~$ sudo apt install postgresql postgresql-contrib [email protected]:~$ sudo apt install libpq-dev [email protected]:~$ sudo pip install psycopg2 [email protected]:~$ sudo -u postgres psql CREATE DATABASE cuckoo; CREATE USER cuckoo WITH ENCRYPTED PASSWORD 'CUCKOOPASSWORD'; GRANT ALL PRIVILEGES ON DATABASE cuckoo TO cuckoo; \q
Your Cuckoo configuration will now need to be updated to reflect the database connection being used. We do this through modifying the $CWD/conf/cuckoo.conf file, and updating the [database] section to have the postgresql credentials.
Adding the analysis VMs to Cuckoo configuration
We can now add our analysis VMs to the $CWD/conf/ virtualbox.conf file, making sure to get the spelling of each VM the same as that described within vboxmanage list vms.
First up start by creating the Machines entries in the form of [Windows7_1] and populating the configuration under them. The example below describes how each VM needs to be entered into configuration:
Then the ‘machines’ variable needs to be updated with the corresponding entries to add the machines to the analysis queue:
Enabling the Web UI
To test this functionality we are going to need the web UI, and in needing this we require MongoDB to be enabled in the reporting.conf file. The $CWD/conf/reporting.conf file needs to have the enabled variable changed to allow Mongo to run, to then enable the Web UI.
Updating Cuckoo before testing
Cuckoo should be updated periodically, for this reason we run the community parameter, which allows Cuckoo to download it’s latest sandbox configuration.
[email protected]:~$ sudo cuckoo community
Starting Cuckoo and validating
Running cuckoo -d will instigate the daemon in the foreground, once we can validate the daemon is working and analysis is operating as expected, we will configure this to run in the background.
[email protected]:~$ sudo cuckoo -d
You may see something like this (^) for the purposes of this demonstration I am not going into process instances (yet).
We now need to run up the Web Interface ready for sending a bunch of samples through, we need to do that from another CLI command cuckoo web with some extra flags.
[email protected]:~$ sudo cuckoo web --host 127.0.0.1 --port 8000
Using your preferred browser you should see the Cuckoo web interface at http://127.0.0.1:8000 along with some system statistics. Now we can start throwing some tasks at the gui to make sure all our VMs are firing and reporting back.
Giving Cuckoo a test run
For this test run I am going to throw in some malware from theZoo, and see what comes out at the other end… this should be an interesting test to see what does and does not work.
Leave all the settings as they are, then hit Analyze in the top right corner. You should notice the Cuckoo console going wild in the background with tasks and communications back from Virtualbox and the relevant agents on the VMs.
We can see now that all 5 VMs are currently processing their samples, and actively reporting back through the Cuckoo daemon. Now we just need to look for completions and dig through their reports.
A completed analysis and generated report should look something like the below at conclusion:
Well it seems the scores are a bit low considering what the samples were, but this may be due to how Cuckoo does analysis without external assistance. In the next blog post I will be discussing the use of MISP to enrich results, and also record analysis results for further enrichment.