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.

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:

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:

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:

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]:

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.

image23| 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.