Hi, I'm Alessandro, a security researcher at DualSecure,
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 were 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 "-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. 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. 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 in 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 hostname 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 clone cert to do that. 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.
So this is the reason why we built this tool is to train user to avoid clicking through certificate.
Since if there is an attack tool that is efficient,
then user will be enticed to be more careful. Just like what FireSheep did with the SSL attacks.
It changes the mentality of a lot of people and made TLS enabled by default everywhere.
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.
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 gonna write the password.
Made a little mistake here.
Okay, I'm in. So 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.
And you can see that there is a 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 VirtualBox system, running the mstsc client. The VirtualBox
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 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.
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 KeePass.
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
interesting, and it's new. It was not there on older MSTSC clients. Same certificate error.
Okay, 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 gonna 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
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 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. And if we look at the files,
then you can see all the files that were collected by the system. So 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 "-i", and an IP address to this execution. The "-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-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 opens called engineering13, which is the hostname 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.
So this is very interesting and important to have an accurate representation of the connection,
which could be used in many contexts. And 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 double... 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 again 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 mapped drive. Normally, that is fine. But as you can see, with PyRDP,
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 PyRDP's context with the player.
I'm gonna 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 initial state. You can
change the speed, play. And once you play, you do have 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 a specific interaction.
This concludes our demonstration of the player's features.
PyRDP 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.
PyRDP convert.
MP4 has the format of output. The input file is a 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 PyRDP's features that are useful in the context of running
honeypots. Part of PyRDP'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
PyRDP and we are going to run the headless image. This is the command line from PyRDP.
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 Lena 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 and pressed in order to reset everything.
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. 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
pyrdp to correct, 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 pyrdp,
I will be able to log in 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 gonna input the correct credentials for the VM,
and start the man in the middle. 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. I have the warning because I have a mapped drive, and I have an
error. Let's try again. Okay, transient error. So we have the 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. pyrdp 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, pyrdp will list mapped 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 Windows system,
and its files using a mapped drive, and its files will be
explored by the man-in-the-middle component. Let's connect.
So, we have the certificate error. Yes. Now, what we see here...
Oh, 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 pyrdp-output-files-clodia-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 pyrdp system. Oh, we can see it's starting now. So, it matched a directory in the users
folder, and documents, stuff.ssh, and then stuff.passwords.keypass.database, a flag,
and so on. And you'll see also that temporary files and executables 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
command line. 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.
Pyrdp 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, pyrdp-mitm is launched with the target server and the player address to
connect to, in this case, localhost. 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, pyrdp 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.
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.
Pyrdp supports transparent proxying with the help of a few firewall rules.
Note that this technique only works on Linux and requires
running pyrdp 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 subnet we are in, we exclude our own IP address to prevent packet production loops in IP tables.
Next, create a custom routing table for pyrdp'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 distant to the server range for transparent proxying by pyrdp.
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 marked packets use the pyrdp routing table
created earlier, which will be responsible for delivering the marked packets to pyrdp
through the loopback interface. With the firewall configured, make sure to launch pyrdp as root and
provide the transparent switch to enable transparent proxying. Start vendor cap on your
land 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
pyrdp, which will then establish a connection with the intended server. This technique scales
well for internal engagements and works 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 pyrdp with a PowerShell payload that acts as a stager. This stager 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
pyrdp workstation on port 888. Start Metasploit's multi-handler to cache the reverse shell once it
is established. Next, use Python's built-in web server to host the payload that the stager will
retrieve. Make sure to disable exit on session so that multiple sessions can be intercepted.
Lastly, start armscoping 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 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.
Even if the client later disconnects from the server, the reverse shell persists.
This technique is powerful and can easily result in multiple sessions when using less
detectable payloads. This concludes our brief tour of pyrdp's features. If you'd like to see
the full feature set or get the source code, make sure to check out the pyrdp GitHub. Lastly,
if you have any war stories to share, we'd be happy to hear about them. Thanks for watching!