Sign up to our newsletter
Lately, we’ve seen an increase in reports of malware being installed via Remote Desktop Protocol (RDP). This is the powerful protocol which has been letting you view a Windows desktop “over the wire” on the other side of the globe (or back at your home from the office) for over a decade now. Sadly, while RDP can serve a variety of useful purposes ranging from remote “hands-on” support to configuring and running servers, in the wrong hands it can be a remote control weapon that enables bad actors to zombify your computer and have it do their bidding.
How could this happen? If your computer is “listening” for an RDP signal (typically over port TCP 3389), and it is connected to the Internet, it will respond when a remote user asks it if it’s alive. To the remote user, they will be presented with a login screen to your desktop, often without you noticing (especially if your computer is on and you just happen to be away from it). At this point, your computer will prompt them for a password – usually. If you have a poorly configured RDP setup on your computer though, it may just let them in. If it does, it’s just the beginning of your trouble.
What can RDP intruders do? If you have administrative privileges assigned to the user they login as, they can take your computer for an unfettered spin around the block, ranging from turning it off, rebooting it, installing software (including malware), or just having a look around to find documents of files with your critical personal information in them like banking, accounting, or other information and then spirit them off across the network to their own computers for nefarious purposes.
How do you stop all this? First thing is to know if you have RDP enabled. That’s easy to check from your Control Panel under System > Remote Settings > Remote Desktop (under Windows 7, other operating systems vary).
Notice this test computer has Remote Desktop (RDP) disabled, which is fine for testing purposes, as nobody should be logging in remotely on this box. But if you choose to allow connections, take some time to define who you think should be connecting using the “Select Users” dialog box:
Notice the user that you are logged in as already has access (blanked out in example). When remote attackers come calling this could pose problems for an unwitting user who is logged in as Administrator. Very likely the bad guys will be looking to gain elevated access, and logging in as Administrator is a quick way to do that. If they can pair that valid User with an easy-to-guess password, they’ve got the keys to your computer’s crown jewels.
Recently, we’ve seen a spike in an RDP-based attacks using the Win32/Filecoder.NAH Trojan (also known as ACCDFISA) which attempts to encrypt files on your computer and extort money to pay the bad guys to unlock them.
Never mind the fact that it’s always a bad idea to send money to scammers in a scheme like this (especially via credit card, which virtually guarantees further fraud), the whole thing could be simply avoided by disabling the service if you don’t need it, and protecting it if you do.
Speaking of protection, aside from not using easily guessed usernames, a strong password would also go a long ways toward protecting the account. If hackers can programmatically “guess” your password because it’s based on a simple word – they will quite quickly. On the other hand, if it’s complex, meaning a combination of upper and lower case letters, numbers, and symbols (the longer the better), their task becomes much more daunting.
If you need to use RDP and are more technically inclined you can change the port on which RDP “listens” for connections (the default port is 3389). Microsoft has an article on how to do this in many versions of Windows. You can also find a range of possible solutions discussed on Stack Overflow.
And on the subject of remote desktop support, stay alert for those “Windows support” people who phone and ask you to install special remote access software to allow them to “fix” your computer. Falling for that scam can end badly. For more on that, take a look at David Harley’s article here.
Author Cameron Camp, ESET