WEBVTT

00:00:00.740 --> 00:00:04.620
Let's now discuss emulation. Emulation is a technology

00:00:04.630 --> 00:00:07.060
which is used by many antivirus solutions.

00:00:07.940 --> 00:00:11.990
It gives the antivirus a chance to gain some insight into the behavior

00:00:11.990 --> 00:00:15.140
of a piece of code without actually executing it.

00:00:15.480 --> 00:00:18.860
An emulator will try to mimic a real operating system.

00:00:19.300 --> 00:00:23.470
The reason being that if a piece of code calls a given API, the

00:00:23.470 --> 00:00:27.290
emulator needs to ensure that it returns a valid response or else

00:00:27.290 --> 00:00:31.470
the code might not behave as it would on a real system. Artifacts

00:00:31.480 --> 00:00:33.530
are recorded during emulation,

00:00:33.540 --> 00:00:36.480
which can be used to gain insight into what the code

00:00:36.480 --> 00:00:39.160
will do when launched on a real system.

00:00:39.540 --> 00:00:40.660
Unfortunately,

00:00:40.690 --> 00:00:44.390
emulation is expensive and will, at some point, have to stop

00:00:44.500 --> 00:00:47.250
to avoid consuming too many CPU cycles.

00:00:48.040 --> 00:00:51.720
Different emulators will have different stop conditions, such as the

00:00:51.720 --> 00:00:54.300
number of CPU instructions which have occurred,

00:00:54.630 --> 00:00:59.050
the elapsed time, or the number of API calls which were observed.

00:00:59.840 --> 00:01:03.560
Let's now take a look at what emulation looks like in practice.

00:01:04.640 --> 00:01:07.520
Let's once again generate a Meterpreter stager using

00:01:07.520 --> 00:01:10.050
the raw format and send it to a file.

00:01:10.260 --> 00:01:15.310
I chose to use Speakeasy, a free emulator which is developed by FireEye,

00:01:15.600 --> 00:01:17.790
a well‑known cybersecurity company.

00:01:18.040 --> 00:01:21.160
We can run Speakeasy with the following command.

00:01:21.240 --> 00:01:26.740
The ‑r specifies that this is raw shell code. The ‑a is

00:01:26.740 --> 00:01:28.580
used to specify the architecture.

00:01:28.950 --> 00:01:32.560
In our case, we chose to generate a 64‑bit stager.

00:01:33.140 --> 00:01:37.660
The ‑t option is used to specify the file name containing the shell code,

00:01:37.660 --> 00:01:38.960
which we want to emulate.

00:01:40.040 --> 00:01:44.300
The ‑o specifies where we want to store the emulation report and

00:01:44.300 --> 00:01:47.220
the ‑d where we want to store memory dumps.

00:01:47.740 --> 00:01:49.700
When we run the code through the emulator,

00:01:49.710 --> 00:01:52.150
we can immediately see very interesting output.

00:01:52.540 --> 00:01:54.550
We can see the call to LoadLibrary,

00:01:55.040 --> 00:01:58.180
which, as we saw in the Meterpreter Deep Dive module is

00:01:58.180 --> 00:02:00.050
used to load the wininet library.

00:02:00.540 --> 00:02:03.800
We can also see that there were many calls to APIs

00:02:03.800 --> 00:02:05.850
exported by the wininet library.

00:02:06.240 --> 00:02:11.510
We can even see the URI which would be used when connecting to the handler.

00:02:11.710 --> 00:02:13.750
You can also see the call to VirtualAlloc,

00:02:14.180 --> 00:02:19.400
which is something we also observed when using API monitoring and ETW providers.

00:02:19.610 --> 00:02:22.640
The difference here is that the code has not been run on

00:02:22.640 --> 00:02:25.180
the endpoint. It has just been emulated.

00:02:25.470 --> 00:02:28.000
This gives us, or an antivirus solution,

00:02:28.010 --> 00:02:31.050
the ability to block something before it actually happens.

00:02:32.040 --> 00:02:32.930
For instance,

00:02:32.940 --> 00:02:36.670
we could imagine that the antivirus file system filter driver is

00:02:36.670 --> 00:02:40.290
informed that an executable file is being written to disk.

00:02:40.500 --> 00:02:43.290
The antivirus could send the file through an emulator to

00:02:43.290 --> 00:02:46.050
figure out what it would do if executed.

00:02:46.840 --> 00:02:48.240
If we take a closer look,

00:02:48.250 --> 00:02:53.290
we can see that the emulation crashed after the calls to InternetReadFile.

00:02:53.520 --> 00:02:56.760
This makes sense because our payload was not downloaded.

00:02:57.240 --> 00:03:00.740
Bear in mind that a dummy payload could be sent back by the

00:03:00.740 --> 00:03:03.940
emulator to check what would have happened if a Meterpreter

00:03:03.940 --> 00:03:06.290
payload had been sent back to the stager.

00:03:08.640 --> 00:03:11.360
This is what the emulation looks like at a high level.

00:03:12.040 --> 00:03:12.760
On the left,

00:03:12.770 --> 00:03:15.600
we have the antivirus, which can send the file or

00:03:15.600 --> 00:03:18.310
script containing code to the emulator.

00:03:18.530 --> 00:03:22.700
The code is then emulated in a fake environment. Artifacts are

00:03:22.700 --> 00:03:25.150
collected and sent back to the antivirus,

00:03:25.260 --> 00:03:29.330
which can make an informed decision on whether the submitted sample is

00:03:29.330 --> 00:03:32.950
malicious or not by analyzing the collected artifacts.

00:03:33.140 --> 00:03:35.790
These artifacts can relate to APIs,

00:03:35.800 --> 00:03:38.560
which would have been called, as well as memory dumps.