Protecting Privileged Domain Accounts: Network Authentication In-Depth

[Author's Note: This is the 5^th in a multi-part series on the topic of "Protecting Privileged Domain Accounts". My primary goal is to help incident responders protect their privileged accounts when interacting with comprised hosts, though I also believe this information will be useful to anyone administering and defending a Windows environment.]

To coincide with my recent SANS webcast on Protecting Privileged Domain Accounts, I decided it was time to get to work and publish my findings on network authentication. So here goes!

Just to recap this journey, I started out with a discussion on how to protect Windows password hashes. Then I took a short diversion to look closer at the LM hash, and in particular, the fact that it is stored in memory even if you implemented all of Microsoft's protection features to disable it. Next was a discussion on a relatively new discovery in the InfoSec world?the fact that our passwords are stored in memory in a form that can be easily dumped out to plaintext. My last article was a discussion of access tokens and how they can, in some circumstances, allow an attacker to impersonate you on the network. In this article, I will cover network authentication in a Windows domain.

Microsoft Network Authentication Protocols

The purpose of a network authentication protocol is to provide a method to authenticate a user or computer against a remote credentials store. Ideally, the protocol will provide strong cryptography to protect the authenticating credentials from exposure to eavesdropping and replay attacks.

Many remote authentication protocols are based on a challenge-response mechanism, where a client makes a request to a server, the server issues a challenge, and the client answers that challenge based on a secret that both the client and server know. This is the basic architecture for the legacy Microsoft network authentication protocols. Other network authentication protocols use a trusted third-party system, which is the architecture for Microsoft's current core authentication protocol, Kerberos.

Let's look at a quick summary of the native Microsoft network authentication protocols:

LM (Lan Manager) Challenge-Response

Introduced in the late 80's with OS/2, this was the primary remote authentication protocol for Windows versions prior to Windows NT. The answer (response) that a client provides to the server challenge is generated from the weak LM hash.

NTLM Challenge-Response

Introduced with Windows NT, the primary difference is the inclusion of a second response using the NT hash. If the account's password supports an LM hash, the NTLM response from the client will include 2 answers: an answer based on the LM hash and another based on the NT hash. If the password is a strong password that breaks the LM hashing algorithm, only an answer based on the NT hash will be provided.

NTLMv2 Challenge-Response

Introduced in Windows NT 4.0 SP4, a number of security improvements were introduced, most notably mutual authentication. You may also see LMv2 discussed with NTLMv2. LMv2 is effectively the same protocol as NTLMv2, except it uses a truncated client challenge to better support "pass-through" domain authentication on legacy clients (I'll discuss "pass-through" authentication shortly). The main take away is that both LMv2 & NTLMv2 use only the NT hash to calculate the response to the server and they both implement mutual authentication.

Kerberos

Introduced with Windows 2000, this is a ticket-based system with its origins at MIT. It requires the NT hash to complete authentication. Much more to say on Kerberos soon.

A great single resource for these protocols is the book Implementing CIFS: The Common Internet File System by Chrisopher Hertel. The book is available free online, and the chapter on Authentication is where you'll find a very thorough discussion of all of these protocols.

All versions of Windows, up to and including Windows 8, support all previous legacy network authentication protocols. Of course there are some problems with the older protocols, which led to the development of the newer protocols. Let's look at some of these problems and how Microsoft addressed them?and why we need to be wary of them.

Problem 1: Lack of Mutual Authentication

A major issue with the first version of LM and NTLM challenge-response protocols is that the only entity that gets authenticated is the client. This means that when using these protocols, it is quite possible to reveal sensitive authentication information to a rogue server. Here's how the LMv1/NTLMv1 challenge-response process works (note that for simplicity's sake, this diagram depicts a client authenticating to a server using a local account on the server rather than a domain account?I'll discuss "pass-through" domain authentication shortly):

1. The client needs to connect to the server, so a logon request is made to authenticate to the server.
2. The server says, sure, no problem, just answer this challenge based on your password hash.
3. The client has the password hash (LM hash for LM challenge-response as well as NT hash for NTLM challenge-response), so it computes the response to the challenge based on the password hashes.

When this is a legitimate server, the server calculates the answer just like the client, since it also knows the correct hashes (for a local account). It compares its answer with the client's answer and if they match, the client has successfully authenticated.

However, when the server is rogue, it has gained sensitive information for this account. It doesn't have the raw password hash that was used to calculate the answer, but now it has all the information it needs to guess the password hash?it has the challenge it issued and the correct answer from the client. In practice, rather than blindly guessing password hashes, the most fruitful attack is for the rogue server to issue a static challenge for which it has already pre-calculated many possible hashes (and corresponding passwords) for that challenge. In other words, the malicious server can issue a static challenge and the attacker can use a pre-computed Rainbow Table to determine the password hash (and password) that resulted in the correct answer. There are free LM challenge-response Rainbow Tables available for the static 8-byte challenge of 1122334455667788 and tools such as Metasploit's smb_sniffer module as well as Cain and Abel will use this challenge by default. To see this attack in action, check out this excellent article by Tim Medin. Tim sets up fake SMB and HTTP services with Metasploit and once the victim answers the static challenge, Tim shows how to crack it to get the password.

Microsoft addressed this issue with the introduction of NTLMv2, and LMv2 which is a slight variation specifying a shorter client challenge for purposes of backward compatibility. The updated versions fix the problem by including a client challenge to provide mutual authentication. Here's how it works:

Steps 1 & 2 are the same as before. However, in step 3, the client returns an answer to the server that is based on the server's challenge AND a challenge provided by the client. If the server is legitimate, it can easily verify the answer using the hash, its challenge, and the client's challenge. On the other hand, if the server is rogue and doesn't know the password hash to calculate the answer, it can no longer utilize a pre-computed Rainbow Table attack because there is randomness introduced in the form of the client challenge. It is still possible for the attacker to leverage a brute-force attack against the challenges & response, but it's no longer feasible to pre-compute these guesses with a Rainbow Table attack.

As I'll discuss shortly, Kerberos is the best option for network authentication, but there are times when it will not function and Windows will revert to an LM/NTLM-based protocol. In these situations, we want to make sure we're using NTLMv2 for the security benefits of mutual authentication. The Recommendations section at the end of this article discusses how to enforce NTLMv2.

Problem 2: Reflective and Relay Attacks

These two attacks are very clever. The Reflective Attack has been addressed, but the related Relay Attack is still a concern for us. Let's look at the Reflective Attack first:

I won't talk you through the steps, but to summarize this attack, the rogue server effectively turns the tables on the client and forces the client to inadvertently provide the authentication answer to the rogue server which allows it to connect right back to the client machine.

This particular issue has been resolved with Microsoft patch MS08-068. The patch prevents an SMB client from answering challenges that its own SMB server service has recently issued. This works well in this particular use case. However, this turns out to be a specific solution to a more general problem, as the Relay Attack demonstrates.

The Relay Attack still co-opts the client to answer a challenge, but this time the rogue server passes the answer to a 3^rd machine in order to gain access, as shown here:

Relaying tools have been around for a while, including SmbRelay3 and Metasploit's smb_relay module. Those tools are very effective, however they only support NTLMv1. A recent Metasploit module from Rich Lundeen provides NTLM relaying for NTLMv2. Another new tool called ZackAttack by Zack Fasel does it as well.

With the previous Reflective Attack, the fix was for the client to make sure it doesn't answer any challenges that it recently issued from its own server service. Unfortunately that solution will not help us with this issue because it would not be feasible for all clients in a particular domain to keep track of each other's challenges.

So what is the fix? Well, many people argue that the fix is SMB signing. I disagree for at least a couple of reasons. I don't want to bog down this part of the article with a bunch of extraneous details, so I will add a few comments at the end of the article as footnotes to this section. For now, suffice it to say that one of the biggest reasons why SMB signing is not a solution is due to the fact that there are other services besides SMB that utilize LM/NTLM authentication, which couldn't possibly be protected by SMB signing even if it worked perfectly for protecting the authentication exchange for SMB (which it doesn't).

The most complete protection against the relay attack is a feature called "Extended Protection for Authentication" (EPA). In a nutshell, EPA provides the following to NTLMv2 authentication:

• EPA embeds the Service Principal Name of the target service with an integrity hash signed by the account's credentials in the logon request. (The Service Principal Name is the name by which a client uniquely identifies an instance of a service on a specific host.)
• Extended Protection works because only domain controllers and machines where the user directly enters the password can compute/validate the integrity hash. Therefore, new requests cannot be created by a rogue server because it cannot sign the new request.
• A rogue server also cannot forward (relay) a request sent to it because the 3^rd host would recognize that the request had a destination Service Principle Name of the rogue server rather than itself.

This article describes how to enable EPA for SMB, this article for IIS, and this article for SQL Server.

This feature protects the authentication layer. A very robust implementation for SMB would include both EPA and SMB signing, preventing the forwarding of credentials (EPA) as well the altering of SMB traffic (SMB signing).

The tough part about implementing EPA effectively (or SMB signing for that matter) is that it needs to be required throughout the domain to be truly effective. If it is optional, the attacker can simply craft a request that tells the server it doesn't support the more secure settings. Another complication is that EPA is implemented on a per-service basis, so there's no single switch to make it all "just work". Nevertheless, EPA is the best overall solution for protecting NTLMv2 authentication from the relay attack.

The Big Problem: Poor Design

The thing that makes LM/NTLM challenge-response protocols so difficult to secure in a domain environment is that they use "pass-through" authentication. This allows a rogue server to be "man-in-the-middle" of the authentication exchange, as shown here:

As you can see from this diagram, in a domain environment, the server sends the challenge to the client and then receives the answer. Once it does, a legitimate server will package the challenge and response and send it to the domain controller for verification, since the domain controller has the password hashes and can calculate the answer for verification. The problem is that the answer is still sensitive, and when the server is compromised, the domain credentials are at risk by exposing the answer.

So what is the best solution? Avoid LM/NTLM protocols and use Kerberos instead!

The Big Fix: Kerberos to the Rescue

With Kerberos, there is no more pass-through authentication. We now have a trusted third-party architecture where the authentication happens directly between the client and the authentication store (the DC). Upon successful authentication, a ticket is granted to the client, who then presents it to the server for access.

This sounds great! We should just use Kerberos and completely disable LM/NTLM protocols, don't you think? Well, unfortunately it's unlikely that you can completely eliminate NTLM in your environment. The following situations still require NTLM, as outlined in Wikipedia:

• The client is authenticating to a server using an IP address.
• The client is authenticating to a server that belongs to a different Active Directory forest that has a legacy NTLM trust instead of a transitive inter-forest trust
• The client is authenticating to a server that doesn't belong to a domain.
• Where a firewall would otherwise restrict the ports required by Kerberos (of which there are quite a few)

The first one is a real trouble spot in most environments. There are a number of situations where you might want to use a specific IP address when connecting to a host. For example, if DNS records have not been properly updated, you may need to reach a host by IP. Another common scenario is the use of scripts or tools that sweep entire IP network ranges.

According to Jesper Johansson in Protect Your Windows Network From Perimeter to Data, the reason that Windows reverts to NTLM when the IP address is used is because "Kerberos is based on host names. Because Windows DNS does not create reverse lookup zones by default, the protocol cannot rely on a way to resolve IP addresses to host names. Therefore, it always falls back to either NTLM or NTLMv2 in that situation."

Nevertheless, we want to enforce the use of Kerberos whenever possible. This is particularly true on our IR workstations. Luckily, with Windows 7 and Server 2008 R2, we have the ability to do this via policy. Here is an example policy which denies outgoing NTLM authentication to all servers, with the configured exception of 192.168.6.12:

Being able to exclude certain trusted IP addresses on your IR workstation, such as a proxy server for example, is a very helpful feature. Notice that there are several settings available for adjusting the level of NTLM blocking and auditing. A good resource for learning about this feature is the Microsoft TechNet article "NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7".

Here is the result of some testing that demonstrates the NTLM blocking feature:

And here's the Event Log entry from the blocked NTLM attempt to 192.168.6.11 (found in Event Viewer under Applications and Services Logs > Microsoft > Windows > NTLM):

In my testing with PsExec, NET USE, and WMIC, 2 of the 3 will use Kerberos by default. I'm not sure why, but I've found that WMIC needs some prodding to use Kerberos. Luckily, there is a switch?albeit an ugly, painful switch?to force WMIC to utilize Kerberos instead of NTLM. It is /AUTHORITY:"kerberos:domain\computer". Here it is in action?notice the first attempt fails because the NTLM restriction blocked it:

I told you it was ugly?but at least it works! If you're interested, here's a simple batch script you can use as a shortcut so you don't have to type all that in each time:

SET /P PCNAME=Hostname to query:
SET /P PCDOMAIN=Domain of host:
SET /P WMICCMD=WMIC command to run:
wmic /node:"%PCNAME%" /AUTHORITY:"kerberos:%PCDOMAIN%\%PCNAME%" %WMICCMD%

Name it with a ".bat" extension AND make sure the batch file (and any like it) is editable only by your privileged account. Otherwise a non-privileged user could add nefarious commands to it without your knowledge and then when you run it with your privileged account, bad things would happen.

Recommendations for Strong Network Authentication

First off, make sure that you are using Windows 7 as your IR workstation and enable the feature to block NTLM authentication where possible. One common IR situation where this will cause problems is when you need to authenticate to an IP address because the hostname has not registered in DNS. If this is the case, you can trick your workstation into using Kerberos by temporarily adding an entry in your "hosts" file (Windows\System32\drivers\etc\hosts) for the system you need to connect to. Then remove it when done.

In situations where you must use NTLM, make sure to enforce NTLMv2 in the Local Security Policy (secpol.msc) by setting "Network security: LAN Manager authentication level" to "Send NTLMv2 response only/refuse LM & NTLM", as shown here:

If you must further lower your settings, be sure that you are using a password greater than 14 characters (which you should do anyway). This will prevent the storage of the LM hash and therefore the worst you can do is NTLMv1, rather than LMv1. Furthermore, by having such a long password, it makes a Rainbow Table or brute-force attack against your NTLMv1 challenge/response difficult (I don't know of any Rainbow Tables currently available for NTLMv1?though that doesn't mean the APT doesn't have them).

If neither NTLMv1 nor NTLMv2 work, then you really have to consider the fact that this could be a downgrade attack. Be very suspicious of any hosts that require you to authenticate with LM challenge-response.

Finally, remember that the LM/NTLM challenge-response protocols are vulnerable to the relay attack, no matter the hash or strength of password. While SMB signing is helpful, consider implementing Extended Protection for Authentication for more complete protection. Given that there are several situations that limit the use of Kerberos, it may well be worth the time and effort to enable EPA in your environment.

That's all for now, other than some lengthy footnotes on SMB signing. While this was what I considered to be the last "major" piece of the puzzle for protecting privileged domain accounts, there are certainly additional ideas and issues to consider, so I'll be back with more on this subject in the coming weeks. Thanks for reading!

Footnotes on SMB Signing

As mentioned above, some consider SMB signing a solution for the relay attack. I don't think it is sufficient for a couple of reasons:

1. It only protects SMB services.
2. There's a flaw in Microsoft's implementation which could allow an attacker to effectively bypass SMB signing under certain circumstances.

The first issue is pretty straightforward. In a perfect SMB signing implementation, SMB signing protects against relaying the response to a 3rd victim SMB server by forcing SMB messages to be signed by a session key created from the account's password hash. A rogue server can't generate the session key because it doesn't have the password hash, so it can't send SMB messages to a 3rd server requiring SMB signing. However, this only protects the SMB service. If there were a tool available that would allow a rogue SMB server to relay the NTLM authentication to a non-SMB service, such as an HTTP server requiring NTLM authentication, the SMB signing feature would provide no protection.

There are a number of tools that implement NTLM relaying against non-SMB services. Kurt Grutzmacher wrote a tool called Squirtle which allows a web client's NTLM-authentication exchange to be relayed to an SMB server, which would fail if SMB signing is required. However, his code is open source and there is no reason that it couldn't be modified to allow a connecting SMB client to relay to non-SMB services such as an HTTP server (for example SharePoint or OWA) or other non-SMB services such as Exchange (MAPI/MSRPC) or MS SQL (Windows Integrated Authentication). A recent Metasploit module from Rich Lundeen provides similar capabilities to Squirtle, but with some additional features including the ability to relay NTLMv2. Another new tool called ZackAttack promises even more functionality and flexibility. So even if SMB signing worked as advertised, there are still a number of situations where our credentials would be at risk for NTLM relaying.

My second issue with SMB signing is that it doesn't work as advertised under certain circumstances. There is a limitation as implemented by Microsoft which could allow for privilege escalation against the victim SMB server in the relay attack even with signing enforced. As described on page 2 of this write-up from Juniper on the implications of SMB signing and WAN acceleration, the session key that is used to protect the client-server SMB communications may not need to be re-created if another user has recently established a connection between the client and server. In particular, it states: "The very first real login sets up the MAC key for a CIFS flow [CIFS = Microsoft's SMB implementation]. When the user logs out and logs in again with different usernames, this client/server CIFS flow will be signed with the MAC key that was previously computed." Juniper uses this to their advantage by having the customer create a "virtual user" on the domain that the WAN accelerator can use to establish a connection to the server before the legitimate client in order to get the session key for signing. It is then able to exchange signed SMB messages without knowing the real user's credentials (which would be necessary if the SMB client/server had to re-create the session key).

So how can this allow for privilege escalation? If an attacker has control of a system with a non-privileged domain user, he can then play the part of the "virtual user" in the Juniper solution. He can first set up an SMB connection to the victim SMB server with the non-privileged user in order to get the session key. He can then wait for the privileged user to establish an SMB connection to the compromised host, at which point the attacker can now forward the challenge/response and use the already established session key for signing. Now the attacker has an SMB connection to the victim server as the privileged domain user! Perhaps it is far-fetched for an attacker to go to these lengths (unless a tool becomes available to make it easy), but it is certainly possible until Microsoft addresses this issue.

Now with all that said, I certainly don't want to imply that SMB signing is useless. If it is required by servers and clients, it will certainly raise the bar, helping protect your SMB communications in most cases, and in all cases if Microsoft addresses the loophole leveraged by Juniper. So if you have it enforced in your environment, certainly don't disable it, but look to Extended Protection for Authentication for a more complete solution to the NTLM relay problem.

Mike Pilkington is a Sr. Information Security Analyst and Incident Responder for a Fortune 500 company in Houston, TX, as well as a SANS Mentor and Community Instructor. Mike will be teaching FOR408: Computer Forensic Investigations - Windows In-Depth in Reston, VA, Nov 12-17, 2012.