 Hi, I'm Alexandre, a security researcher at Yoast Secure, and today I'm with my colleague Olivier to showcase our RDP Interception tool, PyRDP. PyRDP is a tool that can be used to perform real-time RDP interception, which we designed to support both honeypots for malware research and offensive capabilities for intrusion test engagement. Today we'll be highlighting core features for both use cases. 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. In the environment for this demo, we have the PyRDP system deployed in front of a Windows Server 2016 system. PyRDP is running on a Linux system and deployed using our Docker image. The client will be a Windows 10 system running Microsoft Terminal Services, also known as MSTSC. In its default mode of operation, PyRDP will collect a lot of information, but only output significant events in its logs. The player component, which has more granular information, will be demoed later. Let's take a look at the default flags to use PyRDP. 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. The dash P here is to give the host access to the port, so RDP being on 3389. This will ensure that any connection to 3389 on the host is redirected to the Docker image. This is the Docker image name of the latest PyRDP. The monster in the middle executable that is used here, and this is the target server. 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. Let's start the PyRDP man in the middle. 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 and the volume, so they don't exist and they are created on the fly. This should probably be customized for most users. Now let's take a look at what we have if a user connects and plays around. I'm going to start the Microsoft client here. You can see the certificate error that is being generated. The PyRDP system by default will create a certificate for a host name called www.example.com. This is probably not the best. You should generate a certificate more adapted to the target or the user that you're trying to fool. We provide a tool called PyRDP Clonesert to do that. Clonesert 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. This is the reason why we built this tool, is to train users to avoid clicking through certificates. Since if there is an attack tool that is efficient, then users will be enticed to be more careful, just like what Firesheet does with the SSL attacks. It changes the mentality of a lot of people and made TLS enabled by default everywhere. With PyRDP we hope that system administrator will be more careful about those certificate errors and deploy PKI internally, which is very rarely the case in our engagements that we see. So we're going to click on yes. Now we can see several interesting things happened on the log section of the screen. 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. 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. So I'm going to write the password, made a little mistake here, I'm in. There's a secret file on the desktop. 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. You can see that clipboard data was instantly intercepted. You can see that there is credential candidates from heuristic here, scary demo gods. This is being done with a heuristic since it doesn't happen at the protocol level. We are interactively entering credentials inside the started RDP sessions. That's because we are downgrading the client's request for NLA, since NLA will resist two monster in the middle attacks. This attack resistance is rather complex and has been partially circumvented in specific cases, which we will cover in the Honeypot section later. By default, the clipboard content is intercepted. And we can see it, we'll demo it right now. 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. 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. So let me just give you an example to highlight it again. So I copied in Notepad, not even touching the MSTSC client screen. However, the information was sent to the server. So the clipboard content is being very shared, very enthusiastically with MSTSC. And also this is what happens with most RDP clients. Let's copy a few more times just to see. You should be aware that this goes beyond this. So this Windows machine is in a virtual box system running the MSTSC client. The virtual box will also notify the guest, Windows 10, of clipboard events that happen on my host. So this is very interesting because, for example, if I would paste a logline 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. And the expected happened. You can see that the clipboard data is visible here. And it happened pretty fast. 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. You'll be able to get clipboard content with most likely sensitive information, including passwords, if the user uses a password manager like KeyPass. 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. The content is then never forwarded to the server. So it's just a standard operation. There's no update of the clipboard on the server side. So next up in the demo is the file collector. RDP allows clients to share a drive UPON connection. Let's configure it. So let's disconnect. We go in local resources and then we can share whole map drives. That's interesting because the share is not at a very granular level. So this gives a lot of opportunity for attacker. A new warning is given to the user saying that it's potentially dangerous and it can harm the computer. So that's very interesting and it's new. It was not there on older MSTSC clients. Same certificate error. Let's take a look at the file share in action. So we can see that the C drive on engineering 13, which is my client, is visible through the RDP session. 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. 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. To finalize this part of the demo, we're going to stop PyRDP and look at the artifacts generated. The PyRDP output folder has several items in it, replays, which are recordings of the exact sessions, including keystrokes and screen capture, which can be replayed later. There are logs and there are files. If we look at the logs, we can see that the SSL log is also here, available here. So this is very useful, again, if you do packet capture in order to decrypt them with Wireshark or other tools. There is a JSON logs, 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. And if we look at the files, then you can see all the files that were collected by the system. We can take a look at the secret file that we saw earlier, loaded from the C drive, is here with the content. The mapping of the files to the events is available through the log files. This concludes the PyRDP demo of the monster in the middle component. 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. Let's launch both tools right now. 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 dash I and an IP address to this execution. The dash I flags tells PyRDP to send recorded RDP events to a PyRDP player over the network. This allows a player that is decoupled from the attacker's machine like the setup we have here. Now we are going to launch the player on my local system, PyRDP dash player. 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. Let's connect a client to the monster in the middle and see what the player sees. In order for the demonstration to be complete, we'll ensure that we have a map drive here, so the C drive is shared upon an RDP connection. Then let's connect. You can see that there is some activity already happening in the player interface. Now you see that a tab open called engineering 13, which is the host name that is sent by the client. The screen is visible, including the pointer position, which is hard to see right now, but if we see here with the yellow dot, now if we enter the credential, you can see on the below interface exactly the keystrokes being inputted, including special characters like space and shift or control. This is very interesting and important to have an accurate representation of the connection, which could be used in many contexts. You can see that you have also a pixel perfect representation of the interactions. This can really demonstrate the impact of an attack on RDP to executives, for instance. Additionally, if the client mapped a drive, you can explore his drive without his knowledge. So we can browse here and we can right-click and download a file on our local system RDP demo, download this here. You can also browse and explore the user's file system. So here, for example, we are loading into Dave's files and looking at his documents and we can download the many secrets files. Then on our system, RDP demo, here we go. This is a pretty interesting demonstration of the dangers of mapping a drive. You basically allow the server to query anything using file.io on your map drive. Normally, that is fine, but as you can see with Pi RDP, it can be abused. And it could also be abused with a malicious RDP server. Another feature of the player is the take control button that you can see right here. This will be demonstrated later by Alex in the offensive section of the demo. Lastly, is the ability to replay previous captures. This is called a replay in Pi RDP's context with the player. I'm going to demonstrate to you by loading a previous capture for our previous demo. So this is Susan's interactions. So what we see right now is the state, initial state. You can see that you can change the speed, play. And once you play, you do have the clipboard events, not the clipboard, but the keyboard and clipboard events at the bottom of the screen. You can also seek in the video. We see the clipboard data also here. You can scale the window so that it's easier to see globally, especially with 4K environments. And you can increase the speed of the replay. So this is very good if you're hunting for a specific session for specific interaction. This concludes our demonstration of the player's features. Pi RDP also comes with a converter tool that can be used to convert pre-recorded replay files into videos. The converter tool also accepts PCAPs and can output to replay files. Let's take a look at its option. Here we will convert a previously recorded session into a video that we will play. Pi RDP convert, P4 as the format of output, input file is RDP replay. And let's have a default output file name. Now let's look at the resulting file. In this section, we will describe Pi RDP's feature that are useful in the context of running honeypots. Part of Pi RDP's honeypot features is a headless mode. 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. For example, this is a cloud system where we want to deploy Pi RDP and we are going to run the headless image. This is the common line from Pi RDP. 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. Now let's see how long it takes. 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. And you can see that the service is running right now. Headless mode also means that we needed a headless player. Otherwise keystroke data is unavailable for command line enthusiasts. Let's see the headless player in action. We can remove the port, it's no longer required for the player, but we still need the volume mount. If we look at the options, we can see a dash dash headless at the bottom. 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. The lina file, the dump is one-shot deal. 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. So as is common with the beginning of RDP sessions, you see a lot of control character released or impressed in order to reset everything. Then you can see that I entered credentials, so demo. So the password is scary demo gods, and I made a mistake here. So this is lowercase o. 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. You can see that as soon as I was authenticated, the clipboard was shared, and this was my notes was sent to the server. 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 our PI-RDP to collect. And then I disconnected, which ends the stream. So with the headless player, you have access to all of this from the command line instead of having to load the graphical interface. Another feature specific to Honeypot use cases is credential replacement. This allows your Honeypot to accept any credentials entered by the client and relay to the server the correct set of credentials for login. For instance, although the user for this VM is PI-RDP, I will be able to login using admin and a garbage password. So let's do the demonstration. For this, I'm going to go back to using the man in the middle. As you can see below, I'm going to input the correct credentials for the VM and start the man in the middle. Now, using the MSTSC client, I'm going to put a different username here, admin lulz, to make sure that it doesn't exist. And I'm going to try to connect to the Honeypot. I have the warning because I have a map drive and I have an error. Let's try again. OK, transient error. So we have this certificate error and we got connected. And if you look at the log, you can see that in the client info, the admin lulz was supplied. PI-RDP has the ability to intercept files in transit and to allow client file system exploration from the interactive player. Last year, these capabilities were extended to allow active file querying from the monster in the middle component. When a client connects, PI-RDP will list map drives and download all the files which match a specific list of allowed files patterns. Let's see this in action. So we issue the same MITM command as during normal operation, but we add the crawl flag. Let's run it. Now we connect from the window system and its files using a map drive. And its files will be explored by the manager middle component. Let's connect. So we have the certificate error. Yes. Now what we see here, we need to authenticate before the file system is exposed to the server by the client. We authenticated. And now what we see here is a begin crawling disk C, saving secret to PI-RDP output files, Claudia secret.txt. 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. You'll also be able to notice that the directory structure is respected. So as the crawling happens in the background, the files are going to be recreated locally on the PI-RDP system. We can see it's starting now. So it matched a directory in the user's folder and documents, stuff.ssh, and then stuff passwords that keep pass database, flag, and so on. And you'll see also that temporary files and executable under the user directory are going to be saved by default. So it can take a while to gather all these files based on network conditions. The list of files to collect or to ignore can be tweaked on the common line. So with this feature, we hope that we'll be able to gather very interesting information, especially on Hunnepot system deployed in the wild. PI-RDP can also be used as an offensive security tool to gain a foothold or pivot within a network. Let's look at some attack techniques. Session hijacking can be used to take over an intercepted RDP connection. First, PI-RDP-MITM is launched with the target server and the player address to connect to, in this case, local host. Next, the player is launched and waits for intercepted sessions. The player can handle multiple sessions at the same time and will automatically display the live feed of the connected session. Clients who connect to the malicious server will receive a certificate prompt. The certificate can be customized to spoof the common name of the server. The likelihood of the certificate being accepted is considerably high, since most companies do not deploy fully signed private key infrastructures for RDP. After a successful connection is intercepted, the player can be used to monitor the screen and input of the session. When the attacker clicks the Take Control button, PI-RDP takes over the session and redirects all player inputs to the server and all server output to the player. The real RDP client appears frozen during the hijack. Once the attacker is done, the session is returned to the client, which unfreezes. This technique is noisy, but looks like a network error to the untrained eye. After the real client recovers control, there may be artifacts on the screen because the server and client will be out of sync. In order to avoid that, the screen should be left as closely as possible to its original arrangement when control is removed. Priority-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. Priority-P supports transparent proxying with the help of a few firewall rules. Note that this technique only works on Linux and requires running Priority-P as root to use IP transparent sockets. Use the firewall rule templates from the documentation directory and modify them to reflect your environment. Here, we use the address range that we will ARP spoof. Because we're spoofing the stuff that we are in, we exclude our own IP address to prevent packet reduction loops in IP tables. Next, create a custom running table for Priority-P's intercepted connections. Table ID is a number identifying the table. Ensure that IP forwarding is enabled and create a pre-routing rule that will mark all traffic distance to the server range for transparent proxying by Priority-P. The last firewall rule is used to mark traffic coming back from the servers to the clients for transparent proxy. The last step is to ensure that Mark packets use the Priority-P routing table created earlier, which will be responsible for delivering the Mark packets to Priority-P through the loopback interface. With the firewall configured, make sure to launch Priority-P as root and provide the transparent switch to enable transparent proxying. Start better cap on your LAN-facing interface and ARP spoof the subnet to intercept. Here, we set ARP spoof internal to true because we are spoofing our own subnet. This is not required when spoofing an adjacent subnet. For the demonstration, we are only spoofing one client. When the victim attempts to connect to their destination server, they will be intercepted by Priority-P, which will then establish a connection with the intended server. This technique scales well for internal engagements and worse in combination with other attacks. The last technique that we will cover is command injection, which automates session hijacking to seamlessly run a payload for an intercepted connection. Using the same transparent proxy configuration as the previous technique, start Priority-P with a PowerShell payload that acts as a stature. This stature will query a web server which hosts the real malicious payload and execute it in the context of the intercepted session. 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. The malicious payload consists of a simple PowerShell reverse shell for demonstration purposes. This shell will connect back to the Priority-P workstation on port 888. Start Minusploits multi-handler to catch the reverse shell once it is established. Next, use Python's built-in web server to host the payload that the stature will retrieve. Make sure to disable exit on session so that multiple sessions can be intercepted. Lastly, start ArmSchoolP to intercept RDP sessions as they are established. Once a session is intercepted, everything will proceed as normal from the client's point of view until the payload delay is reached. After the delay has elapsed, the client session will appear to freeze while the payload is being delivered and executed. The stature 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. Even if the client later disconnects from the server, the reverse shell persists. This technique is powerful and we can easily resolve in multiple sessions when using less detectable payloads. This concludes our brief tour of priority piece features. If you'd like to see the full feature set or get the source code, make sure to check out the priority in GitHub. Lastly, if you have any more stories to share, we'd be happy to hear about them. Thanks for watching.