Hash injection Attacks in a Windows Network

Aka

Why an exposed LM/NTLM Hash is comparable to a clear-text password

Aka

Why a 127 character long password is not necessarily stronger than a 4 character long password

Aka

Why generating LM/NTLM rainbow tables is a complete waste of time

Aka

Passing-the-hash for direct authentication to remote systems

Aka

Why one vulnerable system can compromise the entire Active directory forest

Aka

One of the scariest Windows authentication hacks you ever saw .......

 

During a Microsoft MVP summit in Redmond I demonstrated some of the work done by my group (Truesec Security Team) to some fellow security MVPs.

I was asked to write a blog on one of the "hash injection"-demos I demonstrated, so here we go:

Conceptual:

This is the concept of injecting a compromized hash into a local session and then use the hash to authenticate to network resources. This method eliminates the need for password cracking in a windows environment.

Description of the demo below:

1. Hacker compromises one server/workstation using a remote/local exploit. (This is not demonstrated in this demo)

2. The hacker extracts logged on hashes and finds a logged on domain admin account hash

3. The hackers use the hash to log on to the domain controller

4. The hacker extracts all the hashes in the Active Directory database and can now impersonate any account in the domain.

Demonstration:

The starting point of this attack is that an attacker has control over at least one computer using for example a client/server-side exploit. (Since this demo is not about exploits I will leave that out in order to keep focus on the authentication attack)

To simulate a remote exploit, I'm simply using a parallel xec connection ing to the compromised server:

In this first scenario I'm running a Truesec tool named Gsecdump to dump the logged on hashes. I can see that both a user from the hell-domain named marcus is logged on as well as a local account named service1.

My next step will be to use the domain-joined password hash to connect to the domain controller.

Before I do that I will try to connect to the domain controller without the hash to prove that I do not currently have credentials to access the domain controller:

'M trying to set up a net use session and just as expected, my current credentials doesn' t allow me to mount the hard drive on the domain controller.

So, my approach wocould be to start a new session on our local attack-machine and inject the hash into that session:

The Msvctl tool is a Truesec internal tool that we use in this case to create something similar to a "runas"-session, but instead of using a username and a password we are simply injecting the hash.

The Truesec Msvctl tool will initiate a new cmd session in the context of the user marcus with the injected hash:

Now when we run the net use command again I'm allowed mounting the hard drive on the domain controller. This works since the Marcus account is a member of the Domain Admins group.

The natural finish wocould be to run the Gsecdump tool again and extract the password hashes from the entire active directory database:

This means that since we can extract all the password hashes we now can impersonate any account in the entire domain using the Msvctl tool.

Another thing that deserves to be mentioned is that the exact same method can be used to extract the local hashes stored in the SAM (Security Account Manager) database of a client or a server:

In my experience as a pen tester, most environments still use identical local administrative accounts and passwords between servers and clients. the effect of this is that I can use the local hashes from this computer and use it to gain full access to other servers or clients. this drastically increases the chance that I will be able to extract logged on hashes from any member of the Domain admins group since I will control a greater number of computers.

(In this demo I have deliberately left out a lot of info on what the Truesec-tools do exactly and we will not make the msvctl tool publicly available .)

Conclusion:

This attack proves that if one computer is fully compromised then the attacker can directly impersonate all the logged on accounts and the accounts stored in the local SAM database or Active Directory Database.

Other important things that needs to be mentioned:

PKI/Smartcards www.2cto.com

The first natural reaction wocould be to think that PKI-based smart card logon wocould solve the problem. even though I'm personally a big fan of PKI/Smartcard-based authentication it doesn' t prevent this attack.

The issue is that LM/NTLM can still be used for network logon event if the users are using smartcards to authenticate

(The security settings in Windows can't force smart-card-based logon for network access, only interactive .)

The fact that passwords will be changed into long randomized passwords when you implement smartcard doesn't change anything. The hash is still there and we are simply using that hash, not the password.

Using the same password for different users

It's really easy to try the extracted hashed passwords for different user accounts. my experience from the field is that it's very common that admins reuse passwords between service accounts, their regular user accounts and their administrative accounts. this means that the low privileged user account that we extract from the admins desktop often gives us control over important servers and sometimes even the entire domain.

The length of the password it not of importance in this scenario

In this scenario it doesn't really matter if a password is a one character password or a complex 127 character password since we are only using the hash.

A simple security or registry setting is NOT all it takes to get rid of LM/NTLM hashes for network authentication

The highest setting (Even in Windows Vista) is "Network Security: LAN Manager Authentication Level = Sent NTLMv2 response only ".

If we cocould enforce Kerberos or native PKI/smartcard authentication for network authentication this cocould solve the problem. You can actually do this but it will require an IPSEC authentication implementation in the network.

The purpose of this post is to generate a discussion on potential countermeasures. I have too thoughts of my own on this topic, but before I post them I'm very interested in ideas from others.

 

Credits

This work is a team effortAnd the biggest credit shoshould rightfully go to Johannes Gumbel for research and coding. Jonas ländin for researching and testing. Hasain Ashakarti for his fantastic intelligence and support.

Guys, being in the same team as you in not only educating and stimulating, it's also incredibly fun!

-Marcus Murray, Truesec Security Team

A post on countermeasures and my personal thoughts will be posted shortly.

Find it on the Truesec Public Tools Download Page

Find it on the Truesec Public Tools Download Page

Http://www.truesec.com/PublicStore/catalog/Downloads,223.aspx