We (still) need to talk about RDP

Quarter by quarter, for three years now, abuse of Remote Desktop Protocol (RDP) has been the most common root cause of all ransomware events.

It’s no surprise why RDP makes for an attractive target: RDP is the primary vehicle for remote access to Windows servers and is used for administrative functions. It’s the most commonly listed method of remote access sold by initial access brokers.

According to some 2019 research [pdf] by Sophos, an open RDP port gets its first connection request somewhere between 90 seconds and 15 hours of being exposed on the internet. Brute forcing RDP is so easy, the researchers noted, that “the criminal gangs who conduct targeted ransomware attacks have almost entirely abandoned alternative methods of network entry.”

“In recent years, criminals deploying targeted ransomware like BitPaymer, Ryuk, Matrix, and SamSam have almost completely abandoned other methods of network ingress in favor of using RDP. Gangs like these have the choice of cracking passwords themselves using tools like NLBrute, buying passwords cracked by others, or buying accounts on compromised RDP servers.”

The situation hasn’t improved much since then. According to a joint statement released by authorities in the US, UK and Australia in February, ransomware actors assumed that organizations rushing to provide remote access during the first COVID lockdowns would misconfigure RDP. And oh boy, were they right.

All that said, I’ve never been 100% sure about whether there were systemic reasons that made RDP so prone to abuse. Surely, by now, after these hundreds of awareness campaigns and news articles, the collective hygiene practiced by systems administrators has improved to make this sort of abuse less effective?

Today there are a larger number of methods for discovering rogue servers and locking down RDP, while the risks of leaving RDP unprotected have only increased. And yet we aren’t seeing a downward trend in the number of exposed endpoints (or compromised networks) stemming from abuse of RDP. I don’t want to give in to the temptation of just putting it down to “lazy admins” and “miserly CIOs”. There has to be more to it.

Source: Shodan.io

By a “systemic” reason, I mean a set of conditions that lead to poor security outcomes, as opposed to a specific vulnerability. A systemic reason might be insecure defaults, for example, or indecipherable documentation. It might be essential security tasks that require additional “premium” licenses or for settings to be configured in multiple admin consoles. It’s often a combination of those things.

Recently a few observations made it all click for me.

The first came courtesy of a former Microsoft security engineer dropping a truth-bomb on Twitter. RDP is usually abused using brute force attacks, he noted, because there aren’t any out-of-the-box ways to apply rate limiting to RDP.

“An entire and large part of the ransomware economy is this singular issue.”

And just as I was getting my head around how Microsoft would go about applying rate limiting in a server OS (it’s not trivial), my former colleagues at the Risky Business podcast published a groundbreaking interview with Michael Montaya, CISO of Equinix. Montaya rather bravely gave Risky Business a blow-by-blow account of a ransomware incident at the company. The beachhead for the attack was a brute force attack on an unsanctioned server with RDP exposed to the internet.

“The configurations that come out of the box in the cloud don’t always follow best practices,” Montaya explained.

If you combine the constrained ability of security teams to discover open RDP ports in unsanctioned infrastructure, and the unconstrained ability for attackers to test stolen credentials against clients with RDP exposed, it starts to take the shape of a systemic problem.

If you glance at where you find the most Windows servers with RDP open to the internet, it doesn’t marry closely with market share. There seems to be disproportionately more vulnerable servers hosted by managed service providers that rent access to Windows VMs as a “cloud service”. The default settings at these service providers is worthy of analysis.

In this context, it’s just a little tiresome to keep chalking up abuse of RDP to “poor user credential hygiene”. That’s the sort of cop out that’s enabled initial access brokers and ransomware affiliates to thrive for the five years. Our services should, at some level, be configured to anticipate and expect that users will practice poor credential hygiene. At the very least, service providers should offer VMs with inbound connections over RDP blocked by default.

Keep beating that drum

Given the known conditions that make RDP so vulnerable, we unfortunately need to keep hammering home the message that admins avoid exposing RDP to the internet in the first place - even if a lot of people are sick of hearing about it.

Inbound connections via RDP should be limited to trusted network sources and protected by multifactor authentication. In a true “zero trust” context, that means MFA is applied even when the admin is already on the network. Better yet, the only trusted source should be a jump host/bastion host that admins must authenticate to first. All authentication via RDP should be logged and monitored for large numbers of unsuccessful logins.

If remote access is absolutely required, an admin should first have to authenticate via a gateway. Bonus points if the solution involves “just in time” access - that is, ephemeral credentials for every session.

These controls aren’t so difficult to implement, but they can be difficult to sell into IT admins that complain loudly about the slightest inconvenience.

In infosec we expend a lot of time and investment in mitigating numerous “theoretical” risks. It’s disappointing that something as commonplace as the abuse of RDP isn’t flashy enough to warrant more energy.

So “once more unto the breach”, my infosec friends, there are better ways to secure remote access.