Move on to the next talk.
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.
I'm going to talk to you about... well, the WINREC man in the middle is the title of my talk.
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.
A little bit about me.
As I said before, I'm Santiago.
I work as a security researcher in Eleven Paths, and these are some of the conferences that I've participated at so far.
Let's have a look now about the remote register protocol of Windows.
Firstly, this protocol is to manage remotely a data store.
You know what the Windows register is.
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,
such as any app that we've installed.
Let's go back to the remote register protocol.
It's a client-server protocol.
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.
And also, it depends on RPC and SMB.
RPC and SMB are two protocols that are used in Windows, and, as the talk progresses, you will see the importance they have.
And another thing is the relationship that this protocol, the remote log protocol, has with others.
Here, we saw it was related to RPC and SMB, but it's also a series of other layers.
Here, you can see a screenshot, and you can see how it's got NetBIOS below SMB2, TCP, IP, Ethernet, et cetera.
Why is it so important that we know the layers that are below the remote log protocol?
Because you will see later that attacks will come there.
And the idea is to modify those.
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,
and we're going to have to deal with them and have to modify them so that the pack ends up consistent.
We will see this later on.
How does a remote log protocol session work?
It's very simple.
Firstly, the client connects to the server.
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.
What operations you normally do?
For example, the first one that you do is an open key.
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.
Once the client has this handle, which is a number, they will start working on other more specific operations, using this key.
For example, they might want to create a specific value in this key or rub the key out.
So, one important thing is the RPC.
The RPC, I don't know if you know what it is.
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.
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,
and they're the same as the ones that we could use in an operating system for a local call.
For example, a 22 or 11 can have the same inputs and outputs.
Why is it so important to know about these?
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,
and the in and out parameters have to be transferred.
So, let's now concentrate here.
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.
As I said, it's important to know the operation for what it is.
Here, the server opens a key and sends the handle to the client.
So the server authorises the operation, sends us a handle, and we can operate using this key.
Formally, this is the function specification that we have.
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.
If we look at the ones that we're interested in, it may well be that we're interested in these first two here.
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.
So, once we've identified those parameters that we're interested in, let's see how this goes across to the packet level.
Let's show an open key operation, and here you can see the sequence of packages that are exchanged.
It's very simple.
There's a net version to see whether they match between client and server.
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.
That's why it's so important to take that into account to know what we have to intercept.
In the case of a set value, for once again, they set the values, and they send it to the client.
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?
We've got the father key, the sub key, and, once again, we've got the data that we want to include.
If we intercept a set value call, if we intercept this function, what would be interested in modifying?
For example, the key where the user is trying to put that value, or the value they're trying to include, or both.
When we transfer this to a package, we get the following.
This is it looks like.
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.
Once it's done that, it sends a set value response.
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.
In this case, the server creates the key and returns a handle to the customer, so they start using it.
There you can see the parameters.
You can see which ones are important.
That is the main key and the sub key.
What else do you see on the screenshot?
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.
That is, we want to create a key on top of another one that already exists.
Firstly, you have to open the existing one once you've opened that one.
You do a get version, then an open key, and then you launch create key.
Why is it so important?
Because, as I said previously, if we open a key, the server returns a handle.
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.
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.
It is very important not just to consider the formal part but the whole of the process behind a call.
Okay.
Once, now that we've seen what the remote log protocol looks like, let's now look at see where the protocol failure is.
Here, you've got a screenshot, and it shows you the first authentication when the client authenticates with the server.
The server is running, and the client corrects.
This is what you get.
This is what you see.
Does anybody see anything strange here?
I imagine not.
We will see what each thing means a little later on.
First of all, though, let's introduce a series of concepts which are important to understand what is going on.
Firstly, the security context.
From the MSDN, I've taken a series of definitions.
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.
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.
So, the server uses this authorisation context, and the information in a security context to check access to requested resources.
So, basically, what does that mean?
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,
so these calls need to be secure in some way, and to make them secure, what you set up is a security context.
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.
If the connection is broken, and you start again, you have to negotiate a new security context.
And how do you negotiate a security context?
With an exchange of packets.
You send to the client a bind package, and then the server sends you back a bind app with the authorisation.
We will see that later on.
You get the bind app back.
If there's a mistake, if this isn't consistent, if there's a fault, it will send you back a fault PDU.
You can send a fault package both sides, i.e.
server to client, or client to server.
They can both send a PDU.
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.
Okay.
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.
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.
We saw previously something that in the previous slide which was security provider.
Let's see what a security provider is.
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.
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.
In this case, it's an NTLM, which is a token that's used to sign or to encrypt.
So, the client, before getting information about the context and the first bind message, they will ask the security provider for the token.
This token represents the customer's ID, or can't access the other resource, et cetera.
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.
So, it can also be used to provide security to those packages that are exchanged, to provide checksums, encryption, et cetera.
So, now, what happens when a security context is formed?
How do you know what level these packages should have?
That is the level, the authentication level.
An authentication level is the amount of protection applied for the security context requested by the client when the security context is created.
And these are the different authentication levels that we have.
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.
They won't be encrypted, they won't be signed, right up to authentication level six.
If you negotiate that level, and both parties have the resources to provide that level, then you provide both integrity and confidentiality, i.e.
it's signed and it's encrypted.
So, it's very, very complicated to modify all of this.
Let's go back now to the image you saw earlier.
On this occasion, you can probably understand a little bit more about what's going on here.
This is the first authentication between client and server using the remote log protocol.
So, firstly, they establish a security context.
This security context, we can see amongst other things that the security provider is in RTLM and has certain authentication information.
When the server receives the information to form the context, they return a bind.
Everything looks okay.
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.
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.
And the server says, I'll return you a fault.
You've sent me something, and maybe the authentication token or something isn't correct.
So, I return a fault.
And when you return a fault, the connection goes down.
You have to set up a new connection.
So, you've got a new connection, so you have to re-establish the context, the security context.
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.
So, you get the bind tag, and so you decide to open the key again.
And they say, yep, I'll allow you to do that.
And it gives you the key handle.
It's interesting because here at the bottom, in the open key, we can see the key.
Let's look at it in more detail now.
Let's go little by little here.
This is the first bind message that's sent when they try to make the security context for the first time.
The first thing that we see is that it's got a 40 authentication length.
That means that it's no longer at authentication length one, because that would be authentication length zero.
In this case, we can see the security provider is NTML.
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.
It's the highest level.
There, we see the open key, and we confirm what we had previously.
And we can see that there's a sign for the whole package, and everything is encrypted.
In this case, we can't modify anything.
Let's carry on.
A fault is sent.
What does the MSDN say to us when there's a fault in context?
Developments.
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.
And there we've got it.
The fault.
So , if the client gets this fault, they can't send anything more in this connection, they should close it.
That explains how a little later, we get a new connection.
What's the problem?
That in the bind message, authentication is zero.
There's no...
So, for it to be zero, what that means is that the authentication level that's being negotiated is one.
There's no authentication information, there's no security in the packages that are set in this context.
That means that if you go further, and if you look, you can see that the authentication length is still zero.
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.
Going back a bit, what have we seen here?
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,
okay, I'll get another security context, but in this case, the security context has no security.
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.
And that's where the tool that I built comes into play.
What does this tool do?
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.
We'll get a package, we'll modify it, we'll send it back to the server.
Open keys and changing values as we want.
How does this attack happen?
Well, these are the things that you have to do to attack.
First, you have to intercept the communication between client and server.
There's several techniques.
I'll show you it.
I'm going to show how I do it.
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.
Once we've got the filtered packages, we modify the fields that we want within the remote log protocol layer.
We recalculate all the different control fields of the winreg lever and the layers above that.
Once we've got that all recalculated, we just rebuild the package and resend it.
How do we do that?
As I said earlier, the customer sends a package to the server.
We intercept the package that's being sent.
We send it to the user space.
Our application opens it, modifies it, changes the bytes or the fields that it wants to modify.
For example, the key using by the user, the value that the user wants, and it recalculates the previous fields.
It then sends it back to the server.
How do we do that?
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.
Once we've got the package with our app, we put it on to Scapi.
It returns to us an interpretation of this package in bytes.
It's a packet bytes.
We can modify it.
You can see there's still a small problem because Scapi can understand, by the way, it's an app.
I don't know if you know it.
It's to modify packets, low-level packets in Python, and it's able to interpret some layers but not all.
And here, it interprets the Ethernet, and others.
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.
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.
This is basically what I've done on the screen.
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.
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,
DC frag length, name, size, access mask, the whole series of fields.
So , once we've recalculated all those fields, we just resend it back to the server in the NFQ.
The same package that the client sends out is then the same package that the server gets.
We've just modified it.
So, we've got the package, we've modified it, we've inserted all the values that we want in the remote log protocols.
Is there anything missing now?
Have I forgotten anything?
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.
Something stops the session.
You can't continue with the session.
So, I reached the conclusion that it was due to the following reason.
It's how the acknowledgement and the sequence numbers work in the TCP IP or TCP session.
It's quite simple, really.
This is how it works.
And this is a problem.
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.
He knew, because the next number of sequences depends on the volume of this package.
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.
This one is based on the length of this previous package.
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.
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,
it doesn't coincide with the acknowledgement that was pre-estimated with the previous package.
So, the TCP session is broken.
Something fails.
Either a package has been sent and I haven't seen it, or something is failing.
What did I do to solve this problem?
First, to see what was the formula to estimate the acknowledgement.
In this case, this is the formula.
And then I created an algorithm that was simulating the TCP IP session.
When the customer sends, or the client sends a package to the server, this package is modified in the middle.
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.
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.
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.
It's resending a new package to a server.
Our algorithm has kept the state of the modified package.
It's going to recalculate this for the modified package.
It's going to resend it.
In this way, we'll have a simulation.
It's our algorithm that is recalculating all of this, and not the two points.
But we'll maintain the TCPIP session well alive.
We'll modify several keys, and we can have a TCP session on another simulation over another simulation.
It will simulate all the time.
I spoke a lot.
I'll show you now this demo.
What will we do?
An ARP spoofing between the client and server.
Let's execute the function.
We'll put the payload on the run key.
It's going to execute when the machine will restart.
The bypass will do a reverse action to the attacker as administrators in the case if the user has administrative privileges.
Let's see it.
By the way, I'm going to do this in Windows 10, and it normally works.
Let's see how this works.
This is the remote record protocol.
It's very simple.
Let's see the IP address of the machine.
105.
This is 100.
Let's see what's in here.
Here, no established value for this key.
We'll connect through the remote registration record protocol.
We have access to the remote machine record or log.
APP events.
Zero.
The machine establishes the value.
It's quite simple.
This is a client.
This is a server.
We can modify the machine's log.
Let's see the tool's functions now.
Our tool, this is the attacker's machine.
He will have no logic access to any of those.
We'll intercept communication between the two machines.
Let's execute the ARP spoofing using any tool available.
I use the middle framework, and I do ARP spoofing between 100 and 105.
These are the two machines.
We have the ARP spoofing running now, and let's execute this tool.
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.
All the logs that the client opens are going to appear.
Here we have it.
You see?
All the keys that the customer opens and the subkeys appear here.
The packages are flat, and it's capturing the packages.
It's getting out the values, and we can display it.
What can we do?
Because this is not much.
For example, let's say, capture a set value operation and put the value I want in there.
Edit a dagger value.
It's listening.
It's listening, and it's listening and capturing everything that is happening.
Here in app events, this guy, while we say hello,
this guy continues to browse.
No problem.
It's okay.
But what happened really?
First, we got the set value package.
We've modified it.
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.
We had to recalculate so that the user could continue to browse.
Otherwise, the connection would have crashed.
The regedit would be stopped.
But if we go to the
server , it doesn't say hello, but attacker revalue.
So, we can modify this.
Let's do something cooler here.
We have the RIP spoofing.
Let's execute the next payload.
So, there's a restart of Apache 2.
I have Apache here.
Another payload with YAC bypass.
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.
We'll execute the two, but this time, it's a minus key argument.
When it opens a key, it's going to be replaced by the one I choose.
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.
It's a PowerShell EIEX.
It's downloading the payload from my server.
It's fileless, so no files in the computer.
The UAC bypass is fileless, and it's going to return a remote connection to our server without leaving anything there.
Just the part that we inserted in the record, on the log, in the register, so we can even remove it.
And now I'm going to execute here the meta-exploit to receive the remote connection.
It's okay.
So, the monitoring status.
Let's make the connection.
It's catching all the keys.
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.
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.
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.
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.
And now it's inserted the branch in the run, and when this machine that we are administering is restarted,
in theory, it should execute the PowerShell sentence that we've included in the run branch.
Okay?
Something appearing there.
Something else.
Something else, again.
Appearing.
And we receive the connection, the remote connection.
We receive a session.
The Windows machine user is there.
His name is Santi.
It exists.
We have a remote access to the client's machine with administration privileges, with no logic access to any of the machines.
This is the Windows machine.
Here you can see it.
Fine.
Let's continue.
I have not much time left, but I would like to explain something else now.
Fine
.
What I just told you is not all the truth.
The remote register protocol is not always wanting to create a security context.
Then it's broken, and then there's another context being formed with no authentication.
This happens only when the users administering the remote machine don't have the same password and the same ID.
A prompt appears, something strange appears, and there's a context with no good security.
But if it's the same user with the same password, the authentication is automatic.
It doesn't ask you anything.
And in this case, the integrity context is maintained.
And the security context with level of authentication six is maintained.
In the case that it's different, there's a fault, and there's a new one forming.
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.
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.
When forming a new one, it doesn't do it properly.
So, what happens if we extract the DCERPC layer from a false package when the user ID and password is different?
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.
This is the answer of success.
We modify this success.
We insert the error field, and what is the client going to do?
Here, I will show you another demo, seeing what happens.
In fact, it's going to break the security context.
It's going to reform a new one with authentication level one, and everything is going to go back to basics.
This machine is useless because it has a different ID.
This is a machine with the same password and ID user than the previous one.
We have to change the IRP spoofing.
It's 110 in this case.
The IRP spoofing between the two machines is done.
Let's execute this.
Let's make the connection with this other machine.
Let's see.
It's the monitoring mode for the moment.
Let's see what happens when it's the same ID and the same password.
First, it didn't ask me for a password or ID.
It's an automatic authentication.
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.
But it's encrypted.
In fact, the encrypted information is getting out.
We can't do anything.
We can't edit.
We can't recalculate the fields.
We can't do anything here.
Everything is trash.
So, what can we do now?
I don't have much time, just two minutes.
So, there's another part.
There's a module that can break the session.
The regedit crashes for a little while.
I'm going to break it now.
If we do this...
It's going to stay there.
So, it's going to crash, and the tool will tell us...
So, I broke the session.
Why?
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.
So, we break the session, and we execute.
In fact, we can do both things at the same time.
We execute this command.
So, this is listening now.
And when it sees the authentication of the user, it's going to modify what we've just seen.
This access package is going to be modified.
There's a fault being sent to it, and the user will form everything normally.
There's new user ID being asked.
There's another security context with low security with authentication level one.
And we can see everything, because there's no security anymore.
It's connected perfectly well.
Here, the guy can see the keys.
Nothing has changed.
But in reality, in fact, what are we seeing here?
All the keys are flat.
You see?
The tools tell us, I forced the session so that it's not encrypted.
You see all the connection again.
It's made on a security one level.
The packages have no security.
And here, again, we can break this once again and do that again.
The user will feel nothing.
Browsing is okay.
And we can send the same attack for an encrypted session.
As we've seen,
this protocol is very vulnerable to man-in-the-middle attacks.
This encrypted protocol, even though the session is encrypted in some circumstances, can be forced so that it's de-encrypted.
And with some effort, you can recalculate everything and modify on the air different values, different keys.
And there's a remote control of Windows 10 that is updated with no problem.
So, it's quite easy.
So, this is it.
No more time left.
So, I've been punctual, I think.
If you have any questions, you can ask here or you can send me questions to my email or through Twitter.
And there's the GitHub to download this tool.
And you'll find user tutorials and even you can test the environment with virtual machines.
It's very simple.
And that's all.
Thank you.
Hello.
I have a doubt regarding this attack.
Is there any way to avoid it?
If you break the security context, you can see everything clearly.
Is there a way so that it never goes down to this level one?
Can we mitigate the problem if you use it by defect in any kind of Windows system?
It's going to happen anyway.
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.
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.
Or you can use another mechanism to encrypt your connections.
So, if there's a person in the same network, there is an encryption between the two machines, there's no traffic possible.
It's a superior layer to this.
Yes, that's it.
Yes.
Thank you again.