Terminal Services Attack Reductions Redux

Monday, September 10, 2012

Brent Huston


We recently published a post about the high frequency of probes, scans and attacks against exposed Windows Terminal Services from the Internet.

Many folks commented on Twitter to me about some of the things that can be done to minimize the risk of these exposures.

As we indicated in the previous post, the best suggestions are to eliminate them altogether by placing Terminal Services exposures behind VPN connections or through the implementation of tokens/multi-factor authentication. 

Another idea is to implement specific firewall rules that block access to all but a specific set of IP addresses (such as the home IP address range of your admins or that of a specific jump host, etc.)

This can go a long way to minimizing the frequency of interaction with the attack surfaces by random attacker tools, probes and scans. It also raises the bar slightly for more focused attackers by forcing them to target specific systems (where you can deploy increased monitoring).

In addition, a new tool for auditing the configuration of Terminal Services implementations came to our attention. This tool, called “rdp-sec-check”, was written by Portcullis Security and is available to the public.

Our testing of the tool showed it to be quite useful in determining the configuration of exposed Terminal Services and in creating a path for hardening them wherever deployed. (Keep in mind, it is likely useful to harden the Terminal Services implementations internally to critical systems as well…)

Note that we particularly loved that the tool could be used REMOTELY. This makes it useful to audit multiple customer implementations, as well as to check RDP exposures during penetration testing engagements. 

Thanks to Portcullis for making this tool available. Hopefully between this tool to harden your deployments and our advice to minimize the exposures, we can all drive down some of the compromises and breaches that result from poor RDP implementations.

If you would like to create some threat metrics for what port 3389 Terminal Services exposures might look like for your organization, get in touch and we can discuss either metrics from the HITME or how to use HoneyPoint to gather such metrics for yourself

PS – Special thanks to @SecRunner for pointing out that many cloud hosting providers make Terminal Server available with default configurations when provisioning cloud systems in an ad-hoc manner. This is likely a HUGE cause for concern and may be what is keeping scans and probes for 3389/TCP so active, particularly amongst cloud-hosted HITME end points.

PSS – We also thought you might enjoy seeing a sample of the videos that show entry level attackers exactly how to crack weak passwords via Terminal Services using tools easily available on the Internet. These kinds of videos are common for low hanging fruit attack vectors.

This video was randomly pulled from the Twitter stream with a search. We did not make it and are not responsible for its content. It may not be safe for work (NSFW), depending on your organization’s policies.

Cross-posted from State of Security

Possibly Related Articles:
Information Security
Firewalls Hardening Tools Attacks Network Security Configuration hackers Mitigation Terminal Services
Post Rating I Like this!
Ian Tibble RDP is not necessarily a Windows-based service, but we'll assume it is hosted on some variant of MS Windows here.
I am predominantly a Unix-oriented analyst but have no religious issues with Windows at all.

There are certain aspects of Windows that dictate against its usage in critical situations, and regardless of the data or apps hosted locally on the box, if a Windows box is made directly "visible" to the public Internet then it does suddenly become critical - assuming the rest of the network is routable and accessible from the Windows device.

If there's no choice but to use RDP in such a hazardous configuration, then comments about hardening here - good stuff, but the biggest safety measure is surely f/w configuration (yes, firewalls are useful after all) as per the comments from others.

Furthermore VPN is useful, but there are much easier attack vectors (usually) than middleperson deals/sniffing type efforts. Not as easy as many would have us believe.

The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.