Quick and easy malware analysis using Windows Sandbox and Elastic Security
Introduction
If you work in an organization's IT department, a CERT/CIRT, SOC, or just generally in the world of IT or Cyber Security, odds are someone in your organization has downloaded a shady file or received an email with some shady attachments and asked you to analyze them. However, your organization doesn't actually pay for or manage any sort of malware sandbox - or they do manage one, but it's totally busted or completely out-of-date because nobody has been managing it, and thus you don't really have any official means to safely run and analyze that maldoc or executable that was sent your way!
Enter the ever-present issue in the Cyber Security world of needing to detonate malware, but not necessarily having somewhere safe or established to do it within your organization. Your options are typically something along the lines of:
The easiest solutions with the least amount of spin up time are #1 and #4. There's merit in #2 and #3, but it all depends on the organization's needs and the available resources to allocate to these options. It might not be feasible for you to invest development resources into a sandbox for malware analysis.
In fact, my own experience during past Incident Response cases in some of the organizations I've worked at has shown that this is typically not the highest priority during an active engagement since the focus is on getting the client back up and running as soon as possible rather than on dissecting the malware to reveal its inner workings. It's important to understand what the malware is doing, but organizations tend to hesitate when you ask them for $20,000 (random ball park figure) to pay for a malware analysis environment or hire someone who's job is just to do malware analysis (far more than paying for a sandbox).
That being said, you may still find yourself with an interesting piece of malware from a threat actor you've never heard of before and you want to analyze it - but you don't have the resources within your organization to easily do so.
So, how can you quickly put together a safe environment in which to detonate and analyze malware? Look no further than Windows Sandbox and Elastic Security.
I'm going to show you how to combine these resources together to get some quick answers with minimal investment since the entire deployment can be easily created and then destroyed when you're done with it. Additionally, there are a number of handy tools that you can pre-load into your sandbox for manual analysis. A few of my personal choices for this are:
Giant Disclaimer Section
Before proceeding, please be aware that playing with malware of any kind is dangerous and that you should always err on the side of caution whenever handling it. You can easily infect yourself or your corporate environment if you're not careful! Please ensure you're taking steps to isolate yourself from other network devices and that you're never running malware directly on your host operating system. You are ultimately responsible for any malware that you execute knowingly within your environment.
Also, this is not a replacement for a seasoned malware analyst.
Fun disclaimers out of the way, let's keep this train moving!
Windows Sandbox
One of Microsoft's best (worst?) kept secrets in my opinion. I know very few people that have made use of this feature, and quite a few had never even heard of it before I showed it to them. Windows Sandbox has an impressive set of features and is built right into Windows 10 and Windows 11 (Pro versions) by default - it just needs to be enabled, your system rebooted, and you're ready to go. More information can be found over on Microsoft's website here.
I really like Windows Sandbox because of the speed, customization options in the config, and the overall convenience. We'll dive into this more shortly and I'll show you what I mean. However, there is one big potential flaw with Windows Sandbox that you should know before getting started: It does not isolate network traffic from other hosts in the network if it's launched with networking enabled. Keep this in mind when running malware, though if you follow the steps I outline below you'll mitigate this problem anyway. Windows Sandbox will isolate file-based and memory-based operations from your host, but if I run recon tools such as adfind.exe I'll be able to find other systems located on the same network. If you happen to run something that has worm functionality built-in and it finds vulnerable hosts on the network then it can and will spread to them. This is why I generally keep the network adapter disabled in my default config and also ensure that I'm running malware on a system that's isolated from the rest of the devices on my network just to be safe.
Elastic Security
If you've read any of my past articles it should be no surprise to you that I'm a huge fan of Elastic's products. They generally speed up my analysis process quite a bit and allow me to perform large sweeping searches across massive data sets (like searching for any systems where event logs were cleared as an example). The lesser known side of Elastic's products is in regards to Elastic Security, Fleet, and Elastic Agent. The short version of this is that Elastic Agent takes over for Windows Defender and essentially works like an EDR with a number of rules that it runs against ingested data to generate alerts. It's generally really easy to setup in conjunction with Elastic Cloud which is my preferred way to use Elastic products.
Tor
For the sake of anonymity it can be helpful to utilize the Tor network in conjunction with a VPN. I've been experimenting with a program called OnionFruit due to its simplicity and the fact that it routes all applications through Tor once connected. You're free to swap this out for any other solution you prefer or just not use Tor at all - it's completely optional. I recommend at least connecting to a VPN prior to running any malware as your public IP address will still be exposed otherwise if, for example, you run a curl command inside of PowerShell in the Sandbox to lookup your current public IP. It's probably for the best that you avoid leaking your personal IP address - especially if you're working from home.
Getting Started
I've gone over the high level setup, so now we're ready to get started! The first thing you'll need is to make sure you've downloaded all of the tools you want to load up into the Sandbox. See my list above as a reference for getting started! Second, you'll want to download the Windows Sandbox scripts and configs from my GitHub here
Now copy the sandbox-init.cmd and sandbox-init-offline.cmd along with the tools and the zipped / password protected malware into your WindowsSandbox folder, and now you're good to go to launch... well mostly! You're all set if you just want to do offline analysis, but if you happen to want to do the online analysis in conjunction with Elastic Cloud then you have a few more steps.
Setting up Elastic Cloud
I'm going to keep this section short as the process to setup Elastic Cloud is already well documented and fairly straight forward. You don't need a large deployment for this by any stretch, so don't worry about setting up some massive cluster! You will, however, need an Integration Server for Fleet / Elastic Security. The stack I'm using in conjunction with this looks like so:
The hourly rate for this setup on the Gold tier is $0.1810 which equates to approximately $132.00 over a month so not free but certainly not breaking the bank either! Definitely much cheaper than many of the premium sandboxes out there which charge thousands of dollars per month or per year and limit the total number of analysis jobs you can run per month.
Once your deployment is up and running you'll want to login to Kibana and navigate to Fleet > Agents and then click on "Add Agent" on the right. A screen similar to this should pop up:
Essentially, what you'll want to do here is download the agent and then copy it to your WindowsSandbox folder. You'll also need the URL and enrollment-token from the last line which you can replace in the "sandbox-init.cmd" file to allow your agent to connect. NOTE: You want the -f option in the enrollment command so that you skip the Elastic Agent prompt asking you to confirm the enrollment. The installer will hang there if this option isn't included. I've included this in my config by default for convenience.
Now you're all set for the internet-enabled version of the Windows Sandbox! Now it's time to actually run it!
Executing the Sandbox
The two WSB files from my GitHub that you downloaded earlier are the key to launching the Sandbox. They should look something like so on your desktop:
You can edit the config in any text editor so be sure to edit them prior to launching and update the paths to reflect your local system. When ready, double click on the one you'd like to use and you should see the sandbox open in a new window on your desktop.
Offline Sandbox
If you're running the offline version then you'll see a new folder appear on your desktop which contains all of your tools as well as the malware (hopefully zipped and password-protected) that you'll be analyzing. The script is also making a change to the PowerShell configuration so that unsigned PowerShell scripts can run. Finally, 7-zip is being installed in the background for the sake of convenience. From here it's up to you to run and install the tools that you want to use to analyze the malware. Using my example in the sandbox-init-offline.cmd file, you can automate the install of other tools as well to save yourself the time of doing it manually. I'll leave it to you to update your local copy of the .cmd file accordingly.
Internet Connected Sandbox
The version of the sandbox with internet connectivity has more going on in the .cmd file. We're doing everything that was included in the offline version, however when sandbox-init.cmd is run within the sandbox we're also installing the 7-zip PowerShell module, OnionFruit is being installed in addition to 7-zip, the malware "infected.zip" with the password "infected" (customize as needed) is unzipped onto the desktop of the sandbox machine, and finally Elastic Agent is being copied to the desktop so it can be installed as a service and connect back to our Elastic Cloud stack. I chose to do Elastic Agent last so as to minimize the amount of false-positives detected from actions such as unzipping the malware and installing PowerShell modules. Make sure you toggle on OnionFruit on the bottom right to establish the Tor connection if you've opted to use it. Your desktop should look something like the below with the name of the malware in my screenshot replaced with the one you're running:
领英推荐
The great thing about this is that once it's setup you're set for the future! You don't need to do all of this by hand every time, so it'll be much faster going forward. When someone ultimately asks you to run some malware or check a document for them you'll be able to copy it over to your sandbox folder, double click the WSB file and a few seconds later you have a safe environment to check it in.
Meanwhile, back in Kibana
Before you double click that juicy executable file you'll want to head back to Kibana to do a couple of things. First, configure your Elastic Security policy so it's something like the below. Essentially, you want Elastic Security in Detect mode across the board as opposed to Prevent mode. You want the malware to run all the way through so you get as much information as possible about what it's doing. When you're done here, save your policy and it'll apply it to the active Elastic Agent as well as future agents when they're added.
Second, you may want to whitelist some known-good processes like 7-zip and Velociraptor. This can be done by hash under the "Trusted Applications" section. I've done a couple of them as an example for you. Again, this is generally a one-time process so once it's done then you don't need to worry about it going forward unless the versions (and subsequently the hashes) change down the road.
An important step under Elastic Security is enabling the rules. Make sure you navigate into Elastic Security > Rules and install them if they aren't already installed. Then select all of the rules and enable them as shown in the screenshot below. You'll find some are really noisy and may not be overly useful over time, so you'll want to tweak these according to your needs, but when you're just starting out it's a good baseline to have them all enabled.
As a safety mechanism, you may also want to restrict the network traffic on the sandbox. This can be done via Elastic Security by navigating to Elastic Security > Endpoints and selecting the Isolate option under the dot menu next to the endpoint. This way you can still take advantage of Elastic Security and send data to the instance, but not allow network traffic to communicate to external hosts.
Analyzing the Malware
Our setup is complete and everything is up and running so it's time for the fun part - actually analyzing the malware! If you're digging into malware analysis by hand using some (or all) of the tools I've listed here, then have at it! It's outside the scope of this article to cover manual analysis as that is a whole topic of its own. So, we're going to focus our efforts on the internet-enabled sandbox and hopefully get some quick answers to our game of "What the heck does this file do?"
For our example, I've grabbed a ransomware binary from our friends over at Malware Bazaar. I can always count on them to have the latest and greatest malware all designed to ruin your day.
I copied my malware zip file with the password infected into the "WindowsSandbox/Malware" folder on my system prior to launching the sandbox so I already have it on my desktop.
I've confirmed that Fleet and Elastic Security can see the agent within Kibana and that the locally installed agent has the policy I applied (confirmed via Fleet), so now all that's left is to double click on the executable and see what happens...
Well... that's not good. The executable appears to have vanished into thin air, Readme files have popped up onto my desktop and the file extensions of existing files have been changed. It's definitely ransomware alright! If we open up one of the Readme files it looks like this:
I've sanitized the email addresses, but otherwise this is exactly how it looked when I opened it up. This double confirms it's ransomware. And hey, you could totally stop here and tell whomever in your company that you've confirmed it's ransomware and they definitely shouldn't run the file. Job well done and all without putting your own (or anyone else's) system at risk!
But what if we want to go even deeper? It's inception time.
Analyzing in Elastic Security
You won't see any notifications from the installed Elastic Agent, but worry not for it's lurking in the background, capturing all of the data from the malware, and then sending that information back to your Elastic Cloud stack and running your enabled rules against it. You'll get all sorts of information here including IP information if the malware reaches out to any specific IP's or if any command and control servers communicate with your system after running the malware. It's all mapped out for you by geographical location and also shows the data sent/received. You can even build timelines from the data and add contextual information. It's a great tool to have in your arsenal!
Any alerts that have been triggered based on your data will show up under the "Alerts" section within Elastic Security. From here you can dive deeper into what the malware did, whether it dropped anything to disk, get the hashes of all associated files, and even see a process tree breakdown under the "Analyze" option.
One of the main features that I like about Elastic Security is that the UI is pretty streamlined. It gives you the information you need without having to deal with a clunky interface or needing to hunt through sub-menus to find important information such as what the actual command was that a process executed. You can run some malware and within a few minutes have useful information in Elastic Security that will let you dive deeper and gain a firmer understanding of what the malware was doing, whether there was any associated network traffic, and if it did anything sneaky on the system such as dropping additional malware, deleting files, adding methods of persistence, or exfiltrating data as just some examples. And best of all? It's included by default and doesn't involve any cumbersome licensing models or restrictive interfaces. You have the full capability of Elasticsearch on the backend to further search and enrich your data.
Integrations
Did I mention that Elastic Security has a bunch of integrations built into it? I didn't? Well, better late than never I guess! There are a ton of integrations built into the agent by default that covers most of the data sources you can think of. Have a Linux system? No worries! It can install on Linux too and collect data from there as well. You could totally setup a sandbox on a Linux system for Linux malware! If you run a Linux-heavy environment, then this may be a direction you'd want to pursue as well. One of my favorite integrations is in regards to threat intelligence and automatic enrichment of your data.
As of this writing, the screenshot above shows all of the supported threat intelligence integrations. Just add your API keys and fill out any other relevant information, enable them, and voila - you're ready to go! I've tested this out in the past and it's awesome being able to integrate an internal MISP server in conjunction with other threat intel sources to gain further insight into malware - including whether it's already been observed in the wild and any associated reports regarding it. While this won't be the end-all be-all of threat intelligence, it's certainly a massive step in the right direction if your organization doesn't have a solution in-place currently!
Wrapping it Up
Time to wrap this article up!
If you've made it this far and followed along then you're now armed with a sandbox environment that's fast, effective, and (mostly) free. The only "gotcha" here is that you need Windows 10 or 11 Pro versions (which most corporate environments use anyway) and if you want to use Elastic Cloud then there's some associated costs there, though nothing egregious by any means!
I originally opted to use this method because I simply didn't have organizational resources to pay for a private sandbox or to develop and maintain one within the organization, yet I still needed to analyze malware that I discovered during a case so that I could understand what it was doing and provide that information to my team as well as the client to help guide the investigation. You could do something similar in other virtualization platforms such as VMWare, VirtualBox, or using cloud native instances in one of the major Cloud providers as well so feel free to take what I've shown here and make it your own!
I hope this helpful! Be safe when analyzing malware and keep on fighting the good fight. See you next time!
Cybersecurity Leader | Risk Advisor | Privacy Professional
2 年This is a great write up. Sharing with my colleague Dannie Stanley who does a bit of malware research.
Senior Manager, Alliant Cyber
2 年Great writeup! I think so many of us discount that Windows has some cool built-in stuff like the Sandbox.