In the Daily Drill Down entitled “Protecting your Windows servers from network attacks, part 1,” I explained that learning about the techniques hackers use is a great way to strengthen your network’s security. Since I covered workstation hacking in part one, I’ll cover Windows NT server-based hacking in this installment. I should point out, though, that these Daily Drill Downs are in no way a comprehensive guide to hacking techniques. You could actually write several large books on hacking. My purpose in writing this is merely to make you aware of some of the more common hacking techniques.

Why Windows NT?
Considering that Windows 2000 is the latest and greatest network operating system that Microsoft has to offer, you may be wondering why I’m discussing Windows NT. I’m focusing on Windows NT servers for the following reasons:

  • Many administrators have been reluctant to upgrade to Windows 2000.
  • There are far more Windows NT servers in the world than Windows 2000 servers.
  • Because of its larger installed base, Windows NT presents a larger target for hackers.
  • Window NT isn’t as secure as Windows 2000.
  • Many of the techniques that I’ll discuss also work on Windows 2000.

Gaining administrative access
No matter what you might have seen in the movies, gaining administrative access to a Windows NT server is no easy task—at least not when you do it over the network. There are several different obstacles that hackers must overcome.

Before hackers can break into a system, they must first determine that it’s actually a Windows NT system. Hackers can confirm the existence of a Windows NT server by using port-monitoring tools to listen to TCP ports 135 and 139. Port 135 is normally used for NTRPC (remote procedure calls) while port number 139 is used to communicate NetBIOS information over a TCP/IP network. Anyone with a network monitor can gain a wealth of information about your network by listening to these two ports. Therefore, unless the configuration of your network prevents you from doing so, the first step in securing your network is to block ports 135 and 139 on your firewall.

I’ve seen cases in which the firewall blocks ports 135 and 139, but hackers were still able to gain information about the network. In these particular cases, it was determined that the firewall PC’s TCP/IP configuration referenced an internal WINS server. Therefore, even though the hackers weren’t able to perform the standard port-listening routine, they were able to gain network information by looking at the WINS records. Remember that your firewall’s entire purpose is to shield your network from the outside world. I recommend that you thoroughly evaluate your firewall to make sure it isn’t compromising your network in a manner similar to the one I’ve described.

For hackers, determining that a network is running Windows NT is only the beginning. Depending on how the network is configured, hackers may or may not be able to gain access to such information as server names and a particular server’s role (PDC, BDC, member server, or stand-alone server) in your network.

If you haven’t made it easy for hackers to acquire this type of information, they will have to work pretty hard to get in. Even though they may not directly know server names, it’s usually fairly easy to determine a server’s IP addresses. From there, hackers can sometimes derive the machine name by using the –A parameter with the PING command. For example, you might type PING –A

Although hackers can gain access to the server name using the above method, the truth is that the server name isn’t a required piece of information—it’s just helpful to have. Remember that as long as you’ve blocked the ports I mentioned earlier, hackers have no idea about the role of your servers. (This, however, is assuming that they don’t have any sort of inside information about your network, such as the type of information gained by having a friend who works for your company.)Therefore, when they start to poke around your network, they usually won’t know whether they are breaking into a domain controller, a member server, or a stand-alone server.

The only real reason for wanting the server name is that many administrators design their networks so that each server’s name conveys something about the server’s purpose. For example, since my domain name is BUD, if I had a server named BUDPDC, a hacker would immediately know the server’s purpose.

As you install new servers, you might keep the whole server name trick in the back of your mind. Of course, if you have named your servers according to their role, I don’t expect you to go back and rename each server in your organization since doing so is a very risky chore.

Now, let’s assume hackers haven’t actually figured out your server names. In such a case, they will have to somehow figure out which server is which. Where hackers go from here really depends on what they are trying to accomplish. If they want to gain total control of a network, they will usually want to search for the PDC and then search for an account equivalent to the administrator account. If, on the other hand, they want to access a specific file or directory, it’s usually easier to find the server that’s housing that particular data.

Looking for a file
A hacker’s best bet when searching for a specific file or directory is to attack the server that actually houses the file. The reason for this is that if the server housing the file or directory isn’t a domain controller, then hackers have a couple of different accounts that they can use to try to gain access. They can either use a domain account that has access to the directory, or they can use one of the server’s local accounts. Often, network administrators will go to great lengths to guard the domain administrator’s password but will make a local administrator’s password something easy to guess. (As you’ll read later, guessing is a big part of the process.)

There are several reasons for making the local administrator’s password easy to guess. First, many administrators don’t see local accounts as a threat. After all, local accounts can’t even log on to the domain. Another reason is that local accounts are often used in disaster situations. For example, if a server crashes and is inaccessible through the network, a local account may be the only way to get into the server to begin the repair process. In such a situation, administrators will want to make sure that everyone remembers the local administrator password because no one wants to have to repair a server with an unknown password. Later, however, I’ll explain how it can be done.

Taking over a domain
If hackers decide to try to access a domain controller, they usually try to locate the administrator’s account and crack the password. This move is often a mistake, however. Sure, there are ways of breaking into the domain administrator’s account, but there are better techniques for getting into the system.

Remember that the domain administrator’s password is one of the most—if not the most—closely guarded secrets on any network. Therefore, the network’s administrator will usually go out of his or her way to make sure this account is safe. He or she will do things like change the account’s name from Administrator to something like John_Smith. The idea is to make the administrator’s account blend in with all the other user accounts so that it would be difficult for a hacker to figure out which account is the real administrator account.

Beyond changing the account name, an administrator might take other steps to secure the administrator’s account, including using a long, complex password, using elaborate logging mechanisms, and setting up fast lockouts. The administrator’s account is also the account most likely to draw attention if a hack attempt is made on it.

One method for hacking a system that is better than breaking into an administrator’s account is to go for another account with administrative privileges. For example, if hackers happen to know the administrator has an assistant named Fred, they might try to hack into Fred’s personal account, hoping that Fred’s account has Administrator rights. By far, the best way to gain access into a domain, though, is to crack the service account.

Depending on which optional components are running, Windows NT may have a service account that’s used when various system services authenticate into the system. For example, Exchange Server requires a service account. The benefit of hacking into a service account is that like local accounts, service accounts are often minimally protected. Administrators often find themselves using service accounts when new servers go online or when repairs are made to existing servers. Therefore, it’s important for the entire support staff to know the service account’s password.

What a lot of people don’t realize is that the service account may actually have permissions beyond those of even the administrator. In the case of Exchange 5.5, the service account has administrative privileges plus the ability to act as part of the operating system—which makes for one powerful account. Combine the strength of the service account with the fact that administrators rarely change service account passwords and the fact that service accounts usually have a user name like SERVICE, and you can see why these accounts make such great targets for hackers.

Guessing passwords
Once hackers have decided which server they want to attack, it’s time for the hard part, getting the password. There are a number of tools out there to help someone crack passwords, but many of these tools require a person first to log on to the network and obtain a password hash. Therefore, unless hackers have a couple of other tools, they will have to resort to guessing games. In such a situation, hackers must find a password to log on with in order to move on with their mission or acquire a hash and begin the real cracking process.

If hackers are trying to break in, there’s a good chance they won’t have the normal login prompt. Therefore, they must force Windows to give them the opportunity to enter a login name and password. There are a couple of ways to do this, but my personal favorite method (not that I would ever stoop to this level) is to use the Net Use command.

The idea is to use the pieces of information that are known in order to gain access to the system. The Net Use command is typically used to redirect the computer to a share point on a specific machine. A hacker may not know enough about your network to have this kind of information, but as you’ll see in the following two sample commands, it’s possible to use one of the built-in Windows NT share points in conjunction with either a server name or an IP address.

Consider the following two commands:

In the commands above, I used both an IP address and a server name with two different built-in share points just to show how the command works. You might also notice the * /USER:ADMINISTRATOR portion of the command. The /USER:ADMINISTRATOR portion of the command allows you to specify the name of the account for which you want to guess the password. The asterisk (*) is used in place of a password. When the asterisk is used, Windows will prompt you to enter a password.

When trying to guess passwords, remember that many users choose very weak passwords. Try checking your network for password examples such as blank passwords, the word “password,” user names, etc. I’ve also found that if you can gain access to the description that goes along with the account name, the description sometimes can reveal clues to the account’s password.

Local hacking
By far the easiest way to hack a Windows NT server is locally. My personal favorite tool for local hacking is Winternals Software’s Administrator’s Pak. This kit includes a variety of recovery tools that can be used to break into just about any Windows NT or Windows 2000 system. You can even reset the administrator’s password without actually knowing the original password.

In this Daily Drill Down, I examined some of the techniques that a hacker might use to break into Windows NT servers. I also explained some methods you can use to block such efforts.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.