1
00:00:00,000 --> 00: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.

2
00:00:08,720 --> 00: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.

3
00:00:19,260 --> 00:00:23,000
Today we'll be highlighting core features for both use cases.

4
00:00:23,180 --> 00: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.

5
00:00:31,760 --> 00:00:38,920
In the environment for this demo, we have the PyRDP system deployed in front of a Windows Server 2016 system.

6
00:00:39,380 --> 00:00:43,800
PyRDP is running on a Linux system and deployed using our Docker image.

7
00:00:43,800 --> 00:00:50,320
The client will be a Windows 10 system running Microsoft Terminal Services, also known as MSTSC.

8
00:00:50,640 --> 00:00:59,380
In its default mode of operation, PyRDP will collect a lot of information, but only output significant events in its logs.

9
00:01:00,200 --> 00:01:05,820
The player component, which has more granular information, will be demoed later.

10
00:01:07,160 --> 00:01:11,500
Let's take a look at the default flags to use PyRDP.

11
00:01:11,500 --> 00: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.

12
00:01:26,160 --> 00:01:33,880
The "-p", here, is to give the host access to the port, so RDP being on 3389.

13
00:01:33,880 --> 00:01:39,660
This will ensure that any connection to 3389 on the host is redirected to the Docker image.

14
00:01:39,660 --> 00:01:44,000
This is the Docker image name of the latest PyRDP.

15
00:01:44,400 --> 00:01:51,760
The monster in the middle executable that is used here, and this is the target server.

16
00:01:51,760 --> 00: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.

17
00:02:06,300 --> 00:02:11,500
Let's start the PyRDP man in the middle.

18
00:02:14,570 --> 00: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.

19
00:02:25,470 --> 00:02:28,730
So they don't exist and they are created on the fly.

20
00:02:29,250 --> 00:02:32,370
This should probably be customized for most users.

21
00:02:35,300 --> 00:02:40,480
Now let's take a look at what we have if a user connects and plays around.

22
00:02:41,460 --> 00:02:45,800
I'm going to start the Microsoft client here.

23
00:02:49,070 --> 00:02:52,990
You can see the certificate error that is being generated.

24
00:02:53,670 --> 00:03:02,030
The PyRDP system by default will create a certificate for a hostname called www.example.com.

25
00:03:02,030 --> 00:03:04,450
This is probably not the best.

26
00:03:04,450 --> 00:03:13,730
You should generate a certificate more adapted to the target or the user that you're trying to fool.

27
00:03:13,730 --> 00:03:18,470
We provide a tool called PyRDP clone cert to do that.

28
00:03:18,470 --> 00: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.

29
00:03:31,470 --> 00:03:39,530
So this is the reason why we built this tool is to train user to avoid clicking through certificate.

30
00:03:39,530 --> 00:03:47,730
Since if there is an attack tool that is efficient, then user will be enticed to be more careful.

31
00:03:47,730 --> 00:03:52,670
Just like what FireSheep did with the SSL attacks.

32
00:03:52,670 --> 00:03:59,350
It changes the mentality of a lot of people and made TLS enabled by default everywhere.

33
00:03:59,350 --> 00: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.

34
00:04:12,510 --> 00:04:14,690
So we're going to click on yes.

35
00:04:16,590 --> 00:04:23,890
Now we can see several interesting things happened on the log section of the screen.

36
00:04:23,890 --> 00: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.

37
00:04:40,580 --> 00: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.

38
00:04:54,920 --> 00:04:58,780
So I'm gonna write the password.

39
00:05:03,340 --> 00:05:05,920
Made a little mistake here.

40
00:05:11,530 --> 00:05:13,650
Okay, I'm in.

41
00:05:17,910 --> 00:05:21,250
So there's a secret file on the desktop.

42
00:05:22,470 --> 00: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.

43
00:05:37,470 --> 00:05:41,730
You can see that clipboard data was instantly intercepted.

44
00:05:42,990 --> 00:05:50,190
And you can see that there is a credential candidates from heuristic here, scary demo gods.

45
00:05:52,630 --> 00:05:57,350
This is being done with a heuristic since it doesn't happen at the protocol level.

46
00:05:57,350 --> 00:06:02,930
We are interactively entering credentials inside the started RDP sessions.

47
00:06:02,970 --> 00: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.

48
00:06:11,190 --> 00: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.

49
00:06:23,360 --> 00:06:27,860
By default, the clipboard content is intercepted.

50
00:06:27,860 --> 00:06:32,580
And we can see it, we'll demo it right now.

51
00:06:33,080 --> 00: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.

52
00:06:49,640 --> 00: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.

53
00:07:04,080 --> 00:07:07,540
So let me just give you an example to highlight it again.

54
00:07:07,540 --> 00:07:13,400
So I copied in notepad, not even touching the mstsc client screen.

55
00:07:13,400 --> 00:07:19,000
However, the information was sent to the server.

56
00:07:19,000 --> 00:07:25,820
So the clipboard content is being very shared, very enthusiastically, with mstsc.

57
00:07:25,880 --> 00:07:30,920
And also, this is what happens with most RDP clients.

58
00:07:34,910 --> 00:07:38,350
Let's copy a few more times, just to see...

59
00:07:40,570 --> 00:07:44,890
You should be aware that this goes beyond this.

60
00:07:44,890 --> 00:07:51,590
So this Windows machine is in a VirtualBox system, running the mstsc client.

61
00:07:52,070 --> 00:08:00,110
The VirtualBox will also notify the guest, Windows 10, of clipboard events that happen on my host.

62
00:08:00,230 --> 00: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.

63
00:08:24,030 --> 00:08:27,750
And, the expected happened.

64
00:08:27,750 --> 00:08:31,630
You can see that the clipboard data is visible here.

65
00:08:31,630 --> 00:08:34,730
And it happened pretty fast.

66
00:08:35,870 --> 00: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.

67
00:08:56,050 --> 00: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.

68
00:09:12,810 --> 00: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.

69
00:09:23,070 --> 00:09:26,550
The content is then never forwarded to the server.

70
00:09:26,550 --> 00:09:30,470
So it's just a standard operation.

71
00:09:30,470 --> 00:09:33,890
There's no update of the clipboard on the server side.

72
00:09:34,250 --> 00:09:38,170
So next up in the demo is the file collector.

73
00:09:38,350 --> 00:09:42,630
RDP allows clients to share a drive upon connection.

74
00:09:42,630 --> 00:09:44,470
Let's configure it.

75
00:09:46,330 --> 00:09:48,610
So let's disconnect.

76
00:10:00,780 --> 00:10:08,400
We go in local resources, and then we can share whole map drives.

77
00:10:09,260 --> 00:10:13,300
That's interesting, because the share is not at a very granular level.

78
00:10:13,300 --> 00:10:17,080
So this gives a lot of opportunity for attacker.

79
00:10:26,540 --> 00:10:38,200
A new warning is given to the user, saying that it's potentially dangerous, and it can harm the computer.

80
00:10:38,200 --> 00:10:40,780
So that's interesting, and it's new.

81
00:10:40,780 --> 00:10:45,060
It was not there on older MSTSC clients.

82
00:10:50,510 --> 00:10:52,530
Same certificate error.

83
00:10:54,750 --> 00:10:55,470
Okay,

84
00:11:10,180 --> 00:11:14,780
let's take a look at the file share in action.

85
00:11:17,360 --> 00:11:29,360
So we can see that the C drive on engineering 13, which is my client, is visible through the RDP session.

86
00:11:30,100 --> 00: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.

87
00:11:48,350 --> 00: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.

88
00:12:08,510 --> 00:12:17,530
To finalize this part of the demo, we're gonna stop PyRDP and look at the artifacts generated.

89
00:12:29,960 --> 00:12:35,600
The PyRDP output folder has several items in it.

90
00:12:35,600 --> 00:12:48,880
Replays, which are recordings of the exact sessions, including keystrokes and screen capture, which can be replayed later.

91
00:12:51,170 --> 00:12:56,910
There are logs and there are files.

92
00:12:59,010 --> 00:13:08,830
If we look at the logs, we can see that the SSL log is also available here.

93
00:13:09,010 --> 00:13:17,110
So this is very useful, again, if you do packet capture in order to decrypt them with Wireshark or other tools.

94
00:13:17,590 --> 00: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.

95
00:13:35,730 --> 00:13:43,850
And if we look at the files, then you can see all the files that were collected by the system.

96
00:13:54,890 --> 00:13:57,410
So we can take a look at the

97
00:14:01,890 --> 00:14:08,970
secret file that we saw earlier, loaded from the C drive, is here with the content.

98
00:14:08,970 --> 00:14:17,510
The mapping of the files to the events is available through the log files.

99
00:14:19,450 --> 00:14:25,410
This concludes the PyRDP demo of the monster-in-the-middle component.

100
00:14:27,170 --> 00: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.

101
00:14:38,930 --> 00:14:41,450
Let's launch both tools right now.

102
00:14:42,090 --> 00: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.

103
00:14:58,070 --> 00:15:06,130
The "-i"-flags tells PyRDP to send recorded RDP events to a PyRDP player over the network.

104
00:15:06,190 --> 00:15:12,550
This allows a player that is decoupled from the attacker's machine, like the setup we have here.

105
00:15:13,450 --> 00:15:18,610
Now we are going to launch the player on my local system,

106
00:15:21,990 --> 00:15:24,370
pyrdp -player.

107
00:15:28,010 --> 00: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.

108
00:15:41,850 --> 00:15:47,710
Let's connect a client to the monster-in-the-middle and see what the player sees.

109
00:15:54,300 --> 00:16:00,800
In order for the demonstration to be complete, we'll ensure that we have a map drive here.

110
00:16:00,800 --> 00:16:05,580
So the C drive is shared upon an RDP connection.

111
00:16:07,360 --> 00:16:09,520
Then let's connect.

112
00:16:11,810 --> 00:16:17,410
You can see that there is some activity already happening in the player interface.

113
00:16:20,120 --> 00:16:27,900
Now, you see that a tab opens called engineering13, which is the hostname that is sent by the client.

114
00:16:29,540 --> 00: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.

115
00:16:40,600 --> 00:16:44,060
Now if we enter the credential,

116
00:16:47,640 --> 00:17:04,320
you can see on the below interface exactly the keystrokes being inputted, including special characters like space and shift or control.

117
00:17:05,400 --> 00: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.

118
00:17:16,840 --> 00:17:24,740
And you can see that you have also a pixel-perfect representation of the interactions.

119
00:17:25,220 --> 00:17:34,480
This can really demonstrate the impact of an attack on RDP to executives, for instance.

120
00:17:37,370 --> 00:17:43,850
Additionally, if the client mapped a drive, you can explore his drive without his knowledge.

121
00:17:43,850 --> 00:17:55,770
So we can browse here and we can double... we can right-click and download a file on our local system.

122
00:17:58,010 --> 00:17:59,590
RDP demo.

123
00:18:00,130 --> 00:18:02,090
Download this here.

124
00:18:04,160 --> 00:18:11,930
You can also browse and explore the user's file system.

125
00:18:11,930 --> 00:18:20,290
So here, for example, we are loading into Dave's files and looking at his documents.

126
00:18:20,290 --> 00:18:28,310
And we can download the many secrets files again on our system.

127
00:18:31,020 --> 00:18:33,040
RDP demo.

128
00:18:33,900 --> 00:18:35,300
Here we go.

129
00:18:38,370 --> 00:18:43,630
This is a pretty interesting demonstration of the dangers of mapping a drive.

130
00:18:43,630 --> 00:18:49,550
You basically allow the server to query anything using File.io on your mapped drive.

131
00:18:49,670 --> 00:18:51,630
Normally, that is fine.

132
00:18:51,890 --> 00:18:55,670
But as you can see, with PyRDP, it can be abused.

133
00:18:55,670 --> 00:18:59,390
And it could also be abused with a malicious RDP server.

134
00:19:01,170 --> 00:19:07,010
Another feature of the player is the Take Control button that you can see right here.

135
00:19:07,530 --> 00:19:13,970
This will be demonstrated later by Alex in the offensive section of the demo.

136
00:19:15,070 --> 00:19:19,790
Lastly, is the ability to replay previous captures.

137
00:19:21,960 --> 00:19:27,120
This is called a replay in PyRDP's context with the player.

138
00:19:27,940 --> 00:19:34,320
I'm gonna demonstrate to you by loading a previous capture for our previous demo.

139
00:19:35,480 --> 00:19:39,000
So this is Susan's interactions.

140
00:19:40,140 --> 00:19:45,100
So what we see right now is the initial state.

141
00:19:45,100 --> 00:19:48,320
You can change the speed, play.

142
00:19:48,320 --> 00:19:57,460
And once you play, you do have the keyboard and clipboard events at the bottom of the screen.

143
00:19:57,480 --> 00:20:00,700
You can also seek in the video.

144
00:20:02,580 --> 00:20:07,320
We see the clipboard data also here.

145
00:20:07,880 --> 00:20:15,920
You can scale the window so that it's easier to see globally, especially with 4K environments.

146
00:20:16,840 --> 00:20:21,170
And you can increase the speed of the replay.

147
00:20:22,050 --> 00:20:27,850
So this is very good if you're hunting for a specific session for a specific interaction.

148
00:20:31,610 --> 00:20:35,720
This concludes our demonstration of the player's features.

149
00:20:37,890 --> 00:20:45,130
PyRDP also comes with a converter tool that can be used to convert pre-recorded replay files into videos.

150
00:20:45,130 --> 00:20:51,410
The converter tool also accepts PCAPs and can output to replay files.

151
00:20:51,990 --> 00:20:56,430
Let's take a look at its option.

152
00:21:01,960 --> 00:21:07,800
Here we will convert a previously recorded session into a video that we will play.

153
00:21:08,760 --> 00:21:11,200
PyRDP convert.

154
00:21:12,160 --> 00:21:16,300
MP4 has the format of output.

155
00:21:18,420 --> 00:21:28,300
The input file is a RDP replay.

156
00:21:29,200 --> 00:21:33,520
And let's have a default output file name.

157
00:22:05,910 --> 00:22:09,490
Now let's look at the resulting file.

158
00:22:26,510 --> 00:22:32,610
In this section we will describe PyRDP's features that are useful in the context of running honeypots.

159
00:22:32,610 --> 00:22:36,810
Part of PyRDP's honeypot features is a headless mode.

160
00:22:36,810 --> 00: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.

161
00:22:49,130 --> 00: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.

162
00:23:01,140 --> 00:23:04,210
This is the command line from PyRDP.

163
00:23:05,380 --> 00: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.

164
00:23:24,620 --> 00:23:28,120
Now let's see how long it takes.

165
00:23:33,830 --> 00: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.

166
00:23:48,890 --> 00:23:53,470
And you can see that the service is running right now.

167
00:23:53,610 --> 00:24:02,110
Headless mode also means that we needed a headless player, otherwise keystroke data is unavailable for command line enthusiasts.

168
00:24:05,190 --> 00:24:10,150
Let's see the headless player in action.

169
00:24:12,530 --> 00:24:19,370
We can remove the port, it's no longer required for the player, but we still need the volume mount.

170
00:24:23,140 --> 00:24:30,160
If we look at the options, we can see a dash dash headless at the bottom.

171
00:24:30,460 --> 00: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.

172
00:24:49,660 --> 00:24:52,480
The Lena file.

173
00:24:55,050 --> 00:24:59,690
The dump is one shot deal.

174
00:24:59,690 --> 00: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.

175
00:25:14,190 --> 00: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.

176
00:25:23,520 --> 00: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.

177
00:25:40,280 --> 00: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.

178
00:25:55,880 --> 00: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.

179
00:26:04,920 --> 00: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.

180
00:26:25,840 --> 00: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.

181
00:26:33,720 --> 00:26:38,140
Another feature specific to honeypot use cases is credential replacement.

182
00:26:38,580 --> 00: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.

183
00:26:46,760 --> 00: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.

184
00:26:56,300 --> 00:26:59,760
So let's do the demonstration.

185
00:27:00,160 --> 00:27:05,580
For this, I'm going to go back to using the man in the middle.

186
00:27:06,060 --> 00:27:14,300
As you can see below, I'm gonna input the correct credentials for the VM,

187
00:27:17,850 --> 00:27:20,150
and start the man in the middle.

188
00:27:24,040 --> 00: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.

189
00:27:42,490 --> 00:27:51,640
I have the warning because I have a mapped drive, and I have an error.

190
00:27:58,110 --> 00:28:00,010
Let's try again.

191
00:28:04,760 --> 00:28:07,800
Okay, transient error.

192
00:28:10,340 --> 00:28:12,830
So we have the certificate error,

193
00:28:17,600 --> 00:28:19,920
and we got connected.

194
00:28:20,260 --> 00:28:28,100
And if you look at the log, you can see that in the client info, the admin lulz was supplied.

195
00:28:28,840 --> 00:28:36,940
pyrdp has the ability to intercept files in transit, and to allow client file system exploration from the interactive player.

196
00:28:37,080 --> 00:28:43,640
Last year, these capabilities were extended to allow active file querying from the monster in the middle component.

197
00:28:43,820 --> 00: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.

198
00:28:53,320 --> 00:28:55,100
Let's see this in action.

199
00:28:56,060 --> 00:29:10,080
So, we issue the same MITM command as during normal operation, but we add the crawl flag.

200
00:29:10,080 --> 00:29:12,300
Let's run it.

201
00:29:13,420 --> 00: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.

202
00:29:31,360 --> 00:29:33,200
Let's connect.

203
00:29:34,280 --> 00:29:37,400
So, we have the certificate error.

204
00:29:37,400 --> 00:29:38,380
Yes.

205
00:29:39,960 --> 00:29:41,170
Now, what we see here...

206
00:29:42,660 --> 00:29:50,130
Oh, we need to authenticate before the file system is exposed to the server by the client.

207
00:29:56,240 --> 00:29:58,220
We authenticated.

208
00:29:59,180 --> 00:30:10,480
And now, what we see here is a begin-crawling-disk C, saving secret to pyrdp-output-files-clodia-secret.txt.

209
00:30:10,480 --> 00: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.

210
00:30:19,760 --> 00:30:25,820
You'll also be able to notice that the directory structure is respected.

211
00:30:25,900 --> 00:30:36,860
So, as the crawling happens in the background, the files are going to be recreated locally on the pyrdp system.

212
00:30:36,940 --> 00:30:39,080
Oh, we can see it's starting now.

213
00:30:39,080 --> 00: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.

214
00:30:55,700 --> 00:31:03,180
And you'll see also that temporary files and executables under the user directory are going to be saved by default.

215
00:31:03,680 --> 00:31:10,280
So, it can take a while to gather all these files based on network conditions.

216
00:31:10,320 --> 00:31:15,920
The list of files to collect or to ignore can be tweaked on the command line.

217
00:31:16,480 --> 00: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.

218
00:31:26,420 --> 00:31:32,180
Pyrdp can also be used as an offensive security tool to gain a foothold or pivot within a network.

219
00:31:32,180 --> 00:31:34,220
Let's look at some attack techniques.

220
00:31:34,480 --> 00:31:39,160
Session hijacking can be used to take over an intercepted RDP connection.

221
00:31:39,160 --> 00:31:46,500
First, pyrdp-mitm is launched with the target server and the player address to connect to, in this case, localhost.

222
00:31:57,840 --> 00:32:01,340
Next, the player is launched and waits for intercepted sessions.

223
00:32:01,340 --> 00:32:07,740
The player can handle multiple sessions at the same time and will automatically display the live feed of the connected session.

224
00:32:09,900 --> 00:32:14,140
Clients who connect to the malicious server will receive a certificate prompt.

225
00:32:14,200 --> 00:32:17,780
The certificate can be customized to spoof the common name of the server.

226
00:32:18,040 --> 00: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.

227
00:32:27,760 --> 00:32:34,280
After a successful connection is intercepted, the player can be used to monitor the screen and input of the session.

228
00:32:39,830 --> 00: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.

229
00:32:49,050 --> 00:32:52,970
The real RDP client appears frozen during the hijack.

230
00:32:52,990 --> 00:32:57,470
Once the attacker is done, the session is returned to the client, which unfreezes.

231
00:32:57,750 --> 00:33:02,090
This technique is noisy, but looks like a network error to the untrained eye.

232
00:33:03,610 --> 00: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.

233
00:33:10,590 --> 00: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.

234
00:33:19,390 --> 00: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.

235
00:33:29,230 --> 00:33:33,910
Pyrdp supports transparent proxying with the help of a few firewall rules.

236
00:33:34,130 --> 00:33:40,910
Note that this technique only works on Linux and requires running pyrdp as root to use IP transparent sockets.

237
00:33:42,290 --> 00:33:48,270
Use the firewall rule templates from the documentation directory and modify them to reflect your environment.

238
00:33:48,570 --> 00:33:51,850
Here, we use the address range that we will ARP spoof.

239
00:33:51,850 --> 00: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.

240
00:33:59,710 --> 00:34:04,290
Next, create a custom routing table for pyrdp's intercepted connections.

241
00:34:04,290 --> 00:34:07,190
Table ID is a number identifying the table.

242
00:34:09,210 --> 00: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.

243
00:34:35,800 --> 00:34:42,660
The last firewall rule is used to mark traffic coming back from the servers to the clients for transparent proxy.

244
00:35:01,750 --> 00: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.

245
00:35:20,710 --> 00:35:28,250
With the firewall configured, make sure to launch pyrdp as root and provide the transparent switch to enable transparent proxying.

246
00:35:37,180 --> 00:35:42,340
Start vendor cap on your land facing interface and ARP spoof the subnet to intercept.

247
00:35:49,190 --> 00:35:53,890
Here, we set ARP spoof internal to true because we are spoofing our own subnet.

248
00:35:53,890 --> 00:35:56,750
This is not required when spoofing an adjacent subnet.

249
00:35:56,750 --> 00:36:00,230
For the demonstration, we are only spoofing one client.

250
00:36:12,260 --> 00: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.

251
00:36:21,260 --> 00:36:26,500
This technique scales well for internal engagements and works in combination with other attacks.

252
00:36:30,650 --> 00: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.

253
00:36:39,350 --> 00:36:47,270
Using the same transparent proxy configuration as the previous technique, start pyrdp with a PowerShell payload that acts as a stager.

254
00:36:47,570 --> 00: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 .

255
00:36:55,690 --> 00: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.

256
00:37:05,810 --> 00:37:11,590
The malicious payload consists of a simple PowerShell reverse shell for demonstration purposes.

257
00:37:11,590 --> 00:37:16,130
This shell will connect back to the pyrdp workstation on port 888.

258
00:37:21,110 --> 00:37:25,870
Start Metasploit's multi-handler to cache the reverse shell once it is established.

259
00:37:36,750 --> 00:37:42,270
Next, use Python's built-in web server to host the payload that the stager will retrieve.

260
00:37:47,270 --> 00:37:52,790
Make sure to disable exit on session so that multiple sessions can be intercepted.

261
00:38:09,740 --> 00:38:15,120
Lastly, start armscoping to intercept RDP sessions as they are established.

262
00:38:49,500 --> 00: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.

263
00:38:56,500 --> 00:39:03,080
After the delay has elapsed, the client session will appear to freeze while the payload is being delivered and executed.

264
00:39:03,640 --> 00: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.

265
00:39:26,320 --> 00:39:30,980
Even if the client later disconnects from the server, the reverse shell persists.

266
00:39:31,540 --> 00:39:37,760
This technique is powerful and can easily result in multiple sessions when using less detectable payloads.

267
00:39:43,870 --> 00:39:47,250
This concludes our brief tour of pyrdp's features.

268
00:39:47,250 --> 00: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.

269
00:39:53,770 --> 00:39:58,270
Lastly, if you have any war stories to share, we'd be happy to hear about them.

270
00:39:58,270 --> 00:39:59,370
Thanks for watching!