WEBVTT

00:00:00.440 --> 00:00:04.550
Here is an example of what an antivirus could look like from a 1,000‑ft view.

00:00:04.940 --> 00:00:08.790
At the bottom of the chart, we can see the kernel and the antivirus driver.

00:00:08.790 --> 00:00:11.810
When an executable file is written to disk,

00:00:11.820 --> 00:00:14.540
the driver would process the operation and scan the

00:00:14.540 --> 00:00:16.850
file as it is being written to disk.

00:00:17.240 --> 00:00:19.980
It could also inform the antivirus service that the

00:00:19.980 --> 00:00:24.080
file has been written to disk, which could trigger static analysis of the file.

00:00:24.350 --> 00:00:27.330
The service might also check the file's reputation in the

00:00:27.330 --> 00:00:30.200
cloud and send it to an emulator or a sandbox,

00:00:30.200 --> 00:00:34.900
as well as checking its hash against a database of known malicious file hashes.

00:00:34.900 --> 00:00:38.030
On the right, we can see the process starting up,

00:00:38.040 --> 00:00:42.040
assuming that the previous steps did not result in the file being quarantined.

00:00:42.040 --> 00:00:45.650
When the process starts, the kernel notifies the driver,

00:00:45.660 --> 00:00:49.100
which in turn can inject the API monitoring DLL into

00:00:49.100 --> 00:00:51.170
the process and inform the service.

00:00:51.410 --> 00:00:53.980
If the process happens to opt in to AMSI,

00:00:53.990 --> 00:00:55.780
which is the case for PowerShell,

00:00:55.780 --> 00:01:00.240
AMSI.dll would be loaded automatically inside the process.

00:01:00.240 --> 00:01:05.319
Once the process starts executing, if it happens to be a Meterpreter stager,

00:01:05.319 --> 00:01:09.710
it might call APIs, such as LoadLibraryA and VirtualAlloc.

00:01:10.130 --> 00:01:13.670
These calls would be monitored by the API monitoring DLL.

00:01:13.850 --> 00:01:16.810
If the Meterpreter stager is invoked using PowerShell,

00:01:16.810 --> 00:01:20.760
the PowerShell script could be scanned by the AMSI provider.

00:01:21.140 --> 00:01:25.730
The Microsoft Windows Threat Intelligence feed would also generate events for

00:01:25.730 --> 00:01:29.020
the memory allocations made by the calls to VirtualAlloc.

00:01:29.430 --> 00:01:33.680
These calls to VirtualAlloc may also trigger in‑memory scans

00:01:33.710 --> 00:01:36.560
for known malicious artifacts at runtime.

00:01:36.940 --> 00:01:39.300
Assuming that the stager still hasn't been detected,

00:01:39.410 --> 00:01:43.360
it would start communicating over the network with the Metasploit handler,

00:01:43.360 --> 00:01:47.170
which could result in the IP address and host name of the Metasploit

00:01:47.170 --> 00:01:50.890
handler being recorded by the driver and sent to the service,

00:01:50.900 --> 00:01:54.310
which in turn could check with cloud‑based threat intelligence

00:01:54.310 --> 00:01:56.800
feeds if they are known to be malicious.

00:01:57.040 --> 00:01:57.740
Finally,

00:01:57.750 --> 00:02:01.690
the HTTP response containing the payload could also be scanned by the

00:02:01.690 --> 00:02:04.960
network driver as it is being sent back by the handler.

00:02:05.540 --> 00:02:09.650
As you can see, there are many ways an antivirus could detect our tradecraft.

00:02:10.139 --> 00:02:13.770
Having a good understanding of these techniques will help you pinpoint

00:02:13.780 --> 00:02:16.370
the reason your tools are being blocked by antivirus,

00:02:16.380 --> 00:02:19.180
which in turn will help you evade detections.

00:02:19.220 --> 00:02:23.340
It goes without saying that having access to multiple antivirus products

00:02:23.350 --> 00:02:26.360
to test your tradecraft will be extremely helpful.