WEBVTT 00:00:00.940 --> 00:00:03.160 Let's now take a look at AMSI. 00:00:03.940 --> 00:00:05.880 AMSI is an interface, 00:00:05.890 --> 00:00:08.520 which is leveraged by many of the built‑in scripting 00:00:08.520 --> 00:00:11.660 languages available to us on Windows, such as PowerShell, 00:00:11.660 --> 00:00:14.560 VBScript, JScript, and VBA. 00:00:15.740 --> 00:00:17.680 By registering an AMSI provider, 00:00:17.680 --> 00:00:21.450 an antivirus can scan scripts at runtime in an 00:00:21.450 --> 00:00:23.560 attempt to block malicious activity. 00:00:24.740 --> 00:00:28.020 Here is a simple example of how AMSI works. 00:00:28.020 --> 00:00:32.729 When a PowerShell process is spawned and it starts executing code, 00:00:32.729 --> 00:00:39.010 the code will be sent to the AMSI APIs exposed by the AMSI.dll module, 00:00:39.020 --> 00:00:42.460 which is automatically loaded inside PowerShell processes. 00:00:43.040 --> 00:00:46.440 The AMSI module will then forward the code which needs to be 00:00:46.440 --> 00:00:50.050 scanned to the registered AMSI provider for analysis. 00:00:50.200 --> 00:00:53.710 If malicious activity is detected by the AMSI provider, 00:00:53.900 --> 00:00:55.160 the code will be blocked. 00:00:57.240 --> 00:00:59.760 Let's now take a closer look at AMSI. 00:01:00.140 --> 00:01:03.570 As explained, AMSI consists of several components. 00:01:03.720 --> 00:01:07.360 One of those components is the AMSI.dll module, 00:01:07.370 --> 00:01:11.400 which is automatically loaded into the process of applications, 00:01:11.410 --> 00:01:13.210 which opt in to AMSI. 00:01:13.510 --> 00:01:15.350 One example is PowerShell. 00:01:15.580 --> 00:01:19.530 The AMSI.dll module exports multiple APIs, 00:01:19.540 --> 00:01:23.660 which are called automatically when running PowerShell commands. 00:01:24.140 --> 00:01:28.380 A good example is the AMSIScanBuffer API. 00:01:28.380 --> 00:01:30.620 As its name suggests, 00:01:30.790 --> 00:01:35.410 this API will scan a buffer containing code which is being 00:01:35.410 --> 00:01:39.180 requested to run and returns a result once that buffer has 00:01:39.180 --> 00:01:41.130 been analyzed by the antivirus. 00:01:41.130 --> 00:01:44.110 To get more insight into how this works, 00:01:44.120 --> 00:01:48.560 I have installed Frida, which is a tool which can be used to hook APIs. 00:01:48.560 --> 00:01:51.580 I then proceeded to start up a command prompt, 00:01:51.580 --> 00:01:54.940 which I will use to run Frida, and a PowerShell prompt, 00:01:54.950 --> 00:01:56.930 which we will monitor with Frida. 00:01:56.970 --> 00:02:01.130 We can hook into the relevant APIs using the following command and 00:02:01.130 --> 00:02:04.360 specifying the process_id of our PowerShell process. 00:02:04.840 --> 00:02:08.400 Each hooked API will result in a JavaScript file, 00:02:08.400 --> 00:02:10.729 which contains a simple log function. 00:02:11.000 --> 00:02:15.020 We can modify these JavaScript files to access input and output 00:02:15.020 --> 00:02:18.460 parameters when the function is called and when it returns. 00:02:18.840 --> 00:02:21.510 I have already prepared the code which will log the 00:02:21.510 --> 00:02:24.830 parameters passed to the AMSIScanBuffer API, 00:02:24.840 --> 00:02:27.450 as well as the results when the function returns. 00:02:28.840 --> 00:02:32.710 If we now type a benign command in our PowerShell process, 00:02:32.720 --> 00:02:35.380 we will notice that the value returned by the call 00:02:35.390 --> 00:02:37.940 to the AMSIScanBuffer API is 1. 00:02:37.940 --> 00:02:44.900 If we run another benign command, the value is also 1. 00:02:44.900 --> 00:02:50.260 If, on the other hand, we run a command containing a known malicious string, 00:02:50.260 --> 00:02:53.230 such as invoke‑mimikatz, the code is blocked, 00:02:53.230 --> 00:02:54.950 and the result is not 1. 00:02:55.440 --> 00:02:57.390 As you will see later on in the course, 00:02:57.400 --> 00:03:01.460 AMSI is vulnerable to the same kind of tampering which can affect API 00:03:01.460 --> 00:03:04.700 monitoring because it also occurs inside the process, 00:03:04.710 --> 00:03:08.300 which can be tampered by the code running inside that process.