I was hacked via RDP. What can I do to shore up security?

Question

I have a Windows 7 64-bit box at home that I use as a "server" computer. It runs Windows Media Center and provides TV to every room in my home. It also serves as shared storage for the home, providing space for Windows Backups and any files my family members want to keep duplicates of.

This computer also serves as MY personal computer. I have my own account on it which I access through RDP. When I want to use a PC I will grab the family laptop or my wife's computer and I'll RDP into this Windows 7 box to my account, desktop, apps, etc. I can also RDP into this machine from outside my home using my public IP address.

Recently I was hacked. The RDP logs show someone logged in as me. They opened Chrome and found stored passwords in the browser. These are of course extractable through the developer console in Chrome. This resulted in $10,000 in fraudulent charges through my PayPal and Google accounts which in turn hit my checking, and credit cards.

My password contained letters, numbers, and symbols. How could anyone have done this? What can I do to beef up security in the future? The box is offline at the moment until I can run virus and malware scans as well as HijackThis, etc. I'm scared to plug the network cable back in. I don't want a true Windows Server because I'd lose MCE and I'm only really using shared storage otherwise.

Answer 1

How could anyone have done this?

There could be a lot of possible ways depending on your setup. Without looking at logs of the affected devices(s) or the network configuration, answering this would be mostly guess work and too broad to discuss. If you have any specific logs, diagram of your setup etc., possible points of attack can be determined and the answer to this could possibly be narrowed down.

What can I do to beef up security in the future?

Make sure Network Level Authentication is enabled

Windows 7 provides Network Level Authentication (NLA) by default. It is best to leave this in place, as NLA provides an extra level of authentication before a connection is established. You should only configure Remote Desktop servers to allow connections without NLA if you use Remote Desktop clients on other platforms that don't support it.

Make sure you have the latest Windows Updates and security software updates

New vulnerabilities are discovered everyday therefore it is good to make sure that you have the latest Windows updates and updates to any security software that you use. For example, there have been vulnarabilites like this: Vulnerability in RDP Could Allow Remote Code Execution (3073094) (this did affect Windows 7 x64 which you have mentioned in the question). If you do not have the appropriate updates in place, someone might be able to exploit these vulnerabilities to get into your PC.

Restrict access using firewalls

Use firewalls (both software and hardware where available) to restrict access to remote desktop listening ports (default is TCP 3389).

Limit users who can log in using Remote Desktop

By default, all Administrators can log in to Remote Desktop. If you have multiple Administrator accounts on your computer, you should limit remote access only to those accounts that need it. If Remote Desktop is not used for system administration, remove all administrative access via RDP and only allow user accounts requiring RDP service. For users that manage many machines remotely, remove the local Administrator account from RDP access at and add a technical group instead.

1. Click Start → Programs → Administrative Tools → Local Security Policy.
2. Under Local Policies, click on User Rights Assignment, go to Allow logon through Terminal Services. Or Allow logon through Remote Desktop Services.
3. Remove the Administrators group and leave the Remote Desktop Users group.
4. Use the System control panel to add users to the Remote Desktop Users group.

Set an account lockout policy

By setting your computer to lock an account for a period of time after a number of incorrect guesses, you will help prevent hackers from using automated password guessing tools from gaining access to your system (this is known as a "brute-force" attack). To set an account lockout policy:

1. Go to Start → Programs → Administrative Tools → Local Security Policy.
2. Under Account Policies click on Account Lockout Policies.
3. Set values for all three options. 3 invalid attempts with 3 minute lockout duration are reasonable choices.

See Account Lockout Policy for details.

Change the listening port for Remote Desktop

Changing the listening port will help to "hide" Remote Desktop from hackers who are scanning the network for computers listening on the default Remote Desktop port (TCP 3389). This offers protection against the latest RDP worms such, as Morto. To do this, edit the following registry key (WARNING: do not try this unless you are familiar with the Windows Registry and TCP/IP):

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp.

Change the listening port from 3389 to something else and remember to update any firewall rules with the new port.

Please note: Although this approach is helpful, it is security through obscurity which is not the most reliable security approach. You should ensure that you are also using other methods to tighten down access.

Use RDP Gateways if possible

Using a RDP Gateway is strongly recommended. This however needs to be installed on a Server OS. It comes built-in to Windows Server 2008 and 2012. It provides a way to tightly restrict access to Remote Desktop ports while supporting remote connections through a single "Gateway" server. When using an RD Gateway server, all Remote Desktop services on your desktop and workstations should be restricted to only allow access only from the RD Gateway. The RD Gateway server listens for Remote Desktop requests over HTTPS (port 443), and connects the client to the Remote Desktop service on the target machine.

There are many online documents for configuring this. The official documentation is here: Installing RD Gateway

Installing the configuring the role service is mostly as described; however, using a certificate is recommended. Using a self-signed cert is ok for testing.

Configuring your client to use your RD Gateway is simple. The official documentation for the MS Client is here: Configure Remote Desktop Connection Settings for Remote Desktop Gateway

Tunnel Remote Desktop connections through IPSec or SSH if possible

If using an RD Gateway is not feasible, you can add an extra layer of authentication and encryption by tunneling your Remote Desktop sessions through IPSec or SSH. IPSec is built-in to all Windows operating systems since Windows 2000, but use and management is greatly improved in Windows Vista/7/2008 (see: IPsec). If an SSH server is available, you can use SSH tunneling for Remote Desktop connections. See Tunneling Remote Desktop Over SSH with PuTTY,Create an SSH Tunnel for Remote Desktop and how to tunnel Windows Remote Desktop through ssh using a linux box? for some examples.

Use existing management tools for RDP logging and configuration

Using other components like VNC or PCAnywhere are not recommended because they may encrypt the sessions as with RDP. RDP also has the benefit of a central management approach via GPO (if used within a domain which may not be the case in your scenario). Whenever possible, use GPOs (if possible) or other Windows configuration management tools to ensure a consistent and secure RDP configuration across all your PCs at home.

By enforcing the use of a RDP gateway, you also get a third level of auditing that is easier to read than combing through everything on the target PC. This type of log can make it much easier to monitor how and when RDP is being used across all the machines in your setup in case another event occurs.

Use Two-factor authentication if possible

Consider using a two-factor authentication approach. RD Gateways do provide a simple mechanism for controlling authentication via two factor certificate based smartcards. Other two factor approaches need another approach at the Remote Desktop host itself e.g. YubiKey, RSA.

Additional security with Network Access Protection (NAP)

You may also investigate the use Network Access Protection (NAP) with an RD Gateway (on a server OS), however, that technology and standard is not well developed or reliable yet. Many clients will not work if you enforce it, although by following the documentation, you can audit the system to see if it thinks the clients are security compliant.