Pass the hash deep dive
In this blog post, I will be talking about pass the hash techniques and how the bad guys are using this to compromise a whole network and do great damage.
Microsoft confirms that 99% of cases reported to Microsoft consulting services for corporate networks being owned by a malware, is by using this technique.
Pass the Hash = Single-Sign-On
Any system that supports Single-Sign On SSO is affected by the pass the hash attack.
SSO in simple terms is when somebody uses his credentials to log on to a system, and some form of that credentials or the actual credential allows him to go and access other resources without retyping his credentials. This benefit of not having to retype your credential every time you access network resources like the corporate SharePoint site, comes with a problem, that if an attacker getd access to your machine, he can use those stored credentials and access the network using your identity.
In other words, if you want SSO, pass the hash attack is something that cannot be fixed and you must accept.
There are two types of pass the hash attack:
- Credential reuse: using the saved credentials on the system on which it was saved.
- Credential theft: taking the saved credential to another system and using it from there and allow attacker to spread over the network.
- John logs on his laptop by entering his username and password.
- John gets a user session on that laptop, and Windows verifier [in case of Windows, it is a one-way hash (NT one-way function)] creates the hash for the password.
- Now John can access a file server, and when doing this, the file server will send challenge/response to John to prove his identity, and John proves that by using that one-way function (password hash).
- Now, John gets a session on the file server.
Pass the Hash Technique
- Step 1: we have Fred. He logs on to his laptop and got a user session, so he has the one hash value of his password stored on the system. Now, an attacker gets over his laptop, or Fred runs a malware, or Fred himself is malicious. Now the malware creates a user session using Fred’s one-way hash password. Fred can now log off and has his session destroyed, but the malware has Fred’s one-way function (his hash) in its own session and it can go around the network as Fred.
- Step 2: malware will perform port scan and discovery to identify targets. Sounds like Jo’s laptop is an interesting target, so let us try to authenticate to it using Fred’s credentials. If Fred can access Jos laptop, a user session is created for Fred on Jo’s laptop.
- Step 3: what is worse if Fred has administrative rights on Jo’s laptop. With such administrative rights, malware can harvest (steal) Jo’s credentials. If Jo is a domain admin, then the malware has now domain admin rights. Malware can access for example a file server using Jo credentials, and now the whole network is compromised.
Where password hashes are stored?
Password hashes for all local accounts are stored locally on all Windows computers. Hashes for all domain accounts are stored on all domain controllers for a Windows domain. Hashes for currently-logged-in users whether local or domain are usually stored in memory in the computer the user is logged into (some exceptions apply)
Sue is a domain administrator. When Sue provides her username and password to log on her laptop, those credentials are fed to a process that is responsible for producing the Single-Sign On experience (Local Security Authority “LSASS”). LSASS hosts number of plugins, each one supports a protocol that Windows supports. Here are some of those plugins that are related to SSO:
During Logon, Sue’s raw credentials (username and password) are presented to each one of those plugins, to prepare the SSO experience. For NTLM, it takes the username and password and generate a one way hash value (NTOWF value) and keeps that in memory. Digest protocol needs to keep the actual password in memory to support SSO. While Kerberos takes the password, contact a domain controller, and get a Ticket-Granting-Ticket (TGT) and also collection of service tickets.
For the duration of Sue’s session, each plugin keeps its version of the credential in memory to support SSO. When Sue tries to access a network resource, the LSASS is asked if it can authenticate without prompting Sue for credentials, Kerberos for example says “I can do that, here is a service ticket”.
If an attacker gets admin access to your machine, he can pull all your password hashes. Attacker can use those hashes without knowing the actual password, and authenticate as you in the network, and even move from machine to machine.
The name Pass the Hash is just a historical name, when the attack was targeted to NT hashes, but it applies also to Kerberos. Attacker can steal the Kerberos ticket and use it as it uses the hash.
Smart card authentication does not defend you against this type of attack. Smart card is a great way to bind authentication with a physical object. You can give your password over the phone to someone, but you cannot do that with smart card. However, if I steal your ticket that represents a smart card logon, then I can get the same access you have with that Kerberos ticket.
It goes beyond that. Microsoft demonstrate a sample pass-the-hash attack as per the following:
- John logs on his machine where malware is running, and open a UNC path, then may be log off.
- The malware runs a tool called Windows Credentials Editor that connects to the Local Security Authority on the same machine and gets all hashes and service tickets.
- Malware can connect to the UNC using the Kerberos ticket captured and authenticates as John.
The funny thing, if the malware can take the actual password hash, it can connect to any resource to the network using that hash. While if the malware captures a service ticket, it can only access the network resource that that service ticket is pointing to. So it is more dangerous to capture NT hash than capturing Kerberos service ticket.
The problem with local accounts is that many organizations use the same username and password combination across machines. This can be because you have a standard image that you are deploying across the network machines, or because you use local accounts to troubleshoot problems on the machine where the network is not accessible and you cannot use network accounts.
Local Account Traversal , the problem
If Fred’s laptop has a local admin account called Admin, and Jo’s laptop has also a local admin account called Admin with the same password as the admin on Fred’s laptop, then if a network connection happening from Fred’s laptop to Jo’s laptop using that local Admin account, then the Security Account Manager (SAM) on Jo’s laptop will accept that connection, and will consider it as the local Admin account is doing the transaction or authentication.
Local Account Mitigation
You should not use local accounts to talk to resources across the network. When you want to do that, use domain accounts only. Moreover, you should make sure that the local administrator password is randomized or at least different in each machine.
The mitigation here is to prevent local accounts from being used to access network resources, even if you have the same local account user name and passwords across your machines for some reason. So if someone compromise one machine, he cannot use the local accounts to authenticate to other machines.
Two new well-known groups are introduced (Windows 8.1 and Windows 2012 R2):
- “Local Account”
- “Local Account and member of Administrators group”
You can go to your group policy editor, under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights\Assignments\Deny access to this computer from the network, and add one of those new well-known groups.
How pass the hash work in real word
Usually an attacker compromises a machine and the first thing he does is to get local administrative privileges on that machine. May be the attacker compromise the machine by drive-by-download exploit or an Excel macro, and escalated privileges using an HP driver vulnerability. Some new attacks will inject the Adobe reader and prompt for Adobe reader update, and trick the user to enter his admin credentials to download the new Adobe reader version.
Then the attacker (once getting admin rights on the machine) will start to dump the local hash database and getting the hash for all local accounts. The local security databases (SAM) contains the hash for all local users The attacker now uses those user accounts and hashes to try to remotely compromise other systems on the same LAN. If the password to a local administrator accounts is the same, and the account is not prohibited from remotely logging in, the attacker will succeed in remotely compromising those systems.