WEBVTT 00:00:00.040 --> 00:00:03.600 You may recall that when we use Metasploit encoders to 00:00:03.600 --> 00:00:05.720 obfuscate on Meterpreter stages, 00:00:05.830 --> 00:00:09.710 we were able to drastically reduce the number of detections which were 00:00:09.710 --> 00:00:13.060 being triggered by antivirus scanners on virus total. 00:00:13.120 --> 00:00:17.550 IDS and network‑based antivirus solutions might analyze network 00:00:17.550 --> 00:00:22.490 packets in an attempt to match known malicious byte sequences similar 00:00:22.490 --> 00:00:26.380 to how an antivirus scanner might attempt to match byte sequences 00:00:26.380 --> 00:00:28.630 inside a file being written to disk. 00:00:28.700 --> 00:00:31.980 When Meterpreter stages connect to the Metasploit handler, 00:00:32.090 --> 00:00:35.380 the handler sends back the payload and a few extensions. 00:00:35.550 --> 00:00:38.360 As these files are being downloaded by the stager, 00:00:38.540 --> 00:00:43.160 they might get scanned and blocked if a malicious artifact is observed 00:00:43.170 --> 00:00:46.400 during communication by a network security system. 00:00:46.540 --> 00:00:50.190 The Metasploit encoders, which we used when evading antivirus on 00:00:50.190 --> 00:00:54.660 disk, can also be used to encode the payload and extensions 00:00:54.660 --> 00:00:57.060 before sending them back to the stager. 00:00:57.350 --> 00:01:02.070 This can be done by setting the enable stage encoder option to true 00:01:02.080 --> 00:01:06.310 and specifying the encoder we want to use with the stage encoder 00:01:06.310 --> 00:01:09.490 option when configuring our Metasploit handler. 00:01:09.750 --> 00:01:13.520 This works exactly the same way as it does when encoding stages. 00:01:13.700 --> 00:01:17.280 The payload is read from disk by the handler, the small stub 00:01:17.280 --> 00:01:20.600 of shellcode which triggers the reflective loader is added 00:01:20.600 --> 00:01:22.060 in the payload's DOS header. 00:01:22.140 --> 00:01:25.380 The payload is then encoded and a decoder stub is 00:01:25.380 --> 00:01:27.700 added in front of the encoded payload. 00:01:27.710 --> 00:01:31.650 This data is then sent back over the network and any signature‑based 00:01:31.650 --> 00:01:35.700 detections will no longer match since the data is obfuscated. 00:01:36.740 --> 00:01:41.160 Let's now take a closer look at why encoding the payload and extensions may be 00:01:41.160 --> 00:01:44.680 required when using Meterpreter in a secure environment. 00:01:44.940 --> 00:01:48.720 I have configured an HTTP proxy on the Windows machine 00:01:48.720 --> 00:01:50.420 which will be our victim system. 00:01:50.430 --> 00:01:53.780 Proxy servers are commonly used in environments that want to 00:01:53.780 --> 00:01:56.570 control user's web browsing activities. 00:01:56.610 --> 00:02:00.020 They can be used to blacklist certain websites based on 00:02:00.020 --> 00:02:03.080 categorization. A company may, for example, 00:02:03.080 --> 00:02:07.970 prevent HTTP traffic to websites hosting social media services. 00:02:08.300 --> 00:02:11.540 Proxy service can also be used to prevent downloads 00:02:11.550 --> 00:02:13.500 of potentially dangerous files, 00:02:13.550 --> 00:02:16.650 which may compromise the internal network if the files were 00:02:16.650 --> 00:02:19.260 to be executed on an internal system. 00:02:19.340 --> 00:02:19.770 Finally, 00:02:19.770 --> 00:02:24.850 a proxy server can communicate with an ICAP server using the ICAP protocol. 00:02:25.070 --> 00:02:29.640 The ICAP server can then process the request, and for example, run it 00:02:29.640 --> 00:02:33.380 through an antivirus scan in an attempt to detect malware. 00:02:33.650 --> 00:02:38.210 The proxy which I have configured is a Squid proxy which leverages the ICAP 00:02:38.210 --> 00:02:43.070 protocol to interface with the open source ClamAV antivirus. 00:02:43.340 --> 00:02:46.760 I have disabled the antivirus on the victim's machine to 00:02:46.760 --> 00:02:50.330 avoid any interference, and we will be reusing the shellcode 00:02:50.330 --> 00:02:52.130 runner which we wrote previously. 00:02:52.270 --> 00:02:56.570 The Metasploit handler has already been started and has not been configured 00:02:56.580 --> 00:03:00.960 with the enable stage encoder option which means that the payload will be 00:03:00.960 --> 00:03:05.820 sent back to the stager unencoded. I have a terminal window open on the 00:03:05.820 --> 00:03:10.480 proxy server which is tailing the ICAP server logs in which an alert would 00:03:10.480 --> 00:03:15.090 surface If ClamAV detects something. Let's now place a breakpoint on the 00:03:15.090 --> 00:03:19.110 line of code where we execute the stager and go ahead and launch our 00:03:19.110 --> 00:03:20.160 shellcode runner. 00:03:20.740 --> 00:03:22.590 Once the breakpoint has been hit, 00:03:22.600 --> 00:03:25.760 let's switch to the assembly mode and step into the call. 00:03:25.880 --> 00:03:29.310 Let's now place a breakpoint on the right instruction which transfers 00:03:29.310 --> 00:03:36.330 execution into the payload, and check the address which we are about to 00:03:36.330 --> 00:03:38.550 return to which is stored on the stack. 00:03:40.740 --> 00:03:42.660 If we inspect this memory location, 00:03:43.240 --> 00:03:47.520 you will notice that we did not receive our payload and that there appears 00:03:47.520 --> 00:03:51.160 to be html tags inside the response from our handler. 00:03:51.450 --> 00:03:55.030 Looking closer reveals that ClamAV detected a virus. 00:03:55.170 --> 00:03:56.560 If you go to our handler, 00:03:56.570 --> 00:04:00.290 you will notice that it did indeed send the payload back, but 00:04:00.290 --> 00:04:04.420 evidently the stager never received it because it was detected and 00:04:04.420 --> 00:04:06.860 blocked whilst traversing the network. 00:04:06.940 --> 00:04:09.960 We can also review the ICAP server logs to see that 00:04:09.960 --> 00:04:12.160 the detection has indeed occurred. 00:04:12.230 --> 00:04:16.079 Let's now stop the debugger and reconfigure our handler so that it 00:04:16.079 --> 00:04:19.279 encodes the payload before sending it over the network. 00:04:19.290 --> 00:04:23.970 We can do this by setting the enable staging coder option to true and 00:04:23.970 --> 00:04:28.340 specifying the encoder to use by setting the stage encoder option 00:04:28.350 --> 00:04:31.370 followed by the name of the encoder we want to use. 00:04:31.840 --> 00:04:35.950 We will now launch our shellcode runner one more time until we reach 00:04:35.950 --> 00:04:38.860 the final right instruction as we did previously. 00:04:48.240 --> 00:04:49.120 (Working) This time, however, 00:04:49.120 --> 00:04:53.120 you will notice that we do not have html tags in memory and a 00:04:53.120 --> 00:04:56.070 message telling us that the request was blocked because of 00:04:56.070 --> 00:04:59.060 malicious browsing activity as it did previously. 00:04:59.440 --> 00:05:01.010 If we step into this code, 00:05:01.020 --> 00:05:04.400 you will find that we are, in fact, stepping inside Zutto 00:05:04.400 --> 00:05:07.900 Dekiru's decoder stub, which will decode the payload, and 00:05:07.900 --> 00:05:09.390 once decoding is finished, 00:05:09.400 --> 00:05:12.660 it will fall through into the original payload and trigger the 00:05:12.660 --> 00:05:15.360 little stub of shellcode inside the DOS header, 00:05:15.440 --> 00:05:18.680 which will trigger the reflective loader and call DLL main, 00:05:18.680 --> 00:05:20.910 which will complete the initialization. 00:05:20.920 --> 00:05:24.130 Bear in mind that all subsequently loaded modules and the 00:05:24.130 --> 00:05:28.230 extensions will also be encoded using the specified encoder. In 00:05:28.230 --> 00:05:32.270 this case, since Zutto Dekiru's decoder stub is polymorphic and the 00:05:32.270 --> 00:05:35.230 X all key used is randomly generated, 00:05:35.330 --> 00:05:38.430 it would be very hard to develop a reliable signature. 00:05:38.440 --> 00:05:40.660 If we check the ICAP server's log file, 00:05:40.740 --> 00:05:43.830 we can see that no detection has occurred, and if 00:05:43.830 --> 00:05:45.310 we check our Metasploit handler, 00:05:45.320 --> 00:05:48.260 we will find a fully functional Meterpreter shell.