Now let's discuss sandboxes.
They are usually not running on the protected endpoint. The reason being
that sandboxes require a considerable amount of CPU and memory because they
run on top of a full‑blown operating system.
In order to analyze code inside a sandbox,
most antivirus and EDR solutions will upload the code to the cloud,
which will in turn run the sample inside the sandbox.
In contrast to how emulation works, sandboxing actually runs the code.
Artifacts are collected during execution in the cloud.
And if analysis of these artifacts reveals malicious behavior,
the cloud service will notify the antivirus that the file is malicious,
which can in turn take appropriate actions.
This is what sandboxing looks like at a high level.
The antivirus sends a sample to the sandbox, which will usually be cloud‑based.
The sandbox runs the code, collects artifacts,
and returns them to the antivirus,
which can then make the decision on whether to block the code or not.
Let's now take a closer look at sandboxes.
As explained, they are usually cloud‑based,
and several antivirus or EDR solutions have their own sandboxes,
which they can use to perform dynamic analysis.
For the purpose of this demonstration, I chose to use Joe Sandbox,
which is web‑based.
I uploaded the shell code runner,
which we wrote during the Meterpreter Deep Dive module to Joe Sandbox.
There are many configuration options that we can modify.
I just used the default settings and started the analysis.
Once completed,
we can open the report. Surprisingly, the sample
was not considered as malicious.
If we scroll down a bit, we will find the behavior graph where we can
indeed see the connection to our Metasploit handler.
If we scroll down further,
we can see the URI which our stager attempted to connect to.
We can also see the modules which were loaded
dynamically by the shell code runner.
You may recall that the stager does make use of the wininet module to
communicate over HTTP. Further down, we can see the memory allocations which
were performed. You may recall that we do allocate a read,
write, execute memory buffer for our stager.
If we go down even further, we can find a section
containing code which was executed.
If we look closer,
we can see that the sandbox was able to figure out which APIs
were resolved at runtime by our stager.
We can see the ROT13 hash for the LoadLibraryA API being passed
to the asn_block_api function, which we discussed during the
Meterpreter Deep Dive module. In this example, we uploaded the
file manually to the sandbox.
A real antivirus or EDR would, of course, do this on the
fly without user interaction. Sending every file being
written to disk into a sandbox, however,
would not be feasible.
Therefore,
most solutions will resort to using a sandbox if a file is
unknown or if it looks suspicious when analyzed statically.
Sandboxes do not have the same performance constraints as
emulators since they are cloud‑based.
The fact that they are usually cloud‑based, however,
comes with many disadvantages, which we will discuss later on in the course.