Monitoring Internal and External RDP with ExtraHop Reveal(x)

The events of the last few months have caused many of the IT teams responsible for remote access to push their systems, their policies, and, in all likelihood, their patience to the breaking point. The deluge of remote workers is only outmatched by the haste in which IT teams and systems were forced to accommodate them.

For some organizations that have mature remote access programs, this transition has been relatively easy with a focus on making sure the incumbent system can scale. Accommodating scale is something that, while it may seem overly simplistic, can be solved with adding equipment (aka… money!). For these organizations it is largely business as usual, with the exception of figuring out how they will maintain visibility for performance, availability, and accountability.

For less mature organizations, these rapid deployments and accommodations of remote access have introduced risks that could eventually result in further security compromises and potentially add the breach of sensitive information to the laundry list of stressors that individuals are already experiencing in the wake of the health, emotional, and economic stress of the COVID-19 calamity.

One of the biggest risks that we're seeing across many of our customer environments involves the Remote Desktop Protocol (RDP). For more on the risks you should know about RDP, read our full security advisory here. In this post, I'll talk about how changing security and IT workflows make risks like RDP unavoidable, discuss how severe RDP exposure can be, and offer some advice on how to balance security and availability in what might feel like a no-win situation.

What's Changed for Security & Engineering Teams?

Most organizations that operate private networks (RFC 1918 address space) for their corporate activities also include some form of security operations center (SOC) comprising engineers and first responders to handle security threats. These individuals are tracking activity from a variety of sources ranging from Endpoint Detection and Response (EDR), Logs (SIEM), and, hopefully, Network Detection and Response (NDR). They've carefully molded and evolved these solutions to fit the organization over the years. But in this "brave new world," they're now forced to ask: what has changed?

First, the tools we have developed and perfected for the typical surveillance motion are likely not applicable in the remote work environment. Many businesses have not yet made the transition from desktop computers to laptops. Most end users cannot, or will not, simply pick their desktops, put them in their car, and take them home (a vision that reminds me of being in high school in the 80s and carrying a 60 lb Tandy computer one mile home to play with on the weekends). So now, the tools, telemetry, and tactics that were instituted to protect your critical assets from end user workstations no longer apply.

Second, the burden of watching for threats has shifted from the SOC to the Remote Access team. While remote access has long been monitored by the SOC, the Remote Access team is now the main source of intel to look for threats against the organization. Because they often lack full expertise in the existing telemetry, this has forced what can be an initially challenging cooperation between the two teams.

Third, in many cases, organizations simply were not ready to have 75-80 percent of the workforce working remotely from either a security or an availability perspective. Enabling a shift of this magnitude has led to a lot of risky behavior, including an increased use of Remote Desktop Protocol (RDP), internally and externally.

Trends in RDP Usage (Plus the Risk Involved)

Shodan ("the world's first search engine for internet-connected devices") reported significant growth in RDP exposure in March.

We're seeing the same behavior on ExtraHop Reveal(x), which identifies several dozen different application types, among them RDP Servers and RDP Clients. We have noticed a huge spike in internal RDP Servers as a result of Remote Desktop being enabled on company workstations.

Below we see a customer with over 3,000 RDP servers. Note the spike over a five week period as their workforce rapidly shifted to remote work.

On the one hand, after the disaster created by BlueKeep and the later DejaBlue vulnerabilities, which left nearly one million internet-connected computers vulnerable, I'm surprised we haven't learned our lesson when it comes to the risks of RDP. If attackers gain access to a poorly-secured device, they can easily share infected files, locate other devices to target, etc.

On the other hand, COVID-19 has forced Remote Access and Security teams into a catch-22. They can either install a VPN client on a non-managed system (if that is EVEN possible, given the state of most home computers), or they can open up RDP to their internal system. Both options are less than ideal, but which evil is worse?

If you have to use RDP, be sure to follow these best practices.

What Can You Do, and How Can ExtraHop Help?

This is about to get technical. We're going to look at some specific risks incurred by exposed RDP, and I'll provide some real-world examples of what we're seeing in our customer base as well as how they're using network detection and response (NDR) to address these dangers.

If you have externally exposed RDP or this has happened without your knowledge, the first step, as with any risk, is to know about it and make sure you have visibility around it. NDR tools like ExtraHop Reveal(x) make this pretty easy to do, allowing you to monitor the protocols in use across your environment.

Risk: External RDP Surveillance

Reveal(x) learns typical behavior within your environment and alerts you to transactions that are new or unusual. When we see a host that has never allowed an external (non-RFC1918 address with exclusions for your public space) RDP connection and then it suddenly does, Reveal(x) will fire a detection and bring your attention to it.

Real-World Example:

We have observed a significant spike in RDP probes (and NOT just from Shodan!) at recent customer sites.

What does that indicate?

Attackers know that more companies are enabling RDP ad hoc, and they're looking for victims, but they don't necessarily want to wait for Shodan to tell them where potential vulnerabilities are.

How does NDR help?

By using Reveal(x) to track and geocode IP addresses that probe more than a single host, our customers are able to figure out which IPs source from countries that lack decent extradition or are blacklisted.

Risk: Lateral RDP Surveillance

We have seen a massive increase in RDP server activity with a number of our customers. If a bad actor has a beachhead within your infrastructure, they now have a very nice, and in some cases, very vulnerable new port/protocol to exploit.

Real-World Example:

In a recent Red Team exercise, we were asked about accommodating an "active adversary" scenario. In this case, they wanted to see if Reveal(x) could detect an RDP Password Spraying attack. Given that the number of available RDP servers has dramatically increased many internal RFC1918 address spaces, we thought the exercise to be very timely and relevant.

We wrote a custom detection that would trigger in the event that Reveal(x) observed a high number of RDP sessions in a five-second period (rather than the 1:1 relationship you'd expect to see with most non-Citrix systems).

What does that indicate?

If a single client has attempted to open a dozen RDP sessions in a five-second period, that could mean an attacker is trying to brute force their way into your network.

How does NDR help?

Not only can Reveal(x) detect password spraying, but our machine learning is powerful enough that you can keep up with attackers as they adjust with delays and jitter.

Additional Risks: Unsecured Remote Access Services

Another observation we have made in recent weeks is activity that I would call "Hedging your Remote Access Bets." We have noted a number of sessions with remote technologies that allow remote access and circumvent your company VPN/Access Gateway. Services like Teamviewer, Logmein, Parallels, GotoMyPc, etc. should be known about and approved.

At a minimum, they introduce risk to your organization as they are a way to usurp policies that go into your Remote Access strategy. These services may be known, but they'll likely serve as a "get out of jail free" card for your Cyber Insurance provider should any of them be found to be a vector in a breach.

Conclusion

We are all working with a new reality these days, especially if remote work is not something your company is accustomed to. Risks are a fact of life in IT. If you have had to accept a risk like RDP to ensure business continuity, it is imperative that, at a minimum, you have visibility into what these systems are doing. If the users you are supporting no longer generate logs, events, and you cannot install or even update your EDR solution, you can fall back on network visibility as it remains the ultimate source of truth, even in a global pandemic.