WEBVTT 00:00.000 --> 00:08.680 Hi, I'm Alessandro, a security researcher at DualSecure, and today I'm with my colleague Olivier to showcase our RDP interception tool, PyRDP. 00:08.720 --> 00:19.260 PyRDP is a tool that can be used to perform real-time RDP interception, which were designed to support both honeypots for malware research and offensive capabilities for intrusion test engagement. 00:19.260 --> 00:23.000 Today we'll be highlighting core features for both use cases. 00:23.180 --> 00:31.340 In this section, I'm going to introduce you to PyRDP's core feature set, which can be used in both offensive and defensive contexts. 00:31.760 --> 00:38.920 In the environment for this demo, we have the PyRDP system deployed in front of a Windows Server 2016 system. 00:39.380 --> 00:43.800 PyRDP is running on a Linux system and deployed using our Docker image. 00:43.800 --> 00:50.320 The client will be a Windows 10 system running Microsoft Terminal Services, also known as MSTSC. 00:50.640 --> 00:59.380 In its default mode of operation, PyRDP will collect a lot of information, but only output significant events in its logs. 01:00.200 --> 01:05.820 The player component, which has more granular information, will be demoed later. 01:07.160 --> 01:11.500 Let's take a look at the default flags to use PyRDP. 01:11.500 --> 01:25.840 In this example, we run it via Docker, and we map a volume here to make sure that we have access to the artifacts generated with PyRDP after our demo, after the interactions. 01:26.160 --> 01:33.880 The "-p", here, is to give the host access to the port, so RDP being on 3389. 01:33.880 --> 01:39.660 This will ensure that any connection to 3389 on the host is redirected to the Docker image. 01:39.660 --> 01:44.000 This is the Docker image name of the latest PyRDP. 01:44.400 --> 01:51.760 The monster in the middle executable that is used here, and this is the target server. 01:51.760 --> 02:06.080 So whenever something connects on 3389 on this system, it will then forward the connection to this IP address and do its monster in the middle capabilities. 02:06.300 --> 02:11.500 Let's start the PyRDP man in the middle. 02:14.570 --> 02:25.470 You can see that SSL information or private key and certificate are generated upon the start because we didn't give them in the Docker image in the volume. 02:25.470 --> 02:28.730 So they don't exist and they are created on the fly. 02:29.250 --> 02:32.370 This should probably be customized for most users. 02:35.300 --> 02:40.480 Now let's take a look at what we have if a user connects and plays around. 02:41.460 --> 02:45.800 I'm going to start the Microsoft client here. 02:49.070 --> 02:52.990 You can see the certificate error that is being generated. 02:53.670 --> 03:02.030 The PyRDP system by default will create a certificate for a hostname called www.example.com. 03:02.030 --> 03:04.450 This is probably not the best. 03:04.450 --> 03:13.730 You should generate a certificate more adapted to the target or the user that you're trying to fool. 03:13.730 --> 03:18.470 We provide a tool called PyRDP clone cert to do that. 03:18.470 --> 03:30.290 Clone cert will connect to a specific server and copy the information from the certificate in a certificate key pair that you can then use with PyRDP. 03:31.470 --> 03:39.530 So this is the reason why we built this tool is to train user to avoid clicking through certificate. 03:39.530 --> 03:47.730 Since if there is an attack tool that is efficient, then user will be enticed to be more careful. 03:47.730 --> 03:52.670 Just like what FireSheep did with the SSL attacks. 03:52.670 --> 03:59.350 It changes the mentality of a lot of people and made TLS enabled by default everywhere. 03:59.350 --> 04:11.810 Well with PyRDP we hope that system administrator will be more careful about those certificate errors and deploy a PKI internally, which is very rarely the case in our engagements that we see. 04:12.510 --> 04:14.690 So we're going to click on yes. 04:16.590 --> 04:23.890 Now we can see several interesting things happened on the log section of the screen. 04:23.890 --> 04:38.710 You can see that the client random is logged, which is very interesting if you ever take packet capture, you can then decrypt and do very granular protocol level analysis of the RDP connection. 04:40.580 --> 04:54.920 On the system we get a password prompt, which is different than the usual password prompt, because we downgrade the authentication and it's now interactive, it's now part of the session. 04:54.920 --> 04:58.780 So I'm gonna write the password. 05:03.340 --> 05:05.920 Made a little mistake here. 05:11.530 --> 05:13.650 Okay, I'm in. 05:17.910 --> 05:21.250 So there's a secret file on the desktop. 05:22.470 --> 05:36.230 But you can see in the logs that channel information is logged, username, since it was not typed and not sent by the client, is not there. 05:37.470 --> 05:41.730 You can see that clipboard data was instantly intercepted. 05:42.990 --> 05:50.190 And you can see that there is a credential candidates from heuristic here, scary demo gods. 05:52.630 --> 05:57.350 This is being done with a heuristic since it doesn't happen at the protocol level. 05:57.350 --> 06:02.930 We are interactively entering credentials inside the started RDP sessions. 06:02.970 --> 06:11.190 That's because we are downgrading the client's request for NLA, since NLA will resist two monster in the middle attacks. 06:11.190 --> 06:20.570 This attack resistance is rather complex and has been partially circumvented in specific cases, which we will cover in the honeypot section later. 06:23.360 --> 06:27.860 By default, the clipboard content is intercepted. 06:27.860 --> 06:32.580 And we can see it, we'll demo it right now. 06:33.080 --> 06:49.520 So if we open this many secret file and we put it in the clipboard, you can see right away, instantly, that it was intercepted on the server side, in the logs. 06:49.640 --> 07:04.040 What's interesting that you might not have noticed here, is that I didn't interact with the mstsc client when the output showed in the logs. 07:04.080 --> 07:07.540 So let me just give you an example to highlight it again. 07:07.540 --> 07:13.400 So I copied in notepad, not even touching the mstsc client screen. 07:13.400 --> 07:19.000 However, the information was sent to the server. 07:19.000 --> 07:25.820 So the clipboard content is being very shared, very enthusiastically, with mstsc. 07:25.880 --> 07:30.920 And also, this is what happens with most RDP clients. 07:34.910 --> 07:38.350 Let's copy a few more times, just to see... 07:40.570 --> 07:44.890 You should be aware that this goes beyond this. 07:44.890 --> 07:51.590 So this Windows machine is in a VirtualBox system, running the mstsc client. 07:52.070 --> 08:00.110 The VirtualBox will also notify the guest, Windows 10, of clipboard events that happen on my host. 08:00.230 --> 08:22.610 So this is very interesting, because, for example, if I would paste a log line here on my clipboard, what we would expect is the information to flow from my host, to my guest, from the guest OS clipboard, to the mstsc client, and then to the intercepted system. 08:24.030 --> 08:27.750 And, the expected happened. 08:27.750 --> 08:31.630 You can see that the clipboard data is visible here. 08:31.630 --> 08:34.730 And it happened pretty fast. 08:35.870 --> 08:56.050 So this is a very interesting capability, that will probably allow some information to be leaked, if we ever intercept bad actors, or in a penetration testing context, you can gather a lot of information, if an administrator leaves an RDP window open in the background for a long time. 08:56.050 --> 09:06.330 You'll be able to get clipboard content with, most likely, sensitive information, including passwords, if the user uses a password manager like KeePass. 09:12.810 --> 09:23.070 What happens here is that PyRDP just receives a message about new clipboard content, and will send to the client a message saying, I need it. 09:23.070 --> 09:26.550 The content is then never forwarded to the server. 09:26.550 --> 09:30.470 So it's just a standard operation. 09:30.470 --> 09:33.890 There's no update of the clipboard on the server side. 09:34.250 --> 09:38.170 So next up in the demo is the file collector. 09:38.350 --> 09:42.630 RDP allows clients to share a drive upon connection. 09:42.630 --> 09:44.470 Let's configure it. 09:46.330 --> 09:48.610 So let's disconnect. 10:00.780 --> 10:08.400 We go in local resources, and then we can share whole map drives. 10:09.260 --> 10:13.300 That's interesting, because the share is not at a very granular level. 10:13.300 --> 10:17.080 So this gives a lot of opportunity for attacker. 10:26.540 --> 10:38.200 A new warning is given to the user, saying that it's potentially dangerous, and it can harm the computer. 10:38.200 --> 10:40.780 So that's interesting, and it's new. 10:40.780 --> 10:45.060 It was not there on older MSTSC clients. 10:50.510 --> 10:52.530 Same certificate error. 10:54.750 --> 10:55.470 Okay, 11:10.180 --> 11:14.780 let's take a look at the file share in action. 11:17.360 --> 11:29.360 So we can see that the C drive on engineering 13, which is my client, is visible through the RDP session. 11:30.100 --> 11:44.260 What happens if we click on it, is we get access to the information on it, and we see at the same time information being collected by the PyRDP system. 11:48.350 --> 12:03.450 If we open the secret.txt file on the root of the C drive, we also notice that the information was saved by PyRDP in the output folder. 12:08.510 --> 12:17.530 To finalize this part of the demo, we're gonna stop PyRDP and look at the artifacts generated. 12:29.960 --> 12:35.600 The PyRDP output folder has several items in it. 12:35.600 --> 12:48.880 Replays, which are recordings of the exact sessions, including keystrokes and screen capture, which can be replayed later. 12:51.170 --> 12:56.910 There are logs and there are files. 12:59.010 --> 13:08.830 If we look at the logs, we can see that the SSL log is also available here. 13:09.010 --> 13:17.110 So this is very useful, again, if you do packet capture in order to decrypt them with Wireshark or other tools. 13:17.590 --> 13:31.790 There is a JSON log, which will be covered later, and there is a man-in-the-middle log, which is the exact output that was available from inside, that you could see on the command line. 13:35.730 --> 13:43.850 And if we look at the files, then you can see all the files that were collected by the system. 13:54.890 --> 13:57.410 So we can take a look at the 14:01.890 --> 14:08.970 secret file that we saw earlier, loaded from the C drive, is here with the content. 14:08.970 --> 14:17.510 The mapping of the files to the events is available through the log files. 14:19.450 --> 14:25.410 This concludes the PyRDP demo of the monster-in-the-middle component. 14:27.170 --> 14:38.730 If you need fine-grained content, like keystrokes, and see the screen during an active attack, you need to combine the use of the PyRDP MITM tool with the PyRDP player. 14:38.930 --> 14:41.450 Let's launch both tools right now. 14:42.090 --> 14:54.690 Here I'm bringing up the previous command that we used to run just the monster-in-the-middle component, and now I'm going to add "-i", and an IP address to this execution. 14:58.070 --> 15:06.130 The "-i"-flags tells PyRDP to send recorded RDP events to a PyRDP player over the network. 15:06.190 --> 15:12.550 This allows a player that is decoupled from the attacker's machine, like the setup we have here. 15:13.450 --> 15:18.610 Now we are going to launch the player on my local system, 15:21.990 --> 15:24.370 pyrdp -player. 15:28.010 --> 15:41.830 You can see that it is a Qt interface, and that it has tabs for live connections and replays, so live activity and replay, or previously recorded activities. 15:41.850 --> 15:47.710 Let's connect a client to the monster-in-the-middle and see what the player sees. 15:54.300 --> 16:00.800 In order for the demonstration to be complete, we'll ensure that we have a map drive here. 16:00.800 --> 16:05.580 So the C drive is shared upon an RDP connection. 16:07.360 --> 16:09.520 Then let's connect. 16:11.810 --> 16:17.410 You can see that there is some activity already happening in the player interface. 16:20.120 --> 16:27.900 Now, you see that a tab opens called engineering13, which is the hostname that is sent by the client. 16:29.540 --> 16:40.420 The screen is visible, including the pointer position, which is hard to see right now, but if we see here with the yellow dot. 16:40.600 --> 16:44.060 Now if we enter the credential, 16:47.640 --> 17:04.320 you can see on the below interface exactly the keystrokes being inputted, including special characters like space and shift or control. 17:05.400 --> 17:16.840 So this is very interesting and important to have an accurate representation of the connection, which could be used in many contexts. 17:16.840 --> 17:24.740 And you can see that you have also a pixel-perfect representation of the interactions. 17:25.220 --> 17:34.480 This can really demonstrate the impact of an attack on RDP to executives, for instance. 17:37.370 --> 17:43.850 Additionally, if the client mapped a drive, you can explore his drive without his knowledge. 17:43.850 --> 17:55.770 So we can browse here and we can double... we can right-click and download a file on our local system. 17:58.010 --> 17:59.590 RDP demo. 18:00.130 --> 18:02.090 Download this here. 18:04.160 --> 18:11.930 You can also browse and explore the user's file system. 18:11.930 --> 18:20.290 So here, for example, we are loading into Dave's files and looking at his documents. 18:20.290 --> 18:28.310 And we can download the many secrets files again on our system. 18:31.020 --> 18:33.040 RDP demo. 18:33.900 --> 18:35.300 Here we go. 18:38.370 --> 18:43.630 This is a pretty interesting demonstration of the dangers of mapping a drive. 18:43.630 --> 18:49.550 You basically allow the server to query anything using File.io on your mapped drive. 18:49.670 --> 18:51.630 Normally, that is fine. 18:51.890 --> 18:55.670 But as you can see, with PyRDP, it can be abused. 18:55.670 --> 18:59.390 And it could also be abused with a malicious RDP server. 19:01.170 --> 19:07.010 Another feature of the player is the Take Control button that you can see right here. 19:07.530 --> 19:13.970 This will be demonstrated later by Alex in the offensive section of the demo. 19:15.070 --> 19:19.790 Lastly, is the ability to replay previous captures. 19:21.960 --> 19:27.120 This is called a replay in PyRDP's context with the player. 19:27.940 --> 19:34.320 I'm gonna demonstrate to you by loading a previous capture for our previous demo. 19:35.480 --> 19:39.000 So this is Susan's interactions. 19:40.140 --> 19:45.100 So what we see right now is the initial state. 19:45.100 --> 19:48.320 You can change the speed, play. 19:48.320 --> 19:57.460 And once you play, you do have the keyboard and clipboard events at the bottom of the screen. 19:57.480 --> 20:00.700 You can also seek in the video. 20:02.580 --> 20:07.320 We see the clipboard data also here. 20:07.880 --> 20:15.920 You can scale the window so that it's easier to see globally, especially with 4K environments. 20:16.840 --> 20:21.170 And you can increase the speed of the replay. 20:22.050 --> 20:27.850 So this is very good if you're hunting for a specific session for a specific interaction. 20:31.610 --> 20:35.720 This concludes our demonstration of the player's features. 20:37.890 --> 20:45.130 PyRDP also comes with a converter tool that can be used to convert pre-recorded replay files into videos. 20:45.130 --> 20:51.410 The converter tool also accepts PCAPs and can output to replay files. 20:51.990 --> 20:56.430 Let's take a look at its option. 21:01.960 --> 21:07.800 Here we will convert a previously recorded session into a video that we will play. 21:08.760 --> 21:11.200 PyRDP convert. 21:12.160 --> 21:16.300 MP4 has the format of output. 21:18.420 --> 21:28.300 The input file is a RDP replay. 21:29.200 --> 21:33.520 And let's have a default output file name. 22:05.910 --> 22:09.490 Now let's look at the resulting file. 22:26.510 --> 22:32.610 In this section we will describe PyRDP's features that are useful in the context of running honeypots. 22:32.610 --> 22:36.810 Part of PyRDP's honeypot features is a headless mode. 22:36.810 --> 22:48.570 This enables server-side deployments, running it on non-x86 systems like a Raspberry Pi, and allowed us to significantly reduce the size of our docker image. 22:49.130 --> 22:58.210 For example, this is a cloud system where we want to deploy PyRDP and we are going to run the headless image. 23:01.140 --> 23:04.210 This is the command line from PyRDP. 23:05.380 --> 23:24.620 This pulls in the latest master branch image and we are going to use the slim tag so that we are going to use the smaller version of our image without the graphical interface features and the video conversion features. 23:24.620 --> 23:28.120 Now let's see how long it takes. 23:33.830 --> 23:48.150 The new image is 70 megabytes, which is pretty good for a Python docker image with native code, down from 600 megabytes for our latest release. 23:48.890 --> 23:53.470 And you can see that the service is running right now. 23:53.610 --> 24:02.110 Headless mode also means that we needed a headless player, otherwise keystroke data is unavailable for command line enthusiasts. 24:05.190 --> 24:10.150 Let's see the headless player in action. 24:12.530 --> 24:19.370 We can remove the port, it's no longer required for the player, but we still need the volume mount. 24:23.140 --> 24:30.160 If we look at the options, we can see a dash dash headless at the bottom. 24:30.460 --> 24:41.020 So usually the player is the graphical interface with the Qt, but the new headless feature allows us to look at replay files without the GUI. 24:49.660 --> 24:52.480 The Lena file. 24:55.050 --> 24:59.690 The dump is one shot deal. 24:59.690 --> 25:14.050 You get all of the output at once, but you can go back and see everything that was collected, including clicks and stuff that was sent during the connection. 25:14.190 --> 25:23.040 So as is common with the beginning of RDP sessions, you see a lot of control character released and pressed in order to reset everything. 25:23.520 --> 25:40.280 Then you can see that I entered credentials, so the password is scary demo gods, and I made a mistake here, so this is a lowercase o. 25:40.280 --> 25:54.380 You can see also the backspace that are pressed, so I started with demo instead of scary, so de backspace backspace scary, but then I made a mistake, so I authenticated again. 25:55.880 --> 26:04.700 You can see that as soon as I was authenticated, the clipboard was shared, and this was my notes was sent to the server. 26:04.920 --> 26:25.840 Then you can see some clicks, and then during that demo, I pasted several secrets to show how easy it was to leak data to the server system and easy for pyrdp to correct, and then I disconnected, which ends the stream. 26:25.840 --> 26:33.660 So with the headless player, you have access to all of this from the command line, instead of having to load the graphical interface. 26:33.720 --> 26:38.140 Another feature specific to honeypot use cases is credential replacement. 26:38.580 --> 26:46.760 This allows your honeypot to accept any credentials entered by the client, and relay to the server the correct set of credentials for login. 26:46.760 --> 26:55.380 For instance, although the user for this VM is pyrdp, I will be able to log in using admin and a garbage password. 26:56.300 --> 26:59.760 So let's do the demonstration. 27:00.160 --> 27:05.580 For this, I'm going to go back to using the man in the middle. 27:06.060 --> 27:14.300 As you can see below, I'm gonna input the correct credentials for the VM, 27:17.850 --> 27:20.150 and start the man in the middle. 27:24.040 --> 27:41.030 Now, using the mstsc client, I'm gonna put a different username here, admin lulz, to make sure that it doesn't exist, and I'm gonna attempt to, I'm gonna try to connect to the honeypot. 27:42.490 --> 27:51.640 I have the warning because I have a mapped drive, and I have an error. 27:58.110 --> 28:00.010 Let's try again. 28:04.760 --> 28:07.800 Okay, transient error. 28:10.340 --> 28:12.830 So we have the certificate error, 28:17.600 --> 28:19.920 and we got connected. 28:20.260 --> 28:28.100 And if you look at the log, you can see that in the client info, the admin lulz was supplied. 28:28.840 --> 28:36.940 pyrdp has the ability to intercept files in transit, and to allow client file system exploration from the interactive player. 28:37.080 --> 28:43.640 Last year, these capabilities were extended to allow active file querying from the monster in the middle component. 28:43.820 --> 28:53.220 When a client connects, pyrdp will list mapped drives and download all the files which match a specific list of allowed files patterns. 28:53.320 --> 28:55.100 Let's see this in action. 28:56.060 --> 29:10.080 So, we issue the same MITM command as during normal operation, but we add the crawl flag. 29:10.080 --> 29:12.300 Let's run it. 29:13.420 --> 29:29.080 Now, we connect from the Windows system, and its files using a mapped drive, and its files will be explored by the man-in-the-middle component. 29:31.360 --> 29:33.200 Let's connect. 29:34.280 --> 29:37.400 So, we have the certificate error. 29:37.400 --> 29:38.380 Yes. 29:39.960 --> 29:41.170 Now, what we see here... 29:42.660 --> 29:50.130 Oh, we need to authenticate before the file system is exposed to the server by the client. 29:56.240 --> 29:58.220 We authenticated. 29:59.180 --> 30:10.480 And now, what we see here is a begin-crawling-disk C, saving secret to pyrdp-output-files-clodia-secret.txt. 30:10.480 --> 30:19.760 So, this file was at the root of the C drive, and so this is why it was the first to be collected, and it was quite fast. 30:19.760 --> 30:25.820 You'll also be able to notice that the directory structure is respected. 30:25.900 --> 30:36.860 So, as the crawling happens in the background, the files are going to be recreated locally on the pyrdp system. 30:36.940 --> 30:39.080 Oh, we can see it's starting now. 30:39.080 --> 30:55.700 So, it matched a directory in the users folder, and documents, stuff.ssh, and then stuff.passwords.keypass.database, a flag, and so on. 30:55.700 --> 31:03.180 And you'll see also that temporary files and executables under the user directory are going to be saved by default. 31:03.680 --> 31:10.280 So, it can take a while to gather all these files based on network conditions. 31:10.320 --> 31:15.920 The list of files to collect or to ignore can be tweaked on the command line. 31:16.480 --> 31:24.640 So, with this feature, we hope that we'll be able to gather very interesting information, especially on Honeypot's system deployed in the wild. 31:26.420 --> 31:32.180 Pyrdp can also be used as an offensive security tool to gain a foothold or pivot within a network. 31:32.180 --> 31:34.220 Let's look at some attack techniques. 31:34.480 --> 31:39.160 Session hijacking can be used to take over an intercepted RDP connection. 31:39.160 --> 31:46.500 First, pyrdp-mitm is launched with the target server and the player address to connect to, in this case, localhost. 31:57.840 --> 32:01.340 Next, the player is launched and waits for intercepted sessions. 32:01.340 --> 32:07.740 The player can handle multiple sessions at the same time and will automatically display the live feed of the connected session. 32:09.900 --> 32:14.140 Clients who connect to the malicious server will receive a certificate prompt. 32:14.200 --> 32:17.780 The certificate can be customized to spoof the common name of the server. 32:18.040 --> 32:26.320 The likelihood of the certificate being accepted is considerably high, since most companies do not deploy fully signed private key infrastructures for RDP. 32:27.760 --> 32:34.280 After a successful connection is intercepted, the player can be used to monitor the screen and input of the session. 32:39.830 --> 32:49.050 When the attacker clicks the take control button, pyrdp takes over the session and redirects all player inputs to the server and all server output to the player. 32:49.050 --> 32:52.970 The real RDP client appears frozen during the hijack. 32:52.990 --> 32:57.470 Once the attacker is done, the session is returned to the client, which unfreezes. 32:57.750 --> 33:02.090 This technique is noisy, but looks like a network error to the untrained eye. 33:03.610 --> 33:10.370 After the real client recovers control, there may be artifacts on the screen because the server and client will be out of sync. 33:10.590 --> 33:17.230 In order to avoid that, the screen should be left as closely as possible to its original arrangement when control is removed. 33:19.390 --> 33:29.070 Hiring a specific server does not scale well during engagements, because it will most likely redirect intercepted sessions to a server which isn't the one that the client tried to connect to. 33:29.230 --> 33:33.910 Pyrdp supports transparent proxying with the help of a few firewall rules. 33:34.130 --> 33:40.910 Note that this technique only works on Linux and requires running pyrdp as root to use IP transparent sockets. 33:42.290 --> 33:48.270 Use the firewall rule templates from the documentation directory and modify them to reflect your environment. 33:48.570 --> 33:51.850 Here, we use the address range that we will ARP spoof. 33:51.850 --> 33:58.750 Because we're spoofing the subnet we are in, we exclude our own IP address to prevent packet production loops in IP tables. 33:59.710 --> 34:04.290 Next, create a custom routing table for pyrdp's intercepted connections. 34:04.290 --> 34:07.190 Table ID is a number identifying the table. 34:09.210 --> 34:18.630 Ensure that IP forwarding is enabled and create a pre-routing rule that will mark all traffic distant to the server range for transparent proxying by pyrdp. 34:35.800 --> 34:42.660 The last firewall rule is used to mark traffic coming back from the servers to the clients for transparent proxy. 35:01.750 --> 35:12.370 The last step is to ensure that marked packets use the pyrdp routing table created earlier, which will be responsible for delivering the marked packets to pyrdp through the loopback interface. 35:20.710 --> 35:28.250 With the firewall configured, make sure to launch pyrdp as root and provide the transparent switch to enable transparent proxying. 35:37.180 --> 35:42.340 Start vendor cap on your land facing interface and ARP spoof the subnet to intercept. 35:49.190 --> 35:53.890 Here, we set ARP spoof internal to true because we are spoofing our own subnet. 35:53.890 --> 35:56.750 This is not required when spoofing an adjacent subnet. 35:56.750 --> 36:00.230 For the demonstration, we are only spoofing one client. 36:12.260 --> 36:21.260 When the victim attempts to connect to their destination server, they will be intercepted by pyrdp, which will then establish a connection with the intended server. 36:21.260 --> 36:26.500 This technique scales well for internal engagements and works in combination with other attacks. 36:30.650 --> 36:39.350 The last technique that we will cover is command injection, which automates session hijacking to seamlessly run a payload for an intercepted connection. 36:39.350 --> 36:47.270 Using the same transparent proxy configuration as the previous technique, start pyrdp with a PowerShell payload that acts as a stager. 36:47.570 --> 36:55.270 This stager will query a web server which hosts the real malicious payload and execute it in the context of the intercepted session . 36:55.690 --> 37:04.390 The payload delay and payload duration parameters are used to control when the payload should be executed and how long to hijack the session for. 37:05.810 --> 37:11.590 The malicious payload consists of a simple PowerShell reverse shell for demonstration purposes. 37:11.590 --> 37:16.130 This shell will connect back to the pyrdp workstation on port 888. 37:21.110 --> 37:25.870 Start Metasploit's multi-handler to cache the reverse shell once it is established. 37:36.750 --> 37:42.270 Next, use Python's built-in web server to host the payload that the stager will retrieve. 37:47.270 --> 37:52.790 Make sure to disable exit on session so that multiple sessions can be intercepted. 38:09.740 --> 38:15.120 Lastly, start armscoping to intercept RDP sessions as they are established. 38:49.500 --> 38:56.500 Once a session is intercepted, everything will proceed as normal from the client's point of view until the payload delay is reached. 38:56.500 --> 39:03.080 After the delay has elapsed, the client session will appear to freeze while the payload is being delivered and executed. 39:03.640 --> 39:13.480 The stager retrieves the code from the server and executes it, causing the reverse shell to connect to the Metasploit listener and giving the attacker covert access to the target server. 39:26.320 --> 39:30.980 Even if the client later disconnects from the server, the reverse shell persists. 39:31.540 --> 39:37.760 This technique is powerful and can easily result in multiple sessions when using less detectable payloads. 39:43.870 --> 39:47.250 This concludes our brief tour of pyrdp's features. 39:47.250 --> 39:53.410 If you'd like to see the full feature set or get the source code, make sure to check out the pyrdp GitHub. 39:53.770 --> 39:58.270 Lastly, if you have any war stories to share, we'd be happy to hear about them. 39:58.270 --> 39:59.370 Thanks for watching!