Playing in Sandboxes

For researchers getting into malware analysis, or organizations that need somewhere to test suspicious files, sandboxes are a great way to isolate and run potentially malicious attachments or files before letting them get into your network. You can use any of the available cloud services like Cisco’s ThreatGrid, any.run, or Joe Sandbox. The downside to the cloud offerings is a limited amount of analysis tasks without paying for a subscription, and those can get expensive quickly.

My solution was to build my own, in my apartment. I have an Intel NUC in my homelab (NUCi5BNH, 600GB SSD total storage, 16GB RAM) that has more than enough horsepower to run the sandbox. After talking to Joey Muniz (www.thesecurityblogger.com) from Cisco, he convinced me to run the Cuckoo sandbox for all of my needs. It is open source and easily extensible for any additional modules I want to build for it.

So how did I build it?

First you need a base OS. Cuckoo is based on Python, so it can run on pretty much anything. I wanted a lightweight OS, and am extremely familiar with ArchLinux from my Raspberry Pi Supercomputer, but it would take too much effort to get all the libraries needed set up. To keep it simple (and easily supported) I chose the Ubuntu 18.04 distro (90GB storage, 8GB RAM, 2xCPU). I spun up an Ubuntu VM on the NUC in ESXi, and created an OVF so I could quickly deploy Ubuntu again if needed.

Next up was installing all the supporting libraries needed for Cuckoo. These include VirtualBox, PostgreSQL, MongoDB, tcpdump, Yara, Volatile, among others. Just follow the Cuckoo install docs which are very well written and include instructions for all of these libraries.

Building the Host

You have to build a VM within the Ubuntu VM to virtualize the actual host that will get infected, and create a clean snapshot for Cuckoo to spin up. I chose an x64 install of Windows 7 (32GB storage, 2GB RAM, 1CPU). To allow it to talk to the Cuckoo software, install Python and copy the agent.py from the Cuckoo directory on the Ubuntu host into the startup directory on the Windows host. Don’t forget to disable UAC, Windows Update, Windows Defender, and the Firewall. You want this machine to be intentionally vulnerable. There’s no point in dumping malicious software in there if its just going to be flagged immediately. If you want to be able to pull screenshots from the host, install the Python Pillow package.

Also take this time to install any other software you want to test. I installed old versions of Adobe Reader and Microsoft Office as well.

Once its up and running, create a snapshot in VirtualBox titled “Clean”, and its ready to go.

Test it!

To make sure everything is working properly, start the Cuckoo web server and upload some malware! The first thing I loaded was the WannaCry ransomware that ran fully and gave me some screenshots as well as behavioral analysis. Images below:

What’s next?

I’m planning on deploying this within my company’s environment so we have an on-prem sandbox that costs significantly less than cloud offerings. I’m also modifying it to run in AWS and Azure, though that will take much more work.

I’m also hoping that my company’s IT department will give me a copy of the Win10 image we load onto all of our enterprise laptops so I can run that within the Sandbox and get much more detailed information about how malicious software will react in our specific environment.

One of the biggest issues I’ve run into so far is malware that can detect sandboxing. I’m trying to find a workaround or modify the Win7 host to hide evidence that its a sandbox.

If you use VirtualBox or ESXi to virtualize software, let me know and I can send you the OVF for a turnkey deployment of Cuckoo with minimal effort needed.

 

 

2 thoughts on “Playing in Sandboxes

  1. Do you know in general what percentage of malware bothers to check if it’s being sandboxed? It seems like it would be pretty trivial to check for the existence of the common python script. Would simply renaming or adding comments to the script to change the hash help to avoid malware that is trying to detect sandboxing?

    Liked by 1 person

    1. Multiple ransomware variants run sandbox checks prior to execution. For malware as a whole, I’m not sure. When I loaded the Locky Ransomware into this sandbox, it didn’t run at all. Many sandboxes work differently, Cuckoo uses a Python agent but ThreatGrid and Joe Sandbox have DLLs loaded that allow them to collect information. Some sandboxes are great at hiding their true nature, but still leave inetsim running, which replies with HTTP 200 Success packets for any attempted outbound communication. WannaCry uses a fake domain name to test for an inetsim. If it gets a 200 response, it doesn’t run.

      My approach is to run potential files through the sandbox a couple of times. The first time I ran WannaCry through it, it didn’t run because it got a successful response from the server, but turning off all network communication made it run.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s