Last updated at Wed, 14 Oct 2020 02:04:31 GMT
This week, Rapid7 Managed Detection and Response’s (MDR) intrepid investigators identified an increase in RDP attacks targeting RDP servers without multi-factor authentication enabled. Given that a fair number of folks are still working remotely, it’s no wonder that attackers continue to seek out and compromise these gateways into organizations.
The Rapid7 Labs and MDR teams also took a look at global RDP attacker activity and prepared some guidance to help defenders ensure their infrastructure is less susceptible to the invading hordes.
RDP exposure redux
We checked our most recent October Project Sonar RDP study and were glad to see that nearly 60% of 4,252,702 exposed RDP endpoints have upgraded to use Network Level Authentication (NLA) likely to help thwart BlueKeep attacks. Enabling NLA forces users to authenticate before establishing an RDP session, which adds a layer of defense to these exposed systems.
| Security Used | Count | Percentage |
|---|---|---|
| NLA | 2,449,447 | 58% |
| TLS | 1,536,173 | 36% |
| Standard | 267,082 | 6% |
While many of these exposed systems are within residential networks, small businesses, and cloud environments, 16% of the Fortune 500 are exposing one or more RDP servers on the default port and over half of those aren’t using NLA (some aren’t even using TLS). This shows that even the most well-resourced organizations are struggling to safely deploy and maintain RDP.
Unfortunately, attackers have access to 15 billion credentials and are really good at phishing all of us, so simple usernames and passwords really aren’t sufficient to protect internet-facing RDP servers. If you cannot disable the use of Microsoft Remote Desktop, the Rapid7 MDR and Labs teams recommend:
- Configuring NLA! Over 1.5 million internet-exposed RDP systems still aren’t configured with NLA.
- Ensuring you have an account lockout threshold configured along with monitoring of login attempts to detect brute force and credential stuffing attacks.
- Configuring your password policies to require good passwords.
- Where possible, restricting the remote IPs that can access RDP-enabled systems.
- Adding multi-factor authentication to all RDP hosts; ideally, you’d be better off placing your RDP enabled systems behind a RDP Gateway or a virtual private network (VPN), since Microsoft keeps patching holes in RDP and you never know who has an 0-Day just waiting in the wings to use against your organization (plus, we know most of y’all still don’t patch these things in a timely manner).
Increased attacker activity
The Rapid7 Labs team couldn’t let the MDR team have all the, er, “fun”, so we took a look at recent attacker activity since September 2020. As usual, the BlueKeep attack volume is orders of magnitude lower than RDP brute-force/credential stuffing attempts.
Toward the end of September, we saw a spike in these attempts, which further aligns with what our responders have been seeing across our managed customers. This underscores the fact that opportunistic (and targeted!) attackers aren’t getting bored with RDP and continue to hone their tactics and techniques to achieve their goals.
Take some time over the next few weeks to reassess your RDP exposure and use the above guidance to help make your remote access configurations more resilient.
Assessing RDP exposure with InsightVM
InsightVM customers can use Query Builder to find exposed RDP ports in their environments with the following query:
services.name = 'rdp'
This query can be saved and visualized in a Dashboard Card by adding a Total Asset Trends card and selecting the saved query. This card will show the total number of assets where an RDP service was found and how that number has changed over a specified time period.
AttackerKB analysis with attacker perspective on insecure RDP implementations can be found here.
