WEBVTT 00:00:00.140 --> 00:00:04.630 In order to get past emulation engines undetected, you have a couple of options. 00:00:04.630 --> 00:00:07.010 You could try to identify APIs, 00:00:07.020 --> 00:00:09.580 which are not frequently used, and attempt to call 00:00:09.580 --> 00:00:11.560 them prior to running your stager. 00:00:11.810 --> 00:00:15.360 If those API calls fail because the emulator doesn't handle 00:00:15.360 --> 00:00:18.300 them correctly or returns unexpected values, 00:00:18.300 --> 00:00:20.870 you can force the application to exit, 00:00:20.880 --> 00:00:23.930 which will ensure your stager doesn't get emulated. 00:00:24.120 --> 00:00:27.040 As explained in the antivirus and EDR modules, 00:00:27.040 --> 00:00:29.910 emulators usually have a termination condition. 00:00:30.140 --> 00:00:33.690 This is to avoid performance issues by limiting CPU and 00:00:33.690 --> 00:00:37.850 memory consumption on the computer, which might impact user productivity. 00:00:37.940 --> 00:00:38.970 As an attacker, 00:00:38.980 --> 00:00:42.330 we can take advantage of this by executing many bogus 00:00:42.330 --> 00:00:45.730 instructions in a loop prior to executing the stager, 00:00:46.000 --> 00:00:49.920 which will make the emulator spin its wheels and eventually exit 00:00:49.930 --> 00:00:52.440 for the sake of performance and productivity. 00:00:52.540 --> 00:00:55.960 Another way of identifying if your stager is being emulated is 00:00:55.960 --> 00:00:58.260 checking the environment through anomalies. 00:00:58.440 --> 00:00:59.370 If, for example, 00:00:59.370 --> 00:01:02.900 you add code to check the file name of your executable file at 00:01:02.900 --> 00:01:06.220 runtime and it doesn't match the original file name, 00:01:06.220 --> 00:01:12.740 or if you perform an HTTP request for a fake URL and get an HTTP 200 response, 00:01:12.740 --> 00:01:16.570 it might suggest that your code is being run in an emulator, 00:01:16.600 --> 00:01:19.400 in which case you can exit the process to ensure 00:01:19.400 --> 00:01:21.360 the stager doesn't get emulated. 00:01:21.540 --> 00:01:25.310 Another way of identifying if an emulator is in use is 00:01:25.310 --> 00:01:28.500 checking CPU register values before and after function 00:01:28.500 --> 00:01:30.560 calls and check for discrepancies. 00:01:31.140 --> 00:01:35.940 Anti‑sandboxing techniques are similar in concept to anti‑emulation. 00:01:36.180 --> 00:01:38.690 The approach, which is usually chosen, 00:01:38.700 --> 00:01:42.180 consists of checking various artifacts on the machine to try 00:01:42.180 --> 00:01:45.540 and figure out if the code is being run on the real user's 00:01:45.540 --> 00:01:48.060 computer and not inside a sandbox. 00:01:48.440 --> 00:01:52.310 The approach we covered in anti‑emulation, which consisted of exhausting 00:01:52.310 --> 00:01:57.190 the emulator using a loop of bogus instructions, will not be as effective 00:01:57.190 --> 00:02:01.900 here since resource consumption isn't a problem in cloud‑based solutions. 00:02:01.900 --> 00:02:03.910 We do have some alternatives. 00:02:03.920 --> 00:02:07.810 We can check if the computer is joined to the correct Windows 00:02:07.810 --> 00:02:11.570 domain that you're trying to attack or if the logged‑on user 00:02:11.570 --> 00:02:14.770 name corresponds to the person you're trying to socially 00:02:14.770 --> 00:02:17.130 engineer into launching your stager. 00:02:17.240 --> 00:02:19.310 These approaches are very effective. 00:02:19.320 --> 00:02:22.380 They are unfortunately not very feasible and require a 00:02:22.380 --> 00:02:26.550 lot of information about the target, which isn't always available to an attacker. 00:02:26.640 --> 00:02:30.110 Alternative techniques consist of checking if the code is being 00:02:30.110 --> 00:02:34.500 run on a virtual machine since most sandboxes are virtualized. A 00:02:34.500 --> 00:02:36.280 technique we mentioned previously, 00:02:36.290 --> 00:02:39.030 which consists of checking for successful responses to 00:02:39.030 --> 00:02:41.420 HTTP requests which should fail, 00:02:41.430 --> 00:02:44.960 are also a good indicator that code is running in the sandbox. 00:02:45.140 --> 00:02:48.290 In the case you were unsuccessful at detecting the sandbox, 00:02:48.300 --> 00:02:49.760 your stager will execute, 00:02:49.760 --> 00:02:53.990 and in some cases will connect to a handler to retrieve the payload, 00:02:54.120 --> 00:02:56.120 which will be sent to the sandbox. 00:02:56.350 --> 00:02:59.970 If this is the case, there is a good chance that you will get caught. 00:02:59.980 --> 00:03:02.670 One option, which is very effective at preventing this, 00:03:02.670 --> 00:03:03.950 but tricky to implement, 00:03:03.960 --> 00:03:07.890 is identifying the public IP addresses used by your victim and 00:03:07.890 --> 00:03:10.560 only allowing those to connect to your handler. 00:03:10.620 --> 00:03:13.370 This will ensure your payload isn't being sent to 00:03:13.370 --> 00:03:15.790 cloud‑based sandboxes for analysis. 00:03:16.040 --> 00:03:19.710 Most solutions will only send executables into a sandbox for 00:03:19.710 --> 00:03:23.210 analysis when it is unsure if it is safe or not. 00:03:23.390 --> 00:03:26.210 If our executable looks benign on disk, 00:03:26.220 --> 00:03:30.410 we reduce the likelihood that it will be sent for a sandbox analysis. 00:03:30.590 --> 00:03:31.520 In some cases, 00:03:31.530 --> 00:03:35.510 if the antivirus is unable to get reputation information about the file, 00:03:35.520 --> 00:03:38.000 it will automatically get uploaded for analysis. 00:03:38.940 --> 00:03:41.270 There are many resources on the internet, 00:03:41.280 --> 00:03:44.110 which documents techniques for bypassing dynamic 00:03:44.110 --> 00:03:46.870 analysis inside sandboxes and emulators. 00:03:47.150 --> 00:03:50.050 One document, which I recommend, is the following, 00:03:50.060 --> 00:03:52.050 which can be found on WikiLeaks. 00:03:52.440 --> 00:03:54.660 The author documented various techniques, 00:03:54.670 --> 00:03:58.610 which he was able to use successfully to get around antivirus solutions. 00:03:58.840 --> 00:04:00.110 If we scroll down, 00:04:00.120 --> 00:04:04.160 we can see that the document focuses on emulation and sandboxes. 00:04:04.540 --> 00:04:08.340 Scrolling down even further will reveal various code samples, 00:04:08.350 --> 00:04:12.410 which the author was able to use to bypass emulators and sandboxes. 00:04:12.500 --> 00:04:16.560 Some involved allocating large amounts of memory and filling it with data. 00:04:16.940 --> 00:04:19.920 Others leverage a technique we discussed previously, 00:04:19.930 --> 00:04:23.000 which consists of exhausting the emulator using loops. 00:04:23.330 --> 00:04:26.200 The document also demonstrates another example, 00:04:26.210 --> 00:04:27.270 which we discussed, 00:04:27.280 --> 00:04:31.250 which consists of checking the logged‑on username and check for discrepancies, 00:04:32.140 --> 00:04:34.660 as well as checking the file name at runtime. 00:04:35.040 --> 00:04:36.420 In the upcoming demo, 00:04:36.430 --> 00:04:39.410 we will be using one of these techniques to exhaust the 00:04:39.410 --> 00:04:41.960 emulator and bypass Windows Defender.