Passing-the-Hash to NTLM Authenticated Web Applications

The fundamental technique detailed here was previously discussed by Alva 'Skip' Duckwall and Chris Campbell in their excellent 2012 Blackhat talk, "Still Passing the Hash 15 Years Later…" .

One of the main advantages of a Windows Active Directory environment is that it enables enterprise-wide Single Sign-On (SSO) through the use of Kerberos or NTLM authentication. These methods are typically used to access a large variety of enterprise resources, from file shares to web applications, such as Sharepoint, OWA or custom internal web applications used for specific business processes. When considering web applications, the use of Integrated Windows Authentication (IWA) - i.e. Windows SSO for web applications - allows users to automatically authenticate to web applications using either Kerberos or NTLM authentication. It is well-known that the design of the NTLM authentication protocol allowed for Pass-the-Hash attacks - where a user is authenticated using their password hash instead of their password. Public tooling for this kind of attack has existed since around 1997 - when Paul Ashton released a modified SMB client that used a LanMan hash to access network shares [2].

The use of Pass-the-Hash (PtH) attacks against Windows environments has been well documented over the years. A small primer of references discussing these attacks, selected from amongst the many good resources available, follows:

1. The official Microsoft documentation detailing how "The client computes a cryptographic hash of the password and discards the actual password." before attempting NTLM authentication. Useful for understanding why PtH for NTLM authentication is possible in Windows environments: https://docs.microsoft.com/en-us/windows/desktop/secauthn/microsoft-ntlm.
2. Hernan Ochoa's slides discussing the original Pass-the-Hash Toolkit: https://www.coresecurity.com/system/files/publications/2016/05/Ochoa_2008-Pass-The-Hash.pdf. These describe a working means to execute PtH attacks from Windows machines that had been developed in 2000.
3. All of the Passing-the-Hash blog. The pth-suite Linux tools are of specific interest (When they were originally released, these were coded for Backtrack Linux. Most of these tools have found a new home in Kali Linux, with one notable exception - which contributed to the writing of this blog post): https://passing-the-hash.blogspot.com/.
4. "Pass-the-Hash Is Dead: Long Live LocalAccountTokenFilterPolicy" - A discussion of PtH for local user accounts, and the additional restrictions imposed on this form of PtH since Windows Vista: https://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/.
5. Exploiting PtH using the PsExec module in Metasploit: https://www.offensive-security.com/metasploit-unleashed/psexec-pass-hash/.
6. The Github documentation for the PtH module in Mimikatz: https://github.com/gentilkiwi/mimikatz/wiki/module-~-sekurlsa#pth.

One of the specific applications of this attack that has always interested me is the ability to PtH to websites that make use of NTLM authentication. Due to the ubiquity of enterprise Windows Active Directory environments, a large number of internal corporate web applications make use of this authentication scheme to allow seamless SSO to corporate resources from company workstations. Being able to execute Pass-the-Hash attacks against these websites is therefore a useful technique for effective post-exploitation on Windows environments. The full impact of this is apparent when a full domain compromise occurs - i.e. after a complete domain hashdump for a given domain has been obtained, which contains the NT hashes associated with all employee user accounts. Pass-the-Hash, in this scenario, effectively allows the impersonation of any corporate employee, without needing to crack any password hashes, or keylog any passwords from their workstations. Meaning that even for the the most security conscious users, who might have used a 20+ character - generally uncrackable - passphrase, there would be no protection against an attacker using their compromised password hash to impersonate them on a target corporate web application.

So, the question becomes, how would one practically carry out such an attack against an NTLM authenticated website? For a long time, performing Google searches of this topic and trawling through the results offered me no additional insight into how to use current (circa 2015-2018) tooling to execute such an attack. When considering the estimable set of Pass-the-Hash tools available in Kali Linux - pth-suite - there was a strange gap. While most of the original pth-suite tools made their way into Kali Linux in 2015, the notable exception - which I alluded to earlier - was pth-firefox, which, as the name suggests, patched the NTLM authentication code in Firefox to allow Pass-the-Hash. Since this Linux tooling was unavailable to me, I turned my attention to investigating techniques that use Mimikatz on a Windows host to perform the same attack.

After having discovered a working technique myself, I recently stumbled upon pg 30 of the original "Still Passing the Hash 15 Years Later…" slides, presented at Blackhat 2012 and delivered by Alva 'Skip' Duckwall and Chris Campbell [1]. These detail a method of convincing Internet Explorer (or any browser that makes use of the built-in Windows "Internet Options" settings) to authenticate using IWA, after injecting the desired NT hash directly into memory using Hernan Ochoa's Windows Credential Editor (WCE). They give a demo of this specific technique at 18:29 of their presentation [3]. Given how long it took me to find this information, and in order to document the relevant steps for practical exploitation, the remainder of this post details how to execute this attack using Mimikatz from a Windows 10 host.

In order to illustrate a web application that makes use of NTLM authentication, I used an Exchange 2013 server, configured to exclusively make use of IWA for Outlook Web Access (OWA). The relevant PowerShell configuration commands run on the Exchange server, from the Exchange Management Shell, were as follows:

Other prerequisites which were in place:

• This Exchange server was joined to the test.com domain. On this domain, a user, named TEST\pth, was created with a complex password and a corresponding mailbox. The NT hash of this user's password was calculated, to later be used as part of the attack. The NT hash was generated as follows:

• After this, a recent version of Mimikatz was downloaded onto a non-domain joined Windows 10 host, which was connected to the same network as the Exchange server. In order to allow us to use the domain name of the Exchange server, instead of its IP address, the DNS server on this standalone machine was set to the Domain Controller of the test.com domain.

Assuming that our OWA web application was accessible on "https://exchange.test.com/owa", browsing to OWA normally would result in the following prompt:

This prompt is generated, as the machine does not have any domain credentials in memory and the WWW-Authenticate header received from the website specifies that it accepts NTLM authentication.

Running Mimikatz as administrator, we can start a command prompt in the context of the TEST\pth user, by using the Pass-the-Hash module in Mimikatz - sekurlsa::pth - and supplying the user's NT hash as an argument:

This will not alter our local rights on the machine, but will mean that if we attempt to access any network resources from the newly spawned command prompt, it will be done in the context of our injected credentials.

In order to ensure that our browser is running under the context of these injected credentials, we spawn an Internet Explorer process from this command prompt, by running "C:\Program Files\internet explorer\iexplore.exe".

Inspecting the "Security Settings" for the "Local Intranet" zone in the "Internet Options" dialog, we can see that - by default - authentication is only automatic (i.e. using SSO) for websites that are present in the intranet zone. This is pictured below:

Thus, in order for a Pass-the-Hash attack to work from Internet Explorer on a Windows machine, the target site must be added to the "Local Intranet" zone. Instead of adding websites to this zone individually, it is possible to use a wildcard domain, in this case "*.test.com", which will match all subdomains of "test.com". Such a configuration is pictured in the following screenshot:

After this configuration, when browsing to "https://exchange.test.com/owa", the TEST\pth user is automatically authenticated through NTLM authentication and OWA then successfully loads.

After the compromise of the domain, the ability to PtH to web applications allows for efficient, and relatively simple, impersonation of any employee, regardless of access privileges, to any company-owned web applications that support IWA. Whilst this might primarily include Microsoft web services, such as SharePoint and OWA (if IWA is specifically enabled), various custom-developed internal financial applications, including those used to pay external parties, have been seen to do the same. When looking at the industry move towards cloud environments, Active Directory Federation Services (ADFS) is commonly involved to facilitate authentication. ADFS, by default, supports IWA when an Internet Explorer user agent is provided [4]. In such a scenario, this would imply that PtH can be performed to access company resources in the cloud.

While the main purpose of this post is not to talk about the complex issue of securing a Windows Active Directory environment, and indeed, cannot do the topic justice while staying on point, some high-level considerations for addressing these attacks are provided for those interested. Some further detail, not discussed here, can be found in a previous post, Planting the Red Forest: Improving AD on the Road to ESAE.

The ability to PtH in Windows environments cannot, in itself, currently be addressed. Both of the protocols that Active Directly uses for SSO inherently allow for PtH-style attacks. The most effective recommendation in this line is thus to prevent compromise of password hashes and Kerberos keys in the first place. Most importantly, this entails ensuring that Domain Controllers, Domain Administrator access, or any other means of obtaining the stored credential information within Active Directory, is not compromised, as this would directly result in the compromise of all stored password hashes and Kerberos keys. On Windows 10 and Server 2016, credential material stored in memory can be protected against credential theft attacks specifically through the use of Credential Guard.

When looking at IWA for web applications in isolation, enforcing the use of Multi-Factor Authentication (MFA) during the login process can be effective. As a specific case-in-point, when ADFS is used with Office 365, initial authentication may be performed through IWA, but a second factor can be required in order to complete authentication, after which access to company resources is granted. Unfortunately, this approach cannot be used to address PtH more generally, as not all relevant protocols have support for it. SMB, for example, does not support MFA, but still provides functionality that allows for remote code execution, thus permitting attackers to move laterally inside corporate environments using PtH unhindered.

The underlying concept behind Pass-the-Hash is that once a credential store is compromised, it is possible to use the stolen stored credential material (which should never be the plaintext password!) in order to authenticate as a user, without needing to first obtain the corresponding plaintext password for that user.

When referring to Microsoft's documentation concerning their implementation of the Kerberos protocol, it is described how "Kerberos Pre-Authentication" is used to obtain a Kerberos Ticket Granting Ticket (TGT). This process requires the user to send an "authenticator message" to the domain controller; this authenticator message "...is encrypted with the master key derived from the user's logon password." [5]. Later, the documentation explains that when the DC receives the TGT request, "...it looks up the user in its database, gets the associated user's master key, decrypts the preauthentication data, and evaluates the time stamp inside." [5]. This means that the key itself is used for validating authentication, not the user's plaintext password. The user's password-derived key is stored in the AD database, meaning that if this database is compromised (as happens when an attacker obtains domain administrator credentials, for example), the stored key can be recovered - along with the user's stored NT hash. Since only the stored key is needed to create a valid authenticator message, Kerberos authentication is inherently "Pass-the-Key". Alva Duckwall and Benjamin Delpy [6] called this attack "Overpass-the-Hash", and the sekurlsa::pth Mimikatz module supports crafting Kerberos Pre-Authentication requests using only Kerberos keys.

The implication of this, of course, is that if a web application, or any other corporate resource, supports direct AD-backed Kerberos authentication, Overpass-the-Hash can be used for authentication against it.

[1] "Still Passing the Hash 15 Years Later: Using Keys to the Kingdom to Access Data" presentation slides - https://media.blackhat.com/bh-us-12/Briefings/Duckwall/BH_US_12_Duckwall_Campbell_Still_Passing_Slides.pdf
[2] NT "Pass the Hash" with Modified SMB Client Vulnerability - http://www.securityfocus.com/bid/233/discuss
[3] "Still Passing the Hash 15 Years Later: Using Keys to the Kingdom to Access Data" Conference Video - Beginning of PtH demo: https://youtu.be/O7WRojkYR00?t=1109, Accessing SharePoint using only the NT hash: https://youtu.be/O7WRojkYR00?t=1210
[4] Configure browsers to use Windows Integrated Authentication (WIA) with AD FS - https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-browser-wia
[5] Kerberos Authentication Service Exchange - https://docs.microsoft.com/en-us/windows/desktop/secauthn/authentication-service-exchange
[6] "Abusing Microsoft Kerberos - Sorry you guys don't get it" presentation slides - https://www.slideshare.net/gentilkiwi/abusing-microsoft-kerberos-sorry-you-guys-dont-get-it