WEBVTT 00:00:00.740 --> 00:00:01.430 At this point, 00:00:01.430 --> 00:00:05.260 we have covered all the main components that make up the Meterpreter shell. 00:00:05.740 --> 00:00:08.540 Let's now apply this knowledge in a demo in which we take a 00:00:08.540 --> 00:00:10.860 look at Meterpreter's initialization. 00:00:12.040 --> 00:00:14.970 We will once again generate an HTTP stager and 00:00:14.970 --> 00:00:16.860 embed it inside a shellcode runner. 00:00:17.540 --> 00:00:20.700 We will then start the handler, execute our shellcode runner, 00:00:20.700 --> 00:00:23.260 and step through the code as it executes. 00:00:26.740 --> 00:00:28.340 Before we start writing code, 00:00:28.340 --> 00:00:32.360 we need to disable the antivirus on the machine which will run our stager. 00:00:32.360 --> 00:00:36.360 You will of course be bypassing the antivirus in another module. 00:00:37.640 --> 00:00:41.210 We can do this by opening the Start menu and clicking on Settings. 00:00:47.140 --> 00:00:50.300 We can then open the Update and Security menu and 00:00:50.300 --> 00:00:52.450 go to the Windows Security tab. 00:00:54.440 --> 00:00:57.440 We can then open the Virus and threat protection page, 00:00:57.440 --> 00:01:01.190 and click Manage settings under the Virus and threat protection settings. 00:01:04.739 --> 00:01:08.970 We can then turn off real‑time protection. 00:01:08.970 --> 00:01:15.250 We can generate a stager using MSFvenom once again. 00:01:15.250 --> 00:01:18.700 This time, we will specify c for the format parameter, 00:01:18.710 --> 00:01:23.470 since we are going to be writing our shellcode runner in C. We can 00:01:23.470 --> 00:01:26.880 use the ‑v parameter to specify a variable name, 00:01:26.970 --> 00:01:28.450 which will hold our stager. 00:01:29.740 --> 00:01:33.760 We can then copy the output for later use inside our shellcode runner. 00:01:35.440 --> 00:01:39.660 At this point, we can go over to Visual Studio and create an empty project. 00:01:47.540 --> 00:01:52.410 We can then add a file called main.c, which will hold our code. 00:01:52.410 --> 00:01:56.730 The code we're going to write will be using the VirtualAlloc 00:01:56.730 --> 00:01:59.160 API to allocate a memory buffer. 00:01:59.940 --> 00:02:03.860 We will then use the memcpy function from the C runtime 00:02:03.860 --> 00:02:07.290 library, to copy the shellcode we generated using MSFvenom 00:02:07.300 --> 00:02:09.360 inside the allocated memory buffer. 00:02:10.539 --> 00:02:14.830 Finally, we will cast our memory buffer to a function pointer and transfer 00:02:14.830 --> 00:02:20.020 execution to it, effectively bootstrapping the stager's shellcode. We first 00:02:20.020 --> 00:02:26.240 include the windows.h header file, so we can make use of VirtualAlloc. We then 00:02:26.240 --> 00:02:31.060 copy the stager provided by MSFvenom, and finally, we define our main 00:02:31.060 --> 00:02:36.460 function, which will be the executable file's entry point. Within the main 00:02:36.460 --> 00:02:41.060 function, we can call VirtualAlloc to allocate enough memory for our stager, 00:02:41.060 --> 00:02:45.920 and store the pointer to the allocated memory returned to us by the API inside 00:02:45.920 --> 00:02:46.750 the variable. 00:02:47.140 --> 00:02:50.320 Now that we have a memory buffer, which is both writeable and 00:02:50.320 --> 00:02:54.510 executable, we can use the memcpy function to copy the stager's 00:02:54.510 --> 00:02:56.860 shellcode inside the memory buffer. 00:02:57.240 --> 00:03:01.080 Once copied, we cast the pointer to our memory buffer into a function 00:03:01.080 --> 00:03:05.350 pointer and execute it. Before we execute this code, let's place a 00:03:05.350 --> 00:03:09.640 breakpoint on the line of code where we execute the function pointer, so 00:03:09.640 --> 00:03:14.850 that we can take a look at our stager while it's executing. Next, let's 00:03:14.850 --> 00:03:18.290 start a Metasploit handler on the attacker's machine, which will catch 00:03:18.290 --> 00:03:19.360 the reverse shell. 00:03:24.440 --> 00:03:27.820 We can now ensure that we have selected the correct target CPU 00:03:27.820 --> 00:03:31.560 architecture which matches the stager shellcode's architecture we 00:03:31.560 --> 00:03:35.280 specified when using MSFvenom. At this point, we can go ahead and 00:03:35.280 --> 00:03:39.210 execute the code using the debugger, and it should hit our breakpoint 00:03:39.220 --> 00:03:40.920 before executing the stager. 00:03:45.140 --> 00:03:49.580 We can now open the assembly view so that we can single step one instruction 00:03:49.580 --> 00:03:54.310 at a time instead of one line of code at a time. To do so, we can go to the 00:03:54.310 --> 00:03:59.780 Debug tab and select Disassembly from the Windows dropdown menu. We can now 00:03:59.780 --> 00:04:05.270 see our C code followed by the corresponding assembly instructions. Stepping 00:04:05.270 --> 00:04:10.380 into the call, we'll indeed jump to the stager's shellcode. If we check the 00:04:10.380 --> 00:04:14.510 first couple of instructions and compare them with the inline assembly we 00:04:14.510 --> 00:04:20.450 reviewed in the generate_reverse_http method, we will notice that they match. 00:04:23.640 --> 00:04:28.540 If we scroll down, we will find the ror instruction, which is used 00:04:28.540 --> 00:04:33.280 when calculating the ROT13 hash. If a value is 0D in hexadecimal, 00:04:33.280 --> 00:04:35.660 it's the decimal equivalent of 13. 00:04:36.140 --> 00:04:40.040 If we scroll down even further, we can find the ret instruction, which 00:04:40.040 --> 00:04:44.860 we can also see inside the asm_reverse_http method. 00:04:46.340 --> 00:04:49.250 We can place a breakpoint in the ret instruction by 00:04:49.250 --> 00:04:51.950 clicking just next to the memory address, and let the code 00:04:51.950 --> 00:04:55.970 run. Once the breakpoint is hit, 00:04:55.980 --> 00:04:58.580 just as we're about to execute the ret instruction, 00:04:58.590 --> 00:05:00.150 we can take a look at the stack. 00:05:00.940 --> 00:05:04.570 The reason being that when a ret instruction is executed, an address is 00:05:04.570 --> 00:05:07.850 popped off the top of the stack into the RIP register, 00:05:07.860 --> 00:05:09.760 also known as the instruction pointer, 00:05:10.240 --> 00:05:13.920 which effectively transfers code execution to that address. 00:05:14.640 --> 00:05:18.190 We can do this by copying the RSP register value, which always 00:05:18.190 --> 00:05:21.450 points to the top of the stack into the memory view. 00:05:22.540 --> 00:05:27.440 We can then copy the address located on the stack into the memory view to 00:05:27.440 --> 00:05:32.130 figure out where we are about to return. You may have noticed that the address 00:05:32.130 --> 00:05:35.230 that I copied in the memory view was in reverse order. 00:05:35.600 --> 00:05:40.810 This is to account for the fact that my CPU works in little‑endian. At 00:05:40.810 --> 00:05:45.310 this point, we can see the distinctive MZ PE header signature, which 00:05:45.310 --> 00:05:47.260 confirms that we are looking at the payload. 00:05:48.530 --> 00:05:50.160 If we take a look at our handler, 00:05:50.200 --> 00:05:53.290 we can also see that the payload was indeed sent to the stager. 00:05:54.040 --> 00:05:56.350 However, we do not have the Meterpreter prompt. 00:05:57.180 --> 00:05:59.790 The reason being that we paused the execution just 00:05:59.790 --> 00:06:01.550 before jumping into the payload. 00:06:02.240 --> 00:06:04.250 If we step over the ret instruction, 00:06:04.640 --> 00:06:06.760 you will notice that this code looks familiar. 00:06:07.740 --> 00:06:12.560 It is the code we saw in the asm_invoke_metserve method. 00:06:13.540 --> 00:06:16.010 We can see the call to the reflective loader, 00:06:16.020 --> 00:06:18.900 followed by a call to the DLL main function, 00:06:18.900 --> 00:06:24.620 which completes the initialization. At this point, if we let execution continue, 00:06:24.680 --> 00:06:27.750 it should result in a fully functional Meterpreter shell.