Alexa metrics
Live Chat

Welcome to UKFast, do you have a question? Our hosting experts have the answers.

Chat Now
Sarah UKFast | Account Manager

#TrendingTech: Remote Desktop Brute Force Attacks

5 April 2013 by Alice Cullen

Hacker forums and the tech press are abuzz with news of a tool enabling hackers to attack the Remote Desktop protocol of servers. It’s a commonly used protocol on remote servers and relies on common ports being left open to access them. Our friends at cybersecurity firm Secarma explain what it is and, more importantly, how can we protect against it?
ICO warns of cloud-using companies' data protection failings
This type of attack is technically nothing new as we have seen with the Morto worm of 2011, but the frequency of these attacks seems to have skyrocketing recently.

The attacks appear to be based on a simple methodology:

  • Scan a range of IP addresses
  • Scanner looks for open ports usually used by RDP (e.g. 3389)
  • A RDP brute force attack is launched using dictionary terms.

What the attack is trying to do?

A brute force attack on the RDP server allows a connection to the attacker.

As there are no reports of successful breaches yet, we cannot definitively say what the motives behind the attacks are. Similar attacks in the past suggest that infected servers could be used to launch further attacks and thus spread itself. However, it could also be used to install other malware or ransomware.

This port and attack method was used by the famous Zeus botnet which, along with its variants, is still responsible for more than 56% of all botnet infections.

With this type of attack, Windows 2003 servers may also be affected by memory exhaustion which would cause them to reboot and 2008+ servers to fill their log files. Note though, this type of attack is not aimed towards Windows servers only as it is an IP based attack.

How can we protect against it?

As with any emerging threat, there are certain measures and precautions that those running RDP on their servers can take.

Successful logins by the attacker will give them access to the drives of that server (via the shares \\tsclient\c and \\tsclient\d). This may give the attacker access to the content of the server but potentially other parts of your solution usually hidden from the external connection as well, e.g. local backups and development areas.

The good news is that there is plenty that can be done to protect yourself from these types of attack:

  1. Do not use easily guessed passwords on your RDP sessions – consider using a passphrase of non-dictionary terms
  2. Do not use standard usernames (root, admin, owner, test)
  3. Implement account lockout policy for a set number of failed logins before locking out the account
  4. Use an alternative port than the default 3389 for RDP connections
  5. Consider locking the RDP port to a specific IP address (e.g. office location)
  6. If the option is available, use RDP to access the server but lock the server down so that it is only accessible once a VPN connection is established ensures traffic is encrypted and secure.
  7. On Windows 2008 (and server 2012), enable Network Level Authentication which means the session can not established until the credentials are authorised
  8. Patch Patch Patch! Ensure you have all the latest patches installed
  9. Use a vulnerability scan to identify any other areas to ramp up security
  10. Have a plan (proactively scanning and retrospectively use forensics)
  11. Limit users who can login using remote desktop to only the accounts that require access.
  12. Use an RDP Gateway – this allows you to tightly restrict access to remote desktop ports while supporting connections through a single “gateway” server. It does this by using the Remote Desktop Protocol (RDP) over HTTPS to establish a secure, encrypted connection between remote users on the Internet and the internal network resources on which their productivity applications run. The official documentation is here:

The reliance on computers and the use of online technologies is growing exponentially. This means more unattended servers and a reliance on monitoring systems. Be proactive in checking into your servers regularly and performing log analysis to check who is doing what on your server. If you are not sure, speak to an expert who can help.