TS Penetration and Defense

Thanks to Datalus[t] for providing this article on the basics of Terminal Services attacking and defense. To see more of this sort of thing, sign up for the group:

Cracking & Defending a Terminal Server

Blakdayz has been on my back about getting some content in here (and rightfully so), so I started pondering what type of content would be relevant to our members. My professional IT experience consists almost exclusively, and lamentably, to network administration in Windows environments. However, since I'm not the only one in this boat, I thought I would extend a collection of knowledge (read: no original thoughts here) on Terminal Services security to the group and allow for some constructive observations and reflections from others.

This will be a very basic guide, but will require a little knowledge of Terminal Services, the command prompt, and working in a Windows Server 2000/2003 environment will be handy. No programming knowledge required; we are going to be script-kiddies for the day.

I'll also make the obvious note that this information is for educational purposes only. I don't recommend doing anything listed here on a server that you do not have permission to touch, as there is a high chance you will be swiftly busted. For the sake of brevity

Overview:

Terminal Server is the server component of Terminal Services (now Remote Desktop Services). It's the service that allows you to open Remote Desktop (the client component) on a workstation or laptop and login to a remote server. Businesses everywhere use terminal servers to allow remote users to access applications from outside the network. It's also very popular for remote administration. Terminal Server listens on port 3389, and one of the first things a green Windows admin learns how to do is enable remote access through TS and setup a rule in the firewall to allow port 3389 to translate to the internal server.

Assumptions:

We are going to assume, for the sake of avoiding argument, that we only have access to port 3389 (or whatever port the server is listening on), and there are no other vulnerable servers on the same network segment that would present a more appealing target. It's important to remember that brute force attacks, particularly on a properly hardened server, are slow, noisy, and generally juvenile when you consider the wealth of more advanced attack vectors out there. However, since brute force attacks are so prolific, it's important to understand how they work and how to defend against them.


Attacking the Box

First, let's find a vulnerable box. If you already have the IP address of the server you wish to attack, you could skip this step. More than likely, you'll need to do some searching to find a readily attackable box. Here are a few tactics:

Port Scans Away Lads!

Fire up your favorite port scanner (nmap is always a solid choice) and scan away at port 3389. With nmap at the command line, this would be something like:

nmap -PN -p 3389,3390 10.0.0.1-254

I'll note here that a common technique for getting more than Terminal Server to share a single external IP address is to use NAT and translate other source ports to a destination of 3389 (Usually the ports just above 3389). This means you should not rule out scanning 3390, 3391, etc. in order possibly turn up additional servers or workstations listening on the victims IP address. I also used the -PN switch to disable pinging the target. Many firewalls have default configurations that do not respond to ICMP messages and we may miss a nice juicy server because of this; after all, we are only scanning two or three ports. If you are targeting a particular area (let's say you want to hack someone in your hometown), you could do a little digging to find out what subnet they operate on in your area and specify that in your scan. If you wanted to target a particular company, dig'ing their domains NS records and looking for something like "remote.companyxyz.com" or "rdp.companyxyz.com" in A/CNAME records is a good place to start, or simply port scan their web server and hope it has TS access turned on (a big no-no, but you'd be surprised).

If you aren't so keen on your IP address showing up in firewall logs (or reside in a country where port scanning is illegal), you can try anonymizing yourself with Tor. Tor bounces your encrypted requests around a random set of relays running the Tor server. Used correctly, you'll appear to be hitting a server from another country entirely. If you have never used it before, head to the Tor Project website and check it out.

Google for TS Web Directory

Many Terminal Servers are also going to have the TSWeb website installed . Try a Google search for "/TSWeb/default.htm" and you will find at least one or two results per page that show a Terminal Server that has port 80 open to the world. TSWeb (Which uses ActiveX) is great for admins because it allows us to simply tell a user to "Go to remote.companyxyz.com and sign in" instead of trying to walk them through getting an RDP connection started. However, it's also a great big announcement to the world that a remotely accessible server resides at this address. Small Business Server editions of Windows Server will ship with the remote workplace sites (including TSWeb) disabled from being accessed outside the network, a great security move by Microsoft.

Crack the Box

Once you've spotted a terminal server that is open to accepting connections, it's time to get cracking. Let's look at dictionary attacks first:

There are a couple of great tools to run dictionary attacks against TS boxes, but all of them will require a good wordlist. A wordlist (or word file) is simply a huge list of words that represent all the passwords you are about to try. I would recommend finding a large dictionary file and performing some transformations with a utility such as John the Ripper before piping the output to one of these tools (for example, add the numeral 1 or try capitalizing the first letter of every word). Transformations such as these will obviously increase the time it takes to crack an account exponentially.

There are a few utilities specifically designed for attacking a TS login. TSGrinder is the most popular and widely available, but TSCrack is out there also on some torrent sites (their main webpage disappeared awhile back).

TSGrinder is strictly a dictionary-based attack tool, there are no options (yet) for character-iteration (e.g. trying every combination of characters until a match is found). You'll also need to have the Microsoft Simulated Terminal Server Client Tool (roboclient) in order to run TSGrinder. Once you get everything downloaded and setup, pop in a command like this:

tsgrinder.exe -w wordlist.txt -u administrator -b -n 2 10.0.0.1

There are a dozen or so options for TSGrinder; the ones I've used here specify my wordlist (wordlist.txt), the account I wish to login to (administrator), the number of threads to run ( 2 ), and the "-b" switch jumps past any banner that is thrown up by the server.

You will almost always want to target the administrator account. The reason for this is that the administrator account typically cannot be locked out despite any lockout policies that have been specified. You are welcome to specify other accounts with TSGrinder, but you'll have to hope the administrator stuck with the default lockout policies to avoid locking out the target user before you've found the correct password. TSGrinder also has a built in feature that will limit the number of attempts on a single login session before opening up a second session. This will prevent you from triggering a 1012 event in the log that may trip an IDS.

There are other options to play with in TSGrinder, including a "1337" mode that performs some common exchanges of characters in your password list (for example, replacing "@" with the letter a). Once a correct password is found, it's all self-explanatory from there.

Defending the Box

Now that we've seen how simple it is to brute force our way past a weak password, let's look at some of the countermeasures that all system admins should be aware of.

Limit Access by IP

This is particularly important for servers that only have remote desktop enabled for administrative purposes. Most sufficiently advanced firewalls can include an ACL to block all inbound traffic and make exceptions for certain IP addresses that wish to connect on port 3389. For a Cisco firewall, your access list might contain an entry like this:

access-list 101 permit tcp host 10.0.0.1 host 10.0.0.2 eq 3389

If you only need to access the server from your office, and your office has a static IP address, there is very little reason to allow the entire internet community to have access to the Terminal Server. If your firewall does not have the capability, you can use the built-in Windows Firewall to control access by editing the scope of the RDP exception rule with a command similar to this:

netsh firewall set service type = Remotedesktop mode = enable scope = custom addresses = 10.0.0.1,192.168.1.1/255.255.255.0

Use a VPN Tunnel

If you have a large set of users who are accessing your Terminal server, consider installing a VPN client on their machines, provided you have the proper hardware on location. Then we would simply turn off RDP access from outside the network, only allowing users who are physically or virtually connected to our private network to access the server.

Rename the Administrator Account

This is a best practice on Windows servers, but is not often implemented on smaller networks. Renaming the administrator account means that the attacker will need to either know what the correct username is, or have a way to enumerate the UID's and find the administrator username. In addition to renaming the default account, you should always have another account in the administrators group that you actually use to login with and administer the server so that proper lockout policies can be implemented.

Setup Lockout Policies

If you haven't done this already, shame on you! Lockout policies ensure that users (and hackers) only have a limited number of guesses before the account is locked down and are very important in mitigating brute-force attacks. One down-side that should be noted for this: Enabling lockout policies may result in a DoS for a user account if a brute-force attack is attempted. I won't go into the ins and outs of lockout policies, but you can read more on TechNet.

Enforce Strong Passwords

Again, if you turned off the "Complex Passwords" requirement (unfortunately, very common) in Windows Server, shame on you! Most users, given the option, are going to use short, simple, dictionary words that (as we saw in the first section) are very easy to crack given some time. A minimum password length of 6 characters is really the shortest you should go, and simply moving it to 7 will increase the number of permutations by nearly a hundred fold. Again, you can check out account policies on TechNet.

Enable Auditing

This won't prevent someone from accessing the system, but it will help to leave a trail when someone launches brute-force attempts at your server. Enabling Account Logon auditing for successes and failures will ensure that any bad password attempt gets thrown into the security log along with the perpetrators IP address. Combine this with a log analysis tool or IDS and you can have some red flags go up automatically at any brute-force attempts.

Change the Listening Port

It may be a possible headache for your users, but switching to a port besides 3389 for remote services will help hide you from port scanners that are searching for open ports. If your firewall allows you to granularly control port translation, you can simply set it to translate incoming packets from a higher port (lets say 33890) to 3389 before forwarding them to your server. If you are stuck with a SOHO router that can't do this, Microsoft provides a KB article that will walk you through adjusting the listening port for TS. It's not recommended by MS, but should not cause any issues. Just remember to specify the port in your remote desktop connection ( e.g. 10.0.0.1:33890 ).

Conclusion

As easy as these steps are to follow for hardening your Terminal Server, there really is no excuse for having a publicly accessible box with weak policies and passwords. If you have any further suggestions for hardening (or attacking) a Terminal Server, feel free to post below!

- Datalust