1
00:00:21,440 --> 00:00:23,320
Move on to the next talk.

2
00:00:23,320 --> 00:00:33,420
My name is Santiago, and I'd like to first thank all of you for coming, for coming to this talk, and also the cyber camp organisers.

3
00:00:33,680 --> 00:00:46,220
I'm going to talk to you about... well, the WINREC man in the middle is the title of my talk.

4
00:00:46,220 --> 00:01:15,060
Simple Injection and Remote Fileless Payload Execution, but really, I'm going to talk about a Windows protocol which is to administrate remotely, and what I'm going to show you a series of weaknesses that this protocol has to be able to use it, and we can get remote access to a machine.

5
00:01:15,300 --> 00:01:17,680
A little bit about me.

6
00:01:17,680 --> 00:01:22,000
As I said before, I'm Santiago.

7
00:01:22,000 --> 00:01:29,180
I work as a security researcher in Eleven Paths, and these are some of the conferences that I've participated at so far.

8
00:01:30,160 --> 00:01:36,980
Let's have a look now about the remote register protocol of Windows.

9
00:01:36,980 --> 00:01:45,980
Firstly, this protocol is to manage remotely a data store.

10
00:01:47,280 --> 00:01:50,580
You know what the Windows register is.

11
00:01:50,580 --> 00:02:15,000
A Windows register is like a store room which is in all Windows operating systems, and it has information about the set-up parameters that can depend upon low-level applications for the operating system, for example, some drivers, or user apps, or the user space at high level,

12
00:02:15,000 --> 00:02:17,940
such as any app that we've installed.

13
00:02:20,120 --> 00:02:25,400
Let's go back to the remote register protocol.

14
00:02:25,400 --> 00:02:27,240
It's a client-server protocol.

15
00:02:27,240 --> 00:02:37,100
That means we've got a client who's got a server, and this client is going to be able to administer the server's register.

16
00:02:37,740 --> 00:02:40,660
And also, it depends on RPC and SMB.

17
00:02:40,860 --> 00:02:55,960
RPC and SMB are two protocols that are used in Windows, and, as the talk progresses, you will see the importance they have.

18
00:02:55,960 --> 00:03:05,880
And another thing is the relationship that this protocol, the remote log protocol, has with others.

19
00:03:05,920 --> 00:03:15,280
Here, we saw it was related to RPC and SMB, but it's also a series of other layers.

20
00:03:15,280 --> 00:03:28,540
Here, you can see a screenshot, and you can see how it's got NetBIOS below SMB2, TCP, IP, Ethernet, et cetera.

21
00:03:28,540 --> 00:03:37,440
Why is it so important that we know the layers that are below the remote log protocol?

22
00:03:37,460 --> 00:03:44,560
Because you will see later that attacks will come there.

23
00:03:44,560 --> 00:03:48,060
And the idea is to modify those.

24
00:03:48,060 --> 00:04:09,120
If we modify this layer's information, you will see that it's not sufficient just to modify the information, because the previous layers have other fields such as control fields, checksums, lengths, which are going to identify the size and content of the pack,

25
00:04:09,120 --> 00:04:15,060
and we're going to have to deal with them and have to modify them so that the pack ends up consistent.

26
00:04:15,060 --> 00:04:16,700
We will see this later on.

27
00:04:18,840 --> 00:04:23,660
How does a remote log protocol session work?

28
00:04:23,660 --> 00:04:24,660
It's very simple.

29
00:04:24,660 --> 00:04:28,100
Firstly, the client connects to the server.

30
00:04:28,100 --> 00:04:41,940
As we said previously, the server authorises the request that's made by the client for authentication, and then the client can ask for a series of operations or carry out a series of operations on the server.

31
00:04:41,960 --> 00:04:43,660
What operations you normally do?

32
00:04:43,660 --> 00:04:47,340
For example, the first one that you do is an open key.

33
00:04:47,420 --> 00:05:12,900
An open key, what the client does is open a key, and then the server, if everything is correct, will send him a handle, which is just a random number for that session, that if the session is interrupted, then you will have to have another one.

34
00:05:13,080 --> 00:05:23,380
Once the client has this handle, which is a number, they will start working on other more specific operations, using this key.

35
00:05:24,340 --> 00:05:30,760
For example, they might want to create a specific value in this key or rub the key out.

36
00:05:31,580 --> 00:05:38,480
So, one important thing is the RPC.

37
00:05:38,480 --> 00:05:40,600
The RPC, I don't know if you know what it is.

38
00:05:40,600 --> 00:05:57,760
Basically, it's a standard or something that was created to abstract inter-process communication, either processes between a local machine and a process that is in another machine.

39
00:05:57,760 --> 00:06:21,420
Basically, what it does is it provides a series of interfaces in which developers can play around with, so they don't have to worry about what is below it, and they can just key in a series of input parameters to get a series of outputs, and these are the operations for remote log protocols,

40
00:06:21,420 --> 00:06:28,280
and they're the same as the ones that we could use in an operating system for a local call.

41
00:06:28,280 --> 00:06:36,320
For example, a 22 or 11 can have the same inputs and outputs.

42
00:06:37,000 --> 00:06:40,260
Why is it so important to know about these?

43
00:06:40,260 --> 00:07:05,040
In the next slide, you will see the input and output parameters, and it's important because, although it looks like when you're doing a call, a local call, actually, you're doing it remotely, so this needs to be translated to the machine that's further away,

44
00:07:05,040 --> 00:07:08,600
and the in and out parameters have to be transferred.

45
00:07:08,960 --> 00:07:12,040
So, let's now concentrate here.

46
00:07:12,040 --> 00:07:22,580
I've got three main operations I've concentrated on, and the attack will be mainly on those, which is the create key, the open key, and the set value.

47
00:07:24,900 --> 00:07:31,340
As I said, it's important to know the operation for what it is.

48
00:07:31,400 --> 00:07:36,320
Here, the server opens a key and sends the handle to the client.

49
00:07:37,120 --> 00:07:42,440
So the server authorises the operation, sends us a handle, and we can operate using this key.

50
00:07:42,440 --> 00:07:47,260
Formally, this is the function specification that we have.

51
00:07:47,260 --> 00:08:03,360
We have a series of in parameters, for example, the father key, which may, and another in parameter, the sub key, and a whole series out and in parameters.

52
00:08:03,360 --> 00:08:08,640
If we look at the ones that we're interested in, it may well be that we're interested in these first two here.

53
00:08:08,640 --> 00:08:23,500
So, if we could take this package and intercept it to modify it, what we would be interested in is if the user is opening a key, we can modify that call and enter a different key.

54
00:08:23,860 --> 00:08:32,480
So, once we've identified those parameters that we're interested in, let's see how this goes across to the packet level.

55
00:08:33,280 --> 00:08:41,480
Let's show an open key operation, and here you can see the sequence of packages that are exchanged.

56
00:08:41,480 --> 00:08:42,660
It's very simple.

57
00:08:42,660 --> 00:08:47,160
There's a net version to see whether they match between client and server.

58
00:08:47,160 --> 00:08:58,060
If they do, an open key operation is sent, which is a package, and all the ins go in one, and all the outs go in another.

59
00:08:58,060 --> 00:09:03,740
That's why it's so important to take that into account to know what we have to intercept.

60
00:09:03,740 --> 00:09:12,120
In the case of a set value, for once again, they set the values, and they send it to the client.

61
00:09:12,120 --> 00:09:25,540
The client says, I want to put this value in this log key, if that's okay, they will put that value in the log key, but they've said what sort of parameters are important here?

62
00:09:25,660 --> 00:09:33,320
We've got the father key, the sub key, and, once again, we've got the data that we want to include.

63
00:09:33,320 --> 00:09:42,500
If we intercept a set value call, if we intercept this function, what would be interested in modifying?

64
00:09:42,500 --> 00:09:49,980
For example, the key where the user is trying to put that value, or the value they're trying to include, or both.

65
00:09:49,980 --> 00:09:53,520
When we transfer this to a package, we get the following.

66
00:09:53,520 --> 00:09:55,240
This is it looks like.

67
00:09:55,800 --> 00:10:11,920
In this case, once it's opened the key, it starts giving query values to all the values that it's got until it finds the value that we want to include.

68
00:10:11,920 --> 00:10:16,780
Once it's done that, it sends a set value response.

69
00:10:16,920 --> 00:10:31,620
So, once again, probably all of this is transmitted here, but here, what's important is to consider that a series of previous steps are required, and there's another operation which is create key.

70
00:10:32,400 --> 00:10:42,300
In this case, the server creates the key and returns a handle to the customer, so they start using it.

71
00:10:42,560 --> 00:10:44,060
There you can see the parameters.

72
00:10:44,060 --> 00:10:46,100
You can see which ones are important.

73
00:10:46,340 --> 00:10:49,320
That is the main key and the sub key.

74
00:10:50,700 --> 00:10:53,260
What else do you see on the screenshot?

75
00:10:53,340 --> 00:11:02,780
You see a series of operations that are carried out before the key is created, for example, you open the key where we want to create the new one.

76
00:11:02,780 --> 00:11:07,440
That is, we want to create a key on top of another one that already exists.

77
00:11:07,660 --> 00:11:13,060
Firstly, you have to open the existing one once you've opened that one.

78
00:11:13,060 --> 00:11:18,420
You do a get version, then an open key, and then you launch create key.

79
00:11:18,420 --> 00:11:20,020
Why is it so important?

80
00:11:20,780 --> 00:11:27,900
Because, as I said previously, if we open a key, the server returns a handle.

81
00:11:28,160 --> 00:11:52,160
But, if, in this moment, we see this, we're interested in these parameters, and we modify just one, just this key here, and we say, okay, this person wants to have a new key in IPP, but I want it in the sub key, in the run sub key, so the handle would no longer coincide.

82
00:11:52,160 --> 00:12:01,880
Even if we modify it properly, the server will reject us because it has seen that you haven't opened the key previously upon which you want to create.

83
00:12:01,880 --> 00:12:09,200
It is very important not just to consider the formal part but the whole of the process behind a call.

84
00:12:10,140 --> 00:12:11,200
Okay.

85
00:12:11,520 --> 00:12:22,400
Once, now that we've seen what the remote log protocol looks like, let's now look at see where the protocol failure is.

86
00:12:22,400 --> 00:12:30,660
Here, you've got a screenshot, and it shows you the first authentication when the client authenticates with the server.

87
00:12:31,300 --> 00:12:36,900
The server is running, and the client corrects.

88
00:12:36,900 --> 00:12:37,980
This is what you get.

89
00:12:37,980 --> 00:12:39,120
This is what you see.

90
00:12:39,260 --> 00:12:41,060
Does anybody see anything strange here?

91
00:12:41,600 --> 00:12:42,880
I imagine not.

92
00:12:44,700 --> 00:12:47,580
We will see what each thing means a little later on.

93
00:12:47,580 --> 00:12:55,180
First of all, though, let's introduce a series of concepts which are important to understand what is going on.

94
00:12:55,180 --> 00:12:59,220
Firstly, the security context.

95
00:13:00,860 --> 00:13:05,700
From the MSDN, I've taken a series of definitions.

96
00:13:05,700 --> 00:13:12,360
You don't have to know them all, but if you want the slides afterwards, you can look into them, and maybe you can see what is happening.

97
00:13:12,360 --> 00:13:26,300
Basically, what Microsoft tells us about a security context is that it is a data structure with information about authorisation for a security principle in the form of a token.

98
00:13:27,060 --> 00:13:38,210
So, the server uses this authorisation context, and the information in a security context to check access to requested resources.

99
00:13:38,840 --> 00:13:41,660
So, basically, what does that mean?

100
00:13:41,660 --> 00:13:58,920
It means that when we make our PC calls, what we're doing is transmitting a whole series of information, a lot of which is very valuable, for example, the keys where we're going to create subkeys, or the values that we're going to put, or the value that we're going to give to a determined key,

101
00:13:58,920 --> 00:14:07,300
so these calls need to be secure in some way, and to make them secure, what you set up is a security context.

102
00:14:08,940 --> 00:14:33,660
So, what the customer and the service does is it negotiates a security context, just a series of characteristics, specific characteristics, and what's the scope with the connection, the scope is in the connection, so each package that's exchanged is exchanged according to a security context.

103
00:14:33,660 --> 00:14:38,880
If the connection is broken, and you start again, you have to negotiate a new security context.

104
00:14:39,040 --> 00:14:42,080
And how do you negotiate a security context?

105
00:14:42,080 --> 00:14:44,740
With an exchange of packets.

106
00:14:44,740 --> 00:14:54,080
You send to the client a bind package, and then the server sends you back a bind app with the authorisation.

107
00:14:54,080 --> 00:14:56,660
We will see that later on.

108
00:14:58,140 --> 00:15:00,660
You get the bind app back.

109
00:15:00,740 --> 00:15:10,220
If there's a mistake, if this isn't consistent, if there's a fault, it will send you back a fault PDU.

110
00:15:10,700 --> 00:15:14,960
You can send a fault package both sides, i.e.

111
00:15:14,960 --> 00:15:17,480
server to client, or client to server.

112
00:15:17,480 --> 00:15:20,100
They can both send a PDU.

113
00:15:20,840 --> 00:15:36,030
When this context is set up, you can start using other protocols that are above that to take authorisation decisions, for example, to see whether this customer has an access to certain resources.

114
00:15:37,000 --> 00:15:37,440
Okay.

115
00:15:37,440 --> 00:15:48,800
This is a flow chart, a state flow chart, which is also MSDN, Microsoft's MSDN, and explains what I've just said to you.

116
00:15:48,800 --> 00:16:07,800
Basically, you've got this branch here, where it sends a bind to the server, it waits for the bind app, and then it will negotiate the context and establish the context for this setting.

117
00:16:08,980 --> 00:16:14,940
We saw previously something that in the previous slide which was security provider.

118
00:16:14,940 --> 00:16:16,920
Let's see what a security provider is.

119
00:16:16,920 --> 00:16:39,060
According to the MSDN, a security provider is a pluggable security module that is specified by the protocol layer above the remote procedure call, and will cause the remote procedure call layer to use this module to secure messages in a communication session with the server.

120
00:16:40,000 --> 00:17:02,460
So, it's an external module which implements all the security characteristics that are negotiated in this context with a set of characteristics, so, for example, the packages have to be encrypted, they have to be signed, and the security provider gives you those contexts.

121
00:17:02,460 --> 00:17:08,760
In this case, it's an NTLM, which is a token that's used to sign or to encrypt.

122
00:17:08,760 --> 00:17:20,620
So, the client, before getting information about the context and the first bind message, they will ask the security provider for the token.

123
00:17:20,920 --> 00:17:36,540
This token represents the customer's ID, or can't access the other resource, et cetera.

124
00:17:36,540 --> 00:17:52,920
This is important because, in addition to that, RPC can use the security context to create an information logic chain that's protected against manipulation and dissemination.

125
00:17:52,920 --> 00:18:06,720
So, it can also be used to provide security to those packages that are exchanged, to provide checksums, encryption, et cetera.

126
00:18:06,720 --> 00:18:12,280
So, now, what happens when a security context is formed?

127
00:18:12,280 --> 00:18:16,440
How do you know what level these packages should have?

128
00:18:16,440 --> 00:18:20,320
That is the level, the authentication level.

129
00:18:20,320 --> 00:18:31,000
An authentication level is the amount of protection applied for the security context requested by the client when the security context is created.

130
00:18:31,640 --> 00:18:35,900
And these are the different authentication levels that we have.

131
00:18:35,900 --> 00:18:44,520
We've got level one, which is one that can be negotiated in which none of the packages will have any sort of security characteristic.

132
00:18:44,520 --> 00:18:50,880
They won't be encrypted, they won't be signed, right up to authentication level six.

133
00:18:50,880 --> 00:19:03,440
If you negotiate that level, and both parties have the resources to provide that level, then you provide both integrity and confidentiality, i.e.

134
00:19:03,440 --> 00:19:05,300
it's signed and it's encrypted.

135
00:19:05,300 --> 00:19:09,520
So, it's very, very complicated to modify all of this.

136
00:19:10,060 --> 00:19:15,480
Let's go back now to the image you saw earlier.

137
00:19:20,340 --> 00:19:26,280
On this occasion, you can probably understand a little bit more about what's going on here.

138
00:19:26,280 --> 00:19:35,640
This is the first authentication between client and server using the remote log protocol.

139
00:19:36,600 --> 00:19:39,320
So, firstly, they establish a security context.

140
00:19:39,320 --> 00:19:50,940
This security context, we can see amongst other things that the security provider is in RTLM and has certain authentication information.

141
00:19:51,080 --> 00:19:56,680
When the server receives the information to form the context, they return a bind.

142
00:19:56,680 --> 00:19:58,340
Everything looks okay.

143
00:19:58,780 --> 00:20:08,380
It's authenticated, and you can see that the server says, yeah, okay, we've got the security context, and now we can start sending packages.

144
00:20:08,540 --> 00:20:24,280
And it looks like the security context has been established in a high authentication level because, for example, you can't see the key, it seems like it's encrypted, we've got certain information about authentication, so the client says, okay, I'll have an open key.

145
00:20:25,280 --> 00:20:30,480
And the server says, I'll return you a fault.

146
00:20:31,160 --> 00:20:38,680
You've sent me something, and maybe the authentication token or something isn't correct.

147
00:20:38,700 --> 00:20:41,020
So, I return a fault.

148
00:20:41,580 --> 00:20:45,960
And when you return a fault, the connection goes down.

149
00:20:45,960 --> 00:20:47,860
You have to set up a new connection.

150
00:20:47,860 --> 00:20:52,040
So, you've got a new connection, so you have to re-establish the context, the security context.

151
00:20:52,260 --> 00:21:02,900
So, the security context is established again, and the client sends another bind message to the server, saying they want to have a new security context.

152
00:21:02,900 --> 00:21:07,920
So, you get the bind tag, and so you decide to open the key again.

153
00:21:08,140 --> 00:21:10,800
And they say, yep, I'll allow you to do that.

154
00:21:10,800 --> 00:21:12,540
And it gives you the key handle.

155
00:21:12,780 --> 00:21:17,340
It's interesting because here at the bottom, in the open key, we can see the key.

156
00:21:18,540 --> 00:21:20,500
Let's look at it in more detail now.

157
00:21:20,820 --> 00:21:22,140
Let's go little by little here.

158
00:21:22,140 --> 00:21:30,100
This is the first bind message that's sent when they try to make the security context for the first time.

159
00:21:30,100 --> 00:21:36,680
The first thing that we see is that it's got a 40 authentication length.

160
00:21:37,440 --> 00:21:46,360
That means that it's no longer at authentication length one, because that would be authentication length zero.

161
00:21:46,360 --> 00:21:51,240
In this case, we can see the security provider is NTML.

162
00:21:51,240 --> 00:22:06,440
If you look at it, you can see that the authentication level is six, which means from this moment onwards, when you've got the security context established between the two, they're going to start exchanging signed encrypted messages.

163
00:22:06,440 --> 00:22:08,300
It's the highest level.

164
00:22:09,440 --> 00:22:14,800
There, we see the open key, and we confirm what we had previously.

165
00:22:15,560 --> 00:22:23,700
And we can see that there's a sign for the whole package, and everything is encrypted.

166
00:22:23,700 --> 00:22:26,380
In this case, we can't modify anything.

167
00:22:27,500 --> 00:22:28,980
Let's carry on.

168
00:22:29,020 --> 00:22:30,800
A fault is sent.

169
00:22:31,680 --> 00:22:37,840
What does the MSDN say to us when there's a fault in context?

170
00:22:38,640 --> 00:22:39,520
Developments.

171
00:22:41,400 --> 00:22:48,720
If there's a fault, even though you've got the context, if you've got a catastrophic error, the server should send a fault.

172
00:22:48,740 --> 00:22:49,660
And there we've got it.

173
00:22:50,280 --> 00:22:51,460
The fault.

174
00:22:51,460 --> 00:22:57,780
So , if the client gets this fault, they can't send anything more in this connection, they should close it.

175
00:22:58,180 --> 00:23:02,820
That explains how a little later, we get a new connection.

176
00:23:02,820 --> 00:23:04,580
What's the problem?

177
00:23:05,680 --> 00:23:12,100
That in the bind message, authentication is zero.

178
00:23:13,280 --> 00:23:13,960
There's no...

179
00:23:17,280 --> 00:23:24,480
So, for it to be zero, what that means is that the authentication level that's being negotiated is one.

180
00:23:24,480 --> 00:23:31,660
There's no authentication information, there's no security in the packages that are set in this context.

181
00:23:31,660 --> 00:23:41,640
That means that if you go further, and if you look, you can see that the authentication length is still zero.

182
00:23:43,440 --> 00:24:03,160
So, it's true that we're negotiating an authentication level of zero or one, and here we can say in the specification itself that in the case that you're negotiating this level, the authentication level is zero.

183
00:24:04,320 --> 00:24:09,780
Going back a bit, what have we seen here?

184
00:24:09,780 --> 00:24:32,700
We've seen that a client, when they make a connection with a server using a remote log protocol, it's given a security context, which with an authorization level of six, that fails, there's a fault sent back, and from that moment onwards, the client says,

185
00:24:32,700 --> 00:24:39,740
okay, I'll get another security context, but in this case, the security context has no security.

186
00:24:40,640 --> 00:24:51,040
They set a context in which packages are sent flat, they don't need to be signed or encrypted, and nothing is guaranteed, and we can modify it.

187
00:24:51,200 --> 00:24:56,640
And that's where the tool that I built comes into play.

188
00:24:56,640 --> 00:24:58,060
What does this tool do?

189
00:24:58,220 --> 00:25:11,940
It's right in the middle between server and customer, and as you've got a security context in which packages have no security, we get those packages, we modify them, and then we'll send them back.

190
00:25:12,960 --> 00:25:16,700
We'll get a package, we'll modify it, we'll send it back to the server.

191
00:25:17,040 --> 00:25:22,400
Open keys and changing values as we want.

192
00:25:22,400 --> 00:25:24,100
How does this attack happen?

193
00:25:24,100 --> 00:25:30,780
Well, these are the things that you have to do to attack.

194
00:25:30,780 --> 00:25:33,940
First, you have to intercept the communication between client and server.

195
00:25:34,000 --> 00:25:36,020
There's several techniques.

196
00:25:36,560 --> 00:25:38,020
I'll show you it.

197
00:25:38,160 --> 00:25:41,760
I'm going to show how I do it.

198
00:25:42,480 --> 00:26:03,860
Once you've intercepted, communication, what you need to do is to filter those packets that you want, modify them, you have to go through the user space and modify them and keep the ones that we want, and the ones that we're not interested in, we just send them back.

199
00:26:04,060 --> 00:26:14,620
Once we've got the filtered packages, we modify the fields that we want within the remote log protocol layer.

200
00:26:15,780 --> 00:26:24,220
We recalculate all the different control fields of the winreg lever and the layers above that.

201
00:26:24,500 --> 00:26:30,760
Once we've got that all recalculated, we just rebuild the package and resend it.

202
00:26:31,600 --> 00:26:33,920
How do we do that?

203
00:26:34,700 --> 00:26:39,280
As I said earlier, the customer sends a package to the server.

204
00:26:39,280 --> 00:26:42,620
We intercept the package that's being sent.

205
00:26:42,940 --> 00:26:46,940
We send it to the user space.

206
00:26:47,040 --> 00:26:55,840
Our application opens it, modifies it, changes the bytes or the fields that it wants to modify.

207
00:26:56,020 --> 00:27:03,900
For example, the key using by the user, the value that the user wants, and it recalculates the previous fields.

208
00:27:03,960 --> 00:27:06,300
It then sends it back to the server.

209
00:27:06,300 --> 00:27:07,760
How do we do that?

210
00:27:11,620 --> 00:27:21,940
I've showed you the technologies I've used, but to go from the kernel space to the user space, there you can see what we do.

211
00:27:22,400 --> 00:27:26,080
Once we've got the package with our app, we put it on to Scapi.

212
00:27:26,320 --> 00:27:33,800
It returns to us an interpretation of this package in bytes.

213
00:27:33,800 --> 00:27:35,680
It's a packet bytes.

214
00:27:36,280 --> 00:27:37,880
We can modify it.

215
00:27:38,200 --> 00:27:42,820
You can see there's still a small problem because Scapi can understand, by the way, it's an app.

216
00:27:42,820 --> 00:27:44,300
I don't know if you know it.

217
00:27:44,400 --> 00:27:52,680
It's to modify packets, low-level packets in Python, and it's able to interpret some layers but not all.

218
00:27:52,680 --> 00:27:58,760
And here, it interprets the Ethernet, and others.

219
00:27:59,460 --> 00:28:16,560
So, in this case, we that have to build a series of classes which are going to say, okay, I've studied the specification of the RPC layer, and the NetBIOS protocol, but I know that in these bytes, there's a control field.

220
00:28:16,740 --> 00:28:31,100
So, I'm going to extract the bytes from the chain, the ones that Scapi can't interpret, interpret it as one integer, and then I will turn it back to Scapi so they can reform it.

221
00:28:31,100 --> 00:28:33,840
This is basically what I've done on the screen.

222
00:28:34,320 --> 00:29:00,580
Those fields that Scapi can't interpret, which are control fields before remote register, and the positions that they occupy in bytes from the TCP layer, from byte 1 to byte 54, it's normally TCP, and from there onwards, according to Scapi, that will give you a whole series of bytes.

223
00:29:01,420 --> 00:29:20,560
These from 1 to 4 will be NetBIOS length, which is the length of NetBIOS, so, if we had a bigger field, we would have to recalculate the length so that, when it reaches the server, it's consistent to size, and a whole series of other fields, for example,

224
00:29:20,560 --> 00:29:27,560
DC frag length, name, size, access mask, the whole series of fields.

225
00:29:27,560 --> 00:29:38,160
So , once we've recalculated all those fields, we just resend it back to the server in the NFQ.

226
00:29:38,180 --> 00:29:44,640
The same package that the client sends out is then the same package that the server gets.

227
00:29:44,640 --> 00:29:47,160
We've just modified it.

228
00:29:47,160 --> 00:29:56,140
So, we've got the package, we've modified it, we've inserted all the values that we want in the remote log protocols.

229
00:29:56,140 --> 00:29:57,820
Is there anything missing now?

230
00:29:57,820 --> 00:29:59,320
Have I forgotten anything?

231
00:29:59,620 --> 00:30:24,000
What I saw is that, when you do that with a command console, it works all very well, but, when you do it with a tool that keeps a session, for example, regedit, which is used a lot, once you send the modified packet, the session closes.

232
00:30:24,900 --> 00:30:26,720
Something stops the session.

233
00:30:26,720 --> 00:30:28,240
You can't continue with the session.

234
00:30:28,240 --> 00:30:32,980
So, I reached the conclusion that it was due to the following reason.

235
00:30:32,980 --> 00:30:40,320
It's how the acknowledgement and the sequence numbers work in the TCP IP or TCP session.

236
00:30:40,440 --> 00:30:42,320
It's quite simple, really.

237
00:30:42,560 --> 00:30:44,440
This is how it works.

238
00:30:44,440 --> 00:30:45,520
And this is a problem.

239
00:30:45,520 --> 00:31:02,380
When the customer sends a package to the server, the number of sequence 126 and acknowledgement 269, the number of sequences of the next package that was going to be sent, was estimated in advance.

240
00:31:02,380 --> 00:31:08,280
He knew, because the next number of sequences depends on the volume of this package.

241
00:31:08,280 --> 00:31:26,860
When it got to the server, the server took the acknowledgement, put it as a sequence number, and the sequence number, the acknowledgement here, took this one and did a series of operations with the length of this package to estimate this one.

242
00:31:26,860 --> 00:31:30,240
This one is based on the length of this previous package.

243
00:31:31,840 --> 00:31:49,580
It gets here and it knows that the next sequence number is the one that was here, because it gets the acknowledgement, it transforms into a sequence number, because it knew the length of this package, and it anticipates the number.

244
00:31:49,580 --> 00:32:05,320
So, when we modify here, the package in the middle, we send the package, the sequence number, the acknowledgement, it's okay, they get here, okay, but when this one estimates the acknowledgement, basing itself on the length of this package, because we've modified it in the middle,

245
00:32:05,320 --> 00:32:11,040
it doesn't coincide with the acknowledgement that was pre-estimated with the previous package.

246
00:32:11,040 --> 00:32:13,620
So, the TCP session is broken.

247
00:32:13,620 --> 00:32:14,860
Something fails.

248
00:32:14,860 --> 00:32:18,160
Either a package has been sent and I haven't seen it, or something is failing.

249
00:32:18,160 --> 00:32:19,960
What did I do to solve this problem?

250
00:32:19,960 --> 00:32:23,100
First, to see what was the formula to estimate the acknowledgement.

251
00:32:23,100 --> 00:32:25,120
In this case, this is the formula.

252
00:32:25,980 --> 00:32:32,180
And then I created an algorithm that was simulating the TCP IP session.

253
00:32:32,260 --> 00:32:38,080
When the customer sends, or the client sends a package to the server, this package is modified in the middle.

254
00:32:38,080 --> 00:32:46,700
At this point, the server is going to calculate an acknowledgement that it will not correspond with this next sequence number, because it's based on the length of the package.

255
00:32:46,700 --> 00:32:58,980
When he sends the package, our algorithm will have the non-modified state of the package, will recalculate the acknowledgement, the sequence number that are expected, and then it will resend the package.

256
00:32:58,980 --> 00:33:05,400
And it says, okay, it's okay, this one is recalculating the acknowledgement of the next sequence number, and it's going to resend it.

257
00:33:05,520 --> 00:33:07,760
It's resending a new package to a server.

258
00:33:07,760 --> 00:33:11,900
Our algorithm has kept the state of the modified package.

259
00:33:11,900 --> 00:33:16,560
It's going to recalculate this for the modified package.

260
00:33:16,560 --> 00:33:17,640
It's going to resend it.

261
00:33:17,640 --> 00:33:19,960
In this way, we'll have a simulation.

262
00:33:20,140 --> 00:33:24,460
It's our algorithm that is recalculating all of this, and not the two points.

263
00:33:24,460 --> 00:33:28,020
But we'll maintain the TCPIP session well alive.

264
00:33:28,020 --> 00:33:34,520
We'll modify several keys, and we can have a TCP session on another simulation over another simulation.

265
00:33:34,520 --> 00:33:36,520
It will simulate all the time.

266
00:33:37,740 --> 00:33:40,720
I spoke a lot.

267
00:33:40,720 --> 00:33:43,180
I'll show you now this demo.

268
00:33:44,160 --> 00:33:46,380
What will we do?

269
00:33:46,380 --> 00:33:50,880
An ARP spoofing between the client and server.

270
00:33:50,880 --> 00:33:56,420
Let's execute the function.

271
00:33:56,700 --> 00:34:00,140
We'll put the payload on the run key.

272
00:34:00,140 --> 00:34:04,600
It's going to execute when the machine will restart.

273
00:34:04,600 --> 00:34:14,320
The bypass will do a reverse action to the attacker as administrators in the case if the user has administrative privileges.

274
00:34:14,320 --> 00:34:15,520
Let's see it.

275
00:34:25,720 --> 00:34:32,420
By the way, I'm going to do this in Windows 10, and it normally works.

276
00:34:36,860 --> 00:34:40,060
Let's see how this works.

277
00:34:40,060 --> 00:34:43,740
This is the remote record protocol.

278
00:34:43,740 --> 00:34:44,780
It's very simple.

279
00:34:44,780 --> 00:34:47,920
Let's see the IP address of the machine.

280
00:34:49,100 --> 00:34:50,780
105.

281
00:34:55,720 --> 00:34:57,440
This is 100.

282
00:35:02,510 --> 00:35:05,190
Let's see what's in here.

283
00:35:05,670 --> 00:35:10,830
Here, no established value for this key.

284
00:35:11,730 --> 00:35:17,030
We'll connect through the remote registration record protocol.

285
00:35:30,540 --> 00:35:37,160
We have access to the remote machine record or log.

286
00:35:37,260 --> 00:35:39,200
APP events.

287
00:35:40,620 --> 00:35:41,820
Zero.

288
00:35:44,800 --> 00:35:48,380
The machine establishes the value.

289
00:35:48,380 --> 00:35:49,320
It's quite simple.

290
00:35:49,320 --> 00:35:50,160
This is a client.

291
00:35:50,160 --> 00:35:50,840
This is a server.

292
00:35:50,840 --> 00:35:55,240
We can modify the machine's log.

293
00:35:57,340 --> 00:36:00,660
Let's see the tool's functions now.

294
00:36:00,720 --> 00:36:04,340
Our tool, this is the attacker's machine.

295
00:36:04,340 --> 00:36:06,900
He will have no logic access to any of those.

296
00:36:06,900 --> 00:36:09,620
We'll intercept communication between the two machines.

297
00:36:09,620 --> 00:36:17,640
Let's execute the ARP spoofing using any tool available.

298
00:36:17,680 --> 00:36:26,320
I use the middle framework, and I do ARP spoofing between 100 and 105.

299
00:36:26,320 --> 00:36:28,380
These are the two machines.

300
00:36:33,260 --> 00:36:41,440
We have the ARP spoofing running now, and let's execute this tool.

301
00:36:45,190 --> 00:36:57,970
If we execute the tool in this way, in theory, only the monitor mode is going to start working as a sniffer of registration logs.

302
00:36:57,970 --> 00:37:02,930
All the logs that the client opens are going to appear.

303
00:37:02,930 --> 00:37:04,110
Here we have it.

304
00:37:04,110 --> 00:37:04,950
You see?

305
00:37:05,050 --> 00:37:09,970
All the keys that the customer opens and the subkeys appear here.

306
00:37:09,970 --> 00:37:14,570
The packages are flat, and it's capturing the packages.

307
00:37:14,570 --> 00:37:18,270
It's getting out the values, and we can display it.

308
00:37:18,270 --> 00:37:20,070
What can we do?

309
00:37:20,190 --> 00:37:22,470
Because this is not much.

310
00:37:22,470 --> 00:37:32,010
For example, let's say, capture a set value operation and put the value I want in there.

311
00:37:32,750 --> 00:37:35,730
Edit a dagger value.

312
00:37:35,730 --> 00:37:36,850
It's listening.

313
00:37:36,950 --> 00:37:41,430
It's listening, and it's listening and capturing everything that is happening.

314
00:37:41,430 --> 00:37:44,810
Here in app events, this guy, while we say hello,

315
00:37:48,780 --> 00:37:50,980
this guy continues to browse.

316
00:37:50,980 --> 00:37:51,620
No problem.

317
00:37:51,620 --> 00:37:52,240
No problem.

318
00:37:52,240 --> 00:37:52,940
It's okay.

319
00:37:52,940 --> 00:37:55,180
But what happened really?

320
00:37:55,560 --> 00:37:58,220
First, we got the set value package.

321
00:37:58,220 --> 00:37:59,380
We've modified it.

322
00:37:59,380 --> 00:38:11,360
We recalculated all the fields, and the next phase is that, in fact, we added another value, attacker value, which was bigger, so the TCP session was wrong.

323
00:38:11,360 --> 00:38:14,480
We had to recalculate so that the user could continue to browse.

324
00:38:14,480 --> 00:38:17,160
Otherwise, the connection would have crashed.

325
00:38:18,060 --> 00:38:20,100
The regedit would be stopped.

326
00:38:20,100 --> 00:38:21,180
But if we go to the

327
00:38:24,280 --> 00:38:33,760
server , it doesn't say hello, but attacker revalue.

328
00:38:34,220 --> 00:38:36,820
So, we can modify this.

329
00:38:37,760 --> 00:38:41,060
Let's do something cooler here.

330
00:38:56,000 --> 00:38:58,580
We have the RIP spoofing.

331
00:38:58,580 --> 00:39:01,200
Let's execute the next payload.

332
00:39:06,400 --> 00:39:11,040
So, there's a restart of Apache 2.

333
00:39:11,040 --> 00:39:12,980
I have Apache here.

334
00:39:16,480 --> 00:39:21,980
Another payload with YAC bypass.

335
00:39:22,160 --> 00:39:33,360
The binary of this bypass with an argument, and it's going to return the connection, so the reverse connection is going to be given to this machine again.

336
00:39:45,780 --> 00:39:50,620
We'll execute the two, but this time, it's a minus key argument.

337
00:39:50,620 --> 00:39:54,660
When it opens a key, it's going to be replaced by the one I choose.

338
00:39:55,180 --> 00:40:03,060
It's the run key, because when the victim's machine is restarted, the payload I'm going to introduce is going to be executed.

339
00:40:03,060 --> 00:40:05,480
It's a PowerShell EIEX.

340
00:40:05,620 --> 00:40:08,960
It's downloading the payload from my server.

341
00:40:08,960 --> 00:40:13,320
It's fileless, so no files in the computer.

342
00:40:13,340 --> 00:40:21,940
The UAC bypass is fileless, and it's going to return a remote connection to our server without leaving anything there.

343
00:40:23,200 --> 00:40:30,640
Just the part that we inserted in the record, on the log, in the register, so we can even remove it.

344
00:40:30,640 --> 00:40:37,980
And now I'm going to execute here the meta-exploit to receive the remote connection.

345
00:40:38,820 --> 00:40:40,080
It's okay.

346
00:40:42,180 --> 00:40:46,900
So, the monitoring status.

347
00:40:47,080 --> 00:40:50,180
Let's make the connection.

348
00:41:08,700 --> 00:41:11,300
It's catching all the keys.

349
00:41:26,080 --> 00:41:40,120
So, when the user opens this key, giving a value to it, allocating a value, saying hello, the user can browse with no more problems.

350
00:41:41,420 --> 00:41:55,280
And, when this user restarts his machine, or her machine, as you can see, first, the key that has been opened has been replaced with a different key.

351
00:41:55,280 --> 00:42:06,920
It's simulated the session, but the key is lower, and it's inserted while the other user has to set value, change the value, and he puts our value.

352
00:42:06,920 --> 00:42:17,920
He has to recalculate the TCP session over the previous one, which was of a higher value, and the user continues to browse, and the TCP session is alive.

353
00:42:17,920 --> 00:42:30,200
And now it's inserted the branch in the run, and when this machine that we are administering is restarted,

354
00:42:33,960 --> 00:42:40,930
in theory, it should execute the PowerShell sentence that we've included in the run branch.

355
00:42:44,330 --> 00:42:46,170
Okay?

356
00:42:46,230 --> 00:42:47,750
Something appearing there.

357
00:42:47,870 --> 00:42:50,310
Something else.

358
00:42:51,110 --> 00:42:53,550
Something else, again.

359
00:42:53,990 --> 00:42:55,530
Appearing.

360
00:42:55,670 --> 00:43:02,010
And we receive the connection, the remote connection.

361
00:43:05,680 --> 00:43:08,120
We receive a session.

362
00:43:08,820 --> 00:43:11,500
The Windows machine user is there.

363
00:43:11,500 --> 00:43:13,400
His name is Santi.

364
00:43:13,400 --> 00:43:14,440
It exists.

365
00:43:15,100 --> 00:43:28,000
We have a remote access to the client's machine with administration privileges, with no logic access to any of the machines.

366
00:43:28,260 --> 00:43:30,560
This is the Windows machine.

367
00:43:31,660 --> 00:43:33,380
Here you can see it.

368
00:43:33,620 --> 00:43:34,720
Fine.

369
00:43:36,680 --> 00:43:38,480
Let's continue.

370
00:43:38,480 --> 00:43:42,920
I have not much time left, but I would like to explain something else now.

371
00:43:42,920 --> 00:43:43,740
Fine

372
00:43:48,950 --> 00:43:49,630
.

373
00:43:50,910 --> 00:43:54,970
What I just told you is not all the truth.

374
00:43:55,950 --> 00:44:03,590
The remote register protocol is not always wanting to create a security context.

375
00:44:03,590 --> 00:44:08,370
Then it's broken, and then there's another context being formed with no authentication.

376
00:44:08,370 --> 00:44:17,670
This happens only when the users administering the remote machine don't have the same password and the same ID.

377
00:44:17,670 --> 00:44:22,510
A prompt appears, something strange appears, and there's a context with no good security.

378
00:44:22,510 --> 00:44:27,390
But if it's the same user with the same password, the authentication is automatic.

379
00:44:27,390 --> 00:44:29,110
It doesn't ask you anything.

380
00:44:29,110 --> 00:44:32,730
And in this case, the integrity context is maintained.

381
00:44:33,470 --> 00:44:37,850
And the security context with level of authentication six is maintained.

382
00:44:37,870 --> 00:44:43,690
In the case that it's different, there's a fault, and there's a new one forming.

383
00:44:43,690 --> 00:44:59,750
If it's the same user with the same password, the security context with the level of authentication six is maintained, and encrypted, and the normal packages are exchanged, and nothing happens.

384
00:44:59,750 --> 00:45:15,030
The next part, well, we've seen that the MSDN says that in the case of a catastrophic error, the server sends a false package, and the customer has to break the security context and do a new one.

385
00:45:15,030 --> 00:45:18,110
When forming a new one, it doesn't do it properly.

386
00:45:18,110 --> 00:45:28,750
So, what happens if we extract the DCERPC layer from a false package when the user ID and password is different?

387
00:45:28,750 --> 00:45:43,710
We put the connection with the same user, same ID, same password, and the session is encrypted, and in the response, when we do the first open key, all the information of authentication is okay.

388
00:45:43,710 --> 00:45:45,590
This is the answer of success.

389
00:45:45,590 --> 00:45:47,730
We modify this success.

390
00:45:47,730 --> 00:45:52,910
We insert the error field, and what is the client going to do?

391
00:45:53,270 --> 00:45:58,090
Here, I will show you another demo, seeing what happens.

392
00:45:59,550 --> 00:46:01,710
In fact, it's going to break the security context.

393
00:46:01,710 --> 00:46:08,770
It's going to reform a new one with authentication level one, and everything is going to go back to basics.

394
00:46:16,600 --> 00:46:20,940
This machine is useless because it has a different ID.

395
00:46:26,840 --> 00:46:31,960
This is a machine with the same password and ID user than the previous one.

396
00:46:32,120 --> 00:46:35,240
We have to change the IRP spoofing.

397
00:46:35,240 --> 00:46:37,980
It's 110 in this case.

398
00:46:46,950 --> 00:46:50,490
The IRP spoofing between the two machines is done.

399
00:46:56,700 --> 00:46:58,740
Let's execute this.

400
00:46:58,740 --> 00:47:03,740
Let's make the connection with this other machine.

401
00:47:03,740 --> 00:47:04,440
Let's see.

402
00:47:04,560 --> 00:47:07,540
It's the monitoring mode for the moment.

403
00:47:08,900 --> 00:47:13,340
Let's see what happens when it's the same ID and the same password.

404
00:47:23,300 --> 00:47:27,760
First, it didn't ask me for a password or ID.

405
00:47:27,760 --> 00:47:29,880
It's an automatic authentication.

406
00:47:29,880 --> 00:47:40,880
We open the keys, we browse a little bit, we go to our tool, and what we see here, all the information that goes out is trash.

407
00:47:40,880 --> 00:47:42,800
But it's encrypted.

408
00:47:43,240 --> 00:47:46,760
In fact, the encrypted information is getting out.

409
00:47:46,760 --> 00:47:47,760
We can't do anything.

410
00:47:47,760 --> 00:47:48,940
We can't edit.

411
00:47:48,940 --> 00:47:50,660
We can't recalculate the fields.

412
00:47:50,660 --> 00:47:52,260
We can't do anything here.

413
00:47:52,260 --> 00:47:53,560
Everything is trash.

414
00:47:53,640 --> 00:47:55,500
So, what can we do now?

415
00:47:56,620 --> 00:47:59,640
I don't have much time, just two minutes.

416
00:47:59,640 --> 00:48:01,700
So, there's another part.

417
00:48:02,040 --> 00:48:04,880
There's a module that can break the session.

418
00:48:05,320 --> 00:48:10,140
The regedit crashes for a little while.

419
00:48:10,140 --> 00:48:12,580
I'm going to break it now.

420
00:48:13,160 --> 00:48:14,280
If we do this...

421
00:48:38,810 --> 00:48:40,270
It's going to stay there.

422
00:48:44,070 --> 00:48:46,550
So, it's going to crash, and the tool will tell us...

423
00:48:51,470 --> 00:48:53,130
So, I broke the session.

424
00:48:53,130 --> 00:48:53,670
Why?

425
00:48:53,690 --> 00:49:06,190
Because, if we got in the middle of a session that is encrypted, we had to force the user to get out so that, in the authentication process, we can do that, because it's previously been authenticated.

426
00:49:06,190 --> 00:49:08,850
So, we break the session, and we execute.

427
00:49:08,990 --> 00:49:12,750
In fact, we can do both things at the same time.

428
00:49:13,050 --> 00:49:15,470
We execute this command.

429
00:49:19,600 --> 00:49:22,200
So, this is listening now.

430
00:49:22,320 --> 00:49:28,680
And when it sees the authentication of the user, it's going to modify what we've just seen.

431
00:49:28,680 --> 00:49:30,820
This access package is going to be modified.

432
00:49:30,820 --> 00:49:35,560
There's a fault being sent to it, and the user will form everything normally.

433
00:49:36,200 --> 00:49:39,240
There's new user ID being asked.

434
00:49:39,240 --> 00:49:44,720
There's another security context with low security with authentication level one.

435
00:49:44,720 --> 00:49:48,380
And we can see everything, because there's no security anymore.

436
00:50:04,810 --> 00:50:06,770
It's connected perfectly well.

437
00:50:06,770 --> 00:50:09,110
Here, the guy can see the keys.

438
00:50:09,190 --> 00:50:10,190
Nothing has changed.

439
00:50:10,190 --> 00:50:14,250
But in reality, in fact, what are we seeing here?

440
00:50:14,290 --> 00:50:16,950
All the keys are flat.

441
00:50:17,150 --> 00:50:17,910
You see?

442
00:50:18,150 --> 00:50:22,470
The tools tell us, I forced the session so that it's not encrypted.

443
00:50:22,470 --> 00:50:24,390
You see all the connection again.

444
00:50:24,390 --> 00:50:29,110
It's made on a security one level.

445
00:50:29,110 --> 00:50:30,890
The packages have no security.

446
00:50:30,890 --> 00:50:39,920
And here, again, we can break this once again and do that again.

447
00:50:39,920 --> 00:50:41,940
The user will feel nothing.

448
00:50:41,980 --> 00:50:43,300
Browsing is okay.

449
00:50:43,300 --> 00:50:48,040
And we can send the same attack for an encrypted session.

450
00:50:48,240 --> 00:50:49,680
As we've seen,

451
00:51:07,660 --> 00:51:13,340
this protocol is very vulnerable to man-in-the-middle attacks.

452
00:51:13,600 --> 00:51:21,420
This encrypted protocol, even though the session is encrypted in some circumstances, can be forced so that it's de-encrypted.

453
00:51:21,720 --> 00:51:28,900
And with some effort, you can recalculate everything and modify on the air different values, different keys.

454
00:51:28,900 --> 00:51:33,820
And there's a remote control of Windows 10 that is updated with no problem.

455
00:51:33,820 --> 00:51:35,100
So, it's quite easy.

456
00:51:35,940 --> 00:51:37,180
So, this is it.

457
00:51:37,180 --> 00:51:38,660
No more time left.

458
00:51:40,340 --> 00:51:42,920
So, I've been punctual, I think.

459
00:51:42,920 --> 00:51:50,120
If you have any questions, you can ask here or you can send me questions to my email or through Twitter.

460
00:51:50,260 --> 00:51:53,940
And there's the GitHub to download this tool.

461
00:51:53,940 --> 00:52:00,720
And you'll find user tutorials and even you can test the environment with virtual machines.

462
00:52:00,720 --> 00:52:02,100
It's very simple.

463
00:52:04,540 --> 00:52:05,980
And that's all.

464
00:52:05,980 --> 00:52:07,120
Thank you.

465
00:52:34,400 --> 00:52:35,320
Hello.

466
00:52:35,760 --> 00:52:40,240
I have a doubt regarding this attack.

467
00:52:40,420 --> 00:52:42,260
Is there any way to avoid it?

468
00:52:43,840 --> 00:52:50,200
If you break the security context, you can see everything clearly.

469
00:52:51,100 --> 00:52:55,680
Is there a way so that it never goes down to this level one?

470
00:52:55,680 --> 00:53:00,060
Can we mitigate the problem if you use it by defect in any kind of Windows system?

471
00:53:00,060 --> 00:53:01,640
It's going to happen anyway.

472
00:53:02,520 --> 00:53:12,140
So, either you don't use it or you use another protocol to administer the regedit in a remote way or don't use applications that use it underneath.

473
00:53:12,280 --> 00:53:21,480
I've showed you regedit, but it's using this protocol, but this can be used in consoles or in other applications that are using this protocol.

474
00:53:21,480 --> 00:53:27,000
Or you can use another mechanism to encrypt your connections.

475
00:53:27,980 --> 00:53:34,760
So, if there's a person in the same network, there is an encryption between the two machines, there's no traffic possible.

476
00:53:35,060 --> 00:53:37,520
It's a superior layer to this.

477
00:53:37,520 --> 00:53:38,740
Yes, that's it.

478
00:53:38,820 --> 00:53:39,600
Yes.

479
00:54:04,220 --> 00:54:05,400
Thank you again.