Cybersecurity Insurance denied due to RDS Gateway

[ITProJeff]

I recently had a client get denied Cybersecurity Insurance due to their RDS Gateway being exposed to the internet (this is RDS Gateway on port 443/3391, not Remote Desktop port 3389). Their claim was that "Current threat actor activity on the internet is focusing on targeting this technology to deploy ransomware and other malware." We had GeoIP filtering restricting access to USA only, MFA, and a brute-force detection/IP blocking software installed. Their only solution was to put it behind a VPN or disable it altogether. We're currently pressing them to find out if that's also required for Citrix Netscaler or VMWare Horizon since they're exposed to the internet as well and can (and have) had vulnerabilities. 

I have not heard of any "threat actor activity" actively exploiting RDS Gateway and am wondering if the new standard is not exposing it to the internet and I missed that? Is everyone else putting it behind a VPN and praying for no or low vulnerabilities on that?

[rapheal21]

This was insane, but we survived it somehow. The hackers managed to RDP directly into our primary backup server with an old administrator account that was created before password complexity requirements were in place(probably either blank or under 4 characters). They ran their scripts which encrypted everything on that machine plus every shared folder visible from that machine using administrator credentials. The damage was widespread as we have lots of shared drives nearing 10TB of data.

The only thing that saved us was our secondary off-site backup that had zero shared folders. It was backed up using Quest which was not visible though windows fileshare services.

This happened Thursday at 11pm CST. As of this morning we are 100% back up.

PSA, if your backup locations are being shared on the network, DHARMA will find it. I used to store my backups that way and would have been screwed if it was still setup like that. Also, block RDP at your firewalls. Your employees should be using VPN to get in then RDP anyways.

Edit: We have RDP blocked at the firewall. I just mentioned it because that is how they usually get in, by abusing RDP vulnerabilities. We are still looking into how they might have gotten access, but unfortunately without a dedicated log server it probably won't happen.

[ITProJeff]

Can you confirm that you had RDP open to the internet and NAT'd to that server and were not using Remote Desktop Gateway? I'm specifically talking about Remote Desktop Gateway (port 443).

[tmekelburg1]

I'm going to wager the insurance company, just like @rapheal21, misunderstood the difference between allowing regular RDP access to the internal network vs. using RDP to connect to an RD Gateway. I wasn't able to find any CVE's related to using an RD Gateway server this year but they may have more intel than we do.

Are you able to get the exact reasons from their insurance carrier? Sounds like adding a VPN would just open up the attack surface even more because now you'll have to make sure that product is patched and configured correctly. Not to mention adding two additional remote login steps with 2FA to the VPN and using 2FA again on the RD Gateway login. Also wondering if the VPN would circumvent some of the granular resource access that you configured in the RD Gateway server (just thinking out loud)? 

Hopefully we have some threat researchers within the Community that may shed some light on RD Gateway vulns.  

[junghyun]

I haven't heard of "threat actor activity" actively exploiting RDS Gateway recently either, but I've somehow had this discussion in the past. I didn't yet raise my bar, but with RDP there's always a risk of MITM and it seems the industry in overall wants to harden its security by putting the RDP gateway behind VPN defense-in-depth fashion. Not totally absurd.

[ITProJeff]

Thank you for the reply. Their email to use did indicate Remote Desktop Gateway instead of RDP, but I agree they're likely may not understand the difference. That's one of the things we're pressing them on. Aside from user frustration and the infrastructure/licensing needed to add the VPN as a layer you are correct is does open up another attack vector, effectively trading one for the other. Perhaps in their mind it's worth it. I'm also thinking since RDS Gateway won't show up in any scans (Shodan for example) they're simply skip past us.

[tmekelburg1]

@junghyun I may be wrong but I thought they fixed the MITM issue by admins installing a cert on the end device and RD Gateway that would verify each endpoint and encrypt the channel upon connection? I'm not super familiar with it because we use a VPN for remote instead 🙃. 

@ITProJeff Yeah anything with RDP in it is a dirty word nowadays. Protocol-that-must-not-be-named. 

[junghyun]

@tmekelburg1 Thanks for asking. There hasn't been a report of MITM with RD gateway that I know of, it's mostly in account of RDP, and as was mentioned in the previous thread it's technically unrelated. My worry is, unfortunately the industry seems to treat RD gateway and RDP alike functionally, mistakenly or intentionally.

[ITProJeff]

Appreciate all the replied. Does anyone have experience with a technical solution other than a VPN?

The options I'm thinking are:

   1. Behind VPN in firewall
   2. Behind dedicated VPN appliance
   3. Azure AD proxy? I believe this would work to hide the RDWeb site, but would RDP shortcuts configured     with the RDS gateway address still work?

   4. Cloudflare option?
   

[Caute_cautim]

@ITProJeff 

Think laterally, given the attacks on VPN, look to SDN's, Hybrid Cloud architecture and Secure Access Security Edge (SASE), but do your homework, some are built from the ground up, different approach, some are based on hardware legacy systems, and others are just additions to existing approaches.

Ditch the VPN, and move towards SASE and Zero Trust approach.

Regards

Caute_cautim