Many Remote Desktop Services admins share the mistaken notion that placing your RDS environment behind one or more Remote Desktop Gateways makes it impervious to hacking attempts. Unfortunately, this couldn’t be further from the truth, especially with relatively new dictionary attack tools like Patator that can attack your RD gateways. Please review this article and watch my comprehensive RDPHard Channel video below to understand how to layer in defenses to reduce this threat.
Point 1 – Remote Desktop Gateways can be brute forced and dictionary attacked just like terminal servers that are open over Port 3389 on the Internet.
Admittedly, placing your RDS servers behind a Remote Desktop Gateway is much better than just leaving them directly connected to the Internet with port 3389 open. In that scenario, attackers can use tools like Hydra and Crowbar to do dictionary attacks against your servers until they find a weak username and password combo.
What folks don’t seem to understand is that Remote Desktop Gateways are also vulnerable to dictionary attacks. As recently as 2018, a module that targets Remote Desktop Gateways was released for Patator, which is a multipurpose brute force and dictionary attack tool.
At its core, the Remote Desktop Gateway is basically an HTTPS proxy for RDP with additional support for UDP tranmission channels. Patator’s Remote Desktop Gateway module understands this, and by doing HTTP authorizations with the PYCURL library, it can run through username and password combos very rapidly. Any matching username / password combos will show a successful response in Patator’s output, which can be analyzed once an attack has been concluded.
Also keep in mind that with the advent of banner scraping search engines like Shodan, its trivially easy for an attacker to find the address of your Gateway, since most organizations running Remote Desktop Gateway have the RD Web Access module running on the same server.
Point 2 – Weak default CAPs and RAPs on RDS Gateways can potentially expose all of your internal servers to attack.
One of the weakest aspects of Remote Desktop Gateway security it its default CAP and RAP policies. By default, everything is wide open. Meaning, when you first install a Remote Desktop Gateway, any domain user will be able to connect through that gateway and access ANY system inside the network.
One of the first things you must do after deploying a Remote Desktop Gateway is lockdown the CAP and RAP policies so that only specific users in the domain can access RDS related servers (or specific workstations if you are using the RD gateway as a bridge to internal workstations or virtual desktops for telework). Watch the video above to see how this is done.
Point 3 – Deploy an MFA solution specifically designed for RDS.
In general I recommend MFA solutions that have direct support for RDS gateways, via push notifications when a Gateway authentication is taking place. The two most popular solutions for RD Gateway that I’m aware of are Cisco Duo and the NPS Extension for Azure Active Directory MFA. When enabled, these solutions require a secondary confirmation during the RD Gateway login via use of a mobile app, or via a phone call.
There are additional MFA solutions for Remote Desktop, but most of these only protect the session hosts, not the Remote Desktop Gateway. In other words, authentication through the RD Gateway remains a simple username/password combo, and the MFA doesn’t kick in until the user has connected to the Remote Desktop Session Host, at which point the MFA challenge kicks in.
As a result, this increases the vulnerability of the organization for several reasons.
- The first reason is that as an attacker, I can still run dictionary attacks against the Gateway unimpeded using a tool like Patator. So, I can glean valid credential combos just by banging on the gateway.
- If you have not properly secured your RD Gateway CAPs and RAPs, I can construct my own RDP file in an attempt to connect directly to other systems over RDP outside of your RDS environment that are not protected by MFA.
- Once I have valid credentials, ANY other service or application that your organization runs which is not secured by MFA I can now target successfully, using breach replay attacks with those valid credentials against those secondary services.
Remote Desktop Gateway Security Takeaways
To summarize, here are the key things you need to do to better secure Remote Desktop Gateway if you use it in your RDS environment:
1.) Implement an MFA solution designed specifically for the RD Gateway, such as Cisco Duo or the NPS Extension for Azure AD MFA.
2.) If you use an MFA solution that only works on the Remote Desktop Session Hosts, make sure that you monitor both failed and successful authentications taking place on the Remote Desktop Gateway, preferably with the ability to geolocate IP addresses. Our Remote Desktop Commander Suite product has that capability, by the way. Also, make sure that you have MFA enabled on other external services and apps that your users access with their Active Directory credentials.
3.) In all scenarios, make sure you lock down your Remote Desktop Gateway CAPs and RAPs to both limit who can authenticate through the Remote Desktop Gateway, and the systems they can connect into over RDP in your internal network.