Hash injection Attacks in a Windows Network

Hack Injection Attacks – Ever Wondered ?

Why an exposed LM/NTLM Hash is comparable to a clear-text password
Why a 127 character long password is not necessarily stronger than a 4 character long password
Why generating LM/NTLM rainbow tables is a complete waste of time
Passing-the-hash for direct authentication to remote systems
Why one vulnerable system can compromise the entire Active directory forest
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.

Here I will be writing about “hash injection”.

Conceptua

This is the concept of injecting a compromised 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.

Demo of Hash Injection Attack

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.

Theory of Hash Injection Attack

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 am simply using a psexec connection connecting to the compromised server:
In this first scenario I am running a Truesec tool named Gsecdump to dump the logged on user 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.
I am trying to set up a net use session and just as expected, my current credentials do not allow me to mount the hard drive on the domain controller. So, my approach would 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 “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 am 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 would 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/Smart-cards

The first natural reaction would be to think that PKI-based smart card logon would solve the problem. Even though I am 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 smart cards to authenticate
(The security settings in Windows can not force smart-card-based logon for network access, only interactive.)

The fact that passwords will be changed into long randomized passwords when you implement smart card 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 is really easy to try the extracted hashed passwords for different user accounts. My experience from the field is that it is 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 is 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 could enforce Kerberos or native PKI/smart card authentication for network authentication this could 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 many thoughts of my own on this topic, but before I post them I am very interested in ideas from others.