For the last two months the infosec world has been waiting to see if and when criminals will successfully exploit CVE-2019-0708, the remote, wormable vulnerability in Microsoft’s RDP (Remote Desktop Protocol), better known as BlueKeep.
The expectation is that sooner or later a BlueKeep exploit will be used to power some self-replicating malware that spreads around the world (and through the networks it penetrates) in a flash, using vulnerable RDP servers.
In other words, everyone is expecting something spectacular, in the worst possible way.
But while companies race to ensure they’re patched, criminals around the world are already abusing RDP successfully every day, in a different, no less devastating but much less spectacular way.
Many of the millions of RDP servers connected to the internet are protected by no more than a username and password, and many of those passwords are bad enough to be guessed, with a little (sometimes very little) persistence.
Correctly guess a password on one of those millions of computers and you’re in to somebody’s network.
It isn’t a new technique, and it sounds almost too simple to work, yet it’s popular enough to support criminal markets selling both stolen RDP credentials and compromised computers. The technique is so successful that the criminals crippling city administrations, hospitals, utilities and enterprises with targeted ransomware attacks, and demanding five- or six-figure ransoms, seem to like nothing more.
All of which might make you think – there must be a lot of RDP password guessing going on.
Well, there is, and thanks to new research published by Sophos today, we can take a stab at saying just how much.
Noting the popularity of RDP password guessing in targeted ransomware attacks, Sophos’s Matt Boddy and Ben Jones (who you may have heard on the Naked Security podcast), and me, set out to measure how quickly an RDP-enabled computer would be discovered, and just how many password guessing attacks it would have to deal with every day.
They set up ten geographically dispersed RDP honeypots and sat back to observe. One month and over four million password guesses later they switched off the honeypots, just as CVE-2019-0708 was announced.
The low interaction honeypots were Windows machines in a default configuration, hosted on Amazon’s AWS cloud infrastructure. They were set up to log login attempts while ensuring attackers could never get in, giving the researchers an unhindered view of how many attackers came knocking, and for how long, and how their tactics evolved over the 30-day research period.
The first honeypot to be discovered was found just one minute and twenty four seconds after it was switched on. The last was found in just a little over 15 hours.
Between them, the honeypots received 4.3 million login attempts at a rate that steadily increased through the 30-day research period as new attackers joined the melee.
While the majority of attacks were quick and simple attempts to dig out an administrator password with a very short password list, some attackers employed more sophisticated tactics.
The researchers classified three different password guessing techniques used by some of the more persistent attackers and you can read more about them – the Ram, the Swarm and the Hedgehog – in the whitepaper.
What to do?
RDP password guessing shouldn’t be a problem – it isn’t new, and it isn’t particularly sophisticated – and yet it underpins an entire criminal ecosystem.
In theory, all it takes to solve the RDP problem is for all users to avoid really bad passwords. But the evidence is they won’t, and it isn’t reasonable to expect they will. The number of RDP servers vulnerable to brute force attacks isn’t going to be reduced by a sudden and dramatic improvement in users’ password choices, so it’s up to sysadmins to fix the problem.
While there are a number of things that administrators can do to harden RDP servers, most notably two-factor authentication, the best protection against the dual threat of password guessing and vulnerabilities like BlueKeep is simply to take RDP off the internet. Switch off RDP where it isn’t absolutely necessary, or make it accessible only via a VPN (Virtual Private Network) if it is.
Want to learn more?
To learn more about what the researchers discovered, the tactics the attackers used and the way that different regions were affected, read the full report: RDP Exposed – The Threat That’s Already at Your Door.
After publishing the whitepaper, Matt and I sat down with Naked Security editor Anna Brading to talk about the research and take questions from viewers on Facebook Live. You can view a recording of the broadcast below:
(Watch directly on YouTube if the video won’t play here.)
13 comments on “RDP exposed: the wolves already at your door”
Is RDP something that individual users and small business owners need to take action on?
How do I tell if an RDP is set up on one of my computing devices? The obvious platforms are Windows, macOS, iOS, and Android, with runners up Linux and Chrome OS. Sure, I could do a general internet search but I might wind up with results from dicey sources.
Further: Suppose RDP is configured on one of my devices. How do I (as an individual) change the passwords and set up 2FA? Here’s where citing reliable other sources would save Sophos from having to redescribe what is well and properly described elsewhere.
In Windows, I hear that Remote Desktop and Remote Assistance are different. Does this post from Sophos apply to Remote Assistance as well?
Is RDP something that individual users and small business owners need to take action on? Yes!
RDP is a Windows protocol. Here are the ways you can discover if it’s running on your Win 10 or 7 devices:
Windows 7: Open the start menu, right click on Computer and select properties. Select “Remote settings” in the left menu. Under “Remote Desktop” check to see if remote connections are allowed.
Windows 10: Open the start menu and search for “remote settings”. This should open up the System section of control panel. Select “Remote settings” and make sure that “Don’t allow remote connections to this computer” is selected.
The only way to setup two-factor authentication is through separate products. There are items like DUO which can provide a second factor of authentication for Windows devices (at a cost), or you can use a Remote Desktop Gateway, which requires a gateway server.
VPN is well known but you should also mention Microsoft RDP gateways which only expose SSL for RDP. These gateways can be further protected behind web application firewalls to minimize the attack surface.
There is an easy fix for this – disable the Admin user, set the windows policy to limit X failed attempts then lock the computer for X minutes, or better yet, limit the scope of IP addresses which can connect
The problem with RDP isn’t the absence of easy fixes, it’s that easy fixes are ignored.
We have RDP enabled on 2 (non standard) ports, each port goes to its own server. There’s a couple of hundred failed logins every night but the passwords they try are just the typical bad standard passwords like “Admin” and “password” and “password123” and such. This has been going on for many years but they never actually breach it. They rarely guess the correct username and when they do they don’t guess the password. One day they’ll get in and that’s why we have backups.
Security through obscurity….genius! That way. You never have to pack because the bad guys can’t find you. Why did Nite think of that?
I hate to tell you this, but that’s not really good security. That is like hiding in a bush in the middle of a war zone. Sure, you haven’t gotten hit yet. But you will eventually get hit. And when you do, it will be a bad time.
First off never expose your RDP port to the internet, use a gateway broker like html5 RDP and port 443 (SSL) to establish a proxy connection. Then use a firewall to limit connection attempts, if x attempts occur in y time then block. Now if your using weak passwords learn to use echo ‘somephrase’ | md5sum take the output and modify it with upper case and special characters, easy pease. Hackers want low hanging fruit, so make it harder for them.
This article makes it sound like enabling RDP with the default windows 10 pro settings is more dangerous than using a VPN. Why would this be true, at least in terms of a brute force attack and assuming just a username password for both?
As I understand it RDP’s default settings include a 30-60 minute lockout after just a few failed login attempts, so a brute force attack would be fruitless against all but the most simplistic passwords. The main risk of using RDP is that you won’t be able to get in when you need to because the admin account will be locked out due to excessive failed login attempts. Renaming the admin account to something less obvious all but eliminates the denial of service threat.
Our methodology was designed to expose what happens if you do nothing – the honeypots used default installations of Windows 10 on AWS and they didn’t come with any lockouts pre-configured.
A brute force attack is fruitless against strong passwords but enough internet-connected computers are protected by simplistic passwords to support an ecosystem of ransomware gangs charging five and six figure ransoms.
Hmmm. I just rechecked this and I see that you are correct that Window 10’s default settings allow an infinite number of continuous failed login attempts.
That seems like a terrible choice for a default, but now I understand why it’s easy for folks to get tripped up by this.
Um, “Windows machines in a default configuration”. What? You were running 32-bit Windows XP and thought it would be secure? Or… maybe you meant something else? I can’t tell from the hyperbolic tone. According to Microsoft, security updates are being offered only for Windows 7 (6 months from end of life) and previous versions (already dead).