Using CAPE Sandbox and FOG to analyze malware on physical machines
If you are working in the field of IT security the concept of sandbox evasion shouldn’t be new to you. If it is, don’t worry - I got you covered!
Most modern malware tries to determine in one way or another if it is being analyzed either by humans or sandboxes and if it detects something like this, it stops what it was about to do or changes its behaviour.
Some of them rely on determining if some vendor specific drivers (like VirtualBox or VMWare) are present, BIOS values are set etc. The ways to detect if you are in a sandbox are virtually endless. A lot of those methods rely on artifacts from virtualization software like those stated above.
Now imagine, we as analysts wouldn’t have to worry to hide all those artifacts since they aren’t there in the first place? Our chances to witness the real behaviour of the malware would be much higher!
Fortunately we aren’t the first one with this thought so we don’t have to reinvent the wheel and are “standing on the shoulder of giants”!
Ingredients
- 1 Teaspoon of CAPE Sandbox
- 1 Cup of FOG Project
- 1 Can of physical hardware (like an Intel NUC)
- 200 grams of virtualization host for our CAPE and FOG VMs
For our recipe to work out, we first have to think about our network layout. Since this will depend heavily on your existing network there is no “one fits all” solution to this, so I’ll only add some Do’s and Dont’s.
Do
- Your physical analysis machine must be reachable by your CAPE server
- Your physical analysis machine must be reachable by your FOG server
- Your FOG server must be reachable by your CAPE server
- You have to add DHCP options for PXE to your existing DHCP server or set up FOG to be a DHCP server
Don’t
- You must not allow your physical analysis machine to reach other machines within your network — except CAPE and FOG. The last thing you want is to spread malware in your corporate network!
It is your own responsibility to design your network in a way that it is not affected by malware running on the analysis machine! You have been warned!
Let’s get started!
Level 1 — Installing CAPEv2
Once, we’ve made our decisions regarding our network setup, we first start by installing CAPE Sandbox on a freshly installed Ubuntu 20.04. Thanks to @D00m3dR4v3n this task couldn’t be easier.
When you have set up your future CAPE VM, and updated it with
sudo apt get update && sudp apt-get upgrade -y && sudo reboot
you can proceed to download the installer script to your CAPE VM. Make sure to edit the parameters at the start to fit your needs especially in regards of NETWORK_IFACE, IFACE_IP, PASSWD, DIST_MASTER_IP and USER.
When you are satisfied with your changes, save them and “chmod +x” your script and then run it with
sudo ./cape2.sh base cape
This will run some time and give you time to reevaluate your life goals and to fantasize about the alpaca farm you will start once you are done with infosec.
Once the script is finished, give your box a restart and you should be able to browse to http://127.0.0.1:8000 and should be greeted with this:
Congratulations, you mastered Level 1 on your way to become a sandbox ninja! Please proceed with Level 2.
Level 2 — Installing FOG
Maybe you asked yourself: How the hell am I supposed to reset my physical machine once I infected it with malware? Well, there are two options in this case. You could either reinstall Windows, install all updates all over again, install all software by hand — or you can use an imaging software like the awesome FOG Project!
FOG allows you to record your finished analysis installation and once you are finished with your malware analysis allows you to boot up your physical machine with PXE and deploy your clean image. So let’s get started with setting up FOG!
The first step is to set up another VM (or physical host — it doesn’t really make a difference) and update it like we did it with CAPE. Once you are up-to-date you should install git:
sudo apt install git
and afterwards clone the FOG repository from GitHub:
Once downloaded, cd into fogproject/bin and run installfog.sh
sudo foginstall.sh
The script will then ask you a few questions. The answers highly depend on your network layout especially if Fog will be the DHCP server in your network or if you will add the DHCP options responsible for PXE to your already existing DHCP server. In our scenario, we are going with the second option and tell FOG not to be a DHCP server:
I suggest to take a snapshot of your FOG host before doing those steps so you can always go back to the pre-installation state if you screw up. If you feel lost, there are a ton of YouTube videos and documentations out there on how to set up FOG to fit your needs.
After continuing you now have again time to think about your alpaca farm since this will also take a while.
Once your FOG installation is almost ready the script will tell you so:
Time to fire up your browser and do what we were told to do.
Once it’s finished its time to update our DHCP server — once again this highly depends on the options you chose and may differ. In my case I’m using VMWare Workstation for this demo and use its built in DHCP server so I edit its vmnetdhcp.conf and add the options next-server and bootfile-name to the section for the corresponding NIC:
Afterwards, either reboot your host or restart the VMWare DHCP service. This is it for now! It’s time to set up our client which we will use to execute the malware. Please proceed to Level 3 — Setting up the physical client.
Level 3 — Setting up the physical client
Congratulations on making it this far! This one is a fairly easy task since most people are comfortable with setting up Windows — may it be in a VM or on a physical host. Either way, just keep in mind that
- the machine must be able to contact the FOG server
- the machine must be able to contact the CAPE server
- the machine must not be able to reach anything else in your network
For the sake of simplicity I’ll skip the steps to set up a Windows machine and come straight to the point where it gets FOGgy!
Once an analysis is finished, our CAPE server will create a task within our FOG server to initialize a reboot of our analysis machine and to kick off the reimaging process. So the first step is to make sure, that we are able to reach our FOG server via PXE. To check this, we’ll boot our machine into its BIOS and make sure PXE boot is the first option. Don’t worry, if there are no FOG tasks for our host it will boot from disk so this setting doesn’t hurt.
Once you changed this and you configured your DHCP server correctly you should be greeted with the following screen at boot time:
As you can see our host is not yet registred with FOG so we choose the option Quick Registration and Inventory.
If we now open our FOG server and navigate to Hosts > List all Hosts our machine magically appeared:
The next step we have to do, is to create an image so we can record our host for the first time. We navigate to Images > Create New Image and add some informations. Make sure you are targeting the correct operating system since this information tells FOG which partitions to image!
Once we are done, we head back to our Hosts section and click on our host to rename it to something more readable and add the image to it.
That’s it for now with the FOG server part. We now boot up our analysis machine normally to do some further steps, namely installing Python, install some dependencies for the CAPE Agent and install our FOG Client.
Install Python 3.7.9
Download the x86 version of Python and install it and make sure you add Python to your path!
Install CAPE dependencies
You can use an elevated CMD to install choco.bat to install those dependencies but in my case it didn’t work as expected and hung after installing choco in an endless loop.
My solution was to close the elevated CMD window and execute the following commands one at a time once again in a elevated CMD:
choco install -y dotnetfx dotnet4.7.2 vcredist-all wixtoolset msxml4.sp3 msxml6.sp1
pip3 install pillow pywintrace
Download CAPE agent.py
In order for our CAPE server to communicate with this analysis machine some sort of agent is neccessary so we get it from the official GitHub repository.
Great, we now have our agent but how can we make sure it runs after rebooting the machine (e.g. in case of restoring the “Known-Good” image)? Scheduled Tasks are your friend! You can use this tutorial to set this up, just add your agent.pyw as program and not eventvwr.msc like in this sample:
Oh, and while we are at it: Given the fact that our machine regularly reboots how can we make sure it gets automatically logged in and our scheduled task kicks off? Regedit is your friend! Please follow the steps outlined here to set this up.
Once you are finished, it’s time to test your creation and reboot the analysis machine. It should automatically log in and there should be some Python processes already running:
If you want to double check, fire up cmd and run “netstat -ano” and look for a process listening on port 8000 (your agent):
After all these steps there is one last thing to install before we create an image of our analysis machine. Install the FOG client. To do so, open up a browser in your analysis machine and open the website for your FOG management. There will be a button at the left bottom called “FOG Client”:
We then choose the “Smart Installer” and start the setup:
Just change the server address and you should be good to go:
If you followed me until this point you are one brave alpaca warrior! There’s one thing left to do inside the analysis machine: Point the DNS and Gateway to your CAPE server! This means that you will be unable to connect to the internet from this machine unless an analysis is carried out (Some CAPE rooter voodoo magic!) so make sure you have all updates installed, Windows Firewall deactivated and turned off Windows Defender.
It could then look something like that:
You are now entitled to access Level 4 — Image your creation!
Level 4 — Image your creation
Head over back to the web interface of your FOG server to the tab hosts and click that tiny orange icon:
This creates a task which will be picked up by our analysis machine once it reboots. So we now reboot our analysis machine and let it boot from network:
It should automatically start recording our image:
Once the recording is done the machine should automatically reboot back into windows and is ready to receive malware samples! You may now proceed to meet the final boss — Configuring CAPE for physical analysis!
Final — Configuring CAPE for physical analysis
Phew, you made it this far? Congratulations! We are almost finished!
We now need to edit some CAPE specific configuration files and the first is cuckoo.conf itsself. You can normally find it under /opt/CAPEv2/conf/cuckoo.conf.
Make sure that machinery is either multi (if you are planning to use analysis VMs additionally to your physical machine) or physical. In our sample we stick with “physical”.
Another thing we have to change, since we are setting it per machinery is the resultserver.:
The next thing we need to edit is our physical.conf which is in the same folder as cuckoo.conf:
You may now think “Wow why didn’t he till me about the API keys earlier? I could have noted them instead of thinking about those damn alpacas!” The reason is: There is none, I just forgot to mention it. Mea culpa! Anyways, since you are almost a sandbox ninja retrieving those keys should be a piece of cake for you. Just head over to your FOG web interface and visit the two URLs mentioned in the config:
They key you find here has to be added unter “apikey”. The other key (user_apikey) can be found under Users:
For every analysis machine you are planning to use, you have to add a corresponding section to physical.conf as you can see in one of the screenshots. Just make sure to change the ip and resultserver_ip to your needs!
After saving physical.conf make sure to restart CAPE so it picks up your changes
sudo service cape restart
Now you can try to run your first analysis. If everything works well you should see changes on your physical machine and after some minutes it should automatically reboot and restore your image.
One thing to keep in mind is the fact that a physical analysis takes longer than a virtual due to the fact that the machine has to be restored from an image after every analysis and it’s not enough to just restore a VM snapshot.
I hope you liked this post and it helped you setting up CAPE in general! If you have any questions, feel free to shoot me a message on Twitter!