Sometimes there is a need to analyze files in a live environment where their composition and providence may not be entirely certain. For the most part we can try to reply on virus detection and heuristics to detect potentially malicious files, but what about those files which have not yet been identified, or have been specifically crafted for your organisation as a targeted attack?
This is where the Cuckoo sandbox can help in analysing files rapidly, and potentially be used to feed into other threat reporting and case work systems. In this article I will show some of the functions which can be performed with Cuckoo and a Windows 10 Virtual Machine Guest correctly configured to handle most payloads.
For this example I will be installing Cuckoo on an Ubuntu host which is actually part of an ESXI cluster - meaning I am running a virtual machine within a virtual machine...
There are a few requirements and I will break this down into stages to make things nice and easy.
We need to install some dependencies, we take care of that through installing the following:
sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y sudo apt-get install python python-pip python-dev libffi-dev libssl-dev -y sudo apt-get install python-virtualenv python-setuptools -y sudo apt-get install virtualbox virtualbox-guest-additions-iso virtualbox-dkms -y sudo apt-get install libjpeg-dev zlib1g-dev sw1g ssdeep tcpdump mongodb volatility -y
Tcpdump is required to capture VM network activity, but we will also require it to operate as root. Its permissions can be updated with the following:
setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump
It is highly recommended to not operate Cuckoo as root in these environments, so making Tcpdump executable from the 'cuckoo' user makes sense as you will be capturing network packets as an analysis proceeds.
pip install -U weasyprint==0.42.2 pip install -U cuckoo
This will install weasyprint (yes this version is required) and Cuckoo through pip. It will take a while, but once done will have all of the base packages you will require to start configuring the malware analysis environment.
Downloading your Windows VMs and Importing into VirtualBox
You can choose to install your own 'gold' images of Windows for testing against the Cuckoo, however if you are really only keen on pulling apart samples relatively quickly and easily you can spin up some prebuilt Windows test OVAs which are provided by Microsoft on a 90 day licence. These images come pre-loaded with the Virtualbox Guest VM software already in place, which saves you the added step of installing it.
mkdir /opt/cuckoos mkdir /opt/cuckoos/shared mkdir /opt/cuckoos/ovas wget https://az792536.vo.msecnd.net/vms/VMBuild_20180425/VirtualBox/MSEdge/MSEdge.Win10.VirtualBox.zip -O /opt/cuckoos/ovas/Windows10.zip
Now that I have the Windows 10 OVA downloaded, we can start by importing it into VirtualBox and then preparing the network interfaces.
vboxmanage hostonlyif create vboxmanage hostonlyif ipconfig vboxnet0 -–ip 192.168.56.1 –-netmask 255.255.255.0
What we have done here is create a HostOnly interface and assigned an IP address to it. This is the subnet which will be used to communicate between the malware VM and the Virtualbox host.
vboxmanage import Windows10.ova --vsys 0 --vmname Windows10_1 --cpus 1 --memory 2048 --unit 10 --disk /opt/cuckoos/Windows10_1.vmdk vboxmanage modifyvm Windows10_1 --nic1 hostonly vboxmanage modifyvm Windows10_1 --hostonlyadapter1 vboxnet0 vboxmanage sharedfolder add Windows10_1 --name "Shared" --hostpath /opt/cuckoos/shared --automount cp /etc/cuckoo/agent/agent.py /opt/cuckoos/shared
Now we have imported the OVA as a VM into Virtualbox and assigned a network interface to it. We have also added a Shared Folder to the VM which will contain our agent and base software which will need to be installed onto the guest.
iptables -t nat -A POSTROUTING -o eth0 -s 192.168.56.0/24 -j MASQUERADE iptables -P FORWARD DROP iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -s 192.168.56.0/24 -j ACCEPT iptables -A FORWARD -s 192.168.56.0/24 -d 192.168.56.0/24 -j ACCEPT iptables -A FORWARD -j LOG sysctl -w net.ipv4.ip_forward=1
We now need to tell the guest VM (if you want it to) how to connect to the Internet. Take care within this part to ensure your outgoing adapter is correctly named (in this case mine is eth0 - yours may be different!).
With this complete, you should now be able to start powering up your VM to get it into a ready state for analysis.
Starting the VM, Snapshotting, and Returning to Ready State
Running the startvm command needs to be from within an Ubuntu GUI session, otherwise the output from the VM will not be visible. Once the VM is configured to the operative state, then we take a snapshot of the instance, shut it down, then restore it to the snapshot. The idea being, each time an analysis occurs, this VM will be spun up at that point for analysis.
When you are ready to start building your Cuckoo VM run the following:
vboxmanage startvm "Windows10_1"
Prior to snapshotting your installation and making it available to Cuckoo, you need to ensure a few capabilities are ready to roll.
This must include the following:
- Disable Updates
- Disable User Access Control
- Disable Firewall
- Disable Anti-virus
- Assign a static ip address within the 192.168.56.0/24 range
- The VM must be able to ping 192.168.56.1
- Python agent.py is running in the background as Administrator
If the above has been configured correctly, now you can snapshot your installation so it will restore from this point each time.
vboxmanage snapshot "Windows10_1" take "cuckoo-ready" --pause vboxmanage controlvm "Windows10_1" poweroff vboxmanage snapshot "Windows10_1" restorecurrent
Now we can tell Cuckoo about this virtual machine and have it added to the analysis engines.
Configuring Cuckoo with your Virtual Machine
Depending on where you have put the Cuckoo working directory you will find some configuration files which will require editing before you can start submitting samples.
In my example my CWD is located at /etc/cuckoo, so the files I will need to update are the following:
ignore_vulnerabilities = yes # recommend setting this to no in production machinery = virtualbox
[mongodb] enabled = yes
mode = gui # set this to headless if you want to not see the analysis live machines = Windows10_1 [Windows10_1] label = Windows10_1 platform = windows ip = 192.168.56.10 # Set to whatever you assigned to your analysis machine
Prior to running cuckoo as the daemon, make sure you update from the community repository.
cuckoo community cuckoo --cwd /etc/cuckoo
This will start Cuckoo with its working directory set to /etc/cuckoo. We need to make sure the virtual machine is now ready for analysis.
We can now see the Cuckoo has found the VM sitting in the shutdown state, and has a current snapshot ready for deployment. Now all that is left to do, is throw it an analysis to pull apart within the VM.
Detonating Executables in Cuckoo
Cuckoo is capable of more than just executing applications for analysis, but for this test I will be walking you through the first detonation within this environment.
For a test web can start the Cuckoo web interface, which will make things nice and easy to submit samples.
cuckoo web -H 127.0.0.1 -p 8000
This will make the cuckoo web interface available on your localhost adapter on port 8000. Open up your favourite browser, and send an executable file into cuckoo for analysis.
For my initial test I will be sending through Wannacry to a Windows 10 analysis machine.
We can see from the console that a job has been raised, now we are going to see the VM spin up (if we have set the mode to 'gui') - like so...
We can see the Wannacry sample has now been sent to the VM and is happily executing away in the background... there is however no telltale sign of the crypto wall yet.