WEBVTT

00:00:00.440 --> 00:00:02.080
Now let's discuss sandboxes.

00:00:02.080 --> 00:00:06.680
They are usually not running on the protected endpoint. The reason being

00:00:06.690 --> 00:00:10.860
that sandboxes require a considerable amount of CPU and memory because they

00:00:10.870 --> 00:00:13.350
run on top of a full‑blown operating system.

00:00:13.840 --> 00:00:16.280
In order to analyze code inside a sandbox,

00:00:16.290 --> 00:00:20.500
most antivirus and EDR solutions will upload the code to the cloud,

00:00:20.940 --> 00:00:24.250
which will in turn run the sample inside the sandbox.

00:00:24.560 --> 00:00:29.370
In contrast to how emulation works, sandboxing actually runs the code.

00:00:29.370 --> 00:00:32.350
Artifacts are collected during execution in the cloud.

00:00:32.350 --> 00:00:36.140
And if analysis of these artifacts reveals malicious behavior,

00:00:36.260 --> 00:00:40.000
the cloud service will notify the antivirus that the file is malicious,

00:00:40.010 --> 00:00:42.450
which can in turn take appropriate actions.

00:00:43.540 --> 00:00:46.360
This is what sandboxing looks like at a high level.

00:00:47.040 --> 00:00:51.560
The antivirus sends a sample to the sandbox, which will usually be cloud‑based.

00:00:52.040 --> 00:00:54.810
The sandbox runs the code, collects artifacts,

00:00:54.810 --> 00:00:57.310
and returns them to the antivirus,

00:00:57.320 --> 00:01:01.060
which can then make the decision on whether to block the code or not.

00:01:03.240 --> 00:01:05.760
Let's now take a closer look at sandboxes.

00:01:06.640 --> 00:01:09.050
As explained, they are usually cloud‑based,

00:01:09.050 --> 00:01:13.170
and several antivirus or EDR solutions have their own sandboxes,

00:01:13.170 --> 00:01:16.260
which they can use to perform dynamic analysis.

00:01:17.240 --> 00:01:20.910
For the purpose of this demonstration, I chose to use Joe Sandbox,

00:01:20.910 --> 00:01:22.550
which is web‑based.

00:01:22.550 --> 00:01:25.130
I uploaded the shell code runner,

00:01:25.140 --> 00:01:29.260
which we wrote during the Meterpreter Deep Dive module to Joe Sandbox.

00:01:30.340 --> 00:01:33.310
There are many configuration options that we can modify.

00:01:33.530 --> 00:01:37.020
I just used the default settings and started the analysis.

00:01:37.540 --> 00:01:38.560
Once completed,

00:01:38.570 --> 00:01:42.400
we can open the report. Surprisingly, the sample

00:01:42.400 --> 00:01:44.450
was not considered as malicious.

00:01:45.440 --> 00:01:49.500
If we scroll down a bit, we will find the behavior graph where we can

00:01:49.500 --> 00:01:52.450
indeed see the connection to our Metasploit handler.

00:01:52.730 --> 00:01:54.270
If we scroll down further,

00:01:54.420 --> 00:01:58.570
we can see the URI which our stager attempted to connect to.

00:01:58.860 --> 00:02:01.120
We can also see the modules which were loaded

00:02:01.120 --> 00:02:03.160
dynamically by the shell code runner.

00:02:03.540 --> 00:02:07.370
You may recall that the stager does make use of the wininet module to

00:02:07.370 --> 00:02:12.220
communicate over HTTP. Further down, we can see the memory allocations which

00:02:12.220 --> 00:02:16.260
were performed. You may recall that we do allocate a read,

00:02:16.260 --> 00:02:19.110
write, execute memory buffer for our stager.

00:02:19.940 --> 00:02:22.630
If we go down even further, we can find a section

00:02:22.630 --> 00:02:24.750
containing code which was executed.

00:02:25.020 --> 00:02:26.100
If we look closer,

00:02:26.140 --> 00:02:29.910
we can see that the sandbox was able to figure out which APIs

00:02:29.910 --> 00:02:32.560
were resolved at runtime by our stager.

00:02:33.240 --> 00:02:38.070
We can see the ROT13 hash for the LoadLibraryA API being passed

00:02:38.080 --> 00:02:42.510
to the asn_block_api function, which we discussed during the

00:02:42.520 --> 00:02:46.770
Meterpreter Deep Dive module. In this example, we uploaded the

00:02:46.770 --> 00:02:48.550
file manually to the sandbox.

00:02:48.940 --> 00:02:52.380
A real antivirus or EDR would, of course, do this on the

00:02:52.380 --> 00:02:55.950
fly without user interaction. Sending every file being

00:02:55.950 --> 00:02:58.210
written to disk into a sandbox, however,

00:02:58.220 --> 00:02:59.500
would not be feasible.

00:02:59.860 --> 00:03:00.520
Therefore,

00:03:00.530 --> 00:03:03.760
most solutions will resort to using a sandbox if a file is

00:03:03.760 --> 00:03:07.450
unknown or if it looks suspicious when analyzed statically.

00:03:07.800 --> 00:03:10.650
Sandboxes do not have the same performance constraints as

00:03:10.650 --> 00:03:13.050
emulators since they are cloud‑based.

00:03:13.440 --> 00:03:15.790
The fact that they are usually cloud‑based, however,

00:03:15.800 --> 00:03:19.860
comes with many disadvantages, which we will discuss later on in the course.