Chapter 4: A Word on Automated Sandboxing

In the last chapter, we discussed utilizing PowerShell to automate some of the common tasks for incident response and triage related to malware. As we learned, utilizing scripting can greatly assist an analyst in collecting pertinent information and making informed decisions quickly.

In this chapter, we'll take those ideas one step further, and examine some of the common fully automated, public, or private malware analysis frameworks that are available to us as analysts and that may speed up our triage even further – without even committing time to scripting for each incident.

We'll examine the IOCs we can collect with a known sample of malware, and then present a challenge at the end of the chapter to test your knowledge gained against a real-world sample of ransomware!

In this chapter, we'll discuss the following topics:

• Using HybridAnalysis
• Using Any.Run
• Installing and using Cuckoo Sandbox
• The shortcomings of automated analysis tools

Technical requirements

• An Ubuntu 18.04 VM with 100 GB of disk space and 4 GB of RAM
• An internet connection
• The malware sample pack from https://github.com/PacktPublishing/Malware-Analysis-Techniques

Using HybridAnalysis

HybridAnalysis is an automated sandbox offering from CrowdStrike utilizing their Falcon Sandbox technology in order to perform rapid triage of malware samples and provide IOCs to analysts.

Navigating to https://hybrid-analysis.com presents us with the following screen:

Figure 4.1 – The HybridAnalysis home page

Here, we can drag and drop a malware sample to be analyzed by the engine. We'll drag our WastedLocker/Locky sample onto the window and begin:

Figure 4.2 – The submission page for HybridAnalysis

After submitting our sample, we'll see the name of our file and have the option to add a comment for the community, as well as a few other options, including one to not submit to any unaffiliated third party.

As with any online, public sandbox, the file will be available to the community as well as CrowdStrike, who owns the HybridAnalysis sandbox, and is shared for intelligence purposes.

Once we solve the corresponding reCAPTCHA and agree to the TOS, we can begin the process by clicking the Continue button:

Figure 4.3 – Here, we can alter our detonation options in HybridAnalysis

As you can see, HybridAnalysis presents us with several options to customize the detonation of our malware sample. We'll go through these one by one to ascertain what the usage may be of these options.

Runtime duration

This selection allows us to alter the total time for which the sandbox runs. This can be quite useful, because some malware authors utilize long sleep times within their code in order to bypass automated sandbox analysis or confuse analysts.

With long sleep times, the malware will wait for extended periods of time without performing any malicious actions, hoping that processes watching them or analysts with short attention spans will move on and miss the malicious activity taking place.

Customizing the command line

Here, we are able to specify certain command-line switches that may be necessary in order to ensure proper detonation of our malware.

Analysis tip

When executing a malicious DLL, it's possible to specify which exported function we would like to call. In instances such as this, the command line would be something like 'RunDLL32.exe Malicious.dll, maliciousFunction1'. It is in instances such as these where having the ability to customize the command line comes in handy.

This could be specific DLL functions, or even command-line arguments that we are aware of that the malware requires in order to run properly.

Documenting a password

Here, we can specify a password for an encrypted Microsoft Office document. Recently, several phishing campaigns have utilized encrypted Excel workbooks with the password specified in the email that is sent to the target. Of particular interest, DOPPEL SPIDER has been utilizing this method to send Dridex!

Environment variables

We can also alter environment variables. This may be useful if we want to alter the normal execution flow of the malware that we are sampling. For instance, malware often writes to %LOCALAPPDATA% – we could alter this environment variable to point elsewhere, should we so choose.

Customizing the date/time

Here we can specify a specific system time to be utilized when detonating the malware. This may be useful if the malware has a built-in date kill switch that prevents it from executing after a date or time specified by the malware author.

Checkbox options

Here are some further options. We will leave these as their defaults, but they allow the option to route traffic via TOR, if the malware refers to .onion domains, as well as options to enable the evasion of anti-analysis features of malware. We will cover these in more detail in Part 2: Chapter 6, Advanced Dynamic Analysis:

Figure 4.4 – Here, we can select an OS and architecture for our malware analysis

After selecting our options and proceeding, we are presented with an opportunity to select the environment we would like to detonate in – be it Windows, Linux, or Android. In this instance, we'll stick with Windows 7 64-bit, and proceed to click Generate Public Report, which will begin our analysis and do just that.

Once the analysis is complete, we'll be dropped at a page with a generated report:

Figure 4.5 – The initial report from HybridAnalysis

The first portion of the page will show a brief risk assessment pane, outlining that our malware sample POSTS to a web server, as well as reading the unique machine GUID, and contacts 11 domains, which map to 5 separate IP addresses:

Figure 4.6 – The indicators that are likely malicious, as flagged by HybridAnalysis

Here, we can see a brief overview of malicious indicators that the HybridAnalysis platform has identified. First, it appears that the sample has contacted known Locky malware domains, triggering Suricata rules built into the HybridAnalysis framework:

Figure 4.7 – Suspicious, but not outright malicious, indicators as flagged by HybridAnalysis

Moving further down the page, some suspicious indicators are outlined, including a possible anti-analysis feature within the sample, as well as a suspicious domain contacted in the .su TLD – the defunct Soviet Union:

Figure 4.8 – Indicators classified as informational by HybridAnalysis

Moving past suspicious indicators to those HybridAnalysis has tagged as informational, we can see that the malware appears to be contacting randomly generated domains – a likely malicious indicator. It also lists the IP addresses that are contacted by the malicious sample – Locky C2s:

Figure 4.9 – Static file information in HybridAnalysis

Once we have finished reviewing the highlighted indicators, we begin getting into the static file metadata provided by HybridAnalysis. We can see the SHA256 checksum, as well as the type of file – in this case, a Windows PE EXE file.

Near the bottom of the static information pane, we can also see a file that the malware purports to be, Advanced Task Scheduler 32-bit, which it most certainly is not:

Figure 4.10 – The file sections and their entropy

Scrolling down, we can also see the sections within the PE format (which we will cover in depth in Part 2: Chapter 5, Advanced Static Analysis – Out of the White Noise). Here, we can review the entropy of each section, which may indicate the use of a packer to obfuscate the code.

Analysis tip

Entropy, in both astrophysics and computer science, refers to the level of randomness within a closed system. In this case, the closed system is the section of the PE containing data. A high level of randomness – or entropy – correlates with a high probability that a program has been utilized to obfuscate the code within a section to evade detection.

In the aforementioned chapter, we'll cover packers in depth, but for now it is sufficient to know that high entropy correlates directly with the use of a packer, as in this case:

Figure 4.11 – DLL imports and their corresponding Windows API calls

Nearing the bottom of the page, we are shown what DLLs are imported by the executable, and what functions the malware is importing from those DLLs. We will cover this in greater depth later in Section 2, Chapter 6, Advanced Static Analysis.

This is a valuable piece of information and may assist us in understanding what functionality this malware has via the Windows API. For example, in this instance, we see an import of CreateServiceW from ADVAPI32.dll, which may indicate a possible persistence mechanism in the form of an installed service! Finally, we are presented with a world map overview of network connections:

Figure 4.12 – A Geo-IP world map of network connections made by the sample

In this instance, we can see many connections made to the Russian Federation via France, as indicated by Geo-IP information. We can also review the previously outlined network connections and POST requests made by the sample to these servers – the ones that tripped the previously outlined Suricata rules.

As shown, HybridAnalysis provides a wealth of information very quickly that may be of significant use to an analyst who is unable to quickly perform triage on their own or who needs a pre-defined report that is easily shareable for collaboration with other analysts.

However, HybridAnalysis is not the only public sandboxing platform available. In the next section, we will take a look at another popular option.

Using Any.Run

Another very popular choice among malware analysts for the automated detonation of malware is Any.Run, located at https://app.any.run. Navigating to the page for this, the browser will present the following home page:

Figure 4.13 – The Any.Run home page

Any.Run has a very polished home page, with a heatmap showing the sources of detonations, interesting samples, trending malware families, and other information. In the upper left-hand corner, we have the ability to start a new task and detonate our sample. One key difference is that we must create an account on Any.Run in order to make use of the detonation sandbox.

Once our account is created, we may begin to detonate our sample by clicking the New Task button:

Figure 4.14 – The new task pane in Any.Run

Once we click to begin the task, we are presented with the name of the file, and a warning that this submission will be shared publicly, as is the case with HybridAnalysis. Unfortunately, we are unable to change our platform, as this is a premium feature of Any.Run requiring a paid subscription.

Clicking Run will move the process along, giving one final warning that this is a publicly accessible sample and requiring our acknowledgement of this fact:

Figure 4.15 – The required terms of service agreement for Any.Run

Once acknowledged, Any.Run will begin spinning up a new Windows 7 instance for our malware sample to detonate, which may take a few minutes to complete:

Figure 4.16 – Any.Run attempting to create a new VM for our detonation

Once the instance is successfully created, we will be presented with a live view into the detonation of our malware, and shown a Windows 7 Desktop, with IOCs populating as they are generated by the malware:

Figure 4.17 – The Any.Run detonation screen

Here, we can watch for new information about the malware as it pours in during the detonation process.

Analysis tip

In Any.Run, this is not simply a video of the desktop in real time. It can be interacted with if necessary! Try moving your mouse and clicking on things during detonation. You'll find that you can utilize the remote system as if it were a VNC connection for the duration of the sandbox life.

Near the bottom of the screen, we can already see some network traffic that corresponds with what we have seen previously within HybridAnalysis:

Figure 4.18 – Malicious network indicators and dropped files in Any.Run

Several requests to servers have tripped Suricata rules once more. Also available is a pane on the left that would outline any files written to the system and their filesystem locations, if applicable.

Shifting our gaze to the upper-left corner of the window, we see several other options and information available to us:

Figure 4.19 – Community tags, sample button, and process tree within the Any.Run UI

Here, we can see a process tree that would nominally include any processes spawned by the malware, as well as options to download a sample, and access a report. Also available are tags assigned to this sample by the community – in this case, the community has correctly identified this sample as Locky.

Reviewing the process tree, we do not appear to have achieved full execution of our sample. This is likely a result of long sleep times and the limited time allotted to us by Any.Run as part of our free membership.

Once the malware has completed execution, or the pre-defined sandbox life has expired, a report on the IOCs and static details of the file will be generated and can be accessed by utilizing the Text Report button shown in the following screenshot:

Figure 4.20 – The high-level overview within the Any.Run report

Beginning at the top of the report, Any.Run presents a concise list of indicators, which is slightly more condensed and valuable than those presented in HybridAnalysis. Here, we can see that the malware contacts known C2s for Locky, changes console tracing settings for Windows, and attempts to connect directly to a raw IP without utilizing DNS:

Figure 4.21 – Static binary information in Any.Run

Moving down the page, we can see some static information on the binary, including some information we have not seen before in HybridAnalysis. TRiD information is available, which will tell us what type of file we are dealing with. In this case, it appears to be a compiled Microsoft Visual C++ executable PE.

Additionally, we have some of the information we have seen previously, including the purported publisher and development information, as well as versioning and subsystem information – in this case, the Windows GUI subsystem:

Figure 4.22 – PE Sections information in Any.Run

In the next section, we are presented again with the PE's section information, including entropy as in HybridAnalysis. We also have DLL import information here, but unfortunately, we are not shown what functions are called from each imported DLL, somewhat negating the usefulness of this information:

Figure 4.23 – Malicious registry operations within Any.Run

Moving along, we can see registry changes that were not apparent in HybridAnalysis. These disable console tracing via Windows, as well as disabling the built-in proxy settings in a possible attempt to evade detection via outbound proxy rules:

Figure 4.24 – Network connections and triggered Suricata rules

Finally, the network details section shows all HTTP requests made by the malware, as well as the IPs that were connected to, their corresponding autonomous system number, and the country the IP is associated with. Here, we can also see the request that triggered the Suricata rules in both HybridAnalysis and Any.Run.

Now that we've covered some of the publicly available sandboxing options, let's take a look at one of the more popular on-premises choices.

Installing and using Cuckoo Sandbox

As we have seen, public analysis tools are incredibly useful, and provide a wealth of information, though not every tool provides the same information. One weakness of public sandboxing utilities and public analysis tooling in general lies within the classification: they are public.

Because these tools are public, it is possible for either the owner of the sandbox or the community at large to access samples that may contain valuable internal information related to your employer's environment.

As a result of this, many companies prefer to not submit malware samples to public sandboxes and have instead elected to build their own sandboxing platform with the open source software Cuckoo, which is available for macOS, Linux, and Android. The Cuckoo platform consists of a *nix server, and a customized, vulnerable Windows 7 VM that will be spun up on demand in order to detonate malware.

In the next few sections, we'll examine what the process for preparing and installing Cuckoo Sandbox looks like and walk through it together.

Cuckoo installation – prerequisites

Unfortunately, one of the shortcomings of Cuckoo installation is that it requires a lot of configuration and can require an entirely separate skillset to correctly install and maintain.

Thankfully, much work has been done on this by analysts and systems administrators responsible for creating Cuckoo environments, and we can utilize their work to avoid reinventing the wheel or struggling with the installation process. To this end, we'll utilize the author's work from https://hatching.io/blog/cuckoo-sandbox-setup/ to complete setting up our Cuckoo environment.

As outlined in the Technical requirements section, you will need a few things:

• An Ubuntu 18.04 VM, with at least 4 GB of RAM and 100 GB of HDD space
• A Windows 7 ISO

  Analysis tip

  Now is a good time to ensure you've enabled VT-x, or nested hypervisors on your Linux VM. It'll be necessary to run Cuckoo going forward! This is usually found in the CPU configuration for your VM platform.

With your Ubuntu 18.04 machine running and ready to receive commands, we may proceed with installing the prerequisite software packages with the help of the following command:

sudo apt install –y python virtualenv python-pip python-dev build-essential

This command will take a few minutes to process, depending on the speed of your internet connection:

Figure 4.25 – Installing our prerequisite packages

Once completed, a user should be added with the username cuckoo via the following command:

sudo adduser --disabled-password --gecos "" cuckoo

Here is the output:

Figure 4.26 – Creating the Cuckoo user

Since Cuckoo will need to be able to capture packets off our virtual wire, we'll need to grant it a group and permissions to do so via the following series of commands:

sudo groupadd pcap

sudo usermod -a -G pcap cuckoo

sudo chgrp pcap /usr/sbin/tcpdump

sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump

Figure 4.27 – Setting permissions for the Cuckoo user for PCAP

Now, before we begin Cuckoo installation, we will need to acquire a Windows 7 ISO. Thankfully, we can acquire one easily from the https://cuckoo.sh site.

We can utilize the built-in utility WGET to acquire this file:

wget https://cuckoo.sh/win7ultimate.iso

Figure 4.28 – Downloading the Windows 7 ISO via WGET

This will take some time, depending on the speed of your internet connection. Once this is complete, we must create a directory and mount the ISO:

mkdir /mnt/win7

sudo mount -o ro,loop win7ultimate.iso /mnt/win7

Figure 4.29 – Mounting our Windows 7 ISO to /mnt/win7

With our Windows 7 ISO now mounted, we can begin installation in earnest.

Installing VirtualBox

Cuckoo uses VirtualBox to rapidly spin up our host systems for malware detonation. To this end, we will need to download and install VirtualBox on our Ubuntu system. First, we will need to trust the keys from the VirtualBox repositories:

wget -q https://www.virtualbox.org/download/oracle_vbox_2016.asc -O- | sudo apt-key add -

wget -q https://www.virtualbox.org/download/oracle_vbox.asc -O- | sudo apt-key add –

Figure 4.30 – Trusting the applicable keys for the VirtualBox repo

Each of these commands should return OK if successfully completed. Once the keys are trusted, we can add the VirtualBox repositories and get their contents with the following command:

sudo add-apt-repository "deb [arch=amd64] http://download.virtualbox.org/virtualbox/debian $(lsb_release -cs) contrib" && sudo apt-get update

Figure 4.31 – Adding the VirtualBox repository

Once we have the repository added, and the contents enumerated, VirtualBox can simply be installed by means of the following command:

sudo apt install –y virtualbox-5.2

This process will take some time to complete. Once done, it is necessary to add the Cuckoo user we created to the VirtualBox user group, similar to the previous commands for packet capture:

sudo usermod –a –G vboxusers cuckoo

Now that we have successfully added the Cuckoo user to the vboxusers group, we can move on to installing and configuring VMCloak.

Cuckoo and VMCloak

Before installing the final portions, we will have to acquire the prerequisites for these two tools utilizing the following list:

sudo apt install -y build-essential libssl-dev libffi-dev python-dev genisoimagezlib1g-dev libjpeg-dev python-pip python-virtualenv python-setuptools swig

These are quite small packages and should install very quickly. Now it is time to create our Python virtual environment for Cuckoo and VMCloak in order to keep their dependencies isolated from the rest of our system:

sudo su cuckoo

virtualenv ~/cuckoo

. ~/cuckoo/bin/activate

The previous series of commands will change to the Cuckoo user we created, create a virtual environment for them, and activate the virtual environment. From here, we can utilize Python's pip tool to install Cuckoo and VMCloak:

pip install -U cuckoo vmcloak

pip will quickly begin downloading and installing the required packages for both Cuckoo and VMCloak, and when complete, will drop you back at your virtual environment prompt.

Defining our VM

The first step in defining the VM for VMCloak is to create a host-only adapter for the detonation VM to use:

vmcloak-vboxnet0

Once we have created this adapter, we can now tell VMCloak to define our VM with the following command, which will create a Windows 7 VM with our mounted ISO that has 2 GB of RAM and two CPU cores:

vmcloak init --verbose --win7x64 win7x64base --cpus 2 --ramsize 2048

Figure 4.32 – Creating our base Windows 7 VM

This process will take quite a while to complete. Once done, the base VM will have been defined. Because we do not want to alter our base image, we will clone it before installing software that may be useful in a detonation environment.

Analysis tip

You may run into trouble here if you are not running a desktop environment. VirtualBox does not seem to like the idea of running these machines headless. If you have issues, a quick remedy is to install the lubuntu-core package and start the lightdm service, and then go back to the Cuckoo user and virtual environment and try again.

We can run the following command to clone our base image and create a copy specifically for Cuckoo to utilize:

vmcloak clone win7x64base win7x64cuckoo

Now we have successfully created a clone of our Windows 7 box. With our clone, we can now proceed to installing any software we may want. In this instance, we'll install the following tools utilizing this command:

vmcloak install win7x64cuckoo adobepdf pillow dotnet java flash vcredist vcredist.version=2015u3 wallpaper ie11

Analysis tip

It's optional at this point, and we will not cover it, but it is possible to install Microsoft Office in order to be able to analyze malicious documents such as Emotet. You'll need a Microsoft Office ISO and also a valid product key.

Now, we will create snapshots of our created VMs for use with Cuckoo:

vmcloak snapshot --count 4 win7x64cuckoo 192.168.56.101

With our four VMs created, software installed, and ready to go, we can now begin the process of configuring Cuckoo to utilize these VMs.

Configuring Cuckoo

With our VM configured, we can now begin the process of configuring Cuckoo itself. We can start the process with cuckoo init:

Figure 4.33 – Initializing the Cuckoo environment

Cuckoo also needs a database in order to track results. For this, we will utilize Postgres. To install Postgres, we will use the following command:

sudo apt install -y postgresql postgresql-contrib

Once installed, it is necessary to make some configuration changes and create the requisite database for Cuckoo. Issuing the following command will open the Postgres shell:

sudo -u postgres psql

Once the Postgres shell is open, issue the following commands to create the Cuckoo user and database, and give the user the required permissions:

CREATE DATABASE cuckoo;

CREATE USER cuckoo WITH ENCRYPTED PASSWORD 'password';

GRANT ALL PRIVILEGES ON DATABASE cuckoo TO cuckoo;

q

Returning to the virtual environment for Cuckoo, we can now install the Postgres driver for Cuckoo so that it may utilize the database we have just created.

While logged in as the Cuckoo user, run the following command to install the driver:

run pip install pip install psycopg2

Finally, we will edit the file at ~/.cuckoo/conf/cuckoo.conf to reflect the database as shown:

Figure 4.34 – Configuring the use of Postgres within Cuckoo

While in the conf directory, open virtualbox.conf for editing and find the entries under MACHINES containing cuckoo1 and remove them, as we will be specifying our created VirtualBox VMs to be used:

Figure 4.35 – The line that requires deletion in the virtualbox.conf file

Now, we can specify our VMs to use with VMCloak using the following command, which will return our output from VMCloak to the Cuckoo configuration:

while read -r vm ip; do cuckoo machine --add $vm $ip; done < <(vmcloak list vms)

With our VMs set up, we can now install the community rules for Cuckoo using the following command:

cuckoo community --force

Here is the output:

Figure 4.36 – Importing our VMCloak VMs into Cuckoo

With Cuckoo now configured to utilize the VMs that have been created, we can take a look at some final configuration steps for Cuckoo that will assist us in the detonation of our malware and ensure that we gain a complete picture of the activities taking place.

Network configuration

As a rule, in malware analysis, it is best to detonate malware without internet connectivity if possible. However, some malware requires an internet connection to detonate successfully, and this is becoming more common, as an always-on internet connection in our homes and business becomes more ubiquitous.

To this end, we will give ourselves both the option to detonate with and without internet connectivity. To do so, we will first need to configure forwarding for our interfaces. Replace eth0 in the following lines with the name of your interface, as shown in ip addr:

sudo sysctl -w net.ipv4.conf.vboxnet0.forwarding=1

sudo sysctl -w net.ipv4.conf.eth0.forwarding=1

With this step complete, we can now utilize Cuckoo's rooter to create the applicable permissions for the Cuckoo group:

/home/cuckoo/cuckoo/bin/cuckoo rooter --sudo --group cuckoo

This process must continue to run and will act as a sort of proxy for Cuckoo to route traffic, since it does not have adequate permissions to do so in its virtual environment. To finish setting up our internet connection, open a new console and navigate to the Cuckoo virtual environment once more. Once there, open the ~/.cuckoo/conf/routing.conf file for editing:

Figure 4.37 – Configuring our interfaces for internet routing within Cuckoo

Find the line beginning with Internet and replace none with the name of your internet interface you retrieved from the output of ip addr.

Cuckoo web UI

At this point, Cuckoo is configured and ready to use, but would require use via the CLI. However, we can utilize the web interface for a more friendly experience. The web server requires MongoDB, so we will install that first:

sudo apt install –y mongodb

With MongoDB installed, we can specify the enabling of MongoDB reporting in the ~/.cuckoo/conf/reporting.conf file from within our Cuckoo virtual environment:

Figure 4.38 – Enabling the MongoDB interface within Cuckoo

With these changes made, the web server can now be started. If you would like to be able to access your Cuckoo instance from the host machine, replace 127.0.0.1 in the following command with the internal IP of the Ubuntu VM, as shown in the output of ip addr. Like the rooter process, this process must remain running in order for the web UI to work:

cuckoo web --host 127.0.0.1 --port 8080

With all configuration in place, and the web server running, open one more terminal and navigate to your Cuckoo virtual environment. We can now start Cuckoo with the following command:

cuckoo --debug.

With all three processes running, you should now be able to navigate to the IP you chose and be greeted with a Cuckoo home page:

Figure 4.39 – Cuckoo's home page!

Running your first analysis in Cuckoo

Clicking the SUBMIT A FILE FOR ANALYSIS button will allow you to upload a file to your Cuckoo UI and begin selecting options to analyze the file:

Figure 4.40 – The analysis options presented to us within Cuckoo

As you can see, we have the option within the UI to utilize an internet connection or simply drop the internet traffic with no connection. We can also specify how long to allow the file to run and select which VM we would like to detonate the malware sample on!

To upload my Locky sample, I utilized a long detonation time and an internet connection. Once submitted, you will be greeted with a processing page that refreshes every 2.5 seconds:

Figure 4.41 – The pending results page within Cuckoo following submission

Shortcomings of automated analysis tools

As you have probably gleaned by now, automated analysis tools are excellent for the initial analysis of a malicious sample and can provide a wealth of information in a brief period of time.

However, these automated analysis tools are not without their shortcomings. First, they are often reliant on signatures and heuristics to detect malicious activity and cannot apply the knowledge of a seasoned malware analyst to a sample. Put simply, they are still machines and their classifications are not always correct. They also may not be able to react to certain sample conditions, such as the usage of analysis evasion techniques, or packed samples.

Some shortcomings of public tools are addressed by private, own-infrastructure sandboxing utilities such as Cuckoo, but these often introduce other problems, such as infrastructure to run the sandboxing framework and the cost of people maintaining it.

It's important to keep in mind that while these are valuable tools in our inventory as analysts, they should not be the only tools in our inventory, and we should understand fully their limitations and what they are doing to obtain their results.

Challenge

Utilizing your newly minted Cuckoo VM and the Locky sample, attempt to answer the following questions:

1. Are there any anti-analysis tricks that are being utilized by the sample? If so, which ones?
2. Is the sample packed? If so, what is indicative of the use of a packer in the sample?
3. If the sample is packed, what is the SHA256 of the unpacked sample?
4. Are there any other suspicious indicators in the process or its memory? If so, what are they?

Summary

In this chapter, we have discussed the many benefits of automated analysis frameworks, including those offered publicly and those that require setup and hosting in your own environment. We have examined two great public examples, HybridAnalysis and Any.Run, as well as an excellent open source alternative – Cuckoo.

With the knowledge gained in this chapter, you should be able to draw your own conclusions about the benefits and drawbacks associated with utilizing automated analysis frameworks, and how valuable they can become in triage and in responding to an incident.

This chapter concludes the first half of the book, and we'll pick up in the second half with advanced static analysis, taking a deep dive into the PE file format, file metadata, and structure, among other interesting topics.

I'd encourage you to test both your knowledge of this chapter and your Cuckoo VM by utilizing the preceding question section.