Introduction

Guessing passwords is one of the oldest, yet one of the most effective techniques to gain access to a system. The reason that it is one of the most effective hacking techniques is because there's a weak link in the whole process: humans. This is because humans like "samantha1" better for a password than "Tr15%^<<lOPi>!+". Although the latter would be far more difficult to hack than the first password, there's a good chance that no user would ever get the latter password memorized.

This is what hackers take advantage of. The only thing a hacker needs is a logon "vehicle". This could be a command prompt, a web page or... the Microsoft Remote Desktop Connection conveniently included in every recent version of Windows or readily available from Microsoft's download site.

Hacking Slang

For clarity's sake, I'll briefly discuss some of the terms used in relation to password hacking. Basically, there are two kinds of password hacking attacks:

• Brute force hacking a.k.a. dictionary hacking attacks
• Password cracking a.k.a hash hacking attacks.

In this article we will be focusing on brute force hacking, using dictionary attacks. This simply means that the hacker will use a tool to automate the password guessing with an accompanying dictionary file: a file that contains every single password the hacker wants to try. Usually there are tens of thousands of passwords in a dictionary file and the hacking tool tries them all, pounding the server with logon attempts: hence the term brute force hacking.

Impact Of Password Guessing in Terminal Server environments

As in other fields of security, Terminal Server environments take up a special place. This is because Terminal Servers, by their very nature, allow interactive access. Interactive access in this context means that you're logged on to the server itself. This is the same effect as if you were walking up to the console in the datacenter and logging on there. This basically allows you to execute any program you can get your hands on and run it in the memory space of that server.

Another significant issue that arises from the fact that Terminal Servers are in the business of allowing interactive access, is an issue with the admin lockout. As you probably know, by default, the local administrator account cannot be locked out. Even if you use the passprop utility, you can only lock out the administrator account for remote logons, not interactive (Terminal Server logons). Only using passprop on Windows Server 2003 allows you to lock out the local administrator account. Because this could effectively completely lock you out of your own network, this isn't a configuration that is used a lot. Hackers know this and use this knowledge to perform brute force hacking attempts on administrator accounts.

Terminal Server Brute Force Hacking tool: TSGrinder

There are a couple of tools out there which allow you to perform brute-force password guessing in your Terminal Server environment. The most well-known however is a free tool called TSGrinder. TSGrinder is a command line tool which very basically allows automating password guessing via RDP connections. TSGrinder is a "dictionary" based attack tool, supports multiple attack windows from a single dictionary file (you can specify this on the program command line).

A very interesting option in the program is the "leet" function. This leet function enables the program to cope with a popular development in password-land. What I mean is that, from the knowledgeable user up,  people tend to secure their passwords by replacing letters with well-known symbols. For example, password becomes p@ssw0rd (replacing a's with @'s and o's with 0's). This is a very well thought thorough option because as we will see trying these passwords does not require you to change your dictionary file.

Another very interesting option is the "banner" option. What this option does, is acknowledge any messages prior to log on. These are the kind of messages that you have to acknowledge before you can log on to a server, usually a legal disclaimer of some sort. This logon message can be set in Group Policy in Computer Policies > Security Settings > Local Policies > Security Settings > Interactive Logon.

This was an issue in earlier versions of TSGrinder but that has been fixed now. This option basically renders the banner message useless as a countermeasure to these kinds of attacks.

TSGrinder also supports multiple password attempts in the same connection, and allows you to specify how many times to try a username/password combination within a particular connection (the default is 5) . This is used by hackers to help avoiding detection, because by default after 5 unsuccessful logon attempts, the Terminal Server ends the connection and an event is logged to the Terminal Server event log. The event looks like this:

So in the default config of TSGrinder you could have someone trying about 1,000,000 passwords and there would not be a single event in the event log (auditing excluded, we'll get to that).

Let's take a look at TSGrinder. The program comes with a very limited dictionary and leet file. You can be sure that hackers have far more advanced dictionaries. Running TSGrinder from the command line yields the help:

As you can see usage is pretty straight-forward. You can try it on your own test server, just like I did.

In this very simple example we will assume that:

• we have a dictionary file called "testdict" 
• we have a leetfile called "testleet"
• the username we are attacking is the default, administrator
• we want to acknowledge any logon banner messages
• we want to have 1 simultaneous thread
• the server we are attacking has the following IP address: 192.168.62.53

That would leave us with the following command line: 

tsgrinder.exe -w testdict -l testleet -b -n 1 -D 8 192.168.62.53

As you can see in the screenshot below, after a while, tsgrinder neatly finds that I've been using P@55w0rd! as my administrator password. It's that easy.

Countermeasures

OK, now that you've seen how easy it is to attack your Terminal Server environment, it's time to take countermeasures. Here are some concrete suggestions that can help prevent these kinds of attacks.

Rename administrator account
You should know that renaming the administrator account is considered a best practice. If you were not aware of that earlier, I sure hope you are now. When you rename the (local) administrator account, the hacker cannot use the administrator account to attack and must know the exact name of the renamed administrator account. This also has the added advantage that you can create a dummy administrator account that can be locked out (you do have account lock outs configured, right?)

Connection Security
Ideally you would want to make sure that users are already somehow checked before they attempt to logon to a Terminal Server. This used to be a huge hassle but now there's a free tool available that does just that and more! The tool is called 2X SecureRDP. 2X SecureRDP works by accepting or denying incoming RDP connections by IP, Mac address, computer name, client version or based on time of day, before the logon screen is even displayed. This significantly enhances the control you have over your Terminal Servers. As an added bonus you can limit users to one concurrent session. This doesn't really prevent brute force attacks from happening but it's a very nice feature that I know many administrators are looking for. Another great feature of this program is that you can log information for every allowed or denied connection and save it to a log file. Below is a screenshot of 2X SecureRDP.

Of course, this tool is not just for Terminal Servers,. It greatly suits every server you access via RDP. In fact, I recommend using this tool on every RDP enabled server.

Auditing
Enable extensive auditing. OK, so this doesn't prevent brute force attacks from happening but at the very least it allows you too log these kinds of attacks. You should audit successful and failed logons events. Because these audit logs tend to get cluttered very soon on a busy server, you should consider an automated audit tool. These kinds of tools monitor and filter the security event logs for you so that you can see what you need to see and be alerted when anything goes bad. An example and my personal favorite of such a program is SELM (Security Event Log Monitor) from GFI.  See a list of well-known similar programs here.

Logon Message
You should configure all of your servers to display a message at logon that must be acknowledged before you can proceed to log on to a server. This really isn't a technical countermeasure but more of a legal one. Once you've acknowledged the logon message, there's no way the perp can say: "I had no idea I wasn't supposed to log on to that server"........

Conclusion

Terminal Server environments are juicy targets for hackers. In this article I showed some techniques hackers can use to perform brute force attacks against local administrator accounts. I also showed you what you can do to prevent these attacks. Please keep in mind that these are just pointers and only make up a small part of the steps you should take to secure your Terminal Server environment.

 This article was previously published at MSTerminalServices.org.