Blog Categories

Subscribe to RSS feed


Hashes to Hashes, Domain Admins to Dust

Disclaimer: This blog is not an attempt to teach people how to hack systems, or access unauthorized data. Such actions are very likely illegal and subject to stiff criminal penalties, and could/should get you fired if you attempt these at your place of employment. However, the information described below is in the public domain and the bad guys already know this information. However, many administrators, architects, or security professionals may not be aware of a "new" class of threats that may keep you up at night. /End Disclaimer

Over the years, Windows administrators have been taught that LM (LAN Manager) hashes are insecure and they should be avoided because they can easily be cracked. LM passwords were stored in two sets of seven characters, so eight and 15 character passwords were no stronger than seven and 14 character passwords. There are a multitude of tools for cracking LM hashes, and this is nothing new to hackers or security professionals. NTLM hashes are strong and take more computing resources to crack. Although rainbow tables can help significantly in this effort, there is still non-trivial effort to crack the hash.

Now let’s step back for a moment. Why are we trying to brute force these hashes? To get the cleartext passwords so we can access resources on the network that is off limits. So why not just use the hash directly to access resources and dispense with the cracking all together? It would sure be quicker, and instant gratification always makes for a happy hacker. This is exactly what the remainder of the article will focus on. If you can grab the password hash (which is not hard given the right circumstances), you can then inject the hash into an authentication session and impersonate that user. A perfect administrator to impersonate would be a domain administrator, and then you 0wn the network.

Earlier this year I attended Microsoft TechED 2007, and was floored by a session presented by Marcus Murray of Truesec, based in Sweden (Trusec). The SEC310 session was so popular, they repeated it several times to massive crowds. He was an outstanding presenter and one of the demos left me speechless. The tool he used was not publically available but still scared the heck out the crowd. As of October 1, 2007 the hash injection he used tool is now freely available to the public so I will give a demo of it below and some mitigation techniques to help counter the hackers. You will need the gsecdump and msvctl tools from Truesec. (Download Here) It also doesn’t hurt to have the SysInternals psexec tool, but it’s not required. (Download Here)


The diagram below depicts the virtual lab environment I setup. It is a Windows Server 2003 R2 native domain, named Oz. Quay (pronounced "key") is the domain controller (notice the directory icon) and Hobart is a generic member server. All systems run service pack 2, and have the latest security updates as of this writing.

In the Oz domain I created a new account called "CompromisedDA" with the following password: 23-__-=409JSD*()djfj77&(*&iojhfJ1!!!"/?,,"vOIOI}{}lmN&*$#..#ghUY. Yes, I all think we would agree this is a strong password. I added the account to the Domain Administrators group. As any domain administrator would do, I logon the member server (Hobart) through the console to perform a task, say applying the latest patches or installing an application. I perform my tasks and then logoff the server after I’m done.

Next I create a domain account called "DelegatedAdmin" which does NOT have domain administrator rights. In fact, they will only be a member of the local Administrators group on the server Hobart. This would be your typical delegated administrator, say a SQL administrator, Exchange admin, helpdesk, etc. Or maybe it’s someone that you gave "temporary" admin rights too like a network guy to help troubleshoot a problem. Perhaps it is a consultant helping out on a project.

On Quay I create a directory at the root level called ThisIsQuay, which will be used later in the demo.

I then login to Hobart as DelegatedAdmin and copy the gsecdump, msvctl and psexec tools to the server. Remember, DelegatedAdmin does NOT have any rights on the domain controller so the following Net Use command to access the C drive on the domain controller Quay does not work (see below). It prompts me for credentials and I press Control-C to exit. I also did a whoami to show that I’m logged in as DelegatedAdmin.

Next I run the gsecdump utility which dumps the password hashes on Hobart, the member server. As you can see below, the CompromisedDA account is listed, along with the corresponding hash because I previously logged into Hobart to perform routine maintenance tasks. Hashes for service accounts are also dumped as well.

The next command is where all of the magic happens. I use the newly-released msvctl utility to pass the captured hash and open a new command prompt with the injected hash of the domain administrator account. Note: REMOVE the domain name and leading otherwise the command will not work. Well it will appear to work, but the subsequent net use will fail.

The tool spawns a new command prompt on the desktop in which I do a whoami and it shows I’m still delegatedadmin (see below). Hmm but what if I do the net use command to access the C$ of the domain controller? I get a successful message. To prove I have access to the domain controller, I perform a dir on the share and you see the folder I created earlier "ThisIsQuay." Holy cow batman, I’m now a Domain Administrator! The implications of this are enormous. Your network is now 0wn3d!

To further prove that this is working, I looked at the audit trail on the domain controller and found these interesting entries; six successful audit entries for the delegatedadmin account but NONE for CompromisedDA, or so it seems. Let’s look deeper to see what is going on.

Opening the 552 event ID, you see exactly what is happening. Delegatedadmin logged on using the explicit credentials of CompromisedDA, the injected hash. I must impress upon you, that at NO time did we need to hack the massively long password or brute force the account. It could take less than 30 seconds to grab the hash and gain remote access to the domain controller using the hash.

Now what is even more scary, is that I can use psexec to remotely run gsecdump on the domain controller, and dump the hashes for all the accounts in the domain, even for prior passwords! How cool is that? What is very interesting is that even though I specify the "-p pass" argument to psexec, it will use the hash that msvctl has injected into the command shell and not "pass" as the password. So I could have used anything for the password argument or even just have used "psexec –s \quay –c gsecdump.exe –s" command as well, and dispense with the supplied credentials all together. The extra typing can really slow down a hacker, so let’s keep this short and sweet.

What I also find interesting is that hashes for several accounts are the same. Just look at the hashes for SQL2005-SVC, LCService, S-SCOM-MSAA, S-SCOM-CSA, S-SCOM-DWAA, S-SCOM-DWRA and DelegatedAdmin. Since this is a test environment, when I was setting up these accounts I used the same plaintext password for all these accounts. So now an attacker can see which accounts have the same passwords. I don’t know if this is true 100% of the time, but is certainly the case in my test environment.

Since I have my black hat on, let’s look for other interesting people I could impersonate so let’s look for all the other domain administrators. Back on Hobart (the member server) in a plain vanilla command prompt with no hash injection capability, I issue the following command:

I see there are a total of seven domain administrators and in my previous gsecdump I already captured the hashes. Notice even if you have "discreet" names such as "Bob Hope" for your administrators that don’t match their real names it’s trivial to discover them even without ANY elevated rights in the domain. Authenticated users have wide-ranging read-access to AD objects, so what account names the domain administrators use is really not important since it can be easily looked up.

Service accounts usually have non-expiring passwords and probably logon frequently, so it would probably be smarter to impersonate a service account to help avoid detection. We could also just as easily create a new account and make it a domain administrator, but that is likely to be detected through auditing and would throw up red flags.

By now, you are probably thinking of words which I am not able to use in a professional setting. Or perhaps you are running for some smelling salts in the medicine cabinet. Take a few minutes to contemplate this attack, and then keep reading.

The World Has Not Ended

Before you think the world has ended and that anyone anywhere can become a domain administrator and 0wn you, there are two points to keep in mind. First, gsecdump will only run with local administrator rights (as far as I’m aware). Second, you can only steal hashes for accounts that were used to logon the computer you have administrator rights to. But with some cleaver work you may be able to incrementally elevate your rights even if the initial computer you have admin rights on never had a domain admin logon to it. I will explain this further later on.

Desktop Support Professionals

Think of this: Alice is a malicious employee that just found out she was going to be laid off in two weeks. She’s a local admin on her PC but she’s savvy enough to use the two tools described above to get the hash of a delegated desktop administrator professional, Bob, which works in IT and regularly works on her computer. Or she could use some social engineering and lure someone on the IT staff she knows is a domain admin to her computer and complain of a problem to "force" him to logon and try to fix a factious problem.

After running the tool Alice now knows Bob’s "secret" (just like Bruce Schneier) but Bob is not an all powerful domain admin. Darn! Alice now uses the psexec command to impersonate Bob and dump hashes on a multitude of workstations, since Bob has logon rights to all workstations since that is his job. Sooner or later Alice finds a computer that a domain administrator (which she recognizes from her dsget command) has accessed. Alice dumps that hash, and now has elevated herself to domain admin rights without cracking a single password, touching a dictionary, or using rainbow tables. In fact, she is disappointed it was so easy but is eager to plant a logic bomb in business critical servers. Doh!

In many companies employees are routinely local administrators on their PCs, so this threat could be very significant. Best practices strongly advises against local admin rights for regular users, and now you can really see why! Personally after seeing this attack vector myself, if I were running a corporate network I would be removing end user administrator access on PCs faster than you could say "I’ve been 0wned."

Server Administrators

Ok, so you think to yourself, my users do not have local administrator rights on their PC because I always follow best practices so that rules out 98% of my workforce that can steal my domain administrator credentials. Let’s talk about that 2% of delegated administrators, such as helpdesk staff, server administrators, DBAs, temporary consultants, Exchange administrators, etc. Like Alice, they can use their existing administrator powers to hop box to box trolling for password hashes from logons of days gone by. Since domain administrators are much more likely to logon servers than desktops, it is probably trivial to find a domain admin account. In addition, service accounts frequently can logon to servers and may very well have domain administrator rights. Monitoring solutions for server health, backup, inventory, etc. routinely require domain admin rights.

How do I protect myself?

Unfortunately, there is no easy answer. The long standing answer of longer more complex passwords is not of any use, which is the main point of my blog. Smart cards may not help the situation either. I checked the "smart card is required for interactive logon" box on the compromised account and the hash I previously stole continued to work. I don’t have a smartcard to see if that would leave a residual hash on the system which this utility could use, assuming no previous ‘password’ logons.

I tested this tool on a fully patched Windows Server 2003 x86 R2 server with SP2. Marcus demoed it on Windows XP SP2 at TechED. I tried running gsecdump on Vista and Windows Server 2008 RC0 and it returned an invalid handle error and did not dump the hashes.

Mitigation Strategies

  1. Do not give regular employees local administrator rights on their computers. This drastically reduces the number of users that can steal your hash.
  2. Only use your domain administrator credentials to logon to domain controllers. Do not logon on to member servers or workstations, ever, with your domain admin credentials.
  3. Domain administrators should have a separate delegated admin account that they use to logon member servers and workstations that does not have domain admin rights.
  4. Look for all audit event 552 IDs, which indicates explicit credentials were used to logon from another account. Setup high priority alerts on this event ID and immediately review. Some legit service accounts may trigger this ID, so filtering may be necessary. But a savvy hacker would impersonate a service account so it might be hard to distinguish from legit activity.
  5. Sorry but run-as doesn’t help you here. I created a new domain admin account DA-1, never logged on to Hobart with it but used ran-as on Hobart to open the event viewer on the domain controller and the DA-1 credentials were cached on Hobart. Do NOT use ran-as on workstations either, as it will cache your credentials. I recommend using remote desktop to access a server and perform your work that way.
  6. Kaspersky anti-virus recognized the tools I used as ‘malware hacktool/win32′ when I downloaded them and blocked access. So anti-virus or anti-malware running on machines might prevent the tools from running. It might be possible to disguise them or run remotely, but I have not tried it. However, if the user is a local administrator they could disable the AV software to allow the tools to run.
  7. Limit the use of service accounts that have domain administrator rights, so their hashes are not on a large number of computers. Never use domain administrator-level service accounts on client computers as clients are more like to have lots of administrators logging into them and increases the exposure risk. Software distribution or enterprise patching software may logon to all clients and servers, leaving credentials in a large number of computers.
  8. Protect your password hash as much as you protect your cleartext password.
  9. Keep all computers up to date with the latest operating system and application patches. A user that is not typically an administrator may use a known exploit in the OS or application (Quicktime, Acrobat, iTunes, Flash, Winzip, Java runtime, etc.) to elevate their rights to local admin and thus get access to the cached hashes.

How bad can this get?

Here is a very scary scenario which should give any administrator or security professional pause. Hopefully this will never materialize, but malware is getting more and more devious.

In many companies PCs routinely get infected with malware and spyware. Even if the user is not an administrator, a malicious user could use an exploit such as a buffer overflow to gain local administrator rights on the PC. So envision this: A user surfs to a web site, which is infected with a nasty new AD-aware virus. The browser is not patched, so it silently installs on their computer and runs with administrator rights. It dumps password hashes, looked up the nearest domain controller, and tries "net use" commands until it gets a hit. If that local PC had a domain admin logon to it, the virus now had domain admin rights and could do all kinds of bad things including destroying Active Directory, bringing down your entire network. Even if it didn’t get lucky enough to get a domain admin hash, it can scan the network for other workstations and servers and use the local hashes to jump ship to other targets. Eventually it is highly likely a domain admin account can be found. All of this could happen in a very short period of time without locking out domain accounts or setting off alarm bells.

Revealing Windows Secrets

The gsecdump utility has an interesting switch, "-a" which dumps all Windows secrets. However, it needs to run as LocalSystem which is tricky to obtain since you cannot run-as. By creating a special Windows service and starting the service, you can open a command prompt window in the context of Local System instantly. When you issue the start command a new command prompt window opens up that is running in the context of Local System. Ignore the 1053 error, as this is expected.

The second screenshot of the new command prompt window shows that whoami returns "nt authoritysystem" as the current user. Now, we can run gsecdump with the –a switch to dump all secrets, including hashes.

What I saw in the results of the –a switch, they really surprised me. The member server was running Microsoft Live Communications Server 2005 SP2 as well as Microsoft Systems Center Operations Manager 2007. In the list of secrets, I saw cleartext passwords for several services including OpsMgr and LCS. I’m not going to post a screenshot of the secrets on my test machine, so I will leave it as an exercise for the reader to test it out.


The attack vectors shown above are most easily carried about by insiders, be they regular employees or delegated administrators. Companies often focus on a "hard" perimeter of firewalls, IDS, IPS, 2-factor authentication for remote access, and only allowing corporate computers to access internal resources. But they do not spend as much time on insider threats, tough computer security policies, patching, and good administrative delegation. According to Business week, of 100 corporate breaches and losses of information that were made public in 2005, half were conducted by employees. (Article) Cnet news reported in 2006 that 78 percent of IT professionals claim their companies have suffer unreported insider-related security breaches. (Article)

It is clear that internal security is extremely important, and the ease of which the hash injection attack can take place demonstrates how important internal IT security controls are. In Government agencies where compartmented classified data processed, using the credentials of another user or administrator could lead to disclosure of highly sensitive need-to-know information.

I hope this blog has given readers something to think about, and will spur you to re-evaluate how you handle administrator access and password protection within your organization.

Leave a Reply