WEBVTT

00:00:00.040 --> 00:00:03.890
Let's now go through a demo where we will be evading Windows Defender

00:00:03.890 --> 00:00:07.270
on the endpoint, as well as ClamAV on the network.

00:00:07.350 --> 00:00:09.630
We will be using the custom stager, which we have

00:00:09.630 --> 00:00:11.660
been working with during the course.

00:00:12.240 --> 00:00:15.250
If you have been following along in the course, at this point,

00:00:15.260 --> 00:00:19.720
you should be quite familiar with the custom stager, which we wrote in C++

00:00:19.730 --> 00:00:22.620
throughout the various modules, which we covered previously.

00:00:22.870 --> 00:00:26.190
You may recall that despite the fact that we were able to partially

00:00:26.190 --> 00:00:28.860
bypass Windows Defender in a previous module,

00:00:29.140 --> 00:00:33.190
it did still cause an alert when the payload was sent back to the stager.

00:00:33.440 --> 00:00:37.660
Let's see if encoding the payload will make our tradecraft more evasive.

00:00:37.730 --> 00:00:41.730
I have already configured the proxy server on our victim system, which will

00:00:41.730 --> 00:00:46.070
ensure that all HTTP traffic will get sent to our Squid proxy,

00:00:46.080 --> 00:00:51.010
which in turn will make use of the ICAP protocol and the open source CanAV

00:00:51.010 --> 00:00:55.460
antivirus to scan HTTP traffic for malicious content.

00:00:55.640 --> 00:00:59.140
I have also enabled Windows Defender on the endpoint.

00:00:59.420 --> 00:01:01.680
If we now switch to our Kali machine,

00:01:01.790 --> 00:01:05.310
you will notice that I have already started the Metasploit handler.

00:01:05.319 --> 00:01:10.660
I have set the enablestagingcoding option to true to ensure our payloads and

00:01:10.660 --> 00:01:14.450
extensions are not sent over the network and obfuscated.

00:01:14.540 --> 00:01:17.660
I have once again chosen the zutto_dekiru encoder.

00:01:17.840 --> 00:01:23.910
You may notice that I also set the autoloadstdapi option to false. This will

00:01:23.910 --> 00:01:27.320
change the Meterpreter initialization process slightly.

00:01:27.330 --> 00:01:30.580
I have found that it can help evade heuristic detections in some

00:01:30.580 --> 00:01:34.160
cases. We can now go back to our stager and compile it.

00:01:34.840 --> 00:01:35.950
Once compiled,

00:01:36.440 --> 00:01:39.580
we can go ahead and execute it and hope for the best or the

00:01:39.580 --> 00:01:41.640
worst, depending on the point of view.

00:01:41.870 --> 00:01:42.860
As you can see,

00:01:42.870 --> 00:01:46.080
Windows Defender did not appear to detect our stager and did

00:01:46.080 --> 00:01:48.660
not trigger an alert as it did previously.

00:01:48.740 --> 00:01:50.720
Our stager did not crash either,

00:01:50.930 --> 00:01:54.850
which would've been the case if the payload had been blocked by the Squid proxy

00:01:54.860 --> 00:01:58.760
and ClanAV. If we go ahead and go to our Metasploit handler,

00:01:58.940 --> 00:02:01.910
you will notice that we did indeed receive a connection from the

00:02:01.910 --> 00:02:05.260
stager and that the payload was sent back encoded.

00:02:05.640 --> 00:02:10.560
We can now manually complete the initialization by loading the stdapi extension.

00:02:11.340 --> 00:02:14.220
At this point, we can start interacting with our

00:02:14.220 --> 00:02:17.160
Meterpreter session. As you can see,

00:02:17.170 --> 00:02:20.570
it appears to be fully functional, and we have successfully evaded

00:02:20.630 --> 00:02:23.460
the antivirus, as well as the perimeter defenses.