What are the risks of remoting in (RDP) to a compromised system? [duplicate]

Clash Royale CLAN TAG#URR8PPP

.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;

up vote
23
down vote

favorite

1

This question already has an answer here:

• 
  Why would a remote desktop connection harm my PC?
  
  3 answers
  
  

Can the client be harmed in any way, and how?

rdp

share|improve this question

asked Aug 6 at 13:59

PtotheBZZ

21615

marked as duplicate by Conor Mancone, Tom K., forest, Steffen Ullrich, Matthew Aug 7 at 9:21

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  If your client have a vulnerability, the server can exploit it.
  – ThoriumBR
  Aug 6 at 14:02
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  While this may not be strictly RDP, but a third-party remoting software such as TeamViewer provides a reverse control function, which may be exploited. FYI: github.com/gellin/TeamViewer_Permissions_Hook_V1
  – Moobie
  Aug 6 at 17:56
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I disagree that this is a duplicate. My main reason is that this question specifically refers to Microsoft's Remote Desktop Protocol and not general remote desktop software. Additionally, the author does not ask "how would the remote desktop connect to my local pc" but instead just asks about risks in general, which is much broader, since a reverse connection is usually impossible without an RCE vuln in the client. The answers to these two questions should be quite different. As it is, however, the proposed dup question has only RDP answers...
  – Luc
  Aug 6 at 23:39
  
  

  
  
  
  

add a comment | 

up vote
23
down vote

favorite

1

This question already has an answer here:

• 
  Why would a remote desktop connection harm my PC?
  
  3 answers
  
  

Can the client be harmed in any way, and how?

rdp

share|improve this question

asked Aug 6 at 13:59

PtotheBZZ

21615

marked as duplicate by Conor Mancone, Tom K., forest, Steffen Ullrich, Matthew Aug 7 at 9:21

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  If your client have a vulnerability, the server can exploit it.
  – ThoriumBR
  Aug 6 at 14:02
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  While this may not be strictly RDP, but a third-party remoting software such as TeamViewer provides a reverse control function, which may be exploited. FYI: github.com/gellin/TeamViewer_Permissions_Hook_V1
  – Moobie
  Aug 6 at 17:56
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I disagree that this is a duplicate. My main reason is that this question specifically refers to Microsoft's Remote Desktop Protocol and not general remote desktop software. Additionally, the author does not ask "how would the remote desktop connect to my local pc" but instead just asks about risks in general, which is much broader, since a reverse connection is usually impossible without an RCE vuln in the client. The answers to these two questions should be quite different. As it is, however, the proposed dup question has only RDP answers...
  – Luc
  Aug 6 at 23:39
  
  

  
  
  
  

add a comment | 

up vote
23
down vote

favorite

1

up vote
23
down vote

favorite

1

1

This question already has an answer here:

• 
  Why would a remote desktop connection harm my PC?
  
  3 answers
  
  

Can the client be harmed in any way, and how?

rdp

share|improve this question

asked Aug 6 at 13:59

PtotheBZZ

21615

This question already has an answer here:

• 
  Why would a remote desktop connection harm my PC?
  
  3 answers
  
  

Can the client be harmed in any way, and how?

This question already has an answer here:

• 
  Why would a remote desktop connection harm my PC?
  
  3 answers
  
  

rdp

share|improve this question

asked Aug 6 at 13:59

PtotheBZZ

21615

share|improve this question

share|improve this question

asked Aug 6 at 13:59

PtotheBZZ

21615

asked Aug 6 at 13:59

PtotheBZZ

21615

asked Aug 6 at 13:59

PtotheBZZ

21615

21615

marked as duplicate by Conor Mancone, Tom K., forest, Steffen Ullrich, Matthew Aug 7 at 9:21

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

marked as duplicate by Conor Mancone, Tom K., forest, Steffen Ullrich, Matthew Aug 7 at 9:21

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  If your client have a vulnerability, the server can exploit it.
  – ThoriumBR
  Aug 6 at 14:02
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  While this may not be strictly RDP, but a third-party remoting software such as TeamViewer provides a reverse control function, which may be exploited. FYI: github.com/gellin/TeamViewer_Permissions_Hook_V1
  – Moobie
  Aug 6 at 17:56
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I disagree that this is a duplicate. My main reason is that this question specifically refers to Microsoft's Remote Desktop Protocol and not general remote desktop software. Additionally, the author does not ask "how would the remote desktop connect to my local pc" but instead just asks about risks in general, which is much broader, since a reverse connection is usually impossible without an RCE vuln in the client. The answers to these two questions should be quite different. As it is, however, the proposed dup question has only RDP answers...
  – Luc
  Aug 6 at 23:39
  
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  If your client have a vulnerability, the server can exploit it.
  – ThoriumBR
  Aug 6 at 14:02
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  While this may not be strictly RDP, but a third-party remoting software such as TeamViewer provides a reverse control function, which may be exploited. FYI: github.com/gellin/TeamViewer_Permissions_Hook_V1
  – Moobie
  Aug 6 at 17:56
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  I disagree that this is a duplicate. My main reason is that this question specifically refers to Microsoft's Remote Desktop Protocol and not general remote desktop software. Additionally, the author does not ask "how would the remote desktop connect to my local pc" but instead just asks about risks in general, which is much broader, since a reverse connection is usually impossible without an RCE vuln in the client. The answers to these two questions should be quite different. As it is, however, the proposed dup question has only RDP answers...
  – Luc
  Aug 6 at 23:39
  
  

  
  
  
  

3

3

If your client have a vulnerability, the server can exploit it.
– ThoriumBR
Aug 6 at 14:02

If your client have a vulnerability, the server can exploit it.
– ThoriumBR
Aug 6 at 14:02

2

2

While this may not be strictly RDP, but a third-party remoting software such as TeamViewer provides a reverse control function, which may be exploited. FYI: github.com/gellin/TeamViewer_Permissions_Hook_V1
– Moobie
Aug 6 at 17:56

While this may not be strictly RDP, but a third-party remoting software such as TeamViewer provides a reverse control function, which may be exploited. FYI: github.com/gellin/TeamViewer_Permissions_Hook_V1
– Moobie
Aug 6 at 17:56

1

1

I disagree that this is a duplicate. My main reason is that this question specifically refers to Microsoft's Remote Desktop Protocol and not general remote desktop software. Additionally, the author does not ask "how would the remote desktop connect to my local pc" but instead just asks about risks in general, which is much broader, since a reverse connection is usually impossible without an RCE vuln in the client. The answers to these two questions should be quite different. As it is, however, the proposed dup question has only RDP answers...
– Luc
Aug 6 at 23:39

I disagree that this is a duplicate. My main reason is that this question specifically refers to Microsoft's Remote Desktop Protocol and not general remote desktop software. Additionally, the author does not ask "how would the remote desktop connect to my local pc" but instead just asks about risks in general, which is much broader, since a reverse connection is usually impossible without an RCE vuln in the client. The answers to these two questions should be quite different. As it is, however, the proposed dup question has only RDP answers...
– Luc
Aug 6 at 23:39

add a comment | 

2 Answers
2

active

oldest

votes

up vote
40
down vote

A true story

When I was in grad school the computer systems in our department were hacked. It turned out it was hacked because a malicious attacker got a hold of the username/password for one of our users, connected in, and then managed privilege escalation from there. Being young and naive I made a comment to my advisor along the lines of "Who can be stupid enough to share their username and password???". My advisor quickly answered with: "Actually, that was me." (which obviously left me feeling like the idiot, and taught me a valuable lesson about not jumping to conclusions or running my mouth). He then explained:

He had been visiting a different institution and connected to their systems. He did not realize that their server was compromised (they didn't know it yet either). He then ssh'd into his own account in our system, and in doing so the compromised system had no problems at all reading his username and password and sending it back to the attacker (the ssh client on their machine had been replaced with a malicious one). They were then able to use that to get into our system and go to town on our servers. All that to say:

The biggest risk of connecting to a compromised machine is that you must assume that absolutely everything you do will be recorded and sent off to the attackers. Do not connect to any other systems from the compromised machine. Do not connect to your email from the compromised machine. Do not connect to any websites at all from the compromised machine, unless it is the sort of thing that you wouldn't mind posting publicly on the internet along with all of your access credentials. Granted, this probably goes without saying, but I've found that sometimes leaving the obvious things unsaid comes back to bite you later.

Your actual question

Of course this isn't exactly what you were asking about. Presuming you don't do anything important on the compromised machine, there is certainly still some risk involved in connecting to it. I would expect the risk to be low as it (seems) unlikely that the compromised machine will be able to directly infect your machine. It's certainly impossible to rule out a zero-day vulnerability that may allow the remote machine to take over the client, but it is probably a lot easier to spread over network connections then hacking backwards through the RDP protocol, so I doubt there are really many viruses/rootkits/etc. that actually do that. There are other resources shared between client and server that you will have to watch out for. Still, given how easy it is to setup a virtual machine, I would consider it a reasonable precaution to connect through one:

1. Spin up a virtual machine


2. Use the virtual machine to connect to the compromised RDP server


3. Trash the virtual machine afterward.

Your mileage will vary. We all have different level of risks that we are willing to accept, and different levels of "inconvenience" we are willing to undergo to avoid those risks. I don't keep up on the RDP scene (I'm a linux guy), but in a quick search I found plenty of RDP security vulnerabilities but none that appeared to allow the remote system to gain control over the client. An additional layer of security might not hurt, but remember to never trust anything from the compromised machine or do anything of any value at all while there.

share|improve this answer

edited Aug 6 at 19:45

answered Aug 6 at 15:05

Conor Mancone

7,02421537

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Using a Microcore Linux booted from a read-only ISO on a VM might also allow you to RDP in with a similar level of risk, and a significantly more convenient user experience.
  – Rogem
  Aug 6 at 21:30
  

  
  
  
  

add a comment | 

up vote
26
down vote

There are a number of settings in the standard RDP client that could be exploited for an attack on the client, if enabled. For example: shared folders, access to devices like printers, etc.

If you're remoting into a known compromised machine, you might want to disable as much as possible in the client's connection and sharing options before connecting.

It's also possible that in addition to the things that you intentionally shared, there could be vulnerabilities in the RDP client itself. Ensure you're patched and up-to-date, and treat the client machine as at-risk of infection until you have a chance to scan it for indicators of compromise.

share|improve this answer

answered Aug 6 at 14:49

nbering

3,19611320

• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  Clipboard is an attack surface in case you happen to copy any passwords or other sensitive info into clipboard at any time the RDP is open, or have accidentally done so as a last copy operation before opening the RDP. Clipboard sharing can be disabled too.
  – Roland Pihlakas
  Aug 6 at 22:08
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, I've heard of the local system's data getting encrypted because the RDP profile was configured to pass through storage drives and the remote system had ransomware which was designed to encrypt all (local and remote / network) storage drives.
  – mythofechelon
  Aug 7 at 14:28
  

  
  
  
  

add a comment | 

2 Answers
2

active

oldest

votes

2 Answers
2

active

oldest

votes

active

oldest

votes

active

oldest

votes

up vote
40
down vote

A true story

When I was in grad school the computer systems in our department were hacked. It turned out it was hacked because a malicious attacker got a hold of the username/password for one of our users, connected in, and then managed privilege escalation from there. Being young and naive I made a comment to my advisor along the lines of "Who can be stupid enough to share their username and password???". My advisor quickly answered with: "Actually, that was me." (which obviously left me feeling like the idiot, and taught me a valuable lesson about not jumping to conclusions or running my mouth). He then explained:

He had been visiting a different institution and connected to their systems. He did not realize that their server was compromised (they didn't know it yet either). He then ssh'd into his own account in our system, and in doing so the compromised system had no problems at all reading his username and password and sending it back to the attacker (the ssh client on their machine had been replaced with a malicious one). They were then able to use that to get into our system and go to town on our servers. All that to say:

The biggest risk of connecting to a compromised machine is that you must assume that absolutely everything you do will be recorded and sent off to the attackers. Do not connect to any other systems from the compromised machine. Do not connect to your email from the compromised machine. Do not connect to any websites at all from the compromised machine, unless it is the sort of thing that you wouldn't mind posting publicly on the internet along with all of your access credentials. Granted, this probably goes without saying, but I've found that sometimes leaving the obvious things unsaid comes back to bite you later.

Your actual question

Of course this isn't exactly what you were asking about. Presuming you don't do anything important on the compromised machine, there is certainly still some risk involved in connecting to it. I would expect the risk to be low as it (seems) unlikely that the compromised machine will be able to directly infect your machine. It's certainly impossible to rule out a zero-day vulnerability that may allow the remote machine to take over the client, but it is probably a lot easier to spread over network connections then hacking backwards through the RDP protocol, so I doubt there are really many viruses/rootkits/etc. that actually do that. There are other resources shared between client and server that you will have to watch out for. Still, given how easy it is to setup a virtual machine, I would consider it a reasonable precaution to connect through one:

1. Spin up a virtual machine


2. Use the virtual machine to connect to the compromised RDP server


3. Trash the virtual machine afterward.

Your mileage will vary. We all have different level of risks that we are willing to accept, and different levels of "inconvenience" we are willing to undergo to avoid those risks. I don't keep up on the RDP scene (I'm a linux guy), but in a quick search I found plenty of RDP security vulnerabilities but none that appeared to allow the remote system to gain control over the client. An additional layer of security might not hurt, but remember to never trust anything from the compromised machine or do anything of any value at all while there.

share|improve this answer

edited Aug 6 at 19:45

answered Aug 6 at 15:05

Conor Mancone

7,02421537

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Using a Microcore Linux booted from a read-only ISO on a VM might also allow you to RDP in with a similar level of risk, and a significantly more convenient user experience.
  – Rogem
  Aug 6 at 21:30
  

  
  
  
  

add a comment | 

up vote
40
down vote

A true story

When I was in grad school the computer systems in our department were hacked. It turned out it was hacked because a malicious attacker got a hold of the username/password for one of our users, connected in, and then managed privilege escalation from there. Being young and naive I made a comment to my advisor along the lines of "Who can be stupid enough to share their username and password???". My advisor quickly answered with: "Actually, that was me." (which obviously left me feeling like the idiot, and taught me a valuable lesson about not jumping to conclusions or running my mouth). He then explained:

He had been visiting a different institution and connected to their systems. He did not realize that their server was compromised (they didn't know it yet either). He then ssh'd into his own account in our system, and in doing so the compromised system had no problems at all reading his username and password and sending it back to the attacker (the ssh client on their machine had been replaced with a malicious one). They were then able to use that to get into our system and go to town on our servers. All that to say:

The biggest risk of connecting to a compromised machine is that you must assume that absolutely everything you do will be recorded and sent off to the attackers. Do not connect to any other systems from the compromised machine. Do not connect to your email from the compromised machine. Do not connect to any websites at all from the compromised machine, unless it is the sort of thing that you wouldn't mind posting publicly on the internet along with all of your access credentials. Granted, this probably goes without saying, but I've found that sometimes leaving the obvious things unsaid comes back to bite you later.

Your actual question

Of course this isn't exactly what you were asking about. Presuming you don't do anything important on the compromised machine, there is certainly still some risk involved in connecting to it. I would expect the risk to be low as it (seems) unlikely that the compromised machine will be able to directly infect your machine. It's certainly impossible to rule out a zero-day vulnerability that may allow the remote machine to take over the client, but it is probably a lot easier to spread over network connections then hacking backwards through the RDP protocol, so I doubt there are really many viruses/rootkits/etc. that actually do that. There are other resources shared between client and server that you will have to watch out for. Still, given how easy it is to setup a virtual machine, I would consider it a reasonable precaution to connect through one:

1. Spin up a virtual machine


2. Use the virtual machine to connect to the compromised RDP server


3. Trash the virtual machine afterward.

Your mileage will vary. We all have different level of risks that we are willing to accept, and different levels of "inconvenience" we are willing to undergo to avoid those risks. I don't keep up on the RDP scene (I'm a linux guy), but in a quick search I found plenty of RDP security vulnerabilities but none that appeared to allow the remote system to gain control over the client. An additional layer of security might not hurt, but remember to never trust anything from the compromised machine or do anything of any value at all while there.

share|improve this answer

edited Aug 6 at 19:45

answered Aug 6 at 15:05

Conor Mancone

7,02421537

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Using a Microcore Linux booted from a read-only ISO on a VM might also allow you to RDP in with a similar level of risk, and a significantly more convenient user experience.
  – Rogem
  Aug 6 at 21:30
  

  
  
  
  

add a comment | 

up vote
40
down vote

up vote
40
down vote

A true story

When I was in grad school the computer systems in our department were hacked. It turned out it was hacked because a malicious attacker got a hold of the username/password for one of our users, connected in, and then managed privilege escalation from there. Being young and naive I made a comment to my advisor along the lines of "Who can be stupid enough to share their username and password???". My advisor quickly answered with: "Actually, that was me." (which obviously left me feeling like the idiot, and taught me a valuable lesson about not jumping to conclusions or running my mouth). He then explained:

He had been visiting a different institution and connected to their systems. He did not realize that their server was compromised (they didn't know it yet either). He then ssh'd into his own account in our system, and in doing so the compromised system had no problems at all reading his username and password and sending it back to the attacker (the ssh client on their machine had been replaced with a malicious one). They were then able to use that to get into our system and go to town on our servers. All that to say:

The biggest risk of connecting to a compromised machine is that you must assume that absolutely everything you do will be recorded and sent off to the attackers. Do not connect to any other systems from the compromised machine. Do not connect to your email from the compromised machine. Do not connect to any websites at all from the compromised machine, unless it is the sort of thing that you wouldn't mind posting publicly on the internet along with all of your access credentials. Granted, this probably goes without saying, but I've found that sometimes leaving the obvious things unsaid comes back to bite you later.

Your actual question

Of course this isn't exactly what you were asking about. Presuming you don't do anything important on the compromised machine, there is certainly still some risk involved in connecting to it. I would expect the risk to be low as it (seems) unlikely that the compromised machine will be able to directly infect your machine. It's certainly impossible to rule out a zero-day vulnerability that may allow the remote machine to take over the client, but it is probably a lot easier to spread over network connections then hacking backwards through the RDP protocol, so I doubt there are really many viruses/rootkits/etc. that actually do that. There are other resources shared between client and server that you will have to watch out for. Still, given how easy it is to setup a virtual machine, I would consider it a reasonable precaution to connect through one:

1. Spin up a virtual machine


2. Use the virtual machine to connect to the compromised RDP server


3. Trash the virtual machine afterward.

Your mileage will vary. We all have different level of risks that we are willing to accept, and different levels of "inconvenience" we are willing to undergo to avoid those risks. I don't keep up on the RDP scene (I'm a linux guy), but in a quick search I found plenty of RDP security vulnerabilities but none that appeared to allow the remote system to gain control over the client. An additional layer of security might not hurt, but remember to never trust anything from the compromised machine or do anything of any value at all while there.

share|improve this answer

edited Aug 6 at 19:45

answered Aug 6 at 15:05

Conor Mancone

7,02421537

A true story

When I was in grad school the computer systems in our department were hacked. It turned out it was hacked because a malicious attacker got a hold of the username/password for one of our users, connected in, and then managed privilege escalation from there. Being young and naive I made a comment to my advisor along the lines of "Who can be stupid enough to share their username and password???". My advisor quickly answered with: "Actually, that was me." (which obviously left me feeling like the idiot, and taught me a valuable lesson about not jumping to conclusions or running my mouth). He then explained:

He had been visiting a different institution and connected to their systems. He did not realize that their server was compromised (they didn't know it yet either). He then ssh'd into his own account in our system, and in doing so the compromised system had no problems at all reading his username and password and sending it back to the attacker (the ssh client on their machine had been replaced with a malicious one). They were then able to use that to get into our system and go to town on our servers. All that to say:

The biggest risk of connecting to a compromised machine is that you must assume that absolutely everything you do will be recorded and sent off to the attackers. Do not connect to any other systems from the compromised machine. Do not connect to your email from the compromised machine. Do not connect to any websites at all from the compromised machine, unless it is the sort of thing that you wouldn't mind posting publicly on the internet along with all of your access credentials. Granted, this probably goes without saying, but I've found that sometimes leaving the obvious things unsaid comes back to bite you later.

Your actual question

Of course this isn't exactly what you were asking about. Presuming you don't do anything important on the compromised machine, there is certainly still some risk involved in connecting to it. I would expect the risk to be low as it (seems) unlikely that the compromised machine will be able to directly infect your machine. It's certainly impossible to rule out a zero-day vulnerability that may allow the remote machine to take over the client, but it is probably a lot easier to spread over network connections then hacking backwards through the RDP protocol, so I doubt there are really many viruses/rootkits/etc. that actually do that. There are other resources shared between client and server that you will have to watch out for. Still, given how easy it is to setup a virtual machine, I would consider it a reasonable precaution to connect through one:

1. Spin up a virtual machine


2. Use the virtual machine to connect to the compromised RDP server


3. Trash the virtual machine afterward.

Your mileage will vary. We all have different level of risks that we are willing to accept, and different levels of "inconvenience" we are willing to undergo to avoid those risks. I don't keep up on the RDP scene (I'm a linux guy), but in a quick search I found plenty of RDP security vulnerabilities but none that appeared to allow the remote system to gain control over the client. An additional layer of security might not hurt, but remember to never trust anything from the compromised machine or do anything of any value at all while there.

share|improve this answer

edited Aug 6 at 19:45

answered Aug 6 at 15:05

Conor Mancone

7,02421537

share|improve this answer

share|improve this answer

edited Aug 6 at 19:45

edited Aug 6 at 19:45

edited Aug 6 at 19:45

answered Aug 6 at 15:05

Conor Mancone

7,02421537

answered Aug 6 at 15:05

Conor Mancone

7,02421537

answered Aug 6 at 15:05

Conor Mancone

7,02421537

7,02421537

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Using a Microcore Linux booted from a read-only ISO on a VM might also allow you to RDP in with a similar level of risk, and a significantly more convenient user experience.
  – Rogem
  Aug 6 at 21:30
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  

  
  
  
  
  
  

  
  Using a Microcore Linux booted from a read-only ISO on a VM might also allow you to RDP in with a similar level of risk, and a significantly more convenient user experience.
  – Rogem
  Aug 6 at 21:30
  

  
  
  
  

Using a Microcore Linux booted from a read-only ISO on a VM might also allow you to RDP in with a similar level of risk, and a significantly more convenient user experience.
– Rogem
Aug 6 at 21:30

Using a Microcore Linux booted from a read-only ISO on a VM might also allow you to RDP in with a similar level of risk, and a significantly more convenient user experience.
– Rogem
Aug 6 at 21:30

add a comment | 

up vote
26
down vote

There are a number of settings in the standard RDP client that could be exploited for an attack on the client, if enabled. For example: shared folders, access to devices like printers, etc.

If you're remoting into a known compromised machine, you might want to disable as much as possible in the client's connection and sharing options before connecting.

It's also possible that in addition to the things that you intentionally shared, there could be vulnerabilities in the RDP client itself. Ensure you're patched and up-to-date, and treat the client machine as at-risk of infection until you have a chance to scan it for indicators of compromise.

share|improve this answer

answered Aug 6 at 14:49

nbering

3,19611320

• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  Clipboard is an attack surface in case you happen to copy any passwords or other sensitive info into clipboard at any time the RDP is open, or have accidentally done so as a last copy operation before opening the RDP. Clipboard sharing can be disabled too.
  – Roland Pihlakas
  Aug 6 at 22:08
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, I've heard of the local system's data getting encrypted because the RDP profile was configured to pass through storage drives and the remote system had ransomware which was designed to encrypt all (local and remote / network) storage drives.
  – mythofechelon
  Aug 7 at 14:28
  

  
  
  
  

add a comment | 

up vote
26
down vote

There are a number of settings in the standard RDP client that could be exploited for an attack on the client, if enabled. For example: shared folders, access to devices like printers, etc.

If you're remoting into a known compromised machine, you might want to disable as much as possible in the client's connection and sharing options before connecting.

It's also possible that in addition to the things that you intentionally shared, there could be vulnerabilities in the RDP client itself. Ensure you're patched and up-to-date, and treat the client machine as at-risk of infection until you have a chance to scan it for indicators of compromise.

share|improve this answer

answered Aug 6 at 14:49

nbering

3,19611320

• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  Clipboard is an attack surface in case you happen to copy any passwords or other sensitive info into clipboard at any time the RDP is open, or have accidentally done so as a last copy operation before opening the RDP. Clipboard sharing can be disabled too.
  – Roland Pihlakas
  Aug 6 at 22:08
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, I've heard of the local system's data getting encrypted because the RDP profile was configured to pass through storage drives and the remote system had ransomware which was designed to encrypt all (local and remote / network) storage drives.
  – mythofechelon
  Aug 7 at 14:28
  

  
  
  
  

add a comment | 

up vote
26
down vote

up vote
26
down vote

There are a number of settings in the standard RDP client that could be exploited for an attack on the client, if enabled. For example: shared folders, access to devices like printers, etc.

If you're remoting into a known compromised machine, you might want to disable as much as possible in the client's connection and sharing options before connecting.

It's also possible that in addition to the things that you intentionally shared, there could be vulnerabilities in the RDP client itself. Ensure you're patched and up-to-date, and treat the client machine as at-risk of infection until you have a chance to scan it for indicators of compromise.

share|improve this answer

answered Aug 6 at 14:49

nbering

3,19611320

There are a number of settings in the standard RDP client that could be exploited for an attack on the client, if enabled. For example: shared folders, access to devices like printers, etc.

If you're remoting into a known compromised machine, you might want to disable as much as possible in the client's connection and sharing options before connecting.

It's also possible that in addition to the things that you intentionally shared, there could be vulnerabilities in the RDP client itself. Ensure you're patched and up-to-date, and treat the client machine as at-risk of infection until you have a chance to scan it for indicators of compromise.

share|improve this answer

answered Aug 6 at 14:49

nbering

3,19611320

share|improve this answer

share|improve this answer

answered Aug 6 at 14:49

nbering

3,19611320

answered Aug 6 at 14:49

nbering

3,19611320

answered Aug 6 at 14:49

nbering

3,19611320

3,19611320

• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  Clipboard is an attack surface in case you happen to copy any passwords or other sensitive info into clipboard at any time the RDP is open, or have accidentally done so as a last copy operation before opening the RDP. Clipboard sharing can be disabled too.
  – Roland Pihlakas
  Aug 6 at 22:08
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, I've heard of the local system's data getting encrypted because the RDP profile was configured to pass through storage drives and the remote system had ransomware which was designed to encrypt all (local and remote / network) storage drives.
  – mythofechelon
  Aug 7 at 14:28
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  10
  

  
  
  
  
  
  

  
  Clipboard is an attack surface in case you happen to copy any passwords or other sensitive info into clipboard at any time the RDP is open, or have accidentally done so as a last copy operation before opening the RDP. Clipboard sharing can be disabled too.
  – Roland Pihlakas
  Aug 6 at 22:08
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  Yes, I've heard of the local system's data getting encrypted because the RDP profile was configured to pass through storage drives and the remote system had ransomware which was designed to encrypt all (local and remote / network) storage drives.
  – mythofechelon
  Aug 7 at 14:28
  

  
  
  
  

10

10

Clipboard is an attack surface in case you happen to copy any passwords or other sensitive info into clipboard at any time the RDP is open, or have accidentally done so as a last copy operation before opening the RDP. Clipboard sharing can be disabled too.
– Roland Pihlakas
Aug 6 at 22:08

Clipboard is an attack surface in case you happen to copy any passwords or other sensitive info into clipboard at any time the RDP is open, or have accidentally done so as a last copy operation before opening the RDP. Clipboard sharing can be disabled too.
– Roland Pihlakas
Aug 6 at 22:08

Yes, I've heard of the local system's data getting encrypted because the RDP profile was configured to pass through storage drives and the remote system had ransomware which was designed to encrypt all (local and remote / network) storage drives.
– mythofechelon
Aug 7 at 14:28

Yes, I've heard of the local system's data getting encrypted because the RDP profile was configured to pass through storage drives and the remote system had ransomware which was designed to encrypt all (local and remote / network) storage drives.
– mythofechelon
Aug 7 at 14:28

add a comment |