Protecting privileged passwords is always extremely important, and you may think just because you use a very long password that is highly complex that it may take a hacker days, weeks, or even years to break into your system. Or you may also think that giving regular users local admin rights on their workstations or laptops, while not ideal, really isn’t THAT bad. After all, the user’s elevated rights would not extend beyond their local computer, right? Or how about giving low-level help desk staff administrator rights on certain servers or computers in the domain? Fairly low risk, right?
Think again, as these scenarios may not seem overly dangerous to your average administrator or IT manager, but to a person with a couple of free tools, they could potentially 0wn your entire Windows forest in just a few short seconds…without having to decrypt long complex passwords, download large rainbow tables, or use large computing resources.
How? Very simple really…it’s called passing the hash. This is not a new attack, and if you are a security professional then I’d sincerely hope you are aware of this attack vector because it’s been around for a long time. But there are a couple of freely available tools that allow the attack to be accomplished in just a few seconds, even on the most modern Microsoft operating systems like Windows Server 2008 R2 SP1 and Windows 7 SP1.
To demonstrate this attack, I have two computers. The first is a Windows Server 2008 R2 SP1 domain controller (fully patched), called N001DC01. The second server is called N001Lync01, and is also Windows Server 2008 R2 SP1 (fully patched) and running Microsoft Lync Server 2010. Both have additional security lockdowns applied to them, including many of those required by the Federal Government.
In a typical corporate environment you would have a limited number of domain administrators, and then many delegated administrators with fewer rights. For this example, the sysadmin account is the domain admin, and on N001Lync01 there is a local administrator account called LocalAdmin. The domain admins would likely use their account to logon to most servers and clients in the environment to do their daily job such as fixing system problems, installing patches, etc. All accounts have long, strong passwords, that are 20 characters or longer. The domain name is contoso.net.
To completely 0wn the domain and elevate my rights from local administrator on one server to being a domain admin, I’ll follow this quick, pain free, process:
1. I’ll logon to N001Lync01 as the local administrator, localadmin. I’ll do a whoami to verify I’m who I say I am.
A few lessons can be learned to help mitigate this attack vector:
1. Do not give regular users local administrator rights on their domain joined computer. It’s pretty trivial for them to escalate their rights to full domain admin, given the right circumstances. Â
2. Limit lower level help desk staff to non-administrator roles on servers and clients. Don’t think giving them admin rights on everything but domain controllers is safe or low-risk. They can be a domain admin in just a few seconds.
3. Only use your domain admin credentials to logon to domain controllers. Use another delegated administrator account to access member servers or client computers. This at least makes escalation a little bit harder. Remember, don’t use privileged credentials on less trusted computers.
4. Limit service account rights to least privilege, and NOT domain admin. If the service account, say for auditing software, accesses every computer in the domain then any local admin on any computer can impersonate anyone else.
6. Use Authentication Mechanism Assurance, a new feature in Windows Server 2008 R2. Marcus Murray has a great blog on how to implement this in the real world.
If you want to try this out for yourself, in a test environment, you can download runhash x86 here, runhash x64 here, lslsass x86 here and lslsass x64 here. Remember, these tools could get you fired or worse if you use them in an unauthorized manner.
The tool PwDump7.exe seems to successfully retrieve hashes for users who are *not* logged on, but who have logged on before. An internet search for pwdump may turn up others . . .
Tjeez.. does this work with workstations where sysadmin’s have logged on to? Or does that hash has to be recent? Like before the kerberos ticket has expired?What are those hashes made up from? and what other methods are there to prevent this?