WEBVTT 00:00:00.940 --> 00:00:04.830 If we choose to use the reverse_https stages and payloads, 00:00:04.840 --> 00:00:08.710 a default certificate will be used by the Metasploit handler. 00:00:08.950 --> 00:00:12.960 This certificate is sent over the network during the SSL handshake, 00:00:12.960 --> 00:00:17.100 similar to how using the default executable template was being flagged 00:00:17.100 --> 00:00:19.860 by antivirus when uploaded to VirusTotal. 00:00:20.040 --> 00:00:23.540 Using this default certificate is likely to get flagged on 00:00:23.540 --> 00:00:25.930 the network or even on the endpoint. 00:00:25.940 --> 00:00:30.060 You may recall that antivirus and EDR solutions sometimes make use of network 00:00:30.060 --> 00:00:33.830 drivers to inspect network packets. To get around this issue, 00:00:33.840 --> 00:00:37.970 we can choose to use a reverse_http stager instead of HTTPS, 00:00:37.980 --> 00:00:40.460 which will avoid the SSL handshake altogether. 00:00:40.740 --> 00:00:43.620 This is not a big deal, because communication between the 00:00:43.620 --> 00:00:46.410 Meterpreter payload and the Metasploit handler is already 00:00:46.410 --> 00:00:48.450 encrypted at the application level. 00:00:48.720 --> 00:00:51.680 The reason for encrypting the data at the application 00:00:51.680 --> 00:00:55.170 level is because SSL interception can be performed by 00:00:55.170 --> 00:00:57.590 security solutions to inspect data. 00:00:57.720 --> 00:01:01.550 If on the other hand we do want to use HTTPS stages and payloads, 00:01:01.550 --> 00:01:05.019 you can of course request a valid certificate from a trusted 00:01:05.019 --> 00:01:09.040 public certificate authority for a domain which you own and bind 00:01:09.040 --> 00:01:10.750 it to your Metasploit handler. 00:01:10.840 --> 00:01:16.720 Ja3 and Ja3s fingerprints can theoretically be used to detect stages 00:01:16.720 --> 00:01:20.480 and payloads which make use of the HTTPS protocol. 00:01:20.610 --> 00:01:25.080 Ja3 hashes can be calculated by capturing the SSL handshake 00:01:25.090 --> 00:01:28.800 and extracting various artifacts such as the TLS version and 00:01:28.800 --> 00:01:30.760 supported ciphers, to name a few. 00:01:30.940 --> 00:01:36.460 All these artifacts are concatenated and hashed using the MD5 hashing algorithm. 00:01:36.840 --> 00:01:40.390 These hashes are commonly referred to as fingerprints, which 00:01:40.390 --> 00:01:44.210 can be linked to a specific client or server, which in our case 00:01:44.220 --> 00:01:48.560 relate to the Meterpreter stager, payload, and Metasploit handler. 00:01:49.040 --> 00:01:54.350 Once again, this can be avoided by using the HTTP stages and payloads instead. 00:01:54.940 --> 00:01:58.320 The more you are able to blend in with existing network traffic, 00:01:58.630 --> 00:02:01.270 the less likely you are to get caught by security 00:02:01.270 --> 00:02:03.350 solutions and perimeter defenses. 00:02:03.730 --> 00:02:06.690 There are many techniques which you can leverage to do this. 00:02:06.830 --> 00:02:09.840 One effective way to blend in is to use a technique 00:02:09.840 --> 00:02:12.160 commonly referred to as domain fronting. 00:02:12.240 --> 00:02:15.930 This technique is possible because of how content delivery networks 00:02:15.940 --> 00:02:19.460 route HTTP traffic and perform SSL encryption. 00:02:19.640 --> 00:02:23.760 This technique lets us establish an SSL tunnel with one domain, and 00:02:23.760 --> 00:02:27.050 piggyback the SSL tunnel to access a different domain. 00:02:27.200 --> 00:02:30.840 This can be very useful to trick perimeter defenses into thinking you're 00:02:30.840 --> 00:02:34.270 connecting to a trusted domain classified accordingly, 00:02:34.280 --> 00:02:37.970 even though you're actually leveraging the SSL tunnel to connect to a 00:02:37.970 --> 00:02:40.660 different domain which may not be as trustworthy. 00:02:41.040 --> 00:02:43.870 Another technique which can help blend in with surrounding 00:02:43.870 --> 00:02:47.870 network traffic is to configure realistic user‑agent and 00:02:47.870 --> 00:02:51.670 header information into your stages, payloads, and handlers. 00:02:51.910 --> 00:02:55.530 Some security solutions might alert on traffic which makes 00:02:55.530 --> 00:02:58.190 use of abnormal or rare user agents, 00:02:58.190 --> 00:03:03.070 for example. Stages can be configured to authenticate over the network. 00:03:03.080 --> 00:03:07.050 This might also be required in some cases by certain proxy servers. 00:03:07.440 --> 00:03:10.840 Finally, Metasploit provides stageless payloads. 00:03:10.850 --> 00:03:13.980 The advantage of using these stageless payloads is that you no 00:03:13.980 --> 00:03:16.710 longer need to send over the payload and extension, 00:03:16.720 --> 00:03:19.200 which will improve stealth over the network. 00:03:19.350 --> 00:03:20.370 This is, however, 00:03:20.370 --> 00:03:24.860 a double‑edged sword, because although you will increase stealth on the network, 00:03:24.870 --> 00:03:29.860 it will be harder to conceal on disk and will result in a much larger file, 00:03:29.870 --> 00:03:32.290 which can be an issue in some circumstances. 00:03:32.540 --> 00:03:34.770 Many things can go wrong on the network. 00:03:34.780 --> 00:03:37.170 It's always a good idea to have a plan B. 00:03:37.240 --> 00:03:39.360 When we write our own custom stages, 00:03:39.440 --> 00:03:42.950 we can add a fallback to a different communication protocol, 00:03:43.040 --> 00:03:45.250 such as DNS tunneling, for example. 00:03:45.490 --> 00:03:48.940 Fallback communication channels may be routed differently and might 00:03:48.940 --> 00:03:51.980 evade detection even though the former did not.